Bezpečnější prostředí pro webové aplikace

[KapitánRUM]

Ahoj,

mám dotaz na ty nejzkušenější.

Jak učinit prostředí pro běh webové aplikace bezpečnější?

Co považujete za BEST PRACTICES na zabezpečení běhu webové aplikace na VPS?
Řekněme třeba Joomla nebo nějaký E-shop na VPS, což je asi nejobvyklejší a nejlepší příklad.
Aplikace potřebuje Postfix, MySQL, Apache, PHP a podporu SSL.

Pointa je, že TO důležité, TO co má jediné cenu, je stejně JEN uvnitř té webové aplikace.
Vycházím z toho, že po získání přístupu k webové aplikaci a stažením její zálohy klesá cena zbytku k nule.

Chroot mi přijde až nesmyslné používat, pokud mi to někdo nabourá a vykrade, pak to stejně udělá přes Apache/PHP/díru v té aplikaci a získá všechno co chtěl. Je to jako hlídat garáž zevnitř, když auto stojí venku!

Tedy:
- přehodit porty SSH
- nastavit dobrá hesla
- na MySQL umožnit připojení jen z localhost
- pro přístup do MySQL lze klidně použít root, jiný uživatel nemá smysl, protože stejně musí mít právo na čtení a pokud to přečte, tak to i vykrade
- aktualizovat všechny služby
- hlídat si tu webovou aplikačku, jestli v ní nejsou zranitelnosti
- zálohovat
- monitorovat přístupy k serveru, hlavně změny souborů

Nebo máte někdo v rukávu nějaký úžasný trik?

[Reklama]

[Zopper]

Ad mysql účty - naopak, samostatný účet na každou databázi a samostatnou databázi na každou aplikaci (a omezit přístup jen a pouze na tuto DB). Pokud se útočník k DB dostane přes SQL injection, omezí ho to na konkrétní aplikaci a přes chybu na blogu nemůže změnit data v eshopu.

Rovněž stojí za úvahu mít většinu systému na read-only oddílu, takže vám nikdo nebude moct přepsat binárky. Zapisovatelné oddíly mít jen tam, kde se něco zapisovat musí.

[branchman2]

• u SSH neprehadzovat port, ale mat whitelist IP; ostatne IP blokovat
• podozrive chovanie reportovat mailom (logy utocnik zmaze)
• monitorovanie nezavisle na nastrojoch serveru
• hardened kernel
• pouzit taku DB, ktora podporuje detailne pristupove prava a k tomu spravit len niekolko funkcii, ktore budu mat jednotlivi uzivatelia povolene - keby niekto napr. nasiel dieru (ale mensiu, takze by si nemohol precitat vsetky hesla), tak by nemohol dumpnut DB - mohol by napr. len vytvorit novu objednavku na nejakeho uz existujuceho uzivatela alebo by mohol stiahnut zoznam tovarov (co moze aj bez diery)

[Mordae]

Nejake to pocteni k tematu je na virtualmaster blogu.

[Ondřej Caletka]

Rovněž stojí za úvahu mít většinu systému na read-only oddílu, takže vám nikdo nebude moct přepsat binárky. Zapisovatelné oddíly mít jen tam, kde se něco zapisovat musí.

Aby mohl přepsat binárky, musí mít práva roota. Když už bude mít práva roota, může si oddíl remountnout do RW. Nebo víš o nějakém způsobu, jak udělat oddíl semipermanentně (=do rebootu) zamčený na read only? Nějaký patch do kernelu by to nejspíš řešil.

[Reklama]

[Mirek Prýmek]

Aby mohl přepsat binárky, musí mít práva roota. Když už bude mít práva roota, může si oddíl remountnout do RW. Nebo víš o nějakém způsobu, jak udělat oddíl semipermanentně (=do rebootu) zamčený na read only? Nějaký patch do kernelu by to nejspíš řešil.

Např. ve FreeBSD je možné u souboru nastavit flagy tak, aby do nich ani root nemohl při zvýšeném securelevel zapisovat.
- viz http://www.freebsd.org/cgi/man.cgi?security(7)

Na Linuxu určitě podobné patche existují taky, ale nakolik je distra používají, to netuším.

[Zopper]

Read-only FS: Buď úpravou jádra, nebo, pokud je systém uvnitř virtuálního stroje, to může být řešeno v rámci hostitelského systému - možná by stačilo jen neumožnit zápis uživateli, pod kterým hypervisor běží.

[Mirek Prýmek]

Co považujete za BEST PRACTICES na zabezpečení běhu webové aplikace na VPS?
Řekněme třeba Joomla nebo nějaký E-shop na VPS, což je asi nejobvyklejší a nejlepší příklad.
Aplikace potřebuje Postfix, MySQL, Apache, PHP a podporu SSL.

Pointa je, že TO důležité, TO co má jediné cenu, je stejně JEN uvnitř té webové aplikace.
Vycházím z toho, že po získání přístupu k webové aplikaci a stažením její zálohy klesá cena zbytku k nule.

Moc nechápu, co chceš vlastně docílit:

1. aplikace musí mít k datům přístup pro čtení
2. nechci, aby mi ta data někdo neoprávněně přečetl

...z toho mi celkem jasně vychází, že alfa a omega je, aby byla bezpečná samotná aplikace. Jestli to běží v rámci VPS nebo ne, je úplně jedno.

[Mirek Prýmek]

Read-only FS: Buď úpravou jádra, nebo, pokud je systém uvnitř virtuálního stroje, to může být řešeno v rámci hostitelského systému - možná by stačilo jen neumožnit zápis uživateli, pod kterým hypervisor běží.

Tím bych si nebyl tak úplně jist. Záleží na tom, jak se hypervisor zachová, když zjistí, že data nemůže zapsat na disk. Skoro bych dal ruku do ohně za to, že alespoň u části hypervizorů se data na úrovni hostovaného systému zapíší, čili putují do nějaké cache a když se zjistí, že z cache na fyzický disk nejdou zapsat, stane se kdoví co.

[Zopper]

Alternativou by tedy možná bylo udělat nějaké "live cd" iso a bootovat systém z něj - a datové oddíly připojit už jako normální disk pro rw.

[PCnity]

Neviem si pomoct... Ale pokial je to najhodnodtnejsie v databaze tej webovej aplikacie, zameral by som sa hlavne na tu aplikaciu samu. Vsemozne veci ako prehodit SSH port a podobne sa viac dotykaju script kiddies...
Ked mam pristup k PHP exec alebo system, mam vyhrate. Skor ci neskor najdem vhodny exploit a /tmp je skoro vzdy zapisovatelne
Staci netcat a bindovat bash. Jednym smerom alebo opacny, je jedno.

Moje best practices su:

*chroot
*ro fs az na absolutne potrebne minimum
*rw fs ak je nutny (ak sessions nie su v memcached alebo koli uploadom) tak s nosuid a noexec!
*updaty, updaty, upday!
*Stale cledovat ci nie zverejneny novy 0day alebo hocikay zavaznejsi bug pre dany projekt [sql injection, eval(), ...]
*Urcite sa vyhrat napriklad s PHP diable functions
*Mozno by ani aplikacny firewall neskodil ktory by sledoval na zaciatok aspon GET requesty a pokial niekto donekocena sekvence meni nejake id vo velkom rozsahu, cez iptables bloknut IP a notifikacia admina.

[KapitánRUM]

A jaký aplikační FW, jsou různé, můžete něco doporučit ZE SVÉ ZKUŠENOSTI?

Dík.

[PCnity]

Budem velmi rad az raz budem moct. Aktualne mame nasadene len NIDS (snort). Ale je to tema ktorej sa mienim venovat ked bude cas

[KapitánRUM]

Takže nikdo neporadí žádný konkrétní nástroj?

[Zdeněk]

má základní pravidla:

• vše co jde by mělo mít samostatný uživatelský účet (joomla má jiný UID než např. webshop)
• v OS nastavené limity na procesy, na FS kvóty a pod., webserver správný počet procesů
• ssh - jen přihlášení klíčema
• nepoužívám ftp, imap, pop3 a další nezabezpečené protokoly
• aplikace má přístup s přihlášením uživatelů pouze přes https
• používám Apache jako webserver, takže vyházet zbytečnosti, dovolit jen ty moduly, které nutně potřebuji
• do apache přidat mod_security a vhodně pro danou aplikaci nastavit
• v případě php používám suhosin
• na serveru používám grsecurity + vhodná pravidla na míru aplikací (někdy je náročnější je sepsat, ale když už to člověk jednou udělá...)
• v aplikaci držím jen ta data, která jsou skutečně potřeba pro běh a jinak to odleju na bezpečné místo
• samozřejmě zálohuji :-)
• všechny logy hned posílám na jiný server
• na serveru používáme iptables