Betörtek hozzám?

Security-all

Sziasztok!

nézegettem egy kicsit a logokat a Debian serveremen és a következőre lettem figyelmes az auth.log-ban:

Aug 14 12:09:08 localhost sshd[22815]: Did not receive identification string from 219.148.119.105
Aug 14 12:12:22 localhost sshd[22818]: User root not allowed because not listed in AllowUsers
Aug 14 12:12:29 localhost sshd[22820]: Illegal user admin from 219.148.119.105
Aug 14 12:12:37 localhost sshd[22822]: Illegal user test from 219.148.119.105
Aug 14 12:12:41 localhost sshd[22824]: Illegal user guest from 219.148.119.105
Aug 14 12:12:45 localhost sshd[22826]: Illegal user webmaster from 219.148.119.105
Aug 14 12:12:51 localhost sshd[22828]: User mysql not allowed because not listed in AllowUsers
Aug 14 12:12:55 localhost sshd[22830]: Illegal user oracle from 219.148.119.105
Aug 14 12:13:01 localhost sshd[22832]: Illegal user library from 219.148.119.105
Aug 14 12:13:06 localhost sshd[22834]: Illegal user info from 219.148.119.105
Aug 14 12:13:10 localhost sshd[22836]: Illegal user shell from 219.148.119.105
Aug 14 12:13:14 localhost sshd[22838]: Illegal user linux from 219.148.119.105

kezdő linuxos admin vagyok, és nem vagyok teljesen tisztában azzal, hogy mit is jelent ez, de ha jól gondolom akkor egy kinai hacker próbálkozott. Honnan tudom, hogy sikerült-e neki? Vagy pontosan mit jelentenek ezek a bejegyzések?

A segítséget előre is köszönöm.
VS

  • 4457 megtekintés

( bervi | 2006. 08. 15., k – 20:15 )

>Betörtek hozzám?

egyelőre remélhetőleg nem :-))

( Todvard | 2006. 08. 15., k – 20:17 )

Ezek probalkozasok. Ennyi alapjan csak azt lehet biztosan mondani, hogy probaltak hozzad belepni ssh-n keresztul a rendszereken altalaban megtalalhato user nevek felhasznalasaval de (egyenlore) nem sikerult. Javaslom, hogy jelentkezz be ssh-n keresztul es nezd meg a system logot, hogy hogyan nez ki egy sikeres bejelentkezes.

Valami automatikus rendszer ami ezt csinalja - naponta 100-200 ilyen ssh belepesi kiserlet erkezett regebben (mig automatikus nem kezdtem el tiltogatni az ilyen IP-ket, mert untam, hogy foglaljak a savszelessegem). Van amikor (a worm - vagy hasonlo) eleg brutalisan csinalja es total lenyomja a savszelt.

Régen az én logjaim is tele voltak ilyen szarokkal. Aztán meguntam. Azóta az sshd nem a saját portján figyel. Mióta átállítottam, egy kísérlet sem volt...

Szerk: emlékeim szerint régen volt valami sshd sebezhetőség, és ezzel lehetett kihasználni. Azóta mindenki ezzel próbálkozik, mondván hátha.

Az nmap megtalálja, de úgy sokkal lasabb lenne a worm/hacker tevékenysége, mire végigszkenneli a nyitott portokat és megállapítja hogy hol van ssh nyitva. Korábban itt a HUPon is volt rengeteg okos ötlet a biztonság növelése érdekében (ssl kulcs, portkopogtatás és társai), keressetek rá, hasznos lehet.

Laci

( gthomas | 2006. 08. 15., k – 20:57 )

A routeren a 22-es port megnyitását követő 2. naptól kezdve nekem is dőltek be ezek a próbálkozások. Mivel csak én használom, ezért áttettem egy másik (>1000) portra, azóta megszűntek.

Hogy növeld a biztonságot (a port áttétel mellett is!), sshd_config-ban:

PermitRootLogin no # root nem léphet be
PubkeyAuthentication yes # publikus kulcsot használ
AllowUsers
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no # sima jelszót nem fogad el - nem lehet próbálkozni
MaxAuthTries 2 # 2 hibás próbálkozás után bontja a kapcsolatot

Köszönöm a gyors válaszokat mindenkinek.

Kicsit jobban átnéztem a korábbi logokat is, és abból az derült ki, hogy nem csak kínából, hanem még legalább 10 másik IP-ről is próbálkoztak. Voltak teljesen véletlenszerü felhasználónevek (gondolom progi generálta), és voltak kimondottan magyar keresztnek is (pedig külföldről próbálkoztak, gondolom van országra vonatkozo nevlistájuk /egy ilyet nem nagy valami beszerezni/ ékezet nélkül), és még a rendszerhez általában kapcsolódó 'nevek', /mysql, mysqladmin, webalizer, webx, .../

1.
PermitRootLogin yes # -volt ezt atirtam no-ra
2.
MaxAuthTries 2 # hibának jelzi amikor restart-olom az sshd-t
3.
mivel csak én használom az ssh(d)-t, ezért az
AllowUsers -nél csak az én user nevem van megadva, ez így ok? (mert különben mindenki be tud lépni?)

VS

( Oregon (nem ellenőrzött) | 2006. 08. 15., k – 22:54 )

nyomj egy:
"last -20" parancsot. persze idezojelek nelkul.

( Dr_Mac | 2006. 08. 15., k – 22:56 )

Nálam is voltak ilyen próbálkozások egy tűzfal/proxy gépen. Én ezt csináltam:
1/ IP címek alapján rákerestem a netblock üzemeltetőjére.
2/ az üzemeltető admin és abuse címére küldtem egy felháborodott levelet (megfeleő log részletekkel kiegészítve) és kértem a felhasználó letiltását

10 szolgáltatóból 8 válaszolt és ami meglepő volt, valamit csináltak is. Ugyanis ezekből a rendszerekből nem jött több próbálkozás. A maradék próbálkozók ellen pedig:
1/ sshd átkerült más portra
2/ az ssh portra érkező próbálkozások átirányítva egy DMZ-ben elhelyezett ősöreg gépen futó ssh szerverre. Itt 3 sikertelen próbálkozás után megy a delikvens a TARPIT-ra :DD

Azóta nyugalom van. 4-5 naponta bepróbálkozik valaki, de hamar feladja.

( Husky v | 2006. 08. 15., k – 23:29 )

Tuzfalas workaround:

-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --update --seconds 120 --name SSH --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name SSH --rsource -j ACCEPT

Altalaban gyorsan tovabballnak a probalkozo scriptek miutan az elso probalkozas utan eltunik az ssh szerver...

En nem vagyok rendszergazda, de van nekem egy szkriptem amit itt a hupon hekkeltek ossze paran es beletettem a fenti ket sort. Tudna ra valaki mondani valamit, hogy jo lesz-e igy:

$IPT -A input_ext -p tcp --dport 22 -m state --state NEW -m limit --limit $LOG_LIMIT -j LOG --log-prefix 'FW-ACCEPT ' --log-tcp-options --log-ip-options
$IPT -A input_ext -p tcp --dport 22 -m state --state NEW -j ACCEPT
$IPT -A input_ext -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --update --seconds 120 --name SSH --rsource -j DROP
$IPT -A input_ext -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name SSH --rsource -j ACCEPT

Ugye ertelemszeruen, IPT az az iptables, input_ext pedig a kulso interface bejovo csomagjai. :-)

---------------------
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

A 'kezdő linux admin'-t úgy értettem, hogy egy suliban vagyok rendszergazda, ahol egy Debian alapú szervert és 55 db. dual-boot os PC-t felügyelek. És azért kezdő, mert 5 hónap Linuxos rendszergazdai munka után, nem mondhatom azt, hogy profi vagyok, hiába használok kb. 3 éve Linuxot.

"Szerző: veresh
Dátum: k, 2006-08-15 23:36

A 'kezdő linux admin'-t úgy értettem, hogy egy suliban vagyok rendszergazda,..."

Üdv.
Jó ha tudod, hogy, drastik "barátunktól" nem várható más, csak amit alant írt és még "szerény" volt. (Pedig jobban járnánk ha inkább termeszhangyákat gyűjtene afrikában.) De internet elérés NÉLKÜL!

"Szerző: drastik
Dátum: k, 2006-08-15 22:52

te nem linux admin vagy hanem linux user
veletlenul sem keverendo ossze a ketto

( _ventura_ v | 2006. 08. 16., sze – 00:39 )

viszont kiváncsi lennék hogy így törtek e már be valakihez, és ha igen milyen jelszóval ?

nálam alap hogy a root al ugye be se lehet lépni ssh-n, de még a felhasználónevet se találja nemhogy a jelszót hozzá, szal 5ös lottó esélyesebb.

mellesleg megjegyzem hogy egy szerver 2 hónapig volt kint root/1234 jelszóval mire bejöttek rá ilyen módon :D

szóval ezektől valahogy sose paráztam, ami persze nem biztos hogy jó.

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.17

( Hijaszu | 2006. 08. 16., sze – 17:01 )

Kivancsi lennek, mit szolna hozza a probalkozo rendszer, ha a 22-es porton a netcat lenne, es bejelentkezesi kiserlet eseten elkezdene attolteni a /dev/urandomot :D

( Frantique v | 2006. 08. 17., cs – 10:04 )

Csináltam egy nem ortodox megoldást, lehet, hogy szabályokkal ellentétes, és sokan a fejemet akarják majd, viszont gondot nem okozott, sőt...

Az ssh-n esetleges sikeres belépés után nem a /bin/bash-t futtatja, hanem egy bash scriptet, amely további azonosításokat kér. Ha beléptél, a script már el is emailezte a logfájl utolsó sorait egy külső emailcímre, valamint szintén egy külső címre kapok egy emailt, hogy xy ip-ről z időpontban sikeres belépés történt t juzernévvel.

A scriptet ctrl+c-vel megszakítva dobja a kapcsolatot, és az illető ip-t 10 perces banlistára helyezi.

Ha a script is azonosított, akkor megkapod a /bin/bash promtját, és a script kilép.

Hatásai: ha be is törnének, és törölnék a logokat, legalább a betörő kilétét fel tudom majd fedni.

Persze, már a belépésig is védve van a rendszer a "klasszikus" megoldásokkal (alternatív port, próbálkozások limitálása, stb.)

Coding for fun. ;)

És ha a támadó nem ctrl+c-t nyom, hanem ctrl+z-t? ;)
Vagy ha sftp-vel jelentkezik be, akkor sem fut le a scripted... :>

Egyébként se értem mire jó ez. Vannak megfelelőbb módszerek is arra, hogy bizonyos dolgokat külön hostra loggoljunk és ne a usertől függjön. A te módszerednél egyértelműen látszik, hogy sima userként is olvashatóak a logfájlok, amely nem túlságosan szerencsés. Másrészről én személy szerint utálnám, hogy az ssh auth után még valamiféle hitelesítést kellene végigszenvednem. Miből gondolod, hogy ha valaki képes az bejelentkezési jelszavadat megszerezni, akkor a scriptes azonosításodról nem tud? :P

No, itt az első "okoskodás". :) Szerintem jobb lesz, ha nem kezdem el mélyrehatóan magyarázni. ;) Lényeg az, hogy nem törtek be, habár próbálkoztak rendesen. Tehát a rendszer működőképes. Amúgy se szeretem a mások által készített megoldásokat, amelyeket nem is lehet igazán átlátni.

Coding for fun. ;)

Abban igazad van, hogy a saját megolodásaidat te magad átlátod. A mások által készítetteket meg át kell nézni hogy átlásd. Amúgy gondosabb emberek raknak komenteket hascriptról van szó,. vagy ha valami bonyibbról akkor gyártanak hozzá doksit,pont neked, hogy átlásd hogy mi hogyan müx. Sajnos az ilyesmire időt kell szakitani.
Nálunk a cégnél most vezetjük be a bacula nevű backup manager progit, mert eddig mindenféle saját scripttel dolgoztunk. Természetesen tudjuk, hogy nem fogjuk 5 pőerc alatt átlátni a működését, abban meg főleg biztosak vagyunk, hogy a Novelles kötetekkel lesz szopás rendesen, de időt áldozunk rá, mert nagyon jó szoftver. Arról nem is beszélve hogy mennyivel kényelmesebb az, ha valami hiba van, akkor csak küldünk egy feljelentést a szoftverkészítőnek és annyi.

Szóval kinek a pap kinek a papné.