Hoher SSH-Traffic

N

nitramf

New Member
Hallo!

ich habe vor geraumer Zeit mal ein Traffic-Monitoring-Script auf meinem vServer installiert. Nach 21 Tagen bin ich beim SSH-Traffic bei knapp 130MB angekommen, meiner Meinung nach etwas viel :eek:

Genutzt habe ich den SSH-Dienst in dieser Zeit kaum.


Ich habe schon einen Rootkit-Scanner durchlaufen lassen, habe keine Ergebnisse bekommen.

Wie kann ich noch feststellen, ob jemand eingebrochen ist? Ich habe keine großen Verdächtigen Dateien gefunden...


Gibt es eigentlich schon fertige IP-Tables Regeln, um diverse "unseriöse" Länder auzusperren? (Ich meine damit z.B. die Ukraine, China usw.)


Gruß,
nitramf
 
Empfehlen würde ich dir fail2ban um Brute-Force Attacken gegen SSH zu unterbinden. Fail2ban kann weitaus mehr als nur SSH Brute-Force Attacken abwehren mit IPTables, sondern auch andere Dienste wie z.B. proftpd schützen.

Sofern du fail2ban nutzt, empfiehlt es sich die Angreifer an die jeweiligen Abuse-Abteilungen der ISP's zu melden. Da man sich mit dem "manuellen" Versenden an die Abuse-Abteilungen immer schwer tut, würde ich dir "blocklist.de" empfehlen. Du konfigurierst dein fail2ban so, dass es die Angriffe an Blocklist meldet und von dort aus werden dann die ISP's benachrichtigt.

Um IP's zu sperren (was ich nur temporär machen würde), kann ich dir folgendes empfehlen:

unter HoneyStats.info kannst du eine öffentliche "public DNSBL zone" IP Liste downloaden. Diese Liste wird immer wieder aktualisiert und basiert auf diversen Honeypots die im Einsatz sind. Dort werden die Angreifenden IP's in der DNSBL Liste gespeichert.

Ansonsten, sofern du ".htaccess" Dateien benutzt gibt es countryipblocks.net, dort kannst du selber bestimmen welche Länder Zugriff haben und welche nicht auf deine Webseiten.
 
nitramf said:
Wie kann ich noch feststellen, ob jemand eingebrochen ist?
Click to expand...

Du durchsuchst deine Log-Dateien, ob sich jemand per ssh am System angemeldet hat. Unter Debian wäre das die /var/log/auth.log.

So stellst du sicher, dass es wirklich nur erfolgloses BruteForce war, oder ob es doch einen Treffer gab.
 
Root-Login per SSH ist hoffentlich schon lange deaktiviert und der Login ist noch Möglichkeit auch bereits auf Key Authentication umgestellt?
 
Root-Login per SSH ist hoffentlich schon lange deaktiviert
Click to expand...
Bei einem sicheren Passwort bzw. Key-Auth hat root-Verbot was Angreifer angeht IMO keinen wahren Sicherheitsvorteil.
Dazu mal ein Zitat
Saying "don't login as root" is h******t. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw, and decreast the chance you got spoofed as to your telnet host target, You'd get your password spoofed but not root's pw. Gimme a break. this is 2005 - We have ssh, used properly it's secure. used improperly none of this 1989 will make a damn bit of difference. -Bob
Click to expand...
Quelle
 
"using" und "administrating" sind zwei paar Schuhe:
Als User will ich Password-Auth, da es für mich bequemer in der Nutzung ist.
Als Administrator will ich non-root Key-Auth, da es für mich eine zweite Verteidigungslinie bedeutet.
Da aber die Sicherheit auf einem Server grundsätzlich oberste Priorität haben sollte, fällt Password-Auth flach, auch wenn es für den User ausreichend sicher erscheint und vermeintlich bequemer ist.
 
schnoog said:
Bei einem sicheren Passwort bzw. Key-Auth hat root-Verbot was Angreifer angeht IMO keinen wahren Sicherheitsvorteil.
Click to expand...

PermitRootLogin = No hat den entscheidenden Vorteil, dass der potentielle Angreifer so schon mal gar keinen Systemuser kennt, dessen Passwort er Brutforcen könnte.
 
Joe User, ich hab natürlich nicht dich gemeint - unsere Antworten kamen quasi synchron. Aber das würde u.U. den erhöten Traffik über den ssh-Port erklären...
 
basstscho said:
Hast vieleicht mal ne Datei über SFTP oder rsync via SSH hochgeschoben?
Click to expand...


Hallo,

nein, leider nicht.
Ich habe mir mal das auth-log angesehen, da gabs einen bestimmten Tag mal ne größere Bruteforce-Attacke aus der Ukraine....

Können Bruteforce-Attacken so einen hohen Traffic erzeugen?
Momentan ist der root-login noch erlaubt, ich ändere das. Wobei das aktuelle PW meines erachtens sehr sicher war (>10 Zeichen + Sonderzeichen), sowas steht in keinem Wörterbuch.


Fail2Ban ist installiert, damit dürfte die Bruteforce-Geschichte ja schonmal vom Tisch sein. Ich resette das Monitoring-Script jetzt, mal sehen was sich die nächsten Tage so an Traffic auftut...


Danke!

nitramf
 
Steht der Port noch auf 22 (Standard)?
Dann empfiehlt sich eine Änderung. Der Traffic auf SSH wird sich deutlich verringern.
Den neuen Port sollte man dann selbstverständlich in der Firewall freigeben.
 
Ich empfehle dir, dass du dir Denyhosts oder Fail2Ban installierst.

Den Port zu verlegen ist ziemlich paranoid und macht bei Portscans wenig Sinn.

Wenn du planst mehreren Usern sftp Zugriff zu geben empfehle ich dir Groups, in denen du die User definierst, und Sie dann per ChrootDirectory in Verzeichnisse einsperrst.

BTW: 130MB SSH Traffic ist nicht gerade viel, ich benötige pro Tag ungefähr 130MB, auch ohne Bruteforce Attacken ;)
 
virtual2 said:
Den Port zu verlegen ist ziemlich paranoid und macht bei Portscans wenig Sinn.
Click to expand...
Ich halte es nicht für paranoid.
Es bietet eine zusätzlich Sicherheit zu fail2ban etc. Die Sniffer sind meist auf den Standardport 22 ausgelegt. Verlegt man den Port z.B. auf > 2.000 sperrt man somit schon viele unnötige Anfragen von Anfang an aus.
 
Das Verlegen des Ports bringt absolut keinen Sicherheitsgewinn. Der einzige Vorteil ist ein etwas kleineres Logfile, da ein paar wenige Script-Kiddie-Tools derzeit noch auf die Standard-Ports ausgerichtet sind. Letzteres nimmt aber stetig ab, womit der obige Vorteil in wenigen Jahren endgültig verpufft ist.
Fail2ban und Co sind noch immer anfällig für (Self-)DoS und bringen auch sonst keinen reellen Sicherheitsgewinn, weshalb von deren Einsatz dringend abzuraten ist. Alles was diese Tools versprechen, kann man auch mit einer Vernünftigen Konfiguration seiner Dienste erreichen...
 
You must log in or register to reply here.
Back
Top