mit iptables Anmeldungen für root aussperren

[mat6937]

Der Rückkanal wird mehr oder weniger zufällig erzeugt.

Was meinst Du mit Rückkanal? Der destination-Port den der ssh-Server für seine syn-ack-Verbindung/Antwort benutzt, ist der source-Port den der ssh-Client (oder der Router, falls einer benutzt wird und wenn dieser auch Port-NAT macht) dem ssh-Server mitgeteilt hat.

[JTH]

Der destination-Port den der ssh-Server für seine syn-ack-Verbindung/Antwort benutzt, ist der source-Port den der ssh-Client […] dem ssh-Server mitgeteilt hat.

Völlig richtig. Es wäre für den Server auch gar nicht möglich, dem Client auf einem zufälligen/beliebigen von dessen Ports zu antworten:

Der wird immer "zufällig" von deinerm SSH-Server vergeben.

[MSfree]

Der wird immer "zufällig" von deinerm SSH-Server vergeben.

Ja Sorry, war mein Denkfehler. Der Client schickt diesen Port mit, auf dem der Server zu antworten hat. Daß diesee Portnummer mehr oder weniger zufällig erzeugt wird, und daß das der Rückkanal ist, ist trotzdem nicht falsch.

[JTH]

Der Client schickt diesen Port mit, auf dem der Server zu antworten hat. Daß diesee Portnummer mehr oder weniger zufällig erzeugt wird, und daß das der Rückkanal ist, ist trotzdem nicht falsch.

Jo, das ist ebenfalls richtig

When connect(2) is called on an unbound socket, the socket is automatically bound to a random free port […].

Der Server schickt, wie mat6937 geschrieben hat, seine Antworten auf den Port, der in den Nachrichten des Clients als eben dieser zufällige Source-Port angegeben ist.

[mat6937]

... auf den Port, der in den Nachrichten des Clients als eben dieser zufällige Source-Port angegeben ist.

Ja, und wenn man auf ssh-Client-Seite einen Router hat, der kein Port-NAT macht, kann man mit Hilfe einer iptables-Regel (oder gleichwertig) aus diesem zufälligen Source-Port einen festen Source-Port (im Beispiel der Port 39857) machen. Z. B.:

Code: Alles auswählen

iptables -t nat -I POSTROUTING 1 -o eth0 -p tcp -d <IP-sshd-server> --dport 22 -m state --state NEW -j SNAT --to-source <interne-IP-ssh-Client>:39857

Diesen festen und nur dem eigenen ssh-Client bekannten Source-Port, kann man dann auf sshd-Server-Seite, zum filtern der Anmeldeversuche benutzen.

[mat6937]

Schau' einfach mal auf meinen log-Ausschnitt...

BTW: Vermeidbarer Ressourcen-verbrauch entsteht auch dadurch, dass Du unberechtigte Anmeldeversuche loggst. Deshalb habe ich nie fail2ban benutzt.
Wenn Du deinen sshd-Dienst richtig konfiguriert hast, den Zugang richtig filterst und ausreichend getestet hast, kannst Du das loggen auch deaktivieren.
Portscanns aus dem Internet zu deinem "border device" (Router mit oder ohne weitergeleiteten v4-Ports bzw. freigegebenen v6-Ports), kannst Du eh nicht verhindern.

[MSfree]

Diesen festen und nur dem eigenen ssh-Client bekannten Source-Port, kann man dann auf sshd-Server-Seite, zum filtern der Anmeldeversuche benutzen.

Nein, kann man nicht. Der Port ist eben nicht fest, auch dann nicht, wenn man kein NAT dazwischen hat.

[Tintom]

Diesen festen und nur dem eigenen ssh-Client bekannten Source-Port, kann man dann auf sshd-Server-Seite, zum filtern der Anmeldeversuche benutzen.

Nein, kann man nicht. Der Port ist eben nicht fest, auch dann nicht, wenn man kein NAT dazwischen hat.

Korrekt. Und genau das meint @mat6937 hier: Wenn man dem ssh-clienten einen Sourceport zuweist, kann man serverseitig nur eben die Verbindungen erlauben, die von dem definierten Sourceport kommen.

[MSfree]

Wenn man dem ssh-clienten einen Sourceport zuweist

Wie soll das gehen?

Du kannst zwar serverseitig den Listen-Port zuweisen (Default = 22), aber clientseiteg kann der Answer-Port meines Wissens nicht festgenagelt werden. Da wird bei jeder neuen SSH-Verbindung eine neue Portnummer verwendet.

[uname]

Also ich verstehe die ganze Diskussion nicht. Wenn man von außen den Port 22 frei gibt, dann muss man auch Angriffe erwarten.
Also einfach einen anderen Port verwenden oder den Port gar nicht erlauben.

Erstens ist bei mir ein root-login sowieso nicht möglich, aber zweitens kommen diese Versuche laut log auch nicht nur auf dem SSH-Port, sondern auf "irgendwelchen" Ports.

Der Zugriff geht natürlich auf deinen Port 22, denn nur dort horcht dein SSH-Server. Der angezeigte Port ist wahrscheinlich der Client-Port des "Angreifers". Insgesamt ergeben IP-Client:Port>1024 und Server:22 einen Socket.

Soll denn überhaupt SSH-Zugriff aus dem Internet möglich sein?
Kannst du den Server-Port nicht ändern?
Fail2Ban ist doch nur eine Krücke und bekämpft nur die Symptome und nicht die Ursachen.

[bluestar]

Wie muss man das verstehen?

Ich passe einfach die Freigabe des Ports meines Nutzungsumfeldes an, beispielsweise halte ich mich einfach nicht in China auf und dementsprechend ist es schlicht nicht nötig den SSH-Server von China aus erreichbar zu haben.

Benutzt Du dann ein VPN (oder gleichwertig) für den weltweiten Zugriff auf deinen ssh-Server?

Ganz genau

[Tintom]

Wenn man dem ssh-clienten einen Sourceport zuweist

Wie soll das gehen?

Du kannst zwar serverseitig den Listen-Port zuweisen (Default = 22), aber clientseiteg kann der Answer-Port meines Wissens nicht festgenagelt werden. Da wird bei jeder neuen SSH-Verbindung eine neue Portnummer verwendet.

Etwa so:
ssh -o 'ProxyCommand nc -p 32122 %h %p' tintom@localhost
Der Server meldet dann:
<...>
Mar 01 13:25:43 localhost sshd[24021]: Accepted publickey for tintom from ::1 port 32122 ssh2: (...)
<...>

[mat6937]

Wie soll das gehen?

Ich habe weiter oben, mit der iptables-Regel doch gezeigt wie das geht. Und glaube mir, bevor ich so etwas hier schreibe, habe ich das doch in meinen Konstellationen, erfolgreich getestet.

Du kannst zwar serverseitig den Listen-Port zuweisen (Default = 22), aber clientseiteg kann der Answer-Port meines Wissens nicht festgenagelt werden. Da wird bei jeder neuen SSH-Verbindung eine neue Portnummer verwendet.

Nein. Ein answer-Port gibt es nur auf dem Server (RELATED-/ESTABLISHED-Verbindungen) und nicht auf dem Client, denn der Client ist derjenige, der mit seinem source-Port die Verbindung anstoßt/initiiert (NEW-Verbindung). Und schon deshalb kann sich auf Clientseite der Port, für den antwortenden Server nicht ändern, ... weil wenn das der Fall wäre, zu welchem Client-Port soll dann die Antwort vom Server gehen? Du kannst es ja selber testen.

[mat6937]

Ich passe einfach die Freigabe des Ports meines Nutzungsumfeldes an, beispielsweise halte ich mich einfach nicht in China auf und dementsprechend ist es schlicht nicht nötig den SSH-Server von China aus erreichbar zu haben.

Hmm, ... da verstehe ich nicht, was Du damit sagen willst.

Ganz genau

OK, das ist jetzt aber eine andere Konstellation (als die des TE), die ich nur aus Gründen der Redundanz auch benutze. D. h. aber nicht, dass eine richtig konfigurierte/optimierte ssh-Verbindung über das Internet, nicht genau so sicher, komfortable und Ressourcen schonend ist, wie eine ssh-Verbindung innerhalb eines VPN. Aber OK, jeder wie er mag.

[MSfree]

Ich habe weiter oben, mit der iptables-Regel doch gezeigt wie das geht.

Das, was du gezeigt hast, geht nicht, bzw. nur zufällig mal.

Nein. Ein answer-Port gibt es nur auf dem Server (RELATED-/ESTABLISHED-Verbindungen) und nicht auf dem Client

Es mag ja sein, das ich nicht die korrekte Fachterminologie benutze, aber der Answerport existiert schon, wenn das erste Netzwerkpaket vom Client zum Server geschickt wird. Und genau dieser Port ist nicht konstant. Jegliche iptables-Regel ist hier also komplett sinnlos.

OK, Tintoms Versuch mit netcat könnte klappen.

[uname]

Der Client-Port (>1023) wird vom Client vorgegeben. Einfach mal nach AF_INET-Sockets suchen.

[mat6937]

Und genau dieser Port ist nicht konstant. Jegliche iptables-Regel ist hier also komplett sinnlos.

Der Port den der ssh-Client wählt ist nicht konstant, aber der Port der durch die source-NAT-Regel festgelegt wird ist konstannt (wenn der Router kein Port-NAT macht), und nur dieser konstante Port (aus der source-NAT-Regel) wird dem Server mitgeteilt. Zu diesem Port geht dann auch die Antwort vom Server. Du kannst es testen.

[mat6937]

Der Client-Port (>1023) wird vom Client vorgegeben.

Das ist richtig und keiner hat das Gegenteil behauptet. Aber schau mal, was die source-NAT-Regel macht bzw. was sie bewirkt.

[bluestar]

Hmm, ... da verstehe ich nicht, was Du damit sagen willst.

Ganz einfach: Der SSH Port ist einfach nicht weltweit erreichbar, sondern nur aus Ländern/IP-Bereichen, wo ich mich aufhalte.

Für mich ist ein SSH Server schlicht kein öffentlicher Dienst und daher auch nicht uneingeschränkt öffentlich erreichbar.

[mat6937]

Der SSH Port ist einfach nicht weltweit erreichbar, sondern nur aus Ländern/IP-Bereichen, wo ich mich aufhalte.

OK und mit welchem Verfahren/Tool/Konfiguration hast Du diese Einschränkung gemacht?

Für mich ist ein SSH Server schlicht kein öffentlicher Dienst und daher auch nicht uneingeschränkt öffentlich erreichbar.

Naja, das ist er bei mir auch nicht (d. h. kein öffentlicher Dienst). Aber es ist ja ein Unterschied, ob jeder Zugriff auf den lauschenden Port meines sshd hat oder ob _nur ich_ (weltweit) von _jedem (auch fremden) existenten/vorhandenen_ Internetanschluss auf meinen sshd zugreifen kann/will.

[bluestar]

OK und mit welchem Verfahren/Tool/Konfiguration hast Du diese Einschränkung gemacht?

Ich verwende Shorewall als iptables-Frontend und die Liste https://www.iana.org/assignments/ipv4-a ... pace.xhtml um den Port zu blockieren.

Aber es ist ja ein Unterschied, ob jeder Zugriff auf den lauschenden Port meines sshd hat oder ob _nur ich_ (weltweit) von _jedem (auch fremden) existenten/vorhandenen_ Internetanschluss auf meinen sshd zugreifen kann/will.

Für mich ist diese "weltweiter Zugriff auf den SSH-Port" eine theoretische Option, da ich nunmal eben nicht täglich weltweit unterwegs bin.

[Tintom]

Halten wir mal zusammenfassend fest:
wenn @dirk11

• mittels GeoIP-Filter die Adressbereiche herausfiltert, von denen er keine Verbindung zu seinem sshd zulassen will und/oder
• mittels --sport den Verbindungsaufbau von einem spezifischen Port eines Clienten aus zulässt

kann er sich das Sperren/Blockieren von Anmeldungen (Ausgangsfrage) sparen.

Eine Lösung mit fail2ban hat er wohl schon verworfen(?).

[wanne]

Also um es zu verdeutlichen/zusammen zu fassen:
Ja man könnte einen ssh clienten Bauen, der den "anderen" Port fest wählt. Oder es an einen vorhandenen SSH per Proxy/firewall dran bauen. Es sollte aber auch klar sein, dass dann nur noch eine SSH-Verbindung aufgemacht werden kann. Deswegen macht das keiner.

Ansonsten:
1. Du kannst nicht nach User filtern, weil SSH ein verschlüsseltes Protokoll ist und entsprechend nur den SSH-Server mit seinem Schlüssel entschlüsseln kann. Mit einer DPI Firewall könntest du den Clients gefälschte Schlüssel unterschieben. ssh würde davor mit dieser Warnung waren.

Code: Alles auswählen

The authenticity of host 'example.com (42.42.24.24)' can't be established.
ECDSA key fingerprint is SHA256:ASDF123YGHH0976434DFFFF.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Die willst du selbstverständlich nicht ignorieren, weil dann auch jeder andere Server mitlesen könnte. (Das ist ein bisschen anders wenn du keine Passwörter sondern Keys nutzt. Da hat SSH alternative Sicherheitsmethoden und du kannst das ignorieren, wenn du deine öffentlichen Schlüssel geheim hältst.)
2. Es gibt keine offiziellen Länderlisten. Nur Sammlungen von Werbenetzwerken und whois Daten. (Z.B in form von geoip-database.) Ich hatte mal einen Provider der Privatsphäre ernst genommen hat und die Standorte seiner Nutzer nicht verkauft hat und wurde dann konsequent als russisch eingestuft. Insbesondere nervig bei Google-Diensten... Das dürfte allerdings die absolute Ausnahme sein. Was es gibt sind Zuweisungen nach Kontinent. – Leider sind die noch öfter falsch, weil viele gerade viele Europäer und Asiaten Afrikanern und seltener Amerikanern IPs abkaufen, weil es abseits von Afrika keine neuen IPv4s mehr gibt und viele Amerikaner auf nem riesen Haufen sitzen, den sie nicht nutzen. So liegen die IPv4-Adressen von amazon.de z.B. in Afrika und debianforum.de in Nordamerika.
3. Eigentlich gibt es keinen Grund für das Blocken, wenn man eh keine Passwörter zulässt bzw. stark genug hat, dass die durch ausprobieren nicht erratbar sind. Wenn einen die logs stören, schaltet man die ab. Die Ressourcen, die die meisten dynamischen lösungen brauchen sind größer als das, was sie sparen.

Ich verwende Shorewall als iptables-Frontend und die Liste https://www.iana.org/assignments/ipv4-a ... pace.xhtml um den Port zu blockieren.

? Das ist die Liste ALLER öffentlichen IP Adressen nach RIR. Du kannst damit weder Ports blockieren noch sinnvoll filtern, weil ja alle keine Einschränkung sind.

[DeletedUserReAsG]

Halten wir mal zusammenfassend fest:
wenn @dirk11

mittels GeoIP-Filter die Adressbereiche herausfiltert, von denen er keine Verbindung zu seinem sshd zulassen will und/oder
mittels --sport den Verbindungsaufbau von einem spezifischen Port eines Clienten aus zulässt

kann er sich das Sperren/Blockieren von Anmeldungen (Ausgangsfrage) sparen.

Eine Lösung mit fail2ban hat er wohl schon verworfen(?).

Er kann auch einfach den Port für ssh in den fünfstelligen Bereich legen, und wird fortan keine Verbindungsversuche mehr darauf haben. Entgegen seiner eigenen Darstellung scheint das ja nicht gemacht worden zu sein.

[dirk11]

Also ich verstehe die ganze Diskussion nicht.

Ich kann aufklären (stand aber auch schon im thread):
Ich bin davon ausgegangen, daß das Zugriffe von außen auf diese Ports sind (was ich in Gänze nicht verstanden habe, weil das ja eigentlich unmöglich ist, sich aber dadurch aufgeklärt hat, daß es der von innen vergebene "Antwort-Kanal" ist - auf die Idee bin ich einfach nicht gekommen, obwohl mir das Funktionsprinzip natürlich von diversen anderen Protokollen bekannt ist).

Soll denn überhaupt SSH-Zugriff aus dem Internet möglich sein?

Sonst hätte ich wohl kaum ein port-forwarding im Router eingerichtet.

Kannst du den Server-Port nicht ändern?

Gibt es schon, aber ich hatte schon Situationen, wo das nicht ging, sprich ich auf umgelegte Ports ausgehend aus dem Netz, in welchem ich mich befand, nicht kam.

Fail2Ban ist doch nur eine Krücke und bekämpft nur die Symptome und nicht die Ursachen.

Ja. Das will ich ja auch gar nicht. Irgendwas ist wohl an meiner iptables-Zeile mit dem hitcount noch verbesserungsfähig.