[Oisf-users] nfq_set_mark question

[Eric Leblond]

Hello,

Le mercredi 11 juillet 2012 à 18:29 +0400, kay a écrit :
> Dear Eric,
> 
> 1)
> Here is the part of source-nfq.c:
> 
> ... ... ...
>     do {
>         switch (nfq_config.mode) {
>             default:
>             case NFQ_ACCEPT_MODE:
>             case NFQ_ROUTE_MODE:
>                 if (p->flags & PKT_MARK_MODIFIED) {
> #ifdef HAVE_NFQ_SET_VERDICT2
> ... ... ...
> 
> You can see that NFQ_ACCEPT_MODE doesn't do anything, that is why I am
> confused. Maybe I'm a dummy but I could not find the code where packet
> is being marked by rule in accept mode.

You misread the construction. I'm using here a common method which is
using the fact that if the case match it will start the code at this
point and execute the code of the following case (you need a break to
get out of the switch).

> 
> 2) Finally I figured out my mistake. My iptables counter rule was:
> 
> -A INPUT -m mark --mark 0x80/0x80 -j ACCEPT
> 
> but should be:
> 
> -A INPUT -m mark --mark 0x80/0x80
> 
> 3) My dreams come false. But to be sure I'll ask you once again, is
> there any possibility to redirect marked traffic to honeypot in
> realtime?

No, it just can't work. One solution could be to have suricata drop the
malicious packet and trigger an alert. Then via a external tool you
parse the alert and add the IP to a list of address which is nat. You
can use ipset for instance.

BR,
> 
> 2012/7/11 Eric Leblond <eric at regit.org>:
> > Hello,
> >
> > Le mercredi 11 juillet 2012 à 17:21 +0400, kay a écrit :
> >> Dear Eric,
> >>
> >> Don't apologize for the late answer, its ok. I have broken my mind
> >> several times, but got new skills =)
> >>
> >> Thank you very much, it works now. But I have questions:
> >>
> >> 1) I can not understand why you commented out the following strings:
> >> > #  mode: accept
> >> > #  repeat_mark: 1
> >> > #  repeat_mask: 1
> >> > #  route_queue: 2
> >>
> >> I reviewed suricata sources and noticed that "nfq_set_verdict2" is
> >> being used only with NFQ_ROUTE_MODE or NFQ_REPEAT_MODE cases
> >> (source-nfq.c). How does it work in ACCEPT mode?
> >
> > nfq_set_verdict2 is only used if we need to do advanced stuff on the
> > packet. The idea behind not using it in all case was to avoid adding
> > backward compatiblity code for people not having the v2.
> >
> >> 2) What is the sense and reason to use "repeat" mode and
> >> repeat_mark/repeat_mask options if the marking functions in the
> >> "accept mode" only and the marking can be implemented via rules?
> >
> > As said in my previous mail, I gave you AN answer to your question.
> > Marking work for repeat mode:
> >
> > -A INPUT -p tcp -m tcp --dport 80 -m mark ! --mark 0x1/0x1 -j NFQUEUE --queue-num 0 --queue-bypass
> > -A INPUT -m mark --mark 0x80/0x80
> > -A INPUT -m mark --mark 0x1/0x1
> > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> >
> > with a suricata.yaml modified:
> >
> > nfq:
> >   mode: repeat
> >   repeat_mark: 1
> >   repeat_mask: 1
> >
> >> 3) Why I can't catch marked packed in "nat" table but can catch in
> >> "mangle" table?
> >
> > Please reread my initial mail:
> > http://lists.openinfosecfoundation.org/pipermail/oisf-users/2012-July/001799.html
> >
> > It explains that nat table is only used for the packet which do not
> > belong to an established connection. Thus you can't see the packet with
> > content.
> >
> > BR,
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users

-- 
Eric Leblond 
Blog: http://home.regit.org/ - Portfolio: http://regit.500px.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120711/d29b62e4/attachment-0001.pgp>