Project

General

Profile

Actions
Copy link

Support #2135

closed

Suricata IPS Inline on a bridge not working

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

Status:
Closed
Priority:
Normal
Assignee:
OISF Dev
Affected Versions:
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
Actions
Copy link
 #1

Updated by Andreas Herz almost 7 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?

Actions
Copy link
 #2

Updated by Andreas Herz almost 7 years ago

  • Assignee changed from Matt Jonkman to OISF Dev
Actions
Copy link
 #3

Updated by Victor Julien almost 7 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.

Actions
Copy link
 #4

Updated by Felipe Houde almost 7 years ago

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

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

F.

Actions
Copy link
 #5

Updated by Felipe Houde almost 7 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

Actions
Copy link
 #6

Updated by Felipe Houde almost 7 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

Actions
Copy link

Also available in: Atom PDF