From: Pieter C. <pie...@co...> - 2004-05-14 09:28:48
|
>From a commercial point of view, getting stream4 to alert properly in inline mode is already a good step forward. It stores the packet and loops it through StoreStreamPkt waiting for an ack from our server that "should" never answer. This would not be a problem if we could some how set an infinite PRUNE_QUANTA and STREAM4_TTL_LIMIT on packets that generated an alert. If this were possible we could just wait for the RST from the server in which case the session would be deleted from Stream4 Is it not possible to spoof the ack packet at the same time the drop is called? For some reason, even alerting when using snort with the -Q option doesn't work properly. Is stream4 really worth all of the effort. Is there anything else you guy's want would rather see working in snort_inline? > I think so. If you install fragroute and run it with the tcp segmentation option, then you can completely circumvent the inline device by breaking any attack into small tcp segments. Not that commercially feasible because things go real slow, but doable. I have not seen automated tools do this yet? Pieter On Fri, 2004-05-14 at 08:57, William Metcalf wrote: > Alright so here is what I have found so far regarding snort_inline and > the stream4 preprocessor. From what I can tell when an alert is > detected in traffic being reassembled in stream4. InlineDrop(); Is > called and the packet is properly dropped. I believe the problem is in > the way that Stream4 handles an un-acked packet, It stores the packet > and loops it through StoreStreamPkt waiting for an ack from our server > that "should" never answer. This would not be a problem if we could > some how set an infinite PRUNE_QUANTA and STREAM4_TTL_LIMIT on packets > that generated an alert. If this were possible we could just wait for > the RST from the server in which case the session would be deleted > from Stream4. Otherwise we hit our TTL and PRUNE limits and the stream > gets dropped from stream4 prematurely. I changed these values globally > in my spp_stream4.c file, and everything I have been throwing at > snort_inline seems to get dropped correctly. The only thing I'm > worried about is that on a busy network we would hit our memory limit > for Stream4 and start pruning sessions because of it. The default is > 8mb, If you up these values I would also suggest that up the amount of > memory you are using for stream4. This method kind of stinks, Does > anybody have a better Idea of how to do this without completely > rewriting stream4? Is stream4 really worth all of the effort. Is there > anything else you guy's want would rather see working in snort_inline? > > Regards, > > Will -- Pieter Claassen <pie...@co...> |