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

[Rob M. <ro...@ho...>]

> Alright, I think that I have found a pseudo work-around for this issue, and
> anybody is welcome to shoot holes in it if they wish.  If we set all of the
> rules to reject rather than drop, the packet is tracked correctly through
> the stream as it should be.  If we send out RST's due to an alert there is
> no retransmission from the client i.e. no Re-transmissions to continue to
> track and eventually prune due to pruning time-out.  Unlike normal flexresp
> which just listens on the network and sends resets if it see's nasty
> packets, Rob or Jed coded InlineReject() to drop the packet just like
> InlineDrop() and then send the reset.  I'm wondering why we don't make this
> default behavior of snort_inline, snort_inline wouldn't have to process the
> same packet over and over again i.e. no multiple alerts on the same packet.

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?

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.

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..

Thanks in advance,

Rob