Iptables MAC Address rules not working when snort is running

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,
I'm fairly new to openwrt and I'm currently trying to use it with snort. I would like to be able to block certain MAC addresses from connecting to the network when I detect them misbehaving.

I would use /etc/config/wireless to do this, but I do not wish to interrupt any user connected to the network by running 'wifi reload'.

So I decided to use iptables to solve this with the following rules placed in /etc/firewall.user

iptables -A input_lan_rule -m mac --mac-source MAC-ADDRESS -j DROP
iptables -A forwarding_lan_rule -m mac --mac-source MAC-ADDRESS -j DROP

These rules seem to do the trick, but only when snort is not running. It seems that when snort is running and I have both rules in place that the banned mac address can connect to the network and use it as they please. However, when I only have the forwarding rule in place then the banned MAC can connect to the network but cannot do anything on the network.

I wonder if anyone with more experience than I could let me know why this is happening and how it might be resolved?

2

@Gozzer, welcome to the community!

What...you have Snort running and blocking traffic?

If so, how?

(I've never heard of anyone getting blocking operational in OpenWrt...or perhaps I incorrectly assume that because you have MAC rule issues?)

I'm guessing it's in the implementation.

1 Like
3

Thank you @lleachii!
I may be doing something wrong, just trying to learn more.
But currently, I have snort running in inline mode monitoring network between my land and wan. I don't have snort blocking MAC addresses as I don't believe that is possible. But I did manage to get it to block some IP addresses and a few other things.

The issue I'm having is that snort seems to be interfering with one of my iptables rules. My original guess was that it may just be bypassing the iptables rules altogether. But, this appears to be wrong as when I remove the input rule then the iptables are clearly being run.

4

How?

I think we need to know how you're blocking if the below doesn't work...as I said, MAC or otherwise, I've never heard of Snort blocking on OpenWrt.

Next:

Do not place rules in the custom chains. This is likely the problem. I'm not certain when the chanis are flushed, etc. - but I assume that it is happening between the appending of your rules. Try:

iptables -A INPUT -m mac --mac-source MAC-ADDRESS -j DROP
iptables -A FOWARD -m mac --mac-source MAC-ADDRESS -j DROP

If it must be LAN, use -i br-lan.

5

As in what rules I used to get it to block or actual implementation?

6

Both, if you don't mind.

(But test your rules first, you had the issue after all.)

7

Well I started with just getting it to work as an IDS
I'm using a raspberry pi 3B+ as I'm experimenting with low memory constraints
I first followed Openwrt's guide on setting up snort https://openwrt.org/docs/guide-user/services/snort
Then in the snort.conf I changed a few things to allow for lower memory such as adding lowmem mode

config detection: search-method lowmem search-optimize max-pattern-len 20

After doing this I used a simple rule to check if it was working

alert icmp any any -> $HOME_NET any (msg:"ICMP test detected"; GID:1; sid:10000001; rev:001; classtype:icmp-event;)

This worked and was logging every ping

To allow it to work in inline mode I changed the following settings

 config policy_mode: inline
 config daq: afpacket
 config daq_dir: /usr/lib/daq
 config daq_mode: inline
 config daq_var: buffer_size_mb=256

Then used the same rule above to test whether it was working or not changing the alert for drop
I haven't gotten round to properly configuring blacklists and whitelists but was able to block a single IP address from doing certain things such as using ssh with rules similar to below

drop tcp IPADD any -> $HOME_NET 22 (msg:"SSH attempt detected"; sid:10000002)

To get snort to run I use

snort -A fast -c /etc/snort/snort.conf -i wlan0:eth0

8

This still doesn't seem to work.
Its the same problem as before the iptables rules work when snort is not running but fail when it is.
And then when I remove the INPUT rule it starts working again. It seems to just be an issue with this particular rule.

9

I have also now tried using /etc/config/firewall to create the firewall rules using

config rule
        option name 'Drop_MAC_Foward'
        option src '*'
        option dest '*'
        option src_mac 'MAC-ADD
        list proto 'all'
        option target 'REJECT'

config rule
        option name 'Drop_MAC_Input'
        option src 'lan'
        option src_mac 'MAC_ADD'
        option target 'DROP'
        list proto 'all'

This has the same issues, works without snort but not with.

I've also tried flushing all of my iptables rules and only having these rules in place which resulted in the same effect.
I've also tried using PREROUTING instead of input for blocking the MAC address and still the same issue. It seems I can't prevent a MAC address from having access to the network whilst snort is running without using /etc/config/wireless

10

To be clear, the MAC you're trying to block is actually on your Layer 2 network (i.e. not behind another router or device), correct

11

So my network layout is
(device with mac to block) - (openwrt) - (isp router)

12

I think I have an idea why this isn't working but need to do more research. Snort is bridging wlan0 and eth0, I think that the default iptables doesn't work with bridged networks? Or that's what I've found from some googling. Most seem to recommend using kmod-br-netfilter to fix this. So I'm gonna have a look at that.

13
14

Well, it seems to be fixed. It wasn't working last night when testing the same rule that now works. But this seems to do the trick.

ebtables -A INPUT -s MAC-ADD -j DROP

I'm unsure why it is working now but didn't when I tried this before.

But as a general overview of the issue:
Snort, when run using inline mode, creates a bridge between the given interfaces. Therefore, you need to use ebtables rather than iptables.

Anyhow, thank you all for your help.

1 Like
15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.