Posts Tagged ‘RT-AC66U’

Sonntag, 28. August 2016

Admin-Interface des Routers gegen das Internet (WAN) schliessen

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

Tags: , , , , , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Montag, 23. Mai 2016

Passwort eines Asus RT-AC66U per SSH zurücksetzen

Die Idee war rückblickend doch nicht so genial, das Benutzerpasswort meines Asus RT-AC66U mit Merlin-Firmware ein Sonderzeichen enthalten zu lassen.

Glücklicherweise hatte ich meinen öffentlichen SSH-Schlüssel auf dem Router hinterlegt und konnte mich so zumindest per SSH einloggen. Einmal auf der Kommandozeile, führte ich folgende Befehle aus:

# nvram show | grep http_passwd
http_passwd=?einganzlangespasswort
# nvram set http_passwd="12345678"
# nvram commit

Quelle: DD-WRT :: NVRAM

Anschliessend funktionierte der Login über die Web-Oberfläche wieder.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Gigabit FTTH mit Asus RT-AC66U? Hände weg von DD-WRT!

Ende Januar 2016 wurde unsere Wohnung mit Fiber to the Home (FTTH) von Fiber7 (einer Tochter von Init7) erschlossen. Das konkurrenzlos günstige Angebot umfasst eine symmetrische 1 Gbit/s-Anbindung für weniger als 65 CHF pro Monat.

Die Verbindung zum Internet stelle ich mit einem Asus RT-AC66U und dem optischen Wandler TP-Link MC220L her. Auf dem Asus RT-AC66U lief bis letzte Woche DD-WRT mit dem Release r26332 vom 22. Februar 2015.

Von Powerline zu Ethernet-Kabel

Da ich mich beim Besuch der Elektriker von BKW ISP AG dazu entschied, den OTO im Wohnzimmer installieren zu lassen (die Alternative wäre das Büro gewesen), stellte sich mir das Problem, dass ich bis vor kurzem die maximale ISP-Geschwindigkeit nicht testen konnte: In der Stube betreibe ich einige Multimedia-Geräte wie den TV, den Apple TV sowie einen UniFi AP-PRO. Nur der UniFi WLAN-Access Point verfügt über einen Gigabit-Ethernet-Port — doch mit dem Access Point lässt sich die maximale Performance des Internetanschlusses nur schlecht testen.

Ein Geschwindigkeitstest mit der von Fiber7 empfohlenen Apple TV-App Ookla Speedtest zeigte Durchsätze von annähernd 100 MBit/s — sowohl für den Up- wie auch Downstream. Durchaus realistisch, wenn man bedenkt, dass der Apple TV nur mit einer Fast Ethernet-Schnittstelle ausgestattet ist.

Erst als ich von Digitec das lange vergriffene Wirewin Netzwerkkabel (25m, Weiss, STP, Kat. 6, Flachband) Kabel geliefert bekam, konnte ich das Büro direkt mit einem Cat 6-Netzwerkkabel erschliessen. Ich schaffte es, das Kabel der Fussleiste entlang und unter zwei Türleisten hindurch zu verlegen und so die zwei Gigabit-Switches TP-LINK SG1016D (Büro) und ZyXEL GS1100-8HP (Stube, mit PoE) miteinander zu verbinden.

In der Zwischenzeit verwendete ich ein Powerline-Produkt namens Devolo dLAN 500 duo+, um Stube und Büro über die Stromverkabelung zu verbinden. Der Frevel an der Sache: Ganze 50 MBit/s brachte ich so über die Leitung.

Erster Speedtest

Nun also waren der Mac mini und der iMac mit Gigabit-Ethernet an den Internet-Router angebunden. Voller Spannung startete ich den ersten von Init7 gehosteten Ookla Speedtest vom Mac mini aus — und erhielt mehrmals in der Folge folgende Messwerte zu Gesicht:

Ookla Speedtest Fiber7 DD-WRT
image-6583

Was zum Teufel? Verkauft mir Fiber7 vielleicht nur ein Zehntel des angepriesenen Durchsatzes?

Netzwerkkabel testen

Um das Problem einzugrenzen, teste ich als erstes das soeben verlegte Netzwerkkabel: Auf dem Mac mini startete ich iperf im Server-Modus:

$ iperf -s

Dann ging ich ins Wohnzimmer und verband einen Toshiba-Laptop mit integriertem Gigabit-Port an den Switch im TV-Schrank und lud mir iperf in der Version 2.0.5-3 auf den Rechner. Ich öffnete eine Kommandozeile und führte folgenden Befehl aus:

$ iperf -c 10.1.2.3

Der Mac mini zeigte darauf folgende Durchsätze an:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 128 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.2.3 port 5001 connected with 10.1.2.4 port 56432
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 721 MBytes 604 Mbits/sec
...

Am Ethernet-Kabel von der Stube ins Büro konnte es also definitiv nicht liegen.

Direkt am Router

Ich schloss den Laptop per Kabel direkt an den Router an und führte den Oookla-Geschwindigkeitstest erneut durch: Auch hier wieder der „mickrige“ Durchsatz in der Grössenordnung von Fast Ethernet (100 Mbit/s). Lag das Problem allenfalls am Geschwindigkeitstest, bspw. am Server von Fiber7?

Ookla Geschwindigkeitstest testen

Ich machte mich auf die Suche nach einem im Internet verfügbaren iperf-Server und wurde auf der iperf-Web-Site fündig: Public iPerf3 servers. Ich wählte debit.k-net.fr, installierte auch noch iperf 3 und führte dann den Test aus:

$ iperf -c debit.k-net.fr

Auch bei dieser Aktion kam ich nicht nur annähernd in die Nähe der erwarteten 1 Gbit/s. Somit war für mich bewiesen, dass das Problem zwischen Router und dem ISP liegen musste. Doch wo genau?

DD-WRT

Langsam aber sicher wuchs in mir das Misstrauen gegenüber der Frickelware DD-WRT. Was, wenn die Open Source-Firmware die Performance des Routers einbrechen liess?

Ich informierte mich im Netz über die offizielle Firmware des Routers und durfte erfreut feststellen, dass das letzte Update kürzlich, am 28. Januar 2016, veröffentlicht worden war. Nach einer kurzen Recherche stiess ich auch auf die vom User „Merlin“ modifizierte Version der Firmware. Ich entschied mich, den Firmware-Wechsel zu wagen und zog Asuswrt-Merlin in der Version RT-AC66U_380.57_0 dem offiziellen Firmware von Asus vor.

Frühlingsputz: DHCP und VPN

Bevor ich aber das Vorhaben startete, entschied ich mich angesichts eines im April bevorstehenden Routerwechsels zwei Funktionalitäten vom Router weg auf einen Linux-Server zu verlagern: Den DHCP-Server sowie ein OpenVPN Site-to-Site-VPN zu meinem Elternhaus. Wie ich erst zu dem Zeitpunkt realisierte, gehört solche Funktionalität nicht auf einen Consumer-Router, sondern auf einen schicken, kleinen Linux-Server (Intel NUC), welcher ein „anständiges“ Linux, ausreichend Speicherplatz und Subversion-Anbindung möglich macht.

Asuswrt-Merlin

Wie in einem Artikel auf DD-WRT beschrieben, setzte ich den Router über das DD-WRT auf die Werkseinstellungen zurück. Anschliessend lud ich über das Web-Interface die Firmware (.trx) auf den Router und wartete den Transfer sowie die Installation ab. Der Router kam problemlos hoch und erschien nun mit der neuen, standardmässigen Oberfläche.

Nach einem erneuten NVRAM-Reset funktionierte auch die Konfiguration: Das NVRAM voller DD-WRT-Variablen wurde beim Rücksetzen nämlich irgendwie nicht gelöscht und überschritt plötzlich das maximal mögliche Volumen von 65 KB, weshalb die Routeroberfläche subtile Fehlfunktionen und Fehlermeldungen aufwies.

1 GBit/s!

Nachdem ich die Konfiguration des Routers abgeschlossen hatte, führte ich voller Spannung den nächsten Speedtest durch. Hatte sich der Aufwand, der mich fast das gesamte Wochenende gekostet hatte, gelohnt?

Ookla Speedtest Fiber7 Asuswrt-Merlin
image-6584

Beruhigt lehnte ich mich in den Bürosessel zurück und feierte innerlich der Beginn des nächsten Breitbandzeitalters.

Tags: , , , , , , , ,
Labels: IT

4 Kommentare | neuen Kommentar verfassen