Harden your OpenWRT

Small guide how to harden your OpenWRT. I am using drop instead of reject to reduce CPU load.

via UCI
  1. Allow critical ports:
config rule
    option src 'lan'
    option dest_port '80,443,22'
    option proto 'tcp'
    option target 'ACCEPT'
  1. Limit SSH Access:
config rule
    option src 'lan'
    option src_ip '192.168.1.0/24'
    option dest_port '22'
    option proto 'tcp'
    option target 'ACCEPT'

config rule
    option src 'lan'
    option dest_port '22'
    option proto 'tcp'
    option target 'DROP'
  1. Deny anything else:
config default_policy
    option input 'DROP'
  1. Block Port Scans:
config rule
    option src 'lan'
    option dest_port '!22,80,443'
    option proto 'tcp'
    option target 'DROP'
  1. Block SYN Flood Attacks:
config rule
    option src 'lan'
    option proto 'tcp'
    option tcpflags 'SYN'
    option limit '1/s'
    option limit_burst '3'
    option target 'ACCEPT'

config rule
    option src 'lan'
    option proto 'tcp'
    option tcpflags 'SYN'
    option target 'DROP'
  1. Block ICMP (Ping) Requests:
config rule
    option src 'lan'
    option proto 'icmp'
    option icmp_type 'echo-request,timestamp-request,address-mask-request'
    option target 'DROP'
  1. Block portmapper:
config rule
    option src 'lan'
    option dest_port '111'
    option proto 'tcp'
    option target 'DROP'

config rule
    option src 'lan'
    option dest_port '111'
    option proto 'udp'
    option target 'DROP'
  1. Allow legitimate to reduce errors:
config rule
    option src 'lan'
    option proto 'tcp'
    option ctstate 'ESTABLISHED,RELATED'
    option target 'ACCEPT'
  1. Block NetBIOS:
config rule
    option src 'lan'
    option dest_port '137-139'
    option proto 'tcp'
    option target 'DROP'

config rule
    option src 'lan'
    option dest_port '137-139'
    option proto 'udp'
    option target 'DROP'
  1. Block SMB (Server Message Block):
config rule
    option src 'lan'
    option dest_port '445'
    option proto 'tcp'
    option target 'DROP'
  1. Block Telnet:
config rule
    option src 'lan'
    option dest_port '23'
    option proto 'tcp'
    option target 'DROP'
  1. Block DNS Tunneling:
config rule
    option src 'lan'
    option sport '53'
    option proto 'udp'
    option target 'DROP'
  1. Block ICMP Redirects:
config rule
    option src 'lan'
    option proto 'icmp'
    option icmp_type 'redirect'
    option target 'DROP'
  1. Block useless IP connections:
config rule
    option src 'lan'
    option src_ip '192.168.1.0/24'
    option dest_ip '192.168.1.0/24'
    option target 'ACCEPT'

config default_policy
    option input 'DROP'
  1. Block Large Packets:
config rule
    option src 'lan'
    option proto 'tcp'
    option tcpflags 'SYN'
    option tcpmss '1:1024'
    option target 'DROP'
  1. Block New Connections Without SYN:
config rule
    option src 'lan'
    option proto 'tcp'
    option tcpflags '!SYN'
    option ctstate 'NEW'
    option target 'DROP'
  1. Block New Connections Without ACK:
config rule
    option src 'lan'
    option proto 'tcp'
    option tcpflags '!SYN'
    option ctstate 'NEW'
    option target 'DROP'

After adding these rules to /etc/config/firewall, you can apply the changes by restarting the firewall service or rebooting your OpenWrt device.

via IPtables

Easy way:

  1. Allow critical ports:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
  1. Limit SSH Access
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
  1. Deny anything else
iptables -A INPUT -j DROP

Expert way

  1. Block Port Scans
    Port scans are used by bad actors to find open ports and services on your network. This rules can mitigate risk.
iptables -A INPUT -p tcp --match multiport ! --dports 22,80,443 -j DROP

This rule drops all incoming TCP traffic that does not match the ports you've specified (in example: SSH, HTTP, HTTPS).

  1. Limit SSH Access
    Consider limiting it to specific IP addresses or ranges to prevent brute force attacks.
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Replace 192.168.1.0/24 with the IP range you wish to allow.

  1. Block SYN Flood Attacks
    SYN flood attacks aim to consume server resources by sending a large number of SYN requests.
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

This rule allows a maximum of 3 SYN packets per second, dropping any additional packets. This should be enough for regular usage.

  1. Block ICMP (Ping) Requests
    ICMP requests can be used for reconnaissance or to map your network. Also they can be used for DDOS. Blocking them can help reduce this risks.
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp --icmp-type address-mask-request -j DROP
  1. Block portmapper
    It is not typically needed for most home networks.
iptables -A INPUT -p tcp --dport 111 -j DROP
iptables -A INPUT -p udp --dport 111 -j DROP
  1. Allow legitimate to reduce errors
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  1. Save and Apply Rules
iptables-save > /etc/iptables.up.rules
  1. Block NetBIOS
    NetBIOS used in Windows environments for file sharing and printer sharing. Most of you never used it.
iptables -A INPUT -p tcp --dport 137:139 -j DROP
iptables -A INPUT -p udp --dport 137:139 -j DROP
  1. Block SMB (Server Message Block)
    SMB is used for file sharing and printer sharing. Blocking it can prevent unauthorized access to shared resources. Can cause problems with LAN printers.
iptables -A INPUT -p tcp --dport 445 -j DROP
  1. Block Telnet
    Telnet is just insecure protocol. Hardly recommend to block.
iptables -A INPUT -p tcp --dport 23 -j DROP
  1. Block DNS Tunneling
    DNS tunneling can be used to bypass firewalls
iptables -A INPUT -p udp --sport 53 -j DROP
  1. Block ICMP Redirects
    ICMP redirects can be used to redirect traffic to malicious servers. This prevents MITM attacks.
iptables -A INPUT -p icmp --icmp-type redirect -j DROP
  1. Block useless IP connections
iptables -A INPUT -s 192.168.1.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -j DROP
  1. Block Large Packets
    Against DOS and DDOS
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1:1024 -j DROP
  1. Block New Connections Without SYN
    This will help to reduce attack vector
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
  1. Block New Connections Without ACK
    Blocking new connections that do not start with an ACK packet can help prevent certain types of attacks.
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

Save them:

iptables-save > /etc/iptables.up.rules

And apply them on boot by adding the following to /etc/rc.local:

/sbin/iptables-restore < /etc/iptables.up.rules
5 Likes

Some or all of this is probably a lot easier to do in uci code.

But the big issue is more towards the fact that we left iptables to history in like 2021 (or 2022 whenever fw4 was introduced)?

4 Likes

I suspect a good chunk of it is entirely unnecessary. For the remainder (if there is any) I agree it's probably a lot easier just using UCI code (or even easier in Luci).

5 Likes

this hardening tip is debated every once in a while in threads here in the forum and also many small blogs.

Just because the tip is repeated a lot does not make it a more safe choice and does not make the default reject wrong. „How many“ practical CPU savings are you expecting?

Also make sure you understand, what it means, to bypass Luci or UCI on firewall changes: the next Luci/uci triggered config change might overwrite iptables changes

5 Likes

Added to post! Thank you!
This post was in my draft, so I didn’t wrote that :slight_smile:

Now I've seen the UCI version I'm even more convinced the rules are entirely unnecessary.

2 Likes

Can I hear arguments? Most of them to prevent DDOS. Unfortunately, it is regular practice if you share connection with many unknown individuals

Perhaps don't do that then. Or create a guest interface in it's own firewall zone, reject/drop (as desired) access to the router, then specifically allow only desired traffic. Put the unknown individuals on that interface.

2 Likes

Is it nftables these days?

Yea, it is. I don’t really know what to say about the fact that you all have missed all available information for about 2-3 years that has been released about firewall 4.

2 Likes

Yes. It is for such interfaces. But some rules I implemented in main interface. Consider me paranoid :smile:

It frankly smacks of a list of 'rules' created by someone who has read too much and doesn't really understand what it is they're doing.

5 Likes

Now with the uci rules section at the top.

Rule number 5…
Have you actually used OpenWrt or read the manual for the firewall because we have a checkbox in luci for syn flood protection, and it has been around for ages.
Or as uci option synflood_protect .

But still (3’rd attempt to break the news to you), the only supported firewall in OpenWrt is firewall 4 and that only have support for nftables so what are we supposed to do with a list of iptables rules?

3 Likes

My take on drop vs reject is that every case is different. If I'm writing a rule on the WAN, for say a public SSH server, I'm going to drop as I don't even want to acknowledge to the potential bad actor that I even exist. For my LAN-facing, DoH block rules, I send reject as I want to tell local hosts "Yeah, I hear you, but stop trying that."

3 Likes

While this is often seen as desirable, it has potential collateral impacts. While the reply from a REJECT rule can be used to indicate presence and thus be used by a bad actor to brute-force your device, setting it to DROP can (in specific situations) cause increased traffic or even inadvertant DoS situations. Specifically, TCP relies on the ack packets, even if it is a reject. Without an ack, the sender may keep resending on the premise that the packets got lost. The result is that non-malicious traffic may increase when otherwise it would have simply understood and honored the REJECT response. This is why the default configuration has the wan zone input rule set to REJECT and not DROP.

2 Likes

When looking at the drop/reject log for wan zone the bad actors are to 99,999% probing the specific registered communication ports like 22, 80, 443 etc to find servers to mess around with.
To search around on the internet for icmp answers in general doesn’t seem to be of anyones interest. Usually that is the ISP doing that when you report connection problem…

But what I have found when talking about ICMPv6 is that if you want a lot of kernel errors and undefined droped packages in system log, then block ICMPv6. This has especially high effect factor for internal network traffic if you only have ipv4 from ISP.

1 Like

How so? The classic approach to DOS someone is simply to 'flood the ingress with bogus packets, crowding out legitimate traffic'. I fail to see how your rules help?

Regarding reject versus drop, my ISP generates differential responses whether an IP is in use or not, so drop does not make my router magically invisible... (drops are harder to use to fingerprint the OS I grant you that).
Disallowing ICMP echo requests means no more delay/availability checking via smokeping or similar services (thinkbroadband's free quality monitor comes to mind) this is a trade off (like most security decisions) that should at least be mentioned somewhere if you propose your set of rules for general consumption.

2 Likes

In a kinda reflected DDoS, the SRC and DST IP could both be victims.

  • The malicious actor (or botnet, etc.) is on an ISP able to spoof SRC IPs
  • The packet arriving at the DST WAN is rejected
  • These reject/etc. replies are transmitted to the victim's [spoofed] SRC IP

But if the malicious actor already knows the IP to be that of the victim (i.e. the victim is a specific and intended target), not even DROP rules will stop an overwhelming flood of bogus packets consuming your inbound bandwidth.

True, that is nothing the endpoint of the water hose can do if the water hose is full and pressurized…

That is pretty much the business idea of Cloudflare. “We take the incoming water on this hose and you go play with another hose we have prepared with less water in it”

3 Likes

I am just not important enough to be worth DDOSing. If someone were to DDOS me I would be quite awestruck that I was worth being selected for a DDOS attack and what possible notoriety the attacker would hope to gain by DDOSing me.