LDAP auth - mi van, ha törik a klienst?

Debian GNU/Linux

Kérdés: Ha egy LDAP auth-os linux klinesnek megszerzi valaki a root jelszavát, akkor el tudja olvasni az /etc/ldap.secret fájlt, és innetől elvileg meg tudja változtatni az összes ldap-felhasználó jelszavát.

1) Hogy lehet ezt kivédeni?
2) Windows hogyan csinálja ugyanezt a domain jelszavak vs localadmin tekintetében.

  • 1628 megtekintés

( misu | 2010. 02. 01., h – 12:08 )

Szia!

Hát ha úgy csináltad, hogy a rootdn-nel csatlakozol kliensként az öreg hiba.
Nálam egy readonly jogosultságokkal rendelkező user olvas auth-nál. Természetesen ldaps -en keresztül.

igen, de akkor pw-t nem tud a juzer cserélni
persze nem rootdn-nel akarok csatlakozni, odáig már rájöttem, hogy majd csinálok egy korlátozottab usert, de most meg arra jöttem rá, hogy még az is túl sok.

szerk:
bocs, mégiscsak tud - tulajdonképp leírtad a megoldást, csk nem hittem el, annyira triviális volt - köszönöm.

( vl v | 2010. 02. 01., h – 12:15 )

1) Hogy lehet ezt kivédeni?

nem írod bele a directory admin jelszavát semmilyen fájlba.
mit vesztesz ezzel:

- a root nem fogja tudni más userek adatait buzerálni, ezt más módon kell megcsinálni (pl. egy webes felületen)
- a pw váltást az ldap szerverre kell bízni (exop), vagy teljesen off-line kell csinálni (pl. egy webes felületen)
- a pw ellenőrzéshez cleartext jelszó kell a bejelentkezésnél, tehát nem fog menni pl. a POP3 CRAM, meg a PPP CHAP authentikáció, és persze nem elég az nss_ldap, kell pam_ldap is

mit nem tudsz megoldani: hogy a betörö a bármely user által megnézhető adatokhoz ne tudjon hozzáférni (gyakorlatilag a jelszó nélküli /etc/passwd tartalomnak megfelelő adatokat az ldapból meg kell engedni kiolvasni)

"vagy teljesen off-line kell csinálni (pl. egy webes felületen)"

sajna offline nem nyerős.

"- a pw váltást az ldap szerverre kell bízni (exop),"
erről tudz még mondani valamit? mi történik ilyenkor?
mármint: ilyenkor nem írási joggal kapcsolódik a kliens az LDAP-hoz? (rákerestem gyorsan, de mindenütt csak annyit találok, hogy ezt írd be, de a miért az nincs...)

ilyenkor az ldap szerverhez a kliens a user saját accountjával csatlakozik, és egy speciális "password change" műveletet hajt végre, aminek az eredményét az ldap szerver fogja eltárolni a "jelszó" mezőben.

de azt is lehet, hogy a usereknek írás jogot adunk a saját jelszó mezőjükre, és azt egy "modify" művelettel változtatják meg.

mindegyik verzió lényege, hogy a user saját accounttal authentikálja magát a szervernél (ehhez cleartext jelszót kell tudni produkálnia), és alapvetően nem szükséges, hogy a password mezőt láthassa, azt ugyanis csak az ldap szerver használja a jelszó ellenőrzéséhez.

Részint köszönöm az inspiratív segítséget, részint hadd kérdezzek:

Nos, tettem egy ldap szervert (http://ubuntuforums.org/showthread.php?p=8154148 és http://ubuntuforums.org/showthread.php?t=1313472 alapján, konkértan ez utóbbival kezdve, majd a másikkal folytatva a people csoporttal és a john doe userrel), mint eddig is.

Majd kiadtam az apt-get isntall libpam-ldap parancsit (ami egy pár egyebet is magával ránt).

Ezúttal azt válaszoltam, hogy nem szeretnék a rootdn-nel kapcsolódni az ldap-hoz (így persze nem is tette el a
jelszót), majd az nsswitch.conf-ban elhelyeztem kézzel az ldap bejegyzéseket:
passwd: ldap compat
group: ldap compat
shadow: ldap compat

és az ldap-os user be is jelentkezik és tud jelszót cserélni.

Amiért írom ezt a bejegyzést: NEM állítottam be az exop paramétert, az /etc/ldap.conf-ban továbbra is ki van kommentezve.

Erre gondoltál, amikor ezt írod: "de azt is lehet, hogy a usereknek írás jogot adunk a saját jelszó mezőjükre, és azt egy "modify" művelettel változtatják meg"?

Érdemes engedélyezni ekkor valamiért az exop-ot? Ha igen, elég, ha kiveszem a kommentet előle, vagy a szerveren is kell tennem valamit? - nagyon sokat gugliztam, de sehol nem találok róla félmondatoknál többet.

szerintem nagyon gyorsan állítsd át az nsswitch bejegyzést

files ldap

vagy

compat ldap

sorrendre, különben gondjaid lehetnek nem működő ldap szerver mellett (pl. ha nem bootol be egészen a géped) a rootként történő belépéssel.

az exop azért jó, mert az ldap szerver dönti el, hogy mit ír be a jelszó mezőbe (milyen kódolást használ), míg ha megengedem a usernek, hogy átírja a mezőt (ami az alternatíva), akkor oda bármit be tud írni - elméletben, nyilván a gyakorlatban nagyon kevesen használják az ldapmodify parancsot ilyen céllal.

egyébként simán jó lehet ez így is, ahogy van, ha működik, nem biztos, hogy érdemes bántani :)

Az a gond egyebkent, hogy a debian alapu rendszerek a libpam-ldap/libnss-ldap (nemtom meik) felkonfiguralasakor rakerdeznek a bind user jelszavara, es ezt asszem cleartext taroljak le. Igaz, hogy ezzel csak egy korlatozottabb user jogaihoz jutnak, adott esetben azonban a tamadonak ez is eleg lehet...

En elgondolkodnek egy Kerberos authentikacion. Ott senki nem tarol sehol jelszot...
-- 


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

( Zsugabubus | 2010. 02. 01., h – 13:45 )

A Windows úgy csinálja, hogy minden gépnek saját accountja van az AD-hez, ezt meg lehet itt is csinálni, ha van hozzá türelmed...
Amúgy ahogy a többiek is mondták, jelszóváltoztatáshoz nem kell a rootdn-t használni.

a windowsnak van egy extra tudománya, amit nem csináltak meg unixon: a rendszer indulásakor úgy megmarkolja a registry-t tartalmazó fájlokat, hogy ahhoz még a rendszergazda sem fér hozzá, csak az os. és ebben a fájlban tartja a gép a domain passwordjét, így ehhez - ha nem hackeled meg az os-t, vagy nem bootolsz máshonnan - gyakorlatilag nem férsz hozzá még adminként sem.

"extra tudomány", "megmarkolja a registry-t"

És a rendszergazda az hogy írja akkor a registry-t?
És egy program a településkor hogy módosítja a registry-t?

Vagy ez is olyan kőkemény, mint az elkülönítve futtatott Explorer 8? Hogy egy normál user által meglátogatott rosszindulatú oldal használhatatlanná teszi a gépet?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

És a rendszergazda az hogy írja akkor a registry-t?
És egy program a településkor hogy módosítja a registry-t?

az os által biztosított api-n keresztül, ami kurvára nem enged meg mindent a rendszergazdának. vannak olyan registry kulcsok, amiket még az admin sem tud írni/olvasni, csak az os.

std unixon nincs olyan, hogy az uid=0 felhasználó valamely fájlrendszer valamelyik fájlját ne tudná bármikor írásra/olvasásra megnyitni. persze lehet játszani mindenféle grsecurityval és haverjaival, de az már más tészta.

Na igen, ezt kellene vegre a kernelbe implementalni, hogy lehessen olyant csinalni, amit az uid=0 _nem_ tud irni (vagy definialni muveleteket, amit a root nem tehet meg). Nem azert, mert idotabaratta kell tenni a linuxot, hanem mert a virusok elso korben a root access eleresere tornek, ha viszont ezzel se tud megtenni bizonyos dolgokat, akkor biztonsagosabb lehetne a rendszer. Persze, most jonnek majd a trollok, es jol megmondjak, hogy ne jartkaljak warez oldalakon... elore varom a LOL-full commenteket.
-- 


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

erre vannak non-std megoldások, pl. a grsecurity-t nagyon sokan használják. igaz, ahhoz, hogy jól beállítsd, hogy használni is tudjad, de a nemkívánatos látogatók fennakadjanak, ahhoz nagyon sokat kell vele pepecselni.

egyébként a windows-os megoldás is messze van a tökéletestől: az admin berakhat drivereket, a driverek kb. a linuxos kernel modulnak felelnek meg, ők pedig bármit csinálhatnak az os-en belül. linuxon is csak úgy védelem a grsecurity, ha a kernel és a moduljai érinthetetlenek a rendszerből, és bootolás után modult sem lehet többet betölteni akárhonnan.

Egyik sem tervezeskor kerult bele, utolagosan van raganyolva, raadasul nincs is default engedve egyik sem. Plusz a userspace support is kulso user toolokkal/libekkel van megoldva, nem a platform resze. Raadasul mindegyiket bonyolult kezelni.
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
[/code]