Snort Portscan help needed

I have a machine that is constantly showing up in my Snort logs. The machine is a proxy and does not have file/print or any netbios settings enabled (as far as I can tell).

Its constantly trying to connect to several machines on ports 139 and 445.
There are no suspicious processes and I've done full spyware/virus/trojan scans on it.

Quote:

---

[snort] (portscan) Open Port 2005-10-19 11:46:45 x.x.x.x x.x.x.x Raw IP

---

the payload is "Open Port: 139"

I've tried to tweak the preprocessor sfportscan as follows:

Quote:

---

preprocessor sfportscan: proto { all } \
memcap { 10000000 } \
ignore_scanners { x.x.x.x } \
ignore_scanned { x.x.x.x } \
sense_level { low }

---

Where x.x.x.x is the machine that keeps showing up in the logs.

It is also setting off some bleeding snort rules:

Quote:

---

BLEEDING-EDGE Behavioral Unusual Port 139 traffic, Potential Scan or Infection

---

Quote:

---

BLEEDING-EDGE Behavioral Unusual Port 445 traffic, Potential Scan or Infection

---

I've done some research on this, and it seems that this rule is being set off because an unusually high number of connection attempts. People recommend to tweak this rule or turn it off as it frequently creates quite a few false positives.

How can I suppress these portscan events from showing up in my logs?

I've looked at the threshold.conf but it looks like you can only set threshholds for certain rules but not preprocessors?

Is the machine yours? If so I would suggest running netstat on it to see what other 139/443 connections its attempting, and narrow it down to a process. You didn't state what OS its running, but from the 139 I would guess its a Windows machine. I'd also through tcpview on it to see what is causing it. It's possibly a false positive, but never hurts to check it out.

I ended up turning sfportscan off, for one I was getting way to many false positives, and secondly, I too couldn't get the "ignore" to work. To catch any large port scans I put IPAudit on the snort boxes which monitors connections and would display a spike on one of the graphs. This tool has also help to catch infected home users who are VPN'd in and infected with a network aware virus.

I'd be interested in how and if you get the ignore to work, since it's intended purpose is to do what you and myself needed. Oddly enough, I was unable to find via google where anyone else was having the same issue, at least, not yet.

TCPVIEW just shows connections from process id 8 which is "system".
Process explorer shows your normal system processes... svchost, etc.

I suppose I could do what you recommend. I configured up a box for ipaudit a while back but never put it in place. Easy enough to do... :) Ah well... That'll be last resort. I'm not giving up yet.

OK, I figured out how to configure snort to ignore the scanners....

Quote:

---

preprocessor sfportscan: proto { all } \
memcap { 10000000 } \
ignore_scanners { xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx } \
ignore_scanned { xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx } \
sense_level { low }

---

I didn't have the comma between the ip addresses, so it was just grabbing the last ip and ignoring the rest.

When testing the config file (with -T), here is the snipped out important info:

Quote:

---

Portscan Detection Config:
Detect Protocols: TCP UDP ICMP IP
Detect Scan Type: portscan portsweep decoy_portscan distributed_portscan
Sensitivity Level: Low
Memcap (in bytes): 10000000
Number of Nodes: 36900
Ignore Scanner IP List:
x.x.x.x / 255.255.255.255
x.x.x.x / 255.255.255.255
x.x.x.x / 255.255.255.255
Ignore Scanned IP List:
x.x.x.x / 255.255.255.255
x.x.x.x / 255.255.255.255
x.x.x.x / 255.255.255.255

---

I also figured out what was creating all the 139:445 entries... a service that introduced in a service pack on the proxy... all good now!

It is quite possible to suprress preprocessor based rules. You need to find the generator ID of the specific preprocessor you are using. This would depend also on whether you are using the sfportscan, frag2, or frag3 preprocessors. In any case, this generator id can be found in "gen-msg.map", and the specific signature can be found in "sig-msg.map", as far as I recall. I don not have access to my machine right now, so I can't check at the moment. But once you find the generator and signature id's, you can suppress them just like any rules-based signature. The rules only account for one generator, gen_id 1.

[EDIT]
Bah. Problem already solved.
[/EDIT]

Phish:

Sorry Kind of off topic but speaking of preprocessors, have you seen todays diary?

http://isc.sans.org/

Striek: Thats good to know for the future. I've been learning snort on my own for a bit now and I've gotten a LOT better than when I first started. There are still some things that trip me up though... guess I should pick up a book or something.

dinowuff: Thanks for the heads up. However, I've already taken appropriate action against this. :)

One more thing that bugs the hell out of me. Say I look at BASE from a remote web browser and see an alert like "PORN oral sex". When that "PORN oral sex" is displayed on my system, snort catches me looking at the log and logs it again. If I refresh, it'll add it again and again for each time it shows up. Kind of annoying.

I have snort deployed on our server subnet, but not on our desktop subnet. So I use a console from my desktop subnet to view my events, which is not seen by the sensor on the server subnet. Basically i don't care about my desktops being attacked, I do care about my server subnet being attacked from the desktop subnet. This stopped this alert echo affect you are refering to.

Now in almost every case if there are virus or trojans or attacks to the desktop network, it has to come by my external sensors or, they(desktop) are trying to scan IP's that are not on my network to begin with and they are detected going outbound by my perimeter sensors.

Since i do run IPAudit, again any scanning or mega traffic is seen by it, It all has to do with placement of your sensors.

The last thing you can do which is administratively taxing, change the signature from $HOME_NET to !xx.xx.xx.xx where xx... is the IP of where you view from.

Oh yea, one last thing, depending on where your DB is in reference to your sensors, you can get this same echo affect when the sensor sends the alert from the sensor to the database.

[edit] I did leave out one of the most important parts, there are 2 ethernet connections to each sensor, one which has no IP and is spanning the switch ports and a management ethernet connection that is in a port that is not spanned. [/edit]

Phish:

The policy rules for pr0n are not great rules at all since they look for the literal value alone in every packet tested. Thus whenever you send any packet via port 80 that the sensor can see the rule will trigger. Try moving the BASE web interface to a non-standard port like 85 and you will stop triggering the rule if it relies only on port 80 traffic.