How to block all protocols except TCP and UDP?

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Fri May 07, 2021 10:54    Post subject: How to block all protocols except TCP and UDP? Reply with quote
How can I block all protocols, except TCP (-p 6) and UDP (-p 17), with IPTables when the INPUT Policy has to be ACCEPT and no chains can be added?

It is easy if INPUT policy is set to DROP because I can just add an ACCEPT rule for -p 6 and -p 17, but if INPUT policy is ACCEPT, then I basically have to drop every single protocol from https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers because IPTables syntax allows for only one protocol per line. There is no way to use a range of protocols in a single command.

...but there has to be an easier way than to do that than what I am doing right now:
iptables -A INPUT -p 1 -j DROP
iptables -A INPUT -p 2 -j DROP
iptables -A INPUT -p 3 -j DROP
iptables -A INPUT -p 4 -j DROP
...
iptables -A INPUT -p 255 -j DROP
Sponsor
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 4402
Location: UK, London, just across the river..

PostPosted: Fri May 07, 2021 12:03    Post subject: Reply with quote
iptables -I INPUT -j DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

as simple as that...but you can be more specific...

for example:
iptables -I INPUT -i br0 -p tcp --dport 53 -j ACCEPT
iptables -I INPUT -i br0 -p tcp --sport 53 -j ACCEPT

--dport - destination port
--sport - source port

_________________
Atheros
TP-Link WR740Nv1 -----DD-WRT 46974 BS AP,NAT
TP-Link WR740Nv4 -----DD-WRT 44251 BS WAP/Switch
TP-Link WR1043NDv2 ---DD-WRT 46885 BS AP,NAT,AP Isolation,Ad-Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---DD-WRT 46974 BS AP,NAT,AD/Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Qualcomm/IPQ8065
Netgear R7800 -----DD-WRT 46979 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Broadcom
Netgear R7000 -----DD-WRT 46979 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,VLAN's,DoT,VPN
-----------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 by mac913
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Fri May 07, 2021 15:00    Post subject: Reply with quote
Alozaros wrote:
iptables -I INPUT -j DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

Not sure it's quite that simple. First of all, the INPUT chain is specific to traffic inbound for the router itself. For traffic between client devices and the internet, you need the FORWARD chain.

Also the above rules put the tcp/udp rules after the DROP rule, where they have no effect. And every packet destined for the router (like DNS queries, ssh connections, etc.) will be dropped. If you also do a version of this on the FORWARD chain, you'll be killing all traffic to/from the internet and between client devices.

Or maybe I'm caffeine deprived. Have I misread something?

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 4402
Location: UK, London, just across the river..

PostPosted: Fri May 07, 2021 16:31    Post subject: Reply with quote
SurprisedItWorks wrote:
Alozaros wrote:
iptables -I INPUT -j DROP
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

Not sure it's quite that simple. First of all, the INPUT chain is specific to traffic inbound for the router itself. For traffic between client devices and the internet, you need the FORWARD chain.

Also the above rules put the tcp/udp rules after the DROP rule, where they have no effect. And every packet destined for the router (like DNS queries, ssh connections, etc.) will be dropped. If you also do a version of this on the FORWARD chain, you'll be killing all traffic to/from the internet and between client devices.

Or maybe I'm caffeine deprived. Have I misread something?


nope you are not caffeine deprived...i was ... Smile it was a simple rushy answer from my side..

in regards to drop rules my mistake, it should ve be reject

iptables -I INPUT -j REJECT
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT

i ve similar to those running..
iptables -I INPUT -i br0 -p tcp --dport 80 -j REJECT
iptables -A INPUT -i br0 -p tcp --dport 80 -m mac --mac-source xx.xx.xx.xx.xx.xx -j ACCEPT

and yes cutting all traffic on INPUT chain will cause troubles unless you know what you are doing...
good to share the main goal...

_________________
Atheros
TP-Link WR740Nv1 -----DD-WRT 46974 BS AP,NAT
TP-Link WR740Nv4 -----DD-WRT 44251 BS WAP/Switch
TP-Link WR1043NDv2 ---DD-WRT 46885 BS AP,NAT,AP Isolation,Ad-Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---DD-WRT 46974 BS AP,NAT,AD/Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Qualcomm/IPQ8065
Netgear R7800 -----DD-WRT 46979 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Broadcom
Netgear R7000 -----DD-WRT 46979 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,VLAN's,DoT,VPN
-----------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 by mac913
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Fri May 07, 2021 17:26    Post subject: Reply with quote
On my Raspberry Pi local DNS server, having general INPUT policy set to DROP, followed by ACCEPT for SSH, DNS, and other ports, does not prevent me from further accessing Raspberry Pi via SSH or GUI.

Example:
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s <Admin1-IP> -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Admin1-IP> -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Admin1-IP> -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Admin1-IP> -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Client1-IP> -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Client2-IP> -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s <Client3-IP> -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


On the router, having the first rule as DROP cuts me off from router access via GUI or SSH. Why does it not do the same for Raspberry Pi? I know DROP and REJECT are somewhat different, but why would REJECT not cut me off from GUI and SSH where DROP would? The main difference between DROP and REJECT is that one (DROP) does not send back a response, while the other one (REJECT) does.

A bit off-topic, but I am also confused "-i lo -j ACCEPT" for WAN INPUT. Would such a rule allow anyone over WAN to connect to router's loopback virtual interface?
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1198
Location: Appalachian mountains, USA

PostPosted: Sat May 08, 2021 17:22    Post subject: Reply with quote
Forgive my rush here, which is keeping me from reading too closely. Couple of small things though.

First, as to what use -i lo might be the input chain. You can, for example, do

iptables -I INPUT -i lo -p tcp --dport https -j ACCEPT

to allow an incoming ssh connection (with appropriate less-common arguments to ssh) to access the GUI.

Second, I'm seeing an issue in this whole discussion with -A INPUT when perhaps -I would be better suited. Remember, -A adds the rule at the end of the chain, so it will never be invoked if an earlier rule, perhaps a standard dd-wrt one, applies to the packet and uses -j to send control elsewhere, to the REJECT or ACCEPT code for example. It's an -I rule that goes to the beginning of the chain. So if you use -I INPUT -j DROP in one rule and then -A INPUT -p tcp -j ACCEPT in the next to try to make an exception to the DROP for tcp traffic, it will fail. All traffic to router (INPUT) processes will hit the DROP rule and will never even be examined by the -p rule.

_________________
Five WRT1900ACSv2's on 44048, 46069, 46816: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), DDNS, wireguard servers and clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Sat May 08, 2021 18:47    Post subject: Reply with quote
SurprisedItWorks wrote:
Forgive my rush here, which is keeping me from reading too closely. Couple of small things though.

First, as to what use -i lo might be the input chain. You can, for example, do

iptables -I INPUT -i lo -p tcp --dport https -j ACCEPT

to allow an incoming ssh connection (with appropriate less-common arguments to ssh) to access the GUI.

Second, I'm seeing an issue in this whole discussion with -A INPUT when perhaps -I would be better suited. Remember, -A adds the rule at the end of the chain, so it will never be invoked if an earlier rule, perhaps a standard dd-wrt one, applies to the packet and uses -j to send control elsewhere, to the REJECT or ACCEPT code for example. It's an -I rule that goes to the beginning of the chain. So if you use -I INPUT -j DROP in one rule and then -A INPUT -p tcp -j ACCEPT in the next to try to make an exception to the DROP for tcp traffic, it will fail. All traffic to router (INPUT) processes will hit the DROP rule and will never even be examined by the -p rule.


Yeah, that is why I can't figure out how to simplify rules that drop all known protocols, except TCP, UDP, and ARP, without having to list each protocol on new line. There are no Netfilter commands to aggregate several protocol numbers in a single command line.

As far as loopback goes, I don't understand whether someone can directly connect to it from WAN. TCPDump shows "127.0.0.1 > WAN IP" packets. If loopback can directly connect to WAN IP for outbound traffic, then can't someone from WAN connect to loopback interface? Most loopback traffic is from loopback to loopback.

Off-topic:
I have to confess that this is actually for a Ubiquiti's UniFi Dream Machine (UDM) router, not a DD-WRT one, but IPTables concept is the same.

UDM uses its own code and first INPUT rule sends packet to ALIEN and/or TOR chains, which lists encrypted user UBIOS rules specified in UDM GUI, but GUI rules force-allow connecting to Ubiquiti Cloud server, have no effect on some bugs, and don't apply to the router itself. For example, the newest firmware re-introduces a bug forces router to perform Device Discovery via UDP Port 10001 IP 255.255.255.255 over WAN. Another example is that dropping ICMP for WAN INPUT/FORWARD/OUTPUT, LAN INPUT/FORWARD/OUTPUT chains does not prevent the router from sending out ICMP packets to WAN to test connection quality.
tedm
DD-WRT User


Joined: 13 Mar 2009
Posts: 431

PostPosted: Mon May 10, 2021 3:48    Post subject: Reply with quote
Please review the following article
https://blog.securityevaluators.com/icmp-the-good-the-bad-and-the-ugly-130413e56030

to see why your idea of blocking every protocol other than TCP and UDP needs to be put to bed. And please do not continue to perpetuate the idea that a simple block on ICMP is at all acceptable. The article is simplified but it does cover the most important ICMP types that need to be allowed.

Ubiquity has documentation about this you should be contacting them. And the Dream Machine's purpose is not for simple protocol blocks in any case, if you are using it as such you are throwing away your money and you will NOT be blocking the problematical traffic in any case.

Use the Dream Machine as it was intended and turn on Deep Packet Inspection and quit messing with protocol blocks (which can easily be gotten around by the bad actors on your network in any case) It's a good box and it's capability is just being wasted as a simple iptables filter.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Tue May 11, 2021 21:11    Post subject: Reply with quote
That article is from 2016, but there is definitely a debate about ICMP. There is sensitive information that can be inquired from ICMP packets that bothers the latest Android developers, which is why April 2021 Pixel update adds noise to ICMP packets.

I've yet to come across a simple consumer client topology network (such as my own) with known MTU that is somehow degraded by dropping inbound and outbound ICMP packets. Every single local client on my network is isolated and using Wireguard VPN anyway.

I don't underestimate the power of IPTables/EBTables or see IDS/IPS as an alternative to them. Comparing Netfilter to IDS/IPS is like comparing IDS/IPS and VLAN isolation or underestimating good old domain black-holing with a local DNS server. UDM uses an old version of Suricata for IDS/IPS and so far there are only false positive results. Ubiquiti in general is heavily OpenWRT-ish.

I agree that I have much to learn, but Ubiquiti clearly states on its website that it is not going to provide a tech support about semi-advanced/advanced networking or give lessons (aside from website-based documentation) even for its pro-level(-ish) Edge Routers, let alone non-Pro oriented UDM. This is why I am asking here.

FYI, Ubiquiti tech support acknowledges that the latest UDM firmware contains a bug that makes it impossible to stop Ubiquiti's Device Discovery service broadcasting every 10 seconds on WAN over UDP port 10001 (255.255.255.255). BoostChicken utilities and custom IPTables is the only way to stop it (for now).
tedm
DD-WRT User


Joined: 13 Mar 2009
Posts: 431

PostPosted: Wed May 12, 2021 9:07    Post subject: Reply with quote
If you have a known MTU on an internal network then it would not be connected to the Internet thus you would not likely have a Dream Machine.

As a sidebar I don't have a huge amount of respect for Ubiquity's developers to be frank. They destroyed the ability of their mesh access points to act as bridges when they moved to version 6 of their controller software. When I screamed about it I got two weeks of "what problem" Then they finally acknowledged there was a problem only after I downgraded (which completely wiped out the AP mesh database which I had to rebuild) then they had the nerve to ask me to upgrade the AP's firmware "just to see if it will work"

No, peckerheads, I will not do that. Not when several of the AP's are only reachable by renting a lift truck.

Anyway, yes the article is from 2016 - because that ICMP blocking nonsense rears up every half decade or so as new techs who don't understand come into networking. You may want to learn but you clearly didn't read the article or you would have seen that there are ICMP types that are OK to block and ones that are not OK to block. You are still lumping all ICMP types into one kind of packet.

Consider for a second that if one of your machines from a network with a known MTU sends a packet to the Internet and that packet travels through a network with a smaller MTU. The packet will get fragmented and the receiver will get the frags and reassemble them. The return packet will get fragged and reassembled by your machine. So far so good. Now what happens if one of the apps on your machine for whatever reason (stupid or not) sets the "don't frag" bit on a packet it sends? The smaller network will NOT frag the packet and will transmit a "packet too big" ICMP message back to your machine - which because you are "blocking ICMP" will not be received - and your machine will then not be communicating. Get it?

And that's just the example that we use for Networking 101 to explain why ICMP blocking across-the-board is bad because it's easy to understand. I'm not going to go dredge out more of them for you. You can do that if you really want.

But like so many people out there you have decided already you are going to do this and you will just deal with any problems that it might cause. Yeah that works great - 3 years from now when you have completely forgotten this discussion and start ripping your hair out over some obscure networking problem you just cannot figure out why it's breaking.

I warned you but if you must burn your hand you better get it over with. Likely I won't be around when you finally in your googling frustration stumble over this post again and go "o gdm it he was right" I'm only trying to save you, I was young and stubborn once, too, and paid the price for that.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Wed May 12, 2021 11:40    Post subject: Reply with quote
You are probably right then. I am still new at this, but I do want to mask my online activities as much as possible. I prefer to have a single connection to DNS server to resolve VPN server domain to connect to VPN and then have nothing but a stream of encrypted data. I don't block ICMP within VPN tunnels, only outside of VPN tunnels.

Back to topic, UDM has a NAT/Firewall setting that allows users match all protocols, except the one/ones selected. If I select to drop all protocols except TCP and UDP via that setting for WAN In or WAN Out, internet stops working. That is puzzling because when I run TCPDump (all interfaces) and analyze packets for protocol types, all I see is TCP, UDP, ARP, and LLDP...
atifak
DD-WRT Novice


Joined: 02 Apr 2021
Posts: 15

PostPosted: Wed May 19, 2021 11:50    Post subject: Reply with quote
Consider what happens if a computer from a network with a known MTU sends a packet to the Internet via a network with a smaller MTU. The packet will be scattered, and the recipient will receive and reassemble the fragments. Your processor will frag and reassemble the returned packet.
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 4402
Location: UK, London, just across the river..

PostPosted: Wed May 19, 2021 18:45    Post subject: Reply with quote
MonarchX interesting topic, you started 'i just wont to cut off all the traffic and allow whatever i need' than, moved to 'i wanna hide badly, i want to use Suricata, for IDS/IPS like or any IPS(Snort)'...
You can run the old Snort 2xx on the router level DDWRT, but than again you are going too far...a normal VPN with a kill-switch and encrypted DNS inside the VPN channel should do..no need going to extreme...yep you can use Tor nodes over VPN, if you want a touch better, but cmon give us a break..you begun the sound like one odd forum member Blondie Laughing Laughing who wanted a rented VM payed with bitcoins, running DDWRT with VPN outside the top 14, also payed with bitcoins, as well having an encrypted DNS and ect.... just because he was a journalist Rolling Eyes Laughing Laughing Laughing if you want to hide badly, than you become a target, there is a lot to learn, how to hide in appropriate manner and still no peace.... Twisted Evil be careful what you wish...

_________________
Atheros
TP-Link WR740Nv1 -----DD-WRT 46974 BS AP,NAT
TP-Link WR740Nv4 -----DD-WRT 44251 BS WAP/Switch
TP-Link WR1043NDv2 ---DD-WRT 46885 BS AP,NAT,AP Isolation,Ad-Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---DD-WRT 46974 BS AP,NAT,AD/Block,Firewall,Local DNS,Forced DNS,DoT,VPN,VLAN
TP-Link WR1043NDv2 ---Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Qualcomm/IPQ8065
Netgear R7800 -----DD-WRT 46979 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Broadcom
Netgear R7000 -----DD-WRT 46979 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,VLAN's,DoT,VPN
-----------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 by mac913
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 79

PostPosted: Wed May 26, 2021 16:14    Post subject: Reply with quote
Back to original topic - how to drop all protocols except TCP and UDP when you are forced to use ACCEPT general policy without listing every protocol you want to drop?

UniFi Dream Machine's built-in firewall had 'Match all protocols, except' , but when I selected to drop all protocols, except TCP and UDP, connection dropped in both directions...




I went protocol number by number that was posted on Wikipedia and https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml to drop all protocol numbers except number 6 and 17. It worked, that was a very long way to do it...
tedm
DD-WRT User


Joined: 13 Mar 2009
Posts: 431

PostPosted: Sat May 29, 2021 19:43    Post subject: Reply with quote
Alozaros wrote:
just because he was a journalist


I think this one is a student at Brigham Young University and doesn't want to be expelled because he looked up women's reproductive rights...LOL...

The giant hole in all of this that I see is once his traffic makes it to the VPN provider it's sent out on to the general Internet. So, his traffic really isn't private since it's still going out onto the public Internet just a different place than from BYU there's still lots of opportunities for it to be inspected. Plus, he has to trust the VPN provider...
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum