SSH Wurm

Diskutiere SSH Wurm im Security Talk Forum im Bereich Netzwerke & Serverdienste; Hallo hat jemand von euch ähnliche Beobachtungen gemacht? Habe folgende Infos von der Gentoo-security-Mailinglist. Mir ist bisher noch...

  1. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    Hallo hat jemand von euch ähnliche Beobachtungen gemacht?
    Habe folgende Infos von der Gentoo-security-Mailinglist.

    Mir ist bisher noch nichts aufgefallen, werde am We aber mal meine Logs überprüfen.
     
  2. Anzeige

    Anzeige

    Wenn du mehr über Linux erfahren möchtest, dann solltest du dir mal folgende Shellkommandos anschauen.


    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. chb

    chb Steirer

    Dabei seit:
    01.06.2003
    Beiträge:
    2.359
    Zustimmungen:
    0
    Hab mal meine Logs angeschaut, aber auch nix gefunden außer 2 - 3 Verbindungsversuche, ohne jedoch nen Login auszuprobieren.
     
  4. #3 bananenman, 28.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    man kann es nicht häufig genug sagen: schaltet das login per passwordauthentification ab! und legt euch sichere schlüssel an! für jeden user einen 2048bit rsa-key und neue 2048bit-hostkey's nicht vergessen (die standardkeys sind nur 1024 bit stark) - vorhandene dsa, ssh1 und die alten rsa-keys löschen!. außerdem sollte ausschließlich das ssh-protokoll 2 unterstützt werden und root sollte das einloggen sowieso verboten werden (ihr habt ja dann user und könnt su - benutzen).

    mfg

    bananenman
     
  5. tr0nix

    tr0nix der-mit-dem-tux-tanzt

    Dabei seit:
    11.07.2003
    Beiträge:
    1.585
    Zustimmungen:
    0
    "nur" 1024 *lol*. Ich denke das reicht ;).
    Wichtig vorallem ist, wie du bereits gesagt hast, dass Version 1 nicht erlaubt wird.
     
  6. #5 bananenman, 28.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    mit sicherheit - trotzdem: der oberguru der crypto-szene (peter gutmann) empfiehlt auch für privatleute schlüssel mit mind. 1556 bit. und die 1000.tel sekunde die das dann länger braucht, merkt man eh nicht.

    mfg

    bananenman
     
  7. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    Wo liegt eigentlich die Obergrenze für rsa-Schlüssel, oder gibt es sowas gar nicht?

    Wie sehr wirkt sich ein größerer Schlüssel auf die Performanz aus?
     
  8. #7 bananenman, 28.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    2048bit ist der größte schlüssel den du erzeugen kannst. und mir ist noch nie irgendeine performance-einbuße aufgefallen - wieso denn auch: der langsamste teil der kette bin immer ich mit meinen 160 anschlägen pro minute und da über den chiffre-kanal ja nicht gearbeitet wird sondern nur befehle versendet werden ... . wo man es merken kann ist bei umfangreichen datenkopieraktionen über ssh bzw. scp/sftp auf älteren maschinen- aber das ist alles nicht so, dass man nun wiklich darunter leiden müsste (insbesondere wenn man eine moderne maschine hat < p3-1000). also: große schlüssel sind schon in ordnung, das langsamste glied der kette ist immer der user (oder das 56k-modem ;) )

    mfg

    bananenman
     
  9. #8 bananenman, 28.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    ich hab grad nochmal meinen privaten server überprüft - und tatsächlich ich hatte mehrere loginversuche:

    Jul 25 11:16:46 XXXXXX sshd[15484]: Illegal user test from 80.55.35.10
    Jul 25 11:16:52 XXXXXX sshd[15486]: Illegal user guest from 80.55.35.10
    Jul 25 11:18:44 XXXXXX sshd[15489]: Illegal user test from 80.55.35.10
    Jul 25 11:18:48 XXXXXX sshd[15491]: Illegal user guest from 80.55.35.10


    eine whois auflösung auf die anfragend ip führte nach schweden, genauer hierhin:

    inetnum: 81.8.206.0 - 81.8.206.127
    netname: SE-AC-UMEA-SAVARADALEN-GRAVMARK-NET
    descr: Network for private home customers Gravmark in Umea
    country: SE
    admin-c: LALU1-RIPE
    tech-c: JEJO1-RIPE
    status: ASSIGNED PA
    mnt-by: ACNT-MNT
    changed: lars-erik.christoffersson@skelleftea.se 20031209
    source: RIPE

    auch heute vormittag gab es aus dem gleichen block wieder mehrere login-versuche ... - werde das mal weiter beobachten.

    mfg

    bananenman
     
  10. #9 destrukt, 28.07.2004
    destrukt

    destrukt Paranoid Developer

    Dabei seit:
    02.11.2003
    Beiträge:
    41
    Zustimmungen:
    0
    Bei mir hasts auch einer versucht, bei mir führte whois hierhin:

    OrgName: RIPE Network Coordination Centre
    OrgID: RIPE
    Address: Singel 258
    Address: 1016 AB
    City: Amsterdam
    StateProv:
    PostalCode:
    Country: NL

    und noch etwas mehr..aber egal..

    und ein nmap -O -sS <IP> ergabe das hier:

    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-07-28 13:15 CEST
    Interesting ports on hs.mooskirchen.at (193.109.140.12):
    (The 1651 ports scanned but not shown below are in state: filtered)
    PORT STATE SERVICE
    20/tcp closed ftp-data
    21/tcp open ftp
    22/tcp open ssh
    25/tcp open smtp
    53/tcp open domain
    80/tcp open http
    110/tcp open pop3
    10000/tcp open snet-sensor-mgmt
    Device type: general purpose
    Running: Linux 2.4.X
    OS details: Linux Kernel 2.4.19 - 2.4.20
    Uptime 3.282 days (since Sun Jul 25 06:31:14 2004)
     
  11. saiki

    saiki Bratwurstgriller

    Dabei seit:
    18.03.2003
    Beiträge:
    934
    Zustimmungen:
    0
    könntet ihr vielleicht kurz erklären wo ich was einstellen muss :)
    Also root access verbieten, nur key auth usw.?
     
  12. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    Also unter gentoo, kannst die sshd Einstellungen unter /etc/ssh/sshd_config vornehmen.

    Wichtig ist hier
    Code:
    Port 22
    Protocol 2
    ListenAddress 0.0.0.0
    PermitRootLogin no
    UsePAM yes
    PubkeyAuthentication yes
    AuthorizedKeysFile     .ssh/authorized_keys
    Sollte ich was vergessen habe bitte ergänzen :)
     
  13. saiki

    saiki Bratwurstgriller

    Dabei seit:
    18.03.2003
    Beiträge:
    934
    Zustimmungen:
    0
    und wie muss ich jetzt die keys für die rechner erstellen?
     
  14. hopfe

    hopfe Haudegen

    Dabei seit:
    01.04.2003
    Beiträge:
    733
    Zustimmungen:
    0
    ist zwar nicht nur zu diesen Thema, aber die Seite behandelt auch kurz die Anmeldung via Publickeys.
     
  15. #14 bananenman, 28.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    die /etc/ssh/sshd_config ist bei allen distributionen die mit openssh ausgeliefert werden (also quasie bei allen) die konfigurationsdatei für den sshd. als zusätzlichen tip noch etwas: der sshd muss keinesfalls auf dem port 22 lauschen - legt ihn doch auf irgendeinen anderen port. das hat folgende vorteile:

    1. erwartet kein angreifer den sshd hinter einem anderen port als der 22 (vielleicht noch der 222 - der ipcop nutzt den port 222 für seinen sshd).

    2. wird ein anderer offener port gefunden, versucht der angreifer diesen mit seinem originären protokoll anzusprechen - was der sshd dann nicht nur blockt, sondern erst garnicht versteht.

    zur openssh-suite kann ich nur sagen: es gibt hervorragend geschriebene man-pages und auch die restliche dokumentation ist sehr gut - also nur mut und frisch ans werk

    kurztip zum schlüsselerstellen:
    $ssh-keygen -b 2048 -t rsa -f ~/.ssh/rsa_id

    erstellt einen userkey mit 2048 bit vom typ rsa. der keyfile wird im homedirectory des users unter /.ssh/rsa_id gespeichert

    vergebt zumindest hinlänglich sichere mantras! da ihr eure keys auf irgendeiner art von datenträgern transportieren müsst (diskette, usbstick/dongle) ist ein keyfile ohne mantraverschlüsselung bei verlust des datenträgers das geld nicht wert das ein blatt klopapier kostet! einzig die hostkeys (die natürlich nur von root angelegt werden können) dürfen nicht verschlüsselt sein (sie bleiben ja aber auch immer im system und gehören root).

    mfg

    bananenman
     
  16. saiki

    saiki Bratwurstgriller

    Dabei seit:
    18.03.2003
    Beiträge:
    934
    Zustimmungen:
    0
    Also irgendwie bin ich immernoch nicht schlauer - die keys werden angelegt, aber was damit?
    Bsp. Ich will mich auf einer anderen Maschine einloggen. Muss ich dort den schlüssel erstellen und das *.pub auf meinen rechner überspielen? Und was muss ich in authorized keys eintragen?

    fragen über fragen...
     
  17. #16 bananenman, 29.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    ist doch garnicht so schwer:

    das ganze public-key verfahren basiert darauf, das es einen privaten und einen öffentlichen schlüssel gibt. beide schlüssel können auf dem rechner der hinterher der server sein soll, oder auf dem zukünftigen client angelegt werden und liegen dann (sofern du die schlüssel mit meinem befehl angelegt hast) im userverzeichnis unter /.ssh/ . der private-key heißt id_rsa und ist der eigendliche schlüssel (d.h. diese schlüsseldatei kann chiffren die mit dem public-key erstellt wurden dechiffrieren - oder aufschließen). der public-key heißt id_rsa.pub und dient zum verschlüsseln und signieren.

    ich gehe jetzt hier von dem fall aus, dass du den schlüssel vom zukünftigen client aus erstellst - das machst du mit folgendem kommando

    $ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa

    angenommen du hast zwei linux-boxen und willst dich von der box b (client) auf der box a (server) per ssh einloggen, dann musst du irgendwie den schlüssel von box b zu box a bekommen und dafür sorgen, das box b in der authorized_keys von box a eingetragen ist sowie das box a in der known-hosts von box b steht - na ist der knoten im hirn schon perfekt? ok, dann nehmen wir halt den einfachen weg und kopieren den schlüssel mit einem script, dass uns auch gleich die ganze andere arbeit abnimmt:

    $ssh-copy-id -i ~/.ssh/id_rsa huhn@mars

    du siehst, das ist ein ssh-aufruf - es muss also auf dem client zumindest ein ssh-client und auf dem server ein sshd laufen und weil wir uns noch nicht mittels pubkey-verfahren einloggen können, muss passwordauthentification auf dem zukünftigen server noch aktiv sein. das script macht folgendes:
    es kopiert die id (und zwar genau die in ~/.ssh/id_rsa) in das /home-directory des users huhn auf dem rechner mars (deinem zukünftigen server) ohne namensauflösung müsste da also sowas stehen wie .../id_rsa huhn@192.168.64 oder vielleicht auch sowas wie id_rsa huhn@mars.homelinux.net .

    so - nun hast du den key übertragen (und zwar im verschlüsselten modus über ssh - also absolut sicher) - der server (mars) kennt deinen public-key und kann daten die er an dich sendet damit verschlüsseln. wie aber verschlüsselst du die daten die du an deinen server schickst? na klar, mit dem public-key des servers! den bekommst du, sobald du die erste ssh-verbindung mit ihm aufbaust - bzw. er bietet ihn dir an - ob du den key der dir da angeboten wird wirklich annimmst oder annehmen solltest ist etwas ganz anderes (du solltest dir schon sicher sein, das der schlüssel wirklich von dem server kommt, von dem er vorgibt zu sein. um das zu überprüfen gibt es öffentliche schlüsselserver, privat reicht aber eigendlich meist auch ein telefonat mit dem admin des servers - er kann sich seinen schlüssel mit

    #ssh-keygen -l -f "Keyfile"

    anzeigen lassen und ihn dir dann am telefon zum vergleich diktieren).

    startest du nun also eine ssh-session, brauchst du nurnoch

    $ssh huhn@mars

    zu tippen. der server (mars) schickt dir dann seinen public-key. sofern du den akzeptierst, wird er in die known_hosts aufgenommen und du verschlüsselst deine daten mit dem public-key des servers, während der server die daten mit deinem public-key verschlüsselt.

    so, dass war's schon - fast. mir geht es nämlich oft so, dass ich meine server von unterwegs abfragen will - oft von meinem notebook aus und gelegendlich über w2k, also mit putty. die neueste version von putty kann openssh-keys importieren - du brauchst die version 0.54 oder höher. im unterprogramm puttygen gibt es die möglichkeit über [conversions] den keyfile (also id_rsa) zu importieren und ihn dann als z.b. mars.pkk wieder auszugeben. diesen konvertierten schlüssel kannst du dann mit putty verwenden. der keyfile muss also irgendwie zusammen mit dem programm putty "an den man" - dafür eignet sich ein usb-stick ganz gut. aber vorsicht: du schleppst dort deinen private-key mit dir rum, was im falle eines diebstahls des usb-sticks dem dieb unter umständen auch gleich noch den ganzen server in die hände spielt. auf den usb-stick gehört also ein aes-loop (es gibt auch kostenlose container-programme für windows) und der key sollte auch wirklich da drinn liegen! außerdem ist wichtig, dass du dem key ein ordentliches mantra mitgibst und das auch gelegendlich rotierst - dazu musst du keinen neuen key erstellen, mit

    $ssh-keygen -p -f ~/.ssh/id_rsa

    kannst du auch nachträglich noch die passphrase für einen bestehenden key ändern.

    wenn alles läuft, empfehle ich passwordauthentification abzuschalten. genauso sollte root ein einloggen verboten sein und es sollte ausschließlich das protokoll 2 verwendet werden. zusätzlich kann man den sshd auf einem anderen port lauschen lassen.

    so, und nun frohes schaffen ...

    mfg

    bananenman
     
  18. chb

    chb Steirer

    Dabei seit:
    01.06.2003
    Beiträge:
    2.359
    Zustimmungen:
    0
    Danke :-), darf ich das ins Wiki übernehmen ?
     
  19. #18 bananenman, 29.07.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    wenns hilfreich ist - dann soll`s mir ein vergnügen sein!

    ;)

    mfg

    bananenman
     
  20. saiki

    saiki Bratwurstgriller

    Dabei seit:
    18.03.2003
    Beiträge:
    934
    Zustimmungen:
    0
    danke hat geholfen, obwohl ich das ssh-id-copy script nicht habe.

    aber es macht ja nur, das per scp der id_rsa.pub auf den sever gespielt und dort in authorized_keys eingetagen wird.
     
  21. #20 bananenman, 03.08.2004
    bananenman

    bananenman Routinier

    Dabei seit:
    07.03.2004
    Beiträge:
    410
    Zustimmungen:
    0
    wie, du hast das ssh-copy-id nicht? (vorsicht - du hast es in deinem post falschrum geschrieben - beim befehlsaufruf vielleicht auch?) sofern du openssh mit einer versionsnummer großer 3.x einsetzt, gehört das script zum "lieferumfang" der openssh-suite! aber schon richtig erkannt, man kann diese schritte natürlich auch "händisch" vornehmen.

    mfg

    bananenman
     
Thema:

SSH Wurm

Die Seite wird geladen...

SSH Wurm - Ähnliche Themen

  1. Moose - ein Wurm befällt Linux Router

    Moose - ein Wurm befällt Linux Router: Das Sicherheitsunternehmen Eset hat eine Analyse der Malware Linux/Moose veröffentlicht, die hauptsächlich Linux-Router und eingebettete Geräte...
  2. Symantec warnt vorsorglich vor Linux-Wurm

    Symantec warnt vorsorglich vor Linux-Wurm: Der Sicherheitsforscher Kaoru Hayashi beschreibt einen Linux-Wurm, der eine PHP-Lücke ausnutzt und neben PCs auch Router, Settop-Boxen,...
  3. In meinem Wlan ist der Wurm drin

    In meinem Wlan ist der Wurm drin: Habe einen Asus Wlan-Adapter mit RT2500 Chip nach Anleitung von Serialmonkey installiert, hat auch prima geklappt. Jetzt ist mir aufgefallen, dass...
  4. ICQ Wurm/Trojanisches Pferd

    ICQ Wurm/Trojanisches Pferd: Ich bekomme seit heute oft von vielen ICQ-Nutzern folgende Nachricht: Check this:: http://7250.edunmerinker.com/1/6247/ Der link ist immer...
  5. Linux-Wurm "Lupper"

    Linux-Wurm "Lupper": Quelle & Zitat: Pro-Linux: Ein Wurm namens Plupii oder Lupper kann sich durch einen Fehler in PHP auf mangelhaft gewartete Linux-Server...
  1. Diese Seite verwendet Cookies um Inhalte zu personalisieren. Außerdem werden auch Cookies von Diensten Dritter gesetzt. Mit dem weiteren Aufenthalt akzeptierst du diesen Einsatz von Cookies.
    Information ausblenden