Important announcement: there is an English version of this forum on
Datum:
Ich beobachte immer wieder Sequenzen in der auth.log, wie diese:
Dec 18 07:27:25 h2847680 sshd[7879]: Did not receive identification string from 220.125.223.160 Dec 18 07:27:25 h2847680 sshd[7878]: Did not receive identification string from 121.238.96.217 Dec 18 07:27:46 h2847680 sshd[7880]: Did not receive identification string from 119.193.35.161 Dec 18 07:28:09 h2847680 sshd[7882]: Did not receive identification string from 121.191.60.54 Dec 18 07:28:50 h2847680 sshd[7883]: Did not receive identification string from 121.238.96.133 Dec 18 07:28:55 h2847680 sshd[7884]: Did not receive identification string from 59.28.161.52 Dec 18 07:29:05 h2847680 sshd[7887]: Did not receive identification string from 119.200.110.25 Dec 18 07:29:08 h2847680 sshd[7888]: Did not receive identification string from 14.56.157.160 Dec 18 07:29:15 h2847680 sshd[7889]: Did not receive identification string from 220.76.76.100 |
Die Absender sind bei Korea Telecom, oder China Telecom (2 Stück) gehostet. Das sieht doch irgendwie abgestimmt aus. Kann sich jemand einen Reim darauf machen, was das soll?
Datum:
Da möchte jemand Zugang zu deinem Server haben. Wenn du Passwort-Authentifizierung abgeschaltet hast und Anmelden nur über public-key-Verfahren (wie RSA) erlaubst sollte dir nicht viel passieren können.
Datum:
Ja, sicher, die probieren eine Einbruch. Das sind wahrscheinlich gehackte Maschinen, die probieren auch ganze Listen von Kombinationen durch. Hier probieren sie den Server mit offenen Anfragen zu plaetten. Sie beantragen ein Login, ruecken aber mit dem Loginstring nicht raus. Der Server haelt die Anfrage fuer eine gewisse Zeit offen und verliert so Memory. Am Einfachsten ist es den SSH port anderswohin, zB auf port 12345, zu verschieben, oder gaenzlich auf SSH zu verzichten. Falls das so nicht meglich ist, kann man allenfalls die Firewall so konfigurieren, dass eine IP nach zwei ungueltigen Anfragen ausgesperrt bleibt. Die Anfragen werden aber trotzdem kommen. Das Logfile braucht dafuer etwas mehr an Diskspace.
Datum:
Nano Oschi schrieb: > kann man allenfalls die Firewall so konfigurieren, dass > eine IP nach zwei ungueltigen Anfragen ausgesperrt bleibt. Ich habe mittlerweile fail2ban installiert, aber das reagiert nicht auf solche Geschichten. (Bei den "normalen" Durchprobier-Attacken ist übrigens seit ein paar Tagen Ruhe. Ich banne jeden Fehlversuch auf ssh für etliche Tage, es hat aber bisher nur 2 ausgeschlossen.) Mit so ein paar Anfragen sollte man doch eigentlich keinen Server in die Knie bekommen. Mein Zitat ist zwar nicht die längste Sequenz, aber sehr viel länger werden die nicht. Aber möglicherweise mach ja auch Strato irgendwas, um den Kerlen den Spaß zu verderben. Kann jemand eine gute Quelle zur genauen Funktionsweise der Protokolle auf dem Internet empfehlen?
Datum:
>Kann jemand eine gute Quelle zur genauen Funktionsweise der Protokolle
auf dem Internet empfehlen?
Das Internet ? Gurgel ?
Duck-und-weg
Datum:
Uhu Uhuhu schrieb: > Kann jemand eine gute Quelle zur genauen Funktionsweise der Protokolle > auf dem Internet empfehlen? Bitteschön: http://de.wikipedia.org/wiki/Request_for_Comments
Datum:
fail2ban deckt auch solche unerwünschten Anfragen ab. Mit [pam-generic] kannst Du auch solche "Did not receive identification string"-Anfragen bannen lassen.
Datum:
Danke für den Hinweis, aber die Anfragen selbst sind kein Problem. Mich interessiert vor allem, was die Brüder damit bezwecken. Denkbar wäre, daß es eine Art ping an Server ist, die kein ping akzeptieren, aber dazu würde auch ein Login-Versuch ausreichen - kommt mir wenig plausibel vor. Solche Lawinen dieser Anfrag, wie im Eingangsposting sind übrigens auf meinem Server sehr selten. Meist kommen mit größerem Abstand 1, 2 solcher Pakete und dann kommt irgendwann eine Bruteforce-Attacke auf den ssh-Zugang, die dann an fail2ban scheitert.
Datum:
Uhu Uhuhu schrieb: > Ich beobachte immer wieder Sequenzen in der auth.log, wie diese: > > [pre] > Dec 18 07:27:25 h2847680 sshd[7879]: Did not receive identification > string from 220.125.223.160 > ... > Kann sich jemand einen Reim darauf machen, was das soll? Da keine Identifizierung gesendet wurde, nehme ich an, dass die nur einen Portscanner oder sowas durchrattern haben lassen. Dies ist wohl noch kein Grund zur Besorgnis. Sobald sie Logins/Passwörter durchprobieren, siehst Du im Logfile dann die entsprechenden Usernamen und die erfolglosen Versuche. Wenn richtig konfiguriert, sind Linux/BSD basierte Server ziemlich imun gegen solche Angriffe, auch ohne Zusatztools. Vorausgesetzt natürlich, dass die Passwörter genügend lang sind oder wie schon erwähnt, mit dem Public-Key-Verfahren gearbeitet wird. Von Zusatztools um die Sicherheit zu steigern würde ich die Finger lassen, lieber das System regelmässig mit den neusten Updates versorgen.
Datum:
Uhu Uhuhu schrieb: > Mich interessiert vor allem, was die Brüder damit bezwecken Stell einen Honeypot auf ;) Verlege den Port, leite den attakierten Port an eine andere Maschine (VM) um und vergebe dieser ein Deppenpasswort z.b. 12345 und schau was die auf der Maschine machen.
Datum:
Johnny B. schrieb: > Da keine Identifizierung gesendet wurde, nehme ich an, dass die nur > einen Portscanner oder sowas durchrattern haben lassen. Dann wären mehr Pakete zu erwarten - es sind aber bei denen, die den ssh-Zugang knakenwollen, höchstens 2. > Dies ist wohl noch kein Grund zur Besorgnis. Das sehe ich auch so, mein Motiv ist reine Neugier. Martin schrieb: >> Mich interessiert vor allem, was die Brüder damit bezwecken > > Stell einen Honeypot auf ;) Ich glaube nicht, daß die an den Honeypot eine Beschreibung ihrer Vorgehensweise schicken würden. Was sie letztlich wollen ist klar: den Server übernehmen und für irgendwelche Sauereien gegen seine Nutzer mißbrauchen. Die usernamen, die bei solchen Attacken durchprobiert werden, sind in erster Linie root, phpmyadmin in vielen Varianten und dann irgendwelche Onlinespiele.
Datum:
Uhu Uhuhu schrieb: > Johnny B. schrieb: >> Da keine Identifizierung gesendet wurde, nehme ich an, dass die nur >> einen Portscanner oder sowas durchrattern haben lassen. > Dann wären mehr Pakete zu erwarten - es sind aber bei denen, die den > ssh-Zugang knakenwollen, höchstens 2. Ne, die wollen ja den Zugang (noch) nicht knacken, sondern nur schauen, welche Ports offen sind, bzw. auf welche Ports sie sich verbinden können. Da reicht es, nur eine TCP-Verbindung auf einen Port zu öffnen ohne Daten zu senden. Gelingt das, dann weiss der potentielle Angreifer, dass da der Server horcht; ein Portscanner eben. Der eigentliche Angriff geschieht dann erst in einem weiteren Schritt und kann dann gut in den Logfiles erkannt werden und beinhaltet im Falle von SSH dann auch den Benutzernamen.
Datum:
Johnny B. schrieb: > Ne, die wollen ja den Zugang (noch) nicht knacken, sondern nur schauen, > welche Ports offen sind, bzw. auf welche Ports sie sich verbinden > können. Für einen Portscan müßten sie die Ports mit einer Anfrage je Port durchtesten. Aber womöglich sehe ich das im Log auch nicht. > Da reicht es, nur eine TCP-Verbindung auf einen Port zu öffnen ohne > Daten zu senden. Gelingt das, dann weiss der potentielle Angreifer, dass > da der Server horcht. Dazu muß man keine verkrüppelte Anfrage schicken, sondern kann einfach gleich loslegen mit dem Angriff.
Datum:
Uhu Uhuhu schrieb: > Johnny B. schrieb: >> Ne, die wollen ja den Zugang (noch) nicht knacken, sondern nur schauen, >> welche Ports offen sind, bzw. auf welche Ports sie sich verbinden >> können. > > Für einen Portscan müßten sie die Ports mit einer Anfrage je Port > durchtesten. Aber womöglich sehe ich das im Log auch nicht. > >> Da reicht es, nur eine TCP-Verbindung auf einen Port zu öffnen ohne >> Daten zu senden. Gelingt das, dann weiss der potentielle Angreifer, dass >> da der Server horcht. > > Dazu muß man keine verkrüppelte Anfrage schicken, sondern kann einfach > gleich loslegen mit dem Angriff. Uhu, sorry, aber habe noch selten so einen Schwachsinn gelesen von Dir. Es macht wohl keinen Sinn, eine Bruteforce Attacke auf einen Port zu starten, hinter welchem vielleicht gar kein SSH Daemon sitzt. Daher scannt man ja erst die Ports ab, bis man den gewünschten Angriffspunkt gefunden hat. Ein 0815 Einbrecher guckt sich ja das Haus in das er einsteigen will auch erst mal an, bevor er einbricht. Eventuell steht ja schon ein Fenster offen, dann macht es wenig Sinn, erst noch die Terassentür aufzubrechen. Viele gescheite Administratoren haben SSH nicht auf Port 22 konfiguriert, sondern irgendeinem anderen Port, um die grosse Masse an ganz doofen Angreifern scheitern zu lassen.
Datum:
Johnny B. schrieb: > Es macht wohl keinen Sinn, eine Bruteforce Attacke auf einen Port zu > starten, hinter welchem vielleicht gar kein SSH Daemon sitzt. Man kriegt doch eine Antwort, wenn man versucht sich auf einem Port einzuloggen, auf dem ssh lauscht. > Daher scannt man ja erst die Ports ab, bis man den gewünschten > Angriffspunkt gefunden hat. Portscans sehe ich nicht im auth.log. Was ich sehe, sind 1 bis 2 inkorrekte Anfragen an den ssh-Port, bevor eine Bruteforce Attacke gestartet wird und das zwar bei vielen, aber längst nicht bei allen Attacken. > Ein 0815 Einbrecher guckt sich ja das Haus in das er einsteigen will > auch erst mal an, bevor er einbricht. Sorry, aber was muß der denn noch wissen, außer daß auf dem ssh-Port auch wirklich ssh lauscht? Er versuchts einfach und wenn die erwartete Antwort kommt, dann fängt er eben eine Liste von Login-Namen jeweils mit einer Liste von Paßworten durchzunudeln und wenn er bei einer Kombination eine positive Antwort bekommt, ist der drin. Wo ist das Problem? Wo ist der Schwachsinn, den du diagnistizierst? > Viele gescheite Administratoren haben SSH nicht auf Port 22 > konfiguriert, sondern irgendeinem anderen Port, um die grosse Masse an > ganz doofen Angreifern scheitern zu lassen. Du hast es immer noch nicht verstanden: ich habe keine Sorge um meinen Server, denn alle Ports auf denen was hängt sind hinreichend abgesichert. Ich finde es nützlich, die Quellserver, von denen solche Attacken ausgehen, an die abuse-Adresse des Providers zu melden, daß diesen Zombies das Handwerk gelegt wird, denn die wollen nicht "nur spielen", sondern haben kriminelles mit gekaperten Servern vor. Im Prinzip könnte man jeden Server zu einem Gelegenheits-Honeypot machen, der automatisch entsprechende Mails verschickt. Der Aufwand dafür ist ausgesprochen gering und jeder Zombie, der stillgelegt wird, ist eine Gefahr weniger.
Datum:
Johnny B. schrieb: > Viele gescheite Administratoren haben SSH nicht auf Port 22 > konfiguriert Das wird übrigens durch einen Portscan unwirksam gemacht: der Angreifer stellt mit dem Scan fest, auf welchem Port eine Reaktion kommt und versucht dann dort sein Glück.
Datum:
Jetzt bin ich dahinter gekommen: Es sind TCP SYN Scans - du hattest also doch recht. Nur heißt das, daß man sich durch einen anderen ssh-Port nur die Einbrecher vom Hals halten kann, die keinen Scan durchführen, sondern es einfach nur auf gut Glück an Port 22 versuchen. Gegen die Scanner kann man sich mit Port-Knocking abschirmen.
Datum:
Uhu Uhuhu schrieb: > Ich finde es nützlich, die Quellserver, von denen solche Attacken > ausgehen, an die abuse-Adresse des Providers zu melden, daß diesen > Zombies das Handwerk gelegt wird, denn die wollen nicht "nur spielen", > sondern haben kriminelles mit gekaperten Servern vor. Und diese Koreaner und Chinesen sollen dann also in ihre gut geflegte und von dir sicherlich nie kritisierte Vorratsdatenspeicherung reinsehen und dem entsprechenden Kunden auf die Finger klopfen?
Datum:
A. K. schrieb: > Und diese Koreaner und Chinesen sollen dann also in ihre gut geflegte > und von dir sicherlich nie kritisierte Vorratsdatenspeicherung reinsehen > und dem entsprechenden Kunden auf die Finger klopfen? An die schick ich keine Mails, weil das sinnlos ist. Wenn die Einbruchsversuche aber von einem Server bei meinem Provider kommen, dann ist das durchaus sinnvoll und führt i.d.R. dazu, daß die Zombies recht schnell stillgelegt werden. Wenn man aber die Mails automatisch generiert, dann wären auch der Aufwand für die Asiaten egal.
Datum:
Ich weiss nicht, Deine Bemühungen mit dem Melden der Bösen Buben sind zwar Ehrenswert, jedoch nützt das praktisch nichts. In Zeiten von Bot-Netzwerken und ferngesteuerten Zombie Rechnern kann man damit wohl nicht mehr viel ausrichten. Meiner Meinung nach braucht man normalerweise ausser den Linux Boardmitteln keine weitere Software um sich gegen Angriffe zu schützen. Am wichtigsten sind regelmässige Upodates des Betriebssystems und gescheite Usernamen/Passwörter oder Verwendung von Keys. Damit sollte man bereits sehr sicher unterwegs sein.
Datum:
Johnny B. schrieb: > In Zeiten von Bot-Netzwerken und ferngesteuerten Zombie Rechnern kann > man damit wohl nicht mehr viel ausrichten. Es handelt sich überwiegend um Strato-Server, die offenbar feindlich übernommen wurden. Es gibt zwar einen harten Kern, der immer mal wieder unter den bösen Buben ist, überwiegend sehe ich aber "Neulinge" in dieser Disziplin. Gekaperte PCs zu melden ist ziemlich nutzlos. > Damit sollte man bereits sehr sicher unterwegs sein. Darauf will ich nicht mehr eingehen - das hab ich hier schon hundermal durchgekaut.
Datum:
Sind die Strato-Server immer noch 'aktiv' oder hat Strato da schon entsprechend reagiert. Das dürfte ja etliche Server betroffen haben...
Datum:
Die reagieren und ja, es sind in der Tat etliche und überraschenderweise kommen deutlich mehr als die Hälfte der Attacken das den IP-Blocks von Strato. Ich vermute, daß die Zombies so programmiert sind, daß bevorzugt im Providerblock ihr Unwesen treiben - ist für die Ganoven ja auch viel interessanter, als Lieschen Müllers Klapper-PC. Strato hält sich nur darüber bedeckt, was sie wirklich machen - aus Datenschutzgründen. Es scheint aber so, daß sie tatsächlich was unternehmen, denn wenn nach einer Woche der Bann auf meinem Server für einen Zombie abgelaufen ist, kommt fast nie direkt wieder einer der Kandidaten. Bis ein Wiederholungstäter es wieder versucht, vergehen meist einige Wochen. Das sind wohl die, deren Admin es nicht schafft, den Server ordentlich abzuschotten. Unter den Zombies waren übrigens schon mehrmals irgenwelche Finanzportale - wie seriös die waren, weiß ich nicht - und einmal eine Spedition. Solche Server sind natürlich für drive-by-Attacken auf die Kunden der Portale interessant.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten