Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

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

Alles rund um die Server (Web-, Mail-, Datenbank-, Datenaustausch-, etc.) die man unter Linux betreiben kann

Moderator: Moderatoren

Antworten
Benutzeravatar
gehrke
Moderator
Moderator
Beiträge: 1807
Registriert: 10. Nov 2012, 11:00
Wohnort: Münsterland

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

Beitrag von gehrke » 2. Okt 2016, 20:16

Moin *,

ich habe ein Problem mit der sshd-Konfiguration eines Servers mit drei Netzwerk-Schnittstellen:

Code: Alles auswählen

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: Alles auswählen

ListenAddress 172.16.10.7

Code: Alles auswählen

[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: Alles auswählen

ListenAddress 172.16.10.0/24
Damit ernte ich diese Fehlermeldung:

Code: Alles auswählen

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

Werbung:
uhelp
Member
Member
Beiträge: 89
Registriert: 25. Nov 2012, 19:33

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von uhelp » 2. Okt 2016, 22:11

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.
Zuletzt geändert von uhelp am 2. Okt 2016, 22:20, insgesamt 1-mal geändert.

Sauerland
Guru
Guru
Beiträge: 3087
Registriert: 5. Aug 2007, 17:57
Wohnort: Sauerland

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von Sauerland » 2. Okt 2016, 22:17

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......
Desktop: OpenSUSE Leap 42.3, Nvidia-Grafik Kernel 4.4
Laptop: OpenSUSE Leap 42.3, Intel-Skylake, Kernel 4.x, Windows 10

marce
Advanced Hacker
Advanced Hacker
Beiträge: 1022
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von marce » 3. Okt 2016, 09:56

http://askubuntu.com/questions/115940/h ... al-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.

Benutzeravatar
gehrke
Moderator
Moderator
Beiträge: 1807
Registriert: 10. Nov 2012, 11:00
Wohnort: Münsterland

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von gehrke » 3. Okt 2016, 16:29

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: Alles auswählen

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: Alles auswählen

# 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

Gräfin Klara
Hacker
Hacker
Beiträge: 314
Registriert: 23. Jun 2008, 20:51

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von Gräfin Klara » 3. Nov 2016, 15:22

gehrke hat geschrieben:...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
Moderator
Beiträge: 7338
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von spoensche » 12. Nov 2016, 14:36

Gräfin Klara hat geschrieben: 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: Alles auswählen

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: Alles auswählen

AllowUser username

Code: Alles auswählen

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 hat geschrieben: 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.

Gräfin Klara
Hacker
Hacker
Beiträge: 314
Registriert: 23. Jun 2008, 20:51

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von Gräfin Klara » 12. Nov 2016, 18:37

.
Ich habe darüber geschrieben, wie man ListenAddress auch bei dynamisch bezogenen Adressen verwenden kann.
spoensche hat geschrieben: Welche Vorteile?
Viele.
gehrke hat geschrieben: ...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 hat geschrieben: 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 hat geschrieben: 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
Moderator
Beiträge: 7338
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: sshd: Einschränkung ListenAddress auf Subnet

Beitrag von spoensche » 13. Nov 2016, 18:47

Gräfin Klara hat geschrieben:.
spoensche hat geschrieben: Welche Vorteile?
Viele.
Nenn mal ein paar. Würde mich schon interessieren.
gehrke hat geschrieben: ...Damit lauscht der Prozess zwar wieder auf alles, aber die Anmeldung aus anderen Netzen wird nun verweigert:..
Gräfin Klara hat geschrieben: 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 hat geschrieben:
spoensche hat geschrieben: 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 hat geschrieben: 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.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste