n.s.5
Anmeldungsdatum: 8. November 2013
Beiträge: Zähle...
|
Hallo Zusammen, ich wurde vorkurzem mit einer für mich interessanten 😉 Situation, auf einem Server, konfrontiert.
Auf dem läuft ein Nginx Reversproxy + SSH auf den Ports 80->443 und 22.
Ich habe mir auf dem Server die Verbindungen mit tcptrack mal darstellen lassen und habe folgendes bild erhalten (siehe Anhang: bild1) Ein Client hat gleichzeitig mehrere Verbindungen geöffnet und auch immer wieder neue initiiert wenn andere geschlossen wurden.
Vor allem sind mir die Port 22 Verbindungen ins Auge gefallen.
Interessant ist das der Client die Verbindung nur offen gelassen hat. Sprich sieht für mich nach einer reinen Keepalive Verbindung aus. Ich habe darauf hin natürlich gleich die SSH Logs gecheckt um die Logins nachzuvollziehen und aktiv eingeloggte user überprüft, aber alles negativ.
Fail2Ban ebenfalls unauffällig.
UFW unauffällig.
Also der client hat wirklich "kein" Traffic verursacht, auch keine HTTP Anfragen nix. Somit haben die Logs mehr Fragen aufgeworfen als geklärt ☺
Warum macht ein Client das?
Was könnte die Absichten sein?
Muss man Handeln? Habt Ihr ein Rat für mich oder ähnliche Erfahrung gemacht, dann lasst ein Kommentar da und den Daumenhoch nicht vergessen 😀
- Bilder
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
n.s.5 schrieb: Ich habe darauf hin natürlich gleich die SSH Logs gecheckt um die Logins nachzuvollziehen und aktiv eingeloggte user überprüft, aber alles negativ.
Ist das die Ausgabe auf dem Server? Die IP mit der 70 hinten dran ist die IP deines Servers? Zeig mal noch
netstat -tunep
Die Bezeichnungen "Client" und "Server" sind irgendwie irreführend.
|
n.s.5
(Themenstarter)
Anmeldungsdatum: 8. November 2013
Beiträge: 9
|
Vielen Dank für deine schnelle Antwort. Ist das die Ausgabe auf dem Server? Die IP mit der 70 hinten dran ist die IP deines Servers?
Ja die Ausgabe ist vom Server mit der 70 am ende
Die Bezeichnungen "Client" und "Server" sind irgendwie irreführend.
Okay ☺ alternative Vorschläge? und hier der netstat output:
| netstat -tunep
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 304 XXX.XXX.XX.70:22 XXX.XXX.170.243:64175 ESTABLISHED 0 16505755 8146/sshd: root@pts
tcp 0 0 127.0.0.1:47544 127.0.0.1:27017 ESTABLISHED 1000 19843 1019/node
tcp 0 0 127.0.0.1:27017 127.0.0.1:47544 ESTABLISHED 111 19844 1034/mongod
tcp 0 0 XXX.XXX.XX.70:22 XXX.XXX.39.48:34584 ESTABLISHED 0 21444 1389/sshd: user [pr
|
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
n.s.5 schrieb: Warum macht ein Client das?
Keine Ahnung. Wenn es keine Authentifizierungsversuche gab, könnte es dann ein Monitoring sein?
Was könnte die Absichten sein?
Grundsätzlich gibt es immer mal Crawler, die offene Ports im Internet scannen. Allerdings machen wir normalerweise nicht mehrere Verbindungen gleichzeitig auf.
Muss man Handeln?
Du kannst ja erstmal nicht viel machen. Du könntest diese spezielle IP blockieren, und schauen, ob das Verhalten nochmal so auftritt.
Habt Ihr ein Rat für mich oder ähnliche Erfahrung gemacht, dann lasst ein Kommentar da und den Daumenhoch nicht vergessen 😀
Grundsätzlich ist immer ein Monitoring gut, welches dich über ungewöhnliche Zustände informiert.
|
n.s.5
(Themenstarter)
Anmeldungsdatum: 8. November 2013
Beiträge: 9
|
Das interessante ist auch, ich habe mal versucht über traceroute pi mal daumen zu erfassen wo die ip herkommt (siehe Anhang).
Leider war beim 7 Hop Schluss und hat damit auch Deustchland nicht verlassen. Dann hab ich mal ein ganz professionellen Ansatz versucht und zwar die IP geggooglet, mit der Hoffnung die ip ist static und wurde schonmal von jemanden erfasst.
Und tatsächlich, die IP kam aus Korea. So stelle ich mir dann auch die Frage würde GeoBlocking sin machen?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
n.s.5 schrieb: So stelle ich mir dann auch die Frage würde GeoBlocking sin machen?
Kann man tun, ich mach das allerdings nicht. Ich würde lieber fail2ban so konfigurieren, dass er IPs mit vielen Dummy-Verbindungen blockt. Ganze Kontinente zu blocken ist IMHO schlechter Stil.
|
n.s.5
(Themenstarter)
Anmeldungsdatum: 8. November 2013
Beiträge: 9
|
misterunknown schrieb: n.s.5 schrieb: So stelle ich mir dann auch die Frage würde GeoBlocking sin machen?
Kann man tun, ich mach das allerdings nicht. Ich würde lieber fail2ban so konfigurieren, dass er IPs mit vielen Dummy-Verbindungen blockt. Ganze Kontinente zu blocken ist IMHO schlechter Stil.
Das kling nach einem Plan ☺
Um etwas von deinem Erfahrungsschatz abzuzweigen wie würdest du eine Dummy-Verbindung definieren?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8553
Wohnort: Münster
|
Einen offenen Port 22 im Internet umschwärmen lichtscheue Halunken wie Motten das Licht, denn ein gehackter SSH-Server ist für die Verbrecher eine Goldgrube. Prüfe, ob Du den SSH-Server vernünftig gesichert hast: Der Benutzer root darf auf keinen Fall Zugang erhalten. Möglichst wenige, am besten nur ein einziger Benutzer darf sich überhaupt anmelden. Benutzer dürfen sich nicht per Passwort, sondern nur über Zertifikate authentifizieren. Diese Zertifikate müssen über einen sicheren Kanal auf den Server übertragen worden sein.
Eine zusätzliche Maßnahme, welche alleine aber gar nichts bringt, ist das Verstecken des SSH-Ports. Der Server läuft einfach auf einem beliebigen anderen, nur Dir bekannten Port als dem Standardport 22. Eventuelle Angreifer müssen daher erst einmal einen Portscan durchführen. Ein angenehmer Nebeneffekt ist, dass die Logs nicht überquellen mit Meldungen abgewiesener Anmeldeversuche.
|
MelcooX
Anmeldungsdatum: 26. April 2016
Beiträge: 144
Wohnort: Am Ende des Weges
|
n.s.5 schrieb: Das interessante ist auch, ich habe mal versucht über traceroute pi mal daumen zu erfassen wo die ip herkommt (siehe Anhang).
Leider war beim 7 Hop Schluss und hat damit auch Deustchland nicht verlassen. Dann hab ich mal ein ganz professionellen Ansatz versucht und zwar die IP geggooglet, mit der Hoffnung die ip ist static und wurde schonmal von jemanden erfasst.
Und tatsächlich, die IP kam aus Korea. So stelle ich mir dann auch die Frage würde GeoBlocking sin machen?
Ob GeoBlocking Sinn macht, kannst schlussendlich nur du selbst entscheiden. Ich mache hier mal 2 kleine Beispiele:
Ein kleiner Deutscher Blog, der sich nur an den deutschprachigen Raum richtet, kann dies schon machen Google hingegen eher weniger...
Aber im Allgemeinen, muss ich sagen, dass ich denke GeoBlocking ist nicht das gelbe vom Ei, dies da du hierbei nur Symptome bekämpfst und nicht die Ursachen. Du kannst ja mal auf db-ip.com schauen, dort stehen auch noch einige weiteren Informationen. Falls es z.B. ein Proxy ist, geht das Wechseln einer IP/Landes relativ einfach und das GeoBlocking läuft vollständig ins leere... Die Frage ist eher, was kann dein "Angreifer" sehen, wenn er sich nur zum SSH-Server verbindet, aber nicht einloggt. Prüfe doch mal dein '/var/log/auth.log' ob da was interessantes ist. Mein Rat ist, wenn du dir wirklich Sorgen machst: Verschiebe den SSH-Server auf irgendeinen Port, der nicht so oft gescannt wird. (Ich hatte mal einen auf nem Port in den 5XXXern, oder wähle von https://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports einen aus). Desweiteren kannst du ja noch Portknocking einrichten...(Dies habe ich nie ausprobiert, aber mal einen alten Forumsbeitrag hierzu: https://forum.ubuntuusers.de/topic/erfahrungen-mit-portknocking/ und aus dem Arch Linux Wiki einen Beitrag dazu.. Setzt aber Voraus, dass du eine halbwegs stabile Internetverbindung hast) Damit Blockt deine Firewall alle, die sich nicht vorher mit der richtigen Klopfsequenz Authorisieren vor der Loginmaske des SSH.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
n.s.5 schrieb: Um etwas von deinem Erfahrungsschatz abzuzweigen wie würdest du eine Dummy-Verbindung definieren?
fail2ban bietet schon vorgefertigte Filter, beispielsweise sshd-ddos. Ansonsten kannst du natürlich auch eigene Filter schreiben, oder ggf. Skripte, die nachschauen, wie viele Verbindungen von derselben IP kommen, und die ggf. blocken. Das hängt auch stark davon ab, was der Normalzustand auf deinem Server ist. Oftmals hilft auch schon ein vernünftiges Monitoring, um im Zweifelsfall händisch eingreifen zu können. Beispielsweise unerwarteter Traffic-Anstieg, ungewöhnlich viele Verbindungen, etc.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13892
|
n.s.5 schrieb: ... alternative Vorschläge? und hier der netstat output:
| netstat -tunep
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 304 XXX.XXX.XX.70:22 XXX.XXX.170.243:64175 ESTABLISHED 0 16505755 8146/sshd: root@pts
tcp 0 0 127.0.0.1:47544 127.0.0.1:27017 ESTABLISHED 1000 19843 1019/node
tcp 0 0 127.0.0.1:27017 127.0.0.1:47544 ESTABLISHED 111 19844 1034/mongod
tcp 0 0 XXX.XXX.XX.70:22 XXX.XXX.39.48:34584 ESTABLISHED 0 21444 1389/sshd: user [pr
|
Naja es ist dein Server der die Zugriffe auf den Port 22 des lauschenden sshd als ESTABLISHED (verbunden) anzeigt, auch wenn kein weiterer Datenaustausch mehr erfolgen kann. Die "Angreifer" können trotz fail2ban und ufw, deinen Server aber damit "beschäftigen".
Bist Du der einzige (mit welchem ssh-Client bzw. welchem OS?) der auf den Port 22 zugreifen soll/muss oder muss der Port 22 für die Öffentlichkeit erreichbar sein? Teste mal mit tcpdump (oder gleichwertig) ob das "syn, syn+ack, ack" mit deinem sshd-Server zustande kommt. Wenn ja und die Anzahl der ssh-Clients überschaubar ist, sollte man den sshd-server so konfigurieren, dass dieser unberechtigte syn-Zugriffe ignoriert und nicht mit "syn+ack" antwortet.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
lubux schrieb: Naja es ist dein Server der die Zugriffe auf den Port 22 des lauschenden sshd als ESTABLISHED (verbunden) anzeigt, auch wenn kein weiterer Datenaustausch mehr erfolgen kann. Die "Angreifer" können trotz fail2ban und ufw, deinen Server aber damit "beschäftigen".
Fail2ban blockt die IPs ja. Klar sind die Verbindungen noch kurze Zeit sichtbar, aber nur bis irgendein TCP-Timeout greift. Ggf. könnte man noch die Werte unter /proc/sys/net/ipv4/tcp_* anpassen, sollte aber in der Regel nicht nötig sein.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13892
|
misterunknown schrieb: Fail2ban blockt die IPs ja. Klar sind die Verbindungen noch kurze Zeit sichtbar, ...
Ja, aber es geht mir darum welcher Datenaustausch ("syn, syn+ack, ack"?) findet statt, bis fail2ban die IPs blockt?
Je nach Intensität der Angriffe, verbraucht dieser Datenaustausch und das blocken der IPs, Ressourcen. Und das kann man m. E. verhindern.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
lubux schrieb: Ja, aber es geht mir darum welcher Datenaustausch ("syn, syn+ack, ack"?) findet statt, bis fail2ban die IPs blockt?
Das kommt natürlich darauf an, wie fail2ban konfiguriert ist.
Je nach Intensität der Angriffe, verbraucht dieser Datenaustausch und das blocken der IPs, Ressourcen. Und das kann man m. E. verhindern.
Verteilte DDOS-Angriffe kann fail2ban eh nicht mitigieren, und wenn ein einzelner Angreifer kommt, dann steht das System eben kurz unter Druck, bis fail2ban geblockt hat. Das erscheint mir aber immer noch sinnvoller, als per Geoblocking ganze Länder auszuschließen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13892
|
misterunknown schrieb: Das erscheint mir aber immer noch sinnvoller, als per Geoblocking ganze Länder auszuschließen.
Ja, aber es geht nicht um Geoblocking. Je nach Art wie der TE seinen sshd-Server nutzt, gibt es auch noch andere Möglichkeiten, unberechtigte Zugriffe durch den Server zu ignorieren.
|