[Oisf-users] Packet drop nfq repeat

[Aleksey]

On 2015-05-19 10:33, Victor Julien wrote:
> On 05/13/2015 11:03 AM, Aleksey wrote:
>> Hi guys!
>> 
>> I'm using Suricata 2.0.8 in NFQ mode. I have quite an ancient machine 
>> on
>> which my testing instance of suricata is running. I've noticed the
>> following thing - if I use nfq accept mode, when I stop suricata,
>> counters show that all packets where accepted:
>> 
>> 13/5/2015 -- 11:30:32 - <Notice> - (Recv-Q0) Treated: Pkts 50, Bytes
>> 18634, Errors 0
>> 13/5/2015 -- 11:30:32 - <Notice> - (Recv-Q0) Verdict: Accepted 50,
>> Dropped 0, Replaced 0
>> 
>> When in turn I use repeat mode, I can notice quite high drops:
>> 
>> 13/5/2015 -- 11:37:37 - <Notice> - (Recv-Q0) Treated: Pkts 219, Bytes
>> 47586, Errors 0
>> 13/5/2015 -- 11:37:37 - <Notice> - (Recv-Q0) Verdict: Accepted 172,
>> Dropped 47, Replaced 0
>> 
>> These are not blocked packets - drop.log is empty and there is nothing
> 
> I think they are actually. This 'Dropped' counter is about the verdict,
> so it's really blocked packets.
> 
> The drop.log doesn't log all packets, it may be a little bit too
> conservative at that.
> 
> I suspect it's the stream engine that blocks packets that seem 'wrong'
> while doing stream tracking and reassembly.
> 
> 
>> to block there - I just connect to the testing website with my 
>> browser,
>> no rules are set to "drop", mostly "alert". CPU usage on suricata box
>> doen't exceed 10-20% (all processes) and suricata process doesn't 
>> exceed
>> 5% during my tests. Probably, I've configured something wrong? Also if 
>> I
>> set nfq fail-open to "true" counters show that all packets are 
>> accepted.
>> 
>> My nfq config is:
>> nfq:
>>   mode: repeat
>>   repeat-mark: 1
>>   repeat-mask: 1
>> 
>> Iptables rule is also quite simple:
>> 
>> iptables -A FORWARD -d 192.168.55.200 -m mark ! --mark 1 -j NFQUEUE
>> --queue-num 0 --queue-bypass
>> 
>> Any ideas?
> 
> Queue bypass means nfqueue passes packets if Suricata is overloaded. If
> Suricata doesn't see them, it messes up stream reassembly. Suricata may
> drop packets it considers 'bad' when doing stream reassembly.
> 
> You could try removing the queue-bypass option.


Hi Victor!

I knew the meaning of queue-bypass so I actually configured it so for 
the reason if something happens to suricata (if someone kills it by an 
accident or so on) traffic could still normally flow. As i've said, the 
CPU load was actually very low during my tests. So i guess it is not 
caused by suricata being overloaded - I guess if it was so, the packets 
could still be dropped in "accept" mode. Also I've used emerging threats 
open rulesets without any "drop" rule, so as I understand, packets 
couldn't get dropped by signatures (and as I understand they would been 
dropped in "accept" mode too not only in "repeat").

Am I mistaken somewhere? Can't it be some configuration issue? I can 
provide certain parts of suricata.yaml or the whole file if needed.

Still, I'll test one more time without queue-bypass tomorrow and get 
back with results.

Thanks for your help.
-- 
With kind regards,
Aleksey