debianforum.de

Verfasst: **28.02.2022 12:26:17**

Hi Leute,

etwas mißverständliches topic, aber muss ja kurz bleiben.

Situation:
Ich habe einen privaten Server laufen. Seit Ewigkeiten bekomme ich bei der Telekom nur noch sehr selten eine neue IPv4, wenn ich die Verbindung trenne. Ist ja prinzipiell begrüßenswert. Aber:
Mich nervt im /var/log/auth.log, daß es unzählige ssh-Anmeldeversuche für den User root gibt.
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.

Rein kommt also sowieso niemand, aber - Frage! - haben diese lästigen Versuche nicht außer kosmetischen (=Eintrag im log) auch andere Auswirkungen? Also beispielsweise eine höhere Latenz in meiner Internet-Verbindung oder sowas in der Art? Immerhin ist so ein Anmelde-Versuch ja auch traffic (wenn auch nur gering)?

Wie müsste eine Regel lauten, welche die Quell-IP z.B. für 10min sperrt, wenn sie versucht, eine Anmeldung als root zu machen? Am besten noch die gesamte IP-range, also alle 112.85.42.XXX wie hier im Beispiel, weil tatsächlich nach einer gewissen Zeit die letzte Ziffer gewechselt wird.

Code: Alles auswählen

Feb 28 12:18:02 server sshd[26417]: error: PAM: Authentication failure for illegal user root from 112.85.42.124
Feb 28 12:18:02 server sshd[26417]: Failed keyboard-interactive/pam for invalid user root from 112.85.42.124 port 29495 ssh2
Feb 28 12:18:02 server sshd[26417]: Postponed keyboard-interactive for invalid user root from 112.85.42.124 port 29495 ssh2 [preauth]
Feb 28 12:18:03 server sshd[26422]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.124  user=root
Feb 28 12:18:04 server sshd[26417]: error: PAM: Authentication failure for illegal user root from 112.85.42.124
Feb 28 12:18:04 server sshd[26417]: Failed keyboard-interactive/pam for invalid user root from 112.85.42.124 port 29495 ssh2
Feb 28 12:18:05 server sshd[26417]: Postponed keyboard-interactive for invalid user root from 112.85.42.124 port 29495 ssh2 [preauth]

Verfasst: **28.02.2022 12:53:18**

Für Inhalte von Paketen ist iptables eher nicht geeignet. In deinem Fall böten sich zwei andere Möglichkeiten an:

fail2ban, mit dem du die IP nach dem ersten Versuch für eine bestimmte Zeit aussperren kannst (dann mittels iptables, und die Wahl eines höheren Ports – seitdem ich eine fünfstellige Portnummer für den sshd nutze, habe ich nicht einen solchen Eintrag mehr im Log gesehen.

Verfasst: **28.02.2022 14:38:25**

dirk11 hat geschrieben:
28.02.2022 12:26:17
Rein kommt also sowieso niemand, aber - Frage! - haben diese lästigen Versuche nicht außer kosmetischen (=Eintrag im log) auch andere Auswirkungen? Also beispielsweise eine höhere Latenz in meiner Internet-Verbindung oder sowas in der Art? Immerhin ist so ein Anmelde-Versuch ja auch traffic (wenn auch nur gering)?

Die Latenz bzw. den verursachten Traffic würde ich heutzutage nicht berücksichtigen. Wenn du eine Verbindung von außen auf deiner Seite blockierst, so ist das erste Paket ja schon zu dir über die langsame Strecke Provider<->Kunde (DSL, VDSL, Kabel, Glasfaser) übertragen worden, wenn dein Provider auf seiner Seite eine dynamische Firewall anbietet, die du per API ansprechen kannst, dann wäre ein Block über diesen Weg wirklich leitungsentlastend.

Verfasst: **28.02.2022 17:55:32**

niemand hat geschrieben:
28.02.2022 12:53:18
Für Inhalte von Paketen ist iptables eher nicht geeignet.

Sicher? Ich kann ja auch jetzt schon andere Sachen mit --hitcount usw. machen.

die Wahl eines höheren Ports

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

Verfasst: **28.02.2022 18:03:58**

dirk11 hat geschrieben:
28.02.2022 17:55:32
Sicher?

Ja, es ist sicher eher nicht geeignet: ohne Weiteres kann es kein DPI. In Verbindung mit

fail2ban funktioniert’s hingegen ganz ausgezeichnet – weil dazu die Transportverschlüsselung nicht ausgehebelt werden muss, sondern die notwendige Information aus dem Log genommen wird. Natürlich kannst du die Info auch mit einem beliebigen anderen Script oder Programm aus dem Log nehmen, und eine entsprechende iptables-Regel erzeugen. Ist halt nur nicht, was du gefragt hattest.

dirk11 hat geschrieben:
28.02.2022 17:55:32
Schau' einfach mal auf meinen log-Ausschnitt...

Mal auf einen der anderen 25564 fünfstelligen Ports geschaut? Wenn da innerhalb kürzester Zeit wieder ein Script dranhängt, würde ich das Problem mit der Maschine suchen: selbst meine Kisten in heftig verseuchten IP-Ranges des OVH-Billigsegments erfahren selten mal ’nen Portscan über alle Ports.

Verfasst: **28.02.2022 23:04:21**

niemand hat geschrieben:
28.02.2022 18:03:58
Mal auf einen der anderen 25564 fünfstelligen Ports geschaut?

Verstehe ich nicht, was meinst Du? Wie gesagt, das passiert willkürlich auf diversen Ports.

Wenn da innerhalb kürzester Zeit wieder ein Script dranhängt, würde ich das Problem mit der Maschine suchen: selbst meine Kisten in heftig verseuchten IP-Ranges des OVH-Billigsegments erfahren selten mal ’nen Portscan über alle Ports.

Was für ein Problem mit der Maschine? Da läuft nur der ssh-Zugang und ein lighttpd.
Das geht laut log 24/7. Von 122.194.229.xxx, von 112.85.42.xxx, von 222.186.30.xxx, 61.177.172.xxx, 218.92.0.xxx, 61.231.217.xxx und noch ein paar anderen.

112.85.42.6 - China
61.177.172.160 - China
122.194.229.38 - China
222.128.90.144 - China
uswusf.

Verfasst: **28.02.2022 23:13:31**

Warum gibst du firewalltechnisch den SSH-Port überhaupt weltweit frei?

Ich beschränke mich standardmäßig immer auf die IPv4 Netze die von der RIPE verwaltet werden und bin ganz glücklich mit der Lösung.

Verfasst: **01.03.2022 07:46:42**

dirk11 hat geschrieben:
28.02.2022 23:04:21
Verstehe ich nicht, was meinst Du?

Verstehe bitte, dass darauf nun nicht eingehen möchte – denn erfahrungsgemäß sind solche Nebendiskussionen mit dir recht fruchtlos und frustrierend.

Ich habe deine Frage beantwortet: iptables alleine ist zu DPI nicht in der Lage – was aber notwendig wäre, um sowas abfangen zu können, bevor es den sshd erreicht und dort einen Logeintrag generiert, aber in die Nähe des gewünschten Ziels kannst du mit beispielsweise

fail2ban kommen: damit kann man die betreffende IP nach dem ersten Versuch anhand des erzeugten Logeintrags mittels iptables blockieren.

Wenn das nicht die Antwort ist, die dir gefällt (deine erste Antwort darauf leicht überspitzt interpretiert: „aber, aber, aber es muss mit iptables gehen! Irgendwas Anderes bekomme ich damit ja schließlich auch hin!“), dann werde ich dir nicht helfen können: ich bin leider nicht die Wunschfee.

Verfasst: **01.03.2022 08:35:19**

bluestar hat geschrieben:
28.02.2022 23:13:31
Warum gibst du firewalltechnisch den SSH-Port überhaupt weltweit frei?

Es gibt Leute, die ssh nutzen.
Davon abgesehen: kann man denn mit iptables eine Quell-IP-range blockieren?

@niemand
Das ist wörtlich zu nehmen: Ich verstehe es nicht. Da werden offenbar willkürlich und zufällig gewählte ports probiert, welche weder von mir "freigegeben" (ich habe gerade nachgesehen, die sind nichtmal in der fritzbox weitergeleitet - ich leite insgesamt nur wenige Ports überhaupt weiter) sind noch überhaupt irgendwie in Nutzung sind. Von daher muss doch überhaupt kein DPI gemacht werden? - Andererseits - woher stammen bei diesen forwarding-Voraussetzungen überhaupt diese Einträge? Ich stehe da gerade verständnismäßig auf der Leitung.

Ist mein "Problem" nur kosmetischer Natur? Das wäre mir dann im Grunde vollkommen egal, mir geht es nur darum, dass ich dadurch keine Leitungs-Leistungseinbußen habe.

Verfasst: **01.03.2022 08:56:56**

dirk11 hat geschrieben:
01.03.2022 08:35:19
Da werden offenbar willkürlich und zufällig gewählte ports probiert

Nein, das ist der Port für den Rückkanal. Der wird immer "zufällig" von deinerm SSH-Server vergeben.

Verfasst: **01.03.2022 09:30:09**

Ahhhh. Das macht es verständlicher!

Dann stelle ich direkt die Nachfrage - funktionieren diese Code-Zeilen nicht?

Code: Alles auswählen

    $IPTABLES -N SSH_WHITELIST2
    $IPTABLES -A SSH_WHITELIST2 -s 192.168.49.0/24 -m recent --remove --name ssh2 -j ACCEPT
    $IPTABLES -N SSH_BADGUYS2
    $IPTABLES -A SSH_BADGUYS2 -m recent --name ssh_badguys2 --set
    $IPTABLES -A SSH_BADGUYS2 -j LOG --log-prefix "SSH scanner detected: "
    $IPTABLES -A SSH_BADGUYS2 -j REJECT --reject-with icmp-admin-prohibited
    $IPTABLES -A INPUT -p tcp --dport 33 -m state --state NEW -j SSH_WHITELIST2
    $IPTABLES -A INPUT -p tcp --dport 33 -m state --state NEW -m recent --name ssh_badguys2 --update --seconds 120 -j REJECT --reject-with icmp-admin-prohibited
    $IPTABLES -A INPUT -p tcp --dport 33 -m state --state NEW -m recent --set --name ssh2
    $IPTABLES -A INPUT -p tcp --dport 33 -m state --state NEW -m recent --rcheck --seconds 60 --hitcount 4 --name ssh2 -j SSH_BADGUYS2

Verfasst: **01.03.2022 10:29:50**

MSfree hat geschrieben:
01.03.2022 08:56:56
Nein, das ist der Port für den Rückkanal.

Ist das nicht der source-Port?

MSfree hat geschrieben:
01.03.2022 08:56:56
Der wird immer "zufällig" von deinerm SSH-Server vergeben.

Warum soll der ssh-Server einen Rückkanal vergeben? Der source-Port des "Clienten", ist doch dann für den ssh-Server der destination-Port, oder?

Verfasst: **01.03.2022 10:32:45**

bluestar hat geschrieben:
28.02.2022 23:13:31
Warum gibst du firewalltechnisch den SSH-Port überhaupt weltweit frei?

Ich beschränke mich standardmäßig immer auf die IPv4 Netze die von der RIPE verwaltet werden und bin ganz glücklich mit der Lösung.

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

Verfasst: **01.03.2022 10:46:50**

mat6937 hat geschrieben:
01.03.2022 10:29:50
Warum soll der ssh-Server einen Rückkanal vergeben? Der source-Port des "Clienten", ist doch dann für den ssh-Server der destination-Port, oder?

Zu einer TCP/IP-Verbindung gehört nunmal ein "Draht" vom Client zum Server und ein zweiter vom Server zum Client, und nur der "Draht" vom Client zum Server läuft über den Standardport 22. Der Rückkanal wird mehr oder weniger zufällig erzeugt.

Verfasst: **01.03.2022 10:47:46**

dirk11 hat geschrieben:
01.03.2022 09:30:09
Dann stelle ich direkt die Nachfrage - ...

Wenn Du für den weltweiten Zugriff auf auf deinen ssh-Server, nur Geräte/Clients mit Linux als OS benutzt, gibt es weitere Möglichkeiten um mit iptables den unberechtigten Zugriff zu blockieren. Z. B. kannst Du nur NEW-Verbindungen mit gesetzten ecn-bit (syn+ecn) zulassen und Du kannst auf dem ssh-Client (auch mit iptables und source-NAT) einen definierten 5-stelligen source-Port benutzen.

BTW: Die wenigsten "Angreifer"/Portscanner machen einen Portscan/Anmeldeversuch mit gesetztem ecn-bit in der NEW-Verbindung (mit dem syn-flag).

Verfasst: **01.03.2022 10:50:48**

MSfree hat geschrieben:
01.03.2022 10:46:50
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.

Verfasst: **01.03.2022 11:14:21**

mat6937 hat geschrieben:
01.03.2022 10:50:48
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:

MSfree hat geschrieben:
01.03.2022 08:56:56
Der wird immer "zufällig" von deinerm SSH-Server vergeben.

Verfasst: **01.03.2022 11:19:25**

JTH hat geschrieben:
01.03.2022 11:14:21

MSfree hat geschrieben:
01.03.2022 08:56:56
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.

Verfasst: **01.03.2022 11:47:08**

MSfree hat geschrieben:
01.03.2022 11:19:25
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

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

Verfasst: **01.03.2022 11:57:19**

JTH hat geschrieben:
01.03.2022 11:47:08
... 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.

Verfasst: **01.03.2022 12:15:37**

dirk11 hat geschrieben:
28.02.2022 17:55:32
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.

Verfasst: **01.03.2022 12:59:52**

mat6937 hat geschrieben:
01.03.2022 11:57:19
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.

Verfasst: **01.03.2022 13:06:51**

MSfree hat geschrieben:
01.03.2022 12:59:52

mat6937 hat geschrieben:
01.03.2022 11:57:19
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.

Verfasst: **01.03.2022 13:46:15**

Tintom hat geschrieben:
01.03.2022 13:06:51
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.

Verfasst: **01.03.2022 14:02:28**

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.

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

debianforum.de

mit iptables Anmeldungen für root aussperren

mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren

Re: mit iptables Anmeldungen für root aussperren