[Discuss] DNS-Amplification Attack Security Patch

Adi Kriegisch (spam-protected)
Do Jun 14 14:20:22 CEST 2012


Hallo!

>> Nein, sind wir nicht. Und ob der in OpenWRT drinnen ist oder nicht, ist
>> genau vollkommen uninteressant, weil OpenWRT auf eben die erwähnten
>> Heimnetze abgestimmt ist. (Das ist genau das gleiche Problem mit zB dem
>> QoS-Package)
> Ist es das? Das darf bezweifelt werden, denn die für Heimnetze und
> "Heimnutzer" relevanten Pakete wirst Du bei aktueller Hardware mühsam aus
> dem Trunk nachinstallieren müssen.
> Das "Produkt" OpenWRT hat ein breites Anwendungsspektrum und es steht Dir
> frei, Deine Anforderungen beim Projekt einzubringen oder einen eigenen
> Flavour zu kreieren.
Ja eh. Entweder wir reden von Images (also OpenWRT Images), dann ist
dnsmasq dabei. Oder wir reden von allen verfügbaren Packages, dann wär
X-Windows auch dabei...
Ein eigenes "Flavour" für Funkfeuer gibts ja: Backfire Vienna. Und diese
Diskussion hier hab ich so verstanden, daß es um den dnsmasq in Backfire
Vienna und dessen Konfiguration bzw. Notwendigkeit geht.
 
>>> Warum sollten wir? Richtig konfiguriert hat er mehr Vorteile als
>>> Nachteile.
>>
>> Die da wären? Ich seh nur einen Vorteil: einfachere Imageerzeugung, weil so
>> niemand was nachinstallieren muß um einen DHCP-Server zu bekommen.
> DNS-Caching, TFTP zum Flashen anderer Geräte im Netzwerksegment, ein
> Paket für all dies, ...
DNS Caching ist nett, auf den meisten Routern aber nur für die Auflösung
der Nachbar-IPs für Luci in Verwendung.
Dnsmasq hat mit tftp zum flashen anderer Geräte aber nix zu tun. Ein TFTP
Client wäre atftp; der dazu passende Server atftpd -- lediglich zum
Announcen eines TFTP Servers via Bootp wäre dnsmasq notwendig (Bootp ist
eine Art abgespecktes DHCP Protokoll).

>> Sonst eher Nachteile:
>> - schickt parallele Requests an _alle_ eingestellten DNS-Server
> 
> Dann stell halt nur einen ein oder konfiguriere es anders. Hier ist der
> Parameter:
[SNIP]
> Setze "all-servers" nicht, und er sendet nur einen Request.
...und wieder etwas, das im GUI nicht geht. Der Default für OpenWRT ist
"--all-servers".

>> - bietet -- wie wir alle sehen konnten -- eine nicht unwesentliche
>>   Angriffsfläche
> Eh klar, wenn man per Default Port 53 auf allen Interfaces aufmacht, ist
> das so, wie wenn Du den Einbrechern einen mehrsprachigen, gut sichtbaren
> Hinweis auf die Unversperrtheit Deiner Wohnung aufstellst... aber warum
> würdest Du das tun wollen?
Das ist -- bis Joes Patch -- der Default auf Backfire Vienna. Und es gibt
immer noch keine Möglichkeit, das im GUI umzustellen. Mein erster Hinweis
auf das Problem an Joe ist jetzt ca. 1 1/2 Jahre her. Diskutiert wurde das
Problem schon lange vorher im Rahmen der Freifunk-Firmware.
Zum "Problem" mit einem Lösungs-Patch ist es erst durch die DNS-Amp Attacke
gekommen.

> Es ist leicht gegen eine Sache Bashing zu betreiben, aber sachliche
> Argumente und Informiertheit wären vorzuziehen.
(...)

>> - Hat eine "kaputte" Konfiguration. "Richtig" konfigurieren geht über GUI
>>   im Moment garnicht.
> Dann implementiere es. Alle nötigen Einstellungen sind in dhcp.lua für
> LuCI und uCI-Werte liest /etc/init.d/dnsmasq aus.
> Es ist nicht wirklich umwerfend kompliziert, ich hatte es als Laie auf dem
> Gebiet in 30 Minuten. RTFM hilft.
Hmmm... das ist der beste Teil: Da gibt es eine Art Bug (oder eine
(Fehl-)Konfigurationssache) in der Backfire Vienna und bevor überhaupt klar
ist, wie eine gute Lösung dafür aussieht, soll ich irgendwas
implementieren?

>> (Und wenn wir wollen, daß die Konfiguration der Router "einfach" und "wie
>> von selbst" geht, müssten wir endlich anfangen, richtige Zonennamen zu
>> propagieren an Stelle von air0 und wan. So wird das mit dem dnsmasq nur
>> ein Knieschuß)
> Oje,...
> Besser als ein Filter ist es, den Port gar nicht erst aufzumachen. So eine
> Firewall kann einen schon in falscher Sicherheit wiegen, wenn man nicht
> weiß, was man tut.
Themenverfehlung: Hier geht es nicht um die Firewall. Falls Du schon einmal
einen Backfire-Router konfiguriert hast, sollte Dir aufgefallen sein, daß
man jedes Interface benennt und einer Zone zuordnet. Joes fix basiert auf
der "notinterface"-Option (über die wir gerne gesondert diskutieren können)
der man genau diese Zonennamen übergibt.
Wenn man nun eine AirGrid verwendet, hat die per default nach dem ersten
flashen eine Zone "air0" und eine Zone "lan". Automatisiert läßt sich diese
Situation nur mehr über IP-Adressen der Interfaces lösen und das
wahrscheinlich nicht immer zuverlässig.

>> Abgesehen davon kann jeder dieser Router auch ganz einfach andere
>> DNS-Server als dnsmasq auf localhost verwenden, indem man sie einfach in
>> /etc/resolv.conf einträg.
> Und das geht über das Interface?
> Ich dachte, man trägt das beim Interface ein und überläßt uCI den
> Eintrag?
> Btw: die Datei, die Du meinst ist /tmp/resolv.conf - die andere wird zur
> Laufzeit meines Wissens gar nicht ausgelesen.
> Du kannst das leicht auf einer Neuinstallation austesten, die statisch
> konfiguriert ist. Über eine Rückmeldung wäre ich dankbar! Es kann sein,
> dass meine Information überkommen ist.
Ja, die Datei in /tmp/resolv.conf (bzw. /tmp/resolv.conf.auto) weil
/etc/resolv.conf ist ein Symlink auf /tmp/resolv.conf und ist genau die,
die alle verwenden.
Wird der dnsmasq nicht gestartet (siehe init.d Script) wird die Datei auch
nicht überschrieben und die in /etc/init.d/boot gesetzen Werte bleiben.
(siehe /lib/network/config.sh -> Funktion add_dns()).

> Auch jeder Rechner hinter einem NAT-Gateway kann andere DNS-Server
> verwenden, wenn sie ihm der DHCP-Server liefert.
Ja, nur muß sie dann jeder manuell eintragen, was bei Notebookusern eher
auf Unverständniss stoßen dürfte.
 
> Er kann sie auch dann benützen, wenn man sie händisch einträgt. DHCP
> ist sowieso überflüssig... die User kennen die Konfiguration des
> Netzwerkes sowieso immer besser. Darum löschen sie auch ständig das
> Internet... ;->
deto.

> Darf ich aus Deinem Interesse an dem Thema schließen, dass Du gewillt
> bist, die Patches zu testen?
Nein, ich bin mit anderen Dingen befasst und habe diesem Thema bereits mehr
Zeit gewidmet, als ich sollte.

> Du bist herzlich willkommen, meine Behauptungen zu widerlegen und bessere
> Lösungswege zu finden - ich bin offen dafür.
Wie war das weiter oben doch gleich mit argumentieren und informieren?

lg Adi
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20120614/33ab3ad2/attachment.sig>


Mehr Informationen über die Mailingliste Discuss