[Oisf-users] Questions on suricata configuration

[unite]

Andreas,

I have checked it one more time. Both in daemon/non-daemon mode the 
packet gets passed to the second iptables rule. To be honest, the 
behaviour I observe satisfies me :) I'm just a bit worried that it could 
be a symptom of something going wrong...


On 2015-01-20 17:21, Andreas Herz wrote:
> On 20/01/15 at 17:05, unite wrote:
>> On 2015-01-20 16:30, Andreas Herz wrote:
>> >On 20/01/15 at 16:22, unite wrote:
>> >>b) If my iptables rules are like this and the rule is set to "alert":
>> >>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>> >> pkts bytes target     prot opt in     out     source
>> >>destination
>> >>    1     84 NFQUEUE    all  --  *      *       172.25.25.0/24
>> >>0.0.0.0/0            NFQUEUE num 0
>> >>    1     84 DROP       icmp --  *      *       0.0.0.0/0
>> >>0.0.0.0/0
>> >>The alert is generated (in fast.log, drop.log is empty)and packet is
>> >>being
>> >>dropped. I'm pretty sure that it is the same packet - counters for
>> >>packets/bytes increment simultaneously and on same values, and also my
>> >>testing host is the only one in the testing network - no one can
>> >>generate it
>> >>except me.
>> >
>> >That's strange, how do you start suricata in inline mode exactly?
>> >(arguments)
>> >I will check on my setup if i can reproduce it.
>> >
>> 
>> I start it in the way:
>> 
>> sudo suricata -c /etc/suricata/suricata.yaml -q 0 -D
> 
> Hmm can you try it without -D to see if it's the daemon mode?
> There was some difference, not sure if it was this one :)
> 
> I checked it with my setup (without -D) and couldn't get anything.
> I did:
> 
> iptables -A IDS -j LOG --log-prefix="IDSTEST: "
> 
> But no packet got there, all got into the NFQEUE (which is before) and
> never came back.
> 
>> >>My config at the moment is not far away from default - so here is the
>> >>diff
>> >>between them:
>> >>sudo diff suricata-2.0.5/suricata.yaml /etc/suricata/suricata.yaml
>> >
>> >I would encourage you to update to 2.0.6, there is a relevant bugfix.
>> >
>> >I guess (to lazy to check) the enabled lines are the ones for logging?!
>> 
>> Yes, enabled yes/no lines are used for logging.
>> 
> 
> Then nothing should be wrong with this.
> 
>> >
>> >I'm not sure how the profile option changes the behaviour but the rest
>> >looks fine.
>> 
>> As I've read in the guide, it should increase performance in cost of
>> increased memory usage.
> 
> Just something you need to play around with.

-- 
With kind regards,
Alex