What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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:
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.
 
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.
 
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
 
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.
 
@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.
 
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.
Does this script still work? I have been looking into doing something similar.
 
I like @ml70's approach - the scripts are a good teaching resource too.

I don't understand why "they" made networking so complicated and obscure. I can write computer code and I cannot figure out how to read my router's GUI firewall rules. For all I know all 65535 ports are open and actively listening for the malware payload.

Someone should invent a router for simple people that does simple, uncomplicated things. It could store a text file where a user can put instructions in an easy .txt file format.

CLOSE ALL PORTS
OPEN PORTS 80, 443 TCP
 
Someone should invent a router for simple people that does simple, uncomplicated things.
That's what home routers already do. They are designed to be used by non-technical people who have no idea of what a port is or does. You want to enable an FTP server? "Simple people" don't want to edit router text files with obscure ports number they don't understand. They just turn the FTP option on in the GUI and everything else is done for them.
 
That's what home routers already do. They are designed to be used by non-technical people who have no idea of what a port is or does. You want to enable an FTP server? "Simple people" don't want to edit router text files with obscure ports number they don't understand. They just turn the FTP option on in the GUI and everything else is done for them.
Fair enough, you are probably right. Most people just want to buy a thing and plug it in and the internet works. FTP servers are fairly technical. They might like the router text file.

If the GUI leaves out options that are only available by editing a config file, then the GUI is useless. A nice single page, config file with well documented comments is all anyone needs. It could even be simplified:

MAKE INTERNET WORK
NO ADS AND VIRUS

The GUI I am faced with is just technical enough for me to realize it has problems (firewall in only one direction) and I will need to learn iptables and a bunch of painful, but mildly interesting things, that I will ultimately benefit from having learned.
 
I really don't understand what you are expecting from an Asus home router or why a text file would help.

"MAKE INTERNET WORK" - it does that already. "NO ADS AND VIRUS" - Ad-blocking is not a feature of the router so "a text file" won't help. No viruses, that's what AiProtection does.

One way firewall - all home routers assume your LAN is trusted and the WAN in untrusted. If your LAN is untrusted (e.g. you're using it in a commercial setting) then you should probably be using a business class router not a home router.

Additional GUI options, iptables, addon scripts, etc. None of these are standard features of stock Asus firmware, which is for simple users. You can have those if you install Merlin's custom firmware but that assumes that you understand those features or are prepared to learn about them.
 
Last edited:

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