Re: [Snort-inline-users] stream4inline and enforce_state

[Rob C. <rca...@pc...>]

Ok, I added that rule and regenerated the files.  Here they are again 
after running with both iptables rules.  It didn't make any difference 
in the outcome, I am still not able to establish any TCP connections. 
That makes sense though, since it also didn't work when all packets were 
going to the queue.

Rob Campbell
Pacific Coast Wireless Internet

Victor Julien wrote:
> Rob Campbell wrote:
>> I have tcpdumps from both interfaces on the bridge.  I also was able 
>> to turn on debugging and I am seeing "Lets drop this its not a synner".
>>
>> I am attaching that output and the 2 tcpdump files.  eth2 is the 
>> external interface and eth3 is the internal interface.  To keep the 
>> logs and packet dumps clean, I used a different iptables rule for only 
>> port 80 traffic.  I get the same results with "iptables -A FORWARD -j 
>> QUEUE", it's just a lot more noisy.  The rule I was using this time 
>> was "iptables -A FORWARD -p tcp --dport 80 -j QUEUE".  The output from 
>> iptables -vnL is also attached.
> 
> This iptables rule is not sufficient. You now only send packets with 
> destination port 80 to the QUEUE, but the return packets, which have 
> source port 80 are accepted by iptables using ACCEPT and thus not send 
> to snort_inline. Please add the following rule in addition to the one 
> you already have:
> iptables -A FORWARD -p tcp --sport 80 -j QUEUE
> 
> This will make sure the return traffic is also send to the QUEUE.
> 
> Regards,
> Victor
> 
> 
> 
>> Rob Campbell
>> Pacific Coast Wireless Internet
>>
>> Will Metcalf wrote:
>>
>>> hmmmm can you send my packet dumps and possibly ./configure with
>>> --enable-debug.  Then export SNORT_DEBUG=8192 if enforce_state is
>>> dropping your packets you should see something in the debug to the
>>> effect of "dropping packet not a synner".  Let me know what you find,
>>> as long as stream4 can see the TWH enforce_state shouldn't be causing
>>> you any problems.
>>>
>>> Regards,
>>>
>>> Will
>>>
>>> On 11/29/05, Rob Campbell <rca...@pc...> wrote:
>>>
>>>> Will,
>>>>
>>>> I'm just checking back to see if you have found anything.  I have 
>>>> done a
>>>> little more testing, but haven't found a way to fix it yet.  It is
>>>> definitely related to enforce_state.  If I use enforce_state, even
>>>> without stream4inline, it will not pass any TCP traffic.  From what I
>>>> understand, without enforce_state I cannot drop TCP packets in
>>>> real-time, is that correct?  I would really like to use Snort for an
>>>> IPS, but without TCP it wouldn't be very useful.  Let me know if you
>>>> have any other ideas, or want me to give something a try.  Thank you.
>>>>
>>>> Rob Campbell
>>>> Pacific Coast Wireless Internet
>>>>
>>>> Will Metcalf wrote:
>>>>
>>>>> I'll see if I can reproduce it this weekend
>>>>>
>>>>> On 11/18/05, Rob Campbell <rca...@pc...> wrote:
>>>>>
>>>>>> I have also tried it with just "iptables -A FORWARD -j QUEUE" to make
>>>>>> sure that the specified interfaces wasn't causing a problem.  Any 
>>>>>> ideas
>>>>>> why it's not working with stream4inline and enforce_state?
>>>>>>
>>>>>> Rob Campbell
>>>>>> Pacific Coast Wireless Internet
>>>>>>
>>>>>> Rob Campbell wrote:
>>>>>>
>>>>>>> No.  That is the only iptables rule I have.  The full rule was 
>>>>>>> "iptables
>>>>>>> -A FORWARD -i br0 -o br0 -j QUEUE", could that cause any problems?
>>>>>>>
>>>>>>> Rob Campbell
>>>>>>> Pacific Coast Wireless Internet
>>>>>>>
>>>>>>> Will Metcalf wrote:
>>>>>>>
>>>>>>>> hmmm how odd, you don't have any other entries in your FORWARD 
>>>>>>>> chain
>>>>>>>> before you -A FORWARD -j QUEUE entry do you?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Will
>>>>>>>>
>>>>>>>> On 11/17/05, Rob Campbell <rca...@pc...> wrote:
>>>>>>>>
>>>>>>>>> It is happening on web traffic, IMAP traffic, and telnet to 
>>>>>>>>> various
>>>>>>>>> ports.
>>>>>>>>>
>>>>>>>>> Rob Campbell
>>>>>>>>> Pacific Coast Wireless Internet
>>>>>>>>>
>>>>>>>>> Will Metcalf wrote:
>>>>>>>>>
>>>>>>>>>> sorry it's late missed the "iptables -A FORWARD -j QUEUE" 
>>>>>>>>>> part.  Just
>>>>>>>>>> out of curiosity is it a particular protocol, or does all tcp 
>>>>>>>>>> traffic
>>>>>>>>>> get dropped?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Will
>>>>>>>>>>
>>>>>>>>>> On 11/16/05, Will Metcalf <wil...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hmmm Are you sure that snort-inline can see the full twh?  
>>>>>>>>>>> i.e. are
>>>>>>>>>>> you queueing both client and server traffic?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Will
>>>>>>>>>>>
>>>>>>>>>>> On 11/16/05, Rob Campbell <rca...@pc...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I have been configuring an IPS using snort inline.  I am 
>>>>>>>>>>>> running the
>>>>>>>>>>>> latest version, 2.4.3RC2.  It is running in bridge mode with
>>>>>>>>>>>> "iptables
>>>>>>>>>>>> -A FORWARD -j QUEUE" on the bridge interface.  When I have
>>>>>>>>>>>> enforce_state
>>>>>>>>>>>> on, it seems to block all TCP traffic. With a packet capture 
>>>>>>>>>>>> I do see
>>>>>>>>>>>> the SYN being sent to the remote host, but I never get any
>>>>>>>>>>>> replies.  If
>>>>>>>>>>>> I turn off enforce_state it starts working again.
>>>>>>>>>>>>
>>>>>>>>>>>> What are the downsides to turning off enforce_state or 
>>>>>>>>>>>> stream4inline?
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>
>>>>>>>>>>>> Rob Campbell
>>>>>>>>>>>> Pacific Coast Wireless Internet
>>>>>>>>>>>>