NFS megosztáson keresztül szerveroldali hack?

Fórumok

Sziasztok!
Hallott már valaki ilyesmiről?
Nfs megosztásról egy szerver service újra inditása lehetséges-e?
Tapogatozok a témában -> default mount , dev, nodev és a haverjai, biztonsági rések?
Jav.:
Legfontosabb, hogyan lehet kivédeni ha létezik ilyen??

Hozzászólások

Javaslom, előbb konkrét kérdésed legyen.
Mint ahogy itt már előttem is tippeltek, hogy mire gondolhattál.

Ha van konkrét kérdésed, abban tudunk segíteni.

A gondolatolvasás... Az a javasasszony melletti szobában lesz! ;)

De hogy a konkret kerdesedre valaszoljak:
Legyen az nfs megosztasom a /mnt ala felmountolva.
majd lefuttatom a kovetkezo parancsokat:

printf '#!/bin/bash\nservice postfix restart\n' >/mnt/szolgaltatasujrainditasa.sh
chmod +x /mnt/szolgaltatasujrainditasa.sh
/mnt/szolgaltatasujrainditasa.sh

voila.

Mindent lehet NFS-rol, amit csak akarsz / megengedsz.
Mit akarsz kivedeni? Vagy esetleg a masik oldal: mit akarsz elerhetove tenni?
Melyik oldalrol?

Szerver oldalra elso korben, ha linux, akkor man 5 exports.
Kliens oldalra meg: man 8 mount, man 8 mount.nfs, man 5 fstab

alap NFS-serverről tárterület felmountolva egy kliensre például.
Kliensen a /mnt/nfsshare mappa alá default beállitásokkal mountolva.(rw,siud,dev,exec,auto,nouser,async)
Lehet-e valahogyan a kliensről, magán az NFS-serveren lévő egyébb szolgáltatást, például apachét újrainditani?

Pere László : rendszereküzemeltetése I 79.old. dev:
Van benne egy részlet. "Ha megengednénk a felhasználóknak a hozott eszközkezelő használataát, a megfelelően előkészitett adathordodzóval korlátlan hatalmat szerezhetnek a rendszer felett."

De melyik felett? a kliens felett, vagy a szerver felett? ezt már nem írja.
Logikus, hogy a kliens felett, de hátha, még se jól gondolom.
Egyébként itt a valami ilyesmikre kell gondoljak:
mknod -m 622 /mnt/nfsshare/console c 5 1 ???

Lehet-e valahogyan a kliensről, magán az NFS-serveren lévő szolgáltatást, például újrainditani?

Ez kb. a dos definíciója.
Hogy Bödőcsösen fogalmazzak: Ha ilyen lehetőség lenne, már nem lenne!
Itt maximum csak hitvitákra lehet menni, hogy ki melyik nfs implementációban mennyire bízik meg.

Ez alapján én azt mondanám, hogy illumos > BSD > linux. De ez a saját preferenciám.
Őszintén szólva BSD-s nfs szervert még nem üzemeltettem, itt csak vakon megbízom olyanok tribal-knowledgeében, mint pl. bra.
De ha Zahy olvassa a thread-et, majd legfeljebb beír egy másik sorrendet! ;-)

Pere László : *
Ugyan nem vagyok a könyvégetés híve... de más céllal minek veszel a kezedbe ilyeneket?

A fenti mknod parancs lefuttatásához a kliens oldalon is kell root jog.

Ugyan nem gyakori use-case, de a nagy kérdés, amit először tisztázz magadban:
Szeretnél kiajánlani nfs share-t olyan kliensek számára, ahol a kliensek fölötti adminisztráció nem a te kezedben van?
Volt már ilyenre példa. Még Szegeden történt, hogy valami hp/ms/akármi aio12000 vagy fene tudja milyen storage volt az nfs szerver, ahonnan "sok" helyet ki tudtak nfs-en exportálni, hogy a linuxokon legyen extra tárhelyünk. Na akkoriban kezdtem el bevezetni azt a termékkategóriát, hogy öntsük le gázolajjal, és gyújtsuk fel a g...be, mert ennyire sz..t a világ még nem látott.
Itt mondjuk én ültem a "kliens oldal" adminisztrációja felett, és minden apró vacakhoz, úgy kellett a windowsos adminisztrációnak súgnom, hogy még miket kattogtasson már ahhoz a rohadás share-hez, mert mindenképp nfsv4 gondolkodásmódot akart erőltetni. Nem is tudom nfsv3 engedett volt-e.
De volt akkora kupleráj az egész helyen, hogy ahány szerver annyi különbüző uid/login készlet. Max. én voltam olyan helyzetben, hogy 8 szerverből 5-ön én voltam az 1000-es uid, mindenütt másutt meg random... Meg a többiek random előfordultak szervereken, random 1000+-os uiddel.

Szóval: Az első kérdés: Mi a "célközönség", akinek az export lessz? Azok is a te adminisztrációd alatt állnak?
Esetleg van egy közös címtár-jellegű szolgáltatásod az uid-ek szinkronban tartására? (ldap, nis, whatever)

Ha nem az első kérdésre a válaszod, akkor a második kérdés, amit fel akarsz tenni: Biztos?
A harmadik: Jól meggondoltad?
A negyedik: Tudsz találni olyat, aki aláír neked egy papírt, a vezetői hierarchiában feletted van, és ő viszi el a balhét miatta?
Az ötödik kérdés: Biztos vagy benne, hogy elviszi helyetted, vagy olyan típusú vezető, aki... bár erre figyelmeztetted előre, de úgyis el fog taposni, amikor ebből probléma lesz?

Na, ha megszületett a döntés, hogy nfs share-t kell biztosíts olyan kliensek számára, amik fölött nincs kontrollod, még mindig lehet "okosan" szervezni:
A storage-ra, még ha létezik is a user, még akkor is, ha akár csak valami ldap/nis miatt virtuálisan, hogy nfs4-ileg is jó legyél...
Nem kell, hogy shell-jül legyen, vagy ténylegesen más is be tudjon lépni az adminisztrátorokon kívül.
Ha mégis be kell engedj embert a storage-ra, ugyanabba a zónába / jail-be / lxc-be, etwas, ahonnan közvetlenül is látszanak az exportjaid...
Tudod helyben azt csinálni, hogy az exportok valamilyen /exports könyvtár alá teszed, és a /exports meg root.root tulajdona, és 0700 access van rá.
Még, hogy védd a segged: az exportokat célszerűen, ha több különböző célcsoportnak kell ugyanarról a storage-ról kiajánlj, értelmes dolog külön FS-re tenni.
Ezt már helyben megoldod amivel akarod: zfs, lvm, ami épp az adott rendszeren elérhető számodra.
Külön-külön mountolva meg már lehet noexec, nodev, no-bármit megadni az exportálandó filerendszerek fstab entry-jeire / zfs propertyjeire / helyettesítsd be az ideillő megoldást

De attól függően, hogy mi a cél az exporttal, még akár az exportnál is lehet azt mondani, hogy all-squash, hogy linuxos exports-osan fogalmazzak! ;-)

Visszatérve az optimális csapásirányra, miszerint csak olyan nfs klienseid vannak, aminek az adminisztrációja is a te hatásköröd:
Biztos vagy benne, hogy nem tudja más illetéktelen megszemélyesíteni a te egyik kliensedet?
Teljesen biztos?
Milyen lépéseket tettél ennek érdekében?
Innetől már picit filozófiaibb, de ha nem k...od nagyon szét a dolgot, akkor lehet ezt értelmesen:
nfs szerver: storage szerver.
nfs kliensek: saját fleet, saját adminisztráció alatt
export pedig olyan alhálózaton keresztül megy, amibe csak a network adminisztrátorok közreműködésével tud gép bejutni.
Pl. kifejezetten szerverek közti vlan, amibe más vlan-ból forgalom be-route-olva nincs!
Persze erre érdemes az exports-nál is figyelni, nehogy közben az nfs-szervered másik interfészén keresztül meg jöjjön valami huncutság...
Ha nem k...ta meg szet azota senki, akkor... mar halvanyak az emlekeim, de talan a 100-as vlan-t nezd meg a munkahelyeden! ;-)
Pont ez a célja. Még az mtu is 9000-re van rajta állítva minden gépen, hogy hatékonyabb tudjon lenni a kommunikáció az nfs kliensek és szerverek közt.

A fenti mknod-os példa meg akkor gáz, ha...
Az nfs szerverre van loginja olyannak, akinek nem kellene. Tfh. 1005 az uid-ja a szerveren.
Fog vérpistike egy ubuntu livecd-t.
Bebootolja egy munkaállomáson a hálózatodban.
Onnantól kezdve olyan IP-t állít be magának amit szeretne.
Ha a hálózatodon nem lenne semmi védelem, akkor be tudhatna állítani olyan IP-t is, amit az nfs szerver, mint megbízható kliens azonosít be, és a kiajánlások meg no-root-squash-al, meg minden rákfenével mennek.
Na akkor jön egy mknod. De mondjuk console helyett inkább a kmem-et személyesíteném meg, és még a fájlnévben is valami jó félrevezetőt adnék neki! ;-)
Majd egy chown 1005.0-ra. chmod 600-ra.
Bemegy a szerverre. Előkotorja a devnode-ját. És a futó rendszer memóriájában bárhol, bármit, tetszés szerint átírhat.
Akinek van ilyenre való malicsusza... az... onnantól bármit megtehet. Pl. az aktuálisan futó shelled jogosultságain üt csak át pár bitet, és euid 0 lessz 1005 helyett.
Innentől a fantáziádra bízom a sztorit.

Nem igazán tudnám, megválaszolni ezeket a kérdéseket.
A legnagyobb probléma a mennyiség, és hogy nem vagyok 100% tisztába egy megosztás felhasználásában sem.
Példa, ez azért van ott mert ez egy honlap Docrootja, de mivel statikus site, és nem töltenek feloda többé semmit, lehetne ro-ban is. Vagy a 110-dik megosztás azért van mert az egy melos ftp home-ja.
102 vlan on találkoztam már nfs share-rel. Szoval még azt se tudnám meg mondani, hoyg tényleg az csatol föl bármit is akinek szabad.
ÉS van egy szerveren tényleg olyan nfs share ami user home is egyben(azaz bejelentkezhet a szerverre).
Lefuttatok majd egy find . -type b és type c -t. Ha jól értettelek erre kell keresni.

ÉS van egy szerveren tényleg olyan nfs share ami user home is egyben(azaz bejelentkezhet a szerverre).

Azt ugye vágod, hogy ha a user home ki van ajánlva nfs-en egy pc-nek, akkor aki azon a pc-n root, az a user home-ok közül bármelyik felhasználó nevében be fog tudni jelentkezni a szerverre? Sőt, nemcsak ezt fogja tudni megtenni, hanem gyakorlatilag bármit azon a fájlrendszeren, ha no_root_squash-t használtál az exportnál. Ha ezen felül még a nodev vagy a nosuid flageket is elfelejted a mountnál a szerveren használni, akkor az illető nemcsak bármit megtehet a fájlrendszeren, hanem akkor lesz root a szerveren, amikor csak akar.
Továbbá ha más kliensek/szerverek is mountolják ezt az nfs share-t user home-nak, akkor az illető azokkal a gépekkel is ugyanezt meg tudja tenni.