Ich beobachte immer wieder Sequenzen in der auth.log, wie diese:
1
Dec 18 07:27:25 h2847680 sshd[7879]: Did not receive identification string from 220.125.223.160
2
Dec 18 07:27:25 h2847680 sshd[7878]: Did not receive identification string from 121.238.96.217
3
Dec 18 07:27:46 h2847680 sshd[7880]: Did not receive identification string from 119.193.35.161
4
Dec 18 07:28:09 h2847680 sshd[7882]: Did not receive identification string from 121.191.60.54
5
Dec 18 07:28:50 h2847680 sshd[7883]: Did not receive identification string from 121.238.96.133
6
Dec 18 07:28:55 h2847680 sshd[7884]: Did not receive identification string from 59.28.161.52
7
Dec 18 07:29:05 h2847680 sshd[7887]: Did not receive identification string from 119.200.110.25
8
Dec 18 07:29:08 h2847680 sshd[7888]: Did not receive identification string from 14.56.157.160
9
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?
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.
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.
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?
fail2ban deckt auch solche unerwünschten Anfragen ab.
Mit [pam-generic] kannst Du auch solche "Did not receive identification
string"-Anfragen bannen lassen.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten