Hi,
I'm not sure I fully understand how the NFQUEUE action works within
the rules file.
If a packet enters NFQUEUE and is NOT rejected/dropped by an external
application (eg. Suricata IPS in my case), shouldn't the rest of the
rules file actions be applied?
Roughly, here's my SW configuration.
My default policy for dmz to lan zones is DROP.
My rules file contains:
[...]
?SHELL echo "$IPS_RULES_WAN"
# the following DROP action is for testing only
DROP dmz:192.168.212.64 lan
[...]
My params file generates:
NFQUEUE(0:5,bypass)
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
lan,fw udp 137,138,139 -
NFQUEUE(0:5,bypass) lan,fw
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
udp - 137,138,139
NFQUEUE(0:5,bypass)
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
lan,fw icmp
NFQUEUE(0:5,bypass) lan,fw
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
icmp
NFQUEUE(0:5,bypass)
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
lan,fw tcp 21,25,80,443,3389,12795 -
NFQUEUE(0:5,bypass) lan,fw
dmz,evpn,ivpn,hvpn,ovpn,vpn1,vpn2:!+CORP_IPS_BL,+CORP_POL_BL,+CORP_GLOBAL_WL
tcp - 21,25,80,443,3389,12795
BTW I also tried to remove ",bypass" from the NFQUEUE actions above
but it doesn't change the issue I'm reporting.
I also tried replacing the SHELL line with the NFQUEUE lines (just in
case), but the result was identical.
So, with the above rules in place I'm expecting that the host in "dmz"
zone with IP address 192.168.212.64 will NOT be able to either ping or
access port 80 on any service within the "lan" zone (see shorewall
dump below).
I'm expecting Shorewall to DROP everything coming from that host.
However, this does not happen. The dmz host has full ICMP and HTTP
access (port 80) to any host within the lan zone.
Note that if I comment out the line in the rules file:
#?SHELL echo "$IPS_RULES_WAN"
then traffic from that dmz host is DROPped.
I can also comment out all the NFQUEUE lines and only leave the
"NFQUEUE * icmp" line active. In this case, only ICMP traffic is
allowed, but the rest is DROPped.
So it's as if the rules after the NFQUEUE actions were not applied to
this host for the port it tries to access at a given point.
Also, I cannot place the NFQUEUE calls at the bottom of the rules file
so they can be applied last because I need my IPS to detect possible
threats first for (say) web traffic, and if the packet is not DROPped
within NFQUEUE then go on and ACCEPT traffic to specific HTTP servers
in the lan zone.
The SW dump contains this:
Chain dmz-lan (1 references)
pkts bytes target prot opt in out source destination
0 0 dbl_log all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED match-set
CORP_POL_BL src
88 8301 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
28093 38M tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
28051 38M ~comb11 all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate ESTABLISHED
0 0 ~comb3 all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED
0 0 ~excl0 udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 137,138,139
1 60 ~excl0 icmp -- * * 0.0.0.0/0 0.0.0.0/0
1 52 ~excl0 tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 21,25,80,443,3389,12795
0 0 DROP all -- * * 192.168.212.64 0.0.0.0/0
[...]
Chain ~excl0 (48 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 match-set CORP_IPS_BL src
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 match-set CORP_POL_BL src
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 match-set CORP_GLOBAL_WL src
555 124K NFQUEUE all -- * * 0.0.0.0/0
0.0.0.0/0 NFQUEUE balance 0:5 bypass
Here's the full SW dump while trying to ping lan host with IP address
10.215.l44.7 from dmz host with IP address 192.168.212.64:
https://drive.google.com/open?id=1mbgoIUZBLmvnk8wyG8c-GufQ_E7VFMSZ
Personally, I'm using Suricata in IPS mode.
The docs state the following:
# When running in NFQ inline mode, it is possible to use a simulated
# non-terminal NFQUEUE verdict.
# This permit to do send all needed packet to suricata via this a rule:
# iptables -I FORWARD -m mark ! --mark $MARK/$MASK -j NFQUEUE
# And below, you can have your standard filtering ruleset. To activate
# this mode, you need to set mode to 'repeat'
# If you want packet to be sent to another queue after an ACCEPT decision
# set mode to 'route' and set next-queue value.
# On linux >= 3.1, you can set batchcount to a value > 1 to improve performance
# by processing several packets before sending a verdict (worker runmode only).
# On linux >= 3.6, you can set the fail-open option to yes to have the kernel
# accept the packet if suricata is not able to keep pace.
# bypass mark and mask can be used to implement NFQ bypass. If bypass mark is
# set then the NFQ bypass is activated. Suricata will set the bypass mark/mask
# on packet of a flow that need to be bypassed. The Nefilter ruleset has to
# directly accept all packets of a flow once a packet has been marked.
nfq:
# mode: accept
# repeat-mark: 1
# repeat-mask: 1
# bypass-mark: 1
# bypass-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
Not sure what happens if I set:
nfq:
mode: repeat
so I set "nfq.mode = repeat" just for kicks, but my issue is still the same.
I also read this elsewhere:
"
In REPEAT mode, Suricata generates a non-terminal verdict and marks
the packets that will be reinjected again at the first rule of
iptables. Add the following rule to iptables:
iptables -I FORWARD -m mark ! --mark $MARK/$MASK -j NFQUEUE
"
I'm guessing that if I set this in Suricata:
nfq:
mode: repeat
repeat-mark: 10
(and I'm not using mark 10 anywhere in Shorewall) then the packets
should be reinjected again and not go through NFQUEUE. So in this
case, maybe the rules after my NFQUEUE calls will get applied.
However, I don't think Shorewall includes "-m mark ! --mark
$MARK/$MASK" for the NFQUEUE code.
What can I try?
Am I wrongly using the NFQUEUE action within the rules file?
Thanks,
Vieri
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
