securing internal network traffic against rogue apps / devices

  • ATTENTION! As of November 1, 2020, you will not be able to reply to threads 6 months after the thread is opened. Threads will not be locked, so posts may still be edited by their authors.

Doverton

New Around Here
Hi,

I am trying to stop undesired behaviour on my internal network and this means I want to stop the following items:
- Unknown MAC addresses communicating
- HTTPS VPNs
- DNS redirection
- DNS over https (DoH)
- Quic

Here is what I've done so far:
- My network has 3 WiFi routers and I have created an "allow-list" of MACs on each router
- I've forced all DNS (not DoH) to go to the router
- I've blocked UDP traffic to port 80/443
- I've tried the following script to stop non-authorised MACs from working (I've created the file with all the MACs listed), but this doesn't appear to work on my RT-AX56U router.
for MAC in `cat mac_addresses_file`; do
iptables -A FORWARD -i eth0 -o eth1 -m mac --mac-source $MAC -j ACCEPT
done
iptables -P FORWARD DROP


What I am seeing is that the client with a blocked MAC is still able to connect to the network, I presume through another wifi spot, even though MAC filtering is enabled on them all.

Any thoughts on how I achieve the above? I'm using unbound, but that is it.

Thanks

David
 

bbunge

Very Senior Member
Do you have any iOS devices that change their MAC address? Might explain the unknown MAC address.
 

eibgrad

Senior Member
First off, it's usually not a good idea to append (-A) rules unless you know for *sure* that any prior rules will not let the traffic through. Since we can't see those rules in context, we just have to assume they should work as intended. That's why most ppl suggest insertion (-I); it's just more likely to work, esp. when you have no further information about the state of the firewall.

Second, you're referencing the raw wireless network interfaces (eth0 and eth1), but usually those are bound to a bridge (e.g., br0) along w/ the switch's VLAN (e.g., vlan1). And once a network interface is bound to a bridge, it can't be referenced anymore in iptables! Any such rules are simply ignored. You can only reference the *bridge* to which they are assigned.

In short, without any further context than what you've described, it's just a guessing game.
 

Jack Yaz

Part of the Furniture
Second, you're referencing the raw wireless network interfaces (eth0 and eth1), but usually those are bound to a bridge (e.g., br0) along w/ the switch's VLAN (e.g., vlan1). And once a network interface is bound to a bridge, it can't be referenced anymore in iptables! Any such rules are simply ignored. You can only reference the *bridge* to which they are assigned.
Incorrect. You can use ebtables to drop the bridged traffic from the interfaces, and use the interfaces directly in iptables. YazFi does this successfully.
 

eibgrad

Senior Member
Incorrect. You can use ebtables to drop the bridged traffic from the interfaces, and use the interfaces directly in iptables. YazFi does this successfully.
Well are you saying that dropping the bridged traffic from the interfaces via ebtables is a *prerequisite* for this to work from iptables? Because the OP never suggested this is what he's doing. And I'm only claiming that when dealing strictly w/ iptables (no other prerequisites), in my experience, you can't do it. But if you now change the conditions, and use something like ebtables to drop/manipulate the bridge, I would presume it's possible. But again, that was never part of the discussion from either the OP or me.
 

mike37

Regular Contributor
Hi,

I am trying to stop undesired behaviour on my internal network and this means I want to stop the following items:
- Unknown MAC addresses communicating
- HTTPS VPNs
- DNS redirection
- DNS over https (DoH)
- Quic

Here is what I've done so far:
- My network has 3 WiFi routers and I have created an "allow-list" of MACs on each router
- I've forced all DNS (not DoH) to go to the router
- I've blocked UDP traffic to port 80/443
- I've tried the following script to stop non-authorised MACs from working (I've created the file with all the MACs listed), but this doesn't appear to work on my RT-AX56U router.
for MAC in `cat mac_addresses_file`; do
iptables -A FORWARD -i eth0 -o eth1 -m mac --mac-source $MAC -j ACCEPT
done
iptables -P FORWARD DROP


What I am seeing is that the client with a blocked MAC is still able to connect to the network, I presume through another wifi spot, even though MAC filtering is enabled on them all.

Any thoughts on how I achieve the above? I'm using unbound, but that is it.

Thanks

David
You might be interested in:
and

These come with rules that'l flag many of the actions you listed. In IDS mode you'll see these and perhaps additional undesirable activity. You'd then customize the rules to ignore actions you approve of, and flag other actions.

Switch over to IPS mode and the unwanted actions will be both flagged and blocked. If processes "evolve" to using other addresses or techniques, the IPS would likely detect and block it.

Well..... this is how the IDS/IPS apps are supposed to work - in fact for asus-merlin they are under development and appear to work on only a few of the routers at this time. But IDS mode (flagging) only would be informative even if you have to tweak iptables to block things

Your situation and ability seem ripe for an IPS, and I'm guessing either of these projects would be very happy to have you involved.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top