Re: Freie Namenswahl für Router (war: NFS-Mount geht nicht beim Hochfahren)

[Thomas Michalka <Thomas.Michalka@gmx.de>]

Am Tue, 31 May 2016 20:40:14 +0200 schrieb Jochen Spieker (Jochen
Spieker <ml@well-adjusted.de>):

> Thomas Michalka:
> > Am Mon, 30 May 2016 13:14:06 +0200 schrieb Jochen Spieker (Jochen
> > Spieker <ml@well-adjusted.de>):
> >> 
> >> Mein Punkt ist, dass der DHCP-Server in der Fritzbox den Clients
> >> mitteilt, dass sie in der Domain '.box' (oder 'fritz.box') leben.
> >> Das will ich nicht.
> >>
> >> …
> >> 
> >> Der Nameserver ist halt normalerweise gerade die Fritzbox.
> > 
> > In der Anleitung (Kap. 12.8, S. 91) finde ich gerade, dass sie einen
> > DNS-Proxy hat. Das heißt nicht, dass sie die vom DHCP zugeteilten
> > Hostnamen in die Namensverwaltung übernimmt.
> 
> Tut sie aber. Sie löst sogar die automatisch erkannten Geräte im
> Heimnetz auf, selbst wenn die von der Fritzbox gar keine IP-Adresse
> per DHCP angefragt haben:

Dann haben sie wohl auch keinen Namen per DHCP erhalten. Woher weiß
dann die FRITZ!Box überhaupt von diesen Geräten? Auch der Name-Server
vergibt nicht eigenmächtig Namen. Woher erfährt der die Namen, bzw. wer
setzt die Namen?

> $ dig jigsaw.fritz.box @fritz.box
> …
> ;; ANSWER SECTION:
> jigsaw.fritz.box.       9       IN      A       172.16.27.5

Das gibt nur die Sichtweise der FRITZ!Box bzw. deren Name-Server
wieder. Das heißt nicht, dass die Box die Host-Names (FQHNs) bzw.
die FQDNs im LAN verteilt.

> $ dig -x 172.16.27.5
> …
> ;; ANSWER SECTION:
> 5.27.16.172.in-addr.arpa. 0     IN      PTR
> jigsaw.home.well-adjusted.de.

Wer genau antwortet denn auf die Reverse-Anfrage? Steht im letzten
Absatz nach ;; SERVER:, z.B.:
;; SERVER: <IP-Adresse>#53(<IP-Adresse>)

Vielleicht ist da noch ein weiterer Name-Server im Spiel.

> Ich meine, ich habe die Einstellung im Web-UI auch schon mal
> ausprobiert. Habe nur keine Lust, das nochmal zu machen, weil das die
> erwähnte Liste von Konfigurationen ändert und ich dann alles wieder
> zurückändern muss.

Na ja, wer etwas ändern will, muss Änderungen akzeptieren.

> >> Ja, ach. DHCP/DNS für ein Heimnetz nähme ich schon gern aus der
> >> Schachtel.

Man kann freilich alles mögliche konfigurierbar machen, aber ich
vermute, dass es über 80 % der FRITZ!Box-Nutzer egal ist, welche FQDN
im LAN benutzt wird.

> > Wie viele Rechner betreibst du denn parallel? Falls es nur ein paar
> > sind, würde doch DHCP (ohne DNS-Service) für die weniger gut oder
> > oft gar nicht konfigurierbaren Geräte, wie Mobilgeräte genügen. Es
> > gibt z.B. einen Multi-Shell-SSH-Client […]
> 
> Du bietest hier sehr viele komplizierte Lösungen für ein Problem, das
> die Fritzbox trivial lösen könnte, wenn AVM denn wollte. Ist nett,
> aber an der Problemstellung in meinen Augen völlig vorbei.

Ich habe schon verstanden, dass Dein Kernproblem ist, dass Du sie so
einstellen willst, dass die Box eben Deine lokale Wunsch-Domain benutzt.
Dann wäre alles gut, weil alle Hosts dann den DNS in der Box nutzen
könnten. Da anscheinend kein Mitdiskutant bisher sagen konnte, *wie* man
das ändert (nur, *dass* es bei manchen anscheinend anders ist -- wer
weiß, warum?) und ich in der Anleitung der 7490 auch keine Möglichkeit,
den DNS direkt zu konfigurieren, gefunden habe, habe ich Workarounds
vorgeschlagen. Wenn Du so es so nennen willst, dass sie am Problem
"vorbeigehen" -- nun ja, genau das ist das Wesen eines Workarounds,
nämlich die Umgehung des Problems, nicht dessen Lösung oder
Überwindung. Man könnte auch sagen, dass es sich um eine _andere Lösung_
handelt ;-)

Ob diese Workarounds kompliziert sind oder nicht, das will ich nicht
diskutieren. Ich sehe das eher pragmatisch und betrachte daher den
Aufwand, und der ist mit dem zentralen Editieren der zwei Dateien
/etc/hosts und /etc/resolv.conf und dem automatischen Verteilen
auf alle LAN-Hosts objektiv gering (nur bei neuen Hosts diese
in /etc/hosts eintragen), zumal, wenn man es mit dem Nutzen
(Wunsch-FQDN und keinen Ärger mehr) vergleicht.

> Meine Frage war, ob jemand konkret weiß, ob man bei einer Fritzbox
> dafür sorgen kann, dass per DHCP eine eigene Domain an die Clients
> verteilt wird.

Wie gesagt, einige haben sinngemäß so geantwortet, dass bei Ihnen die
FQDN fritz.box nicht eingestellt ist, bzw. dass sie eine eigene FQDN
verwenden. Das muss nicht heißen, dass sie die FRITZ!Box anders
einstellen können, sondern kann auch daran liegen, dass sie in
der /etc/resolv.conf ihrer Hosts nicht die IP-Adresse der FRITZ!Box
eingetragen haben, sondern die eines anderen Name-Servers (eines lokalen
oder die des Providers) und/oder die /etc/hosts zur Auflösung der
Hostnamen im LAN benutzen. Soll doch die FRITZ!Box meinen, was sie
will! Und soll doch ihr Name-Server laufen wie er will, obwohl er von
keinem LAN-Host befragt wird! Hauptsache, die Hosts, mit denen man
arbeitet, kennen die Namen der anderen Hosts, und sie können ihre
IP-Adressen auflösen -- auch ohne Name-Server. Hat auch den Vorteil,
dass er ausfallen kann, ohne Auflösungsprobleme im LAN zu verursachen.

> Zu den Clients:
> 
> $ wc -l /tmp/dhcp.leases 
> 16 /tmp/dhcp.leases
> 
> Und da fehlen wahrscheinlich noch ein paar, die gerade nicht an/da
> sind. Linux, manchmal Windows gebootet, Android, iOS, Fernseher,
> Sonos, Drucker, PS3, HomeMatic.  Nein, die muss ich nicht zwingend
> alle ständig per DNS ansprechen. Mich ärgern aber halbe Lösungen.

Dann brauchst Du einen detaillierter konfigurierbaren Router (mit DHCP
und DNS u.s.w.) als die 7490. Aber dann ist es Dir vielleicht wieder zu
kompliziert (wie meine Workarounds). Gut für Dich wäre vermutlich ein
Mittelweg, aber woher soll AVM wissen, welcher für Dich der richtige
wäre?

> > Und warum willst Du das kleine OpenWRT-Ding nicht, z.B. als inneren
> > Router, um Dein übriges LAN von dem Internet-Server sicher zu
> > trennen?
> 
> Wozu? Der Paketfilter in der Fritzbox funktioniert. Auch mit v6.

Kurz: um zusammen mit der FRITZ!Box eine DMZ zu bauen.

Ein Paketfilter ist gut, aber da Du den Port 80 für einen öffentlich
erreichbaren Server weiterleitest, besteht IMO ein nicht geringes
Risiko, dass mit einer ausgenutzten Sicherheitslücke auf Deinem Server
dieser, dann vielleicht Dein LAN und per Rückwärts-Angriff vom Server
dann auch noch Dein Router kompromittiert wird. Nach dem Motto: Haste
einen, haste alle!

Deshalb sind zwei unabhängige Paketfilter mit einer DMZ dazwischen viel
sicherer, gerade, wenn man einen öffentlich erreichbaren Server
betreibt (dann in der DMZ).

> Wenn
> ich Ernst machen wollte, würde ich im Switch VLANs konfigurieren, aber
> ich will mir das Leben zu Hause nicht unnötig schwer machen.

VLAN würde Deine LAN-Rechner nur schützen, solange ein Angreifer nur
Deinen Server kompromittiert hat. Deine anderen LAN-Hosts würde er vom
Server aus dann nicht sehen (aber den Router schon!). IMHO braucht es
dazu aber keine VLAN-Konfiguration auf der FRITZ!Box, sondern die
Ethernet-Ports dürften nicht geswitched werden. Den Ports müssten
unterschiedliche Netze (z.B. 192.168.1.0 für den Server u. 192.168.23.0
für das restliche LAN) zugewiesen werden, zwischen denen dann auch nicht
geroutet wird (kann aber sein, dass das bei der 7490 nur mittels VLAN
geht). Das ist aber dann nicht sinnvoll, wenn Du auf demselben Rechner
noch interne Dienste fürs LAN betreibst.
Aber genau das würde ich aus den o.g. Gründen nicht machen.

> Am Ende
> müsste ich eh alles mögliche durchlassen, der "Internet-Server" bietet
> außer 22+80 ins Internet nichts an,

Ja, eben nur die! Wieso dann alles mögliche durchlassen? Entscheidend
ist doch, dass man von einem SSH- und HTTP-Server in einer DMZ nicht in
Dein LAN käme, wenn Du auf Deinem inneren Paketfilter keine Ports
weiterleiten lässt.

> von innen leuchtet das Teil aber wie ein Tannenbaum.

Aha, das sind dann Dein internen Dienste auf _demselben_ Host; habe ich
oben so noch nicht gelesen. Dann würde Dir eine Abschottung durch VLAN
auch nichts nützen, weil Du die Server-Dienste aus Deinem LAN nicht
erreichen könntest, wenn zwischen den VLANS nicht geroutet wird. Wenn
aber geroutet werden muss, wozu dann VLANs?

Außerdem haben Angriffe auf der Anwendungsebene (z.B. über bösartigen
Javascript-Code in HTML-Seiten, die du selber holst) viele offene Türen
auf Deinem Server, was durch Paketfilter nicht zu vermeiden ist. Wenn
die Angreifer erst einmal dort sind, könnten Sie einen eigenen Account
einrichten und sich auf dem Server über Port 22 per SSH von außen
regulär einloggen, ohne dass Du das gleich merkst.

Bei einem Grenznetz (DMZ) ist das ungleich schwerer, weil man bei dem
geschilderten Angriffsszenario über die Anwendungsschicht von innen erst
einmal den inneren Router kapern müsste, um dort eine unauffällige
Port-Weiterleitung für einen permanenten Zugang von außen einzurichten.
Solche Veränderungen würden aber auch eher auffallen und außerdem hat
man damit noch nicht den äußeren Router geknackt, um dort denselben
Port weiterleiten zu lassen.
Bei Dir ist es ungleich einfacher, weil auf dem Server nur ein
unauffälliger Account einzurichten wäre (damit der Angreifer sich
nicht gleich als root anmelden muss). Für den Zugang über offene Ports
im Router hast Du selber schon gesorgt. Ich an Deiner Stelle würde
wenigstens den SSH-Port auf einen andere Nummer setzen.

Das Wichtigste wäre in meinen Augen aber die Trennung Deiner externen
Dienste von den internen, wenigstens durch Virtualisierung auf der
Hardware.
Völlig Sicherheit wird man nie erreichen, aber wie bei Einbrüchen
in Wohnungen kommt es darauf an, den Angreifern so viele Steine in den
Weg zu legen, dass möglichst alle früher oder später aufgeben, weil mit
der Angriffs- bzw. Einbruchsdauer das Entdeckungsrisiko stark zunimmt.

VG, Tom