107 login attemps

[adjustman]

Auszug

Code: Select all

Jan  5 16:04:41 server1 sshd[545]: Failed password for root from 202.56.254.98 port 37826 ssh2
Jan  5 16:04:46 server1 sshd[550]: Failed password for root from 202.56.254.98 port 37900 ssh2
Jan  5 16:04:52 server1 sshd[553]: Failed password for root from 202.56.254.98 port 37961 ssh2
Jan  5 16:04:57 server1 sshd[557]: Failed password for root from 202.56.254.98 port 38033 ssh2
...
Jan  5 16:05:10 server1 sshd[698]: Failed password for root from 202.56.254.98 port 38210 ssh2
Jan  5 16:05:15 server1 sshd[761]: Failed password for root from 202.56.254.98 port 38296 ssh2
Jan  5 16:05:19 server1 sshd[780]: Failed password for root from 202.56.254.98 port 38358 ssh2
Jan  5 16:05:24 server1 sshd[782]: Failed password for root from 202.56.254.98 port 38423 ssh2
Jan  5 16:05:29 server1 sshd[786]: Failed password for root from 202.56.254.98 port 38493 ssh2
Jan  5 16:05:33 server1 sshd[788]: Failed password for root from 202.56.254.98 port 38555 ssh2
Jan  5 16:05:38 server1 sshd[792]: Failed password for root from 202.56.254.98 port 38615 ssh2
Jan  5 16:05:43 server1 sshd[794]: Failed password for root from 202.56.254.98 port 38681 ssh2
Jan  5 16:05:48 server1 sshd[798]: Failed password for root from 202.56.254.98 port 38746 ssh2
Jan  5 16:05:53 server1 sshd[800]: Failed password for root from 202.56.254.98 port 38808 ssh2
Jan  5 16:05:57 server1 sshd[804]: Failed password for root from 202.56.254.98 port 38884 ssh2

[alexander newald]

Liegt evtl. an der einstelligen Datumszahl (Tag). Mal das Update von der Webseite ausprobieren.

[adjustman]

Liegt evtl. an der einstelligen Datumszahl (Tag). Mal das Update von der Webseite ausprobieren.

ja, danke. Jetzt gehts. Es werden IPs geschrieben. :) d.h. es schiebt einen Prozess an (Auszug)

Code: Select all

Jan 6 19:35:12 Bad password for               irc from 213.112.249.240 on server1
Jan 6 19:35:14 Bad password for               root from 213.112.249.240 on server1

der aber nicht "fertig" wird. Erst durch Strg+c wird er beendet. Funktioniert das dann trotzdem?

[alexander newald]

Die Frage verstehe ich nicht - Sorry

[adjustman]

ok, nochmal langsam
Beim Aufruf von ./check_logins --daemon wird das Log ausgelesen und auch auf der Shell die Resultate angezeigt.
Dann bleibt der Cursor stehen und es geht nicht mehr weiter.
Erst Strg+c kehrt zum Prompt zurück. Dann sind etliche IPs in /root/.check_ips/ip_block zusehen.
Diese sind dann aber nach ner Zeit X wieder verschwunden. Besser ausgedrückt? :oops: Die Frage ist, ob das so normal ist?

[alexander newald]

ja

[adjustman]

ich hab das jetzt ne Weile beobachtet. IMO geht das ein, zwei Tage, dann nicht mehr. Das Script (als Daemon) läuft aber. @Alexander, weisst Du da näheres? danke.

[distanzcheck]

habe es nun soweit am Laufen mit Suse 9.0

bekomme aber auf zwei Servern nach dem na einigen gefundenen Login Versuchen aus der messages log folgende Fehlermeldung

Code: Select all

/etc/modules.conf.local is more recent than /lib/modules/2.4.25/modules.dep

sind da in der messages zuviele Login Versuche oder woran liegt das ?

Dirk

[distanzcheck]

und noch eine frage ist das messages log bei suse 9.0 das richtige log zur auswertung ?

Dirk

[squize]

Kommt darauf an, ob die ssh Einträge in /var/log/messages stehen oder nicht.
Es ist aber auf jeden Fall besser sich ein eigenes Logfile dafür zu generieren, so dass das Skript nicht zuviele Einträge parsen muss, was die Last natürlich erhöht.
Einstellen kannst du das in /etc/syslog.conf

Gruss

Marc

[host4you]

Also ich habe das Script auf einem debian 3.0 laufen....
Soweit so gut, nur habe ich eine frage, und zwar wenn ich die ip_block leere und die pos, und dann das script erneut starte schreibt er die anzahl der login versuche in pos, soll ja auch so sein. Aber in ip_block taucht keine IP auf und in den iptables sind auch keine chains erstellt worden.

Nun stellt sich für mich die frage ob das original so ist.

Das script läuft bei mir als daemon

Hier mal ein auszug aus meiner auth.log

Code: Select all

Feb 28 07:27:10 Bad password for               root from 134.86.254.6 on server7
Feb 28 07:27:14 Bad password for               root from 134.86.254.6 on server7
Feb 28 07:27:19 Bad password for               root from 134.86.254.6 on server7
Feb 28 07:27:24 Bad password for               root from 134.86.254.6 on server7
Feb 28 07:27:34 Bad password for               www from 134.86.254.6 on server7
Feb 28 07:27:44 Bad password for               www from 134.86.254.6 on server7
Feb 28 07:27:56 Bad password for               www-data from 134.86.254.6 on server7
Feb 28 07:28:07 Bad password for               mysql from 134.86.254.6 on server7

Und hier der auszug nachdem das Script die auth.log gescannt hat und "angeblich gesperrt" hat

Code: Select all

Feb 28 06:31:12 server7 logger: Sperren von  163.13.129.78
Feb 28 06:31:12 server7 logger: Sperren von  65.254.58.66
Feb 28 06:31:13 server7 logger: Sperren von  217.215.31.40
Feb 28 06:31:13 server7 logger: Sperren von  217.209.129.89
Feb 28 06:31:13 server7 logger: Sperren von  161.24.15.138
Feb 28 06:31:13 server7 logger: Sperren von  163.13.129.78
Feb 28 06:31:13 server7 logger: Sperren von  65.254.58.66
Feb 28 06:55:49 server7 -- MARK --
Feb 28 07:08:37 server7 logger: Sperren von  134.86.254.6
Feb 28 07:09:08 server7 last message repeated 31 times
Feb 28 07:10:09 server7 last message repeated 60 times

Aber wie oben beschrieben taucht nichts in den iptables auf :( das timeout habe ich derzeit auf 24 Stunden gestellt...


PS: Danke Alexander für das Script :)[/code]

[alexander newald]

Der Pfad im Script zu IPTables stimmt?

[host4you]

Ahhhhh da war doch noch was ;)

In deinem Script stand /usr/sbin/iptables

Auf meinem Server ist es.....

Code: Select all

server7:/home/xxxxx# which iptables
/sbin/iptables
server7:/home/xxxxx#

Danke Dir, ich habs mal geändert und warte jetzt das man mich attackiert ;)

Ich werde das script nachher mal auf meine anderen 6 Server installieren und dann mal schauen was sich tut ;)


NACHTRAG:

Die pos Datei wird von der Anzahl größer, aber es tut sich nichts. Worauf bezieht sich die pos Datei ?

[alexander newald]

Die speichert die letzt Position in der Logdatei, damit die nicht jedesmal von vorne durchsucht werden muss.

[host4you]

Ah okay.... klingt logisch ;)

[claim]

Auch, wenn das vielleicht ein bisschen wie ein Troll klingen mag, aber macht dieses Skript denn überhaupt so viel Sinn?

Wir waren uns doch einig, dass die meisten dieser Angriffe automatisiert von Client-Rechnern aus erfolgen, also von beliebigen Rechnern auf dem Planeten, die dynamisch (insbesondere mit variabler IP) an das Internet angebunden sind. In den wenigsten Fällen (vielleicht 2% - wenn überhaupt) der Fälle werden die Angriffe von einem Rechner mit statischer IP aus gefahren.

Die Folge ist doch dann, dass man säckeweise IPs blockt, die in einer Stunde eh wieder jemand anderem gehören.

Meiner Erfahrung nach ist es wesentlich wirkungsvoller, statt IP-Adressen Hostnames zu erheben und sich täglich mögliche Einbruchsversuche automatisch selbst zuzumailen. Anhand der letzten paar Domains in den Log-Einträgen kann man in der Regel den Provider identifizieren und danach eine entsprechende Mail mit den relevanten Logdaten und einer kurzen Bitte um Aufklärung der Vorfälle an abuse@provider.xyz schicken.

Das hat in mehrern Fällen schön Antworten gegeben wie "Wir haben den Nutzer verwarnt und werden bei Wiederholung den Account kündigen.".
Die Geschichte ist übrigens nicht nur für Logins, sondern auch bei Mailservern interessant (Spamming).

Viele liebe Grüße!
Claim

[floschi]

Wenn du soviel Zeit hast, warum nicht?

Ich störe mich letztendlich an den ellenlangen Listen die mein Logwatch erzeugt und durch ein einfaches iptables Skript sind die enorm zurückgegangen. Für mich reicht das.

[alexander newald]

@Clain

Was nützt es, wenn der Angreifer dann doch mal ein Passwort findet?

[claim]

Ist man in dem Fall nicht ohnehin boned?

Falls jemand ein Passwort erfolgreich errät, ist Holland in Not. Da kann man eigentlich nur im Voraus die Shell-Accounts auf ein absolutes Minimum drücken (und drastisch in den Rechten beschneiden), einloggen per root verbieten und für die wheeled accounts ordentliche Passwörter benutzen.

Oder habe ich etwas verpasst, wie eine IP-Sperre dagegen helfen kann? Dauern Einbrüche denn lange genug, um einen vernünftig getimeten Cronjob zu benutzen? Die Lösung kann ja nicht sein, 24/7 auf den Logs rumzuhämmern...

[alexander newald]

Doch, es ist eine Lösung, die Logs zu durchsuchen und dann die IPs einige Zeit zu sperren.

[claim]

Moment: Ich habe nicht gesagt, dass es keinen Sinn macht, die Logs zu durchforsten. Ich habe lediglich angemerkt, dass es keinen Sinn macht, staendig in die Logdaten zu sehen, um quasi jede "aktuell" zugreifende IP auf Missbrauchsversuch zu pruefen. Das ist doch ein absolut inakzeptabler Performanceverlust.

Es muss doch irgendwie verhaeltnismaessig sein. Ich meine: wenn jemand einbricht, muss in angemessener Zeit reagiert werden. Wenn ein Cron-Job nur jede Stunde einmal nachsieht und der Angreifer weniger als eine Stunde braucht, ist die Wahrscheinlichkeit doch hoch, dass der Angreifer von der Sperre gar nicht mehr tangiert wird. Das Pruefintervall deutlich zu reduzieren, heisst wiederum Performance zu verlieren. Daher meine Frage, ob dann eine IP-Sperre so sinnvoll ist.

Ich will hier ja niemanden aergern - ich sage nur, was mir dazu einfaellt. Wenn jemand mit dieser Methode Angriffswellen einschraenken kann, ist ja alles in Ordnung. Ich habe halt mit meiner Variante auch schon Erfolge erzielt.