IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Hacking (Seite 2 von 2)

Brute-Force Angriffe auf Joomla

Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.

Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!

Siehe auch: SSH-Server absichern mit MFA

Fragen? Einfach melden.

Mal wieder auffällig viele Brute-Force SSH Angriffe….

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme.

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann. Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Siehe auch: SSH-Server absichern mit MFA, SSH Brute Force, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi, SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen​

Fragen? Einfach melden.

Heartbleed Bug: Was du darüber wissen musst und wie du dich schützt

Heartbleed OpenSSL vulnerability logo

Au man… Das ist ja der Hammer! Wie konnte denn bitte dieser Scheiß passieren? Zum Glück war mein System noch auf der Version 0.9… Aber keine Sorge, ich muss an genug anderen Systemen neue Schlüssel erstellen und die Anwender zu neuen Kennwörter „überreden“.

Das ist einer der größten Löcher die ich bisher gesehen habe und wer hat es gefunden? Google…. Ö_ö

Disbelief reaction meme about Heartbleed bug

Hier muss nun unbedingt ein Plan her für besseren Code Audit, richtig? Ich habe sogar bereits von Exploids gelesen, welche noch vor dem Bekanntwerden im Umlauf gewesen sein sollen. Alle Systeme mit den bösen Versionsständen müssen also als kompromittiert angesehen werden. Ich habe nun schon mit einigen Leuten darüber gesprochen und in diesem Punkt stimmen mir die Meisten zu, bis zu dem Punkt an welchem die damit verbundenen Konsequenzen klar werden. Also neue Schlüssel bauen, von der CA signieren lassen, einbinden, allen Anwendern neue Kennwörter zuschieben usw. usw. usw… Denn mit dem einspielen der Patches ist zwar das Loch gestopft, die möglicherweise abgeschnorchelten und vielleicht bereits missbrauchten Daten sind damit noch nicht zurückgeholt. Denn noch tun sich hier einige Entscheider schwer..

Richtig unangenehm wird es, wenn man daran denkt das in der Vergangenheit aufgezeichnete -verschlüsselte- Daten mit dem vielleicht eingesammelten privaten Schlüssel nun entschlüsselt werden können. Es sei denn Perfect Forward Secrecy war aktiviert. Das ist wohl das Gute an der ganzen Nummer. Man hat nun nicht nur einen theoretischen Grund um PFS einzuführen.

Also weiter machen!

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

SSH Brute Force

Es ist ja nicht zu glauben… Da scheint eine ganze Chinabude nichts weiter zutun zu haben als SSH Burte Force Attacken durchlaufen zu lassen. Dieser Netzowner geht mir gerade tierisch auf die Nerven. Ich bekommen durchgehen Angriffe aus Netzen bei dem er der Eigentümer ist. Das ist im Moment auch echt massiv 🙁

netname: CHINANET-JS
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: CJ186-AP
mnt-by: MAINT-CHINANET
mnt-lower: MAINT-CHINANET-JS
mnt-routes: maint-chinanet-js
changed: hostmaster@ns.chinanet.cn.net 20020209
changed: hostmaster@ns.chinanet.cn.net 20030306
status: ALLOCATED non-PORTABLE
source: APNIC

role: CHINANET JIANGSU
address: 260 Zhongyang Road,Nanjing 210037
country: CN
phone: +86-25-86588231
phone: +86-25-86588745
fax-no: +86-25-86588104
e-mail: ip@jsinfo.net
remarks: send anti-spam reports to spam@jsinfo.net
remarks: send abuse reports to abuse@jsinfo.net
remarks: times in GMT+8
admin-c: CH360-AP
tech-c: CS306-AP
tech-c: CN142-AP
nic-hdl: CJ186-AP
remarks: www.jsinfo.net
notify: ip@jsinfo.net
mnt-by: MAINT-CHINANET-JS
changed: dns@jsinfo.net 20090831
changed: ip@jsinfo.net 20090831
changed: hm-changed@apnic.net 20090901
source: APNIC
changed: hm-changed@apnic.net 20111114

person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: anti-spam@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: dingsy@cndata.com 20070416
mnt-by: MAINT-CHINANET
source: APNIC

 

 



Siehe auch: SSH-Server absichern mit MFA, Mal wieder auffällig viele Brute-Force SSH Angriffe…., Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi

Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑