Der Nachteil der Verwendung von Asuswrt-Merlin auf meinem Asus RT-AC66U-Router ist das latent vorhandene Gefrickel. Ich kann es kaum erwarten, bis mein Turris Omnia ankommt!

So musste ich vor einigen Monaten bemerken, dass das Web-Interface meines Routers aus dem Internet zugänglich ist, egal, ob ich diese Option im Web-GUI des Routers nun aktiviere oder deaktiviere. Das Interface läuft auf Port 8443 und ist nur mit HTTPS erreichbar (mit einem selber signierten Zertifikat).

Ich griff deshalb kurzerhand zu iptables, um diesen sicherheitsmässigen Fahrlässigkeit den Garaus zu machen: Ich loggte mich per SSH auf den Router ein und fand zuerst einmal das WAN-Interface heraus:

$ ifconfig
...
eth0       Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX 
           inet addr:85.X.X.X  Bcast:85.X.X.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:662731029 errors:0 dropped:0 overruns:0 frame:0
           TX packets:536190886 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000 
           RX bytes:871096761 (830.7 MiB)  TX bytes:4294213359 (3.9 GiB)
           Interrupt:4 Base address:0x2000
...

Soso, eth0 also, da dies das einzige Interface mit einer öffentlichen IP war.

Folgender iptables-Befehl killt alle aus dem WAN stammenden Anfragen auf Port 8443:

# iptables -A INPUT -i eth0 -p tcp --destination-port 8443 -j REJECT
# iptables -A INPUT -i eth0 -p tcp --destination-port 22 -j REJECT

Wieso ich REJECT und nicht (wie ursprünglich konfiguriert) DROP gewählt habe? Drop versus Reject

Schnellcheck

Um sicherzugehen, dass die iptables auch wirklich nützen, habe ich mich dann des Tools NetRenderer bedient. In der Adresszeile des Web-Tools gebe ich

https://85.X.X.X:8443/

ein und warte, bis mir ein Timeout angezeigt wird. Wird stattdessen ein Zertifikat-Fehler angezeigt, weiss ich, dass die Verbindung (leider) immer noch möglich ist.

Langfrist-Check

Auf StatusCake habe ich mir einen Check auf dieselbe URL eingerichtet, welcher mich alarmiert, sollte die Verbindung plötzlich wieder möglich sein (bspw. auf Grund eines Reboots). Dies war heute der Fall, nachdem die Regel 57 Tage und 9 Stunden gehalten hatte.

Nachtrag

Himmelarsch, Port 22 (SSH) war auch die ganze Zeit über offen!

$ nmap -F 85.X.X.X
22/tcp   filtered ssh
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
8443/tcp filtered https-alt