1. Blumira Support
  2. Using Blumira
  3. Findings

Quick Links

Investigating "Connection from Public IP Address" findings

Overview

This guide provides helpful tips for investigating the group of “Connection from Public IP Address” findings using Report Builder to view all logs for the suspicious activity, including ways to identify the nature of connection attempts.

The detection rules associated with the group of findings covered by this guide are as follows:

  • SSH Connection from Public IP Address
  • SMB Connection from Public IP Address
  • RDP Connection from Public IP Address
  • FTP Connection from Public IP Address
  • Telnet Connection from Public IP Address

Due to the variety of ways connection attempts are logged by endpoints and firewalls, these detection rules can fire in instances where connections are initially allowed and then subsequently denied. They are designed to highlight the risk associated with having these protocols open to the public internet.

Events that can trigger “Connection from Public IP Address” findings

There are several event scenarios that can match the logic for protocol connection findings. Below are some common cases and tips for investigating.

Scenario Considerations
VPN access

Protocols like SSH may be configured with VPN access, and determining IP attribution may be helpful to ensure configurations are functioning properly.

Identifying source attribution with a whois lookup or open source IP reputation tool can help you determine the expected or filterable IP addresses.
WAN IPs (external IPs associated with hosts) This detection may fire on hosts with Blumira Agent installed if a public IP is found in the logs with similar connection attempts. If a finding is generated on a public IP associated with a host or internal IP, we recommend reviewing firewall rules and policies, and adding a detection filter as needed.
NAT gateways  Investigating to find out whether traffic is denied at the next step in the traffic flow may be helpful. Ensure that the dst_port is not open or accessible and firewall policies are in place. Filtering this out, after ensuring, may help to reduce noise from these detections.
Firewall policies or group rules In some instances, a connection from public IP address finding is generated when the “Accepted” or “Allowed” action is found in the logs. A firewall may later block the connection attempt after implementing a control. We recommend reviewing your firewall policies and ensuring they are working as expected to avoid false positive findings.
Malicious connections

If malicious connections are determined, check whether other security processes, such as Sophos, have blocked the connections.

We recommend doing the following immediately:

  • Close the dst_port and ensure it is not accessible.
  • Add firewall policies.
  • Add the external IP addresses that appear malicious to your firewall blocklist, such as with Blumira’s Dynamic Blocklists.

Using Report Builder to investigate and pivot on all logs for the destination port

Reference: See Using the Report Builder for more information about building reports.

To identify connection attempts via protocol, create a report that includes the following information:

  1. Keeping the finding’s detail page open, open Report Builder in a new browser window so you can refer to the finding while reviewing data in a separate window.
  2. In Report Builder, set Time Range to include the timeframe of the finding’s activity.
  3. In Data Sources, select the types that appear in the type field in the matched evidence table of the finding. Alternatively, you can click Edit Report and then click Select All Data Sources to expand the dataset to all log sources.
  4. Add a filter where dst_port equals the value of the suspicious source in question.
    Example: dst_port - Equal - 22.
  5. Click Include Suggested Columns or add columns such as those below, if available in your logs, which will provide you with helpful information about these connections:
    • timestamp
    • devname
    • status
    • action
    • n_action
    • ip_proto_name
    • src_country
    • src_ip
    • src_port
    • src_ip_geoip.countrycode
    • src_xlated_ip
    • src_xlated_ip_ipv4
    • src_zone
    • dst_ip
    • dst_port
    • dst_xlated_ip
    • dst_zone
    • reason
    • rule
    • rule_name
    • vpn
    • client_id
    • device_address
    • additional_fields
    • unknown_field
    • app_type
    • subtype
    • type
    • event_type
    • user
    • process_name
    • command
    • parent_process_name
    • parent.cmdline
  6. Click Submit.

While reviewing the report, look for the following information:

  • The device being connected to, its function in your network infrastructure, any security controls in place, and the device’s current exposure
  • Indicators of successful connections and exposure
  • Indicators of blocked connections following allowed connections (or successful firewall filtering being applied)
  • Indicators of VPN connections or other designed controls for managing access
  • Pivoting on the src_ip (external IP) attempting connections to the protocol may help to uncover logs related to the traffic flow

Creating detection filters in “Connection from Public IP Address” findings

We recommend adding detection filters that are as granular as possible to avoid filtering out too much activity.  For instance, protocols over their associated ports are integral to the detections, so we do not recommend creating a filter on DestinationPort. Adding details from the matched evidence such as country or geolocation information, if possible, can increase the granularity of the filter rule without compromising the efficacy of the detection. 

Caution: Do not filter on the DestinationPort by itself, because this will effectively disable the detection and remove visibility for connection attempts over the designated protocol.

Below are examples of detection filters that do not rely on the DestinationPort field:

  • Allowing connections between the two IPs (external to internal traffic) 1.1.1.1 and 2.2.2.2

  • Filtering findings from one SourceIP 1.1.1.1

Related Articles