IP and Port Scan Alerts

Some network activity is unambiguously bad. When a DNS server is reflecting gigabits of traffic per second to a single target because it’s misconfigured and participating in a denial-of-service attack, it’s pretty obvious that something malicious is going on.

Other network activity is harder to judge. For example, network scans - either broad (a sweep of IPs on a LAN) or deep (an enumeration of services on a particular host) - can either be part of a routine survey, or a sign of a breach in progress.

This post will describe how to look at alerts from the Observable service for network scans.

Port scan alerts

The “Internal Port Scanner” alert will include one or more “Port Scanner” observations. These will include:

  • When the scan took place
  • Which machine on the network did the scanning
  • Which IPs were the target of the scans
  • How many ports the scanner hit on the hosts, and what type of services were targeted
  • How long the scan took

Some scans are obvious - they enumerate every port from 0 to 65535 as quickly as possible. Some try to evade detection by hopping around, going slowly, or only probing a handful of services (e.g. common database ports). The Observable service takes pains to detect various possible scanning patterns.

Clicking the Time link on an observation will show the network traffic associated with the scan:

Sorting the table by “Connected Port” is a good way to see the scan. The screenshot above shows the scan’s progression - each port is hit with a small amount of traffic. We also see unusual ports like as 13/tcp and 19/tcp, which are more common in scans than in legitimate sessions.

IP Scan alerts

“IP Scanner” alerts are similar - they include one or more observations that show how a network segment was targeted. Instead of showing an individual host, they show:

  • What IP block was targeted
  • What ports were used in the sweep
  • How many connections were attempted

As above, clicking the Time link on an observation will show the network traffic associated with the scan:

For an IP scan, sorting the table by “Connected IP” is a better way to see what’s going on. When we do that we see the scanning IP hitting several addresses in a row on the same port -, .2, .3, .4, .5...

Whitelisting expected scans

An IP or port scan might be something you do yourself to discover what’s on the network. However, it might also be something an attacker does once they gain access, so they can find out where to move next.

If you do regular scans yourself with a tool like Nmap or Solarwinds, or if you subscribe to an external service like Qualys’s, you might want to whitelist those scheduled activities ahead of time, so they don’t generate an alert. This way you can react promptly to unexpected scans, but not be bothered for expected ones.

There is a scanner whitelist in the Observable web portal - click the Settings icon, select the Alerts tab, and then select the Configure IP Scanner Rules item.

From that page you can fill out a form with the expected scans:

  • IP Address: This is the scanning machine
  • Connected Addresses: This is the IP block (in CIDR notation) that is expected to be scanned. You can whitelist all destinations with
  • Connected Ports: These are the ports that are expected to be used. You can whitelist all ports with 0-65535.

Once a scan specification is whitelisted, a scanner won’t produce an alert if it matches the specification. However, if it deviates (e.g. scanning outside the whitelisted range), an alert will be produced.

Detect Threats Faster – Start Your Free, No-Risk Trial