SSH Wurm

H

hopfe

Haudegen
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Over the past few days I've noticed many attempts from different sources
trying to login on ssh via guest/test/admin/etc accounts. Looking
further into the matter I found SANS is looking for information too.

http://www.incidents.org/diary.php?date=2004-07-23
http://www.incidents.org/diary.php?date=2004-07-25

and more information here:
http://www.dslreports.com/forum/remark,10854834~mode=flat~days=9999

It appears as the net is getting hit with these all over. I would guess
this is a very early stage of some kind of new worm/exploit in the
works. What is more, it appears to have the ability to pass some NAT
boxes by tricking them into replying back to the source.

If you're not already doing so, I recommend to disable password
interactive login and enforce key only logins. This will prevent some
of the ssh exploits, brute-force attacks, and general script kiddies.

And as always, upgrade to the latest version of OpenSSH/OpenSSL.
- --
Greg Watson
http://www.linuxlogin.com
GnuPG Key: http://www.linuxlogin.com/gpg_key.pub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBBoMk0stmTYtmfxsRAgEtAJ4xX4NUhVY1TrQ2sLVw2VOH3/02KACgiOak
7fJRiR57F4RbRZQflDbIVqs=
=r4zY
-----END PGP SIGNATURE-----
 
Hab mal meine Logs angeschaut, aber auch nix gefunden außer 2 - 3 Verbindungsversuche, ohne jedoch nen Login auszuprobieren.
 
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
 
bananenman schrieb:
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
"nur" 1024 *lol*. Ich denke das reicht ;).
Wichtig vorallem ist, wie du bereits gesagt hast, dass Version 1 nicht erlaubt wird.
 
"nur" 1024 *lol*. Ich denke das reicht
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
 
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?
 
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
 
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: ********** 20031209
source: RIPE

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

mfg

bananenman
 
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)
 
könntet ihr vielleicht kurz erklären wo ich was einstellen muss :)
Also root access verbieten, nur key auth usw.?
 
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 :)
 
und wie muss ich jetzt die keys für die rechner erstellen?
 
ist zwar nicht nur zu diesen Thema, aber die Seite behandelt auch kurz die Anmeldung via Publickeys.
 
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
 
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...
 
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 ********** .

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
 
wenns hilfreich ist - dann soll`s mir ein vergnügen sein!

;)

mfg

bananenman
 
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.
 
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
 

Ähnliche Themen

Email via script via Exchange Server (SASL)

X startet nichtmehr

Samba 4 Gast Zugang unter Ubuntu funktioniert nicht

JBidWatcher: Problem bei loading Auctions in Verbindung mit mySQL

MacBook Pro hat Benutzer-Konten vergessen

Zurück
Oben