Hetzner: Rate-Limit auf Port 22

greystone

Active Member
Ich habe gerade einen neuen Server bei Hetzner in Betrieb genommen. Scheint so, als ob die ein Rate-Limit auf Port 22 haben.

Also 5 SYN-Pakete (= 5 x Verbindungsaufbau), dann machen die den Port erstmal für <=10 Min dicht.

Der Support weiss von nichts, behauptet es gäbe kein Rate-Limit, verweist auf die Selbstverantworltichkeit der Serveradministration für dedizierte Serverprodukte und hat mir ansonsten empfohlen mal im Rechenzentrum anzurufen. SSH-Port umlegen hilft.

Code:
$ while :;do echo "$(date) : $(nmap -p22 1.2.3.4 2>&1|grep 22/)";sleep 5;done

Mo 18. Nov 16:40:13 CET 2024 : 22/tcp open  ssh
Mo 18. Nov 16:40:18 CET 2024 : 22/tcp open  ssh
Mo 18. Nov 16:40:23 CET 2024 : 22/tcp open  ssh
Mo 18. Nov 16:40:28 CET 2024 : 22/tcp open  ssh
Mo 18. Nov 16:40:33 CET 2024 : 22/tcp open  ssh
Mo 18. Nov 16:40:38 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:40:43 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:40:49 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:40:54 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:40:59 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:04 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:10 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:15 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:20 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:25 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:31 CET 2024 : 22/tcp filtered ssh
Mo 18. Nov 16:41:36 CET 2024 : 22/tcp filtered ssh
^C

$ while :;do echo "$(date) : $(nmap -p12345 1.2.3.4 2>&1|grep 12345/)";sleep 5;done

Mo 18. Nov 16:41:51 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:41:56 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:01 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:06 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:11 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:16 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:21 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:26 CET 2024 : 12345/tcp open  unknown
Mo 18. Nov 16:42:31 CET 2024 : 12345/tcp open  unknown
^C

Das ist neu. Bei einem anderen dedizierten Server habe ich das auch gerade mal getestet. Da ist kein Block.
 
Last edited:
Hab das mal eben gestestet mit 3 maschinen Debian 12 jeweils HEL, FSN, NBG und kann das Verhalten nicht bestätigen.
Sicher das da nichts anderes dazwischen funkt?

~# while :;do echo "$(date) : $(nmap -p22 x.x.x.x 2>&1|grep 22/)";sleep 1;done
Sat Mar 15 10:38:34 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:36 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:37 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:39 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:40 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:44 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:45 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:47 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:50 AM CET 2025 :
Sat Mar 15 10:38:54 AM CET 2025 :
Sat Mar 15 10:38:58 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:00 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:01 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:03 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:05 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:06 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:09 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:11 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:12 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:14 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:15 AM CET 2025 :
Sat Mar 15 10:39:19 AM CET 2025 : 22/tcp filtered ssh
Sat Mar 15 10:39:21 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:23 AM CET 2025 :
Sat Mar 15 10:39:27 AM CET 2025 : 22/tcp open ssh
~# while :;do echo "$(date) : $(nmap -p22 x.x.x.x 2>&1|grep 22/)";sleep 1;done
Sat Mar 15 10:38:41 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:44 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:47 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:49 AM CET 2025 : 22/tcp filtered ssh
Sat Mar 15 10:38:50 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:52 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:53 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:54 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:38:58 AM CET 2025 :
Sat Mar 15 10:39:02 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:03 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:07 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:08 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:09 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:13 AM CET 2025 :
Sat Mar 15 10:39:17 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:18 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:22 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:23 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:27 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:28 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:29 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:31 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:32 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:34 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:35 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:36 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:38 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:39 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:40 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:44 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:45 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:47 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:39:50 AM CET 2025 : 22/tcp open ssh
~# while :;do echo "$(date) : $(nmap -p22 x.x.x.x 2>&1|grep 22/)";sleep 1;done
Sat Mar 15 10:40:27 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:30 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:32 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:33 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:37 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:40 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:42 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:43 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:46 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:48 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:49 AM CET 2025 :
Sat Mar 15 10:40:53 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:55 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:56 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:40:59 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:03 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:06 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:09 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:11 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:12 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:16 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:17 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:18 AM CET 2025 :
Sat Mar 15 10:41:23 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:26 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:27 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:29 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:30 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:31 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:33 AM CET 2025 :
Sat Mar 15 10:41:37 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:38 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:40 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:43 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:45 AM CET 2025 :
Sat Mar 15 10:41:49 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:50 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:52 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:53 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:54 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:56 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:41:59 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:42:03 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:42:04 AM CET 2025 : 22/tcp open ssh
Sat Mar 15 10:42:05 AM CET 2025 : 22/tcp open ssh

Getestet von @home über DTAG
 
Last edited:
Bei mir ist es jetzt auch nicht mehr. Ich vermute, Hetzner hat das wieder entfernt.
 
Last edited:
Hetzner betreibt laut eigenen Aussagen DDoS-Schutz mit Arbor (Peakflows?) kombiniert mit Filterregeln auf deren Juniper-Router:

Ein solches Verhalten ist meines Erachtens typisch für aktive DDoS-Abwehr, es kann sein dass das System entweder durch Versuche von dir auf der IP aktiv wurde oder gerade für eine Netrange wegen Angriffs auf einen anderen Kunden aktiv war.
Dass es jetzt nicht mehr auftritt bedeutet dann lediglich dass der DDoS-Schutz aktuell wieder in standby ist.
 
Back
Top