ugrás a tartalomhoz

PHP SSH2 biztonsági kérdés

daniel18 · 2010. Dec. 19. (V), 22.27
Sziasztok!

Jó ideje foglalkozom webprogramozással, de tanácstalan vagyok egy PHP extension használatában ami a PHP-SSH2. Őszintén szólva nem örülök használatának, de sajnos jobb megoldást még nem találtam arra, hogy weben keresztül küldjek távoli szervergépre parancsot és az eredményt weben kitudjam íratni.

Próbálkoztam SSL-SOCKET programozással Perl-ben, de az sem bizonyult valami jónak mivel telneten crash-elni tudtam az egészet habár a szkript tökéletese működne ha ez a baki nem lenne. Megoldást ugyan nem találtam rá, de úgy érzem ez nem a tökéletes megoldás arra amit akarok.

Ha nem bánjátok lenne egy-két fontos kérdésem a PHP-SSH2 kapcsán.

- Mekkora biztonsági kockázat használata nagy látogatottságú rendszer esetén? Úgy hogy némely felhasználó használhatja is a PHP SSH2 Extension-t (természetesen az ő nevében root jogok nélkül és csak lekérdezésre, egyéni parancsot nem küldhet!).
- Előfordulhat, hogy a felhasználók egy időben többszörösen küldenek ki PHP SSH2-es utasítást. Ez nagyon megviseli a két szervert (local/remote) illetve nem lassul a le túlzottan a cucc? Az utasítás főként: felhaszn. létrehozás / törlés , szolg. letilt / felold, stb ...

A válaszokat előre is köszönöm.

Üdvözlettel,
Daniel
‹ PHP-HTML Webadmin profilpanel hiba HELP PHP URL megjelenítés! ›
 ■
1

Mi a feladat?

janoszen · 2010. Dec. 19. (V), 22.34
Mi a feladat, ami ezzel meg van valósítva? Annak függvényében lehet megmondani, hogy van-e biztonsági probléma.

Egyébként ha jól nézem, az OpenSSL-hez van hozzáforgatva, szóval van esély rá, hogy normálisan működik.
2

Fájl műveletek, Szolgáltatás inditás / leállítás / újraindítás

daniel18 · 2010. Dec. 19. (V), 22.52
Főként egy adott program vezérlése a cél.
cd /; ./dRx-Agent -user "test" -action "create";
A vezérlő szkript pedig az alábbi értékekkel tér vissza:
USER_CREATION_OK - Felhaszn. létrejött.
USER_IS_EXITS - A felhaszn. már létezik.
Ezt pedig egy PHP program értelmezi. Viszonylag egyszerű dologról van szó.

De ahogy nézem tökéletesen teljesíteni tudja a kéréseket hiba nélkül, ami jó.
5

Nem biztonságos

janoszen · 2010. Dec. 20. (H), 00.03
Hát figyelj... hogy is mondjam na. Készülj, kemény lesz, nem bántani szeretnék, de néhány dolgot muszáj tisztázni.

A megoldás amit választottál elég messzemenő hiányosságoktól szenved. Az ilyen SSH-s, shell execes megoldásokban annyi a benézhető biztonsági hiba, hogy szinte kizárt, hogy jól meg tudd írni. Ahhoz, hogy jól megírd, ismerni kéne a rendszert, azt pedig az elmondottak alapján nem ismered, mert akkor nem ilyen megoldást választanál.

Feltételezve, hogy van egy rendszergazdád, ülj le vele beszélgetni. Nagyon jó megoldások vannak az ilyen feladatokra, nem kell újra feltalálni a kereket.

Hogy mondjak konkrétumot is, Linux alatt van a PAM nevű csoda, amihez van pl MySQL és LDAP modul is, tehát az egész felhasználói adatbázisod lakhat MySQL-ben. A fájl manipulációra meg lehet pl FTP-t használni. Ehhez mindössze egy olyan FTP daemont kell föltelepíteni a gépre, amin be tudsz menni mondjuk mester jelszóval, belső hálón. PHP-ban nagyon frankó FTP modul van ilyen feladatokra.

Egy szóval, amire van kész megoldás, arra lehetőleg használd azt, ha pedig feltétlenül parancs-végrehajtást akarsz, akkor írj egy API funkciókat biztosító szoftvert a távoli gépre, ami validálja, hogy a hozzá beérkezett kérés érvényes-e, nincs-e benne csúnyaság, stb.

Nem tudom eleget hangsúlyozni, a jelek szerint rendszer szolgáltatást építesz rendszer ismeret nélkül. Ülj le valakivel, aki ért hozzá és tanulj, tanulj, tanulj.
6

Valóban így van.

daniel18 · 2010. Dec. 20. (H), 10.12
Először is köszönöm a gyors válaszokat. Másodszor valóban vannak érthetetlenségek még rendszerismeret téren.

Köszönöm az információkat.
9

Kérdezz

janoszen · 2010. Dec. 20. (H), 10.57
Kérdezz, azért vagyunk itt. Ez a változatosság kedvéért legalább egy izgalmas téma. Ha esetleg BP közelében vagy, akkor egy kávé / kóla mellett szívesen rendet teszek a zavaros fogalmak között.
10

Sajnos kicsit távol van.

daniel18 · 2010. Dec. 20. (H), 12.03
Hálásan köszönöm, de attól tartok Csongrád elég messze van BP-től. De ha arra járnék, akkor nem lenne rossz dolog összefutni (bár mostanában nem járok sűrűn BP felé, de majd ha gondolod megbeszélhetnénk egy időpontot).
3

Jó lesz ez!

daniel18 · 2010. Dec. 19. (V), 23.47
Engem meggyőzött a dolog, habár a ssh2.so még beta de nem találtam hibát a működésében (cáfoljon, aki nem így gondolja!).

Egy kis segítség azok számára, akik hasonló megoldást szeretnének:

Telepítés:
http://www.kevinbradwick.co.uk/2010/01/how-to-install-libssh2-on-a-centos-5-system/

Leírás:
http://kevin.vanzonneveld.net/techblog/article/make_ssh_connections_with_php/

Lib:
http://phpseclib.sourceforge.net/

Üdv,
Daniel
4

Howto

janoszen · 2010. Dec. 20. (H), 00.01
A Howto amit linkeltél, elég komoly problémákkal küszködik. Ha pl frissül a PHP verziód, akkor egyszer csak nézel mint Rozi a moziban, mert a libssh-d nem fog hozzá frissülni. Egyébként olvasd el a fenti hozzászólásomat, aki a leírást írta, az alapvető rendszerprogramozással sincs tisztában. Hogy csak egy problémát mondjak, ha a távoli SSH szerver sikeresen bejelentkezik, majd pl. a shell hiánya miatt elcrashel, akkor a második megoldással olvasol a végtelenségig.
7

Igen, verziókkal lehet kőkeményen szívni is.

daniel18 · 2010. Dec. 20. (H), 10.23
Hát nem nagyon akarok eltérni a fő témától, de a Drupal kőkemény használata mellett kőkeményem belém is lett vésve, hogy a verzió nagyon fontos és nem irkálok módosítgatásokat így-úgy mivel a drupal project release bármikor változhat és akkor kőkemény szívás az update ha egyéni módosítások vannak benne, akár csak ez a libssh cucc.

Jelenlegi megoldásom libssh esetén a telepítés módjának rögzítése kellemetlenebb nevén dokumentálása, valamint a beszerzési helyét még azért átnéztem: http://www.libssh2.org/download/

Köztünk szólva, hogy 1.2.7-es verzió a legújabb (2010-Aug-17) az szerintem nagyon jó. Tehát foglalkoznak a témával.

Ezen kívül apt-n is elérhető:
libssh-2-dbg - A tiny C SSH library. Debug symbols
libssh-2-dev - A tiny C SSH library. Development files
libssh-2-doc - A tiny C SSH library. Documentation files
libssh-2 - A tiny C SSH library
libssh2-1-dbg - SSH2 client-side library (debug package)
libssh2-1-dev - SSH2 client-side library (development headers)
libssh2-1 - SSH2 client-side library
libssh2-php - PHP Bindings for libssh2
Üdv,
Daniel
8

Security

janoszen · 2010. Dec. 20. (H), 10.54
Az a baj, hogy nem nagyon teheted meg, hogy egy security fixet nem teszel föl. Mivel a .so fájloknak kompatibilisnek kell lenniük azzal a programmal, ami hívja őket, egy PHP verzió frissítés haza vághatja a kézzel fordított .so fájlod működőképességét. Éppen ezért mindenképpen érdemes csomagkezelőből föltenni. Ha muszáj fordítani, akkor pedig mindenképpen csinálj belőle csomagot, mert akkor egyszerűbb lesz az új verzióra átállni. Ezen felül a csomagépítéshez mindenképpen használj valami teszt rendszert, amiben ki tudod próbálni az új csomagot.
11

Van teszt környezet.

daniel18 · 2010. Dec. 20. (H), 12.26
Van teszt környezetem, egy itthoni kisebb szervergép azon tesztelgetek + fordítgatok.

Olyan közepes config:
- 1 GB ram,
- AMD64 2,00 GHz proc,
- 80 GB HDD

De azokra a célra ami nekem kell, általában megfelel.

Visszagondolva a PHP SSH-ra van egy másik megoldás is:
Az pedig a PHP EXEC, ami egy belső szkriptet hív meg és onnan lép fel SSH-ra. Így viszont a LIBSSH2, PHP SSH2 csomagot el lehet felejteni, mivel nem kell már hozzá.

Például:
./SSH2 -host="127.0.0.1" -port "22" -user="test" -pass="test" -cmd="ps aux"
Ezt a parancsot kiküldi a szerverre és a "ps aux" értékkel visszatér. Az exec meg betudja olvasni változóba, ami pont kapóra jönne.

Mondjuk ez a megoldás lenne legjobb a számomra (biztonságilag is + csak ezt a kis szkriptet kellene updatelni és nem veszélyeztetné az egész webszervert + ha a process netán összeomolna -sosem lehet tudni- nem a webserver omlik össze), viszont ötletem sincs hogyan kéne megcsinálni (SSH-ra auto login? - talán egyéni kulcsfájl készítésével, de fontos lenne a felhasználó / jelszó páros módú autentikáció). A másik pedig az egyéb programozási nyelvek, mint: Perl, Python, C... ezek közül talán a Perl-t meg a Python-t értem a legjobban.

Perl-ben van a "Net::SSH::Perl" (http://www.stupidfool.org/perl/docs/perldoc/Net/SSH/Perl.html), viszont sok hibába ütköztem amikor megpróbáltam használni.

Pl: A kért parancsot kiküldte és tökéletesen meg érkezett választ. A második lekérésnél már összeomlott az egész Perl szkript.
14

Mutatom

janoszen · 2010. Dec. 20. (H), 17.06
Kétség kívül működik, de Te sem ezt a kérdést tetted föl, hanem a biztonságra voltál kíváncsi. Mi történik, ha pl a parancs helyére ezt írom be?

rm -rf /


Elárulom: szó nélkül le fogja törölni a merevlemezedet. Ha bármilyen szinten kompromittálódik a frontend, amin keresztül a parancsokat küldöd, megy a levesbe az egész gépparkod.

És nem ez az egyetlen probléma, van kismillió hibalehetőség, amit nem tudsz így lekezelni és ami miatt a rendszered kideríthetetlen fantomhibákat fog dobálni.

Röviden összefoglalva: rossz a koncepció. Felejtsd el az SSH-t, felejtsd el az execet, hacsak nem vágysz hosszú éjszakákon keresztüli debuggolásra és a biztonsági hibák miatti barebone recoveryra. Ismerd meg a téged kiszolgáló rendszereket és tanuld meg, hogyan lehet ezeket biztonságosan üzemeltetni!
16

Persze ez így van, viszont ...

daniel18 · 2010. Dec. 21. (K), 12.38
Viszont az UNIX-os parancsokat ez a cucc nem futtathat majd le. Tehát mutatom másképp:

./SSH2 host="127.0.0.1" [....] box="1" uid="1" cmd="user-create"
Egyéb commandok:

user-create  : Egyértelműen UNIX felhasználó létrehozása
user-delete  : Unix felhasználó törlése
user-block   : Unix felhasználó letiltása
user-unblock : Unix felhasználó feloldása
Operátorok:

box : Szerver ID száma ahova dolgozunk (DB-ből szívja fel az adatokat)
uid : Felhasználó azonosítója úgyszint DB-ből.
cmd : Parancs (lsd. Egyéb commandok)
Nos van egy Agent program a célszerveren (ami ezeket a parancsokat teljesíti). Ezt kellene lényegében elérnem SSH-n vagy bármely biztonságos protokollon, hogy munkára bírjam a célgépen.

Szóval a program valahogy így nézne ki:

1, amit weben exec-el elérek:
Felkapcsolódok SSH-ra, és elküldöm a ./Agent "[kapcsolók]" parancsot. Az Agent nem enged futtatni egyni UNIX-os commandokat.
2, az agent fut..:
Ha az Agent megkapta a parancsot a távoli géptől, akkor lefuttatja a kérést. (ha valami hosszú dologra készül, akkor screen be pakol hogy weben ne kelljen sokat várni a válaszra.
Tehát az agent tulajdonképp két módban is tud működni:
1. megvárja a választ és visszaküldi...
2. kiküldi a parancsot és nem várakozik...

A kérdés az, hogy hogyan tudjam lefuttatni a célgépen a parancsot weben keresztül?
17

Mi akadályozza meg?

janoszen · 2010. Dec. 21. (K), 13.01
  • Az agentnek átadáskor ugye escapeled a paramétereket?
  • Biztos, hogy az agented nem hív további shell scripteket? Biztos, hogy sehol nem lehet beküldeni egy olyan pipe hívást, ami code execet jelent?
  • Biztos, hogy lekezelted, hogy az SSH alatt, parancs futtatás közben, stb éppen elcrashel valami?


Nem értem, miért kötöd az ebet a karóhoz az SSH-val, CSAK hátránya van. Ha ilyesmire használod, akkor a biztonsági hibák melegágya és túl sok hibalehetőség van benne ahhoz, hogy megbízhatóan lehessen használni.
18

Lenne más megoldás?

daniel18 · 2010. Dec. 21. (K), 16.00
Ezzel csak egy a probléma. Lenne más megoldás arra, hogy szervert vezéreljek webes felületen keresztül? (UNIX user létrehoz / töröl, stb...)

Természetesen filterezési folyamatokon átesik a cucc.
20

PAM

janoszen · 2010. Dec. 21. (K), 21.32
Mint mondotta, a PAM-mal és az NSS-sel tudsz adatbázisból (MySQL, LDAP, stb) felhasználói adatbázist használni és pont olyan lesz, mint ha létrehoztad volna. Ergó nem kell se SSH-znod, se semmit, csak azon kell elgondolkoznod, hogy minden szerveren külön felhasználói adatbázist akarsz vagy egy központit és ezekre kell becsatlakozni és létrehozni a megfelelő bejegyzést. A neten van kismillió howto a konfiguráláshoz.

Ha esetleg szolgátlatást akarsz elindítani / leállítani, arra ott van a monit, aminek van egy XML-es vezérlő felülete.

Ha még valami másra vágysz, akkor KÉRDEZZ.

(A filterezést meg hagyjuk, az SSH-n keresztül küldött parancsok filterezése kb olyan rossz vicc, mint az, hogy valaki saját maga akar SQL escapelő függvényt írni a szerverhez adott helyett. Ha akarod, csinált, de a rendszer szinthez nagyon értők is be tudják nézni a végtelen számú lukat, nemhogy valaki, aki még csak most ismerkedik vele.)
23

Feltörni ezt azért nehéz volna szerintem.

daniel18 · 2010. Dec. 22. (Sze), 01.31
Function ...

function drx($cmd, $box_id=null)
{
       // [...] Box adatok betöltése, stb...
           $StringReplace = Array(
              ';' => '', '/' => '', '`' => '', "'" => '', '"' => '',
           );

       // [...] Felcsatlakozás, autentikáció egészen idáig:

            if (!($stream = @ssh2_exec($con, "cd /SERVER; ./dRx-Agent " . $cmd )

       // [...] a $stream-et while segítségével pedig átadom a $data-nak -> string
    return $data;       
}
Művelet ...

switch ($_POST['cmd']) {
                case "user-create": // Felhasználó létrehozása ...
                    $SSH2 = drx('cid="'.intval($row['customer_id']).'" cmd="user-create"', $box);
                break;
                case "user-remove": // Felhasználó törlése ...
                    $SSH2 = drx('cid="'.intval($row['customer_id']).'" cmd="user-remove"', $box);
                break;  
                case "user-block": // Felhasználó letiltása ...
                    $SSH2 = drx('cid="'.intval($row['customer_id']).'" cmd="user-block"', $box);
                break;              
                case "user-unblock": // Felhasználó feloldása ...
                    $SSH2 = drx('cid="'.intval($row['customer_id']).'" cmd="user-unblock"', $box);
                break;              
            }
A parancsok futása alatt, maga az Agent részben is futnak MySQL ellenőrzési pontok. Pl.: létezik-e a customer, létezik-e az unix user, stb...

Mivel javarészt csak számokkal kell dolgoznom az átvitel során, ezért ez nem hiszem hogy elsődleges támadási pont lenne. Az unix user neve és jelszava egy auto generált azonosító szám / jelszó.
24

Wow

janoszen · 2010. Dec. 22. (Sze), 09.16
Minden bántó szándék nélkül: te tényleg azt gondolod, hogy KETTŐ karakter replacelésével és néhány intval hívással megoldottál mindent? Vedd észre, hogy az agent oldalon IS kell védekezned, különben találnak egy sebezhetőséget és végigverik a szerverparkot. Lásd azt a nagy amcsi szolgáltatót, amelyiknél több ezer gépet bevert egy ex-alkalmazott.

Ha tényleg biztonságos rendszert akarsz, követned kell a layered defense elvét, mert ha még tökéletes kódot is írsz, simán találhatnak a kiszolgáló programokban (PHP, libssh) olyan sebezhetőséget, amivel megkerülhetik a védelmedet. Ezzel kapcsolatban ajánlom Tyrael előadását. (Sajnos nincs itt a link a slideokhoz, Tyrael, másold be légyszi.)
26

szerintem kicsit tulspirazod

Tyrael · 2010. Dec. 22. (Sze), 10.24
szerintem kicsit tulspirazod a dolgot.
irta a srac, hogy agent oldalon is van validacio, ennek ellenere en is javaslom, hogy megfelelo korultekintessel jarjon el a kod irasanal/tesztelesenel, de merlegre kell tenni, hogy mekkora az uzleti erteke annak, hogy lehessen tavolrol usert krealni a rendszerben, milyen megoldasok vannak a feladatra, melyiknek mekkora a befektetett munkaideje, illetve a biztonsagi kockazata, es ez alapjan el lehet donteni, hogy megvalosithato-e a feladat az elfogadhato biztonsagi kockazaton belul, illetve mely megoldast erdemes megvalositani.
szerintem.

amugy az eloadasom itt talalhato:
http://www.slideshare.net/Tyrael/biztonsgos-webalkalmazsok-fejlesztse

Tyrael
28

Nem azért, hogy védjem magam.

daniel18 · 2010. Dec. 22. (Sze), 13.16
Lényegében 6 év tapasztalatom van webes programozási szinten (PHP, HMTL, CSS, stb...), valamint a Linux környezethez is elég jól értek (Héjprogramozás, Perl, CGI, szolgáltatások, stb...) (annak ellenére, hogy a témában ez lejön).

A téma lényegébe a LIBSSH2/PHP-SSH2 biztonsági réseinek kivesézésére szólt, de némileg megnyugodtam hogy az újabb változat már jelentősen fejlődött a 2008-as régebbi változatokhoz képest. (Szeretek biztosra menni

A védelemmel teljes mértékben tisztában vagyok, megjegyzem én sem örülök annak hogy SSH-zni kell. De ha egyszer a helyzet megköveteli?

Az Agent program megjegyzem most jár 2300 sornál és mivel úgy szól a fáma, hogy a saját programozó nem ellenőrizheti saját programját azért a vezetői rendszerprogramozónk nézte át a kódot és megfelelő biztonsági szintűnek találta (de mivel még eléggé durván dev release, ezért előfordulhatnak hibák).

Most a sorrend a következő: agent program beta release elérése, majd utána lesz értelme elkezdenem a webes parancsküldő szolgáltatást.

Felsorolok pár biztonsági réteget, hogy kicsit világosabb legyen a dolog:

1. Parancsvédelem - Remote host
Mivel a célgépen az ./Agent [...] programmal lehet összetett parancsot küldeni a szervernek, ezért a futási / olvasási jogot CSAK kizárólag arra jogosult felhasználók kapják meg (az agent által létrehozott user alapilag ezeket a filek-et nem tudják elérni)

2. Titkosítás
Az agent csak valid titkosított parancsokat fogad el, mint például: "S4da3FaGPY66S0J00kTCrKC29K7yus+/R79HiTi9PuM=". Ez egy parancsot tartalmaz, aki megfejti grat hozzá. :-)

3. Egyebek
Számtalan biztonsági pontot illetve réteget hoztunk még létre. Ha a legrosszabb eset bekövetkezik... a "box" szervert fel törik, akkor a főszerver adatbázisát is fel kell törniük plusz azt az algoritmust ami szerint az egész dolgozik (megjegyzem ezt megcsinálni gyakorlatilag nem lehetséges, még annak sem aki jól ismeri a rendszert és részt vett a programozásába).
29

Hát jó

janoszen · 2010. Dec. 22. (Sze), 13.25
Hát jó, ahogy érzed. Én az SSH-ban túl sok hibalehetőséget látok, hogy csak úgy el lehessen mellette menni. Próbáld meg azt elkerülni, hogy egy géped kompromittálódásával az egész rendszered menjen a levesbe. Igen, a fő gépedre gondolok. Ha abban van egy root exploit mondjuk a webszerverben, akkor semmi nem véd meg attól, hogy reverse engineeringelje a kódodat vagy éppen csak kiolvassa a logint/passwordöt és belépjen SSH-val, majd azt futtasson, amit akar.
32

Erre számtalan védelem van

daniel18 · 2010. Dec. 22. (Sze), 13.30
Nem vagyok linux guru, de tudok pár dolgot. Például: Rootkit hunter ... vagy ami humánosabb az a fájlok dátumának változásának figyelése. Biztonsági mentések, stb... De ezt majd a rendszergazdánk eldönti, hogy hogyan építi fel. Én csak a szoftvercsomagot készítem el, ami ezeket képes megcsinálni.
12

SOAP

joed · 2010. Dec. 20. (H), 16.01
Én inkább egy SOAP vagy XML-RPC megoldásban gondolkodnék titkosított csatornán. Feltéve, hogy a célgépen tudsz SOAP service-t elhelyezni.
13

Nem jó út.

daniel18 · 2010. Dec. 20. (H), 16.33
Sajnos az XML-RPC nem megfelelő erre, plusz ha a csatornája is titkosított rendkívül letudja terhelni a szervereket. Habár ötletnek nem rossz.

Viszont úgy néz ki, hogy egyenlőre a PHP SSH2 jelenleg bevált nekem és gyors is. Valakinek van-e negatívuma / pozitívuma a PHP SSH2 kapcsán?
15

Névfeloldás?

janoszen · 2010. Dec. 20. (H), 18.56
Ugye ilyen triviális dolgokat megcsináltál, hogy kikapcsoltad az SSH szerveredben a csatlakozás idejű névfeloldást?
19

tehat ha jol ertem, akkor az

Tyrael · 2010. Dec. 21. (K), 17.03
tehat ha jol ertem, akkor az a szituacio, hogy van egy ket szervered, az egyiken fut egy webszerver, ezt erik el a userek, a masik szerveren kellene pedig kiadnod a parancsokat, amivel ha jol lattam a kommentekbol useradd/userdel, etc. muveleteket vegeznel.

ahogy ti is irtatok, lehetne ssh-t hasznalni, viszont ebben az esetben javasolnam, hogy valami custom shell-t kapjon az a dedikalt user, akinek a neveben csatlakozik A gep a B gephez, igy viszonylag jol garantalni lehetne, hogy csak azt az N darab muveletet tudja elvegezni, amit szeretnel (viszont a unix useradd/del pont olyan muvelet, amihez kell root, ergo vagy root user neveben leptek be, vagy szukseg lesz valami sudo/suexec mokara a shell kapcsan)

ha a remote shell-t nem sikerulne beloni, akkor meg mindig meg lehetne azt csinalni, hogy mindket szerveren fut apache, es a publikus csak atdobja a kerest a hatterben a masiknak, aki localban vegrehajtja exec-cel, itt szinten kelleni fog sudo/suexec.

a harmadik megoldas idealis kornyezetben az lenne, hogy ha a geped valami kozponti user adatbazisbol dolgozik (kerberos, ldap, etc.), mert azt fel lehet ugy konfiguralni, hogy root jog nelkul lehessen usereket felvenni/torolni, persze megfelelo authentikacio mellett.

alapvetoen azt gondold vegig, hogy mi tortenik, ha kompromitalodik valamelyik gep.
akarhogyis, de ha valahogy ez megtortenik, akkor a tamado mar tovabb tud menni a rendszerben (akar a lokalis akar a tavoli kodfuttatason keresztul, vagy ha a useradatbazisba tud irni, azzal is felvehet egy felhasznalot, akivel be tud kivulrol lepni)

Tyrael
21

Luk luk hátán

janoszen · 2010. Dec. 21. (K), 21.35
Tyrael, az a baj, hogy a t. kérdező nem volt Synapse előadásán. Ergó nem látja azt, hogy ha custom shell is van, simán lehet, hogy egy háttérben futó shell script lesz vulnos, amiben van egy szép kis code exec és már kész is a kocsi.

Mint fentebb írtam, én MINDENKÉPPEN azt javaslom, hogy NE akarjon SSH-n keresztül csinálni SEMMIT. (Mi egy ilyennel majdnem megszívtuk, szerencsére volt egy pár védelmi réteg és mi vettük észre először, különben kényelmesen rootig lehetett volna verni az egyik gépünket.)
22

ha a hatterben futo barmi

Tyrael · 2010. Dec. 21. (K), 23.00
ha a hatterben futo barmi lesz vulnos, akkor mar tok mindegy, hogy milyen protokollon keresztul tudott nem megfeleloen validalt inputot betolni.
sftp(scponly, rssh), vagy git(git shell, gitosis) is szepen elmukodik igy.
persze ha szar a kod, akkor ez sem biztonsagos, de akkor miert felteteleznenk, hogy az osszes tobbi app/service az?

Tyrael
25

SSH

janoszen · 2010. Dec. 22. (Sze), 10.11
Nézd, én debuggoltam az SSH-t, amikor a chrootolt PHP futtatást fejlesztettem. Annyi pont van, ahol el tud romlani egy ilyenben, hogy irreálisnak érzem, hogy egy kvázi-kezdő ezt össze tudja rakni tisztességesen. Kb 2 hétig csak az OpenSSH szervert néztem strace-val csak azért, hogy az összes vicik-vacak libet és device nodeot be tudjam rakni a chrootba, amire szüksége van. Nem véletlenül döntöttünk úgy, hogy nem SSH-n keresztül hozzuk létre a felhasználókat.
27

az ssh szerintem elegge

Tyrael · 2010. Dec. 22. (Sze), 10.28
az ssh szerintem elegge kiforrott megoldas, sokkal nagyobb az eselye, hogy mashol verik be a rendszeredet, mint hogy egy privat 0day openssh sebezhetoseget arra "pazarolnak" hogy pont a te rendszeredet nyomjak be vele.
persze ha nem frissitesz megfelelo tempoban, akkor ez problema lehet kesobbiekben, de ez mar egy masik kerdes.

az hogy ha chroot-olni akarod az ssh-t akkor nem teljesen trivialis a megoldasa, az megint csak lazan kapcsolodik a temahoz.

Tyrael
31

Libssh

janoszen · 2010. Dec. 22. (Sze), 13.27
Nem az SSH-ra gondolok, mint potenciális exploit, hanem mondjuk a PHP-ra vagy éppen libssh-ra vagy a pecl-es csomagra.
30

Ez akkor most mi?

daniel18 · 2010. Dec. 22. (Sze), 13.26
Proclub, biztosan tudunk egymásnak újat mondani, viszont ha 6 év gyakorlat kezdésnek számít akkor csak gratulálni tudok (csak mert nagyon le lettem rangozva és nyomva a bénaság felé).

Ne vedd személyeskedésnek, csak ez itt egy nyílt beszélgetés és nyilván Te sem helyeznéd el szívesen a rendszered biztonsági algoritmusát / kódjait elemzésre. Persze jó volna, de sajnos sokan vannak akik szeretnek az ilyesmivel visszaélni (pl.: lenyúlni).

Maradjunk annyiban, hogy ez a biztonsági kérdés a részemről meg lett oldva.

Köszönöm a válaszokat és a rám szánt időt.

Üdv,
Daniel
33

-

janoszen · 2010. Dec. 22. (Sze), 14.00
-