OpenSSH alapértelmezett biztonsági beállításainak változása a DragonFly BSD-ben

DragonFly BSD

Egy friss commit szerint több ponton változik a DragonFly BSD OpenSSH-jának alapértelmezett beállítása.

  • a publikus kulcson keresztüli root login engedélyezésre került (eddig a root login SSH-n keresztül egyáltalán nem volt engedélyezve)
  • plaintext jelszóval ezentúl nem lehet bejelentkezni (eddig !root felhasználó bejelentkezhetett plaintext jelszóval)

A változások csak a friss telepítéseket érintik.

( hrgy84 | 2009. 11. 23., h – 15:25 )

Ezt linuxra is!
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Személy szerint nem értettem soha ezt a root-ként ne tudjunk belépni a szerverre mizériát.
Ha megszerzik egy olyan embernek a jelszavát aki wheel, vagy tud sudo-zni, már ugyanúgy szereztek root jogot.
No meg ott vannak a local exploitok is. Ahhoz sem kell root-ként belépni ssh-n.

Kulcso hitelesítés meg anno debian ssl bug óta, meg a kulcsos hitelesítés szinten felveti a kérdést, hogy, ha esetleg egy hasonló okosság megint születik, tényleg biztonságosabb 32000 kulcs az emberek által kitalált ténylegesen biztonságos jelszó ellenében?

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

"Személy szerint nem értettem soha ezt a root-ként ne tudjunk belépni a szerverre mizériát."

Ez audit miatt celszeru (vagytok root-ok 6-an a szerverre, es akkor nem azt latod a logban, hogy a root belepett, es osszedontotte a szervert, hanem hogy pistike belepett, suzott, majd osszedontotte a szervert, igy konnyebb rakuldeni pistikere a lancfureszes kulonitmenyt).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ok, igaz. Alapvetoen ugy gondolkodom, hogy vagy te, mint root, a tobbiek meg szepen sudoznak.
(valakinek vegulis kell igazi rootnak lennie aki felrakta a szervert, aztan ha latszik logbol, hogy o lepett be, ugyis eltunteti a logokbol :), kiveve ha a logszerver tulaja szinten kedves ember es nem enged root hozzaferest a szerverhez magan kivul meg sudo-val, es su-val sem.)

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Az (Open)SSH-nál nem is ez a formátum, de hogy tanulj is valamit:
LogLevel DEBUG

Ezzel megjelenik a logban, hogy kinek a kulcsával történt belépés. Azt evidenciának veszem, hogy ha a rootot többen használják, mindegyiknek külön kulcsa van...

suckIT szopás minden nap! Hogyan csináljunk kevesebb, mint 500 ezerből 115 milliót?

- a root egy default user, a 'pistike' vagy a 'www17admin' nem (legalabbis vegig kell probalgatni)
- rootnal rogton teljes privilegiumod van, fapad usernel meg turkalni kell a history-ban, hogy hogyan szokott emelt jogokhoz jutni ;-)
- vannak helyek, ahol ezt policy is tiltja (ld eax megjegyzeset)

Meg ugy egyaltalan, nem jo ;-)

-Igen a root tenyleg igazi user, minden rendszeren van - ha csak at nem nevezed pl.
A jelszavat attol meg nem biztos, hogy kitalalod. Ha kulcsot hasznalsz teny, hogy piciket tobb lehetoseget kell kiprobalnod, de ugye mint irtam openssl bugnal piciket visszaesett a lehetosegek szama :).
-A pistike, www17admin, (vagy ha mar lud legyen kover: sales, accounting) felhasznalok lehetseges, hogy leteznek. Ha azoknak konnyen kitalaltad a jelszavat, akkor nem biztos, hogy history-t kell turnod, lehet mint irtam egy exploitot felrakni, vagy ha mondjuk jogosultsagok vannak szarul beallitva bizonyos file-okra felulirsz 1-2 gyakoribbat a sajat binarisaiddal, amit valoszinuleg root-kent is lefog futtatni a delikvens, vagy szepen fogod es szepen atallitod a usernek a PATH valtozojat. A binarist szinten onnan inditsa. Bar lehet, hogy bash_history-ban turkalva is lesz valami erdkes :).
-Egy olyan policy ami az esetek 99%-ban ertelmetlen onnantol kezdve, hogy bela kap shell-t, es jelszonak beallithatja a bela-t (vagy sales/sales).

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Sohasem értettem, minek a usereknek shell.
A /bin/false miért nem jó? Minden szükséges szolgáltatás elmegy vele.
Nálam rajtam kívül mindenki /bin/false, pedig rendszer usereket használók sok helyen. SMB/MTA/PRINT/SQL így is megy. Ftp-t/ssh-t meg felejtsék el, az elég nekem. :)

Amiatt, mert olyan userekről beszéltünk akik adminisztrálják is a rendzsert, vagy valami munkájukhoz kell shell?
Amúgy igen, /bin/false a legtöbb usernek, ha user-t kell csinálni akinek nem kell shell, ez alap azt hiszem.

ja elfelejtettem:

DenyUsers,AllowUsers direktivakat is erdemes hasznalni.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Errm... ez attol fugg. Kulcsos authnal nem kotelezo, hogy a pam is tudjon a userrol, ezt tapasztalatbol mondom. Eleg ha NSS szinten le tudja kerni a user adatokat, es igy kabe ennyi. Meg tisztan kulcsos authnal ki szokas kapcsolni a PAM-ot, az ugyanis kikapcsolhatatlanul engedelyezi a jelszavas belepest.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hat... nekem pont forditva volt mondjuk szuksegem ra, mert nem tudtam materializalni a PAM szamara a felhasznaloimat, de jo tudni.

Viszont... ha a pam_ssh -t session-nak rakod be, akkor ugyanugy jelszot fog kerni nem? Amennyire tudom, a auth modulok kerik a jelszot, az account modulok csekkoljak hogy jo vagy-e, a session pedig mar kozvetlen belepes elott futik le.
Nekem foleg az a lenyeg, hogy semmi modon ne lehessen jelszot megadni. Nem mintha nem total random jelszavak lennenek (amik kesobb el is vannak felejtve), de akkor se szeretnem, ha valami script kiddie elkezdene probalkozni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A pam_ssh, ha sessionek rakod be az kb. olyan mintha login scriptedbe inditanal egy ssh-agentet. ssh-agent azert jo, ha be ssh-zol valahova es onnan tovabb ssh-nal, akkor is hasznalhatod a gepeden leve kulcsot. (az ugrodeszka szerveren ssh agent forward be kell legyen kapcsolva). Szerintem auth resszel egyutt lehet ertelmes hasznalni.

http://linux.die.net/man/8/pam_unix
pam_unix -ot kell kivenni az authbol, ha nem szeretnel jelszot mivel az auth resz ellenorzi a jelszot. Az account egyebeket pl. hogy lejart -e a jelszavad.

"Scriptek" akkor is probalkoznak, 10-20 kiserletet tesz a legtobb automatikus script aztan megy tovabb, naponta 2-3 ilyen csoport is lehet. Ha csak kulcsos a bejelentkezes akkor is 10-20 at probalkoznak, de minek :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Na varj, most mar vegkepp elkeveredtem. Ha az auth reszbol kiveszem a pam_unix-ot, akkor ki fogja ellenorizni a kulcsot (mintha azt mondtad volna, hogy a kulcsos authot tiltsuk le a ssh szerverbe)? Egyaltalan, mit teszel a helyebe? Jo lenne ezt reszleteiben is latni, mert ez igy nekem nagyon zavaros.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Mondjatok egy példát erre kérlek. Köszi."

Pl. igy el lehet erni csak localhoston listenelo dolgokat, vagy konnyen-gyorsan el lehet fogyasztani a kernel filedeszkriptorokat.

"Még egy expolit sem fut így le."

Hat, melyik? :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"Nem értem a technikailag a "tunnelt" ebben az esetben. Ezt itt hogyan vitelezi ki?"

Legegyszerubben: 

ssh -2ND 1234 szerver.hu

"AllowUsers+többike(/bin/false) már okod ad a nyugott alváshoz? :)"

Nem, de legalabb a juzerek nem tudnak belepni ssh-val. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Igen megborulhat tole sok progi, de a normalisabbjanak nincsen vele gondja - persze kulonbozo install scriptek teny nem szeretik.
Ja cracklib azt hiszem alap, viszont pl. egy webhosting cegnel kevesbe kivitelezheto, mikor az egysugaru userecske nem bir megjegyezni semmilyen jelszot azon kivul ami a pin kodja 1234.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Ezen en mindig jokat mosolygok. Epp idoszeru lenne mar minden webhostingnak elfelejteni a jelszavas authentikaciot, amivel csak gond van, es elkezdeni vegre kulcsot hasznalni. Manapsag azert ez mar az egysegsugaru felhasznalok szamara sem kihivas, hiszen pl. Gnome alatt a Seahorse minden tovabbi nelkul general varazsloval kulcsot, KDE alatt is van valami ilyes dolog, Win ala meg a PuttyGen-nel egyszerubb app nem kell. Linux alatt automatikus a kulcsfelvetel a modern disztroknal, Windows alatt pedig a PageAnt-ot beloni talan csak fel perc muve (de egy par soros install script egy klikkentessel megoldja).

Hala istennek, mi mar csak mosolygunk a feltort FTP accokrol jovogeto hirekre.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Jo, akkor magyarazzuk el 200 ugyfelnek akik 90%-a azt sem tudja hogy mi az az utf-8, vagy mar egy ftp beallitasa is nehezere esik, neadjisten levelezest kellene beallitani outlook ala (meg csak nem is thunderbird, mert ott pl. az ikont se talalna meg az asztalon), hogy na gyerekek ezt kene hasznalni igy, es igy. Lerajzolhatod, leirhatod nekik, akkor sem fogjak tudni. Az meg, hogy KDE-t, vagy Gnome-t hasznalnanak?:) Warez windows xp maximum. Az, hogy 1-2 baromnak ellopjak a jelszavat meg magara vessen, en is hasznalok neha ftp-t, nekem meg nem nyultak le a jelszavamat (ok persze, ha kedves isp-m szeretne lenyulhatna), bar teny, hogy nem is olyan windows-t hasznalok, mikor azt hasznalok, ami tele van virusokkal.

Amugy azt nem szabad gondolni barmelyik userrol is, hogy ami nekunk 5 perc, es teljesen magatol ertetodo, sot meg egyszerubb, az szamukra is ilyen. O nekik vannak megszokott programjaik, megszokott ikonok, megszokott helyeken, ha csak az ikont odebb pakolod, mar nem talaljak meg. Mashogy gondolkodnak, mashoz ertenek - ha ertenek :).

Amugy idovel szerintem az ilyen kulcsos authentikacios dolgokat is elkezdik leszedni a gepekrol. FTP jelszavakat sem menet kozben sniffelik le.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Nalunk par kor email, es egyeb okossagok utan sem voltak kepesek a webmailhez uj url-t hasznalni. Meg fel ev utan is volt olyan aki telefonalt, hogy hat nem jon be semmi :).
Irigyellek, hogy ilyen felkeszult ugyfelekkel tudsz dolgozni, en valahogy soha nem kapom ki oket :).

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Nalunk szoktatas lesz. Eloszor is redirect (5 sec, addig oriasbetuk hirdetik az uj URL-t), majd szepen lassan lelojuk a regi cimet.

Igazabol ez nem felkeszultseg, hanem jo magyarazokeszseg es kenyszerites. A kollegam szerintem egy regenyrevalot tudna meselni... de sikerult.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Rackshee | 2009. 11. 23., h – 16:20 )

"a publikus kulcson keresztüli root login engedélyezésre került
Ez meg miért jó?

( blackberry | 2009. 11. 25., sze – 23:58 )

Ha a
- Port nem a defaultra,
- PermitRootLogin no-ra,
- PasswordAuthentication no-ra van állítva
- és az AllowUsers-ben csak én vagyok benne
akkor mennyire érezhetem magam biztonságban? Érdemes még valamit beállítanom?

A port nem default ertekre torteno allitasaval ovatosan, mert lehet hogy a vegen magadat szivatod meg. Szerintem egy ilyen modon lezart ssh mar eleg biztonsagos a 22-es porti futashoz is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.