Bezpečnosť Webového Servera Apache

Bezpečnosť Webového Servera Apache

1.Úvod
Bezpečnosť webového servera Apache sa dotýka každého z nás. Pri používaní Internetu si neuvedomujeme, že takmer 54 percent serverov funguje práve na webovom serveri Apache [10]. Bezpečnosť tohto serveru môže mať fatálny dopad na nás, na naše súkromie a bezpečnosť.

Keď si nainštalujeme webový server Apache, otvárame okno do sveta a každý si bude môcť pozrieť informácie na našom webovom serveri. Ak sme si ale webový server Apache nenastavili dostatočne bezpečne, prípadne budeme cieľom vandalov 1, ktorí sa nám budú snažiť dostať na server, tak máme problém. Takýto vandal môže prostredníctvom webového servera napríklad spustiť svoj program na serveri a môže odchytávať citlivé informácie. V prípade, že máme takýto server na osobnom počítači alebo tento server slúži ako proxy, môže útočník odchytiť napríklad vaše heslo od internet bankingu. Aj preto je treba venovať bezpečnosti webového serveru Apache zvýšenú pozornosť.

Vandal, ktorý sa nám snaží dostať do serveru, nemusí byť žiadny odborník. Existujú programy, pomocou ktorých vieme zaútočiť na Apache. Ak nie je na našom webovom serveri nainštalovaný najnovší webový server Apache, tak amatér môže takýto program spustiť a stať sa napríklad super-používateľom. Majiteľ serveru si to ani nemusí uvedomiť a útočník môže odchytávať jednotlivé časti GRID karty 2, prípadne spraviť man-in-middle útok 3 , kedy po určitom čase bude mať k dispozícií časť GRID karty a môže podvrhnúť alebo spraviť nechcený bankový prevod.

Tento projekt sa venuje bezpečnosti webového servera Apache a nielen bezpečnosti, ale aj architektúre a tiež otázke, prečo by sme radšej mali použiť webový server Nginx. Opisuje jednotlivé konkrétne tipy, ako zabezpečiť a ako obmedziť v čo najväčšej miere konanie vandala. Tiež sa bude venovať širším súvislostiam, a to ako po útoku zabrániť v systéme ďalšej zlobe, ktorú môže vandal napáchať.


2. Bezpečnosť Apache
Apache je najpoužívanejší webový server podľa spoločnosti NetCraft [10]. Jeho magická sila a neskutočné rozšírenie spočíva v mnohých vlastnostiach. Nebudem chodiť okolo horúcej kaše, ale prejdem rovno k veci. Nasledujú bezkonkurenčné vlastnosti webového servera Apache.

  • Vysoká konfigurovateľnosť
  • Jednoduchosť konfigurácie
  • Modulárnosť
  • Podpora skriptovacích jazykov

Konfigurovať webový server Apache je naozaj ako rozprávka. Konfiguráciu môžete jednoducho rozdeliť pomocou include na viac súborov a tak si roztriediť napríklad konfiguráciu modulov a virtuálnych domén. Navyše, pri rozdelení fungujú aj značky ako *, čo teda znamená vyber všetky súbory, ktoré sa nachádzajú v ceste.


    LoadModule ssl_module modules/mod_ssl.so

Include /etc/apache2/vhosts.d/*.conf

    ServerName test.domena.sk
    ServerAlias *.test.domena.sk
    DocumentRoot "/home/www/test"
    <directory "=""" home="home" www="www" test"="test"">
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    

Výpis 1: Ukážka konfiguračného súboru Apache



Ako vidíme na Výpise 1, Apache disponuje vlastnosťou naozaj jednoduchej konfigurácie virtuálnych domén. Na riadku 7 definujeme, že do priečinku na riadku 8 pôjdu všetky adresy, ktoré zodpovedajú adrese *.mipa.serverko.sk:80. Každá pod-doména tejto adresy teda skončí v tomto priečinku. Od riadku 9 nasledujú nastavenia prístupu k priečinku. Indexes definuje, že ak nie je vytvorený DirecotoryIndex v priečinku, tak zobrazí formátovaný výstup obsahu priečinku, pričom môžeme tento priečinok prehliadať 4. DirecotoryIndex je miesto v priečinku, kde má Apache hladať súbor, ak používateľ nešpecifikuje adresu 5 . Presnejšie vysvetlenie a viac k problematike je možné nájsť v dokumentácii k Apache projektu [4].

Ak by teda administrátor v kofigurácii nechal možnosť Indexes, vandal má možnosť vidieť súbory, ktoré by inak nevidel a tým administrátor svojou nedbalosťou zvyšuje šance na
kompromitovanie systému.

2.1 Architektúra Apache
Apache spracováva požiadavky od používateľa na úrovni procesov a nití 6. V praxi sa pripojí klient 7 na server a pošle serveru správu GET a za ňou URL adresu, napríklad GET /42.html a server mu odpovie obsahom ako môžeme vidieť na Výpise 2.

dash-pc:~ dash\$ telnet www.serverko.sk 80
Trying 94.229.33.132...
Connected to www.serverko.sk.
Escape character is ’^]’.
GET /42.html

Zmysel Zivota Vesmiru a Vobec
42

Connection closed by foreign host.

Výpis 2: Ukážka požiadavky na Apache pomocou programu telnet



Apache, aby spracoval požiadavku, musí podľa konfigurácie, ako sme si už ukázali, nájsť doménu, podľa nej priečinok a v priečinku nájsť súbor a odpovedať klientovi obsahom súboru. Aby Apache dokázal odpovedať na mnoho požiadaviek súčasne, používa modul súbežného spracovania [8]. V nasledovných sekciách opíšem fungovanie jednotlivých modulov súbežného spracovania.

2.1.1 Prefork
Modul Prefork po príchode požiadavky vytvorí proces s jednou niťou, ktorá obsluhuje požiadavku. V konfiguračnom súbore sa objavuje možnosť MaxClients, pomocou ktorej musíme stanoviť maximálny počet simultánnych požiadaviek 8. Napríklad ak Apache vytvorí 100 procesov, môže obslúžiť simultánne 100 požiadaviek naraz 9 . Ak sa stane havária, tak spadne iba jeden proces a teda sa neobslúži iba jedna požiadavka.

2.1.2 Threaded/Worker
Threaded modul funguje podobne ako Prefork až na to, že proces môže obsahovať viac nití. Podobne ako v Prefork module, Apache potrebuje možnosť MaxClients a ThreadsPerChild. Možnosť ThreadsPerChild určuje množstvo nití pre proces. Ak sa stane havária, spadne jeden proces a všetky požiadavky, ktoré obsluhoval nebudú obslúžené.

2.1.3 Modularita
Jednou z kľúčových vlastností, ktoré som spomínal v úvode, je modulárnosť Apache. Každý modul registruje u Apache svoje funkcie, pomocou ktorých môže vybavovať požiadavky [4]. Napríklad vybavenie požiadavky môžeme vidieť na Výpise 3. Tento modul ochraňuje webový server Apache proti útoku Slowloris, tomuto útoku sa ešte budem venovať.

for (i = 0; i < server_limit; ++i) {
 for (j = 0; j < thread_limit; ++j) {
  ws_record = ap_get_scoreboard_worker(i, j);
  switch (ws_record->status) {
   case SERVER_BUSY_READ:
    if (strcmp(client_ip, ws_record->client) == 0)
     ip_count++;
    break;
   default:
    break;
  }
 }
}
if (ip_read_count > conf->read_limit) {
 ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL, "[client \%s] rejected,
  too many connections in READ state", c->remote_ip);
 return OK;
} else {
 return DECLINED;
}

Výpis 3: Ukážka modulu mod_antiloris [9]



2.2 Architektúra Nginx
Webový server Nginx je založený na udalostiach [3]. Nginx spustí obmedzené množstvo jedno-niťových procesov, ktoré sa nazývajú workeri. V každom workeri môže Nginx obslúžiť
tisícky požiadaviek. Architektúra Nginxu je postavená na myšlienke, aby čakajúce operácie neblokovali iné operácie. Ak vznikne udalosť, môže ju vybaviť jeden z workerov, ak sa teda na niečo čaká, worker môže zatiaľ obsluhovať inú požiadavku a čakanie sa deje na pozadí (a po čakaní sa vyvolá udalosť a worker môže dokončiť požiadavku). Teda operácie sa navzájom neblokujú.

Nginx používa Reactor návrhový vzor 10, kedy čakajúce operácie vybavuje operačný systém. Teda operačný systém môže čakať na niekoľko operácií, bez blokovania procesoru alebo vlákna aplikácie [14]. Pričom, keď sú dáta pripravené na vybavenie, spustí sa udalosť, ktorú už vybavuje Nginx. Obrázok 1 bližšie opisuje návrhový vzor Reactor. V 1. kroku je spustenie event loop, čo je slučka v jednom procese s jednou niťou, ktorá vybavuje udalosti. V 2. kroku program čaká na udalosť od operačného systému. Ak príde udalosť od klienta v 3. kroku, operačný systém túto udalosť (pripravené dáta) rozdelí na udalosti (demux events), ku ktorým je identifikovaný handler, ktorý ich vybaví.

{phocagallery view=category|categoryid=36|imageid=1066}

Obrázok 1: Návrhový vzor Reactor [5]



2.3 Apache verzus Nginx
Apache je procesovo a niťovo orientovaný, preto je obmedzený na vybavovanie požiadaviek iba vrámci jeho vlákien a nití. Týmto prístupom blokuje ďalšie požiadavky, ktoré by mohli byť pri inej architektúre vybavené, napr. Reactor.

Zoberme si štandardnú situáciu, kedy má Apache prednastavenú hodnotu MaxClients na 256 a teda vie vybaviť 256 požiadaviek súčasne. Ak vytvoríme stránku, ktorá obsahuje 50 väčších obrázkov a naše internetové pripojenie je pomalšie (slabý signál WIFI, napríklad mobilné zariadenia, tablety a podobne), vieme počas tejto požiadavky, ktorá môže trvať aj 1 minútu vybaviť len 256 - 50 = 206 požiadaviek. Treba si uvedomiť, že na túto stránku prišiel iba 1 klient. Ak by sme teda mali 5 klientov (slabý signál WIFI, mobilných zariadení, tabletov), server by bol nečinný, sieť by bola priepustná a Apache by nevybavoval požiadavky.

Jedno z riešení je zvýšiť hodnotu MaxClients, tu však narážame na problém, kedy vytvorenie každého ďalšieho procesu so sebou nesie určitý overhead v pamäti RAM. Ak teda zvýšime hodnotu MaxClients, server nám môže začať swapovať pri veľa pomalých požiadavkách. Tu narážame na architektonické obmedzenia webového serveru Apache.

Táto slabina Apache sa dá zneužiť útokom Slowloris 11. Slowloris ako prvé spraví analýzu ako dlho Apache udrží spojenie (KeepAliveTimeout a Timeout), kým môže poslať ďalší bajt informácie (a tak udržať spojenie dlho živé). Potom vytvorí toľko pomalých požiadaviek na Apache, až sa stane nedostupný. Teda v praxi môžeme spustením jednoho programu zhodiť Apache. Existuje modul mod_antiloris, ktorý zabráni tomuto problému, avšak vytvorí ďalší. Príklad implementácie modulu mod_antiloris, môžeme vidieť na Výpise 3. Modul počíta koľko IP adries je pripojených a je v SERVER_BUSY_READ stave. Ak prekročí tento súčet určitú hodnotu, modul mod_antiloris túto požiadavku odmietne. Avšak, ak sme v sieti, ktorá je za NAT s viacerými používateľmi (spoločnosti, obchodné domy, mobilný internet), tak máme problém, pretože tento modul nám naše požiadavky bude odmietať.

Ak by sme takto zaútočili na Nginx, server by stále mohol prijímať a vybavovať požiadavky,
pretože nič neblokuje proces (nemusí čakať), ktorý vybavuje požiadavky.

2.4 Zabezpečenie Apache
Základ pre bezpečie je vo všeobecnosti mať prehľad. Preto by som začal najskôr s dizajnom a tým, ako navrhnúť základnú politiku a ako sa správať. Na Apache chceme prevádzkovať viacero domén. Tieto domény rozdelíme na virtuálne domény a spustíme ich s rozdielnym používateľom (mpm-itk). Treba myslieť na to, že cez aplikácie, ktoré hostujeme na Apache, sa môžu útočníci dostať do systému. Preto je ďalej nutné oddeliť Apache od systému, ako to najviac ide, a použiť mod_security, ktorý umožňuje vytvoriť chroot prostredie. Viac o týchto moduloch v Sekciách 2.4.2 a 2.4.3.


    Order Deny,Allow
    Deny from all
    Options None
    AllowOverride None


    Order Allow,Deny
    Allow from all

Výpis 4: Odmietnutie prístupu pre / v Apache



Ďalším veľmi dôležitým bezpečnostným prvkom je SELinux 12 (Security Enhanced Linux). SELinux je bezpečnostný systém, ktorý umožňuje kontrolovať a riadiť prístup ku rôznym zdrojom. Zdrojom sa rozumie súbory, sokety, porty, pamäť, zásobníky, procesy, služby jadra, systémové volania, zariadenia, súborové systémy a iné [6]. Ide o rozšírenie jadra Linuxu. Viac o tomto systéme v sekcií 2.4.5.

Blokovaním portov pomocou firewallu môžeme tiež zvýšiť bezpečnosť. Vandal nebude mať možnosť po prieniku otvoriť port a páchať ďalšiu zlobu, alebo nebude môcť zneužiť službu, ktorá nie je určená pre verejnosť. Viac o firewalle iptables v Sekcií 2.4.7.

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
iptables -A FORWARD -j DROP

Výpis 5: Zakázanie akejkoľvek sieťovej prevádzky okrem Apache



Fail2ban je program, ktorý podľa logov dokáže prísť na pokus o prienik 13 a túto IP adresu zablokovať na určité obdobie. Pokiaľ vandal zadáva neustále zlé meno alebo heslo, Fail2ban to dokáže detekovať a zablokovať jeho prístup po niekoľkých neúspešných pokusoch. Tiež umožňuje tieto pravidlá definovať a vytvoriť personalizované bezpečnostné automatické pravidlá. Nevýhoda môže byť, že cez zablokovanú IP adresu môže ísť viac používateľov a teda vandal zablokuje prístup na určitý čas aj týmto používateľom. Viac o Fail2ban v Sekcií 2.4.8.

Apache treba pravidelne aktualizovať. Ak pravidelne aktualizujeme, môže sa stať, že po oznámení novej zraniteľnosti nám do aktualizácie ostáva niekoľko dní, čím zvyšujeme riziko napadnutia systému. Preto je nutnosť sa prihlásiť k odberu noviniek, ktoré sa venujú bezpečnosti. Tu nám vzniká ďalšia potreba, ak bude odhalená zraniteľnosť, tak reagujeme najlepšie ihneď. Preto ďalšia potreba je mať administrátora stále na telefóne s prístupom ku konzole (toto je vhodné tiež na riešenie rýchlych úloh so serverom ako pridanie používateľa a podobne).

User apache
Group apache

Výpis 6: Nastavenie používateľa a skupiny pod ktorou beží proces Apache



Čím viac server Apache poskytuje služieb, tým viac zraniteľností môže vandal nájsť. Ak teda nepotrebujeme služby ako CGI (Options -ExecCGI), PHP a iné moduly, je vhodné ich deaktivovať. Navyše, s týmto súvisí skrývanie služieb. Ak nedáme útočníkovi informácie o tom, akú verziu na serveri máme a práve naopak verziu podvrhneme, vandal bude musieť po tom, čo spustí exploit na podvrhnutú verziu zistiť, akú verziu serveru máme naozaj. Konfigurácia skrývania verzie Apache nasleduje.

ServerSignature Off
ServerTokens Prod

Výpis 7: Skrývanie verzie Apache



Používatelia Apache by mali používať HTTPS (mod_rewrite), pokiaľ ide o informácie, ktoré nie sú verejne prístupné. SSL certifikát si môžeme zadarmo zriadiť od spoločnosti StartCom Ltd. na adrese [1]. Toto je z pohľadu najmä používateľa, ale aj nás, pretože administračné rozhranie aplikácie nemusí mať tak silnú ochranu ako verejná stránka a po odchytení hesla je možné spraviť prienik cez toto rozhranie.

2.4.1 Desatoro bezpečnosti Apache

    1. Aktualizácie, sledovanie noviniek, dostupnosť administrátora
    2. mpm-itk
    3. mod_security, mod_evasive
    4. Deaktivácia nepoužívaných služieb
    5. Skrývanie, podvrhnutie verzie softvéru
    6. HTTPS
    7. SELinux
    8. Firewall iptables
    9. Fail2ban
    10. Pivo pre administrátora :)



2.4.2 Modul mpm-itk

      Modul mpm-itk nie je obyčajný modul pre webový server Apache. Tento modul nahrádza časť architektúry Apache a teda miesto Prefork dostaneme mpm-itk. Pracuje podobne ako Prefork, až na to, že pridáva novú funkcionalitu.



      Modul dokáže spustiť vybavenie požiadavky na virtuálnu doménu pod rôznymi používateľmi [7] pridaním konfiguračných atribútov, napríklad do Výpisu 1. Dokonca poskytuje možnosť dynamického priradenia používateľa, ako môžeme vidieť na Výpise 8. S použitím mod_rewrite môžeme takto definovať, že všetky adresy s URL /user/homepage budú spustené pod používateľom user 14 .



RewriteEngine on
RewriteRule /([a-z]+)/ - [E=ITKUID:$1]
AssignUserIDExpr %{reqenv:ITKUID}

Výpis 8: Dynamické priradenie používateľa podľa URL [7]



      Pomocou tohto modulu môžeme tiež obmedziť hodnotu MaxClients pre virtuánu doménu konfiguráciou MaxClientsVHost. Tiež nastaviť nice pre virtuálnu doménu konfiguráciou NiceValue, požiadavkam tak bude prideľované menej času procesora.



2.4.3 Modul mod_security

      chroot je prostredie, v ktorom duplikujeme všetky systémové prostriedky, ktoré potrebuje Apache, a aj samotný Apache. Pomocou modulu mod_security nakonfigurujeme cestu novému chroot prostrediu. Ak by sa teda vandal dostal do takéhoto systému, nezmôže nič iné, okrem poškodenia Apache. Týtmo oddelíme Apache od zbytku systému. Nakoľko vytvorenie chroot prostredia je časovo náročný proces, je vhodnejšie čas investovať do konfigurácie SELinux, pretože SELinux na úrovni jadra oddeľuje služby podobne (viac v sekcií 2.4.5).



      Modul mod_security ďalej umožňuje filtrovať URL (GET a POST). Na Výpise 9 a riadku 6-9 filtrujeme nami definované SQL a tak zabraňujeme útoku SQL injection, ak sa vandal snaží spustiť SQL 15. Riadok 10-11 zabraňuje útoku cross-site scripting, a teda ak vandal cez URL chce vložiť na stránku škodlivý kód 16 . 13ty a 14ty riadok zabraňuje útoku path traversal, vandal tak nemôže zobraziť alebo použiť súbor, ktorý je nižšie v adresárovej štruktúre (nižšie ako tam, kde má prístup) 17 . Tiež môžeme blokovať nevhodné slová v POST na riadku 14. Riadok 15 umožňuje predstierať Apache, že je Microsoft-IIS server verzia 8.0.



SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
SecFilterForceByteRange 0 1337
SecFilterScanPOST On
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
SecFilter "drop[[:space:]]table"
SecFilter "delete[[:space:]]+from"
SecFilter "<script"
SecFilter ""
SecFilter "../"
SecFilterSelective "HTTP_REFERER" "(ufo|pterodactyl|porn)"
SecFilter "POST_PAYLOAD" "(ufo|pterodactyl|porn)"
SecServerSignature "Microsoft-IIS/8.0"

Výpis 9: Ukážka konfigurácie modulu mod_security



      Ak PHP vyhodí chybu Fatal error, mod_security vie toto zachytiť a pred zobrazením chyby používateľovi ho presmerovať na adresu /404.html. Konfiguráciu môžeme vidieť na Výpise 10. Viac informácií o module mod_security môžete nájsť v literatúre [15].



SecFilterScanOutput On
SecFilterSelective OUTPUT "Fatal error:" deny,status:500
ErrorDocument 500 /404.html

Výpis 10: Filtrovanie výstupu Apache modulom mod_security



2.4.4 Modul mod_evasive

      Vyššie som spomínal náchylnosť webového servera Apache na DoS (denial-of-service attack) útoky 18 . Okrem zmiernenia symptómov pridaním cache servera, môžeme použiť modul mod_evasive. Na Výpise 11 môžeme vidieť príklad konfigurácie. Tento modul obsahuje hash tabuľku (o veľkosti DOSHashTableSize), kde má uložené IP adresy, ktoré pristupujú na server. Ak nejaká IP adresa prekročí počet DOSPageCount (rovnaké URL) za DOSPageInterval sekúnd, tak modul bude blokovať IP adresu po dobu DOSBlockingPeriod sekúnd a oznámi to emailom na adresu DOSEmailNotify [16].



DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 60
DOSEmailNotify Táto e-mailová adresa je chránená pred spamovacími robotmi. Na jej zobrazenie potrebujete mať nainštalovaný JavaScript.

Výpis 11: Zabránenie DoS útoku pomocou modulu mod_evasive



      Webový server Apache a Nginx sa tiež môžu správať ako reverzné proxy, a teda rozdeľovať záťaž na jednotlivé webové servery, ktoré môžu zmierniť DoS útok distribuovaným vybavením požiadaviek. Na udržiavanie relácie (session) použijeme Sticky session, a teda požiadavky s rovnakou reláciou vybavuje jeden server. Takéto vybavenie požiadaviek môže byť problém, pretože distribúcia požiadaviek nie je rovnomerná a jeden server môže byť zahltený požiadavkami. Riešením môže byť ukladanie informácií o relácií do databázy a periodicky obnovovať reláciu. Tiež na uchovávanie informácií môžeme použiť cookie. Ak teda do cookie uložíme hash (na základe ktorého spárujeme reláciu), ktorý sa bude meniť pri každej požiadavke, nielen zvýšime bezpečnosť, ale aj úplne obídeme použitie relácií.



2.4.5 SELinux, MAC

      SELinux (Security-Enhanced Linux) sú bezpečnostné moduly, ktoré pridáme do jadra Linuxu 19 [13]. Ide o MAC (mandatory access control) 20 , kedy je bezpečnosť zaisťovaná podľa používateľov, rolí, domén, programov, procesov k súborom, priečinkom, zariadeniam a podobne prostredníctvom jadra. Vždy ide o vzťah objektu (object), ku ktorému chceme získať prístup a predmetu (subject). SELinux predstavuje nový prepínač -Z (–context 21 ), ktorý môžeme vidieť na Výpise 12. Prostredníctvom tohto prepínača môžeme zobraziť používateľa (unconfined_u), rolu (object_r), doménu (home_root_t) a level (s0) pre daný objekt. Treba si uvedomiť, že ako prvé sa kontrolujú pravidlá DAC a až potom pravidlá, ktoré umožňuje MAC. Na Výpise vidíme aj mód SELinuxu (Current mode), ktorý nastavíme v súbore /etc/sysconfig/selinux (alebo napríklad príkazom setenforce 0) 22 .



$ ls -Z .bash_history
-rw-------. dash dash unconfined_u:object_r:home_root_t:s0 .bash_history
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28

Výpis 12: SELinux práva súboru a zobrazenie stavu



      Ak by sme mali proces, ktorý beží pod doménou httpd_t a vytvoríme súbor, ktorý je v doméne samba_share_t, tento proces by nemal mať k súboru prístup. Toto platí iba za podmienok, kedy proces je izolovaný, a teda má rozdielnu confined doménu 23. Politiku SELinuxu manažujeme pomocou programu semanage 24. Na Výpise 13 môžeme vidieť mapovanie používateľa test na SELinux používateľa guest_u. Viacero používateľov môže mať priradeného rovnakého SELinux používateľa. Na riadku 10 nastavujeme do domovského priečinku doménu httpd_sys_content_t, po spustení príkazu umožňujeme používateľovi a procesu s doménou httpd_t (Apache) čítať tento priečinok. Ak by sme teda nastavili virtuálnu doménu na tento priečinok, SELinux by nám to povolil. Riadokom 11 obnovíme politiku adresára.



$ semanage login -a -s guest_u test
$ semanage login -l

Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
test guest_u s0 *

$ semanage fcontext -a -t httpd_sys_content_t "/home/test/web/(/.*)?"
$ restorecon -R -v /home/test/web

Výpis 13: SELinux používatelia



      Pomocou programu semanage 25 môžeme nastavovať rôzne ďalšie parametre SELinuxu, ako môžeme vidieť na Výpise 14. Na riadku 9 je tu príkaz semodule, ktorý zobrazuje jednotlivé použité bezpečnostné moduly. Ak teda nemáme záujem o nejaký modul, spustíme príkaz semodule -r module_name. Moduly môžeme disablovať, aktivovať alebo vytvoriť nové 26.



semanage boolean -l
semanage user -l
semanage login -l
semanage module -l
semanage port -l
semanage interface -l
semanage node -l
semanage fcontext -l
semanage permissive -l
semodule -l

Výpis 14: SELinux príkaz semanage

 

      Ak vznikne problém pri používaní SELinux s prístupovými právami, je dobré vždy sa pozrieť do logov /var/log/messages, /var/log/audit/audit.log a tam hľadať odpoveď a riešenie. setroubleshoot dokonca radí používateľom, aký príkaz majú vykonať. Viac v sekcií 3.1.2.



      Na Obrázku 2 môžeme vidieť kontext SELinuxu. Obyčajní používatelia Linuxu sú mapovaní na SELinux používateľov (môže byť viac Linux používateľov na jednoho SELinux používateľa), ktorí majú svoje role 27, ktoré majú doménu. SELinux nám teda oddelí od seba jednotlivé serverové aplikácie, používateľov a po napadnutí sa vandal nedostane ďalej do systému, čím zabránime získaniu informácií vandalom, zneužitiu ďalších služieb a páchaniu zloby na serveroch, ktoré sú na lokálnej sieti 28 s napadnutým serverom.



2.4.6 DAC

      Štandardné Linuxové práva alebo DAC (discretionary access control), kde nastavujeme súborom, priečinkom, zariadeniam a podobne práva na čítanie, zápis a spustiteľnosť pre vlastníka, skupinu a ostatných. Tiež je možnosť nastavenia sticky bit príkazom chmod +t /tmp. Sticky bit umožňuje v adresároch zmazať súbor alebo priečinok iba vlastníkovi súboru a super-používateľovi (aj napriek tomu, že používateľ má právo zmazať súbor).



      Čítať citlivé súbory ako konfiguráciu alebo spustiteľné súbory webového servera Apache by mal mať právo iba super-používateľ. Výpis 15 ukazuje, ako je možné obmedziť prístup k spustiteľným súborom.



      {phocagallery view=category|categoryid=36|imageid=1067}

 

Obrázok 2: SELinux kontext [12]


chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache

Výpis 15: Práva Apache v Linuxe



2.4.7 Firewall iptables

      Predtým, ako budeme písať o firewalle, by mal každý čitateľ poznať program nmap. Tento program umožňuje skenovať počítač, ktoré služby poskytuje a na základe správania zistiť, o aký operačný systém a verziu služby ide. Ak teda nmap zistí, že na serveri je stará verzia webového server Apache, môže využiť starú chybu a preniknúť do systému. Na Výpise 16 možno vidieť ako jednoducho zistiť verizu Apache (preto by ste mali verziu Apache podvrhnúť a správať sa tak ako MS Windows server). Ak by sme teda simulovali správanie vandala, hneď prvý odkaz na Googli vyhodí zranitelnosti Apache verzie 2.2.3, ktorých je 38 a huncútstvo sa môže začať.



      Ak sa pokúšate testovať správanie vandala, dávajte si pozor. Všetky testy prevádzajte v testovacom prostredí, alebo použite pár zahraničných serverov, cez ktoré pôjdete. Nikto si potom nebude dávať takú námahu vystopovať vás cez 10 serverov po celom svete (vyžaduje veľa námahy a byrokracie). Ak použijete servery, ktoré nelogujú, alebo na nich máte super-používateľa (zahladíte stopy a vymažete všetky logy), tak ste vyhrali, pretože žiadna informácia o tom, odkiaľ vandalizmus išiel, neexistuje.



$ nmap -sV www.strana-smer.sk -p 80
Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-18 20:54 CET
Nmap scan report for www.strana-smer.sk (80.94.52.12)
Host is up (0.024s latency).
PORT
STATE SERVICE VERSION
80/tcp open http
Apache httpd 2.2.3 ((CentOS))

Výpis 16: Skenovanie servera strana-smer.sk

 

      Firewall iptables vie detekovať na určitej úrovni vandalizmus a zablokovať vandala. Konfigurácia iptables funguje ako zoznam, predstavme si, ako postupne iptables prechádza tento zoznam zhora a ak vyhovuje pravidlo paketu, tak sa vykoná požadovaná akcia (povoliť, zakázať, zahodiť a podobne). Preto ak by ste na začiatku zoznamu všetko zablokovali a na konci povolili Apache, iptables by nikdy k pravidlu s povolením neprišiel. Na riadku 1 vo Výpise 17 teda ako prvé vymažeme zoznam pravidiel a na koci zoznamu použijeme reštriktívnu politiku a všetko zakážeme (riadky 11-13). Teda služby, ktoré nemusia byť z Internetu prístupné, necháme zakázané a nebudeme ich explicitne povoľovať.



      Pomocou firewallu môžeme obmedziť pripojenia na server na IP adresu na riadkoch 2-3. Modul conn-limit nepovolí viac ako 2 paralelné pripojenia na port 80 Apache. Na riadkoch 4-7 môžeme vidieť obmedzenie na službu SSH na slovníkový útok 29. Modul limit v našom príklade dokáže obmedziť 3 pripojenia z 1 IP za minútu (limit), pričom ak tento limit nie je dosiahnutý, tak sa limituje podľa počtu počiatočných príchodzích (burst) paketov (limit-burst). Takto teda môžeme obmedziť nielen službu SSH, ale aj Apache a zabrániť tým buď slovníkovým alebo z časti DoS útokom. Riadok 8-10 povoľuje webový server Apache na porte 80.



iptables --flush
iptables -A INPUT -p tcp --dport 80 -m conn-limit --connlimit-above 2 \
  -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp --sport 513:65535 --dport 22 -m limit \
  --limit 3/minute --limit-burst 2 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 --dport 513:65535 -m state \
  --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --syn -s 192.168.100.0/24 --dport 80 \
  -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
iptables -A FORWARD -j DROP

Výpis 17: Politika firewallu iptables



      Ak vieme IP adresu, odkiaľ sa bude k jednotlivým službám pristupovať, je vhodné službu obmedziť na tento rozsah, napríklad -s 192.168.100.0/24 alebo -s 192.168.100.0/255.255.255.0 ako vidíme na riadku 8 vo Výpise 17. Čím viac služby obmedzíme, tým dáme vandalovi menej priestoru k páchaniu zloby. Na Výpise 18 môžeme vidieť použitie modulu nth, kedy každý 4. paket je presmerovaný na iný server. Toto je jeden zo spôsobov, ako distribuovať požiadavky na servery, ktorých služby vybavujú požiadavky rovnako (aby používateľ dostal vždy rovnaký obsah). Viac o tejto problematike nájdete v literatúre [11].



iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 0 -j DNAT --to-destination 192.168.1.10:80
iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 1 -j DNAT --to-destination 192.168.1.20:80
iptables -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -m nth --counter 0 --every 3 --packet 2 -j DNAT --to-destination 192.168.1.30:80

Výpis 18: Distribuovanie požiadaviek pomocou firewallu iptables



2.4.8 Fail2ban

      Fail2ban je program, ktorý beží na pozadí a pozerá v reálnom čase logy aplikácii. Ak nájde v týchto logoch nejaký vzor, ktorý vyhodnotí za útok, zablokuje na určitý čas vandala pridaním pravidla do iptables alebo TCP wrapperu a upozorní admina. Tieto vzory si môže písať aj sám používateľ, a teda Fail2ban sa dá prispôsobiť na akúkoľvek aplikáciu. Fail2ban obsahuje už v sebe ochranu pre Apache, ktorej regulérne výrazy môžeme vidieť na Výpise 19.



      Regulérne výrazy a pravidlá, ktoré sa vyhodnocujú, nájdeme v priečinku /etc/fail2ban/filter.d/, kofiguráciu jednotlivých služieb nájdeme v /etc/fail2ban/jail.conf. Môžeme konfigurovať čas zablokovania používateľa, pridávať ďalšie vzory a email, na ktorý sa odošle pokus o prienik.



[[]client []] user .* authentication failure
[[]client []] user .* not found
[[]client []] user .* password mismatch
^ -.*"(GET|POST).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
[[]client []] File does not exist: .*/~.*
[[]client []] (File does not exist|script not found or unable to stat):
/\S*(\.php|\.asp|\.exe|\.pl)
[[]client []] script ’/\S*(\.php|\.asp|\.exe|\.pl)\S*’ not found
or unable to stat *$
[[]client []] (Invalid (method|URI) in request|request failed:
URI too long|erroneous characters after protocol string)

Výpis 19: Fail2ban regulérne výrazy Apache



3 Napadnutý Apache

      Po prihlásení na server nikdy nevieme, či sme sa stali terčom vandalov. Ak máme podozrenie, musíme predpokladať, že akýkoľvek súbor mohol byť podvrhnutý, aby napáchal ďalšiu zlobu. Preto po každej aktualizácii si vytvoríme md5 kontrolný súčet súborov v systéme a porovnáme s predchádzajúcou verziou. Na Výpise 20 môžeme vidieť na 1. riadku skontrolovanie premennej PATH, aby sme nespustili spustiteľný súbor, ktorý nechceme. 2. riadok ukazuje, že naozaj bola kompromitovaná premnenná PATH z /usr/bin na /usr/fake/bin. Na 3. riadku zmeníme túto kompromitovanú PATH premennú na pôvodné hodnoty. Ďalší riadok kopírujeme predchádzajúci kontrolný súčet, na 6. riadku vygenerujeme nový kontrolný súčet súborov a na 7. riadku ich porovnáme. Od poslednej aktualizácie teda niekto zmenil súbor /etc/my.cnf, kde sa nachádza konfigurácia MySQL servera.



$ export | grep " PATH"
declare -x PATH="/sbin:/bin:/usr/sbin:/usr/fake/bin"
$ export PATH="/sbin:/bin:/usr/sbin:/usr/bin"
$ /usr/bin/scp username@server:/home/username/etc-sum2012-12-15 \
/tmp/etc-sum2012-12-15
$ /usr/bin/find /etc/ -type f -exec md5 {} \; | sort > /tmp/etc-sum2013-01-03
$ /usr/bin/diff /tmp/etc-sum2012-12-15 /tmp/etc-sum2013-01-03
83c83
< MD5 (/etc//my.cnf) = 08cb0fed522c43a1663ece509c7b3852
---
> MD5 (/etc//my.cnf) = d1533210a024e7eb035ffcc1884c8a8f

Výpis 20: Podvrhnuté súbory po útoku



      Toto správanie sa dá jednoducho automatizovať pomocou Cronu, avšak, ak chceme ukladať súbory kontrolného súčtu na nejaký server, vždy nám môže tento server (napríklad služba pastebin.com) vandal napadnúť. Preto ja si tieto súbory odkladám do osobného počítača, ktorý nie je verejne prístupný, neposkytuje žiadnu verejnú službu, pravidelne mení IP adresy a najmä nikto od neho okrem mňa nemá prístupové údaje. Aplikácie, ktoré boli kompromitované postupne zastavujeme, preinštalujeme a konfiguračné súbory vrátime zo zálohy. Ak však bolo kompromitovaných mnoho súborov, vždy je lepšie preinštalovať celý server. Tiež vandal môže urobiť zmeny na úrovni jadra a znemožní vám opraviť škody, ktoré napáchal, vtedy nie je nič jednoduchšie, ako preinštalovať systém.



      Po preinštalovaní služieb a vrátení konfigurácie do pôvodného stavu tu ešte stále môže byť na pozadí proces, ktorý môže páchať zlobu. Preto treba každý proces prejsť a tie, ktoré nepoznáme, zabiť, zmazať ho a jeho súbory a reštartovať server. Súbory, ktoré má proces vandala otvorené, získame spustením programu lsof, ako môžeme vidieť na Výpise 21. Týmto programom môžeme zobraziť vzťah procesu s akýmkoľvek typom Linuxového súboru 30 . Proces nginx na Výpise má teda otvorený svoj binárny súbor, počúva na porte 80, používa knižnicu libcrypt a loguje do súboru /home/web/test/error.log.



$ lsof -c nginx | awk ’{ print $NF }’
/opt/nginx/sbin/nginx
/dev/null
(LISTEN)
/home/web/test/error.log
/usr/lib64/libcrypt-2.16.so

Výpis 21: Časť lsof procesu nginx



3.1 Logy

      Logy servera nám poslúžia na zistenie, čo sa stalo a následné ošetrenie zraniteľnosti, avšak vandal môže tieto informácie podvrhnúť, a teda závisí najmä od toho, ako ďaleko sa dostal 31 . Základným logom, ktorý by mal administrátor pravidelne sledovať, je /var/log/messages. Tam môžeme začať a potom postupne prechádzame a hľadáme chybové hlásenia a anomálie aj v logoch aplikácií 32 .



      V princípe je vhodné sledovať logy čím viac, tým lepšie a získať prehľad, čo sa na serveri deje. Napríklad do Cronu nastaviť pravidlo, ktoré pošle administrátorovi za určité obdobie zaujímavé logy (zahodené pakety, zamietnuté oprácie, error log aplikácií a podobne).



3.1.1 iptables

      Prvým kontaktom s vandalom je sieť, preto je dobré tiež nastaviť logovanie siete. Na Výpise 22 môžeme vidieť nastavenie logovania zahodených paketov. Na 1. riadku vytvoríme LOGGING chain 33 . 2. riadkom zabezpečíme, aby všetky pakety, ktoré prídu, prišli do LOGGING chain. Riadokom 3 zalogujeme paket (–log-prefix) a riadkom 5 ho zahodíme.



iptables -N
LOGGING
iptables -A
INPUT -j LOGGING
iptables -A
LOGGING -m limit --limit 2/min -j LOG --log-prefix \
    "Packet Dropped: " --log-level 7
iptables -A
LOGGING -j DROP

Výpis 22: Logovanie zahodených paketov iptables



3.1.2 SELinux

      Sledovaním logov SELinuxu môžeme detekovať pokus o záškodnú činnosť vandala. Logy môžeme sledovať príkazmi aureport –avc a ausearch -m avc a v súboroch /var/log/messages, /var/log/audit/audit.log. Pomocou programu setroubleshoot môžeme získať viac informácií o akciách SELinux a ich riešenie a tiež, nastaviť odosielanie emailu pri zamietnutí operácie. Setroubleshoot je program, ktorý analyzuje správanie SELinux, ponúka riešenie problémov a notifikuje administrátora.



3.1.3 Systémové prostriedky

      Aplikácie nie sú vždy napísané dobre a je celkom bežné, že nejaká aplikácia sa správa tak, ako by nemala 34 . Preto je vhodné inštalovať nástroj na kontrolovanie a notifikovanie systémových prostriedkov (meranie siete, disku, procesora, portov, služieb a podobne) a niekedy zasiahnuť ručne, čím predísť výpadku. Existuje viacero programov, ktoré toto umožňujú, napríklad Nagios, Zabbix alebo Monit. Ďalej sa však budem venovať programu Emon, ktorého som autorom. Nakoľko jeho konfigurácia je jednoduchá (nevyžaduje zásah do systému, ktorý monitorujeme, teda žiadne inštalácie klientov) a poskytuje všetky služby, pričom nemusíme vedieť programovať a všetko jednoducho nastavíme v jednom XML súbore.



      Emon dokáže monitorovať ping, DNS, porty, URL, CPU, RAM, SWAP, disk, sieť a súbory [2]. Každému serveru, ktorý monitorujeme sa vytvorí na monitorovacom serveri vlákno. Toto vlákno sa prostredníctvom SSH 35 pripája na server, ktorý monitorujeme a vyberie z /proc potrebné informácie. Tieto informácie potom zobrazuje na Curses rozhraní a za každé obdobie odosiela administrátorom grafy vyťaženia servera. Emon umožňuje nastaviť podmienky, kedy odoslať notifikáciu administrátorom, napríklad zaslať notifikáciu, ak na rozhraní eth1 namerá 5 krát veľkosť väčšiu ako 1024 KB/s upload a podobne. Všetky nastavenia pre jednotlivé servery sa dajú nastaviť na mieru. Na Obrázku 3 môžeme vidieť graf, ktorý ukazuje vyťaženie sieťe za posledných 7 dní. Graf pekne reflektuje prevádzku servera cez deň a noc, pričom pred 4 dňami bola špička.



      {phocagallery view=category|categoryid=36|imageid=1065}

 

Obrázok 3: Program Emon, vyťaženie siete [2]



3.2 Analýza v reálnom čase

      Útok sa snažíme detekovať v čo najskoršom štádiu. To zahŕňa analýzu logov a systémových prostriedkov, notifikáciu a použitie nástrojov na analýzu procesov, siete, systémových prostriedkov v reálnom čase. Nasleduje zoznam programov, ktoré umožňujú podrobnú analýzu v reálnom čase.

 

      • Logy sledujeme v reálnom čase pomocou príkazu tail -f /var/log/messages /var/log/audit/audit.log 36.
      • htop umožňuje vidieť vyťaženie CPU, pamäte a disku v kontexte s procesmi (a aj posielať signály procesom) 37.
      • iotop umožňuje vidieť vyťaženie disku (read, write, %) v kontexte s procesmi 38.
      • nethogs umožňuje vidieť vyťaženie siete v kontexte s procesmi.
      • iftop a iptraf umožňujú sledovať vyťaženie siete 39. Môžeme vidieť IP adresy, porty, počet paketov, prenosovú rýchlosť, smer komunikácie.
      • dstat umožňuje vidieť prostriedky systému v kontexte s ostatnými prostriedkami.


Vysvetlivky

      1. Označenie  útočníka, cracker, výtržník, lotor, fiškus.
      2. Nemusí  ísť o GRID kartu, ale akýkoľvek bezpečnostný predmet zadávaný cez počítač.
      3. Útočník môže simulovať správanie banky, a vy nemáte ako zistiť, že naozaj nie ste na stránke banky a komunikácia prebieha prostredníctvom vandala. Vandal môže takto simulovať určité obdobie, až odchytí všetky bezpečnostné predmety a spraví prevod.
      4. Nemôžeme ísť mimo určenej cesty priečinku, napríklad /home/www/serverko/mipa/../secret.txt.
      5. Napríklad ak je DirecotoryIndex nastavený na index.html, adresu http://mipa.serverko.sk/ bude Apache prekladať ako adresu http://mipa.serverko.sk/index.html.
      6. Tiež sa nazýva aj vlákno, po anglicky Thread.
      7. Klient môže byť prehliadač alebo napríklad telnet.
      8. Prednastavene  je táto hodnota 256.
      9. Pri nečinnosti (nie sú požiadavky) tieto procesy zanikajú.
      10. EventMachine v Ruby.
      11. V štandardnej inštalácií webového servera Apache (Linux, Windows), sa mi ho podarilo pomocou útoku Slowloris zhodiť s jedným počítačom! Na operačnom systéme Mac OS útok prednastavene nefungoval, neskúmal som ďalej prečo.
      12. Alebo tiež Mandatory Access Control alebo MAC systém.
      13. Napríklad útoky hrubou silou, slovníkové útoky a iné.
      14. Alebo  napríklad adresa /root/passwd bude spustená pod používateľom root.
      15. Napríklad  máme v URL GET atribút /&name=peter. Ak priamo hodnotu name vkladáme do databázy, vandal môže pozmeniť URL na /&name=peter);DETELE FROM names a my miesto SQL INSERT INTO names (name) VALUES (peter), spustíme SQL INSERT INTO names (name) VALUES (peter);DETELE FROM names. Čím zmažeme celú tabuľku names.
      16. Napríklad pridaním príspevku do fóra vloží javascript, ktorý nás presmeruje na hambatú stránku. Prípadne tú istú stránku, ktorá je podvrhnutá, a vy prihlásením do stránky vandalovi odovzdáte svoje prihlasovacie meno a heslo.
      17. Predstavme si napríklad prehliadač súborov a Apache, ktorý beží pod používateľom root. Vandal tak môže jednoducho vypísať akýkoľvek súbor na disku. Ale ak mu zabránime dostať sa nižšie v adresárovej štruktúre, môže zobraziť len to, čo je vyššie. Napríklad ak máme prehliadač súborov v priečinku /var/www/ nemôže zobraziť súbor /etc/passwd, ale súbor /var/www/1337.txt zobraziť môže.
      18. Distribuovaný útok, kedy niekoľko počítačov sa snaží neustále pripájať na server, čím mu vyčerpá buď sieťové prostriedky (priepustnosť siete, vyčerpanie MaxClients) alebo týmito požiadavkami zníži jeho výkon tak, že nemôže vybaviť ďalšie požiadavky.
      19. Politika SELinuxu narozdiel od Linuxu je odlišná v tom, že SELinux prednastavene všetko zakazuje a povoľuje iba to, čo si používateľ explicitne definuje.
      20. V Linuxe je prednastavene DAC (discretionary access control). V DAC je bezpečnosť zdrojov (súbory, priečiny, sieť, zariadenia a podobne) zaisťovaná iba prostredníctvom vlastníctva týchto zdrojov (user, group). Napríklad pri použití DAC ignorujeme dôveryhodnosť programu, kedy napadnutý nedôveryhodný program môže získať prístup do systému.
      21. Pre procesy ps -eZ, pre používateľa id -Z, pre otvorené porty netstat -tlnpZ.
      22. Mód umožňuje vypnúť SELinux (disabled), alebo iba zobrazovať varovania a logovať (permissive), alebo zapnúť politiku SELinuxu (enforcing).
      23. Doména unconfined_t povoľuje všetko, a teda sa aplikujú DAC pravidlá.
      24. Nainštalujeme v Linuxe Fedora príkazom yum install policycoreutils-python.
      25. Pre viac informácií pozrite manuálové stránky man semanage.
      26. Moduly sú binárne súbory umiestnené v priečinku /etc/selinux/targeted/modules/active/modules/ a majú príponu pp.
      27. Role môžeme vnímať ako úlohy.
      28. Tieto servery väčšinou nemajú takú ochranu, ako servery, ktoré sú vystavené Internetu.
      29. Počítače podľa slovníka náhodne skúšajú často používané prihlasovacie mená a heslá. Preto by ste mali službu SSH obmedziť iba na prihlásenie cez certifikát a zakázať prihlasovanie prostredníctvom hesla.
      30. Pre viac informácií si prečítajte dokumentáciu man lsof.
      31. Ak používate na logovanie server, ktorý neumožňuje upraviť logy po pridaní, vandal by musel zaútočiť na logovací server, aby ich upravil a vám tak znemožnil analýzu. Útok na logovací server môže byť podstatne ťažší. Teda oddeliť logovanie od služieb je ďalšia vrstva bezpečnosti.
      32. Napríklad webový server Apache /var/log/apache2/error_log a databáza MySQL /var/log/mysql/mysqld.err.
      33. Zoskupenie pravidiel.
      34. Napríklad aplikácie na mieru.
      35. Emon podporuje prihlásenie heslom, certifikátom, alebo certifikátom s heslom.
      36. Všimnime si, že môžeme paralelne sledovať niekoľko logov. Akonáhle sa do logu pridá nový riadok, program tail tento riadok ihneď zobrazí aj s označením súboru logu.
      37. Napríklad proces vyťažuje prostriedky celého systému alebo DoS útok.
      38. Napríklad proces je veľmi spomalený, pretože pracuje s pokazeným diskom alebo detekcia covert channel :)
      39. Napríklad server odosiela SPAM alebo warez.




Literatúra

      1. StartSSL - The Swiss Army Knife of Digital Certificates & PKI. URL http://www.startssl.com/
      2. Emon - Remote server monitoring application. 2013. URL http://sourceforge.net/projects/emon2/
      3. Amy Brown, G. W.: The Architecture of Open Source Applications, Volume II. 2012, ISBN 9781105571817. URL http://www.aosabook.org
      4. The Apache Software Foundation: Apache HTTP Server Documentation. 2013. URL http://httpd.apache.org/docs/
      5. Frank Buschmann, D. C. S., Kevlin Henney: Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, Volume 4. Wiley, 2007, ISBN 978-0-470-05902-9. URL http://books.google.sk/books?id=WVQF2PK2tlgC&printsec=frontcover#v=onepage&q&f=false
      6. Gentoo Foundation, Inc.: SELinux Gentoo Documentation. 2013. URL http://www.gentoo.org/proj/en/hardened/selinux/
      7. Gunderson, S. H.: The Apache 2 ITK MPM. 2011. URL http://mpm-itk.sesse.net/
      8. Kabir, M. J.: Apache Server 2 Bible. Wiley, 2002, ISBN 0764548212. URL http://www.amazon.com/Apache-Server-Bible-Mohammed-Kabir/dp/0764548212
      9. Monshouwer, K.: mod_antiloris. July 2010. URL http://mod-antiloris.sourceforge.net/
      10. Netcraft: Web Server Survey. March 2013. URL http://news.netcraft.com/archives/2013/
      11. Netfilter: Documentation about the netfilter/iptables project. 2013. URL http://www.netfilter.org/documentation/index.html
      12. Raphaël Hertzog, R. M.: The Debian Administrator’s Handbook Edition 1. 2012, ISBN 979-10-91414-00-5. URL http://debian-handbook.info/browse/stable/
      13. Red Hat: Fedora Documentation. 2013. URL https://docs.fedoraproject.org/en-US/index.html
      14. Schmidt, D. C.: Reactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events. ISBN 0-201-6073-4. URL http://www.cse.wustl.edu/~schmidt/PDF/reactor-siemens.pdf
      15. Thinking Stone: ModSecurity for Apache User Guide. 2006. URL http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/modsecurity-manual.html
      16. Zdziarski, J.: What is mod_evasive? 2010. URL http://www.zdziarski.com/blog/?page_id=442



Fotogaléria:

      {phocagallery view=category|categoryid=36|limitstart=0|limitcount=3}