Angriff auf ssh Acount ?

Dieses Thema im Forum "Security Talk" wurde erstellt von theborg, 04.11.2004.

  1. #1 theborg, 04.11.2004
    Zuletzt bearbeitet: 04.11.2004
    theborg

    theborg KBitdefender Programierer

    Dabei seit:
    06.08.2004
    Beiträge:
    688
    Zustimmungen:
    0
    Ort:
    Hamburg
    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?

     
  2. Anzeige

    Schau dir mal diesen Ratgeber an. Viele Antworten inkl. passender Shell-Befehle!
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 qmasterrr, 04.11.2004
    qmasterrr

    qmasterrr Foren Gott

    Dabei seit:
    01.01.2004
    Beiträge:
    2.735
    Zustimmungen:
    0
    Ort:
    Germany/NRW/Wesel
    eventuell ssh auf einen anderen port schalten (nicht 22)
    password auth auschalten.
    root das einloggen über ssh verbieten.
     
  4. devilz

    devilz Pro*phet
    Administrator

    Dabei seit:
    01.05.2002
    Beiträge:
    12.244
    Zustimmungen:
    0
    Ort:
    Hessen

    Hier im Forum gabs zu GENAU diesem Thema schonmal ne Diskussion (gestartet von hopfe).
    Eventl. findest du DA deine Antworten :)
     
  5. #4 Meister Lampe, 04.11.2004
    Meister Lampe

    Meister Lampe Doppel-As

    Dabei seit:
    17.02.2004
    Beiträge:
    124
    Zustimmungen:
    0
    Ort:
    Marburg
    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...
     
  6. rup

    rup Haudegen

    Dabei seit:
    10.04.2002
    Beiträge:
    627
    Zustimmungen:
    0
    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?
     
  7. #6 bananenman, 04.11.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    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
     
  8. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    Ort:
    Aachen
    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.
     
  9. #8 theborg, 04.11.2004
    theborg

    theborg KBitdefender Programierer

    Dabei seit:
    06.08.2004
    Beiträge:
    688
    Zustimmungen:
    0
    Ort:
    Hamburg
    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.
     
  10. #9 bananenman, 04.11.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    @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
     
  11. #10 theborg, 04.11.2004
    theborg

    theborg KBitdefender Programierer

    Dabei seit:
    06.08.2004
    Beiträge:
    688
    Zustimmungen:
    0
    Ort:
    Hamburg
    hm danke ich teste es mahl *G* zum login benutze icheh ssh direkt und nicht mc ....
     
  12. #11 Meister Lampe, 04.11.2004
    Meister Lampe

    Meister Lampe Doppel-As

    Dabei seit:
    17.02.2004
    Beiträge:
    124
    Zustimmungen:
    0
    Ort:
    Marburg
    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...
     
  13. #12 theborg, 04.11.2004
    theborg

    theborg KBitdefender Programierer

    Dabei seit:
    06.08.2004
    Beiträge:
    688
    Zustimmungen:
    0
    Ort:
    Hamburg
    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 ?
     
  14. #13 bananenman, 04.11.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    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
     
  15. #14 theborg, 04.11.2004
    theborg

    theborg KBitdefender Programierer

    Dabei seit:
    06.08.2004
    Beiträge:
    688
    Zustimmungen:
    0
    Ort:
    Hamburg
    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
     
  16. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    Ort:
    Aachen
Thema:

Angriff auf ssh Acount ?

Die Seite wird geladen...

Angriff auf ssh Acount ? - Ähnliche Themen

  1. Neue Angriffe auf DH-Verschlüsselung

    Neue Angriffe auf DH-Verschlüsselung: Nicht der Algorithmus an sich, aber seine Implementation in zahlreichen Servern, Client-Anwendungen und Webbbrowsern gefährdet die Sicherheit und...
  2. Kernel-Patch erschwert Rowhammer-Angriff

    Kernel-Patch erschwert Rowhammer-Angriff: Ein Patch wird aller Voraussicht nach in der kommenden Kernel-Version verhindern, dass Anwender den physischen Speicher einer Anwendung erfragen...
  3. Stallman: Systematischer Angriff auf GNU?

    Stallman: Systematischer Angriff auf GNU?: Richard Stallman, Gründer von GNU, sieht in so manchem Projekt, das eine für Entwickler liberaler lizenzierte Alternative zu GNU-Projekten...
  4. IETF: Internet-Überwachung ist ein Angriff

    IETF: Internet-Überwachung ist ein Angriff: Die Internet Engineering Task Force (IETF) hat sich in RFC 7258 die Aufgabe gegeben, die Internet-Protkolle gegen Überwachung und Spionage...
  5. Linux-Kernel soll vor Angriffen warnen

    Linux-Kernel soll vor Angriffen warnen: Eine neue Kernel-Funktion soll Warnungen ins Log schreiben, wenn der Kernel erkennt, dass versucht wird, eine bereits geschlossene...