Snort Forums Archive

Archive Home » Rules » TCP Portsweep events with my IP as Source -Any help?

Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.

[ Notice: Full Version of This Topic ]

TCP Portsweep events with my IP as Source -Any help?

Posted by Asha2442004 on April 12, 2005 06:05:54

Hello all,
I have installed Snort 2.3.2 over FC3, the stealth interface is monitoring my PIX's outside interface. Now, my ids is generating some TCP Portsweep alerts with my PIX firewall (outside) as source IP, that could probably mean i am having a desktop or server inside my network which is having a spyware of some sort that is doing this scan. My firewall does a NAT/PAT for internet browsing. I am unable to ascertain which host is actually doing it and i don't think this is a false positive as the packet information seen from the BASE console is very clear. Can somebody advise on how i can zero-in to the host that is causing this alert.

Thanx in advance,
P

Posted by tomthebomb007 on May 06, 2005 10:35:51

I too am interested in the port scan alert, 1:469, from the two w2k hosts in my
test switch. They like to scan our domain controllers. My sensor is a linux box
inside the firewall spanning a GigabitEthernet port on a stealth cable. I am
told that many programs use nmap to get their buisness done. I guess the
question is are they doing in excessively or are they just checking the
availability of a few ports. Why are there not much in the false positive
section of this rule? I consider myself too new at this IDS stuff to add to
this.

Posted by bsmokeman on September 15, 2005 07:54:10

same here, portscans, portsweeps, tons of them, and we are not doing them.
false positives? I wouldn't think so due to the payload description.
8000 + all have payload with varying ip ranges, and port ranges like this:
000 : 50 72 69 6F 72 69 74 79 20 43 6F 75 6E 74 3A 20 Priority Count:
010 : 31 35 0A 43 6F 6E 6E 65 63 74 69 6F 6E 20 43 6F 15.Connection Co
020 : 75 6E 74 3A 20 31 36 0A 49 50 20 43 6F 75 6E 74 unt: 16.IP Count
030 : 3A 20 35 33 0A 53 63 61 6E 6E 65 72 20 49 50 20 : 53.Scanner IP
040 : 52 61 6E 67 65 3A 20 31 30 2E 30 2E 32 30 2E 31 Range: 10.0.20.1
050 : 3A 32 34 2E 33 32 2E 31 30 38 2E 32 34 36 0A 50 :24.32.108.246.P
060 : 6F 72 74 2F 50 72 6F 74 6F 20 43 6F 75 6E 74 3A ort/Proto Count:
070 : 20 34 34 0A 50 6F 72 74 2F 50 72 6F 74 6F 20 52 44.Port/Proto R
080 : 61 6E 67 65 3A 20 32 35 3A 34 36 37 31 37 0A ange: 25:46717.

Posted by Joel_Esler on September 15, 2005 15:52:23

I am not seeing a question here, is there a question? How can we help? The rule looks for a ICMP type 8
packet with a 0 packet payload. Yes, this can occur in normal traffic. It's not a false positive, its detecting
what it is supposed to be detecting.. If the rule is no use to you, either use suppression to stop the alerts,
or shut the rule off.

Joel Esler
SOURCEfire