Komentáře k článku

Základní zabezpečení LAMP serveru

Články - - Různé -

S rozšířením VPS a podobných služeb se stále častěji stává, že se o webový server stará ten, kdo k tomu má ve firmě nejblíž, tedy nějaký správce sítě (to bývá ten lepší případ) nebo vývojář. V článku si ukážeme základní metody zabezpečení LAMP serverů, takový základní bezpečnostní check list…

Zpět na článek

59 komentářů k článku Základní zabezpečení LAMP serveru:

  1. Jenda

    Re: 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ěží?

    Odpovědět
    1. ad

      Re: Základní zabezpečení LAMP serveru

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

      Odpovědět
      1. Heron

        Re: Základní zabezpečení LAMP serveru

        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).

        Odpovědět
    2. Dan7

      Re: Základní zabezpečení LAMP serveru

      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.

      Odpovědět
      1. Martin Třinec

        Re: Základní zabezpečení LAMP serveru

        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.

        Odpovědět
        1. patrik.sima

          Re: Základní zabezpečení LAMP serveru

          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…

          Odpovědět
          1. Martin Třinec

            Re: Základní zabezpečení LAMP serveru

            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!

            Odpovědět
      2. Heron

        Re: Základní zabezpečení LAMP serveru

        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.

        Odpovědět
        1. Dudo

          Re: Základní zabezpečení LAMP serveru

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

          Odpovědět
    3. JirkaS

      Re: Základní zabezpečení LAMP serveru

      „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.

      Odpovědět
      1. tomo

        Re: Základní zabezpečení LAMP serveru

        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

        Odpovědět
        1. JirkaS

          Re: Základní zabezpečení LAMP serveru

          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…

          Odpovědět
          1. V.

            Re: Základní zabezpečení LAMP serveru

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

            Odpovědět
          2. tomo

            Re: Základní zabezpečení LAMP serveru

            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.

            Odpovědět
        2. Jenda

          Re: Základní zabezpečení LAMP serveru

          „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?

          Odpovědět
    4. Josef Liška

      Re: Základní zabezpečení LAMP serveru

      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.

      Odpovědět
    5. bambas

      Re: Základní zabezpečení LAMP serveru

      „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.

      Odpovědět
      2. MartinX

        Re: Základní zabezpečení LAMP serveru

        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.

        Odpovědět
        1. Heron

          Re: Základní zabezpečení LAMP serveru

          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.

          Odpovědět
          1. tdvorak

            Re: Základní zabezpečení LAMP serveru

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

            Odpovědět
          2. MartinX

            Re: Základní zabezpečení LAMP serveru

            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).

            Odpovědět
  2. DoubleThink

    Allow_url_include omezuje i php:// a data:// wrapper

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

    Odpovědět
    1. v6ak

      Re: Allow_url_include omezuje 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ů.

      Odpovědět
      1. DoubleThink

        Re: Allow_url_include omezuje i php:// a data:// wrapper

        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.

        Odpovědět
        1. v6ak

          Re: Allow_url_include omezuje i php:// a data:// wrapper

          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…

          Odpovědět
    2. Jakub Vrána

      Re: Allow_url_include omezuje i php:// a data:// wrapper

      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).

      Odpovědět
      1. v6ak

        Re: Allow_url_include omezuje i php:// a data:// wrapper

        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.

        Odpovědět
  3. Martin Hruška

    AppArmor

    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.

    Odpovědět
    1. patrik.sima

      Re: AppArmor

      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.

      Odpovědět
    2. Josef Liška

      Re: AppArmor

      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.

      Odpovědět
  4. shade

    PHP5-FPM a Suhosin

    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.

    Odpovědět
    2. Josef Liška

      Re: PHP5-FPM a Suhosin

      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.

      Odpovědět
  5. Dragonn

    Co změna loginu roota?

    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

    Odpovědět
    1. František Kučera

      Re: Co změna loginu roota?

      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?

      Odpovědět
    2. tomo

      Re: Co změna loginu roota?

      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 :)

      Odpovědět
    3. Jenda

      Re: Co změna loginu roota?

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

      Odpovědět
  6. Sob

    Hesla v TC

    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.

    Odpovědět
    1. Heron

      Re: Hesla v TC

      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í.

      Odpovědět
      1. Sob

        Re: Hesla v TC

        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.

        Odpovědět
          1. Jenda

            Re: Hesla v TC

            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.

            Odpovědět
  7. patrik.sima

    Díky za článek

    Takových článku více!

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

    Odpovědět
    1. Josef Liška

      Re: SSH klíče

      +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.

      Odpovědět
      1. v6ak

        Re: SSH klíče

        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.

        Odpovědět

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3551