[Snort-users] Snort is not seeing all traffic...

PJ-ML p.jones.ml at ...8985...
Thu May 8 18:45:45 EDT 2003


Thanks, VERY effective. I saw all the packets to the specific host...10167 
packets received by filter, 2037 packets dropped by kernel. So it is seeing 
traffic to those "servers" that I thought it could not see before.

With that said, I am thinking that either my IDS is too weak of a machine 
and it is dropping packets (at the wrong time) because it can not handle 
the load OR I have my snort configured incorrectly (which would not 
surprise me).  I had someone use "Retina" to scan the host...from port scan 
to http attacks and I saw those packets scrolling in my term as well as 
when I was just using CIS-5.0.02 on those same hosts. Not sure what I am 
doing incorrectly.

~PJ



>At 11:23 PM 5/7/2003 -0400, PJ-ML wrote:
>>The ethernet link to hub and to other parts of the network are all 100. 
>>Could it be the speed of the server? I am lost in fog. Not sure where to 
>>go, I know that I must tune the server...but I do not know what to tune 
>>if it is not seeing even purposeful exploits...I will be more than 
>>happy  to give any more info that anyone requires to help me figure this 
>>out except for  the root password to my machine ;-)
>
>I'd first see if your snort box even has the packets sent to it, using the 
>all-seeing tcpdump tool.
>
>run tcpdump -n -i (whatever interface) host (target of attack) and then 
>re-run the attack.. does tcpdump spit out packets?
>
>As an example:
>
>snortbox # tcpdump -n -i eth0 host 10.1.1.1
>
>testbox # attack 10.1.1.1
>
>snortbox should have packets from the attack dump to the screen. Note that 
>the only reason I added -n to the tcpdump commandline is to prevent 
>tcpdump from spending a long time trying to do reverse DNS lookups. If 
>there's no DNS available tcpdump can hold off printing packets to the 
>screen for a shockingly long time.
>
>





More information about the Snort-users mailing list