Szerverünk alapvető biztonsága és naplózása 1. rész

Az internet térhódításával és a programok sérülékenysége miatt egyre több támadás érheti szervereinket. Teljes biztonság és védelem nem létezik, de törekednünk kell arra, hogy a lehető legkisebb felületet biztosítsunk egy-egy támadásra.

Mivel nem tudunk a nap 24 órájában a gép előtt ülni és reagálni, ezért fontos, hogy olyan rendelkezzünk olyan alkalmazással, ami dönt és reagál helyettünk. A támadások szinte bármelyik protokollon keresztül érhetnek bennünket, de tapasztalataink szerint a legtöbb támadási kísérlet weboldalon keresztül, majd ssh-n keresztül történik. Ezután próbálkoznak még mindenféle porton bejutni: smtp, imap, pop3, ftp, dns és az összes nyitva lévő porton.

A támadok legtöbbször egy-egy program sérülékenységét használja ki, ezért is fontos, hogy ezek az alkalmazások mindig frissek és mindig biztos forrásból származzanak. A legtöbb linux disztribúció folyamatosan biztosítja ezeket a security frissítéseket, de mindeközül is kitűnik az arch linux a rolling release-el. A rolling release lényege, szemben a pl. az ubuntu LTS vagy fél évente kiadott verzióval, hogy ezeknél nincs igazi "kiadás", hanem mindig a legfrissebb csomagokat tartalmazzák ugrade, vagy disztribúció frissítés nélkül is. Ez is hozzásegített ahhoz, hogy a főbb szervereken lecseréljem az Ubuntut Arch Linuxra. Az itt bemutatott parancsok emiatt is Arch Linuxra lesznek érvényesek, de magák a programok/csomagok ugyanúgy megtalálhatóak Ubunut alatt is.

Az Arch Linux alapértelmezett pacman csomagkezelője helyett én a yaourt-t használom, mert ez képes közösségi repókban lévő csomagokat is keresni és telepíteni is.

A logok elemzésén, folyamatos figyelésén alapúl a fail2ban és az sshguard. Bár a fail2ban ugyanúgy ellátja az sshguard feladatát, egy fontos különbséget találtam. Az sshguard képes jobban kiszűrni a notórius próbálkozókat így ezt egy nagyobb bantime-al jutalmazza (akár hetekre, hónapokra).

Telepítésük egyszerű:

# yaourt -Ss fail2ban sshguard

A szolgáltatást engedélyezzük, hogy következő boot során automatikusan elinduljon:

# systemctl enable sshguard
# systemctl enable fail2ban

Ahhoz, hogy már most aktiválva legyenek, el kell őket indítani:

# systemctl start fail2ban
# systemctl start sshguard

Ezután az iptables -L parancs kiadásával láthatjuk a létrehozott IP-szabályokat, mint pl:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
sshguard   all  --  anywhere             anywhere
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-apache (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

Chain sshguard (1 references)
target     prot opt source               destination

A ban lista most még üres (szerencsére), ami azt jelenti, hogy nem próbálkoztak, vagy nem fut még annyi ideje a program, hogy ki tudja szűrni a támadásokat. Az alapkonfiguráció a fail2ban esetében is csak az ssh-ra korlátozódik, de számos program logjában tud filterezni. Alapműködése ugyanis az, hogy folyamatosan elemzi a különböző logokat egy python script és, minden gyanús tevékenységhez tartozó IP-t banra tesz. Minden egyes programnak saját configja van, ahol megadhatóak a logok útvonala, illetve egy regexp listában, hogy mik azok a gyanús tevékenységek, amiket figyelnie kell, ezáltal saját filtert is tudunk írni. Az sshguard configja ettől jóval egyszerűbb, mivel csak az ssh-t figyeli, és nem logokat elemez.

Szokták még használni a psacct-t vagy ubuntus nevén acct-t is, aminek akkor van értelme, ha a felhasználónak shell accoutja van, és úgy akarjuk megfigyelni, hogy milyen folyamatok tartoznak hozzá. Erre én a whowatch nevű programot szoktam inkább használni.

Egy korábbi blogomban már említettem a snoopy nevű programot, ami a felhasználói aktivitást monitorozza az auth.logba. Ez a megoldás tökéletes lehet akkor, ha pl. az apache cgi scripteket futtat, vagy python scriptek futnak. Ez egyben persze legnagyobb hátránya is, hogy minden fileművelet bekerül ide, és a logunk egy nap akár 500Mb is lehet. Emellett egy majdnem tökéletes megoldást biztosíthat számunkra - feltéve, ha bash-t használunk -, ha a profile fájlba beteszünk egy trap-t, ami logol minden konzolon kiadott parancsot a syslogba. Erről szintén az előbb említett blogban lehet olvasni.

A logwatch-ra akkor lehet szükség, ha nem szeretnénk minden egyes napunkat azzal kezdeni, hogy átnyálazzuk a logokat. Nagy forgalmú szerver, és/vagy több szerver esetén erre rá is mehet a napunk. Ehelyett ez a kis program elvégzi helyettünk az elemzést. Attól függően, hogy milyen alkalmazások vannak feltelepítve a szerverre, képes azokat a logok alapján felismerni és elemezni, majd ezekből egy szép kis statisztikát készíteni és elküldeni azt a megadott e-mail címekre. Több rendszergazda esetén, több szem, többet lát alapon. A konkrét támadási kísérletet ugyan nem tudja megakadályozni, de jól jön, ha legalább látjuk, hogy hol, hogyan próbálkoztak bejutni és meg tudjuk tenni a szükséges lépéseket az elhárításra.

A logwatch kapcsán, amire még nem sikerült megoldást találnom, az amavis új logformátumának lekezelése. Sajnos a logwatch nem tudja értelmezni az amavis bejegyzéseit a mail.log-ban, ezért a napi statisztikában szépen ezeket "értelmezhetetlen" jelzővel ellátva meg is kapjuk.

A részben a restricted shellekről fogok írni, és megmutatom, hogy én melyik mellett döntöttem.

Kategória: