ubuntuusers.de

Hallo,

nachdem mein IPv6 soweit funktioniert, wollte ich meine hosts.allow auch um IPv6 erweitern. ich habe für den Server aktuell eine fd00-adresse (zur 2001er-SIXXS), um im LAN einfacher drauf zu zugreifen.

nachdem, was ich bisher über google gefunden habe, müssten die Einträge so aussehen:

ALL: [::1]
sshd:  [fd00:1::/64]

localhost funktioniert nach dieser Änderung, vom Client bekomme ich aber das:

ssh fd00:1::1
ssh_exchange_identification: Connection closed by remote host

in der auth.log steht nur das:

refused connect from fd00:1::c038:a537:6551:95a2 (fd00:1::c038:a537:6551:95a2)

ifconfig (Server):

ifconfig eth0
eth0      Link encap:Ethernet  Hardware Adresse 20:cf:30:bb:68:54  
          inet Adresse:192.168.0.1  Bcast:192.168.0.255  Maske:255.255.255.0
          inet6-Adresse: 2001:xxxx:xxxx:xxxx::1/64 Gültigkeitsbereich:Global
          inet6-Adresse: fd00:1::1/64 Gültigkeitsbereich:Global
          inet6-Adresse: fe80::22cf:30ff:febb:6854/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:80285432 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56002692 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:1129696764 (1.1 GB)  TX bytes:887944866 (887.9 MB)
          Interrupt:28 Basisadresse:0xc000 

müsste doch eigentlich stimmen, oder? wenn ich hosts.allow und hosts.deny umbenenne funktioniert der Zugriff...der Fehler ist also in der hosts.* zu suchen in der hosts.deny steht nur

sshd: ALL

Das Konzept mit hosts.allow und hosts.deny ist als veraltetet zu betrachten. D.h. Dienste über iptables Schützen wenn diese nicht erreichbar sein sollen, oder nur auf den Schnittstellen lauschen lassen an welchen die Dienste auch gebraucht werden.

mfg Stefan Betz

ich habe unter v4 die hosts.allow/hosts deny zusätzlich zu den IP-Tables, weil man da nur bestimmte ip-bereiche/Provider zulassen kann...vorher hatte ich auf SSH permanent zugriffe (eigenartoge IP-Bereiche), teilweise so stark, dass ich selbst nicht mehr reingekommen bin (kam timeout). mit den IP-Tables kann man eine solche host-Basierte Lösung schwer bis gar nicht umsetzen, oder?

aktuell habe ich das drin:

ALL: 127.0.0.1/255.255.255.0
sshd:  192.168.0.0/255.255.255.0
sshd:  192.168.1.0/255.255.255.0
sshd:  134.0.24.0/21
sshd:  88.128.80.0/24
sshd:  .dip.t-dialin.net
sshd:  .t-ipconnect.de
sshd:  .customers.d1-online.com

frank-w schrieb:

…weil man da nur bestimmte ip-bereiche/Provider zulassen kann…

Natürlich kann iptables auch mit IP Ranges umgehen, kein Problem. Nur dynamisches DNS geht halt nicht, aber ganze Netze kannst du hinzufügen.

…vorher hatte ich auf SSH permanent zugriffe (eigenartoge IP-Bereiche)…

Google mal nach iptables Rate Limit, findest du auch in meinem Blog.

mfg Stefan Betz

frank-w schrieb:

... host-Basierte Lösung schwer bis gar nicht umsetzen, oder?

aktuell habe ich das drin:

sshd:  .dip.t-dialin.net
sshd:  .t-ipconnect.de
sshd:  .customers.d1-online.com

Ja, ich habe mit der "/etc/hosts.allow" auch Alles was von .cn & Co. kommt für IPv4 ausgesperrt:

sshd : 127.0 192.168.178 .dip.t-dialin.net .t-ipconnect.de .kabelbw.de .kabel-badenwuerttemberg.de : allow
sshd : ALL : deny

Funktioniert auch super,nur ipv6 ist komplett draußen...aktuell würde mir reichen ipv6 komplett zu erlauben (kann es ja per iptables dicht machen. Will ssh über v6 erstmal nur im lan nutzen.

@encbladexp: du meinst sowas in der Art (rate-limit):

1
2
3
4
5

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 600 --hitcount 2 -j DROP

http://www.debian-administration.org/articles/187

frank-w schrieb:

nachdem, was ich bisher über google gefunden habe, müssten die Einträge so aussehen:

ALL: [::1]
sshd:  [fd00:1::/64]

localhost funktioniert nach dieser Änderung, vom Client bekomme ich aber das:

ssh fd00:1::1
ssh_exchange_identification: Connection closed by remote host

in der auth.log steht nur das:

refused connect from fd00:1::c038:a537:6551:95a2 (fd00:1::c038:a537:6551:95a2)

Versuch mal mit:

ALL: [::1]
sshd:  [fd00:1::]/64

frank-w schrieb:

du meinst sowas in der Art (rate-limit)…

Genau, das macht am wenigsten Probleme und ist Wartungsfrei. ▶ Link

mfg Stefan Betz

Danke lubux, damit scheint es zu funktionieren.

jetzt kann ich mich in Ruhe daran setzen, das rate-limit umzusetzen und ggf. die hosts in die iptables mit reinzubekommen.