Dotaz: Nezpecnost serveru s LAMP

[petrfm]

Ahoj, mam HW server pripojeny pres mikrotika na verejnou IP. Mam na nem nejake sdileni, SAMBU a takove nesmysly. Bezi mi tam i virtualka s ubuntu a LAMP. No a tady to prichazi. Mam takove nutkani, nechat na nem bezet jeden takovy nepodstatny projekt, ktery ale zabira dost mista na disku a proto by se hodilo, mit to takhle hezky fyzicky u sebe.

Melo by tam bezet i phpbb. A tady to prichazi. Bojim se, ze mi pres to phpbb nekdo hackne cely ten server.

A proto se ptam zkusenejsich, na co si dat pozor a kde jsou slaba mista? Pokud pobezi vsechno pod uzivatelem www-data a ten nebude mit pristup mimo svuj pracovni adresar, muze se utocnik pres chyby ve skriptech / php dostat dale na server, nedej boze do vnitrni site?

A co s tou verejnou ip? nemuze mi ji pak nekdo kvuli tomu phpbb napadnout? Je tam mikrotik a jsou otevrene porty jen pro 80.443 a VPNku. Nemam z venci pristup na zadne SSH, apod. Presto mam strach, aby nekdo nevlezl dovnitr treba chybou FW toho mikrotika... je to mozne? Ma smysl updatovat vzdycky na nejnovejsi verzi?

Jak byste to udelali vy? Nechali na tom serveru jen svoje veci a tyhle verejne projekty hostovali na nejakem hostingu, nebo se toho nemusim bat?

Diky za tipy,

P.

Odpovědi

[Jendа]

muze se utocnik pres chyby ve skriptech / php dostat dale na server

Ano. Sice by neměl, ale občas se objeví lokální nějaký root exploit.

nedej boze do vnitrni site

Pokud www-data nebude mít zakázanou síťovou komunikaci, tak samozřejmě může. Pokud bude, tak viz výše.

To s tím Mikrotikem nechápu (jako co třeba znamená „napadnout IP adresu“).

Jak byste to udelali vy?

Vybodl bych se na to nebo mu udělal virtuál.

[petrfm]

vybodl by ses na co ? To hostovat sam, nebo na ty obavy?

S tou IP jsem se spatne vyjadril. myslel jsem to tak, ze tim, ze tam pobezi takova sluzba, ze se mi nekdo obuje do IP adresy. Proste ze to phpbb, ktere najde nejaky bot bude lakadlo a potom dojde k prolomeni nejakeho zabezpeceni toho mikrotika a utocnik si treba otevre nejaky dalsi port, nebo co ja vim

Virtualka - resi to neco? Cele to bezi na proxmoxu, takze si tam muzu virtualky sekat jak chci, ale to bych pak musel definovat presne pravidla, kam ta virtualka v siti muze, apod, pripadne ji nastavit IP z jineho rozsahu, atd. ze? Coz ovsem taky nebude zadna velka slava, kdyz ty vsechny masiny pak budou pripojene jednim fyzickym rozhranim.

[Jendа]

Na ty obavy…

Virtualka - resi to neco?

Ano, může se celá zafirewallovat.

Coz ovsem taky nebude zadna velka slava, kdyz ty vsechny masiny pak budou pripojene jednim fyzickym rozhranim.

Proč? Firewall se samozřejmě musí dělat na hostu, ne v té kompromitované virtuálce.

[trekker.dk]

Proč? Firewall se samozřejmě musí dělat na hostu, ne v té kompromitované virtuálce.

Root exploit v hypervizoru, exploit v hypervizoru, znovu root exploit v hostiteli a jsi tam, kde jsi byl. Na druhou stranu bych řekl, že už tohle je nad rámec toho, o co se kdo bude snažit - většině "hackerů" stačí prohákovat se k tomu PHP, aby se nechal spustit spamovací skript, na to roota nepotřebujou.

[petrfm]

Ted nad tim trochu premyslim. Hostingy asi maji pro mysql extra masinu, pro php extra masinu, atd. Takze kdyz nekdo ziska roota pres diru v php a bude mit v mysql vice projektu a spravne nastavene prava pro pristup do tabulek, tak se treba pres toho roota nedostane do mysql, ale jen k souborum hostovanym na tom serveru (kde jsou v config souborech hesla do mysql, takze se defakto stejne dostane vsude, navic i kdyz ta mysql bezi na virtuale, tak k ni musi ten PHP/apache server mit pristup a kdyz na nem nekdo ma roota... takze zase zadna ochrana... ))) )

[Kit]

Je snad možné se přes Apache dostat na roota?

[Jendа]

CVE-2014-0038

[Jendа]

Pardon, CVE-2014-0196. Rychleji píšu než čtu.

[rastos]

Čo to má spoločné s Apache?

[Jendа]

Omlouvám se, pořád jsem uvažoval kombinaci Apache+PHP. A tam to jde třeba tak, že mi děravá aplikace umožní vykonat libovolný PHP kód a pak buď je povolená alespoň jedna z mnoha „nebezpečných“ funkcí, nebo použiju nějakou díru v PHP (taky jich je dost).

[Max]

Což řeší selinux.
Zdar Max

[92859205890]

Ale no tak fakt tomu verite ?

[Mac_CZ]

Tak pokud nevěříte selinux, tak zkuste apparmor.

[Pavel 'TIGER' Růžička]

No já osobně používat LAMP, tak bych ho jako první hodil do virtuálu a hrál si s tím ve virtuálu. Také nevím, jaké konkrétní napadnutí myslíš, resp. jakých škod se obáváš?

[petrfm]

Ja ten laml ve virtuale mam. Je to jedna masina, na ktere je KVMko a mam tam celkem 4 virtualy, z ktere jedna je ten lamp. Mam tam ale i webdav uloziste, atd. Kdybych to chtel rozdelit, musim udelat extra virtualku jen pro ten lamp na hrani a potom na tom hlavnm lampu spustit nejakou reverzni proxy, protoze potrebuju mit z venci pristupny i ten prvni LAMP. (kdyz chci nekomu neco poslat, nahraju to na nej a poslu mu odkaz, pouzivam tam owncloud - ale neni to verejne nejak propagovane, musi znat spravnou adresu)

Ceho se bojim? Toho, ze pokud prolomi ten LAMP a ovladne tu virtualu, dostane se do vnitrni site. No a vnitrni sit nemam tak dobre zabezpecenou - mam povolene skoro vsude SSH, pouzivam hesla, bezi tam samba s firemnimi vecmi, atd.

Zvenku se tam nikdo nedostane, protoze je to za firewallem, ktery dela ten mikrotik, ale kdyby se dostal dovnitr, je to prusvih. Proto se ptam na Vas nazor, jestli to ma smysl riskovat, nebo jestli tim vlastne nic moc neriskuju, nebo jestli se to da nejak SNADNO zabezpecit.

[Pavel 'TIGER' Růžička]

Tak to rozhodně dobré není. Kdybys to takhle spustil, byla by to špatně navržená topologie sítě. Nevím, nakolik ty LAMPácké věci jsou vytížené, ale rozhodně bych to viděl na server před mikrotik a na server za mikrotik. Teoreticky by to šlo i v rámci jednoho stroje, kde by LAMPy byly mimo rozsah Tvé sítě a tvá síť by měla zakázán přístup z toho rozsahu, což znamená alespoň o jednu síťovku navíc. Leč pořád je to řešení, za které bych nedal ruku do ohně. Pokud jsou firemní věci velmi důležité a to většinou jsou, tak to dobrý nápad není. Buď dva stroje, nebo hosting.

[petrfm]

No, tohle prave resim... Konecne mne nekdo presne pochopil Pokud by byl LAMP neprustrelny, riziko by to nebylo, ale pokud se nekdo pres to forum dostane na server, je to v pytli a vidim to jako riziko.

Mikrotik ma docela chytry switch, takze by asi opravdu stacily do serveru dve sitovky a pripojit ten LAMP virtual extra a nedovolit mu pristup do vnitrni site, to je ale presne to reseni, ktere je uz tak komplikovane, ze to radeji dam na hosting.

Diky tedy za diskuzi a potvrzeni mych obav, ze se nejedna o dobry napad.

P.S. jen ze zvedavosti - ty virtualy se daji hodit na jiny subne i v tom proxmoxu, takze kdyz pominu riziko, ze by nekdo odposlouchaval na fyzickem rozhrani a ovladl ten proxmox, tak bych defakto mohl zabranit aby se ty site navzajem videly i takto jednoduse. ALE - dostanu se potom na ten server kvuli spravy? Jak se to nastavuje? Pro tu moji konkretni IP - spravcovskou, treba muj notebook si nastavim routu do obou subnetu?

 

P.

[petrfm]

Ted si to ctu znova ten tvu prispevek a uz mi svita - zakazan pristup z toho rozsahu. Cili naopak. Ta chranena sit - firemni server by mel zakazany pristup ze site toho LAMPU (treba dropem na firewallu), ale muj notebook, ze ktereho to vsechno spravuju by mohl do obou siti. Takhle by se to asi dalo udelat, ze ?

No a ta fyzicka sitovka navic tam je proto, aby nekdo neodposlouchaval v promiskuitnim modu... je otazkou, jak je reseny ten ethernet na tom proxmoxu, ale mam za to, ze ty virtualky to strka vsechny do bridge na to jedno LAN rozhrani. No ale pokud uz jsem ve vnitrni siti, muzu zacit busit do routeru a oteviraji se dalsi zpusoby, jak ho oje*at, aby mne pustil i do te druhe site, je to tak? Proto je lepsi to mit fyzicky rozdelene na dve ETH rozhrani a budto dva switche, nebo administrovatelny switch, ktery ty pakety proste na "druhy kabel" nepusti.

P.

[Pavel 'TIGER' Růžička]

Tak nějak to bylo myšlené.

[Max]

1) Naladit oprávnění pro jednotlivé weby, co web, to uživatel a skupina, takže se nebudou nijak ovlivňovat.
2) naladit cachování.
3) Kam není potřeba zápis, tam ho nepovolit.
4) Zakázat v php různé nebezpečné fce.
5) zabezpečit pomocí selinux, popř. něčem podobném
6) povolit v apache status modul jen z lokální sítě, aby jsi mohl provádět diagnostiky případných problémů.
7) aspoň trochu to něčím monitorovat, aby jsi hned věděl, když nastane nějaký problém.

Rozchodit apache a php je triviální, ale rozchodit ho nějak rozumně a bezpečně, to už se moc nevidí.
Zdar Max

[petrfm]

No a neni tohle vsechno uplne zbytecne, kdyz utocnik ziska roota? Vyjma snad bodu 567... ?

Prave proto jsem pokladal tenhle dotaz, protoze jak pises, podle tutorialu vsechno rozchodit neni problem, ale zacatecnik snadno neco prehledne, nebo podceni. Slo mi tedy prave o to zjistit, jake jsou potencialni rizika a jestli jsou vysoka (proste mira zneuzitelnosti, protoze zneuzit a prolomit se da vse, otazkou je, jak casto se takovy problem vyskytne a zda vubec nekomu muj server stoji za to, aby to stihl do doby, nez ubuntu vyda zaplatu).

Cili asi bude lepsi provozovat ten server soukromne, nepristupny z netu, nebo jen pro hrstku znamych a tyhle exponovane veci dat na placeny hosting, kde tohle vsechno resi zkuseny admin.

P.S. dokazal by mi nekdo poradit, jak jednoduse otestovat nastaveni firewallu? Muzu k te siti pristupovat z venku z jineho pripojeni...

[hydrandt]

Z toho, jak to popisuješ, bych si zas tak velké starosti nedělal. Stačí se řídit zde zmíněnými radami. Já se teda přiznám, že selinuxu nerozumím, ale aspoň nastavuju noexec na partišny kde to jde apod.

To, že se ti tam někdo dostane kvůli chybě firmwaru v mikrotiku, je podle mě dost nepravděpodobné, a když máš zvenčí přístupné jen 80 a 443, zas tak moc toho napáchat nejde - určitě je ale dobré sledovat mailing listy těch php aplikací, co tam máš nasazené, a aktualizovat.

Jednoduchý test zvenku je nmap -A ip.adresa -- rád se přiučím co všechno to neodhalí

[MMMMMMMMM]

s těmi placenými hostingy bacha - není admin jako admin, např. http://www.lupa.cz/clanky/otazky-okolo-hacku-banan-cz-zustavaji/ (byla velká aféra)

[ET]

jestli se s tim neches moc mazat, schovej celej web pod heslo

[petercheco]

Kluci, píšete sem milión užitečných věcí, ale nikdo z vás nenapíše základ.

Fail2ban na vše, vše na jeden pokus a minimálně jeden týden ban ip adresy, která se dopustila jednoho chybného přihlášení.. Pak útočníka omrzí jakýkoli útok na server :).

[Jendа]

Proč by ban po chybném přihlášení útočníka měl odradit od zneužití chyby v PHP aplikaci?

[petrfm]

Ono to bylo asi mysleno tak, ze i kdyz se potom dostane do vnitrni site, tak nenapacha takovou skodu, jako kdyz treba zjisti heslo a bude zkouset zadavat na ruzne sluzby.

Je fakt, ze instalovat selinux a takove kejkle se mi fakt nechce, to radeji ten system necham zvenci uzavreny. Proto se mi prave moc nelibi ta myslenka, to otevirat ven, i kdyz by mi to asi dost pomohlo.

Myslim, ze je zbytecne zabihat do uplnych obskurnich detailu, nemam na tom serveru data z nasa, ale slo mi spis o nasmerovani, treba i na nejaky clanek, kde bych se docetl, jake jsou potencialni rizika a slo mi asi i o to, jestli mi to nejaky zkuseny admin proste nerozmluvi, s tim, ze "nechej si to zavrene, pro sebe, hrej si a uc se na tom s linuxem, ale nepoustej tam lidi z venci". A proste po tom, co par opensource projektu na PHP provozuju (na komercnim hostingu) - vim, ze jakmile se nekde spusti neco v PHP, je to bezpecnostni problem a neustala starost o sledovani novinek a zalepovani der. Nevim, jak je na tom konkretne PHPBB, ale treba s Joomlou jsem si uzil svoje a to je pak cloveku dost neprijemne od zaludku, kdyz vidi, jak se mu kdekdo prohani po webu a upravuje scripty. Proto bych nechtel, aby se diky nejakemu nepodarenemu scriptu prohanel po firemnim serveru.Nevadi mi, kdyz kompromituje to phpbb, smaze ho, apod. Ale nesmi se dostat dale do site, potazmo na ten linuxovy server.

Proto bych jako reseni uvital ne nejaky selinux a jine silenosti na tydenni studium (placeny hosting me vyjde max. na blbe 4 stovky rocne), ale spise zpusob, jak te aplikaci zabranit, i kdyz ji nekdo prolomi, aby se dostal mimo ten jeji pisecek. Chtelo by to neco, jako jsou virtualky pro operacni systemy. Urcite mi nekdo namitne, ze to jde udelat. Jasne, ale strasne se mi tim vsechno zkomplikuje. A me se prave na virtualizaci libi to, jak je to ucinne, ale pritom jednoduche

[petrfm]

Jeste mne napada jedna vec, jak to mohl pisatel myslet... ze malo kdo pujde hned na diru ve scriptu, ale zkusi se spise zalogovat na ssh, apod. Tim si defakto zabanuje svoji IP. To by u mne ale nemelo moc velky vyznam, protoze ssh, ani nic, co by dovolovalo prihlasovani nemam vubec pristupne z venku.

[Jendа]

Co jsem koukal u sebe, tak roboti zkoušející děravé skripty a SSH jsou nezávislé sekvence IP.

[xkucf03]

Buď tu (ne úplně bezpečnou) aplikaci spusť v LXC¹ nebo aspoň použij PHP-FPM a spouštěj ji pod uživatelem vyhrazeným jen pro ni.

Pro úspěšný útok by se ti pak musely sejít dvě chyby: 1) v té aplikaci 2) v systému – lokální eskalace práv nebo dokonce možnost vyskočení z LXC.

Plus k tomu přidej obvyklé zabezpečení na úrovni php.ini (zákaz některých funkcí, omezení open_basedir atd.). A omezení firewallem – když víš, pod jakým UID ta aplikace běží, tak jí v iptables můžeš zakázat navazovat spojení ven.

_{[1] lehká virtualizace (resp. kontejner) uvnitř toho současného virtuálu}

[xkucf03]

P.S. a pokud to není nějaká aplikace pro frikulínskou veřejnost, ale spíš něco jako intranet, tak tam dej HTTP(S) basic autentizaci → bez hesla nebude útočník ani vědět, že tam nějaké phpbb běží, protože ho Apache vůbec nepustí dál.

[student]

LXC negarantuje izolaciu, takze vyskocenie z LXC nemusi byt chyba. Root v LXC = root v hostujucom systeme.