Angriff auf ssh Acount ?

theborg

theborg

KBitdefender Programierer
Hi ich hab was interesantes gefunden in der /var/log/messages nur die frage was ist das brutforche auf den ssh acount ?

Und das entlos weiter von verschidenden ip´s aus kann man da irgentwas machen das der ssh bei sowas ne stunde oder so gespert wird und gibt es programme womit man solche datein auswerten kann?

Nov 3 21:39:50 y022 sshd[24292]: Illegal user test from ::ffff:218.18.107.39
Nov 3 21:39:50 y022 sshd[24292]: input_userauth_request: illegal user test
Nov 3 21:39:50 y022 sshd[24292]: Failed password for illegal user test from ::ffff:218.18.107.39 port 60379 ssh2
Nov 3 21:39:51 y022 sshd[24292]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:39:55 y022 sshd[24294]: Illegal user guest from ::ffff:218.18.107.39
Nov 3 21:39:55 y022 sshd[24294]: input_userauth_request: illegal user guest
Nov 3 21:39:55 y022 sshd[24294]: Failed password for illegal user guest from ::ffff:218.18.107.39 port 60476 ssh2
Nov 3 21:39:55 y022 sshd[24294]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:39:59 y022 sshd[24295]: Illegal user admin from ::ffff:218.18.107.39
Nov 3 21:39:59 y022 sshd[24295]: input_userauth_request: illegal user admin
Nov 3 21:39:59 y022 sshd[24295]: Failed password for illegal user admin from ::ffff:218.18.107.39 port 60568 ssh2
Nov 3 21:39:59 y022 sshd[24295]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:00 y022 /USR/SBIN/CRON[24298]: (root) CMD ( /root/confixx/confixx_counterscript.pl)
Nov 3 21:40:03 y022 sshd[24296]: Illegal user admin from ::ffff:218.18.107.39
Nov 3 21:40:03 y022 sshd[24296]: input_userauth_request: illegal user admin
Nov 3 21:40:03 y022 sshd[24296]: Failed password for illegal user admin from ::ffff:218.18.107.39 port 60672 ssh2
Nov 3 21:40:04 y022 sshd[24296]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:07 y022 sshd[24300]: Illegal user user from ::ffff:218.18.107.39
Nov 3 21:40:07 y022 sshd[24300]: input_userauth_request: illegal user user
Nov 3 21:40:07 y022 sshd[24300]: Failed password for illegal user user from ::ffff:218.18.107.39 port 60770 ssh2
Nov 3 21:40:08 y022 sshd[24300]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:12 y022 sshd[24301]: Failed password for root from ::ffff:218.18.107.39 port 60863 ssh2
Nov 3 21:40:12 y022 sshd[24301]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:17 y022 sshd[24302]: Failed password for root from ::ffff:218.18.107.39 port 60956 ssh2
Nov 3 21:40:18 y022 sshd[24302]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:21 y022 sshd[24304]: Failed password for root from ::ffff:218.18.107.39 port 32835 ssh2
Nov 3 21:40:22 y022 sshd[24304]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
Nov 3 21:40:26 y022 sshd[24305]: Illegal user test from ::ffff:218.18.107.39
Nov 3 21:40:26 y022 sshd[24305]: input_userauth_request: illegal user test
Nov 3 21:40:26 y022 sshd[24305]: Failed password for illegal user test from ::ffff:218.18.107.39 port 32930 ssh2
Nov 3 21:40:26 y022 sshd[24305]: Received disconnect from ::ffff:218.18.107.39: 11: Bye Bye
 
Zuletzt bearbeitet:
eventuell ssh auf einen anderen port schalten (nicht 22)
password auth auschalten.
root das einloggen über ssh verbieten.
 
theborg schrieb:
Hi ich hab was interesantes gefunden in der /var/log/messages nur die frage was ist das brutforche auf den ssh acount ?

Und das entlos weiter von verschidenden ip´s aus kann man da irgentwas machen das der ssh bei sowas ne stunde oder so gespert wird und gibt es programme womit man solche datein auswerten kann?


Hier im Forum gabs zu GENAU diesem Thema schonmal ne Diskussion (gestartet von hopfe).
Eventl. findest du DA deine Antworten :)
 
hast du ein notebook und brauchst nur selbst zugang? dann würde ich das teil total abschotten: ssh auf anderen port legen, root das einloggen verbieten, einen eigenen user erschaffen, der sudo-rechte hat und ein einloggen per ssh nur über zertifikat zulassen. letzteres habe ich selbst gerade erst für mich entdeckt, habe es also noch nicht selbst durchgeführt... jedenfalls bekommt dein client ein entsprechendes zertifikat, über das er sich identifiiert. ein passwort wird unnötig und das einloggen von woanders absolut unmöglich, jedenfalls ohne das zertifikat, welches wohl kaum zu erraten sein wird...
 
Interessant waehre evtl. auch "Port knocking"

Ich habs bisher noch nicht getestet und weiss auch noch nicht wie gross der Aufwand ist, es soll aber in etwa so funktionieren:

- Du (dein Client) schickst eine bestimmte nur dir bekannte Sequenz an einen geschlossenen (drop) Port (z.B. ssh).
- Die FW loggt deine Anfrage im FWlog
- Ein Daemon ueberwacht das Log, erkennt Deine Sequenz und schaltet daraufhin die FW fuer diesen Port frei (accept)

Wer hat Erfahrung damit?
 
ein passwort wird unnötig

das ist leider nicht so: wenn du ein zertifikat benutzt ist es dringend angeraten das du dieses selbst mit einem password schützt. nehmen wir folgendes an:

user a hat in seiner firma ssh-zugang zu bestimmten servern. aus sicherheitsgründen ist passwort-authentifizierung verboten, er (oder root) erstellt also ein zertifikat das nicht mit einem eigenen mantra geschützt ist. in der mittagsause klaut user x den usb-stick mit dem zertifikat und damit die identität des users a. user x hat vollen zugriff mit den entsprechenden rechten des users a (ein grund warum man niemals eins zertifikat für root ausstellt).

alles klar? ein nicht passwortgeschütztes zertifikat ist kein schritt in die richtung "mehr sicherheit" sondern einer in die entgegengesetzte.

2. situation: user x klaut den usb-stick von user a, dieser hat sein zertifikat jedoch mit einem mantra versehen (und zwar mit einem richtig guten). wenn sich user a nun an einem server einloggen will erfolgt zwischen den beiden rechnern folgender handshake:

1. client stellt anfrage auf ssh-verbindung und sendet den public-key seines zertifikats mit.
2. server nimmt das zertifikat und möchte es einem lokalen user zuordnen - allerdings ist das zertifikat verschlüsselt. der server fragt den client nun seinerseits nach dem passwort.
3. der client fordert den user auf das entsprechende manta einzugeben und sendet dies (mit dem publik-key des servers verschlüsselt - also absolut sicher) an den server.
4. wenn der server das zertifikat mit dem mantra aufschließen kann, dann der entsprechende user zugeordnet werden - ab jetzt laufen alle verbindungen mit dem entsprechenden user-keys.

alles klar? da der dieb das mantra (hoffentlich) nicht kennt, kann keine verbindung zustande kommen. für user a (dich) ist es aber unerheblich ob er ein passwort eingeben muss um sich einzuloggen oder um das zertifikat freizuschalten (wodurch er automatisch eingeloggt wird).

es gibt in der openssh-suite aber noch ein paar kleine schmankerl - so den ssh-agent: das ist ein usergebundener cache der eine beliebige anzahl von zertifikaten bis zum nächsten neustart des systems vorhalten kann, so dass nicht ständig die neueingabe des mantras notwendig ist (man kann sich - je nach einstellung - sogar zwischendurch abmelden, der usercache bleibt bestehen. erst nach einem systemneustart müssen die zertifikate mit ihren dazugehörigen mantras wieder in den cach aufgenommen werden).

diese ganze obige geschichte erklärt auch warum die system-zertifikate auf gar keinen fall verschlüsselt werden dürfen: würde man die identität eines servers mittels eines mantras schützen könnte ein client keine daten mehr an den server senden, da er den public-key des servers nicht verwenden könnte, denn:

der client verschlüsselt alle daten an den server mit dem public-key des servers (der kann diese mit seinem private-key aufschließen)

der server verschlüsselt alle daten an den client mit dem public-key des entsprechenden users (dieser kann die daten mit seinem private-key dechiffrieren)

die sicherheit der systemzertifikate beruht einzig darauf, dass niemand außer root (und damit dem system selbst) die private-keys auch nur lesen darf. es ist also ganz wichtig die entsprechenden berechtigungen nach einem eventuellen neuerstellen dieser identitäten zu setzen.

mfg

bananenman
 
1. client stellt anfrage auf ssh-verbindung und sendet den public-key seines zertifikats mit.
2. server nimmt das zertifikat und möchte es einem lokalen user zuordnen - allerdings ist das zertifikat verschlüsselt. der server fragt den client nun seinerseits nach dem passwort.
3. der client fordert den user auf das entsprechende manta einzugeben und sendet dies (mit dem publik-key des servers verschlüsselt - also absolut sicher) an den server.
4. wenn der server das zertifikat mit dem mantra aufschließen kann, dann der entsprechende user zugeordnet werden - ab jetzt laufen alle verbindungen mit dem entsprechenden user-keys.

Hmm irgendwie hab ich das System etwas anders verstanden, bitte korregiere mich wenn ich falsch liege.

1. Der Client stellt die Verbindung zum Server her und erhält den Public-Key vom Server.
2. Der Client schickt seinen Publickey und die Anmeldedaten (Username), an den Server (natürlich verschlüsselt mit den PublicKey des Servers).
3. Der Server erkennt das der Publickey des Clients für den Benutzer berechtigt ist, und verschlüsselt seine Antwort nun mit den Publickey des Benutzers und sendet eine Antwort zurück.
4. Nun wird zum dechiffrieren der Antwort der Privatekey des Clients benötigt, welcher jedoch durch ein Mantra geschützt ist.
5. Der Benutzer gibt das Mantra ein und der PrivateKey wird nun lokal am Client entschüsselt und kann für die weitere Übertragung verwendet werden.
 
Hm irgentwie verstehe ich nicht was ihr meint

meine absicherung sieht momentan so aus selbst wenn jemand das root pw hat und sich damit einlogt, das dann sofort beim login nen logout program gestartet wird ob das efektiv ist weis ich nicht aber besser als ganichts und dann hab ich nen normahlen user der kaum rechte hat nur zum starten/stoppen der server.
 
@hopfe: jain - der handshake den du beschreibst ist der normale ssh-handshake für den austausch eines normalen password-login. soweit ich weiß läuft der handshake bei verwendung eines zertifikats aber anders ab - allerdings würde ich das nicht beschwören wollen. das zertifikat ist ja usergebunden, bzw. der user (der angemeldet wird) ist zertifikats-gebunden - damit scheidet z.b. die übermittlung des users schonmal aus.

@theborg: editier doch mal die /etc/ssh/sshd_config - alle einträge die dort mittels der raute deaktiviert sind, sind standard-einträge. wenn du also root-login von anfang an verbieten willst, musst du aus der zeile

#PermitRootLogin yes

ein

PermitRootLogin no

machen. deinem normalen user kannst du alle besonderen rechte entziehen - er sollte halt nur mit su zum root werden können. und wenn du grad in dem conf-file bist, kannst du auch gleich den port auf dem der sshd lauscht ändern und dafür sorgen das ausschließlich das ssh-protokoll 2 akzeptiert wird (das hat allerdings auch nachteile: fish und/oder bamse (der fish nachfolger) benötigen das ssh-protokoll 1 - das fish-protokoll wird z.b. vom konqueror, krusader oder auch vom mc genutzt: die so beliebte shell-verbindung im mc funktioniert dann nicht mehr).

mfg

bananenman
 
hm danke ich teste es mahl *G* zum login benutze icheh ssh direkt und nicht mc ....
 
Hmmm, wie gesagt, das mit dem Zertifikat habe ich selbst auch noch nicht gemacht.

Aber zu dem root den Login zu verweigern: Nachdem du ssh so umgebaut hast kannst du wiefolgt vorgehen: Dem User, mit dem man sich einloggen kann, sollte man eine restricted-shell oder wie die genau heißt zuteilen, sodass er kaum einen befehl ausführen kann. er sollte nicht mal cd benutzen dürfen. dazu sollte der user in eine eigene gruppe gepackt werden, diese ist dann in der su-Liste drin, womit er nur über su zum root werden kann. Jedenfalls haben wir das damals hier an unserem Webserver so gemacht... Ist wahrscheinlich aber nur ein Weg unter vielen... Genauer kann ich dir das gerade auch nicht sagen. Ich bin nicht der Experte in der Richtung, sondern arbeite mit einem Kumpel, der sich auf Security spezialisiert hat, eng zusammen, wenn solche Zugänge aufgebaut werden müssen...
 
ja aber das ist doch imprinzip nen hindernis aber keine echte sicherheitzeinrichtung oder wen der user geknakt wird dann ist der angreifer schonmahl im system und das mit su wird er doch als erstes testen oder ?
 
den user knacken kann er nur, wenn du ihm das mantra für dein zertifikat gibst - hast du natürlich keins oder nur ein schwaches verwendet: selber schuld. und superuser kann er nur werden wenn er das passwort kennt - hast du natürlich keins oder nur ein schwaches verwendet: selber schuld. unabhängig davon kann man ja noch einstellen wieviele versuche superuser zu werden pro sitzung überhaupt möglich sind - 3 versuche ist eine gute grundlage um eine art brute-force-attacke zu unterbinden.

mfg

bananenman
 
hm jo da haste recht nen kolege hat das so das der root user nicht root heist sondern irgentwie anders das wehre auch noch ne möglichkeit

Die entfehlungen von euch die oben stehen hab ich mitlerweile umgesetzt der user mit dem einzigen ssh acount hat jetzt nur noch rechte die server zu starten und su auszufüren mahl sehn ob das klapt
 
ah - prima, vielleicht sollte man doch öfter mal bei pro-linux vorbeischauen. ich hatte das wegen der üblichen trollpostings in ihrem forum schon aufgegeben ... ;)

mfg

bananenman
 
Pro-linux und Heiseforum lies ich auch nicht mehr, aber die Artikel sind teils recht gut.
 
mahl ne blöde frage noch so nebenbei wie starte ich den ssh server neu ohne den server neuzustarten und so das ich hinterher wieder drauf komme ?
 
unter slackware

# /etc/rc.d/rc.sshd restart

(restart killt nur den laufenden listener-prozess und startet in mit neuer konfiguration neu).

mfg

bananenman
 

Ähnliche Themen

3 Wege zur Authentifizierung?

Fail2Ban won't ban

sftp mit vsftpd und mysql

Mysteriöser 11.4 Absturz - Maschine läuft, SSH und vor Ort Login unmöglich

ejabberd Server neuerdings instabil

Zurück
Oben