[Oisf-users] Suricata IPS using iptables with NFQUEUE and nfq_set_mark questions
Stanford Prescott
stan.prescott at gmail.com
Tue May 23 22:21:59 UTC 2017
Thanks, Eric. The use of mangle and PREROUTING is an attempt to only send
traffic from the internal LAN interfaces to NFQUEUE for Suricata to
inspect. I am hoping that will leave me with the ability to keep our
current configuration of Snort listening on the WAN interface in IPS mode.
It's definitely a learning experience for me.
I do remember reading about the save mark and restore mark. I will need to
go back and add that.
On Tue, May 23, 2017 at 5:10 PM, Eric Leblond <eric at regit.org> wrote:
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170523/3733eee0/attachment-0002.html>
More information about the Oisf-users
mailing list