Dotaz: LAMP - administrace a bezpecnost

[petrfm]

Ahoj, pred lety jsem instaloval LAMP na server, kde mam nejake aplikace na hrani, ale ted bych chtel jednu appku vystavit ven, cili se da cekat nejaky potencialni utok. Na tom serveru je vice aplikaci, vsechny bezi pod www-data skupinou a userem, coz asi neni takovy problem, ne? V pripade utoku se lupic dostane do adresaru vedlejsich aplikaci, je to tak?

Ale at se do toho nezamotam, existuji nejaka obecna pravidla, jaka pridelovat opravneni, jak nastavit jmena a hesla u mysql,atd? Instaloval jsem to jako naprosty zelenac, takze jsem mel treba k mysql heslo roota jen "", atd. Potreboval bych to projit a odstranit tyhle boty, at mi prvni pokus o utok neroznese server na kasi

Nemate tip na nejaky hezky clanek? Vsechny co jsem nasel, se tykaji vesmes instalace skrze CLI a zakladni konfigurace, ale malo ktery se zabyva bezpecnosti, nikde jsem necetl nejake zdurazneni, ze kazda aplikace by mela mit extra uzivatele a pristupove udaje do databaze, aby v pripade zneuziti jednoho skriptu, nemohl pachatel vysosat celou databazi, atd.

Je mi jasne, ze to je na precteni knizky o administraci linuxu, presto si myslim, ze LAMP je celkem bezna vec, takze by ta pravidla sly shrnout do par vet, nebo se pletu? Chtelo by to proste nejaky seznam moznych chyb, ktery bych prosel, zkontroloval, odskrtal si je a byl trochu klidnejsi

Diky, P.

Odpovědi

[Filip Jirsák]

by ta pravidla sly shrnout do par vet, nebo se pletu?

Pletete se.

Neexistuje nic jako „obecná bezpečnost“, bezpečnost se vždy týká konkrétní situace a záleží na kontextu. Proto neexistuje žádný univerzální návod „jak nastavit LAMP bezpečně“. Ostatně kdyby nějaké takové obecné zabezpečení existovalo, bylo by to výchozí nastavení těch aplikací.

Určitě používejte aktuální verze všech aplikací, nastavte bezpečná hesla. Nejkritičtějším místem ale budou ty nainstalované aplikace. Pokud se útočník skrze nějakou aplikaci dostane do systému, dostane se tím i do těch sousedních aplikací. Ale nejen to. Pokud dokáže pod tím účtem www-data spouštět svůj kód, stane se útočník lokálním uživatelem. A zabezpečit počítač proti útokům lokálního uživatele je úplně jiná liga než pouhé zabezpečení proti vzdálenému útoku. Také bezpečnostních chyb, které může zneužít lokální uživatel, je statisticky daleko více.

[petrfm]

Aha takze mi vlastne vubec nepomuze, mit pro kazdeho virtualhosta extra pristup do DB, protoze kdyz se dostane na uroven wwwdata, tak si proste projde okolni adresare a stahne soubory conf.php, kde ta pristupova data ma jak na taliri, je tak? Takze vlastne nejaka extra snaha o izolaci php aplikaci je marna, pokud jedna bude derava, ostatni jsou pristupne taky.

Nebo se da kazdy virtualhost spoustet pod extra userem? neni to paranoidni? ma to vyznam? a je to slozite?

[Jendа]

Aha takze mi vlastne vubec nepomuze, mit pro kazdeho virtualhosta extra pristup do DB, protoze kdyz se dostane na uroven wwwdata, tak si proste projde okolni adresare a stahne soubory conf.php, kde ta pristupova data ma jak na taliri, je tak?

Ano.

Takze vlastne nejaka extra snaha o izolaci php aplikaci je marna, pokud jedna bude derava, ostatni jsou pristupne taky.

Můžeš mít pro různé věci fastcgi procesy pod různými uživateli s tím, že adresáře s ostatními weby nebudou pro ně čitelné. Co se stane, když útočník získá toho uživatele… děj se vůle boží. Osobně by mě zajímalo, jak tohle dělají velké hostingy.

[petrfm]

No na hostingu ma podle mne kazdy ucet pristup jen do sveho adresare a kazdy ma svou databazi a sveho uzivatele. Otazka je, jak je to udelano realne. To se spousti xKrat apache? Neni v php nebo apache nejaka direktiva, ktera zakazuje skriptu pristup mimo, nebo nad svuj pracovni adresar? Pokud nekdo naboura apache, tak je asi pruser vzdycky, ale proti chybam ve skriptech by to mohlo pomoct.

V podstate tam nejake omezeni byt musi, protoze jako klient hostingu se skriptem nedostanu nad svuj pracovni adresar k vedlejsimu klientovi. Musi tam byt moznost nejakeho jednoduche omezeni Pak jsou v podstate moji virtualhosti v apache takovi "jedinecni platici klienti".

[petrfm]

http://navody.c4.cz/safe_mode

hmm, opan_basedir a safemode jsou ty kouzla, ktere hledam Na chyby v php to sice asi nepomuze, ale tech je urcite mene, nez chyb ve scriptech Pak mi tedy staci, pouzivat jednoho uzivatele, jen si definovat basedir pro kazdeho virtualhosta a asi si nadefinovat pro kazdeho hosta a jeho databaze extra uzivatele v mysql. Pak bych mel byt v bezpeci, pokud jde o zneuziti php aplikace, je to tak?

[Jendа]

safe_mode bylo z PHP odstraněno.

[Jendа]

No na hostingu ma podle mne kazdy ucet pristup jen do sveho adresare a kazdy ma svou databazi a sveho uzivatele.

Pak je problém jak jsem říkal já a Filip Jirsák - zabezpečit systém přes lokálním uživatelem je ještě těžší.

To se spousti xKrat apache?

Ne, proč? Apache jenom servíruje statické soubory, tam snad není moc co řešit. Chceš sandboxovat PHP, a to jde buď tak, že spustíš pro každého uživatele fastcgi server, nebo ho používáš jako klasické CGI (což je pomalé).

Neni v php nebo apache nejaka direktiva, ktera zakazuje skriptu pristup mimo, nebo nad svuj pracovni adresar?

Podle všeho je PHP tak děravé, že tohle omezit nemůže. Pokoušel se o to ten safe_mode a nefungovalo to tak moc, že to radši zahodili.

V podstate tam nejake omezeni byt musi, protoze jako klient hostingu se skriptem nedostanu nad svuj pracovni adresar k vedlejsimu klientovi.

Jak kde. Zkoušel jsi tam nahrát třeba nějaký PHP shell?

[petrfm]

Pockej, lokalni uzivatel se ale prece skrze php skript nemuze dostat do systemu, ne? Pokud nemam vubec nainstalovany funkce typu shell_exec, atd. Nebo myslis tema dirama v php? To uz je trochu scifi, tomu asi nezbranim nijak, ja se chci branit zneuziti systemu napadenim jedne php aplikace a pristupem do dalsich.

Pokud je php derave, je to stejne, jako by bylo derave ssh a vubec cokoliv, co umozni eskalaci prav a prevzeti vlady nad systemem, tomu se nejde vyhnout Ale vhodnym nastavenim PHP snad muzu minimalizovat sanci, ze mi nekdo verejne znamou chybou zastarale opensource php aplikace rozlozi server na prvocisla.

[Filip Jirsák]

Pockej, lokalni uzivatel se ale prece skrze php skript nemuze dostat do systemu, ne? Pokud nemam vubec nainstalovany funkce typu shell_exec, atd.

No právě, pokud tam nemáte žádnou funkci nebo jejich kombinaci, která by umožnila spustit kód. O to se pokoušeli přímo autoři PHP jako o safe_mode, a nikdy se jim to nepodařilo.

Ale vhodnym nastavenim PHP snad muzu minimalizovat sanci, ze mi nekdo verejne znamou chybou zastarale opensource php aplikace rozlozi server na prvocisla.

Můžete tak PHP nastavovat, ale nikdo vám na to nedá návod krok za krokem, protože vždy záleží na prostředí, v jakém to PHP běží. Na druhou stranu to také není tak, že ať uděláte sebevíc, stejně první člověk, který se na daný web podívá, hned získá roota. Každopádně bych se snažil co nejvíc omezit na straně operačního systému, kde ty bezpečnostní mechanismy přeci jen fungují docela spolehlivě. Tj. každou aplikaci spouštět pod samostatným účtem, ten aby měl minimální práva k zápisu i ke čtení, ideálně aby nemohl spouštět žádné jiné programy. Do databáze také každá aplikace svůj účet, který bude mít oprávnění jen k tomu, co aplikace potřebuje, atd.

[petrfm]

Diky moc za odpoved, ale popravde, vubec netusim, jak spustit kazdou webovou aplikaci pod jinym uctem, jsem rad, ze mi apache a php bezi pod tim jednim jak rikam, bezpecnost jsem zacal resit prave vcera, do te doby jsem byl rad, ze ten system bezi a moc jsem na nej nesahal )) Poradil byste, co mam pohledat v google, abych se dopidil nejakeho navodu, jak to rozchodit oddelene?

Mam takovy pocit, ze to nebude dlouho trvat a kazdy web se bude spoustet jako extra kontejner virtualky to je asi idealni stav, ze? Jen zatim chybi nejaky jednoduchy zpusob, jak na par kliku, nebo prikazu klonovat servery s LAMPem a nejakou reverzni proxy nad nimi.

[Denny]

spousteni cgi pod různými user:group per virtualhost:

LoadModule suexec_module        lib/apache/mod_suexec.so
##nezapomenout "globlani nastaveni apache aby nebezel pod rootem,...
User http
Group http

Značka VIRTUALHOST není povolena! (lol) Takže posílam bez,.. no prostě to má být virtuálhost

        ServerName myhost
        ServerAlias  www.myhost
        DocumentRoot /home/www/vhosts/myhost/htdocs

        SuexecUserGroup myhost myftp


        php_admin_value open_basedir /home/www/vhosts/myhost/htdocs
        php_admin_value upload_tmp_dir  /home/www/vhosts/myhost/tmp

nejaka dokumentace http://httpd.apache.org/docs/current/suexec.html#usage

[Jendа]

Značka VIRTUALHOST není povolena! (lol)

Ale tak admin webserveru by mohl umět escapovat HTML ;)

< > se escapuje pomocí &lt; a &gt;

[petrfm]

Aha, tak jestli je to takhle jednoduche a zalezitost konfiguraku jednotlivych virtualhostu v apache, pak si dovedu predstavit, ze to takhle delaji i ty velke hostingy, to se da asi pomerne snadno naskriptovat.

BTW : nemas tam preklep, nema byt misto

SuexecUserGroup myhost myftp

SuexecUserGroup myhost http

Jak to pak je s opravnenim jednotlivych slozek? Jaky ma byt group a user? Group http a user host? A povolit cteni a zapis cele skupine, nebo jen uzivateli?

[petrfm]

Našel jsem ještě tohle, taky zajímavé, co myslíte? Těch možností je asi více.

https://petrhlozek.cz/apache-a-nastaveni-prav-pro-virtual-hosty/

BTW :Zrovna se pídím po tom, jak zjistit, pod jakym userem bezi apache, delam to tak dobre?

petr@ubuntuserver:~$ ps aux | grep apache
www-data  2866  0.0  0.4 366128 10100 ?        S    06:44   0:00 /usr/sbin/apache2 -k start
www-data  2867  0.0  1.7 393748 36456 ?        S    06:44   0:00 /usr/sbin/apache2 -k start
www-data  2868  0.0  0.4 365840  8996 ?        S    06:44   0:00 /usr/sbin/apache2 -k start
www-data  2869  0.0  0.4 365864  9244 ?        S    06:44   0:00 /usr/sbin/apache2 -k start
www-data  2870  0.0  0.4 365840  8996 ?        S    06:44   0:00 /usr/sbin/apache2 -k start
www-data  3879  0.0  0.4 365864  9780 ?        S    08:36   0:00 /usr/sbin/apache2 -k start
www-data  3880  0.0  0.4 365620  9000 ?        S    08:36   0:00 /usr/sbin/apache2 -k start
petr      7174  0.0  0.0   9492   900 pts/0    S+   14:49   0:00 grep --color=auto apache
root     23867  0.0  0.8 365404 17548 ?        Ss   Dec26   0:03 /usr/sbin/apache2 -k start

proc tam je ten root? Muze to byt proto, ze mam v systemu webmina a on si spousti svou instanci?

[source]

Ano, musím napsat, že něco takového taky postrádám. Všude je instalace LAMPP, přístup do databáze atd. řešen přes root a hloupé hesla bez vysvětlení, jak by se to mělo dělat lépe. V návodech se prakticky neřeší oprávnění a SQL injection. Hlavně, že to funguje... A pak to vypadá, jak to vypadá.

[petrfm]

Zejo? vsechno clanky pro nadrzene zacatecniky a potom uplyne rok, dva a zacatecnik je sice stale zacatecnikem, ale zacne si uvedomovat, ze mit v mysql jmeno root bez hesla asi neni uplne super a spoustet apache a php pod rootem taky nebude idealni. Proste by stacilo shrnout tech par pravidel, jako vytvorit extra ucty, PROC je vubec vytvarim (tohle vysvetleni, ze jde predevsim o bezpecnost tutorialy taky dost flakaji) a ze pokud nejake funkce php nepouzivam, mel bych jich povolovat co nejmene. Zminku o basedir jsem nikde nenasel a to je pritom asi zaklad, ktery se da udelat pro to, aby to bylo trochu bezpecne.

[Max]

Hmm, já to řeším tak, že co web, to db, php spouštím přes fastcgi a suexec. Takže co web, to jiný uživatel (+ lze nastavit i různé php pro různé weby, popř. i jiné věci, než jen php). Když někdo získá přístup k nějakému webu, tak má přístup jen do db toho webu a jen do souborů toho webu. Dále se pak zabezpečuje běh fastcgi, ošetřují se handlery proti podvržení jiných scriptů apod. Kdo nepotřebuje různé verze php a chce jen použít jednu verzi php, tak se z hlediska výkonu vyplatí nasadit nějaké řešení v rámci apache a php a neřešit to oklikou přes fastcgi.
LAMP je hodně komplexní záležitos, která se může nastavit různými způsoby, což určuje konkrétní řešení/požadavky. Další problém je, že co nová verze apache/php, to větší, nebo menší změna.
Jako každé jiné řešení je tedy potřeba jej pochopit a pak jde vše snadněji.
Pokud hledáš nějaké obecné řešení, tak viz třeba ispconfig. Je zdarma a z něj pak můžeš vypozorovat, jak to řeší on. Navíc k němu existuje aktuální dokumentace/instalační návody pro více distribucí.
Zdar Max

[petrfm]

Vzdycky jak zahlednu nejake klikatko, rikam FUUUJ a pak otevru nahledy a strasne se mi to libi Problem je, ze to cloveka nic nenauci. Navic, jak je treba ten ispconfig bezpecny? Neni to zase dalsi dira do systemu? Ale vypada to moc hezky, na jeden klik basedir, chroot, volba zda php bezi jako fastcgi, atd. Jednoducha sprava emailovych schranek. Ja ale neposkytuji hosting, mam jen svuj pidi servrik, kde si testuju nejake aplikace, takze bych to asi nevyuzil, mozna, kdybych presel z hostingu na VPSku, tak uz by to bylo jine, nez se porad hrabat v konfiguracich. Ale jak rikam, bojim se, ze tyhle klikatka jsou dira do systemu. Otazkou zustava, zda spatna konfigurace zacatecnikem neni mnohem horsi dira

[petrfm]

Trochu odbocim - uz dlouho touzim po tom, mit na serveru lokalni MAIL server s IMAP pristupem, ktery by stahoval vsechny mozne schranky na hostingu, seznamu, apod. a ladoval zpravy do lokalni slozky, kde mam neomezeny disk. V podstate takove moje velke uloziste posty, abych nemusel resit quoty na jednotlivych hostinzich a abych mohl pristupovat ke vsem schrankam pres jeden login (tridily by se treba do slozek). Odtud bych si je prochazel roundcubem, thunderbirdem, nebo z mobilu. Vim, ze je treba dovecot, fetchmail, atd., ale nakonfigurovat to a spravovat pres CLI je pro mne nocni mura. Divam se, ze tohle vsechno ISPConfig umi, jako klikatko. Mas s nim realne zkusenosti? Je to dobry napad, pouzit ISPconfig k nastaveni a sprave takoveho postovniho serveru? Nebo je lepsi, dat si tu praci a rozchodit to na urovni jednotlivych sluzeb a jejich konfiguraku? Libi se mi, ze si zridim nekde schranku, nebo neco zmenim, tak nemusim na SSH a do konfiguraku, ale jednoduse tu zmenu provedu pres klikatko.

[petrfm]

Ted jsem si vyzkousel ze srandy jednu vec. Nahral jsem na server do extra slozky php filemanager a spustil. Ihned mi vyhodil kompletni adresarovou strukturu vc. adresaru "nad nim". A jako perlicka je funkce SHELL, kdy funguju v bashi pod userem www-data a mam volne pole pusobnosti. Takze utocnikovi vlastne staci, kdyz nekam propasuje svuj script podobny tomuto php filemanageru a muze si s linuxovym strojem delat co chce, resp. co mu dovoli user www-data.

Takze mezim zapnout basedir a omezit exec Je fajn, zit v sladke naivite a pocitu bezpeci, kdyz si clovek rozchodi LAMP podle tutorialu

[Jendа]

Problém je v tom, že kromě execu musíš zakázat i spoustu dalších (a užitečných) funkcí, u kterých bys to třeba ani neřekl. Třeba bzip. (ok, to už opravili, ale takových překvapení tam prostě bude spousta)

[petrfm]

Safemode and open_basedir are flawed by design and will always have security holes like this one (or all the local exploits we demonstrated). The security of your server setup should therefore NEVER rely on these directives.

Hustééé takže PHP je prostě díra jako do (_!_) a nic jiného, než striktní izolace tomu nepomůže. Je fajn, nastavit si basedir, když útočník si pak teda ty okolní adresáře pošle zkomprimované ))

[Václav "Darm" Novák]

Takze utocnikovi vlastne staci, kdyz nekam propasuje svuj script podobny tomuto php filemanageru a muze si s linuxovym strojem delat co chce, resp. co mu dovoli user www-data

Nejenom může, ono se to tak běžně děje :) To se nám takhle na webu objevil záhadný skript navíc… A on to phpfm.

[Josef Kufner]

Pokud to chceš (jakš takš) jisté, tak každou aplikaci nainstaluj do samostatného kontejneru. Pak chyba v aplikaci zpřístupní jen ten kontejner, související databázi a všechno, kam jinam to ještě má přístup.

[lertimir]

Pro začátečníka (a mnohdy i jako kontrola pro profesionála) jsou dobré auditní programy jako je lynis nebo OpenVAS.

[lojza]

nebylo by lepsi hodit si tu jedinou aplikaci co potrebujes vystavit ven na nejaky lepsi hosting kde nad tou bezpecnosti uz premejsleli trosku vetsi profici nez jsem ja sam ted i kdybych nad tim sedel dalsich 5 let, navic budou asi sledovat secunii apod. a reagovat na to ? event. vychazet spise z predpokladu, ze mi tam uz nekdo vnikl a prizpusobit se nejhorsimu scenari s cilem minimalizovat skody .. ?

[petrfm]

rekl jsem to blbe. Nechci tim samozrejme suplovat hosting, i kdyz jedna appka, pristupna z venku mi tam bezi, ale mam omezeny pristup pres htaccess na IP, ktere vyuzivam, takze tam se o bezpecnost tolik nebojim.

Chtel jsem tam ale testovat napadeny skript a tak jsem si uvedomil, ze jsem dosud nejak neresil tyhle potencialni rizika, takze i kdyz to je server jen na hrani, chtel bych ho mit aspon elementarne zabezpeceny. Nejvic jsem se zapotil, j\kdyz jsem zjistil, ze mam do DB usera root a bez hesla, to byl dira jak do (_!_), i kdyz z pohledu zjisteneho, existuje dalsich asi x der, implementovane do php jako ficury, takze zadne drama Spis tenhle topic docela zmenil muj dosud veskrze nadseny pohled na PHP jako takove.

Vsechno je to o tom, ze se neustale ucim, casem treba poridim VPSku misto sdileneho hostingu a zase tyhle vedomosti zuzitkuju, takze vsem dekuji za podnety a dobre rady, cenim si jich.

[lertimir]

Podle mne se na to díváš špatně. Jednak je dobré si uvědomit, že aktuální webserver s dobře naprogramovanou aplikací je "bezpečný". Do uvozovek to dávám proto, že samozřejmě může existovat 0-day zranitelnost, kterou někdo použije a nebo chyba v PHP aplikaci. V prvé řadě je třeba server bránit tady. Tedy aktualizaci serveru a správným programováním.

A následně je třeba analyzovat, jakou škodu může útočník dosáhnout, když zranitelnost využije. a proti rozsahu škod se dále chránit. Ten root do DB bez hesla je v této kategorii.

[petrfm]

No ja nevim, ale vzdy jsem si myslel, ze je lepsi, poridit si domu trezor a predpokladat, ze se muze nekdo vloupat, takze si cennosti schovat do nej a nenechat je valet na stole, uklidneny tim, ze mam nejmodernejsi zamek, kdyz zlodej muze treba rozbit okno, nebo vyuzit toho, ze zapomenu zamknout.

Navic, i pet vterin aktualni system mi nevyresi problem s deravou php aplikaci, takze je treba je od sebe izolovat. Z toho co pises, mi vyplyva, ze ten root bez hesla do mysql nebyla az takova tragedie. Ale ve chvili napadeni jedne aplikace uz v podstate nemam co chranit, kdyz utocnikovi staci nahrat adminera a stahne si celou DB na jeden klik. Pokud nepouzivam basedir, pak i komplet cely webovy server.

Tohle je vec, o ktere jsem se v zadnem tutorialu o zprovozneni LAMP na linuxu nedocetl. Pritom se da predpokladat, ze aplikace v php jsou derave jak cednik a server by to proste mel ustat

[Filip Jirsák]

s dobře naprogramovanou aplikací … nebo chyba v PHP aplikaci

No právě. Vždyť i masově nasazované redakční systémy jako WordPress, Drupal nebo Joomla se předhánějí, kdo bude mít dřív nějakou bezpečnostní chybu. Jak potom asi vypadají aplikace, které nejsou tak sledované? Bohužel v PHP komunitě je bezpečnost evidentně dlouhodobě velmi podceňovaná, o čemž svědčí jak dlouholeté pokusy o čtverhrané kolečko v podobě safe_mode, než konečně přiznali, že to nikdy nefungovalo a fungovat nemůže, nebo „pokrokové“ diskuse o tom, jak správně escapovat data pro SQL, místo toho, aby se programátorům neustále vtloukalo do hlavy, že uživatelský vstup do SQL příkazu nikdy, opravdu nikdy nepatří, a vždy se předává pomocí bindingu parametrů. Nesouhlasím s těmi, kdo na základě programovacího jazyku šmahem odsoudí nějaký program, ale ta záplava novinek, v jaké další PHP aplikaci byla opět nalezena zranitelnost SQL injection, je pozoruhodná. Takže pokud má tazatel nějaké aplikace, které na tom serveru prostě mají běžet, a nic bližšího o nich neví, měl by bohužel být připraven na nejhorší.

[petrfm]

Takže pokud má tazatel nějaké aplikace, které na tom serveru prostě mají běžet, a nic bližšího o nich neví, měl by bohužel být připraven na nejhorší.

No právě... když si napíšu aplikaci o dvou řádcích, kde nepoužívám ani DB, bát se nemusím, ale jakmile nainstaluji blbý wordpress, nemám klidné spaní. Myslel jsem, že na aplikaci, kde se publikuje jedna tabulka z databáze není co zkur... ale nasazení WP mi otevřelo oči. Dělal jsem na tom dvoustránkové weby a plácal se do stehen, jak je to easy a rychlé. Dnes mi připadá, že se raději vrátím zpět ke statickým stránkám, protože ty můžu spustit a zapomenout, WP je miminko, o které se člověk musí téměř denně starat.

Resumé tedy je, že pokud použiju suexec a nadefinuji si unikátní uživatele pro moje "kritické" projekty a potom třeba jednoho na pokusy, měl bych být relativně v suchu a pokusná, děravá aplikace by neměla ohrozit mé kritické projekty, je tak?

[Filip Jirsák]

Ještě je rozumné nějak limitovat zdroje aplikace – bez toho pořád hrozí, že útočník vaši kritickou aplikaci sice neovládne, ale ta pokusná aplikace spotřebuje všechny dostupné zdroje a ta kritická aplikace se nedostane ke slovu.

[lertimir]

Dnes mi připadá, že se raději vrátím zpět ke statickým stránkám, protože ty můžu spustit a zapomenout,

Podle mne na nic co ma vnejsi konektivitu admin nemuze spustit a zapomenout. V cemkoliv se muze objevi chyba. Pokud pouzivam WP tak potrebuji mit proces, jak v casovem intervalu radove hodin reagovat na zverejnenou chybu a opravu. Ale stejne to potrebuji mit i na primo apache. je fakt ze apache ma mene zranitelnosti nez WP, ale musim to mit poreseno.