Suricata listen on dummy interface

1

I am currently deploying a suricata machine in my virtual network (IDS mode, ubuntu server 20.04 OS). It works fine, when I let suricata listen on the interface “ens33”, which is the interface with a valid network connection and IP address from the DHCP server. However, I need to rewrite some of the network packets (don’t ask why, I just need to). After rewriting I send them from ens33 to a dummy interface “loop1”.

But, when I edit my suricata config (yaml) and set loop1 as the interface suricata should listen on, it triggers none of the rules, while listening on ens33 does trigger alerts.

I cannot find anything about Suricata IDS not supporting listening on a dummy interface. What am I doing wrong?

2

Suricata should work fine on “dummy” devices in Linux, and similar bridge type interfaces.

Are all the packets being forwarded? Everything look OK in tcpdump? Maybe there will be some hints in the stats records.

1 Like
3

Thank you for the reply. My rewrite-script is explicitly for rewriting and forwarding HTTP packets. Might that be an issue to Suricata?

4

What is your script doing? How are the packets being forwarded?

5

It’s a python script, using scapy’s sending packets function.

sendp(packet, iface="loop1", verbose=False)
6

You’ll likely have to validate manually that you are getting valid streams.

I’ve used dummynet devices a lot with Suricata - I have Suricata listening on the interface while I tcpreplay a pcap into it and all is good. You may want to try similar just to verify that Suricata is seeing data on the interface (tho wireshark, tcpdump should be able to show you that)… But if that is logged correctly, you can probably narrow it down to your rewriting program.

7

Not sure how scapy rewrites packets, but are you ignoring checksums in suricata? -k none

8

No I wasn’t ignoring checksums, so I got a lot of checksum alerts in the first place.

9

I can confirm that the interface is receiving the packets successfully (from the script). TCPdump captures the http requests just fine from the loop1 interface. Using tcpreplay to make sure, didn’t trigger any of the alerts.

EDIT:

But, I notice the following:

The alert I’ve created is an HTTP alert:
alert http any any -> any any (content:"malware.xyz"; http_header; msg:"MALWARE KEYWORD DETECTED";)

So the script I have only handles/forwards HTTP traffic. But, when not using the script, the alert message I see in the log has the tag {TCP}. Does this mean it’s triggered by a TCP packet? Shouldn’t this be HTTP, since it’s an HTTP alert? If so, this would look like the cause of the traffic forwarded by the script not generating any alerts, since it’s HTTP only that is being forwarded to the loop1 interface (?).