• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] sshd: Einschränkung ListenAddress auf Subnet

gehrke

Administrator
Teammitglied
Moin *,

ich habe ein Problem mit der sshd-Konfiguration eines Servers mit drei Netzwerk-Schnittstellen:
Code:
enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.10.7  netmask 255.255.255.0  broadcast 172.16.10.255
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.20.9  netmask 255.255.255.0  broadcast 172.16.20.255
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.22.9  netmask 255.255.255.0  broadcast 172.16.22.255
Die IPs werden von einem DHCP-Server vergeben und sind (derzeit) festgepinnt.

In der Standardkonfiguration lauscht sshd auf allen Interfaces. Ich möchte erreichen, dass er das nur auf 'enp1s0' tut.

Mir ist klar, dass ich das Ziel annähernd auch via Firewall oder tcp-wrapper erreichen kann, aber ich würde gerne schon den Daemon selber entsprechend konfigurieren.

Hierzu habe ich die Option ListenAddress gefunden und ein erster Ansatz funktioniert auch:
Code:
ListenAddress 172.16.10.7
Code:
[root@j8 /]# netstat -tulpen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name    
tcp        0      0 172.16.10.7:22          0.0.0.0:*               LISTEN      0          27926      3338/sshd
Nun würde ich aber gerne die Einschränkung etwas weiter fassen und auf alle Adressen meines Admin-Subnetzes lauschen - für den Fall, dass das Pinning auf die feste IP durch den DHCP-Server irgendwann mal nicht funktioniert.
Mein Versuch:
Code:
ListenAddress 172.16.10.0/24
Damit ernte ich diese Fehlermeldung:
Code:
Okt 02 20:06:20 j8.gehrke.local sshd[3411]: error: Bind to port 24 on 172.16.10.0 failed: Permission denied.
Okt 02 20:06:20 j8.gehrke.local sshd[3411]: fatal: Cannot bind any address.
Okt 02 20:06:20 j8.gehrke.local systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a
Scheinbar misversteht der Daemon das /24 als Port.

Wie macht man das korrekt?
TNX


cu, gehrke
 

uhelp

Member
man 5 sshd_config

Dort der Abschnitt match
Da kannst du in CIDR Notation rumfuhrwerken.

Alles was rot ist, ist falsch. (mangels strike through halt rot)

Das bezieht sich nicht auf den Server selbst.

Ich bin gar nicht auf die Idee gekommen, das auf den Server zu beziehen.
DHCP hat bei einem Server nichts zu konfigurieren. Einfach nur Unsinn.
Gib dem notfalls sogar via DHCP aber eine feste IP.

Wenn das DHCP IP-Pinning nicht geht, geht der DHCP Server nicht.
Dann isses so oder so egal.
Einfach nur Unsinn.
 

Sauerland

Ultimate Guru
Ich würde dem ssh-Server eine feste IP geben und nicht vom Router eine vorgegebene IP versenden lassen.......

Also die Netzwerkarte nicht mit dhcp konfigurieren......
 

marce

Guru
http://askubuntu.com/questions/115940/how-can-i-setup-ssh-so-that-it-is-restricted-to-my-local-network

mehr müsste ich ausprobieren.

Ansonsten - DHCP hat auch im Serverumfeld einen mehr als berechtigten Einsatzzweck. Denkt mal drüber nach, wie das aussieht, wenn man mal mehr als 2,3 Server zu verwalten hat. So in der Richtung von 1000, 2000, 40000. Und selbst bei <10 kann das durchaus sinnvoll sein.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Dank für Eure Antworten.

Auch nach etwas Reflektion bin ich weiterhin der Meinung, dass die IP-Vergabe durch den DHCP-Server für meinen Kontext die bessere Vorgehensweise ist.

Scheinbar ist ListenAddress hier die falsche Option. Ich habe nun 3 komplette Subnetze via AllowUsers eingetragen, das funktioniert:
Code:
AllowUsers *@172.16.10.0/24
AllowUsers *@172.16.11.0/24
AllowUsers *@172.16.17.0/24
Damit lauscht der Prozess zwar wieder auf alles, aber die Anmeldung aus anderen Netzen wird nun verweigert:
Code:
# netstat -tulpen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          74053      13157/sshd
TNX
 
gehrke schrieb:
...Damit lauscht der Prozess zwar wieder auf alles, aber die Anmeldung aus anderen Netzen wird nun verweigert:..

sshd listen ist nur auf Adresse möglich, nicht aber auf device.
Ich habe dieses Manko so gelöst, dass sshd auf ein TUN device mit fixer Adresse hört und dieses forwarded auf das gewünschte hardware_interface. Dazu genügt ein Einzeiler in iptables mit TUN, Port und device . Das hat viele Vorteile, weil sich dieses simple "routing" auch mit Sicherheitsmaßnahmen bestücken läßt., sofern man will. Welche Adresse das eigentliche device über z.B. dhcp erhält. spielt dann keine Rolle. Diese Lösung ist VPN ähnlich.

Gräfin Klara
 

spoensche

Moderator
Teammitglied
Gräfin Klara schrieb:
Ich habe dieses Manko so gelöst, dass sshd auf ein TUN device mit fixer Adresse hört und dieses forwarded auf das gewünschte hardware_interface. Dazu genügt ein Einzeiler in iptables mit TUN, Port und device . Das hat viele Vorteile, weil sich dieses simple "routing" auch mit Sicherheitsmaßnahmen bestücken läßt., sofern man will.

Welche Vorteile?

Zum umsetzen von Sicherheitsmaßnahmen benötigst du kein Routing.

Sicherheitsvorkehrungen Seitens SSHD:
Code:
PasswordAuthentication no
PermitRootLogin no
UsePrivilegeSeparation yes
UseStrict yes
X11Forwarding no
PubkeyAuthentication yes
PermitEmptyPasswords no
AllowTcpForwarding no

Somit sind keine Brute Force Attacken möglich und das Forwarding ist auch deaktiviert. Zusätzlich kann man jetzt noch mit
Code:
AllowUser username
Code:
AllowGroups grp1, grp2

den Zugriff nur bestimmten Usern bzw. bestimmten Usergruppen erlauben. Mittels PAM kann man diesen Usern bzw. Gruppen den Zugriff zusätzlich zeitlich begrenzen, z.B. nur von Montags-Freitags 8:00-18:00. Wenn SFTP verwendet werden darf, kann man die User z.B. noch in einen Chroot sperren.

Weiterhin sollte man das Banner deaktivieren. So verhindert man das z.B. die verwendete SSH Version ausgegeben wird und erschwert die Suche nach potentillen Exploits, sofern vorhanden.

Mittels IP-Tables und IP-Set schränkt die max. Anzahl gleichzeitiger Verbindungen in einem Zeitraum x von einer einzelnen IP ein. Wird diese überschritten wird die IP für den Zeitraum y geblockt.

Mit fail2ban kann man auch noch zusätzliche Restriktionen zum Schutz des SSH anwenden.

Gräfin Klara schrieb:
Welche Adresse das eigentliche device über z.B. dhcp erhält. spielt dann keine Rolle. Diese Lösung ist VPN ähnlich.

Man kann auch statische IP's per DHCP vergeben. Was ist den bitte VPN ähnlich? Für ein VPN fehlt in deiner Konstellation noch die feste Gegenstelle.
 
.
Ich habe darüber geschrieben, wie man ListenAddress auch bei dynamisch bezogenen Adressen verwenden kann.

spoensche schrieb:
Viele.
gehrke schrieb:
...Damit lauscht der Prozess zwar wieder auf alles, aber die Anmeldung aus anderen Netzen wird nun verweigert:..
Der Zugriff aus anderen Netzen verträgt duchaus eine policy, die über jene einer sshd Konfiguration hinausgeht. Meinst du nicht auch?
Wenigsten das DROP aller ports nicht sshd. Wenn man will. TUN existiert NUR für den sshd, optimal für eine individuelle sshd policy.

Freilich geht es auch einfacher, z.B. mit einer statischen alias IP nach der Zuteilung der dynamischen vom dhcp.
Aber das ist keine policy routing Struktur und für den Zugriff aus anderen Netzen nicht empfehlenwert.
Deshalb habe ich als mögliche Lösung ein virtuelles device mit statischer IP vorgeschlagen.

spoensche schrieb:
Zum umsetzen von Sicherheitsmaßnahmen benötigst du kein Routing.
Nein, dafür benötigt man kein routing ... aber darüber habe ich auch gar nicht geschrieben.

spoensche schrieb:
Was ist den bitte VPN ähnlich?
Für ein VPN fehlt in deiner Konstellation noch die feste Gegenstelle.
Ich habe deshalb darauf hingewiesen, weil man dort die rules für das forwarding virtueller devices finden kann.
Das hat nichts mit Sicherheiten oder einer "festen Gegenstelle" zu tun.

Gräfin Klara
 

spoensche

Moderator
Teammitglied
Gräfin Klara schrieb:
.
spoensche schrieb:
Viele.

Nenn mal ein paar. Würde mich schon interessieren.

gehrke schrieb:
...Damit lauscht der Prozess zwar wieder auf alles, aber die Anmeldung aus anderen Netzen wird nun verweigert:..

Gräfin Klara schrieb:
Freilich geht es auch einfacher, z.B. mit einer statischen alias IP nach der Zuteilung der dynamischen vom dhcp.
Aber das ist keine policy routing Struktur und für den Zugriff aus anderen Netzen nicht empfehlenwert.
Deshalb habe ich als mögliche Lösung ein virtuelles device mit statischer IP vorgeschlagen.

Du brauchst keine Alias IP, wofür? Ausserdem kannst du mittels Forwarding Regeln genau definieren aus welchem Netz der Zugriff auf Port 22 erlaubt ist.

Policy routing ist, wie der Name schon sagt fürs Routing und nicht für einen einzelnen Dienst. Mittels Policy Routing kannst du für jedes Netz eine eigene Routing Tabelle verwenden und das Routing zu diesem Netz über Rules definieren. Mittels Policy Routing kann man z.B. den Traffic auch load balanced über zwei Internet Anschlüsse verteilen.

Du verwechselst hier etwas.

Gräfin Klara schrieb:
spoensche schrieb:
Zum umsetzen von Sicherheitsmaßnahmen benötigst du kein Routing.
Nein, dafür benötigt man kein routing ... aber darüber habe ich auch gar nicht geschrieben.

spoensche schrieb:
Was ist den bitte VPN ähnlich?
Für ein VPN fehlt in deiner Konstellation noch die feste Gegenstelle.
Ich habe deshalb darauf hingewiesen, weil man dort die rules für das forwarding virtueller devices finden kann.
Das hat nichts mit Sicherheiten oder einer "festen Gegenstelle" zu tun.

Forwarding hat nichts mit einem VPN zu tun. Ein virtuelles Device muss nicht zwangsläufig für VPN verwendet werden. Es kann auch für Container etc. verwendet werden.
 
Oben