Support #2547
closedBlocking does not happen
Description
Prompt please.
I set up suricata in ips mode and use AF_PACKET.
- suricata -V
This is Suricata version 3.2.1 RELEASE
Main sections of the configuration file /etc/suricata/suricata.yaml
.....
vars:
address-groups:
HOME_NET: "[192.168.34.0/24]"
...
rule-files:
- test.rules
...
outputs:
...
- drop:
enabled: yes
filename: drop.log
append: yes
...
af-packet:
- interface: eth0
threads: 1
defrag: yes
cluster-type: cluster_flow
cluster-id: 98
copy-mode: ips
copy-iface: eth1
buffer-size: 64535
use-mmap: yes
- interface: eth1
threads: 1
cluster-id: 97
defrag: yes
cluster-type: cluster_flow
copy-mode: ips
copy-iface: eth0
buffer-size: 64535
use-mmap: yes
.....
stream:
memcap: 64mb
checksum-validation: yes
inline: yes
....
Rules /etc/suricata/rules/test.rules
drop tcp any any -> any any (content: "test"; msg: "test bloking tcp pakets"; classtype:bad-unknown;)
- tail- f /var/log/suricata/drop.log
07/22/2018-23:30:51.387207: IN= OUT= SRC=192.168.34.199 DST=192.168.3.115 LEN=52 TOS=0x00 TTL=64 ID=30730 PROTO=TCP SPT=80 DPT=46262 SEQ=1823302659 ACK=847928038 WINDOW=227 ACK RES=0x00 URGP=0
#iptables -nvL Show counters are incremented in section FORWARD
Blocking does not happen, only logging in the logs drop.log and fast.log.
Everything works great in NFQUEUE + iptables.
Please help, I do not know what to do.
Updated by Victor Julien almost 6 years ago
Can you upgrade to the stable release (currently 4.0.5) and try again? 3.x is no longer supported.
Updated by Alexander Gozman almost 6 years ago
Victor Julien wrote:
Can you upgrade to the stable release (currently 4.0.5) and try again? 3.x is no longer supported.
Latest releases do not block either. It seems that the bug was introduced in 4474889667d664a66c1c123f4f7d2756e8a7fbb9: live devices list is created too late and AFPRunModeIsIPS() failes 'cause LiveGetDeviceCount() returns 0. The whole thing is called before LiveDeviceFinalize().
Updated by Alexander Gozman almost 6 years ago
Alexander Gozman wrote:
Victor Julien wrote:
Can you upgrade to the stable release (currently 4.0.5) and try again? 3.x is no longer supported.
Latest releases do not block either. It seems that the bug was introduced in 4474889667d664a66c1c123f4f7d2756e8a7fbb9: live devices list is created too late and AFPRunModeIsIPS() failes 'cause LiveGetDeviceCount() returns 0. The whole thing is called before LiveDeviceFinalize().
Sorry, I've meant latest version (from git).
Updated by Eric Leblond almost 6 years ago
- the interfaces should have no IP
- no operating system bridge should be setup
From what you are writing you are seeing packet on FORWARD chain of iptables meaning that the operating system is "routing" the packet. This is not the way to do, Suricata is in charge of getting packet from one interface and copy it to the other interface.
Updated by Alex SW almost 6 years ago
Victor Julien wrote:
Can you upgrade to the stable release (currently 4.0.5) and try again? 3.x is no longer supported.
Thank you for your answers.
I will definitely try the new version.
BUT!
It surprises me.
I'm using the latest version of Debian and its stable repository.
- lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
- uname -a
Linux suricata 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
Put this package from a stable repository using apt.
- cat /etc/apt/sources.list
deb http://ftp.ru.debian.org/debian/ stretch main
deb-src http://ftp.ru.debian.org/debian/ stretch main
deb http://security.debian.org/debian-security stretch/updates main contrib
deb-src http://security.debian.org/debian-security stretch/updates main contrib
- stretch-updates, previously known as 'volatile'
deb http://ftp.ru.debian.org/debian/ stretch-updates main contrib
deb-src http://ftp.ru.debian.org/debian/ stretch-updates main contrib
After installation, the marijuana works by default in af_packet.
Are you sure there is a bug in this version?
Updated by Alex SW almost 6 years ago
Eric Leblond wrote:
I'm not sure I understand your setup. In AF_PACKET IPS mode:
- the interfaces should have no IP
- no operating system bridge should be setup
From what you are writing you are seeing packet on FORWARD chain of iptables meaning that the operating system is "routing" the packet. This is not the way to do, Suricata is in charge of getting packet from one interface and copy it to the other interface.
- iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
target prot opt source destination
- iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
target prot opt source destination
- iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
cat /proc/sys/net/ipv4/ip_forward
1
If ip_forward = 0, then neither the system, nor the suricata does not transmit traffic!
"Suricata is in charge of getting packet from one interface and copy it to the other interface." - I understand this perfectly.
"the interfaces should have no IP" - At what level of the OSI model should I interact with this design? How should I transfer and receive traffic from the suricata?
Where can you read about it. Thank you.
Updated by Alex SW almost 6 years ago
ifconfig eth0 217.100.100.100/32 up
ifconfig eth1 192.168.1.1/25
Updated by Eric Leblond almost 6 years ago
In AF_PACKET IPS mode, we have a layer 2 bridge so you can't have 2 interfaces with different network attached. A typical setup will be:
[Clients Network (192.168.1.0/24)] -- [eth1 - Suricata - eth0] -- [ ethX (192.168.1.1) - Gateway - ethN (Public IP)]
So the hosts in the clients, really speak with the gateway and the Suricata box is completely transparent.
Updated by Alex SW over 5 years ago
Eric Leblond wrote:
In AF_PACKET IPS mode, we have a layer 2 bridge so you can't have 2 interfaces with different network attached. A typical setup will be:
[Clients Network (192.168.1.0/24)] -- [eth1 - Suricata - eth0] -- [ ethX (192.168.1.1) - Gateway - ethN (Public IP)]So the hosts in the clients, really speak with the gateway and the Suricata box is completely transparent.
traffic arrives on ethN (Public IP), as it is transmitted to this one ??
According to the concept of the AXI model and traffic forwarding, packets will run immediately from ethN (Public IP) to ethX (192.168.1.1). So the bridge is needed between ethN (Public IP) <-> eth0 and eth1 <-> ethX (192.168.1.1)
Where is all this written about?
PS I created ifconfig eth0 217.100.100.100 up && ifconfig eth1 0 up && ifconfig eth2 0 up && ifconfig eth3 192.168.34.0/24 up.
Changed file file /etc/suricata/suricata.yaml
...
af-packet:
- interface: eth0
threads: 1
defrag: yes
cluster-type: cluster_flow
cluster-id: 98
copy-mode: ips
copy-iface: eth1
buffer-size: 64535
use-mmap: yes
- interface: eth1
threads: 1
cluster-id: 97
defrag: yes
cluster-type: cluster_flow
copy-mode: ips
copy-iface: eth0
buffer-size: 64535
use-mmap: yes
....
Traffic is not blocked. With the interface eth3, banned traffic goes away.
Updated by Alex SW over 5 years ago
Sorry/ Changed file file /etc/suricata/suricata.yaml
...
af-packet:
- interface: eth1
threads: 1
defrag: yes
cluster-type: cluster_flow
cluster-id: 98
copy-mode: ips
copy-iface: eth2
buffer-size: 64535
use-mmap: yes
- interface: eth2
threads: 1
cluster-id: 97
defrag: yes
cluster-type: cluster_flow
copy-mode: ips
copy-iface: eth1
buffer-size: 64535
use-mmap: yes
Traffic is not blocked. With the interface eth3, banned traffic goes away.
Updated by Alex SW over 5 years ago
And sorry///
" concept of the AXI model" -> concept of the OSI model :)))) translator failed
Updated by Victor Julien over 5 years ago
I assume the last picture was posted by mistake, so I've removed it.
Updated by Victor Julien over 5 years ago
If you're using Suricata in IPS mode with AF_PACKET, Suricata will be a L2 bridge. Iptables won't be involved and the interfaces should not have IPaddresses.
Alternatively, you can run a routing IPS with Suricata. In this case you do assign IPaddreses, you do use iptables and you run Suricata with NFQ instead of AF_PACKET.