Hilfe die Chinesen hacken mich...

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hey,

    hab seit gestern einen Raspberry Pi3 und mach meine ersten Erfahrungen.

    Bisher alles per Fernverwaltung mit SSH und xrdp bzw. rdesktop. Ubuntu Mate

    Apache2 eingerichtet und eine DNS-Adresse zugewiesen von dnshome.de. und ports 22(ssh), 3389(xrdp) und 80 auf den Pi geleitet,

    Bei den Prozessen fiel auf, dass SSH da einigen Ressourcen nimmt, deswegen ich nach dem logs geguckt habe.

    Code
    Jun 12 23:25:33 pi sshd[24633]: Failed password for root from 121.18.238.10 port 58681 ssh2
    Jun 12 23:25:33 pi sshd[24643]: Failed password for root from 121.18.238.11 port 43719 ssh2
    Jun 12 23:25:35 pi sshd[24643]: Failed password for root from 121.18.238.11 port 43719 ssh2
    Jun 12 23:25:35 pi sshd[24633]: Failed password for root from 121.18.238.10 port 58681 ssh2

    Und das geht ellenlang soweiter

    Sieht aus wie ne Bruteforce-attacke. Deswegen kurz danach den Pi heruntergefahren und vom Stecker gezogen. Werde aufjedenfall in Zukunft ein härteres Passwort wählen ^^ die hätten nicht lange gebraucht, wenn ich es nicht rechtzeitig bemerkt hätte.

    Einmal editiert, zuletzt von Citral (12. Juni 2016 um 23:52)

  • Moin,
    hast du denn ein rootpasswort vergeben?? Wenn ja, warum??

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Änder den SSH Port in /etc/ssh/sshd_config , restarte den Dienst und erfreu dich der Stille.
    Beziehungsweise änder einfach den Externen Port, also den Weiterleistungsport im Router, sodass Extern zum Beispiel Port 221 auf Intern 22 weiterleitet. Dann brauchst du am Pi nichts verändern.

    Das ist keine Schutzmaßnahme, hilft in 90% der Fälle aber.

    Ein Schutz gegen sowas wäre zB mithilfe des Programms fail2ban möglich, oder du richtest auf dem Pi eine Firewall ein sodass nur noch Verbindungen von bekannten IPs möglich sind, also die Du verwendest.

  • Moin,
    meine Frage war schon ernst gemeint!
    Default ist kein Root-Passwort vergeben. Und SSH lässt normal keinen Login per SSH zu.

    Und es gibt keinen zwingenden Grund sich ein Root-Passwort einzurichten.

    Natürlich hat meigrafd recht mit seine Vorschlägen. Ich nutze auch andere Ports usw.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Moin,
    wollte ich doch meinen...

    Ich bin nur stutzig geworden weil du das

    Code
    Werde aufjedenfall in Zukunft ein härteres Passwort wählen ^^ die hätten nicht lange gebraucht, wenn ich es nicht rechtzeitig bemerkt hätte.

    geschrieben hast.

    Befolge einfach meingrafd's Vorschläge. Das sollte greifen.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.


  • Sieht aus wie ne Bruteforce-attacke.

    Wenn Du auf deinen Clients das ecn-Bit setzen kannst, dann könntest Du das auch auf deinem PI setzen und zum PI nur noch TCP-Verbindungen mit gesetztem ecn-Bit (per iptables) zulassen. Die Portscanner und die Bruteforce-Angreifer verwenden i. d. R. kein gesetztes ecn-Bit. Ohne gesetztes ecn-Bit beim Client, wird dein PI alle NEW-Verbindungsversuche ignorieren (d. h., nicht mit syn+ack antworten). Achtung, dass Du dich nicht aussperrst.

    Auch das ist keine Schutzmaßnahme, hilft aber in gefühlten 99% der Fälle.

    Z. B.:

    Code
    net.ipv4.tcp_ecn = 1
    Code
    iptables -I INPUT 1 -i eth0 -p tcp --tcp-flags SYN SYN -m multiport --dports 0:65535 -m ecn ! --ecn-tcp-cwr -m state --state NEW -j DROP

    Statt für die portrange 0:65535, kann man das auch nur für einzelne lauschende tcp-Ports konfigurieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • > Sieht aus wie ne Bruteforce-attacke

    sowas geht ueber inet nicht, das ist viel zulangsam.
    da werdenstandard/meistbenutzte passwoerter und standard user durchprobiert.

    1. regel fuer offene ports sichere passwoerter fuer alle accs
    2. regel noch sichere passwoerter.

    falls auf http zugegriffen werden kann ist da ein blick in die logs auch hilfreich, dort werden immer standard scripts / config seiten versucht aufgerufen. php z.b. dort auch immer genau schaun was man tut.

    im uebrigen muss hinter der ip nicht der angreifer sitzen, kann ein gekaperter pc sein.

    es gibt auch scripts solche angreifer abzuwehren, fail2ban z.b.

  • Das ist völlig normal wenn der Port offen ist.
    Muss denn der Pi unbedingt aus dem Internet via SSH erreichbar sein ?
    Selbst mein Apache sperrt via htaccess den Grossteil der Welt aus.
    Insbesondere USA, China, Südamerika, Afrika, Asien, Tor, VPN-Anbieter....

  • Oder eben nur lokale Verbindungen zulassen. Ich hab an meinen pi kaum Ports weitergeleitet. Mailserver, https, openvpn. SSH geht dann nur noch über openvpn und das ist sicher. Außerdem läuft über https mit reverseproxy eine shellinthebox, wenn ich grad mal keine Möglichkeit hab, per openvpn zu verbinden. Aber da ist ein Einbruch recht unwahrscheinlich. Das ist nämlich zusätzlich noch per htaccess gesichert, man müsste also 2 Passwörter knacken. Und fail2ban läuft natürlich auch ^^

    Wenn du unbedingt direkt mit ssh verbinden willst, empfehle ich dir, auf Passwörter zu verzichten und stattdessen Zertifikate zu benutzen

  • Ich hab diverse ded. Server die RDP und SSH Verbindungen nutzen. Alle werden attackiert, Loginversuche sieht man im Sekundentakt. Je nahc OS wirds mit "root" oder mit addministrator" versucht und ganz billigen Wörterbuchpasswörtern. Sollten die es damit schaffen einzudringen war dein Passwort einfach Mist.
    Grundsätzlich wird aber alles abgeklopft was mit Standardports im Internet zu erreichen ist.

    Verwendet niemals die lokalen Ports nach draußen -> nimm sowas wie 45022 und leite das intern auf die 22, RDP auch nimm 43889 auf 3389 usw....
    Verwende eine Whitelist von IP Adressen die sich verbinden dürfen, alles andere wird abgelehnt

    und dann ist Ruhe.


    Diese Art der Attacken sind normal und schocken mich jetzt nicht. Mehr Sorgen mach ich mir um SQL Ports, REST und OData Schnittstellen....da achtet man nicht so drauf im laufenden Betrieb. Firewallregeln sind also Pflicht sobald dein Pi vom Internet her erreichbar ist. Mein Pi ist es nicht, aus gutem Grund. :)

  • Eine weitere Möglichkeit, gegen die Wörterbuchattacken vorzugehen, ist das Anmelden von extern (Alle IP-Adressen außer der 192.168.*.*) nur per Zertifikat zuzulassen.

    PS: Habe schon ähnliches auf nem anderen Server erlebt, ist aber nichts worüber man sich sorgen machen muss, solange man nicht eines der Top 100 Passwörter verwendet. (123456, password, Password, root, ....)

    Einmal editiert, zuletzt von ChrisvA (13. Juni 2016 um 09:06)

  • Hallo,

    Du solltest in Betracht ziehen, failtoban zu installieren und SSH-Authentifzierung nur per SSH-Key zu erlauben. Dann sind solche nervigen "Angriffe" nach 3 Fehlversuchen von failtoban abgeklemmt und ohne SSH-Key kommt dann eh niemand rein. Eventuell hilft es auch den TCP-Wrapper in /etc/hosts.allow und /etc/hosts.deny zu aktivieren. Zum Beispiel so:

    allow:
    # meine lokalen LANs:
    sshd: 192.168.0.0/255.255.255.0
    sshd: 192.168.1.0/255.255.255.0
    sshd: 192.168.18.0/255.255.255.0

    deny:
    # ALL: PARANOID
    sshd: ALL

    Ciao
    Thomas

    • Standardport ändern, damit hat man schonmal gefühlt 98% der Logmeldungen weg. Am Einfachsten geht das am Router über Portweiterleitung, dann brauchst du deinen SSH-Server nicht neu zu konfigurieren. Dass über Standardports automatisierte "Angriffe" ausgeführt werden, ist nichts Neues.
    • Anmeldungen von Außen nur über Zertifikate zulassen. Ist sicherer als jedes Passwort.
    • fail2ban o.Ä. einsetzen und entsprechend konfigurieren. Würde ich generell für jeden(!) Dienst empfehlen, der von Außen erreichbar ist.
    • Was ich mir mittlerweile angewöhnt habe: Ist dein Dienst nur per IPv4 erreichbar, würde ich GeoIP-Blocking in Betracht ziehen. Heißt: Zugriff von Außen ist z.B. nur innerhalb Deutschlands möglich. Bietet zwar auch keinen 100%igen Schutz für jemanden, der wirklich auf deinen Dienst zugreifen will - aber für Skriptkiddies reicht das auch schonmal...

  • > Sieht aus wie ne Bruteforce-attacke

    sowas geht ueber inet nicht, das ist viel zulangsam.

    Doch, auch das ist eine Bruteforce-Attacke. Brute-Force bedeutet nicht das zwangsläufig nur einzelne Zeichen genutzt werden.
    Und dass das Internet dafür zu langsam sei stimmt auch nicht. Heutzutage sind die meisten privaten Internetanschlüsse im 20MBit/s Bereich oder höher angesiedelt, zumal die Geschwindigkeit zum Anschluss hin (<- Download) weit aus höher liegt als weg (-> Upload). Man kann einen Internetanschluss also schneller bombardieren als dieser antworten kann.
    Ich hab sowas beruflich auch schon veranstaltet um die Sicherheit von Mitarbeiter-Rechnern zu prüfen... Da kam auch erschreckendes bei raus, selbst von Leuten die es eigentlich besser wissen müssten (Admins) :wallbash:

    fail2ban schützt übrigens nur gegen Angriffe die in Logfiles stehen. fail2ban überwacht nämlich die Logdateien und sucht nach bestimmten Mustern. Steht etwas nicht im Logfile kann fail2ban darauf auch nicht reagieren. Es gibt aber auch manchmal Sicherheitslücken, die nicht geloggt werden. Gegen sowas schützt dann nur das System möglichst up2date zu halten und eine gute Firewall (iptables etc).


    PS: Es gab hier schon öfters solche Diskussionen... Man muss hier aber auch aufpassen was man schreibt, weil sowas wie "Standardport ändern" wird Hier nicht als Schutzmaßnahme anerkannt, das löst sonst schnell ein Shitstorm aus... Deshalb unbedingt dazu schreiben dass das keine Schutzmaßnahme ist :daumendreh2:

  • Ich hab bei mir nen fakessh-Dienst laufen, wenn sich jemand über Port 22 versucht, bei mir anzumelden kommt er direkt auf meine iptables-Liste ;)

    Kann bei Bedarf die Skripte gerne zur Verfügung stellen!

    Einmal editiert, zuletzt von DeadRabbit (13. Juni 2016 um 17:43)

  • Solche Erfahrungen hatte ich auch schon mal gemacht. Allerdings war das jemand von einer indischen Uni. Nachdem ich den Dekan angeschrieben habe und ihm von dem Vorfall berichtete meldete sich sehr schnell ein Admin und dementierte dass diese IP Internetzugang hat :lol: Meine Logs bewiesen aber eindeutig das Gegenteil.

    Meine Tips (In absteigender Priorität, kann aber auch kombiniert werden)

    1) ein VPN benutzen (99,999% sicher)
    2) ssh Zugriff nur per key zulassen (99,999% sicher)
    3) Keinen root Zugriff per ssh erlauben und den User Pi deaktivieren und einen anderen User benutzen. Dann muss der Attacker erst einmal Deinen normalen User erraten und dann das PWD (Kein 100%iger Schutz)
    4) Keinen Standardport verwenden (Obfuscation - also kein 100%iger Schutz, hält aber die Scripkiddies ab)

    Eine weitere zusätzliche Option ist Portknocking zu benutzen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!