US-CERT: SSH kulcs-alapú támadások Linux-alapú rendszerek ellen

Titkosítás, biztonság, privát szféra

A United States Computer Emergency Readiness Team (US-CERT) egy figyelmeztetőt adott ki, miszerint tudomása van arról, hogy olyan aktív támadás van folyamatban Linux-alapú számítógépes rendszerek ellen, amelyekben kompromittált SSH kulcsokat használnak fel. A feltételezések szerint a támadások során lopott kulcsokat használnak a rendszerhez való hozzáféréshez, majd helyi kernel exploito(ka)t a "root" hozzáféréshez. Amint sikerül root joghoz jutni, telepítésre kerül a phalanx2 névre hallgató rootkit.

Úgy tűnik, hogy a phalanx2 a korábbi phalanx rootkit leszármazottja. A phalanx2 és a vele érkező támogató script-ek úgy vannak konfigurálva, hogy módszeresen lopják el a kompromittált rendszereken megtalálható SSH kulcsokat. Ezek a kulcsok elküldésre kerülnek a támadókhoz, akik a továbbiakban ezeket a kulcsokat is felhasználhatják újabb (a támadott site-tal kapcsolatos) rendszerekre való bejutáshoz.

További részletek, és a rootkit felismeréséhez használható tippek a US-CERT figyelmeztetőjében.

( turul16 v | 2008. 08. 27., sze – 18:13 )

Sok PASSPHARE megjegyzes se begepelese helyett lehet olyat csinalni ,hogy egy master jelszoval levedem az osszeset es minidg azt keri, ill. az adott login sessionre megjegyzi ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( turul16 v | 2008. 08. 27., sze – 18:16 )

Milyen javítatlan ismert local root sebezhetőségek vannak most ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( penztar v | 2008. 08. 27., sze – 18:56 )

Hello!

Elméletileg ,ha meg is szerezték a kulcsomat és megpróbálják felhasználni akkor a a kulcshoz tartozó passphraze ismerete nélkül nem tudnak bejutni?
Én inkább minden belépésnél begépelem ,minthogy az ssh-agentre bízzam a dolgot. Tegnap láttam a logokban erre a dologra próbálkozást,de nem jött nekik össze. Ráadásul olyan bután próbálkoztak ,hogy a root nevében próbáltak belépni. A próbálkozók biztos nem ismerik az első számú alapszabályt ,hogy rootként távoli gépre nem lép be normális ember.

Üdv.

Kérem, hogy magyarázd meg ezt a megjegyzésedet! Mire való a PermitRootLogin opció? Az OpenSSH fejlesztőinek nincs köze a valódi security-hez? Nincs annak értelme, hogy ha ki lehet játszani az ssh szerver auth mechanizmusát, akkor még csak felhasználóként tud bejutni valaki a rendszerre? (És mondjuk tételezzük fel - csak a vita kedvéért -, hogy épp nincs az adott gépen futó kernelhez vagy userspace-hez local root...) Én eddig azt hittem, hogy ennek van értelme.

1. egy biztonsagi (meg mellesleg akarmilyen) mechanizmus akkor er valamit, ha garantaltan megcsinalja azt, amire szanjak.
2. egy rendszer biztonsaga nem azonos az ot alkoto biztonsagi mechanizmusok osszegevel.

a fentieken keretik kicsit elfilozni, mielott tovabbolvasol. ami kovetkezik belole a kerdesedben felvetett esetre az az, hogy ha te a PermitRootLogin-tol varod el azt, hogy megakadalyozza tavolrol a root szintu elerest, akkor bizony nem csak a PermitRootLogin-t kell szamitasba venned, hanem a rendszer egyeb mechanizmusait is. konkretan a nem privilegizalt felhasznalokat a privilegizalt felhasznalotol elvalaszto falat megvalosito mechanizmust. ez a fal a kernelben letezik, es nem mellesleg van benne szamos szandekosan letrehozott atjaro (pl. suid mechanizmus). ha te abban a hitben szeretnel elni, hogy biztonsagos a rendszered tavoli root eleressel szemben, akkor bizony a PermitRootLogin hasznalata eseten a hamis biztonsagerzet esete all fenn, mivel az elobb emlitett falon szamos, nem szandekozott res is talalhato. az, hogy te ilyenrol nem tudsz vagy nem akarsz tudni, edeskeveset szamit annak, aki mosolyogva (rajtad) setal at rajta.

" 2. egy rendszer biztonsaga nem azonos az ot alkoto biztonsagi mechanizmusok osszegevel.

Az összegével bizonyosan nem. A biztonság nyilván a leggyengébbel egyezik meg. De itt nem erről volt szó. Ha feltételezzük, hogy az openssh a "permitrootlogin no" esetén már akkor eldobja a kapcsolatot, mielőtt megkísérelne valamilyen használható auth mechanizmust, és ha feltételezzük, hogy egyszerű felhasználóként a támadó nem képes root jogot szerezni, akkor a "permitrootlogin no" növel a biztonságon. Én azt nem állítottam (sőt rendszeresen az ellenkezőjét állítom), hogy egy átlagos rendszeren nincs valamilyen ismert, félig ismert (0day) vagy nem ismert local root, vagy lyuk a falon, ahogy te fogalmaztál. Én azért kérdeztem rá, mert Hunger azt írta, hogy nincs semmi értelme a távoli root hozzáférést megakadályozni, és szeretném (továbbra is) érteni, hogy mire alapozza ezt.

Szerintem ket tipusu tamadast erdemes megkulonboztetni:

1. Tomeges beprobalkozas, ahol valamilyen ujonnan kikerult scriptet vagy kodot futtatnak le tobb tizezer hostra, egyiken csak mukodik alapon
2. Megbiznak egy profit, hogy egy adott rendszert torjon fel

Nekem ugy tunik, hogy bar a 2. ellen nem igazan vedenek az ilyen konfiguracio jellegu beallitasok, az 1. ellen csokkenthetik az aldozatta valas lehetoseget (mivel a script kiddiek a legkisebb ellenallas iranyaba mozognak, nem az a celjuk, hogy adott gepet torjenek fel, nekik jo lesz barmelyik gep, amelyiken konnyen mukodik a tores).

akkor nezzuk meg alaposabban. amirol nem volt szo idaig, de implicite ott logott a sorok kozott, az az un. threat model. az esetunkben az a kerdes, hogy a PermitRootLogin milyen tamadas ellen ved meg ill. mindezt milyen feltetelek mellett teszi. ha ezek kozul barmelyik is nem realis, nem egyezik a valo eletbeli tapasztalatokkal, akkor ugye hunger joggal kritizalta penztar jotanacsat.

a PermitRootLogin funkcio ket feltetelezesre epul:

1. a tamado kepes megszerezni egy nem privilegizalt felhasznalo bejelentkezeshez szukseges adatait, de nem kepes megszerezni a root-et (azt nem feltetelezhetjuk, hogy semmit nem kepes megszerezni, mert akkor ugye nem lenne ertelme az egesz mechanizmusnak).

2. a nem privilegizalt felhasznalokent bejelentkezett tamado nem kepes privilegium szint emelesre.

az elso feltetelezessel az a problema, hogy igazabol hamis biztonsagerzetet ad, mert egy tavoli rendszert adminisztralo felhasznalot megtamadni es megszerezni tole a tavoli rendszerbe bejelentkezeshez szukseges informaciokat fuggetlen attol, hogy az adott felhasznalo a tavoli rendszerbe root-kent vagy sima felhasznalokent jelentkezik-e be. egyszerubben, tokmindegy, hogy te root-kent vagy atya-kent jelentkezel be az altalad adminisztralt ceges tuzfalra, ugyanannyi erofeszitest igenyel az otthoni vagy ceges munkaallomasod feltorese, ahol a tuzfalra bejelentkezeshez szukseges informaciokat tarolod.

a masodik feltetelezessel meg az a problema, hogy nem kis munka olyan rendszert konfiguralni, ahol ez teljesul. saccra az internetre kotott gepek tulnyomo tobbsegenel nem all meg ez a feltetel.

Kihagysz egy fontos lehetőséget, amit én a sorok közt említettem. Ha a támadó irányítottan támad, elég hozzáértő és idővel/energiával/haraggal rendelkezik, akkor ellene a sikeres védekezésnek 0 azaz nulla esélyét látom. Ha azonban nem irányítottan támad, hanem megvett a fekete piacon egy ssh auth 0 day-t, akkor se a user (aki sudo után távoli admin), se a távoli root hozzáférését nem szerzi meg, tehát ha az ssh beengedi root-ként, akkor alma, ha nem, akkor jöhetnek a 0 day local root exploitok, de ez meg ugye megint megdrágítja, megnehezíti. Tehát szerintem létezik olyan (tömeges, tehát nagyobb esélyű) támadási forma, amely ellen a permitrootlogin no sikeres védekezés, illetve erősebb védelem lehet. Amíg Hunger meg nem cáfol. Egyébként a "nem képes privilégium szint emelésre" kifejezés szerintem olyan, mint a "tisztességes politikus". Szerintem ilyen rendszert semekkora -kivitelezhető- energiával nem lehet csinálni. Talán az NSA képes lenne ennyi energiát rászánni. És egyáltalán nem az SELinux-ra vagy bármi ilyen Flask izére gondolok, hanem egy tényleg EAL7-es OS-re. Az meg hát... Majd ha piros hó esik.

Már öreg este van ahhoz, hogy most elolvassam az openssh forrását, de az volt a fenti fejtegetés alapja, hogy a permitrootlogin opciót az ssh szerver még akkor ellenőrzi, mikor megtudja a felhasználó nevét, és még el se gondolkodott, hogy hogy is azonosítsa. Az "ssh auth 0 day" kifejezés egy olyan, a fejlesztők és a nép előtt nem ismert exploit lenne (hangsúlyozom, nem tudok ilyenről, csak tegyük fel), amely képes kijátszani mondjuk az ssh szerver RSA kulcs alapú azonosítási módszerét, így a támadó be tudná hazudni bármely esetben, vagy speciális esetekben, hogy ő Admin Norbert vagy épp a root maga. Utóbbi esetben már nincs miről beszélni, csak a rootkit telepítőt kell felmásolni és kész a baj. Ha a permitrootlogin nem azt csinálja amit én gondolok, de szerintem valszeg azt csinálja. És ha igen, akkor ugye jöhet az első variáció, ahol az idegennek még egy júzernevet is ki kell találni. Jó, ez nem annyira nehéz, de mondjuk Brazíliából kissé munkásabb egy szerver három felhasználójából az egyiket kitippelni.

A második kérdésre a válasz, persze, hogy nem kezdené számolgatni. De hát ez csak elmélkedés, ugyebár, szóval engedtessék meg nekem, hogy azt mondjam: két, szekvenciális biztonsági intézkedés több, mint egy. :)

ha jol ertem, akkor oda lyukadtunk ki, hogy a PermitRootLogin egyetlen elonye az, hogy meg tudsz vele akadalyozni egy ismert nevu account elleni tamadast az ssh kapcsolat egy korai fazisaban. azon tul, hogy ez security by obscurity, megkerdeznem, hogy mi akadalyoz meg abban, hogy atnevezd a 'root'-ot valami masnak? ;)

Biztos érthetetlenül fogalmaztam. Ez nem security through obscurity, valóban véd valami ellen. Azt belátom, hogy abból a szemszögből, hogy "megszerezhetem a root és a user jelszavát egyaránt", valóban nincs jelentősége. Ismeretlen támadók esetén van, de ezt már leírtam, ha érthetetlenül is.

Legyen az, hogy mindenki használja az ssh-ját ahogy akarja. Aki akar, menjen root-tal, én nem fogok. Engem még így tanítottak és szerintem ésszerű is.

eloszor azt mondtad, hogy van egy helyzet, amivel nem szamoltam. kiderult, hogy ssh 0-day-re gondoltal, amivel ki lehet jatszani a hitelesites folyamatat, felteve, hogy a tamado legalabb a felhasznalo nevet tudja. ekkor szerinted a PermitRootLogin jol jonne, mivel a 'root' nevu felhasznalot kapasbol kirugja. amire ravilagitottam az az, hogy ha a vedelmed a felhasznalok nevenek titokban tartasara alapozod (ez a security by obscurity tipikus esete), akkor ennyi erovel a root-ot is atnevezheted es nem kell PermitRootLogin. szoval a te altalad vazolt helyzetben sincs ertelme. persze ettol meg hiheted, hogy amit neked tanitottak, az esszeru, csak akkor jo lenne mar vegre megmagyarazni, nem csak gorcsosen hajtogatni, mert igy kicsit vakhit szaga kezd lenni a dolognak ;-). amiert nem hagyom a temat annyiban meg az, hogy nem szeretem a hamis biztonsagerzetet okozo dolgokat, mert tobb kart okoznak, mint amikor az ember tudja, hogy valamije nem biztonsagos (ui. maskepp szamol a kockazatokkal).

szo sem volt uid-rol ;). atya arrol beszelt, hogy a vakon probalkozo tamadok ellen jo a PermitRootLogin, mivel a 'root' nevet nem kell kitalalni, csak a hozza tartozo jelszot/kulcsot/akarmit (vagyis az implicit feltetelezes az, hogy a tamado ki tudja ezeket talalni, de a usernevet nem). erre mondtam, hogy ha csak ennyi az ertelme, akkor egyszerubb atnevezni a root-ot es maris pont annyit kell kitalalnia, mint az altala titokban tartott normal felhasznaloneveknel.

Nagyra becsüllek (noha az inkognitó nemigen illik a fehér kalaphoz), ezért elmondom még egyszer. Mintha nem értenéd, hogy mit mondok. Pedig inkább csak nem akarod.

Ha a támadó eleve 0 uid-del tud belépni az ssh auth kijátszásával, akkor azonnal nagy a baj.

Ha a támadó egy ssh beállítás miatt nem tud eleve 0 uid-del belépni, akkor még több energiát kell szánnia erre a rendszerre. Ez segít_het_.

Ha még most is jössz a security through obscurity-vel, akkor már nincs több érvem, mert nem lehet téged meggyőzni.

Vicces, ahogy így mondod, hogy az ssh védelmi mechanizmusai a NATO, a kernel védelmi mechanizmusai meg egy portás bácsi... Főleg ha az a kernel egy patkolt RSBAC, grsec, PAX reszelvény. Hát, te biztos jól tudod, hogy is megy ez. Itt többen alázzák a kernel védelmi részét, amit én készséggel el is hinnék (noha azért nem jönnek-mennek a népek a kernel priv szintjein keresztül, ha van is olyan, akinek ez nem okoz gondot), node. A kiegészítések azért vannak, hogy segítsék a BoF, a null pointer deref, a stack exec meg még sokmás elleni támadások kivédését. Akkor most ezek semmire valók. Minek erőlködik pl. a Paxteam, ha azon is át lehet menni, mint kés a vajon. Ha meg nem, akkor mégis jó lehet a permitrootlogin valamire?

A jó hozzáállás az, ha alapból ezt feltételezve építed ki a rendszeredet...

Egyébként meg nincs ez a feltételezés elrugaszkodva a valóságtól. Túl nagyok és bonyolultak a mai általános OS kernelek ahhoz, hogy bátran biztos lehess abban, hogy minden valamirevaló támadónak van egy-kettő ilyen a tarsolyában.

tudnal mondani olyan linux kernel verziot, amirol a mai napig nem derult ki, hogy volt benne kihasznalhato hiba? vmsplice meg do_brk es tarsai ugye lefednek par generaciot, de azert lehet probalkozni. mellesleg megjegyzem, hogy pl. tavaly a sracok javitottak egy olyan hibat 2.6-ban, ami valoszinuleg meg a 2.0 elotti idokbol szarmazik (nem volt mar kedvem annyira utananezni), es elso ranezesre kihasznalhatonak tunt, de errol mit sem tudtak, es ezert a mai napig nincs javitva regebbi kernelekben...

A tegnapi git :) (2.6.25.11..git ?)

És mi a helyzet a 0dayel, bácsi kérem? ;)

A korabeli vmsplice(), ill. do_brk() hibak kihasznalasat meg tudjak -e fogni gcc opciok, ill. PaX vagy hasnlo vedekezesek ? Ha igen melyik tudja es mivel ?

A vmsplice() egy rakás sebezhetőséget tartalmazott. Az egyik egy null ptr deref probléma volt, azt a PAX_UDEREF megfogja már közvetlenül a kernel->userland hivatkozásnál, de ha az nincs a kernelben, akkor a PAX_KERNEXEC fogja meg a (shell)kódvégrehajtást (bár utóbbit nagyon trükkösen és bonyolultan talán kilehetne játszani ret2libc-szerű módszerrel, úgyhogy inkább a PAX_UDEREF ad rá rendes védelmet).

A do_brk() ellen a PAX_MPROTECT restrikciók is elegendők, ha valamilyen MAC rendszerrel mellette ki van kényszerítve a PAX_FLAGS.

A gcc opciók meg nem sok vizet zavarnak... :)

Szándékosan nem kölünböztetitek meg a célzott támadásokat és az automatikus támadó scripteket? A hír is arról szól, hogy automatikusan próbálkoznak root -al belépni. Ez ellen bármilyen primitív is a PermiRootLogin véd annyiban, hogy usernevet is ki kell találniuk (átnevezni is lehet csak az macerásabb) ráadásul ez igencsak kis befektetés azért, hogy az automata támadók jó részével ne kelljen foglalkozni. Aki céltudatosan támad (célja az adott rendszerbe jutás és nem tetszőleges számú bármilyen rendszerbe bejutás) az ellen sztem senki sem gondolja, hogy ez védelem. (Azt sem hinném, hogy root@ssh -val próbálkozik aki ért hozzá...)

Root login tiltásának egyéb kedvező hatásai is vannak:
- ha mindig root-al lép be az admin akkor minden feladatra azt fogja használni (még az explorert is innen indítja :)
- ha saját user-el majd sudo (vagy su) akkor rájön, hogy root nélkül is mennyi mindent meg lehet csinálni ;) sőt olyan rendszert is kialakíthat ahhol semmilyen adminisztrációs feladathoz nem kell root shell-t indítani a rendszert érintő hibaelhárítást kivéve.
- Ha nagyon gyönge HW-n van az ssh (és állandó támadások vannak) lehet, hogy teljesítményt takarít meg azzal, hogy a pw hash-eket nem kell összehasonlítani. (Igaz az SSH session felépítése valószínú nagyságrendekkel több erőforrást emészt fel... nem néztem a forrást)
- Mivel a scriptek a root felhasználót támadják a valódi támadót nehezebb kiszűrni a zajból, míg ha az admin userek loginjait kezdik próbálgatni akkor már baj lehet...
- Ha több admin van akkor a szőnyeg széli történetek miatt amit itt már többen említettek jól jöhet(loggolás)

Biztos van még több előnye is. Hátrányát azon kívül, hogy hamis biztonságérzetet adhat nem látok és ti sem soroltatok fel ezért érthetetlen ez a hadjáratotok ellene bár ti vagytok a profik ebben a témában.

Remélem senkit sem riasztottatok el attól, hogy beállítsa... (és azt is remélem, hogy aki beállítja nem hiszi azt hogy a rendszere csupán ettől biztonságos lett)

Azt, hogy ki lépett be, nem minden esetben elegendő logolni, ezért célszerű a dolgot rendszerben nézni: lehetőség szerint saját account plusz sudo. A több darab 0 UID az több 0 UID-hoz tartozó account, több támadható root-jogosultság. Egyébként meg igen-igen komoly elvárások vannak itt-ott arra nézve, hogy a rendszergazda, de akár a normál userek tevékenységét hogyan, milyen módon/védelemmel kell naplózni -- van erre eszköz, illetve szoftveres megoldás is.

Valóban, de ha hozzáveszem, hogy az a logbejegyzés, miszerint A. belépett, majd su-zott, és végrehajtotta a qwe, ert, tzu parancsokat az érdemi infót szolgáltat, ha root-ként ment be, akkor csak azt tudom, hogy valaki belépett root-ként, és kiadta a qwe, ert és tzu parancsokat. A felelősségi kérdést nem lehet tisztázni, hiszen nem lehet kideríteni, hogy ki jelentkezett be root jogosultsággal.
Vacak dolog a szőnyeg szélén állni, csak azért, mert tudod a rootjelszót, és valamelyik kolléga, aki szintén ismeri, csinált valami baromságot...

en ertem mit mondasz, csak nem ertek vele egyet. konkretan:

> Ha a támadó egy ssh beállítás miatt nem tud eleve 0 uid-del belépni, akkor még több energiát kell szánnia erre a rendszerre.

ezt a kijelentesed mire alapozod? ill. miben merul ki a 'meg tobb'? mert ugye az az alapfelteves, hogy a tamado valahogy be tud lepni (meg tudja szerezni valaki login adatait), tehat a kerdes az, hogy mennyivel van hatrebb, ha nem direkt root, hanem root-ta valni tudo felhasznalo csak. szerintem semennyivel, szerinted meg valamivel. kerdes, hogy mi ez a valami. saccra itt arra gondolsz, hogy meg kell me'g szereznie pl. a su-nal hasznalt jelszot, ami, oszinten szolva, meglepodnek, ha nem lenne benne a .bash_history-ban (ki nem gepelte mar melle?), de van szamos mas modja is nyilvan. meg ugye ott van az orok local kernel exploit esete. akkor lenne igazad, ha mindezen tamadasi modszerek ellen *is* lenne vedekezes (erre irtam korabban, hogy ilyen rendszert nem trivialis konfiguralni, plane ha hasznalhatonak kell lennie) ill. a PermitRootLogin doksija egyertelmuen felhivna ennek szuksegessegere a figyelmet, de mint tudjuk, nem ez a helyzet.

ha abbol indulsz ki, hogy a tamado mindig olyan szofisztikalt, hogy csak a matematikailag bizonyithatoan biztonsagos (szerk: fizikailag is persze) rendszerbe nem jut be, akkor tenyleg fel pillanat - de akkor meg semmilyen ma letezo biztonsagi intezkedesnek nincs ertelme.

- Use the Source Luke ! -

Nem, én arra gondolok, hogy ha egy keylogger naplójában ott van, hogy:

ssh -l simauser nagyonsecure.hu
s3cr3t15
su -
s3cr3t25

akkor nem sokkal nehezebb a dolga a támadónak, mint ha az lenne benne, hogy:

ssh -l root nagyonsecure.hu
s3cr3t25

Értem? :)

(Upsz, a példa jelszavak véletlenül megegyeznek trey hupdb és wiki jelszavaival... ;))

Szerintem amíg ilyen HUP kaliberű oldalakkal játszol, addig nincs mitől félned. Csodálkozni nem csodálkozom, mert már sok-sok éve is ezt tetted.
Persze emlékszünk szerintem mindketten arra, hogy már évekkel ezelőtt is játszottál olyanokkal, ahol ráfaraghattál volna. De ez maradjon a mi titkunk ;)

--
trey @ gépház

A citi-s és egyéb software-es védelmek elég mókásak, pl a citi bill. képernyőhöz is csináldtak sniffert ... nem csinált mást mint minden egérkattintáskor a kurzor NxN pixeles körzetéről screenshot-ot csinált ... na és mi volt a képeken? (hát persze, hogy a jelszavad :).

Nem mondom, hogy 100%-os megoldások, de a hardware alapú (ez lehet akár papír is :) megoldások kicsit szimpatikusabbak.

Egyébként meg mindek ellopni a jelszavát, meg a hozzáférését, elég felnyomni a gépét (mondjuk valamilyen böngésző/levelezőbug v. egyéb segítségével) aztán ptrace az ssh/egyébteccőlegescéltárgy processzre és már csináljuk is amit akarunk és a csorikám csak azt látja majd, hogy a saját gépéről történt a dolog, de sehogy se érti majd :)

És ehhez még lokál/remote root sem kell, a root amúgyis veszélyes :P

Már öreg este van ahhoz, hogy most elolvassam az openssh forrását, de az volt a fenti fejtegetés alapja, hogy a permitrootlogin opciót az ssh szerver még akkor ellenőrzi, mikor megtudja a felhasználó nevét, és még el se gondolkodott, hogy hogy is azonosítsa.

Egyrészről ehhez nem kell feltétlenül elolvasnod a forrást, mert tapasztalati úton is eldöntheted: amikor root-ként próbálsz bejelentkezni a szerverre és a PermitRootLogin no, akkor egyből kidob, amint elküldésre kerül, hogy user: root, vagy pedig ugyanúgy kéri a jelszót továbbra is?

Ennek persze oka van, hisz ha egyből visszautasítana, akkor az egyfajta infoleak lenne arról, hogy ez az opció tiltva van, vagy pedig, hogy a felhasználó nem is létezik (ez is értékes információ, ugye :).

Másodszor pedig nyugodtan nézd meg a forrást, mert ugye pont ez a lényeg, ha nem csak elméleteskedni akar az ember... Amit észre kell venned, hogy az az információ, amely alapján eldől, hogy az sshd beenged-e a végén az egyetlen változó tartalmán múlik (egész pontosan az 'authenticated' nevű változón). Ha ez a végén 0, akkor sikertelen a bejelentkezés, ha nem 0, akkor sikeres. A PermitRootLogin beállítás pedig csak ennyit jelent a kódban:

/* Special handling for root */
if (authenticated && authctxt->pw->pw_uid == 0 &&
!auth_root_allowed(get_authname(type)))
authenticated = 0;

Azaz, ha ennek a feltételnek a lefutása után te egy hibát kihasználva áttudod írni az 'authenticated' változót, akkor máris be vagy jelentkezve...

Ez lényegében 1 byte (sőt, 1 bit ;) átírása az authentikációt végző process memóriaterületén.

Megpróbálok válaszolni valamennyire, de nem szeretnék sok időt a témával eltölteni, mert sajnos van már tapasztalat arról, hogy mennyire hiábavaló az ilyen jellegű eszmecsere (ne vedd személyes támadásnak vagy sértésnek, a hiba javarészt azokban az "akadémiai" leírásokban és konferenciákban van, amelyeknek a lehető legkevesebb közük van a valósághoz, a valódi informatikai biztonsághoz, hackeléshez, de mégis a leginkább elterjedő fals gondolkodásmód mögött állnak). Az egyik legnagyobb probléma az, hogy a legtöbb fejlesztő/kutató azt hiszi, hogy ezen a területen (is?) elég a felszínes vagy elméleteskedő hozzáállás. Épp ezért mostanság az igazi hozzáértők már nem is szeretik beleérteni magukat a "szakmába", mert ál-szakértőkkel eléggé tele van a padlás. Jól példázza ezt az is, hogy mostanság jópár "Security Expert" levelezése és egyéb privát szennyese lett kiteregetve az interneten, hogy elveszítsék azt a fajta hitelüket, amelyet egyébként sem érdemelnek meg (Lásd Petko D. Petkov mailboxa, vagy Alan Shimel bankkártya adatai).

Nade visszatérve a nagy felháborodást keltett kijelentésemre. :)

Kategorizáljunk... Nézhetjük a problémakört a védelem oldaláról és közvetlenül támadás oldalról is. Persze a legjobb védelmek a támadási módszerek figyelembe vételével készülnek. Én most nyilván támadás oldalról nézem elsősorban a dolgot. Szóval, milyen módszerekkel juthat be ssh-n keresztül egy támadó:

1. Kitalálja, hogy a jelszó 'asd1234'. :) Szerintem mi most nem ezt a fajta támadást keressük, de tegyük félre későbbi elemzésre ezt a scenario-t is.

2. Valamilyen módszerrel hozzájut a jelszóhoz. Ez történhet a kliens számítógép kompromitációjával (amelyről a kapcsolat kezdeményezés történik), keylogger felhasználásával, valamilyen Man-in-the-middle támadással, ahol bele tud hallgatni a kommunikációba vagy akár a hátad mögött kilesve, hogy mit gépelsz a billentyűzeten.

3. A szervert támadja, amelynél vagy magában az ssh szerverben (sshd) használ ki egy sebezhetőséget, vagy egy másik futó szolgáltatásban.

Az első esetben két lehetőség van. A 'root' jelszót találja ki a támadó, vagy a 'user'-ét. Előbbinél nyilván a PermitRootLogin kikapcsolása megvéd a bejutástól, de valószínűleg te nem erre a nagy védelemre alapozol és vélhetően nem ilyen könnyen kitalálható a root jelszavad... Ha viszont a user jelszót sikerül kitalálni, akkor már érdekesebb dolgokra van lehetőség.

- Kilehet használni lokálisan egy kernelben lévő sebezhetőséget (van belőle bőven, hidd el :)

- Kilehet használni lokálisan egy suid root binárisban lévő sebezhetőséget (konfiguráció és telepített alkalmazástól függ).

- Olyan trükkös csapdát lehet előkészíteni, hogy amikor majd te bejelentkezel és beírod a su/sudo után a jelszót, akkor azt - vagy az uid=0 sessiont - megszerezze a támadó (nem annyira nehéz, mint elsőre tűnik)

Nem akarok - érthető okokból :) - konkrét megoldásokat felvázolni, de utóbbi is elég jól működik és az áldozatok jórésze nem veszi észre a csalást, vagy mire észbekap már késő...

A második eset elég gyakori és csak az utóbbi időben kapott nagyobb figyelmet, legfőképp a kliens-oldali támadások miatt (böngésző és levelező kliens sebezhetőségek kihasználása).

Elkanyarodva kicsit: egyik kedvenc történetem ezzel kapcsolatban egy 2002 körüli eset, ahol az ismert szakértőt és OpenBSD/OpenSSH/dsniff fejlesztőt, Dug Song-ot palizott be (feltehetőleg :) Gobbles úgy, hogy egy IRC kliensében lévő hibát kihasználva bejutott a szerverébe (monkey.org). Az eset kiderült és Dug Song magyarázkodott mindenfele, hogy hogyan is történhetett mindez. Egy később publikált Apache exploitban (apache-scalp.c) viccesen csak annyit írt Gobbles: ". . . and Doug Sniff said it was a hole in Epic." :)

Na szóval ez 2002-ben volt és azóta azért elég sokat változott a világ. A kliens-oldali hibák kihasználása virágkorukat élik (upsz, képzavar %), amelyet jól bizonyítanak a milliós számban előforduló zombi gépek, botnetek is.

Ha pedig azt feltételezzük, hogy valaki képes lehallgatni/leloggolni a jelszavunkat, amikor a kliensünkön beírjuk egy ssh bejelentkezéskor, akkor miből gondoljuk, hogy a belépéshez használt user jelszót tudja csak kizárólag megszerezni a támadó és az utána beütőtt (su/sudo/kutyafüle :) root jelszót nem? Nyilván semmi technikai akadálya nincs utóbbinak se...

A harmadik eset az, amelyet a legutóbbi hozzászólásodban is említettél. A probléma az, hogy azt feltételezed egy ssh exploit esetén a RemoteRootLogin tiltása bármit is segítene. Persze nyilván előfordulhat olyan jellegű sebezhetőség is, amely ilyen beállítás mellett kihasználhatatlanná teszi a root jog megszerzését, de erre elég kevés az esély.

Az ilyen jellegű alkalmazásoknál alapvetően két különböző sérülékenységet különböztetünk meg (az, hogy ssh auth 0day, így nem mond semmit)... Vannak pre-auth és post-auth sebezhetőségek. Pre-auth esetén még valós felhasználónév/jelszó párossal _se_ kell hogy rendelkezz ahhoz, hogy lokális hozzáférést szerezz. Post-auth esetén pedig rendelkezel egy érvényes user/pass-al, viszont a problémát kihasználva nagyobb privilégiumot tudsz szerezni.

Nyilván OpenSSH-nál kicsit bonyolítja a helyzetet, hogy van egy UsePrivilegeSeparation opció is, amelynek köszönhetően az authentikáció során az sshd nem root-ként kommunikál a klienssel, hanem egy korlátozott, /var/empty/-be chroot-olt userként (OpenBSD-n _sshd, más rendszereken simán sshd user). A helyzet azonban az, hogy aki ilyen jellegű támadást kezdeményez, annak egyébként is meg van a módszere arra, hogy az elszeparált privilégiumból emeltet szerezzen, akár kernel hibák kihasználásával, akár az sshd-ban egy másik hibának a kihasználásával. Egyszer régen idéztem ezt, amelyik természetesen még mindig igaz: Halvar Flake once said, "No good hacker just looks for one bug." Ha pedig egy memória korrupciós hibának köszönhetően módosítani lehet úgy az sshd futását, hogy beengedjen, akkor azt a kis memóriában tárolt változót sem nehéz már átírni, amely azt tárolja, hogy EngedélyezettaRootLogin vagy sem... ;)

Egy ssh 0day exploit egyébként nagyságrendekkel többet ér, mint egy local root exploit... Szóval ha valaki képes egy ssh 0day-t megvenni, amely esetleg nem is ad kapásból rootot, akkor is az adott rendszer kerneléhez exploitot vennie ehhez képest már tényleg semmiség. :)

OT
Bocs, de esetleg van olyan ember, akinek esetleg nem *triviális*. Jelenleg ott tartunk, hogy 3 olyan ember között látszik kialakulni ÉRTELMES kérdezz-felelek, akik IMHO! az átlagnál többet tudnak a számítógépes biztonságról. És ebben az esetben a lényegtelen beleböffentések előre nem visznek, ezzel szemben ha esetleg hagynánk őket kibontakozni (vagy értelmeset tudnánk kérdezni), az mindenkinek jó lenne. /OT
Szerk: esetleg valamelyik házimanó rakja át a flame-be, és akkor megnyugszom.

A trivialitásokkal az a baj, hogy azokat nem mondja ki az ember ... és a ilyenkor a hallgató azt ért alatta amit akar (pl mást mint amit a beszélő gondolt :) ...

Sokan azt hiszik, hogy elég a "PermitRootLogin no" és már biztonságban is vannak illetve vannak páran akik szerint semmit sem ér :)

Szerintem egyik sem igaz, mert valóban nem óv meg attól, hogy lopott kulcs/jelszó segítségével bejussanak a rendszerre (tipp: használj olyan kulcsot, aminél észreveszed, hogy ellopták, pl: usb tokent ... jó tudod, Dexter abból is ellopja, de pl halál ellen sincs orvosság), de megóv az agyatlan zombi próbálkozásoktól, amikor a root acc-ot próbálját törni erőből (szótári alapon) távolról.

Asszem nem pont PaxTeam-nek kell elmesélni milyen remek állapotban van a 2.6-os Linux kernel biztonsági téren (igen és is masztizómajom vagyok :), illetve Zahy is biztosan ismeri a *BSD-ek képességeit, de lássuk be az esetek többségében a támadást sokkal egyszerübb emberi tulajdonságok ellen kivitelezni, mint sw hibák kihasználásval.

Garantáltan olcsóbb megoldás mint bug-ot venni :), mondjuk aki maga keresi és találja (írja:) a bug-ot annak megvan rezsiben ...

Pl lehet egy hardened OpenBSD-d, a legkiválóbb védelemmel, ha van olyan adminod aki a Zinternetezős XP-jéről adminisztárja, akkor nem kell oda semmilyen BSD v. ssh bug, elég az a admint, bocsánat, usert szemmel tartani, idővel meglesz a kivánt hozzáférés. (itt jön a képbe PaxTeam 2. pontja: egy rendszer biztonsaga nem azonos az ot alkoto biztonsagi mechanizmusok osszegevel. mert ez is része a rendszer biztonsági mechanizmusainak.) vagy unix-on ott vannak azok a remek race-ek amikre Hunger is utalt, szerintem:)

De had írjak én is trivialitásokat:

1. Nincs feltörthetetlen rendszer (de van, csak azok használhatatlanok, pl: 1x1 méteres tömör betonba öntött, kikapcsolt gép) és nem is lesz, bármint is mond a marketing.

2. Lehetséges, sőt érdemes a feltörés (károkozás) valószínűségét csökkenteni. Mindent meg kell tenni, hogy ne Te legyél az idális/könnyű préda. (erre még a sok álszakértő irásai közül is jó némelyik.) Használj többrétegű védelmet, hátha valamelyik réteg megfogja a támadót ...

Pl: maradva az ssh-nál és linux-ot feltételezve:
- kernelbe grsec (PAX-xal :), ha már fenn van esetleg ACL képességek használata ...
- iptables (még mindig jobb beengedni néhány hazai szolgáltatót, mint a nagyvilágot),
- ssh-ban az értelmes opciók használata
- sudo nem su
- valamilyen lenyomatkészítő és elemző értelmes használata (aida?, tripwire ...)
- távoli logolás (így legalább a támadás elejét látod majd az ott megőrzött logban, ha fel nem nyomják azt is :)
- esetleg ssh port elé, az sshtől független (kisebb kódbázisú, auditált, stb) kapúnyitó eszköz, valamilyen hw-s/OTP azonosítással (Cert Aladin-on, CryptoCard, SecureID, stb), így nem elég az ssh kulcsot ellopni, illetve a mezei ssh exploit sem lesz elég a támadáshoz ...
- képezd a usereidet, hogy ne csináljanak veszélyes dolgot, hogy ha veszélyes dolgot csinálnak, ne hallgassák el ... (pl ne adják kölcsön a gépüket, ne onnak adminisztáljanak ahonnan warezolnak, stb)
- használd a biztonsági frissítéseket (már ha tudod róluk, hogy azok :), persze van 0day rengedeg, de a zombi gépek nagy százalékát szerintem 60 napnál régebbi buggal tolják meg ... (de ne feledd: update = ismert hibák cseréje ismeretlenekre) és rendszeresen ellenőrizd a rendszeridet, a magára hagyott rendszer a legjobb célpont.
- a "desktop"-od se legyen kevésbé biztonságos, mint a rendszer amit arról üzemeltecc (tudjátok PaxTeam 2. pont :)

3. Mivel a 2.-tól függetlenül az 1. pont igaz: Legyen naprakész mentésed a célrendszertől független (fizikailag távol, hálózatilag elérhetetlen) helyen. Mert az is baj ha lenyomnak, de az mégnagyobb baj, ha nincs miből visszállnod, hanem kezdheted 0-ról az egészet.

Na de minek is írtam le, hiszen van akinek ez triviális :)

Hát, hogy mindig, azt nem tudom, de van olyan eset amikor jobb mint a su.

Pl:
- nem kell osztozni a root jelszón több felhasználónak (így több admin esetén nagyobb az esélye annak, hogy tudd ki mit csinált rootként),
- elvileg szabályozható, ki és milyen parancsot futtathat rootként v. egyéb felhasználóként a sudo segítségével
- nem szükséges root jelszó használata (tehát így kitalálni sem lehet :)

Másra való. A su jó egy egyszemélyesen adminisztrált rendszer esetén, sőt kicsit jobb is, mert a felhasználó jelszava nem egyezik meg az admin jelszóval. Többadminos és operátoros rendszer esetén azonban a sudo sokkal ésszerűbb választás, operátorok esetén nincs is más lehetőség.

Az egyből rootként bejelentkezés, lett légyen konzolról avagy távolról egy másik problémát is feszeget, méghozzá a "ki volt az?" kérdéskörét. Komolyabb rendszerek körül több olyan személy is található, aki root-ként tevékenykedhet. Ez egészen addig nem okoz problémát, ameddig valami okból nem kell a root-jogosultsággal rendelkezőknek (jobb esetben...) a szőnyeg szélén állniuk. (v.ö: letagadhatatlanság).

A távoli adminisztrátori szintű bejelentkezés megléte esetén elég egy account adatait megszerezni, míg ha csak normál felhasználóként lehet a gépet távolról elérni, akkor kell egy normál felhasználói acocunt plusz vagy egy local-admin/root exploit, vagy pedig a root/admin accounthoz tartozó bejelentkezési információk.

Úgy vélem, hogy a közvetlen adminisztrátori szintű bejelentkezés tiltásával a rendszer teljes kompromittálódásához szükséges munka/információ menyiségét növeljük meg, ami lehet, hogy csak picit növeli meg a rendszer biztonságát, azonban jelentősebb hátránya nincs, így az alkalmazása erősen javasolható.

> Az egyből rootként bejelentkezés, lett légyen konzolról avagy távolról egy másik problémát is feszeget, méghozzá a "ki volt az?" kérdéskörét.
> Komolyabb rendszerek körül több olyan személy is található, aki root-ként tevékenykedhet. Ez egészen addig nem okoz problémát, ameddig valami
> okból nem kell a root-jogosultsággal rendelkezőknek (jobb esetben...) a szőnyeg szélén állniuk. (v.ö: letagadhatatlanság).

es ezen hogy segit a normal felhasznalokent torteno bejelentkezes (kene mondanod egy rendszert, amit egy rosszhiszemu admin sem tud kijatszani)? a unix nem arra lett kitalalva, hogy a mindenhato root felhasznalot nyomon lehessen kovetni.

> A távoli adminisztrátori szintű bejelentkezés megléte esetén elég egy account adatait megszerezni, míg ha csak normál felhasználóként lehet a
> gépet távolról elérni, akkor kell egy normál felhasználói acocunt plusz vagy egy local-admin/root exploit, vagy pedig a root/admin accounthoz
> tartozó bejelentkezési információk.

tehat ha van x admin jogu felhasznalod, akkor az egyik esetben eleg megtorni barmelyikuk rendszeret, hogy a tamado root-kent bejusson az altaluk adminisztralt gepekre, a masik esetben pedig eleg megtorni barmelyikuk rendszeret, hogy a tamado normal felhasznalokent bejusson majd root-ta valjek. mi is a kulonbseg valojaban akkor? azt kene eszrevenni, hogy a tamadora vonatkozo feltevesben nem jatszik szerepet az, hogy az admin milyen jogu felhasznalokent eri el az adminisztralni kivant gepet...

> Úgy vélem, hogy a közvetlen adminisztrátori szintű bejelentkezés tiltásával a rendszer teljes kompromittálódásához szükséges munka/információ
> menyiségét növeljük meg, ami lehet, hogy csak picit növeli meg a rendszer biztonságát, azonban jelentősebb hátránya nincs, így az alkalmazása
> erősen javasolható.

egyenlore (halal az egyelore! ;) az se vilagos, hogy a tamado szamara barmit is megnovelsz, az viszont vilagos, hogy az adminisztratoroknak extra munka egyfolytaban su-zni (mellesleg ezzel sokszorosara noveled az ehhez szukseges jelszavak kiszivargasanak eselyet).

a PaxTeam valaszabol ugy veszem ki, hogy a PermitRootLogin letiltasanak akkor van ertelme, ha nem tavolrol adminisztralod a gepet (szoval csak lokalisan rootkent belepve lehet adminisztralni a gepet).

szerk: jol van, megint hulyeseget irtam - elfelejkeztem a su(do)-rol :)

- Use the Source Luke ! -

( crypton | 2008. 08. 27., sze – 23:39 )

Szerintem:

+password only ssh access, (eros pwd)
+fail2ban,
(+rkhunter.)
(+IDS)

ezek jo megoldasok lehetnek a remote tamadas ellen...?

cryp

Kulcs adathordozó eltulajdinítódás?
Ha meg titkosítod a kulcsot, valami 10soron, akkor az a szopás...
Láttam egy kolléga esetében multkor, hogy míg a HDD elhalt a gépében, addig a mentés céljára szánt cd-t a barátnője letakarította körömlakklemosóval, mer az jó neki, mer koszos.
IP konzol, ILO stb. nem lévén, kocsikázni kellett...

kötöjelkötöjel
Kiszámít mér és berakodás idő -ból -a Pókháló

Ha a kulcs adathordozót eltulajdonítja, akkor még mindig ki kell találnia a kulcs jelszavát. És ugye el kell először tulajdonítani a kulcsot, és ki kell találnia, hogy a talált kulcs melyik gépen, milyen felhasználóhoz tartozik. Ezt egy pendrive-on talált kulcsból nem fogja kitalálni.

Ha a jelszavas belépés engedélyezett, akkor meg nem kell semmi, csak a hálózaton keresztül megpróbálni kitalálni a felhasználónevet, jelszót.

Nekem két gépem lóg állandóan a neten, ssh user/pass próbálkozás folyamatos, mindenhonnan.

És ki tudja, hogy azon a gépen, amin felhasználók is vannak, a pisti user jelszava nem titok-e véletlenül...

Szóval én úgy látom, hogy ha jelszavas azonosítás engedélyezett, akkor a script kiddie-k reménykedhetnek. Ha csak kulcs, akkor ráfaragtak, mert kulcsot kitalálni nem fognak.

Szóval lehet, hogy a kulcs egy kicsit nem biztonságos, de a jelszó meg nagyon nem az.

G

Gyermekmondóka méretű jelszó; sok -és értelmetlen- karakteres felhasználónév, sshd >1024 porton; csak VPN-en csatlakozva, login engedlyezése csak 1 usernek, su engedélyezése csak egy másiknak, libwrap, iptables, etc.
Nem pont attól félek, hogy az sshd-t fogják megborítani...
Apache, Postfix, bármi nagyobb veszélyben van szvsz.

kötöjelkötöjel
Kiszámít mér és berakodás idő -ból -a Pókháló

Én értem, hogy jelszavas belépés is lehet biztonságos.

De nem látom bizonyítottnak, hogy a jelszavas belépés biztonságosabb lenne, mint a kulcsos... ugye én erre írtam.

A másik: OK, hogy én adok egy megfelelően bonyolult jelszót az embereknek, de utána ki tudja, mit fognak majd helyette választani...

Egy cégnél jártam, ahol megvoltak a jelszó szabályok, minimum hossz, nagybetű kisbetű szám... aztán hogy, hogy nem, olyan jelszavak lettek, hogy pl. Qwert12345

Egyedileg generált jelszavakat kell adni; a usernek nem kell megváltoztatnia.
14 naponként random jelszó generál; kiküld sms-ben, oszt jónapot. (ssh-n meg ne lépjen már be a gizike is...)
Nem jobb a jelszavas login, nem is bizotnságosabb, de semmivel sem rosszabb a fentiek szerint, mint a kulcs alapú auth.

kötöjelkötöjel
Kiszámít mér és berakodás idő -ból -a Pókháló

igy van, csakhogy

1. amennyi erovel valaki meg tud szerezni egy ssh kulcsot, ugyanannyi erovel meg tud szerezni egy ssh jelszot is.
2. a kulcs alapu bejelentkezesnel nincs mas tamadasi mod (kripto tamadas tudomasunk szerint nincs), mig a jelszo alapunal lehet ugye probalkozni.

a fenti kettobol kovetkezik, hogy a ketfele hitelesitesi modszer akkor lenne ekvivalens, ha a jelszavakban levo entropia legalabb akkora lenne, mint a kulcsokban levo. megeszem a kalapom, ha neked vagy barkinek ilyen kaliberu jelszava van ;).

Ez így van, a "jelszó"-ról általában beszéltem. A munkaszerződésbe bele lehet foglalni, de b...hatom, ha a baj már megtörtént, hogy utólag deresre lehet húzni a dolgozót, inkább olyan jelszavakat adok (ahol nem a felhasználó ad magának), amit jó eséllyel nem fog sárga cetlire felvésni.

Ahol meg a felhasználó adja magának a jelszót, ott a céges policy (ha van, egyébként meg best practice) alapján kell megkövetelni a bonyolultságot.

( dj | 2008. 08. 28., cs – 09:29 )

Igazán nem vagyok egy biztonságtechnikai szakértő, de két dolgot nem értek a hírrel kapcsolatban.
1; honnan szerzi meg az első kulcsot
2; honnan tudja, hogy az ssh szerver melyik porton üzemel?
Mert ugye nem evidens a 22-n üzemeltetni egy ssh szervert.

( penztar v | 2008. 08. 28., cs – 10:06 )

Hello!

Nem hittem volna ,hogy ekkora vitát fogok gerjeszteni.No akkor csak röviden. Én nem mondtam semmilyen PermitRootLogin opció dolgot. Én csupán arról beszéltem ,hogy értelmes ember aki ssh-t használ nem jelentkezik be távolról root felhasználó névvel. Szerintem aki használ ssh-t annak ez alap dolog kellene hogy legyen.Én ezt azért írtam ,mert ha véletlenül ugye a normál felhasználó publikus kulcsát valamilyen úton módon meg tudják szerezni még akkor is csak normál felhasználóként tud bejelntkezni és akkor még mindig valahogy meg kell szerezni a privilégium emeléshez szükséges jelszót.Persze ha már valaki bent van akkor a kernel dolgainak hibája miatt lehet rendszergazda jogokat szerezni. Én úgy vagyok vele,hogy a biztonságot úgy próbáltam meg kialakítani ,hogy a sima felhasználóval se tudjanak belépni. Ezért használom a kulcs alapú azonosítást és a kötelező passphrase beírást minden egyes alkalommal és nincs ssh-agent.Szerintem ,ha már az authentikációt próbáljuk a lehető legszigórubban megkövetelni akkor sok próbálkozónak el lehet venni a kedvét a próbálkozástól. Aki meg nagyon be akar törni azt úgy sem lehet megállítani,mert ugye feltőrhetetlen rendszer nincs.Valamelyik nap nézegettem a logokat és nagyon sok próbálkozás van ssh belépésre root felhasználóval és egyéb általános pl. sales,staff és hasonló nevekkel.Egyébként nehezen tudom elképzelni ,hogy létezik olyan adminisztrátor aki úgy konfigurálja az ssh szerverét ,hogy sima jelszavas authentikációt használ.Ha van akkor azt nem biztos ,hogy ilyen titulussal kellene definálni. Én félig meddig azért talán biztonságban "próbálom" magam érezni ,mert ma még szerintem az 1024 bites rsa kóddal generált kulcsot tudomásom szerint nem könnyű megfejteni,bár mostanában a debian egyik karbantartója sokat "tett" érte ,hogy megjósolható legyen.
Remélem ,hogy most nem fogok megint túl nagy vitát generálni a hozzászólássommal.Ja és tudni kell nem vagyok sem adminisztrátor sem security expert csak egy olyan ember aki megpróbálta a lehető legtöbb információt begyűjteni akkor amikor elterveztem ,hogy ssh szervert fogok telepíteni.Nem akartam a gépemet hackerek átjáró házává tenni és zombi gépként sem nagyon akarom használni a gépet.

Üdv.

Én nem vagyok normális ember valószínűleg, mert root-ként távolról is meg helyileg is belépek... (?)
Nem azért, mert buta vagyok, vagy tudatlan, hanem mert végiggondoltam és nem feltétlenül bízok MÁSOK átgondolatlan dogmáiban.

Ha az a kérdés biztonságban vagyok-e, ha kispista névvel jelentkezek be és onnan su vagy sudo: nem. Ha kispista-ként valaki be tud lépni (bármi oka is legyen ennek) onnantól semmiféle "exploit" nem kell hogy a root jelszavamat megszerezze, ha legközelebb belépek és sudo vagy su, akkor már meg is van a root jelszó. Viszont ad egyfajta hamis biztonságérzetet, esetleg gyengébb jelszót teszünk kispistának, mert ugye az úgysem root, és úgyis mindig kétszer kell bejelentkeznem, ami egyébként macerás.
Ennél hasznosabb a root átnevezése.

Ha nem célzott a támadás, akkor a legfontosabb, hogy ne essünk bele abba a tömegbe, amit támadnak: most én kérdezem (kezek a szívekre):
melyik baromnak van a 22-es porton az SSH szervere?!? (bocs Trey, ha Neked is van ott :-) )
Alap; első amit meg KELL változtatni.
Ezzel a nem célzott támadások alig kicsit kevesebb, mint 100%-a kilőve. És ugyebár ezek vannak messze messze többségben.

Ha meg célzott a támadás, és tényleg nagyon fontos valakinek a 100Giga mp3-ad, akkor tökmind1, hogy egy vagy két jelszót kell megszerezni. Hmmm.... nem akarok ötleteket adni, illetve nem adok, de annyit írok, hogy ilyen esetekre mondjuk 3 különböző de egyben hasonló dolgot írtam volna.

Ha valakinek tényleg _kell_ a biztonság, akkor SSH_port_randomizáció + erős_jelszó + esetleg_PermitRootLogin(persze akkor már minek).

Jó elismerem, hogy bizonyos esetekben mindent meg kell tenni a biztonság érdekében, legyen az akár 1 plusz lépés a root-ként való belépésben. De kijelenteni, hogy "értelmes ember..." vagy hogy "alap" mérlegelés nélkül az baromság (ráadásul SOKKAL fontosabb dolgok vannak ennél). Minden valamiféle kompromisszum kérdése: több jelszó (ugyebár gépenként kétszer több jelszó, mondjuk 10 helyett 20) azt eredményezi, hogy valamit kell kezdeni a sok jelszóval, mert kétszer több jelszót nem kétszer, hanem mondjuk 4 vagy 8szor nehezebb megjegyezni. Leírod? Papírra? Telefonba?? GÉPEDBE????

"Ha kispista-ként valaki be tud lépni (bármi oka is legyen ennek) onnantól semmiféle "exploit" nem kell hogy a root jelszavamat megszerezze, ha legközelebb belépek és sudo vagy su, akkor már meg is van a root jelszó. Viszont ad egyfajta hamis biztonságérzetet, esetleg gyengébb jelszót teszünk kispistának, mert ugye az úgysem root, és úgyis mindig kétszer kell bejelentkeznem, ami egyébként macerás."

Itt nem teljesen értem, hogy mire gondolsz. Kifejtenéd?

"melyik baromnak van a 22-es porton az SSH szervere?!? (bocs Trey, ha Neked is van ott :-) )

Ott van a HUP-on, de majd szólj, ha sikerült rá csatlakozni ;)

"Alap; első amit meg KELL változtatni."

Ez csak lassítja a támadást. Ettől még kitalálható, hogy hol van az sshd. Sokkal jobbnak találom azt a megoldást, hogy az sshd portjára csak bizonyos IP-kről lehet csatlakozni. Mi ezt alkalmazzuk.

--
trey @ gépház

22-es port
"Ott van a HUP-on, de majd szólj, ha sikerült rá csatlakozni ;)"
"Ez csak lassítja a támadást. Ettől még kitalálható, hogy hol van az sshd. "

Én a _nem_célzott_támadások_ esetére írtam a 22es portos dolgot. Persze ha nem ott van ki lehet találni, no problemo, de ha van egy friss sshd exploit akkor a botszerverek nem céltalanul lődöznek randomIP:randomPort-ra, hanem randomIP:22-re (mert ugyebár ez a hatékony :-) kb 60000szer hatékonyabb :-) ). Azt pedig Te sem állíthatod, hogy a Nálad levő ssh szerver _biztosan_ bug-mentes. (Tehát nyilván nem én leszek, aki majd szól, ha sikerült csatlakozni.)

IP cím korlátozás: természetesen ha lehet használni kell is, én pont azt írtam, hogy a "nem lépünk be root-ként távolról, hanem sudo... alap" helyett vannak SOKKAL jobb megoldások.
Mellesleg ezt (kispista/su|sudo) sem tartom butaságnak, csak azt, hogy ebben merül ki az biztonsági "alap". Használja, aki szereti.
Másrészt nem kérdezősködök, hogy netfilterrel van-e a korlátozás, mert ne mondd el:-), szerintem a biztonság ott kezdődik, hogy nem pofázzuk ki az értékes infokat másoknak, nem? :-)

kispista: ha kispistán keresztül mész be és su, ugye nem nézed végig minden alkalommal pl a bash.rc bash.profile-t? Ha be tudok lépni én is átírhatom, és a su vagy sudo helyett vmi más futhat.
Nem tudom ezt nem értette-e, vagy hogy miért adhat hamis biztonságérzetet. (oda gondolj bele egy {ironikus} ... {/ironikus} tag-et)

Üdv

"Azt pedig Te sem állíthatod, hogy a Nálad levő ssh szerver _biztosan_ bug-mentes."

Nem állítom, de mivel a packet filter védi, előbb azon kellene áthámoznod magad. :)

"Mellesleg ezt (kispista/su|sudo) sem tartom butaságnak, csak azt, hogy ebben merül ki az biztonsági "alap". Használja, aki szereti."

Én szeretem, használom :) A legtöbb esetben így: sshd portra szűrés, kulcs auth, regular user, majd onnan su.

Paranoiásabb esetben: ssh kulccsal management gép, majd onnan tovább a mögötte levő éles gépre ssh. Mivel nem tudod, hogy melyik a management gép, elég nehéz kitalálni, hogy melyiket kell megtörni, ha onnan tovább akarsz menni. De ha bejutottál a menedzsment gépre, akkor még mindig csak ott tartasz, mintha az éles gép kinn lenne a neten magában. Azt is meg kell törni.

"Másrészt nem kérdezősködök, hogy netfilterrel van-e a korlátozás, mert ne mondd el:-)"

Nem tudom elmondani, mert pontosan én sem tudom. A HUP esetében nem én üzemeltetem ezt a részt, de tippelem, hogy nem netfilter.

"szerintem a biztonság ott kezdődik, hogy nem pofázzuk ki az értékes infokat másoknak, nem? :-)"

Nem hiszem, hogy a titkolózáson alapuló biztonság az üdvözítő. Hogy ki miben hisz, az vallási kérdés.

"ha kispistán keresztül mész be és su, ugye nem nézed végig minden alkalommal pl a bash.rc bash.profile-t? Ha be tudok lépni én is átírhatom, és a su vagy sudo helyett vmi más futhat."

Ez nekem még mindig zavaros. Konkrét példát tudnál mondani?

--
trey @ gépház

Ha bejut. Ha bejut próbálkozhat local root exploittal is. Éppen ezért nekem az a véleményem, hogy az itt kialakult vita arról, hogy engedélyezem a root-ot vagy sem kb. az ötödik rangú kérdés (kb. olyan, hogy ki melyik kezével törli ki). Nem az a lényeg, hogy mivel, meg hogyan, hanem az, hogy úgy meg kell védeni az éles gépet, hogy azt könnyen ne érhessék el közvetlenül. Erre a használható megoldások azok, amit feljebb felsoroltam:

- menedzsment gépet használni, amiről tovább lehet menni az ő szemszögéből már helyi hálón levő éles gépre
- szűrni egyáltalán, hogy a menedzsment gép sshd portjára honnan lehet csatlakozni
- jó őrzött kulcsot használni
- stb.

Ha ilyen feltételek adottak, akkor nyugodtan neki lehet állni keresni gyengébb láncszemet, mert ezen a scriptek elvéreznek, a célzott támadások meg nem ezt fogják megpróbálni.

pl. ha én akarnám feltörni a HUP-ot, akkor biztos nem ezen az útvonalon próbálkoznék, hanem a csodás PHP/Apache vonalon :) Sokkal nagyobb az esély a sikerre :))

--
trey @ gépház

"Szerintem arra, gondol hogy mivel az..."
Így van. Még van más hasonló a tarsolyban de ez épp elég.

Figyelmetekbe ajánlom, hogy én kifejezetten arra írtam ezeket, hogy "root-tal ne léphessünk be távolról, mert az alap". Ez tök elhanyagolható a többi ténylegesen fontos lépéssel szemben.
Ugyebár arra írtam, hogy ha bejut akkor még local exploit sem kell, igaz várni kell 1-2 órát :-) (ha nincs local exploit).
A kettő közt az lenne a különbség, hogy ha bejut, akkor biztonságosabb, ha kispista-ként jot be és nem root-ként, de lényegtelen a különbség, ha már bejutott.

Másrészt Trey IP szűrésen keresztül bejutni:
A fölötte levő hír: "Az Internet legnagyobb biztonsági rése"
Ha nem esett volna le vkinek, ez épp ezt teszi hatástalanná.
Aztán ha van egy jó haver valamelyik útvonalban is kedvező szolgáltatónál IP szűrés kipipálható.

De szerintem nem kéne folytatni a vitát, mert nem vitázunk, épp Te is azt írod, hogy a védelemben sok sokkal értékesebb megoldás van mint a nem_privilegizált+su.