[Snort-users] Problem with resp
bamm at ...539...
Thu May 24 23:34:44 EDT 2001
Before implementing tcp-resets, I suggest looking at the signature, and
more importantly, how the protocol for the connection you are attempting
to reset works. Attempting to reset http/web traffic is next to
pointless when looking for content like "cmd.exe". On the other hand,
resetting on the content "cat /etc/pass" (yes, I realize this is a
cheesy example) in a telnet connection will often be successful. Of
course this depends on the packets being "streamed" in the detection
engine since, unless the individual issuing the command is one heck of a
typist, each packet will be lucky to contain more than a couple of
characters. Also, notice how I reset at "pass" rather than "passwd".
This gives a us head start, and our reset only needs to beat the packet
containing the "\n".
The best use I have found for tcp-reset, is short-term incident
containment. In some (usually larger) organizations, the individuals
responsible for network security monitoring, do not neccessarily have
access to the firewalls/routers. So, once a compromise has been
detected, tcp-reset can be used to deny connections to/from the source
and/or dest hosts based on the ip addrs until the compromised system can
be removed from the network or filtered at the FW/router. Once long term
containment and IR procedures have been implemented, the reset rule can
Ball AeroSpace & Technology Corp.
Managed Security Services
rvisscher at ...2107...
Joe McAlerney wrote:
> In most people's experience, the spoofed packets generated by Snort to
> close the connection does not get sent out in time. The true packets
> get transmitted, then the spoofed packets stumble in with out-of-order
> sequence numbers. So, the connection is not reset. I have heard that
> libpcap is the bottleneck, and there is not really an easy way to solve
> Perhaps someone else can elaborate more.
> -Joe M.
More information about the Snort-users