Re: [Snort-inline-users] Re: snort-inline Stream4 workaround

[Jason <sec...@br...>]

my .02

Rob McMillen wrote:

[...]

> 
> 
> I have a problem with an inline device sending resets onto the network.
> What happens if a "bad guy" figures out that your have an inline device
> that sends resets on certain packets?  How hard would it be to craft that
> packet that makes the inline device send a reset, but craft it with a
> spoofed source ip address?  This could potentially be used as a denial of
> service bot (I am sure there is a better term for this).
> 
> Am I just being too paranoid?

Other than advertising the presence of an inline device I do not think
that resets are a bad thing. There is no traffic amplification so it is 
a reflector at best. The attacker could simply craft the same packets 
and send them down the line. I can see where it might be possible to use 
the system as a reflector to reset internal connections however proper 
border filtering should make that a non issue. Even if the inline device 
used a "make state unusable" strategy and sent 3 or 4 bogus packets, 
they will be relatively small compared to the data being sent to the 
inline device so there would be a packet amplification but not data 
amplification case. This might open up other possible prediction attacks 
when using the system as a reflector but it is still an edge case and 
does not seem to have significant value. Time and motivation would 
ultimately test that one.

I can see where sending the reset to the attacker could highlight an 
opening for them to launch a DoS against the inline device through 
resource exhaustion but this problem is worse without the resets.

Perhaps a specific reset case where the stream is taken over by inline 
and the next few packets ( a small random number ) are acked while a 
reset is sent to the target immediately. The acked pkts can be silently 
dropped and never sent to the target. After a few acks the reset is sent 
to the attacker and the entire tracker flushed. This would help prevent 
easy identification of the inline device since predictability on a 
specific pattern or packet would not produce an observable repeating result.

> 
> Also, reject only works in nat mode (i.e. when the inline device has an
> interface with an ip address).  Why?  Because I have not gotten off my
> lazy butt to change the way libnet launches the packets.  It does not know
> how to send them out if the interface is not up.

Easy enough to solve, require a response port to run in this mode. Use a 
rule to drop any inbound pkts to the interface and set it as the default 
route for external networks. Use net routes on the management interface 
for local networks...

> 
> Just out of curiosity, would the list see the stream reassembly being used
> for certain ports or for all ports?  Wondering if it would be worth while
> to generate an inline stream reassembler..

I do not see any value in an inline device that does not reassemble all 
tcp traffic, for optimization purposes it could be tied to ports that 
have rules for them however one tcp any any style rule would mean 
reassemble everything.

> 
> Thanks in advance,
> 
> Rob
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
>