Massive Passwortattacken auf Rootserver

[llaehn]

Hallo,

ich habe an drei verschiedenen Rootserver von unterschiedlichen Inhabern festgestellt, das diese seit einigen Tagen massiven Paswortattacken ausgesetzt sind. Aus der auth.log geht hervor, dass sich jemand per ssh anmelden möchte, benutzername ändert sich ständig.

Als quellsystem habe ich häufig andere 1&1 Rootserver bzw. den 1&1 Ip-Adressbereich 217.160... festgestellt.

Jeder der einen Rootserver hat, sollte vielleicht mal seine logs prüfen.


lars

[captaincrunch]

Bis auf die Tatsache, dass da 1&1-Rooties mit von der Partie sind ein alter Hut. ;) Eine Liste wäre mal ganz interessant.

[chaosad]

naja bei simplen Passwortattacken mach ich mir jetzt weniger Gedanken. Es sei denn es werden irgendwann wirklich zuviele. Aber ansonsten :)

[andreask2]

Wobei das irgendwie immer mehr wird, inzwischen habe ich teilweise weit über 10.000 versuche am Tag.

[stefanpropehan]

Wobei das irgendwie immer mehr wird, inzwischen habe ich teilweise weit über 10.000 versuche am Tag.

Da kann ich dir nur recht geben... ich habe auch das Gefühl das ich nach dem ich die IP-Adresse hier im Forum aufgrund eines Problems gepostet hatte, es massiv mehr wurde. Also kein automatisches absuchen bestimmter IP-Ranges, sonder gezielte "Attacken".

[chaosad]

ja aber obs daran liegt? Das nächste mal die IP vielleicht nicht preisgeben, dann kann man schon ein wenig vorbeugen. Aber wenns jemand drauf anlegt kriegt er die IP auch irgendwie raus.

[chris76]

Da kann ich dir nur recht geben... ich habe auch das Gefühl das ich nach dem ich die IP-Adresse hier im Forum aufgrund eines Problems gepostet hatte, es massiv mehr wurde. Also kein automatisches absuchen bestimmter IP-Ranges, sonder gezielte "Attacken".

Das kann ich mir fast nicht vorstellen. Bei den vier Server für die ich zuständig bin, sind zwei bei 1und1 (verschiedene Subnets) einmal Strato und einmal VD-Server. Bei allen "Attacken" nach dem gleichen Muster und in der gleichen Menge.

[stefanpropehan]

Wie schon geschrieben "dem Gefühl" nach... es kann natürlich auch gut sein, das dies mit der generellen Erhöhung der Passwortattacken zusammenfällt.

Mein erster Server wird beim Hoster mit dem "S" gehostet, mein zweiter Server hat eine feste IP über eine Standleitung von einem Telekomunikationsanbieter. Dort sind Passwortattacken kaum zu registrieren... was damit wirklich auf das Scannen bestimmter IP-Ranges der großen Hoster zurückzuführen ist.

Stefan

[ticool]

Hattest du nicht geschrieben, dass die Attacken von mehrer 1und1 Servern ausgehen?

Wie siehts denn mit einer Abuse Meldungs aus?

[andreask2]

ich habe auch das Gefühl das ich nach dem ich die IP-Adresse hier im Forum aufgrund eines Problems gepostet hatte, es massiv mehr wurde.

Nein, ich habe meine IPs noch nicht gepostet, und habe dasselbe Problem. Vor einigen MOnaten waren das hin und wieder mal ein paar Versuche, inzwischen hat es sich halt vervielfacht, vermutlich deshalb weil die Erfolgsaussichten bei diesen Versuchen gar nicht so schlecht sind. Ich würde in jedem Fall Root-Login verbieten, und allen anderen public-key Verfahren vorschreiben. Dann muss man sich hier keine Sorgen machen.

Also kein automatisches absuchen bestimmter IP-Ranges, sonder gezielte "Attacken".

Das glaube ich nicht.

Und ich hatte auch schon mehrfach IPs von anderen Root-Servern als "Angreifer", bisher war es aber immer so, dass der entsprechende Server selber geknackt worden war.

[alexander newald]

Bei meinen Servern ist es rückläufig: http://linux.newald.de/temp/block_ssh-month.png

Ein paar Zugriffe aus dem Bereich 160.140.x.x habe ich auch dabei, allerdings so wenig, dass ich eher sagen würde, das ist vernachlässigbar

[lord_pinhead]

Ã?nder den Port und mach was andreask2 gesagt hat (Pubkey und Rootlogin sperren), dann sollen sie nur kommen. Das sind wahrscheinlich wieder ein paar Kiddies die Stro´s brauchen, setz eine Abuse ab und Sperr am besten deren IP Ranges per IPTables, sodass sie überhaupt nicht mehr auf die ssh kommen, egal welchen Port du nimmst. Dann ist ruhe und du kannst wieder schlafen ;)

[bungeebug]

spitzen lösung...

dann sperr am besten noch die komplette t-online range da sind die meisten bei .... wie du hast selber t-online? ach is nich so wichtig, sperrste dich eben selbst aus.


schwachsinn

[lord_pinhead]

Ich hatte nie gesagt er soll T-Online Ranges aussperren. Wenn du genau liest siehst du es. Wenn es Dialin Verbindungen sind von 1&1, haben die immer die selbe Range da diese Gebietsabhänging sind. Und Rootserver haben sowisso immer feste Adressen, also ist das kein Problem. Das Script von Alexander ist natürlich die beste Lösung, da braucht man das gar nicht mehr per Hand machen.

Also mal ein bischen nachdenken bevor man losbrüllt, es hat schon seinen Sinn ;)

[alexander newald]

Für mein Script zum Blocken der Logins gibt es übrigens ein Update

[chaosad]

hab ich was überlesen? :) wo gibts denn nen link zu deinem Skript? Würd ich mir mal gerne anschauen.

[andreask2]

Vielleicht sollte Alexander das mal in diesem Themenbereich posten: http://www.rootforum.org/forum/viewforum.php?f=30

[alexander newald]

Kann man aber nur als Admin von diesem Forum...

[chris76]

Kann man aber nur als Admin von diesem Forum...

Wenn dein Projekt dem hier entspricht
http://www.rootforum.org/forum/viewtopi ... 8400#88400
melde dich beim Team und dann wird darüber entschieden

[Anonymous]

hab ich was überlesen? :) wo gibts denn nen link zu deinem Skript? Würd ich mir mal gerne anschauen.

ich hab das auch überlesen :-D
Kann nicht mal jemand einen Link zu dem Skript posten?

lg,
Stefan
http://www.online-bummeln.de

[alexander newald]

http://linux.newald.de/new_design/login_check.html

[nyxus]

http://linux.newald.de/new_design/login_check.html

Kannst Du mal mit ein paar Worten erzählen warum Du diese Portweiterleitung machst?

[andreask2]

Würde auch mal interessieren (mal abgesehen von "Logs werden vollgemüllt"). Wofür lohnt es sich ein zusätzliches Risiko ins System zu holen?

[alexander newald]

Wenn man den SSH Port sperrt, und die Loginversuche weitergehen, dann hat man immer wieder "Fenster", in denen der SSH Port freigegeben wird und erst wieder einige Loginversuche stattfinden müssen, bis der SSH Port wieder gesperrt ist. Somit hat ein Angreiffer immer noch die Möglichkeit alle Möglichkeiten durchzuprobieren - Es dauert nur länger.

Bei der von mir genutzten Lösung werden Verbindungsversuche auf Port 2222 als Angriff gewertet und die IP weiterhin geblocket.

Der Port 2222 wird per UID 65535 und eigenen fork() geöffnet:

Code: Select all

sub daemon_blocked {
	#
	# Accept connections of blocked ips and count them
	#
        $< = 65535;
        $( = 65535;
        $> = 65535;
        $) = 65535;
	$server = IO::Socket::INET->new(LocalPort => $server_port,
	                                Type      => SOCK_STREAM,
	                                Reuse     => 1,
	                                Listen    => 10 );
	#
	# Check if a socked could be opened
	#
	if ($@ eq "IO::Socket::INET: Address already in use") {
	        die "Port already in use";
	        }

	while ($client = $server->accept()) {
		my $client_ip = $client->peerhost();
		while($childs >= $maxclients) {
			select(undef, undef, undef, 0.25);
			}
		$childs_handle->shlock();
		if ($childs < 0) { $childs = 0; }
		++$childs;
		$childs_handle->shunlock();
		if (!fork) { blocked_child($client_ip); }
		}
	}

[aldee]

Steht doch auf der Seite. Während des Zeitraums, in dem Verbindungen zu Port 22 blockiert werden, hat man nicht die Möglichkeit festzustellen, ob die Loginversuche weitergehen. Daher biegt er jetzt statt einer Sperre einfach bei danebengegangenen Loginversuchen den Port-22-Traffic von den betreffenden IPs auf einen anderen Port um und setzt bei weiteren Verbindungsversuchen einfach den Zeitraum, in dem diese Umbiegerei bestehen bleibt, wieder auf den Ursprungswert hoch.

Edit: Ups, zu langsam :-).

Hat eigentlich Perl ein SSH-Server-Modul parat? Es bietet sich ja förmlich an, das Ding zu einer Art Honeypot zu erweitern, um zu sehen, was auf dem Server eigentlich getrieben werden sollte.