Dropping Traffic Using Suricata with XDP

Help
, ,
1

Hello everyone, and thank you in advance for your help.

I am working on dropping messaging traffic by using Suricata in conjunction with XDP. With the Suricata configuration detailed below, I have it operating in IPS mode. I have successfully loaded XDP onto the interfaces, and I can see in the Suricata logs that the messaging traffic is being dropped. Despite all these successful indicators, when testing on a client device, messaging applications still function correctly even though the logs indicate they are being dropped.

Every time I refresh the page on the client device, I can see the drop logs, yet the page loads successfully. What could be causing this issue? What checks would you recommend I perform to troubleshoot? How can I resolve this situation?

I start Suricata using the command suricata -c /etc/suricata/suricata.yaml --af-packet -v, and from the output, I can confirm it’s running in IPS mode and that xdp_filter.bpf is successfully loaded to the LAN (enp3s0) and WAN (enp2s0) interfaces.

root@Surricate:/# suricata -c /etc/suricata/suricata.yaml  --af-packet -v
Info: conf-yaml-loader: Configuration node 'stream' redefined.
Notice: suricata: This is Suricata version 7.0.4 RELEASE running in SYSTEM mode
Info: cpu: CPUs/cores online: 4
Info: af-packet: Setting IPS mode
Info: exception-policy: master exception-policy set to: auto
Info: ioctl: enp3s0: MTU 1500
Info: ioctl: enp2s0: MTU 1500
Info: conf: Running in live mode, activating unix socket
Info: logopenfile: fast output device (regular) initialized: fast.log
Info: logopenfile: eve-log output device (regular) initialized: eve.json
Info: logopenfile: stats output device (regular) initialized: stats.log
Warning: detect-classtype: signature sid:52000000 uses unknown classtype: "messaging", using default priority 3. This message won't be shown again for this classtype
Info: detect: 9 rule files processed. 37178 rules successfully loaded, 0 rules failed, 0
Info: threshold-config: Threshold config parsed: 0 rule(s) found
Info: detect: 37181 signatures processed. 1137 are IP-only rules, 4934 are inspecting packet payload, 30898 inspect application layer, 108 are decoder event only
Info: af-packet: enp3s0: AF_PACKET IPS mode activated enp3s0->enp2s0
Info: ebpf: Successfully loaded eBPF file '/usr/libexec/suricata/ebpf/xdp_filter.bpf' on 'enp3s0'
Info: runmodes: enp3s0: creating 4 threads
Info: af-packet: enp2s0: AF_PACKET IPS mode activated enp2s0->enp3s0
Info: ebpf: Successfully loaded eBPF file '/usr/libexec/suricata/ebpf/xdp_filter.bpf' on 'enp2s0'
Info: runmodes: enp2s0: creating 4 threads
Info: unix-manager: unix socket '/var/run/suricata/suricata-command.socket'
Notice: threads: Threads created -> W: 8 FM: 1 FR: 1   Engine started.

Here are the changes I made in the suricata.yaml file:

stream:
  bypass: true

af-packet:
  - interface: enp3s0
    threads: 4
    cluster-id: 99
    cluster-type: cluster_qm  
    defrag: no  
    use-mmap: yes
    ring-size: 200000
    bypass: yes
    xdp-mode: driver
    xdp-filter-file: /usr/libexec/suricata/ebpf/xdp_filter.bpf
    copy-mode: ips
    copy-iface: enp2s0
  - interface: enp2s0
    threads: 4
    cluster-id: 98
    cluster-type: cluster_qm  
    defrag: no  
    use-mmap: yes
    ring-size: 200000
    bypass: yes
    xdp-mode: driver
    xdp-filter-file: /usr/libexec/suricata/ebpf/xdp_filter.bpf
    copy-mode: ips
    copy-iface: enp3s0

default-rule-path: /var/lib/suricata/rules

rule-files:
  - suricata.rules
  - opnsense.file_transfer.rules
  - opnsense.mail.rules
  - opnsense.malware_ja3.rules
  - opnsense.media_streaming.rules
  - opnsense.messaging.rules
  - opnsense.social_media.rules
  - opnsense.test.rules
  - opnsense.uncategorized.rules

I fetched the .rules files from the OpnSense repository at https://github.com/opnsense/rules/tree/master/src. The rules were initially set to alert, which I have edited to drop.

In the /var/log/suricata/fast.log file, I can see that the test traffic for WhatsApp is being dropped, yet WhatsApp continues to work flawlessly on the client device.

03/30/2024-18:36:55.963799  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 192.168.254.10:52264 -> 185.60.218.53:443
03/30/2024-18:36:55.963895  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 10.10.12.254:52264 -> 185.60.218.53:443
03/30/2024-18:37:00.713574  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 192.168.254.10:52265 -> 185.60.218.53:443
03/30/2024-18:37:00.713613  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 10.10.12.254:52265 -> 185.60.218.53:443
03/30/2024-18:37:11.077536  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 192.168.254.10:52267 -> 185.60.218.53:443
03/30/2024-18:37:11.077565  [Drop] [**] [1:52000065:1] OPN_Messaging - WhatsApp - Related TLS SNI (whatsapp.com) [**] [Classification: Unknown Classtype] [Priority: 3] {TCP} 10.10.12.254:52267 -> 185.60.218.53:443

Any insights or suggestions on what might be going wrong and how to resolve this issue would be greatly appreciated.

2

I would argue that this would only drop the packet that has the tls sni in but all the rest is still passed. The signature you use is not intended to drop but rather to notify about a connection attempt.