Re: Repost: resp:rst_all not working

[Venkata Raghavan <dvrnews () yahoo co in>]

Matt

Thanks for your reply. I need a few clarifications.

I understand from your post that snort does send a
reset but because both the hosts (SMTP server and
client) are on a LAN the reset does not happen. Am I
right.

But my doubt is why is it not visible in a packet
capture in ethereal. The reset that was sent to the
linux client from snort is visible whereas there is no
such reset to the windows client. 

Am I missing something fundamental.


Venkat




 --- Matt Kettler <mkettler () evi-inc com> wrote: > At
04:00 AM 3/5/2004, Venkata Raghavan wrote:
> > alert tcp any any -> $HOME_NET 25 (msg:"SMTP Rule
> Testing"; 
> > flow:to_server,established; content:"test";
> nocase;resp: rst_all;)
> > After this, when I lauch an telnet (port 25)
> session to an SMTP server 
> > from my  windows client, the alert gets generated.
> But there is no reset. 
> > Then I tried the
> > telnet from a linux PC - this time it gets reset.
> > WHen I check the packets sent using ethereal, I
> observe that whereas from 
> > a windows PC the data "test" comes as four packets,
> from a linux PC "test" 
> > comes as a data of
> > single packet. I guess this is a problem with the
> WinXP version of 
> > Telnet  client.
>
> None of this is a problem in a telnet client
> Technicaly the windows XP one 
> is doing the right thing and disabling nagle..
>
> The reason it's "not working" is you're just unaware
> of the limitations of 
> tcp resets.
>
> 1) tcp reset is a race between snort and the host
> that you aren't sending a 
> reset to. Whoever gets the packet to the host snort
> is trying to reset wins 
> the race.
>
> 2) flexresp is only likely to win this race if
> there's a significant 
> latency somewhere between the hosts you are
> desynchronizing.  tcp resets 
> work VERY poorly within a lan.
>
> 3) It's pointless to send resets to an attacker. If
> they are smart, they'll 
> be filtering them. Reset your local server or client
> instead. Rst_all 
> doesn't hurt, but realize that the one sent to the
> attack originator won't 
> do much good unless the attacker is automated or
> stupid.
>
> 4) Smart attackers can generally evade flexresp by
> cheating and starting 
> the race early. non-nagled tcp connections (ie:
> telnet) are actually likely 
> to evade it by the natural patterns of their
> traffic. Flexresp2 makes this 
> harder, and will generally deal with nagle issues,
> but a clever attacker 
> can still have some chance of winning regardless.
>
>
>
>
>
>
>
>  

________________________________________________________________________
Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. 
Go to: http://in.insurance.yahoo.com/licspecial/index.html


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users