1

According to manual.snort.org, TCP Portscans goes from one computer to other one, but when you take a look to an tcp portscan alert in snort/snorby you can see this:

In one hand: Source: 136.238.4.165 Dest: 10.19.0.5

On the other hand: Priority.Count:.5.Connection.Count:.18.IP.Count:.1.Scanner.IP.Range:.10.10.28.88:136.238.78.44.Port/Proto.Count:.6.Port/Proto.Range:.199:58891.

So, in one hand we have the source and dest fields, that says that machine 10.19.0.5 was scanned from 136.238.4.165. On the other hand, Scanner IP Range says that from the 10.10.28.88 to 136.238.78.44 was scanning to 10.19.0.5

How should i understand this information? Which device started the scan?

Txalin
  • 13
  • 3

1 Answers1

0

I think you're getting too hung up on the TCP connection terminology and how that relates to what Snort means by source and destination.

While Snort does have the capability to keep some state information for stateful inspection (called flowbits) the signatures are processed against individual packets. This means that the source and destination do not map to client and server, they map directly to the source and destination address fields in the IP header. So that means that the specific packet that caused this rule to fire had 10.19.0.5 in the destination address field and 136.238.4.165 in the source address field. We're talking about a single packet here, it has nothing to do with who initiated the session.

Also keep in mind how the sfPortscan preprocessor works. Its detection algorithm really just checks against 3 patterns:

  1. TCP/UDP traffic where one host talks to one host and hits many ports
  2. TCP/UDP traffic where many hosts talk to one host and hits many ports
  3. TCP/UDP/ICMP traffic where one host talks to many hosts on a single port

Largely because of the #3 this alert can be triggered by just about any system that's actually providing a service. For some reason Windows SMB fileservers seem to be the worst offenders for false positives. This makes the sfPortscan preprocessor exceptionally noisy. So noisy, in fact, that unless you have a tightly restricted network, and have the expertise to tune the output significantly, it's almost not even worth enabling this preprocessor.

Scott Pack
  • 14,717
  • 10
  • 51
  • 83
  • Thanks scott, so, if i understand you properly, i need to check on the payload field, concretely on the scanner ip range field, to find sources of the scan, isn't it? – Txalin Sep 17 '13 at 09:12
  • @Txalin: You definitely have to go to other sources, yes. Check your flow data, firewall logs, scanner logs, whatever you got. – Scott Pack Sep 17 '13 at 12:31