[Snort-users] Calling all packet monkeys
snort_on_acid at ...131...
Wed Mar 23 07:02:35 EST 2005
Hehe ..."someone brought in a laptop with a foreign
IP" now there would be a sight to see, plugging in
your own IP and then expecting it to route back in...
OK, so Hi Paul in Dallas. I suspect that the TCP
session may have been started by an internal host that
was src: 161, dst: 135 and that the return traffic is
the answer to an established session over port 135,
and that your ACL allows established sessions first?
Just making sure, is the snmp traffic blocked at both
UDP and TCP? Hope this helps..
> Message: 2
> Date: Tue, 22 Mar 2005 16:21:54 -0600
> From: Paul Schmehl <pauls at ...6838...>
> Reply-To: Paul Schmehl <pauls at ...6838...>
> To: snort-users at lists.sourceforge.net
> Subject: [Snort-users] Calling all packet monkeys
> Setting aside the fact that we have a default deny
> policy on inbound
> traffic and the fact that I have confirmed that we
> *explicitly* do not
> allow traffic to port 161 (snmp), I am seeing some
> really strange traffic.
> The alert being tripped is:
> alert tcp $EXTERNAL_NET any -> $HOME_NET 161
> (msg:"SNMP request tcp";
> flow:stateless; reference:bugtraq,4088;
> reference:bugtraq,4132; reference:cve,2002-0012;
> classtype:attempted-recon; sid:1418; rev:11;)
> src host is a foreign address
> src port is 135 ?!?!
> dst host is an RFC1918 address
> dst port is 161
> Every one of the 38 packets has the ACK and RST
> flags set.
> Payload is:
> length = 20
> 000 : 00 00 00 00 50 10 02 00 00 00 00 00 00 00 00
> 00 ....P...........
> 010 : 00 00 00 00
> Anyone have any idea what this might be?
> (much less how it could happen?) I can only think
> of two possibilities;
> either a NAT address that's "opened a hole" or a
> spoofed src host.
> Paul Schmehl (pauls at ...6838...)
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
More information about the Snort-users