Lancom ist open DNS resolver!?

[Pauli]

Hallo,

habe aktuelle eine 'open DNS resolver' Warnung vom Telekom Abuse Team erhalten!

Habe alles im internen Netzwerk deaktiviert bzw. ausgeschaltet, bekomme aber immer noch angezeigt, dass meine Ö-IP als DNS resolver fungiert! Kann hier der Lancom 1781A 8.82 mein Problem sein? Der DNS Server ist eigentlich nicht aktiviert und somit sollte er ja nur automatisch die Weiterleitung von Anfragen aus dem LAN an die DNS Server des Providers machen oder nicht?


Danke für jeden Hinweis,
Pauli

[backslash]

Hi Pauli,

das kann aber nur auf unmaskierten WAN-Verbindungen passieren - und da ist es gewollt (weil sowas i.A. in einem VPN-Netz geschieht). Wenn du wirklich eine unmaskierte Internet-Verbindung betreibst, dann mußt du in der Firewall eine Regel aufnehmen, die DNS für alle verbietet und eine weitere, die DNS aus deinem lokalen Netz heraus erlaubt:

Code: Alles auswählen

Name:    ALLOW-LOCAL-DNS
Quelle:  alle Stationen im Lokalen Netz
Ziel:    LAN-IP des LANCOMs (oder auch: alle Stationen im lokalen Netz)
Dienste: UDP, Zielport 53
Aktion:  übertragen


Name:    DENY-DNS
Quelle:  alle Stationen
Ziel:    alle Stationen
Dienste: UDP, Zielport 53
Aktion:  zurückweisen

Gruß
Backslash

[Pauli]

Servus Backslash,

ich betreibe eine normale T-Online und eine Unitymedia WAN Verbindung, also beide sollte ganz normal maskiert sein!

Allerdings werden DNS Anfragen von außen an eine meiner Ö-IP's beantwortet - getestet mit nslookup! Füge ich eine entsprechende Firewall-Regel hinzu geht es nicht mehr. Komisch finde ich jedoch, dass die Beantwortung in der Standardkonfig von außen funktioniert?!


Pauli

[backslash]

Hi Pauli,

es gab tatsächlich beim Umbau des DNS-Servers zur 8.80 einen Fehler, durch den auch Abfragen auf maskierten Verbindungen beantwortet wurden... Mittlerweile ist der gefixt. Du kannst dich also auch an den LANCOM-Suppüort wenden und eine aktuelle 8.82er Build erfragen - oder einfach die Firewall-Regeln drinlassen und auf die nächste offizielle Firmware warten...

Gruß
Backslash

[Pauli]

Danke für die Info!

Ich habe zwar schon die 8.82.0100RU1, aber wahrscheinlich hat die noch den Bug. Ich lasse nun erst mal die FW Regel drin und warte mal auf die neue LCOS Version.

Meine Regel sieht so aus und müsste doch auch das gewünschte Ergebnis bringen oder soll ich lieber Deine zwei genannten verwenden?

Code: Alles auswählen

Name:    DNS-DENY
Quelle:  alle definierten WAN Gegenstellen
Ziel:    alle Stadionen
Dienste: UDP, Zielport 53
Aktion:  REJECT

Gruß, Pauli

[backslash]

Hi Pauli,

Ich habe zwar schon die 8.82.0100RU1, aber wahrscheinlich hat die noch den Bug. Ich lasse nun erst mal die FW Regel drin und warte mal auf die neue LCOS Version.

ja, da ist der Bug noch drin...

Meine Regel sieht so aus und müsste doch auch das gewünschte Ergebnis bringen oder soll ich lieber Deine zwei genannten verwenden?

Code: Alles auswählen

Name:    DNS-DENY
Quelle:  alle definierten WAN Gegenstellen
Ziel:    alle Stadionen
Dienste: UDP, Zielport 53
Aktion:  REJECT

solange du nur verhindern willst, daß DNS über die Internet-Verbindungen aufgelöst wird, reicht das auch aus... Ich bin halt eher der Verfechter einer Deny-All-Strategie, bei der alles erwünschte explizit freigeschaltet werden muß - daher auch der Anasatz mit den zwei Regeln...

Gruß
Backslash

[Pauli]

Ich habe zwar eine Deny-All für Eingehende Verbindungen am Ende meiner Regel-Liste, aber die hat mir bei der DNS Geschichte nicht geholfen:

Code: Alles auswählen

Name:    EINGEHEND_DENYALL
Quelle:  alle definierten WAN Gegenstellen
Ziel:    LOCALNET
Dienste: ALLE
Aktion:  DROP

Ich vermute mal das Problem ist das LOCALNET oder? Da die DNS Anfragen vom Lancom selbst weitergeleitet wurden und er nicht LOCALNET ist!

Pauli

[backslash]

Hi Pauli

Ich habe zwar eine Deny-All für Eingehende Verbindungen am Ende meiner Regel-Liste, aber die hat mir bei der DNS Geschichte nicht geholfen:

Code: Alles auswählen

Name:    EINGEHEND_DENYALL
Quelle:  alle definierten WAN Gegenstellen
Ziel:    LOCALNET
Dienste: ALLE
Aktion:  DROP

Ich vermute mal das Problem ist das LOCALNET oder? Da die DNS Anfragen vom Lancom selbst weitergeleitet wurden und er nicht LOCALNET ist!

Pauli

richtig, denn die Anfragen von aussen, sind an die WAN-IP des LANCOMs gerichtet, weshalb das Ziel "LOCALNET" nicht greift... hättest du dort "ANYHOST" stehen, dann würde die Regel auch auf die DNS-Anfragen aus dem Internet matchen...

Gruß
Backslash

[Pauli]

OK+Danke, dann ist ja soweit alles geklärt und mit der neuen Software sollte der Bug dann ja wieder behoben sein!

Gruß, Pauli

[Torstinator]

Ich hol das mal wieder hoch. Ich hatte nämlich das gleiche Problem. Mit der neuen Firmware ist das Problem allerdings sofort gelöst!

Ich bin sehr froh, dass ich nun keine Post mehr von der Telekom zu diesem Thema bekommen werde.

[Hagen2000]

Hallo miteinander,

ich hole mal diesen alten Thread hoch.

Wir haben diese Woche ebenfalls eine E-Mail von der Telekom erhalten, dass wir angeblich einen open DNS Server betreiben würden.
Allerdings haben unsere eigenen Tests von außen angezeigt, dass alles in Ordnung ist.
Wir haben auch kein Port-Forwarding eingerichtet.

Unser LANCOM Router ist ein 1781VA mit FW 9.10, wobei noch ein Speedport W723V B als externer Modem via PPPoE pass through benutzt wird. Gibt es da ggf. irgendwelche bekannten Probleme?

Was macht die Telekom eigentlich? Versuchen die einfach, den Port 53 per UDP anzusprechen?

[backslash]

Hi Hagen2000

Gibt es da ggf. irgendwelche bekannten Probleme?

nein. DNS-Anfragen von maskierten Verbindungen werden verworfen... Ich hab's gerade nochmal nachgeschaut...

Was macht die Telekom eigentlich? Versuchen die einfach, den Port 53 per UDP anzusprechen?

entweder proben die der Port 53 nur und schlagen Alarm, wenn kein "ICMP port unreachable" zurückkommt oder aber sie stellen echte DNS-Anfragen und schauen, ob sie beantwortet werden. Ich schätze mal letzeres, denn sonst würde jeder, der sich an die Anleitung diverser selbsternannter Sicherheitsexperten hält und ICMPs blockt, so eine Mail von der Telekom bekommen... Außerdem kann ein fehlendes "ICMP port unreachable" ja auch einfach auf einen Paketverlust zurückzuführen sein. Daher wäre diese Methode einfach zu unsicher...

Warum sie dir allerdings so eine Mail geschickt haben, kann ich nicht sagen - es sei denn sie würden wirklich nur den Port beproben...

Gruß
Backslash

[Hagen2000]

Hallo \,

Danke für die Hinweise. Zwischenzeitlich habe ich von der Telekom auch noch eine etwas detailliertere Antwort erhalten. Letztlich werden wir die Sache nicht weiter verfolgen, was auch dem Vorschlag der Telekom entspricht, da derzeit kein Test einen offnen DNS-Port feststellen kann.