Názory k článku
Základní zabezpečení LAMP serveru

„Nemá smysl povolit 100 PHP procesů s limitem 64M RAM každý na serveru s 1024M RAM.“

Z principu by to vadit nemělo, ten proces taky nemusí sežrat celých 64 mega (že je praxe často jiná…)

-

„Pokud to z nějakého důvodu není možné, nepoužívat ssh přístup k serveru přes účet root, místo toho používat uživatele user a sudo nebo su.“

A to jako pomůže čemu?

-

Pozor, v tom populárním útoku (ukradení údajů trojanem) je TotalCommander zcela nevinně a úplně stejný útok lze už z principu provést na libovolného klienta a libovolný protokol.

-

K čemu je dobré nastavovat firewall na default drop a pak povolovat přístup k příslušným portům, když nám na serveru stejně nic jiného neběží?

Lebo stále sa nájde niekto, komu beží na webserveri cups a mysql nielen na localhoste?a

V takovém případě je ale problém se zabezpečením úplně jinde (ve správci) a ani nastavený firewall (tím správcem) na tom nic nezmění.

Ten článek je sice obecný, ale má pravdu. Osobně si myslím, že na LAMP server stačí DB přes UNIX socket (případně pro menší weby klidně nějaká souborovová DB s přístupem přes knihovnu (trivial database, sqlite), Apache s nastaveným SSL a webové aplikace. SSH tam běží by default. Nic jiného není potřeba.

Přes SSH (autentizace pomocí klíčů) tam jdou nahrávat i soubory (SFTP). Port 22.
Přes Apache se tam dostanou uživatelé. Port 22 a 443.

Nic víc tam neběží, firewall je tedy zbytečný (povoloval by všechny dostupné porty).

Napr. protoze kdyz nekdo na ten server dopravi nejakeho v php napsaneho demona a pusti si ho na portu 10000, tak se na nej zvenku nepripoji.

Mimochodem, je radove efektivnejsi, kdyz ssh je omezeno firewallem na duveryhodne IP adresy, nez kdyz je prestehovano na nejaky obskurni port.

Omezení na důvěryhodné IP vás ale může nepříjemně kousnout právě když to nejméně potřebujete.

Některé firmy (UPC opakovaně) vám změní "pevnou" IP právě ve chvíli nějakého průšvihu.

UPC mění IP adresu jen při dlouhém výpadku/vypnutí modemu. Jinak je pořád stejná.
Ale když se změní je to problém. Člověk se strašně diví, proč mu nejede SSH. A než mu to dojde...

Mluvím tu o PEVNÉ IP, která má být tak pevná, že stojí pevných 200 Kč za měsíc!

A ta by se fakt bez upozornění měnit neměla ani kdyby trpaslíci v modemu poskakovali!

ale tady jde o tu na druhé straně ;)

Ta na serveru by snad měla být pevná vždycky, ne?

Nejbezpečnější je zabezpečit onen ssh démon.

Seznam důvěryhodných adres se mění a je problém s jejich revokováním (tedy odstraňováním již nedůvěryhodných). Dále je problém, pokud se někdo chce nutně připojit z nové lokality (třeba přes GRPS v době výpadku jeho pevné konektivity).

Takovéto "zabezpečení" pouze hází klacky pod nohy tomu, kdo tam chce oprávněně něco dělat.

Mne sa osvedčil denyhost.
Mám zapnúté automatické sťahovanie zozbieraných ip adries z blacklistov.

"Pokud to z nějakého důvodu není možné, nepoužívat ssh přístup k serveru přes účet root, místo toho používat uživatele user a sudo nebo su."

Také jsem to tak před lety používal, ale pak jsem se někde dočetl (a zaboha si nemůžu vzpomenout kde), že z bezpečnostního hlediska je podstatně horší přihlásit se jako user a pak udělat 'su', než přihlásit se rovnou jako root. Šlo nějak o to, že při prvotním přihlášení je heslo přenášeno jiným způsobem než později v 'su'. Že je možné jej sledováním šifrovaného streamu časem získat.

Desifrovat spat SSH session (v rozmunom case) by kompromitovalo cele ssh.

Ja sa na to pozeram tak ze root je na kazdom pocitaci - tak sa mozes pustit do hadania jedo hesla - co ak nahodou je za servrom NBUsr123 alebo nieco podobne neuhadnutelne. Ale uzivatel kvido_zo_zapadakova alebo nieco podobne zmysluplne ta ani ako acount nenapadne.

Proste je horsie hadat username+passwd ako passwd.

Tod moj pohlad preco nie root na verejnom SSH

Nepochopil. Neřekl jsem dešifrovat.
Šlo nějak o to, že v případě prvotního přihlášení odchází vše najednou a přímo heslo v těch datech není. Pokud je dodatečně použito 'su', tak už je heslo součástí streamu. Podle frekvence odesílání dat (tedy úhozů) se pak dá odhadnout minimálně délka hesla. A pokud někdo začíná komunikaci vždy tím, že napíše 'su -', tak možná i něco jiného...
Nechci se ale pouštět do dalších debat, protože si to přesně nepamatuju. Spíš se ten článek pokusím najít, ale zatím se nedaří. Je to přeci jen už minimálně pět let...

Když si pustim screen a pak v něm dávam su nebo sudo, tak datový tok se mění, ale snad ne tolik?

Myslim ze to bolo rozobrane v nejakom phracku. A cital som to tiez - uz je to fakt dost davno. V podstate tam bola pouzita rovnaka myslienka ako teraz pri utoku na SSL technologiu. t.j. ze session by sa mohol lahsie desifrovat pokial je entropia nizka. Co je zo zaciatku dost dobre mozne, pretoze utocnik vie co sa posiela - protokol nepusti.

Osobne neviem v akej forme ssh posiela data na server - hadat neplanujem. Osobne mam root konto priamo cez ssh na kompe co je videt z netu zakazane. K tomu to este bezi na vysokom porte - nech to netrafi kazdy skript.

Session zacinam obvikle tym ze kuknem co sa dialo z apache - k tomu mi stacsia aj zakladne USER_LOGIN prava no a ked chcem nieco potunit tak prepinam cez su na root-a.

„Ja sa na to pozeram tak ze root je na kazdom pocitaci - tak sa mozes pustit do hadania jedo hesla - co ak nahodou je za servrom NBUsr123 alebo nieco podobne neuhadnutelne. Ale uzivatel kvido_zo_zapadakova alebo nieco podobne zmysluplne ta ani ako acount nenapadne.“

A není lepší rootovi nastavit silnější heslo, nebo ještě lépe přihlašování heslem nepoužívat?

Rozdíl v obtížnosti ukradení hesla z TC a v ukradení ssh klíče je značný. SSH klíč je uložen na disku zašifrovaný a i v případě, že používáte ssh agenta tak tento jej klientovi nevydá a místo toho provádí ověření sám, tj. klíč jako takový by neměl jít snadno ukrást.

Firewall je dobré mít nastaven i proto, že jsem viděl snahy o otevření backdoor portu se shelem uživatele apache skrze php xss díru.

Tak si odposlechnu passphrase, kterou je ten klíč zašifrovaný, ne?

„Pokud to z nějakého důvodu není možné, nepoužívat ssh přístup k serveru přes účet root, místo toho používat uživatele user a sudo nebo su.“

A to jako pomůže čemu?

To pomuze tomu, ze uzivatel muci mit klic, pomoci ktereho se prihlasuje, takze se vylucuje moznost bruteforce utoku na heslo roota (ktery neni povolen na ssh) a i na uzivatele (nema heslo, jen certifikat). Samozrejme, a to je v clanku zmineno, je mozne, ze libovolny utok muze provest konkretni uzivatel (at vedome ci ne) - ma pristup k serveru.

Ale root přece taky nemusí mít heslo a může mít jen klíč.

No, tie brute-force utoky sa casto precenuju. Mam ssh na standartnom porte 22 (root nema moznost priameho loginu), kazdy den tak 3-5 utokov a po 5 pokusoch je IP adresa zablokovana v /etc/hosts.deny. Staci ak bezi DenyHosts.

Na tohle pozor. Už jsem se přihlašoval ze sítě (NAT za 1 IP pro více klientů) a nedostal jsem se na ssh. Na vině byl právě DenyHosts, který danou IP zablokoval, protože tam byl nějaký zombie pc. Řešením je skutečně dobře zabezpečit danou službu (přihlašování pomocí klíčů), potom tyto slovníkové útoky nejsou problém.

Ještě tu nepadla metoda port knocking. Používá to někdo? Máte nějaké zkušenosti?

Ano, raz sa to stalo aj mne. Problem s prihlasenim cez kluc je ten, ze sa neprihlasim, ak nemam na lokalnom pocitaci prislusny kluc. To moze tiez skomplikovat situaciu, ak sa potrebujem nutne dostat na server z cudzieho pocitaca (chapem potencialny problem s keyloggermi a pod., ale niekedy to jednoducho pouzit treba).

Ta direktiva bude postačovat, podle dokumentace omezuje (mimo jiné) i php:// a data:// wrapper.

Postačovat nebude, možností útoku je více, byť' některé nejsou tak snadné (např. include uploadovaného souboru a prý nějaký útok pomocí /proc).

Postačuje rozumně nastavený whitelist nebo whitelist znaků.

Víš vůbec o čem je tu řeč? Nemám úplně ten pocit. Include uploadovaného souboru je realizován právě přes onen php:// wrapper. Útok pomocí /proc mi nic neříká - pravděpodobně pokus o přístup k nějakému internímu souboru nebo pipe, což se řeší správným vymezením pravomocí http serveru.

Jinak samozřejmě, kdo sestavuje argument pro include z externích proměnných je kokot, nicméně intervence správce serveru má přece taky své meze - pokud by mi webhostér kecal do toho, jakou množinu vstupů smím použít u té které funkce, tak bych ho hnal svinským krokem.

Ale vím. Include uploadovaného souboru (tím myslím nemyslím tělo požadavku, ačkoli to taky znám a mám úspěšně vyzkoušeno na některých webech) se dá udělat přes /tmp nebo kam se to ukládá. Mám to v laboratorních podmínkách vyzkoušeno. A neměl by to být až takový problém, stačí začít s malým číslem a pak po dvou přidávat, jednou by to mělo vyjít. Není-li na ten server uploadováno každou chvíli, může to být celkem rychlé. (A na sdílených hostinzích to bude ještě jednodušší...)

Útok přes /proc zde nevysypu zpaměti, ale četl jsem o něm na soom.cz a pamatuji si, že něcl takového jde.

A stejně, v každém případě si těžko můžeš být jist, že jsi postihl všechny možnosti. Ale to asi víš (odhaduji z "kdo sestavuje argument pro include z externích proměnných je kokot").

"pokud by mi webhostér kecal do toho, jakou množinu vstupů smím použít u té které funkce, tak bych ho hnal svinským krokem."
Souhlas, toto není věcí webhostéra. Já říkám, že webhostér (nebo obecně správce serveru) se sice může snažit, ale je to spíš jako bonus. (A u general-purpose serverů jako hostingy by to nemělo jít do extrémů, jinak to moc general-purpose není.) Základ je to dobře naprogramovat...

allow_url_include zamezí Remote File Inclusion od PHP 5.2.1, kde zahrnul mj. i php://input - informace v článku je skutečně chybná / zastaralá. Jak ale správně podotýká v6ak, tak nezamezí Local File Inclusion - tomu lze zabránit pomocí open_basedir, mnohem lépe ale samozřejmě lepším návrhem aplikace (to ale není v moci webhostingu).

Tak v obecném případě může uživatel mít možnost nahrát nějaký soubor (vím, tady je další prostor pro bezpečnostní chybu, ale to nemám namysli) a ten pak includovat. Direktiva open_basedir ale může spolu s allow_url_include výrazně omezit možnosti útočníka v praxi a snad v některých případech i zabránit útoku.

Stálo by za zmínku, že AppArmor je parádní hračka nejen pro mass hosting.

Jdou s tím dělat fakt zajímavé věci.

A taky se občas stane, že zajímavě něco nejede a člověk vůbec netuší proč. A v defaultu to rádo spamuje logy. Pak se příjemně čtou.

S tímto nástrojem jsem také nikdy neměl moc trpělivosti. Pro mass hosting je super nástroj mpm_itk. Výhodou je možnost drop-in replacementu apache2_mpm_p­refork.

jj, ale někdy stačí iptables (a jsou účinější než zákaz tunelů v SSH).

1. Dneska už je mnohem lepší na serveru místo apache modulu použít PHP5-FPM, kde PHP5 nemusí běžet s právy webserveru a výkonově je na tom pravděpodobně i lépe.

2. Neplést si suhosin patch a suhosin php modul. Jsou to dvě rozdílné věci (sice od toho samého autora, ale pořád je to něco jiného). Suhosin patch je zakompilovaný přímo v PHP5 (v Debianích a Ubuntu balících) a nelze vypínat/zapínat.

"Patch" je moje (=editorova) chyba, omlouvám se a opravuju.

Díky za upozornění na php5-fpm,já používám pro účely shared hostingu mpm-itk, což dělá podobnou věc a líbí se mi na tom, že to dělá přesně to co mi stačí, u php5-fpm zase bude značný prostor pro optimalizace, například mi přijde jako killer feature php5-fpm ten slowlog - velmi jednoduchá, ale šikovná věc.

Hele, co si myslíte o změně root loginu? Přece superuživatel je ten, kdo má uid #0 a ne podle loginu. To by mohlo i docela řešit již výše zmiňovaný problém s tím, že na 95% serverů lze předpokládat existenci root uživatele a stačí "jenom" hádat heslo. Popravdě nevím, jestli by to nemělo nějaký další dopady na některé systémové služby a rád bych, kdyby se k tomu vyjádřil někdo, kdo se v tom vyzná. Děkuji

1) vzhledem k tomu, že na většině serverů mám zakázané přihlašování heslem a používám klíče, je úplně jedno, jak se jmenuje root :-)

2) v podstatě děláš z jména druhé heslo resp. část hesla, což je nesmysl. Heslo by mělo být dostatečně silné a pak je jedno, že se root jmenuje root. Nebo myslíš, že když ho přejmenuješ třeba na „spravce“, je v pořádku mít slabší heslo?

Nie netvrdim ze login ma byt armorom pre passwd, len tvrdim ze sa mi spi lepsie ked bude utocnik riesit bruteforce attack na zablokovany root account. Po dalsie root account podla mna musi mat za kazdych okolnosti dobre heslo.

Samozrejme ze keby som siel do hlbky a nemal linux/ svoj servrik viac menej pre zabavu tak by som sa prihlasoval cez ssh kluce + heslo. To by podla mna mala byt bezna prax - tak nejako ma to ucili ked som bol mladsi :)

Pokud rootovi nastavíš jako heslo původní_heslo_ro­ota+uživatel_správ­ce, bude to úplně stejné.

Pro upresneni, TC ma uz pres dva roky podporu pro master heslo a skutecny sifrovani hesel. Takze kdo si nechce nechat ukrast hesla kazdym, kdo se dostane k jeho ini souboru, ma moznost.

Přijde mi celkem úsměvné, řešit šifrování hesla někde na klientovi, když potom data, včetně přihlašovacích údajů, lítají internetem nešifrovaná.

Jinak díky za připomenutí.

Ale to je opet volba kazdyho. Stejne jako nemusim pouzit bezpecny ukladani hesel v TC, tak nemusim pouzivat ani FTP s SSL. Ale pokud chci, tak ta moznost existuje.

Mně zase přijde úsměvné řešit nějaké šifrování hesla na klientovi s backdoorem :).

A kde ze se skryva jakej backdoor?

Kauza TC, která proběhla zhruba před rokem, spočívala v tom, že měl webmaster děravý počítač. Dírou se mu tam natáhl backdoor a ten se potom nahrával na weby, které byly uložené v TC.

To jsem videl na vlastni oci, prepisoval htaccess

Takových článku více!

Jinak nevím jak u vás, ale mě to spolehlivě vyřadilo i lighttpd.

pekne citania, vdaka

Dodá'm poznámku o nechtěně sdílených SSH klíčích, byť se to týká spíše nekvalitních VPS: http://www.soom.cz/index.php?name=articles/show&aid=556

+1

jen bych dodal že místo forknutí x ssh procesů by bylo možná čistější použít ssh-keyscan, např. takto:

for i in `seq 2 252`; do ssh-keyscan -T 1 -t rsa AA.BB.CC.$i; done > res

Ve Virtualmasteru je přegenerování ssh klíče součástí firstboot skriptu, takže by se to stávat nemělo. Většina duplicit, kterou jsem odhalil tímto postupem je daná tím, že má jeden stroj skutečně více IP. Našel jsem ale i pár strojů se skutečně duplicitními klíči, patrně vytvořených z chybné šablony.

Jasně, já se s tou prasárnou vypořádal a ve článku jsem byl na tomto místě záměrně spíše stručnější. (Původní varianta byla na tomto místě podrobnější.)

Ale i tak díky, příště to asi použiju.

+1
pekny clanek s konkretnimi pripady a ne jen s teoretickou omackou, vice takovych :)

Tahle adresa neexistuje:
# wget http://mysqltunerl.pl
nastesti je preklep evidentni...

Díky za upozornění, opraveno.

Text odkazu je správně, ale odkaz pořád špatně.

Aktuální verzi Admineru lze stáhnout z http://www.adminer.org/latest.php. Adresa uvedená v článku stáhne bohužel jen stránku s informacemi pro stažení.