Project

General

Profile

Support #2135

Suricata IPS Inline on a bridge not working

Added by Fuad Kamal almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Hi,
I have installed Suricata 3 on Ubuntu 16.04
I followed the instructions in :
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Setting_up_IPSinline_for_Linux
also, same instructions in :
https://taosecurity.blogspot.com.eg/2014/01/suricata-20beta2-lsb_release -aas-ips-on-ubuntu-1204.html

Bridge is working fine.
I tested both scenarios, Host, and forward_ing as per first link.

- Host Scenario, both alert and drop work fine on the Bridge machine.
I use :
sudo iptables -A INPUT -j NFQUEUE
sudo iptables -A OUTPUT -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml.1 -q 0
and ymal file has nfq as accept

forward_ing scenario, alert works from remote PC, but drop does not. That means that bridge and NFQUEUE are both working fine.
I use :
sudo iptables -I FORWARD -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml.1 -q 0
and ymal file has nfq as accept

If I run suricata as below, I get [wdrop] in forward_ing mode :
sudo iptables -A OUTPUT -j NFQUEUE -o bridge0

I can not find why packets are not dropped in forward_ing scenario using NFQ, while alert is working fine.
Attached is the yaml configuration file I use.

Regards,
Fuad


Files

suricata.yaml.1 (60.9 KB) suricata.yaml.1 Fuad Kamal, 06/07/2017 03:18 PM

History

#1

Updated by Andreas Herz almost 2 years ago

  • Assignee set to Matt Jonkman
  • Target version set to Support

the taosecurity link is not working. And the first question is, in your test.rules did you convert the action of the rules from alert to drop?

#2

Updated by Andreas Herz almost 2 years ago

  • Assignee changed from Matt Jonkman to OISF Dev
#3

Updated by Victor Julien almost 2 years ago

  • Status changed from New to Closed

Sadly bridge+nfqueue has never worked well. If you need a brige I'd advice you to look at afpacket in bridge mode.

We are talking to the netfilter project about ways to improve things, but for now don't mix bridge and nfqueue.

#4

Updated by Felipe Houde almost 2 years ago

nfq:
mode: accept
repeat-mark: 1
repeat-mask: 1

Shouldnt you use mode: repeat with the repeat mark/masq options ?

F.

#5

Updated by Felipe Houde almost 2 years ago

with some iptables rules like this:

iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j NFQUEUE

iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j LOG --log-level 3 --log-tcp-options --log-ip-options --log-tcp-sequence --log-prefix "[UNMARKED:DROP]"
iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j DROP

iptables -A FORWARD -m physdev --physdev-is-bridged -m mark --mark 0x1/0x1 -j ACCEPT

#6

Updated by Felipe Houde almost 2 years ago

ebtables -t broute -A BROUTING -p 0x0800 -j ACCEPT
ebtables -t broute -A BROUTING ! -p 0x0800 -j ACCEPT

ebtables -A INPUT -j DROP
ebtables -A FORWARD -p 0x0800 -j ACCEPT
ebtables -A FORWARD -p 0x0806 -j ACCEPT
ebtables -A OUTPUT -j DROP

iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j NFQUEUE
iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j LOG --log-level 3 --log-tcp-options --log-ip-options --log-tcp-sequence --log-prefix "[UNMARKED:DROP]"
iptables -A FORWARD -m mark ! --mark 0x1/0x1 -j DROP
iptables -A FORWARD -m physdev --physdev-is-bridged -m mark --mark 0x1/0x1 -j ACCEPT

net.ipv4.ip_forward=0
net.bridge.bridge-nf-call-arptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-filter-pppoe-tagged=1
net.bridge.bridge-nf-filter-vlan-tagged=1
net.bridge.bridge-nf-pass-vlan-input-dev=1

nfq:
mode: repeat
repeat-mark: 1
repeat-mask: 1

Also available in: Atom PDF