Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Viele Verbindungen im Zustand SYN_RECV

4 views
Skip to first unread message

Jochen Meier

unread,
Oct 31, 2019, 2:28:52 PM10/31/19
to
Seit einiger Zeit liefert netstat auf meinem Server häufiger sehr viele
Zeilen mit SYN_RECV. Teilweise von vielen unterschiedlichen IPs wie unten,
teilweise aber auch nur von ein oder zwei IPs. Es wird dabei nie eine
vollständige Verbindung aufgebaut, d.h. in den Logs von Web- bzw.
Mailserver tauchen die IPs nicht auf.

Wird hier mein Server als Multiplikator für einen Angriff missbraucht: Auf
ein Paket mit gefälschter Absender-IP verschickt mein Server minutenlang
Pakete an den vermeintlichen Absender? Falls ja, kann ich das verhindern?

Hat jemand eine bessere Erklärung?

Grüße,
Jochen

tcp6 0 0 159.69.x.y:80 185.36.x6.100:46150 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.102:39009 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.105:52728 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.106:48887 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.123:64747 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.125:37124 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.130:48974 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.134:65273 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.137:47067 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.14:39579 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.145:38103 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.149:54845 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.170:44364 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.173:52549 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.176:64947 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.183:35159 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.184:55352 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.186:47240 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.188:41762 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.20:48910 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.209:46494 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.215:53775 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.223:41057 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.233:59145 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.238:42627 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.238:43652 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.238:44775 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.239:52421 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.24:54281 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.28:41120 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.33:65496 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.49:59038 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.5:39318 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x6.61:38997 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.65:64657 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x6.69:51980 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.78:60750 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.90:57191 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x6.92:48547 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x6.92:62375 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.102:44244 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.109:51317 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.111:34553 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.124:35151 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.127:35958 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.134:35827 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.136:57353 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.162:55060 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.163:57422 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.168:35730 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.180:40178 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.185:39980 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.186:63133 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.19:42912 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.21:58495 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.216:34449 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.223:63620 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.229:56430 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.230:44722 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.240:51149 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.242:61020 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.27:42407 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.29:48831 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.34:55673 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.36:56589 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.38:54821 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.40:44592 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.44:51547 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.45:54152 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.49:51432 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.52:40754 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.55:45061 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.57:47021 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x7.62:46867 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.66:49959 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.67:44258 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x7.83:45417 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x7.89:45465 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x7.93:39526 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x8.0:58623 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x8.104:35316 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x8.125:33943 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.129:40439 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.142:53259 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.147:34903 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.156:54603 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.16:48991 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.174:34867 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.181:62018 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.186:55101 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.189:47129 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.193:35670 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.193:48659 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.193:59146 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.195:45962 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.198:49806 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.212:37409 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.219:52573 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x8.220:39725 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.239:61069 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.35:38293 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x8.44:63834 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.50:44188 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x8.60:44655 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x8.75:56617 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x8.83:46360 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.0:52326 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.101:42079 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.102:44142 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.102:63967 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.117:42962 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.123:37519 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.123:53539 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.123:59336 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.126:58428 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.130:49919 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.131:42667 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.138:63024 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.140:47593 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.150:47304 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.159:54776 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.161:59934 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.168:36807 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.174:48647 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.174:65133 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.17:52768 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.177:58036 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.179:45481 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.186:61543 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.188:42651 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.188:42920 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.20:37135 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.209:44106 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.209:46608 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.213:48614 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.241:40735 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.250:47563 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.33:59479 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.34:37801 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.38:33360 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.54:65143 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.56:37822 SYN_RECV
tcp 0 0 159.69.x.y:587 185.36.x9.59:47553 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.60:65097 SYN_RECV
tcp6 0 0 159.69.x.y:443 185.36.x9.67:40779 SYN_RECV
tcp6 0 0 159.69.x.y:80 185.36.x9.84:35137 SYN_RECV
tcp 0 0 159.69.x.y:25 185.36.x9.87:52654 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.113:33542 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.116:63862 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.13:61513 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.158:38264 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.185:44308 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.186:47219 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.187:49029 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.208:40608 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.212:35431 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.214:43927 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.218:44998 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.220:33513 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.225:50122 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.228:48855 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.232:38697 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.244:54683 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.244:63774 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.252:39885 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.252:44884 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.254:49541 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.29:40051 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.30:52883 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.3:64151 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.41:56709 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.43:36196 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.45:51431 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.50:62366 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x6.57:36359 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.67:42216 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.69:46558 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.70:63126 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x6.75:58350 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x6.77:64777 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.83:56750 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x6.99:40614 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.115:56105 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.144:42659 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.14:54569 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.157:55355 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.159:40624 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.163:35732 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.185:34921 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.189:47017 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.193:39089 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.199:35857 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.20:33512 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.204:63081 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.213:55942 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.219:51634 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.228:49175 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.23:62302 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.245:63182 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.246:50018 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.250:34465 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.253:61150 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.254:65329 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.28:61619 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.3:46312 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.3:54223 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.38:58348 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.42:44486 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.48:40558 SYN_RECV
tcp 0 0 159.69.x.y:587 194.247.x7.76:56027 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.79:39516 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.80:33297 SYN_RECV
tcp6 0 0 159.69.x.y:80 194.247.x7.8:35781 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.85:33663 SYN_RECV
tcp 0 0 159.69.x.y:25 194.247.x7.86:52422 SYN_RECV
tcp6 0 0 159.69.x.y:443 194.247.x7.93:60752 SYN_RECV

Marc SCHAEFER

unread,
Nov 1, 2019, 4:19:13 AM11/1/19
to
Jochen Meier <gesammeltim...@arcor.de> wrote:
> Hat jemand eine bessere Erklärung?

Ich vermute, es ist mehr ein Symptom für eine Attacke, die deinen Host mit
sovielen Verbindungsversuche zu überlasten, dass er nicht mehr für
legitime Benutzer verfügbar ist.

Die Verteidigungsmassnahme heisst Syncookies[1].

[1] https://de.wikipedia.org/wiki/SYN-Cookies

Florian Weimer

unread,
Nov 1, 2019, 7:33:09 AM11/1/19
to
* Jochen Meier:

> Seit einiger Zeit liefert netstat auf meinem Server häufiger sehr viele
> Zeilen mit SYN_RECV. Teilweise von vielen unterschiedlichen IPs wie unten,
> teilweise aber auch nur von ein oder zwei IPs. Es wird dabei nie eine
> vollständige Verbindung aufgebaut, d.h. in den Logs von Web- bzw.
> Mailserver tauchen die IPs nicht auf.

Was macht der Server denn so?

Das sieht ein bißchen so wie Mirkforce aus. Lang ist's her.

dl8...@dl8fbh.ampr.org

unread,
Nov 1, 2019, 8:47:02 AM11/1/19
to
Jochen Meier <gesammeltim...@arcor.de> wrote:

> Seit einiger Zeit liefert netstat auf meinem Server häufiger sehr viele
> Zeilen mit SYN_RECV. Teilweise von vielen unterschiedlichen IPs wie unten,
> teilweise aber auch nur von ein oder zwei IPs. Es wird dabei nie eine
> vollständige Verbindung aufgebaut, d.h. in den Logs von Web- bzw.
> Mailserver tauchen die IPs nicht auf.
>
> Wird hier mein Server als Multiplikator für einen Angriff missbraucht: Auf
> ein Paket mit gefälschter Absender-IP verschickt mein Server minutenlang
> Pakete an den vermeintlichen Absender? Falls ja, kann ich das verhindern?

Verbinde Dich neu zum Provider, Du bekommst dann eine neue IP.

Michael

Günter Frenz

unread,
Nov 1, 2019, 8:51:01 AM11/1/19
to
Ich beobachte das auch auf zwei Systemen, einmal mein Router hier zu
Hause (mangels Alternativen nur Port 22) und auf einem Server im
Rechenzentrum (da auf allen offenen Ports). Die Mengen derartiger
Pakete sind gering genug, dass meine Systeme damit keine Probleme
bekommen, die Absenderadressen sind aber auf beiden Systemen aus dem
selben Bereich (zeitgleich). Spricht m. E. eher dafür, dass die Systeme
für DDOS missbraucht werden.

Man könnte versuchen, da via Paketfilter eine Mengenbegrenzung
einzubauen, muss dann aber aufpassen, dass man sich dabei nicht selber
ins Knie schießt.

Günter

Marc Haber

unread,
Nov 1, 2019, 10:51:59 AM11/1/19
to
Jochen Meier <gesammeltim...@arcor.de> wrote:
>Seit einiger Zeit liefert netstat auf meinem Server häufiger sehr viele
>Zeilen mit SYN_RECV. Teilweise von vielen unterschiedlichen IPs wie unten,
>teilweise aber auch nur von ein oder zwei IPs. Es wird dabei nie eine
>vollständige Verbindung aufgebaut, d.h. in den Logs von Web- bzw.
>Mailserver tauchen die IPs nicht auf.
>
>Wird hier mein Server als Multiplikator für einen Angriff missbraucht: Auf
>ein Paket mit gefälschter Absender-IP verschickt mein Server minutenlang
>Pakete an den vermeintlichen Absender? Falls ja, kann ich das verhindern?
>
>Hat jemand eine bessere Erklärung?
>

Also, erstmal schreibst du weder, welches Tool Du benutzt, noch wie Du
es aufrufst. Da kann an nur raten, was Sache ist.

Dann...

>tcp6 0 0 159.69.x.y:80 185.36.x6.100:46150 SYN_RECV

... ist das gelogen, tcp6 mit IPv4 adressen glaubt Dir vielleicht
deine Oma.

Und dann.. würde Dein System nur in SYN_RECV gehen, wenn auf den Ports
25, 80, 443, 587 wirklich ein Dienst lauschen würde, sonst gibt's ein
RST und gut ist.

Und wenn da Dienste laufen, könnte das genau so gut normale Nutzugn
Deiner Dienste sein. Vielleicht mit kaputten Clients.

TCP als Multiplikator fände ich persönlich ein wenig zu lahm, da gibt
es viel effizientere Aufgaben.

Wenn es wirklich nur um ein paar hundert Verbindungen geht und dein
Server in seiner Funktion nicht beeinträchtigt ist, ignorier's.

Und das nächste Mal trollst Du bitte nicht so offensichtlich.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Marc Haber

unread,
Nov 1, 2019, 10:52:49 AM11/1/19
to
Du weißt doch gar nicht, wie der Server angebunden ist?

Ulf Volmer

unread,
Nov 1, 2019, 12:29:30 PM11/1/19
to
Marc Haber <mh+usene...@zugschl.us> schrieb:
> Jochen Meier <gesammeltim...@arcor.de> wrote:
>>Seit einiger Zeit liefert netstat auf meinem Server häufiger sehr viele
>>Zeilen mit SYN_RECV. Teilweise von vielen unterschiedlichen IPs wie unten,
>>teilweise aber auch nur von ein oder zwei IPs. Es wird dabei nie eine
>>vollständige Verbindung aufgebaut, d.h. in den Logs von Web- bzw.
>>Mailserver tauchen die IPs nicht auf.
>>
>>Wird hier mein Server als Multiplikator für einen Angriff missbraucht: Auf
>>ein Paket mit gefälschter Absender-IP verschickt mein Server minutenlang
>>Pakete an den vermeintlichen Absender? Falls ja, kann ich das verhindern?
>>
>>Hat jemand eine bessere Erklärung?
>>
>
> Also, erstmal schreibst du weder, welches Tool Du benutzt, noch wie Du
> es aufrufst. Da kann an nur raten, was Sache ist.

Schreib er. netstat.
>
> Dann...
>
>>tcp6 0 0 159.69.x.y:80 185.36.x6.100:46150 SYN_RECV
>
> ... ist das gelogen, tcp6 mit IPv4 adressen glaubt Dir vielleicht
> deine Oma.

Also mein netstat unter Debian Buster zeigt bei einigen Verbindungen
analoges Verhalten:

tcp6 0 0 172.17.227.55:80 172.17.254.3:44990 TIME_WAIT

Wenn ich mit die gleich Verbindung mit ss anschaue, taucht dort die IP

[::ffff:172.17.227.55]:80

auf.

Viele Grüße
Ulf

dl8...@dl8fbh.ampr.org

unread,
Nov 1, 2019, 1:47:02 PM11/1/19
to
Marc Haber <mh+usene...@zugschl.us> wrote:

>>Verbinde Dich neu zum Provider, Du bekommst dann eine neue IP.
>
> Du weißt doch gar nicht, wie der Server angebunden ist?
>

Wenn es anders wäre, wüsste er wohl damit umzugehen.

Michael

Autist

unread,
Nov 2, 2019, 3:15:05 AM11/2/19
to
> [1] https://de.wikipedia.org/wiki/SYN-Cookies

Das geilste was da steht, dass SYN-Cookies nicht mehr wg. der Netzwerk
-Last zum DDoS missbraucht werden können, sondern der CPU-Laat wegen;
als würde das Berechnen des SYN-Cookies erwähnenswert CPU-Last kosten.
Glaubt der Autor wirklich was der da schreibt?

Marc Haber

unread,
Nov 2, 2019, 7:36:07 AM11/2/19
to
Ulf Volmer <u.vo...@u-v.de> wrote:
>Also mein netstat unter Debian Buster zeigt bei einigen Verbindungen
>analoges Verhalten:
>
>tcp6 0 0 172.17.227.55:80 172.17.254.3:44990 TIME_WAIT

Interessant, ich habe bevor ich das schrieb alle meine Server
durchgeflöht und nichts dergleichen gefunden. Ich ziehe den Anpfiff
zurück und bitte um Entschuldigung.

Autist

unread,
Nov 2, 2019, 2:03:41 PM11/2/19
to
Man muss aber auch sagen, dass diese Backlog-Logik von listen()
äußerst dämlich ist. Als würde die Verwaltung halboffener Verbindungen
(vor Linux 2.2) bzw. hergestellter, aber noch nicht ge-accept()-teter
Verbindungen (Linux 2.2 und neuer) nennenswert groß Speicher verbrau-
chen. Da köntne man doch ein systemweites Limit für alle Sockets ins-
gesamt setzen, dass so ultimativ hoch ist, dass ältere Verbindungen
auf denen nichts passiert ist schon wieder timeouten ehe der Buffer
für halboffene bzw. noch nicht angenommene Verbindung voll ist.

Jochen Meier

unread,
Nov 2, 2019, 6:30:17 PM11/2/19
to
Marc Haber <mh+usene...@zugschl.us> wrote:

> Also, erstmal schreibst du weder, welches Tool Du benutzt, noch wie Du
> es aufrufst. Da kann an nur raten, was Sache ist.

Ich hatte eigentlich gedacht, alles notwendige angegeben zu haben. Die
Ausgabe stammt von einem netstat unter Debian, wobei ich alle
Spalten nach SYN_RECV entfernt habe. Dies sollte nur die Menge an
Anfragen veranschaulichen.

>>tcp6 0 0 159.69.x.y:80 185.36.x6.100:46150 SYN_RECV
>
> ... ist das gelogen, tcp6 mit IPv4 adressen glaubt Dir vielleicht
> deine Oma.

Was kann ich dafür wenn das netstat unter Debian lügt?

> Und dann.. würde Dein System nur in SYN_RECV gehen, wenn auf den Ports
> 25, 80, 443, 587 wirklich ein Dienst lauschen würde, sonst gibt's ein
> RST und gut ist.

Dort laufen ja auch Dienste. Und diese protokollieren keine Einträge
mit den IPs, die viele Verbindungen in SYN_RECV verursachen.

> Und wenn da Dienste laufen, könnte das genau so gut normale Nutzugn
> Deiner Dienste sein. Vielleicht mit kaputten Clients.

Da es ein sehr kleiner Server ist, der fast ausschließlich privat
genutzt wird, kann ich das ausschließen. Gut, das hätte ich gleich dazu
schreiben können...

Grüße,
Jochen

Jochen Meier

unread,
Nov 2, 2019, 6:30:17 PM11/2/19
to
Marc Haber <mh+usene...@zugschl.us> wrote:

> Interessant, ich habe bevor ich das schrieb alle meine Server
> durchgeflöht und nichts dergleichen gefunden. Ich ziehe den Anpfiff
> zurück und bitte um Entschuldigung.

Die nehme ich gerne an.

Grüße,
Jochen

Jochen Meier

unread,
Nov 2, 2019, 6:30:18 PM11/2/19
to
Thomas Noll <-_tn...@web.de> wrote:

> Verhindern nicht, aber u.U. reduzieren.
>
> net.ipv4.tcp_synack_retries = 5 ist default, wenn deine legitimen Clients
> gute Verbindungen haben, kannst du das reduzieren.

Das habe ich gerade auch in einem Artikel über Syncookies gelesen und
bin mir aber unsicher. Eine 4 dürfte vermutlich den echten Clients
nicht schaden.

> Ansonsten bleibt eigentlich nur drop mit netfilter, aber da musst du dir
> Gedanken machen, wie du die guten von den bösen unterscheiden kannst.

Das ist eine Aufgabe die damit endet, dass ich das halbe Internet
blockiere, und ich dann im Urlaub nicht mehr an meinen Server komme...

Ich beobachte das schon eine ganze Weile und die IPs wechseln ständig.

Grüße,
Jochen

Jochen Meier

unread,
Nov 2, 2019, 6:30:18 PM11/2/19
to
Günter Frenz <usen...@guefz.de> wrote:
> Am Fri, 1 Nov 2019 09:19:12 +0100 (CET) schrieb Marc SCHAEFER:
>
>> Die Verteidigungsmassnahme heisst Syncookies[1].
>>
>> [1] https://de.wikipedia.org/wiki/SYN-Cookies

Die sind bereits aktiviert, aber ich finde in den Logs keinen Eintrag,
dass sie durch den Angreifer auch ausgelöst werden. Dann sollte doch der
Kernel in etwa "Possible SYN flooding on port X. Sending cookies"
protokollieren.

> Ich beobachte das auch auf zwei Systemen, einmal mein Router hier zu
> Hause (mangels Alternativen nur Port 22) und auf einem Server im
> Rechenzentrum (da auf allen offenen Ports). Die Mengen derartiger
> Pakete sind gering genug, dass meine Systeme damit keine Probleme
> bekommen, die Absenderadressen sind aber auf beiden Systemen aus dem
> selben Bereich (zeitgleich).

Interessant. Wirklich stören tut es meinen Server auch nicht. Ich bin
vor allem neugierig.

> Spricht m. E. eher dafür, dass die Systeme
> für DDOS missbraucht werden.

Wie ich jetzt aber nachgelesen habe, verursacht ein empfangenes SYN Paket
unter Linux nur fünf kleine Pakete (verteilt über mehrere Minuten) an den
vermeintlichen Absender. Das scheint mir nicht sehr effektiv.

Grüße,
Jochen

Sven Hartge

unread,
Nov 2, 2019, 7:20:03 PM11/2/19
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Jochen Meier <gesammeltim...@arcor.de> wrote:

> Dann...

>>tcp6 0 0 159.69.x.y:80 185.36.x6.100:46150 SYN_RECV

> ... ist das gelogen, tcp6 mit IPv4 adressen glaubt Dir vielleicht
> deine Oma.

Mal die Kirche im Dorf lassen, Marc.

Die tcp6-Sockets unter Linux können sehr wohl IPv4 wie auch IPv6, sofern
man dem Kernel das nicht verbietet und das Programm die korrekten
Optionen beim Öffnen angibt.

Apache2 z.B. macht über einen tcp6-Socket beides während OpenSSH zwei
separate Sockets öffnet:

,----
| # netstat -tlpn | grep apache2
| tcp6 0 0 :::80 :::* LISTEN 383526/apache2
| tcp6 0 0 :::443 :::* LISTEN 383526/apache2
| # netstat -tlpn | grep sshd
| tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 382803/sshd
| tcp6 0 0 :::22 :::* LISTEN 382803/sshd
`----


Entsprechend sieht man dann bei Apache2 auf dem tcp6 Socket auch
Verbindungen von IPv4-Adressen, während bei sshd diese fein sauber
getrennt sind.

> Und das nächste Mal trollst Du bitte nicht so offensichtlich.

Da ist eine Entschuldigung deinerseits fällig.

S!

--
Sigmentation fault. Core dumped.

Sven Hartge

unread,
Nov 2, 2019, 7:21:08 PM11/2/19
to
Frank Graf <f.g...@firemail.de> wrote:

> Mir sagte man es sei der kaputte IP-Stack von Linux, als ich mal nach
> diesem Verhalten fragte.

Die Diskussion, welches Verhalten hier richtig ist, ist so alt wie IPv6
selbst.

Günter Frenz

unread,
Nov 3, 2019, 4:24:02 AM11/3/19
to
Effektiv wird so etwas wenn man das auf sehr vielen Servern
gleichzeitig macht. Dann summiert sich das beim Ziel auf und stört
dort. Bei den reflektierenden Servern fallen die paar Pakete nicht ins
Gewicht.

Am Freitag kamen die Absenderadressen alle aus dem IP-Bereich eines
bulgarischen Hosting-Providers, als ich das ein paar Tage vorher mal
beobachtet hatte, kamen sie nacheinander von einzelnen Systemen aus der
Amazon Cloud.

Für so eine Art Monitoring, welche potenziellen Angriffsziele im Netz
vorhanden sind, kommen die Pakete zu häufig und eben nur an die offenen
Ports.

Günter

0 new messages