Tutorial Script: Dynamically block Asus open ports (security holes...)

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

ml70

Regular Contributor
Asus opens plenty of listening ports, some of which have been used to hack the device in the past ("Asusgate" etc).
If you're not using any Asus services from the internet, maybe it'd be smarter to block them to avoid security holes.
The problem is some of the ports are dynamic, a fixed script will not catch all of them.

The script creates two ipset tables for open udp and tcp ports on the router, which you can then block with iptables as
Code:
iptables -A INPUT -i eth0 -p udp -m set --set blockasusports-udp dst -j DROP
iptables -A INPUT -i eth0 -p tcp -m set --set blockasusports-tcp dst -j DROP
iptables -A OUTPUT -o eth0 -p udp -m set --set blockasusports-udp src -j DROP
iptables -A OUTPUT -o eth0 -p tcp -m set --set blockasusports-tcp src -j DROP
where eth0 is your wan interface.

You need to load modules needed by ipset in init-start:
Code:
insmod ip_set.ko
insmod ip_set_iphash.ko
insmod ip_set_ipmap.ko
insmod ip_set_ipporthash.ko
insmod ip_set_ipportiphash.ko
insmod ip_set_ipportnethash.ko
insmod ip_set_iptree.ko
insmod ip_set_iptreemap.ko
insmod ip_set_macipmap.ko
insmod ip_set_nethash.ko
insmod ip_set_portmap.ko
insmod ip_set_setlist.ko

And the script, blockasusports.sh:
Code:
#!/bin/sh
# blockasusports.sh
set -x   # echo commands for debugging

ipset -N blockasusports-udp portmap --from 0 --to 65535
# if you really need port 0 connectivity, change line to: :>/tmp/blo...
echo "0" > /tmp/blockasusports-udp

while read port
do
  test $port -eq 123 && continue
  ipset -A blockasusports-udp $port
  echo $port>>/tmp/blockasusports-udp
done <<EOT
`netstat -uaen | grep -E "0.0.0.0:[[:digit:]]+" | awk -F "[ :\t]+" '{print $5}'`
EOT

ipset -N blockasusports-tcp portmap --from 0 --to 65535
echo "0" > /tmp/blockasusports-tcp

while read port
do
  ipset -A blockasusports-tcp $port
  echo $port>>/tmp/blockasusports-tcp
done <<EOT
`netstat -taen | grep -E "0.0.0.0:[[:digit:]]+" | awk -F "[ :\t]+" '{print $6}'`
EOT

set +x
return 0 2>/dev/null   # exit if sourced
exit 0

Note: the script blocks all ports which are listening on all interfaces (0.0.0.0:port).
Should there be some which are only listening on your wan interface you need to modify the script, check with netstat -aen .
Something like
Code:
wanip=`nvram get wan_ipaddr`
netstat -taen | grep -E "$wanip:[[:digit:]]+" | awk -F "[ :\t]+" '{print $6}
using the tcp ports match as an example.

To check what has been blocked
Code:
ipset -L blockasusports-udp
or tcp, and the ports are also saved in /tmp/blockasusports-udp and -tcp.
 
Last edited:

ml70

Regular Contributor
You can run it hourly
Code:
cru a BlockAsusPorts "0 * * * * /jffs/scripts/blockasusports.sh"
add it to wan-start , or would init-start be a better choice.
 

RMerlin

Asuswrt-Merlin dev
Test your ports from outside your LAN, not from the inside. Asuswrt does NOT open any public port unless you explicitly enable that service (for example, WAN-side SSH).

There is no point in dropping a port that is already dropped by the firewall's default policy.
 

ml70

Regular Contributor
Are these not open to every interface?
Code:
tcp        0      0 0.0.0.0:18017
tcp        0      0 0.0.0.0:9518
udp        0      0 0.0.0.0:9999
udp        0      0 0.0.0.0:67
udp        0      0 0.0.0.0:18018
udp        0      0 0.0.0.0:1900
9518 is the dynamic port. How many of these are opened by unauditable Asus closed source code? Rather safe than sorry.

Another point of interest is how easily eth0 wants to get an ip to itself, if internet is provided by a pppoe tunnel through eth0. When in a LAN setting like an apartment building with its own lan or ISP's lan where traffic is not blocked between customer ports, seems all a neighbor has to do is to plug their WAN cable into their router's LAN port advertising their dhcp to the public, and Asus is happy to grab a DHCP ip for its eth0 port, and set a route to the neighbor's network via eth0.

From here it's easy for the neighbor to set default gw to Asus default gw address (the pppoe gw, a bit of guesswork at most), and suddenly neighbor has free internet. I can't 100% prove this because I don't have wireshark lappy I could plug in between wan cable and Asus wan port to record the traffic, but something I've observed regarding the ip address and route added.
Ebtables --ip-proto udp --ip-sport 67:68 --ip-dport 67:68 -j DROP on both input, output and forward (-i and -o there) have failed to block anything.

Or could this failure to block the dhcp traffic be an artifact of the darned CTF, AC66 the amazing 100 mbps router (after plugging all the security holes) sold as a gigabit router (with all the security holes, speed is easy when you don't care about security)...one more reason why I have trouble trusting Asus on security.

Only working mitigations are to blackhole the network neighbor is using, which quickly turns into a cat and mouse game (if persistent they will always find your own lan which you cannot blackhole), or write a daemon which every 10 seconds: ifconfig eth0 0.0.0.0 ; ip route flush dev eth0
 

Jack Yaz

Part of the Furniture
Are these not open to every interface?
Code:
tcp        0      0 0.0.0.0:18017
tcp        0      0 0.0.0.0:9518
udp        0      0 0.0.0.0:9999
udp        0      0 0.0.0.0:67
udp        0      0 0.0.0.0:18018
udp        0      0 0.0.0.0:1900
9518 is the dynamic port. How many of these are opened by unauditable Asus closed source code? Rather safe than sorry.

Another point of interest is how easily eth0 wants to get an ip to itself, if internet is provided by a pppoe tunnel through eth0. When in a LAN setting like an apartment building with its own lan or ISP's lan where traffic is not blocked between customer ports, seems all a neighbor has to do is to plug their WAN cable into their router's LAN port advertising their dhcp to the public, and Asus is happy to grab a DHCP ip for its eth0 port, and set a route to the neighbor's network via eth0.

From here it's easy for the neighbor to set default gw to Asus default gw address (the pppoe gw, a bit of guesswork at most), and suddenly neighbor has free internet. I can't 100% prove this because I don't have wireshark lappy I could plug in between wan cable and Asus wan port to record the traffic, but something I've observed regarding the ip address and route added.
Ebtables --ip-proto udp --ip-sport 67:68 --ip-dport 67:68 -j DROP on both input, output and forward (-i and -o there) have failed to block anything.

Or could this failure to block the dhcp traffic be an artifact of the darned CTF, AC66 the amazing 100 mbps router (after plugging all the security holes) sold as a gigabit router (with all the security holes, speed is easy when you don't care about security)...one more reason why I have trouble trusting Asus on security.

Only working mitigations are to blackhole the network neighbor is using, which quickly turns into a cat and mouse game (if persistent they will always find your own lan which you cannot blackhole), or write a daemon which every 10 seconds: ifconfig eth0 0.0.0.0 ; ip route flush dev eth0
Just because something is listening on a port does not mean it is accessible through the firewall.
 

ColinTaylor

Part of the Furniture
@ml70 As RMerlin pointed out all you've done is create a complicated process that replicates what the router's firewall already does.

Expanding on @Jack Yaz's post, taking port 67 as an example; just because it's listening on all interfaces doesn't mean it's accessible from the WAN. It needs to listen on all interfaces because interfaces (like VPNs) come and go. The restriction on who/what can access it is then done in the dnsmasq config (e.g. interface=br0).

I don't follow your whole argument about DHCP and PPPoE. In the apartment complex scenario you describe you wouldn't be normally be using a PPPoE configuration. Sure it's possible to do a man in the middle DHCP attack by operating a rogue DHCP server on the WAN side, but that would apply to all dynamic connections, not just PPPoE. The router has no idea of the network topology on the WAN side so can only assume it has been setup correctly. You can't just block all DHCP on the WAN because then you wouldn't get an internet connection at all.
 

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