Support #2547: Blocking does not happen - Suricata - Open Information Security Foundation

Custom queries

Good First Issues
OISF community

Actions

Copy link

Support #2547

closed

Blocking does not happen

Added by Alex SW almost 6 years ago. Updated about 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Affected Versions:

3.2.5

Label:

Description

Good afternoon!
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.

History
Notes
Property changes

Actions

Copy link

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.

Actions

Copy link

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().

Actions

Copy link

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).

Actions

Copy link

Updated by Eric Leblond almost 6 years ago

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.

Actions

Copy link

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?

Actions

Copy link

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

Chain OUTPUT (policy ACCEPT)
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

Chain POSTROUTING (policy ACCEPT)
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.

Actions

Copy link

Updated by Alex SW almost 6 years ago

ifconfig eth0 217.100.100.100/32 up
ifconfig eth1 192.168.1.1/25

Actions

Copy link

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.

Actions

Copy link

Updated by Alex SW almost 6 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.

Actions

Copy link

#10

Updated by Alex SW almost 6 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.

Actions

Copy link

#11

Updated by Alex SW almost 6 years ago

And sorry///
" concept of the AXI model" -> concept of the OSI model :)))) translator failed

Actions

Copy link

#12

Updated by Alex SW almost 6 years ago

Please help me figure it out !!

Actions

Copy link

#13

Updated by Alex SW almost 6 years ago

File B_zD7oIWEAMQI7F.jpg added

Actions

Copy link

#14

Updated by Victor Julien almost 6 years ago

I assume the last picture was posted by mistake, so I've removed it.

Actions

Copy link

#15

Updated by Victor Julien almost 6 years ago

File deleted (~~B_zD7oIWEAMQI7F.jpg~~)

Actions

Copy link

#16

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.

Actions

Copy link

#17

Updated by Victor Julien about 5 years ago

Status changed from New to Closed

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

Suricata

Custom queries

Support #2547

Blocking does not happen

Updated by Victor Julien almost 6 years ago

Updated by Alexander Gozman almost 6 years ago

Updated by Alexander Gozman almost 6 years ago

Updated by Eric Leblond almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Eric Leblond almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Alex SW almost 6 years ago

Updated by Victor Julien almost 6 years ago

Updated by Victor Julien almost 6 years ago

Updated by Victor Julien over 5 years ago

Updated by Victor Julien about 5 years ago