[Oisf-users] Suricata IPS using iptables with NFQUEUE and nfq_set_mark questions
Eric Leblond
eric at regit.org
Tue May 23 22:10:00 UTC 2017
Hi Standord,
On Tue, 2017-05-23 at 17:01 -0500, Stanford Prescott wrote:
> Thanks, David. I was coming from using Snort and running multiple
> instances of Snort, one on each firewall interface, to listen to
> traffic on each one. So, I was thinking I had to approach Suricata
> the same way, but it is now apparent to me that Suricata in IPS mode
> functions differently from Snort.
>
> We are working on using Suricata in IPS nfq mode to listen on the
> firewall's internal LAN interfaces. We already use Snort in a "type"
> of IPS mode which involves moving offending IP addresses into an IP
> block chain in iptables. However, it only works on the WAN interface.
> We want to expand the abilities to be able to also listen on the
> internal LAN interfaces, especially for outgoing traffic coming from
> internal network devices. Our current setup for a type of snort IPS
> on the WAN doesn't translate to the internal networks at all, so
> Suricata appears to be a good solution to monitoring the internal
> interfaces.
>
> I have tried these iptables rules
>
> iptables -t mangle -N jumpToSuricata
> iptables -t mangle -A jumpToSuricata -m mark ! --mark 1/0x01 -j
> NFQUEUE --queue-num 0
The basic concept of NFQ in repeat mode is to be able to use Suricata
on the FORWARD chain (in combination with the existing iptables
"firewall" ruleset) so it is rather strange to see you use NFQUEUE
repeat mode in PREROUTING. Also sniffing in FORWARD will allow you to
get all packets at a moment where NAT transformation do not hide you
something of the reality of the traffic.
> # source inc.bits-flags to get definitions (assuming this is a shell
> script)
> . /etc/rc.d/inc.bits-flags
>
> # Internal conns
> iptables -t mangle -I PREROUTING 1 -m connmark --mark
> $typeInternal/$connTypeMask -j jumpToSuricata
> # Internal-to-smoothie conns
> iptables -t mangle -I PREROUTING 1 -m connmark --mark
> $typeInt2FW/$connTypeMask -j jumpToSuricata
> # smoothie-to-internal conns
> iptables -t mangle -I PREROUTING 1 -m connmark --mark
> $typeFW2Int/$connTypeMask -j jumpToSuricata
Here you do not seem to restore the mark so I doubt this will work.
BR,
--
Eric
>
> and starting suricata with suricata -c /etc/suricata/suricata.yaml -q
> 0 -vv -D
> and suricata starts without any errors in the suricata.log file.
>
> Now, I need to determine if it is doing what I am expecting it to do.
>
> On Tue, May 23, 2017 at 1:00 AM, David Sussens <dsussens at gmail.com>
> wrote:
> > Stan,
> >
> > You need to run suricata as follows:
> >
> > suricata -c /etc/suricata/suricata.yaml -q 0 -q 1 -q 2 -q3
> >
> > This is for a four queue setup. The multiple run modes error is
> > related to the "-i" which tries to run Suricata in af-packet/pfring
> > mode instead of nfq mode.
> >
> > The relevant interface is them determine by which chain the packets
> > encounter as they enter the firewall. It is important to
> > understand exactly how packets traverse the chains in order to make
> > this work.
> >
> > If packets are being forwarded through the box, then the forward
> > chain is used and the nfqueue rule needs to be there.
> > If the packets are destined for a service listening locally on the
> > box, then the input chain will be encounter.
> > Ff the packets are originating from the box, then the output chain
> > is used.
> >
> > In a situation where you have a local proxy running that accepts
> > and then proxies traffic onward, then the input and output chains
> > are relevant.
> >
> > This may all seem fairly self explanatory, but I have found that
> > many issues are caused by a lack of understanding of how iptable
> > chains interact with packets.
> >
> > David Sussens.
> >
> > On Tue, May 23, 2017 at 3:45 AM, Stanford Prescott <stan.prescott at g
> > mail.com> wrote:
> > > When I add this rule
> > > iptables -A INPUT -m mark ! --mark 1/1 -j NFQUEUE
> > >
> > > suricata.yaml with
> > > nfq:
> > > mode: repeat
> > > repeat-mark: 1
> > > repeat-mask: 1
> > > # route-queue: 2
> > > batchcount: 20
> > > fail-open: no
> > >
> > > when I try to start Suricata
> > > suricata -c /etc/suricata/suricata.yaml -i eth0 -vv -D -q 0
> > >
> > > I get an error stating that "more than one run mode has been
> > > specified..."
> > >
> > > I can't see any other run modes I have set in suricata.yaml other
> > > than "mode: repeat" but I am not sure what I am looking for.
> > >
> > >
> > > On Mon, May 22, 2017 at 1:46 PM, Dominic Ruggiero <dominic1011 at gm
> > > ail.com> wrote:
> > > > Thanks to all who have been participating in the recent threads
> > > > about
> > > > Suricata Repeat Mode for your expertise!
> > > >
> > > > Suricata is now running on my hosts in Repeat Mode with no
> > > > packet
> > > > errors in suricata.log.
> > > >
> > > > - LXTerminal commands:
> > > >
> > > > sudo iptables -I INPUT -m mark ! --mark 1/1 -j NFQUEUE
> > > > sudo iptables -I OUTPUT -m mark ! --mark 1/1 -j NFQUEUE
> > > > sudo suricata -c /etc/suricata/suricata.yaml -q 0
> > > >
> > > > - Relevant suricata.log output (note the Errors 0!):
> > > >
> > > > (RX-Q0) Treated: Pkts 33144, Bytes 13638158, Errors 0
> > > > (RX-Q0) Verdict: Accepted 33133, Dropped 10, Replaced 0
> > > >
> > > > - sudo iptables -vnL --line-numbers:
> > > >
> > > > Chain INPUT (policy DROP 0 packets, 0 bytes)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 2980 1405K NFQUEUE all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 0
> > > > 2 4344 1516K ufw-before-logging-input all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 3 4344 1516K ufw-before-input all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 4 0 0 ufw-after-input all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 5 0 0 ufw-after-logging-input all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 6 0 0 ufw-reject-input all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 7 0 0 ufw-track-input all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain FORWARD (policy DROP 0 packets, 0 bytes)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 ufw-before-logging-forward all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 2 0 0 ufw-before-forward all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 3 0 0 ufw-after-forward all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 4 0 0 ufw-after-logging-forward all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 5 0 0 ufw-reject-forward all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 6 0 0 ufw-track-forward all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain OUTPUT (policy ACCEPT 5 packets, 200 bytes)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 2895 806K NFQUEUE all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 0
> > > > 2 3909 887K ufw-before-logging-output all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 3 3909 887K ufw-before-output all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 4 97 8448 ufw-after-output all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 5 97 8448 ufw-after-logging-output all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0
> > > > 6 97 8448 ufw-reject-output all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 7 97 8448 ufw-track-output all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-after-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-after-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 ufw-skip-to-policy-input udp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 udp dpt:137
> > > > 2 0 0 ufw-skip-to-policy-input udp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 udp dpt:138
> > > > 3 0 0 ufw-skip-to-policy-input tcp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
> > > > 4 0 0 ufw-skip-to-policy-input tcp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
> > > > 5 0 0 ufw-skip-to-policy-input udp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 udp dpt:67
> > > > 6 0 0 ufw-skip-to-policy-input udp -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 udp dpt:68
> > > > 7 0 0 ufw-skip-to-policy-input all -- * *
> > > > 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-
> > > > type
> > > > BROADCAST
> > > >
> > > > Chain ufw-after-logging-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 LOG all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0
> > > > level 4
> > > > prefix "[UFW BLOCK] "
> > > >
> > > > Chain ufw-after-logging-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 LOG all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0
> > > > level 4
> > > > prefix "[UFW BLOCK] "
> > > >
> > > > Chain ufw-after-logging-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-after-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-before-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 ACCEPT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate RELATED,ESTABLISHED
> > > > 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 3
> > > > 3 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 4
> > > > 4 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 11
> > > > 5 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 12
> > > > 6 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 8
> > > > 7 0 0 ufw-user-forward all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-before-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 1334 107K ACCEPT all -- lo * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 2 2973 1404K ACCEPT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate RELATED,ESTABLISHED
> > > > 3 0 0 ufw-logging-deny all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate INVALID
> > > > 4 0 0 DROP all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate INVALID
> > > > 5 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 3
> > > > 6 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 4
> > > > 7 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 11
> > > > 8 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 12
> > > > 9 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 icmptype 8
> > > > 10 0 0 ACCEPT udp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 udp spt:67 dpt:68
> > > > 11 37 4877 ufw-not-local all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 12 37 4877 ACCEPT udp -- * * 0.0.0.0/0
> > > > 224.0.0.251 udp dpt:5353
> > > > 13 0 0 ACCEPT udp -- * * 0.0.0.0/0
> > > > 239.255.255.250 udp dpt:1900
> > > > 14 0 0 ufw-user-input all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-before-logging-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-before-logging-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-before-logging-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-before-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 1340 107K ACCEPT all -- * lo 0.0.0.0/0
> > > > 0.0.0.0/0
> > > > 2 2472 771K ACCEPT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate RELATED,ESTABLISHED
> > > > 3 97 8448 ufw-user-output all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-logging-allow (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 LOG all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0
> > > > level 4
> > > > prefix "[UFW ALLOW] "
> > > >
> > > > Chain ufw-logging-deny (2 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 RETURN all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate INVALID limit: avg 3/min burst
> > > > 10
> > > > 2 0 0 LOG all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0
> > > > level 4
> > > > prefix "[UFW BLOCK] "
> > > >
> > > > Chain ufw-not-local (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 RETURN all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
> > > > 2 37 4877 RETURN all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
> > > > 3 0 0 RETURN all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
> > > > 4 0 0 ufw-logging-deny all -- * *
> > > > 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 10
> > > > 5 0 0 DROP all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-reject-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-reject-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-reject-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-skip-to-policy-forward (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 DROP all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-skip-to-policy-input (7 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 DROP all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-skip-to-policy-output (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 ACCEPT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-track-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-track-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-track-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 42 2520 ACCEPT tcp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate NEW
> > > > 2 50 5728 ACCEPT udp -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 ctstate NEW
> > > >
> > > > Chain ufw-user-forward (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-user-input (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-user-limit (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 LOG all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0
> > > > level 4
> > > > prefix "[UFW LIMIT BLOCK] "
> > > > 2 0 0 REJECT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0 reject-with icmp-port-unreachable
> > > >
> > > > Chain ufw-user-limit-accept (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > > 1 0 0 ACCEPT all -- * * 0.0.0.0/0
> > > > 0.0.0.0/0
> > > >
> > > > Chain ufw-user-logging-forward (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-user-logging-input (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-user-logging-output (0 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > > Chain ufw-user-output (1 references)
> > > > num pkts bytes target prot opt in out source
> > > > destination
> > > >
> > > >
> > > > Thanks Again,
> > > >
> > > > Dominic Ruggiero
> > > >
> > > >
> > > >
> > > > On Mon, May 22, 2017 at 10:03 AM, David Sussens <dsussens at gmail
> > > > .com> wrote:
> > > > > Stan, that mechanism is exactly what I have described. This
> > > > feature has been
> > > > > available for quite some time now.
> > > > >
> > > > > Good luck with your implementation.
> > > > >
> > > > > David Sussens.
> > > > >
> > > > > On 22 May 2017 17:14, "Stanford Prescott" <stan.prescott at gmai
> > > > l.com> wrote:
> > > > >>
> > > > >> Thank you, David. That should be very helpful. I think I got
> > > > confused by
> > > > >> the article I read which I am thinking is a new feature that
> > > > has been added
> > > > >> to suricata which appears to be a way of marking traffic
> > > > with different
> > > > >> marks to return to iptables to process depending on what the
> > > > mark is.
> > > > >> Perhaps like both traffic to be accepted and dropped are
> > > > returned to
> > > > >> iptables to be processed depending on what the mark is?
> > > > >>
> > > > >> On Mon, May 22, 2017 at 4:26 AM, David Sussens <dsussens at gma
> > > > il.com> wrote:
> > > > >>>
> > > > >>> Basically what needs to be done is the following:
> > > > >>>
> > > > >>> 1. In iptables:
> > > > >>>
> > > > >>> -A INPUT -m mark ! --mark 1/1 -j NFQUEUE --queue-balance
> > > > 0:3
> > > > >>> --queue-bypass
> > > > >>>
> > > > >>> You add the rule above. This rule works as follows:
> > > > >>>
> > > > >>> Traffic that is does not have a mark/mask of 1/1 is
> > > > forwarded to suricata
> > > > >>> for processing. Once Suricata is finished processing, the
> > > > traffic is
> > > > >>> reinjected into the INPUT chain but this time the mark 1/1
> > > > is set, which
> > > > >>> means on the second round the trafffic is not forwarded to
> > > > suricata and will
> > > > >>> skip on to the rules lower down in the INPUT chain.
> > > > Remember that traffic
> > > > >>> is only reinjected if it was not dropped by Suricata.
> > > > Thus, your marking
> > > > >>> does not have to be specified in the suricata rules at all
> > > > and it is
> > > > >>> business as usual from that prespective.
> > > > >>>
> > > > >>> 2. in suricata.yaml:
> > > > >>>
> > > > >>> nfq:
> > > > >>> mode: repeat
> > > > >>> repeat-mark: 1
> > > > >>> repeat-mask: 1
> > > > >>> route-queue: 2
> > > > >>> batchcount: 20
> > > > >>> fail-open: no
> > > > >>>
> > > > >>> You change the nfq mode from accept to repeat this causes
> > > > packets that
> > > > >>> were not rejected by Suricata to be reinjected into the
> > > > appropriate chain.
> > > > >>>
> > > > >>> This is how I am using it. In my case I am doing this to
> > > > ensure that
> > > > >>> traffic is first checked by Suricata, and then goes to the
> > > > local Apache
> > > > >>> Inverse Proxy.
> > > > >>>
> > > > >>> Hope this helps.
> > > > >>>
> > > > >>> David Sussens.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Sun, May 21, 2017 at 10:04 PM, Stanford Prescott
> > > > >>> <stan.prescott at gmail.com> wrote:
> > > > >>>>
> > > > >>>> I ma trying to integrate Suricata 3.2.1 into our iptables
> > > > firewall in
> > > > >>>> IPS mode. We have have been using Snort in IDS mode but
> > > > wanted to provide
> > > > >>>> more filtering options. I like the possibility of using
> > > > Suricata in IPS mode
> > > > >>>> using nfq in repeat mode to return marked packets to the
> > > > iptables table that
> > > > >>>> sent the packets to Suricata for further processing. Snort
> > > > doesn't seem to
> > > > >>>> do this so we are trying to make the switch to Suricata.
> > > > >>>>
> > > > >>>> I've been doing a lot of research to figure all of this
> > > > out. I have read
> > > > >>>> this excellent article about nfq and nfq_set_mark.
> > > > >>>> https://home.regit.org/tag/suricata/page/4/
> > > > >>>>
> > > > >>>> To use iptables with mark and mask, the article indicates
> > > > that the
> > > > >>>> "nfq_set_mark" keyword needs to be added to the Suricata
> > > > rules. How do I
> > > > >>>> determine to what rules I add the keyword? Would I just
> > > > add the keyword to
> > > > >>>> every rule that Suricata is using as listed in
> > > > suricata.yaml? Or is there a
> > > > >>>> recommended set of rules to add the keyword? Or are there
> > > > rule sets
> > > > >>>> available that already have the keyword added to the
> > > > rules?
> > > > >>>>
> > > > >>>> Is Suricata able to set a mark for packets to be accepted
> > > > and set a
> > > > >>>> different mark for packets that need to be dropped or
> > > > rejected?
> > > > >>>>
> > > > >>>> Any other tips and suggestions for getting Suricata
> > > > working in IPS mode
> > > > >>>> working with iptables would be much appreciated.
> > > > >>>>
> > > > >>>> _______________________________________________
> > > > >>>> Suricata IDS Users mailing list: oisf-users at openinfosecfou
> > > > ndation.org
> > > > >>>> Site: http://suricata-ids.org | Support:
> > > > >>>> http://suricata-ids.org/support/
> > > > >>>> List:
> > > > >>>> https://lists.openinfosecfoundation.org/mailman/listinfo/o
> > > > isf-users
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Suricata IDS Users mailing list: oisf-users at openinfosecfound
> > > > ation.org
> > > > >> Site: http://suricata-ids.org | Support: http://suricata-
> > > > ids.org/support/
> > > > >> List: https://lists.openinfosecfoundation.org/mailman/listin
> > > > fo/oisf-users
> > > > >>
> > > > >
> > > > > _______________________________________________
> > > > > Suricata IDS Users mailing list: oisf-users at openinfosecfounda
> > > > tion.org
> > > > > Site: http://suricata-ids.org | Support: http://suricata-
> > > > ids.org/support/
> > > > > List: https://lists.openinfosecfoundation.org/mailman/listinf
> > > > o/oisf-users
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation
> > > .org
> > > Site: http://suricata-ids.org | Support: http://suricata-
> > > ids.org/support/
> > > List: https://lists.openinfosecfoundation.org/mailman/listinfo/oi
> > > sf-users
> > >
> >
> >
>
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-
> ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-u
> sers
--
Eric Leblond <eric at regit.org>
More information about the Oisf-users
mailing list