Snort mailing list archives

RE: TCP Reset


From: Erik Engberg <Erik.Engberg () cygate se>
Date: Tue, 22 May 2001 13:09:26 +0200

My few cents on TCP kill/reset.

Pretty much useless for most DoS, BoF and anything else that can be spoofed.
Problem: They can be triggered to annoy a third party network and can waste
resources and bandwidth. Besides, you can never ever be sure it's not
spoofed to start with and that an attacker will "honor" a reset.
You need the IDS to function as a firewall or bridge and intercept the
packets to be effective against these kinds of threats. Or use the
functionality of Syn defender/Syn gateway/Syn proxy or whatever your
firewall vendor calls it.

TCP resets can be effective in certain cases:

To kill unencrypted established connections like telnet, smtp, ftp etc where
a prepetrator tries to do su, sudo, VRFY, EXPN, illegal SITE commands etc. 
Same goes for "keywords" in URLs, on webpages etc... (I´d recommend to use
another app to filter that).
Or why not kill backdoor traffic? Or kill unwanted traffic types on an
internal net where it's not practical with a firewall (get behind me
telnet!)

Wan't your machine to ignore resets? filter it out with your favourite
firewall (ipfilter in my case) or reconfigure your kernel to not give a damn
about them...
However, it won't be to helpful as a tcpkill should go to both machines in a
connection.

//Erik

-----Original Message-----
From: michael.porter () hushmail com [mailto:michael.porter () hushmail com]
Sent: Saturday, May 19, 2001 9:51 PM
To: Snort Users Mailing List
Subject: [Snort-users] TCP Reset


Hi,

What does the group think of the benefits of killing TCP connections, as 
available in FLEXRESP, or even the Tcpkill feature in ISS Realsecure?

From what I've understood so far, it's effective against DoS attacks like 
SYN-Flood, and of limited value against buffer overflow attacks; plus, it 
could be abused by the attacker too.

Since the 'Reset' is sent after the attack packet reaches the host, can 
it actually prevent the buffer overflow? Now, if the malicious code that 
gets executed adds a new account (say), wouldn't killing the connection 
after the event be quite wasted?

TIA,

Michael
Free, encrypted, secure Web-based email at www.hushmail.com

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users


Current thread: