Alapvető tanácsok

Egyre többen vannak, akik otthoni környezetben is állítanak össze szervert, akár csak azért, hogy valamit megosszanak az ismerőseikkel FTP-n keresztül, vagy éppen, hogy saját weboldalt üzemeltethessenek. Azt gondolnánk ebben az esetben nincs mitől félni, de sajnos ez nem igaz. Amint a gépünk elérhetővé válik a világhálón, abban a percben rögtön adatcsomagok és kérések százai kezdenek el száguldozni ide-oda. Előbb-utóbb elkezdik felderíteni a nyitott portjainkat is, ezek pedig többet árulnak el rólunk, mint hinnénk. Egy nyitott 22-es port már el is árulja, hogy SSH eléréssel csatlakozhatnak gépünkhöz és legtöbbször nem is kerül sok időbe, míg megjelennek a logban a hibás felhasználónévre/jelszóra utaló távoli bejelentkezési próbálkozások. FTP szerver esetében ugyanez a helyzet. Ha pedig engedélyezve van a root login, akkor pedig szinte biztos, hogy lesz valaki, aki fáradtságot nem ismerve, akár brute force módszerrel megpróbálja majd megfejteni az ehhez tartozó jelszót. Aztán ott vannak még a DDoS támadások, a webszerver gyengeségeit kihasználó sebezhetőségek és még sorolhatnám napestig. Persze ezek legtöbbször a felszín alatt zajlanak, nekünk fogalmunk sincs róla, hiszen ki az, aki egyfolytában a logokat nézegeti. Legtöbbször csak akkor kapjuk fel a fejünket, mikor már megtörtént a baj. Amikor gépünk nem fogadja el a jelszót, képtelenek vagyunk bejelentkezni, vagy ha mégis, akkor azzal kell szembesülnünk, hogy adataink az örök bitmezőkre vándoroltak.

Mit tehetünk ez ellen? Felvesszük a kesztyűt és nekivágunk, hogy bevédjük magunkat. Az első és legfontosabb a jól megválasztott jelszó, főleg az admin felhasználó esetében.

Milyen a jó jelszó?

Kis és nagybetűk, valamint speciális karakterek keveréke. Például: So9@k1 Milyen a rossz jelszó? Kutya, cica, barátnő neve, saját név, admin, administrator, sysadm és minden egyéb kézzel fekvő szó, amit akár még próbálkozás útján is könnyű kitalálni. Ne legyünk lusták, még ha nehezebb is megjegyezni, akkor is fontos, hogy erős jelszót adjunk meg, hiszen ha valakinek sikerül megfejteni, akkor minden további védelem hiábavaló. Hiába van egy áthatolhatatlan fallal körülvett várunk, ha tárva nyitva hagyjuk a kaput. Itt fontos megjegyezni, hogy ne használjuk ugyanazt a jelszót több helyen. Például a MySQL adminisztrációs jelszava és a root login jelszava semmiképp se egyezzen meg. Ha valaki bármelyikhez is hozzáfér az lesz az első, hogy megnézi, hogy máshova „passzol-e”.

Az FTP és a védelem

Szintén alapigazság, hogy minél komplexebb feladatra használjuk gépünket és minél több szolgáltatás fut rajta, annál nagyobb a kockázat is. Fontos, hogy a futtatott programjaink védelmére és finomhangolására is ügyeljünk. Az FTP szerver esetében mindig tiltsuk le a root, valamint az egyéb rendszerszolgáltatások által használt nevek bejelentkezési lehetőségét. Az egy IP-ről való bejelentkezések és bejelentkezési próbálkozások számát csökkentsük le minimális szintre. Egy felhasználónévvel egyszerre csak egy valaki lehessen belogolva. Nem árt, ha korlátozzuk a le/feltöltési sávszélességet is, főleg ha az otthoni netünk alacsonyabb sávszéllel rendelkezik. Ne engedjünk anonymous felhasználónévvel bejelentkezni senkit és a legfontosabb: minden egyes felhasználó csak a saját könyvtárában tudjon böngészni, a szerver felsőbb szintű mappáihoz ne férhessen hozzá. A két bejelentkezési próbálkozás közt eltelt időt is megnövelhetjük, hogy lassítsuk a jelszótörők dolgát.

Egy minta proftpd.conf fájl. Kiragadva a Global szekció:

<Global>
AccessGrantMsg "Gratulalunk %u! Sikeresen bejelentkeztel XY szerverere!"
IdentLookups off
RootLogin off // root login kikapcsolva
DefaultRoot ~ // Csak a saját magához rendelt könyvtárat böngészheti, feljebb nem léphet.
DeleteAbortedStores on // Töröljük a be nem fejezett feltöltéseket.
AccessDenyMsg "Upsz! Ugy tunik valami hiba tortent. Tovabbi informacio: mail@mailod.hu"
TransferRate RETR 512:0 // Sávszél korlátozás
MaxClients 5 "550 Tul sok felhasznalo egy idoben! (Limit=%m)"
MaxClientsPerHost 2 "551 Maximum ket kapcsolat/IP"
DisplayGoAway ""A host elerte a megengedett maximum kapcsolatok szamat. Probald ujra kesobb!""
DisplayQuit ""Viszlat %u!""
RequireValidShell off
</Global>

Mindig legyünk tisztában azzal egy felhasználó hozzáadásakor, hogy mi az, amit engedélyezni szeretnénk neki. Amennyiben azt akarjuk, hogy egy megadott mappához csak FTP-n keresztül férhessen hozzá, akkor ne engedjük máshova bejelentkezni, állítsuk a shell-jét /bin/false-ra.

# useradd -d /home/felhasznalo -s /bin/false -c "Azonosító vagy Név" felhasznalonev
# mkdir /home/felhasznalo && chown -R felhasznalonev /home/felhasznalo && passwd felhasznalonev

A fenti kódsor létrehozza a felhasználót, hozzárendeli a /home/felhasznalo könyvtárat, a shell-t /bin/false-ra állítja, megadhatunk egy azonosítót vagy akár a felhasználó valódi nevét idézőjelek közé. A második sor létrehozza a /home/felhasznalo könyvtárat, hozzáendeli a felhasznalonev-hez, majd ezután kérni fog egy jelszót szintén a felhasznalonev-hez.

Ha viszont mégis szükség van SSH elérésre, akkor egy chroot-olt shell-el megoldhatjuk azt is, hogy a saját könyvtárain kívül ne férhessen hozzá máshoz, ott viszont kedvére ténykedhessen. (Megjegyzés: Az, hogy FTP-n beállítottuk a chroot-ot még nem jelenti azt, hogy itt is! A kettő teljesen különböző dolog.)

SSH

Az alapértelmezett 22-es port helyett megadhatunk egy négy vagy nagyobb számjegyű portot, ezzel kicsit lelassíthatjuk a betörők munkáját. (A 22-es portot tiltsuk le a tűzfalban). Mindenképpen tiltsuk le a root logint.

Szerkesztjük a beállításokat:

# nano /etc/ssh/sshd_config

Port 3145 // Megváltoztatjuk az alapértelmezett 22-es portot.
Protocol 2 // Biztonságosabb protokollra váltunk.
PermitRootLogin no // Tiltjuk a root logint.

Majd újraindítjuk az SSH szervert:

# /etc/init.d/sshd restart

A hozzászólásokban említésre került egy másik módszer is, miszerint teljesen tiltsuk le a jelszavas bejelentkezést és az egész folyamatot kössük certificate-ekhez (tanúsítványokhoz). Sokak számára bevált ez a megoldás is, azonban fontos megjegyezni, hogy ezt az opciót CSAK és kizárólag Debian lenny-n vagy a legfrissebb etch-n alkalmazzuk, ugyanis frissítetlen etch esetén egy biztonsági résnek köszönhetően a támadó könnyedén hozzáférést szerezhet gépünkhöz. A cikk feltételezi, hogy rendszeresen telepítésre kerül minden fontos biztonsági és szoftverfrissítés és nem az elavult, biztonsági kockázatot jelentő verziókat futtatjuk. Ez örök érvényű szabály, mindig a lehető legfrissebb, stabil verziót használjuk.

Tűzfal, nyitott portok, felesleges szolgáltatások

A védekezés legfontosabb alappillére azonban mégis a tűzfal. Anélkül úgy fog kinézni a gépünk, mint egy villogó tábla egy jó nagy „Támadj!” felirattal. Sokan idegenkednek az iptables-től, sokáig én is tartottam tőle, azonban eljött az az idő, amikor félre kellett tennem a félelmemet és használatba kellett vennem. Tapasztalatból mondom, hogy korántsem annyira bonyolult, mint amilyennek tűnik. Megérne egy külön cikket, hogy pontosan hogyan is néz ki egy jól beállított tűzfal, mik is a nélkülözhetetlen szűrési feltételek. (Igény esetén érkezik.) A legalapvetőbb lépés azonban az, hogy minden portot zárjunk le gépünkön, csak azokon engedélyezzük a forgalmat, amelyeken valójában tevékenykedünk.

Itt jegyezném meg, hogy én az nmap nevű kis programot használom arra, hogy a szerverem nyitott portjait áttekintsem. Csomagkezelőből telepíthető és nagyon sokoldalú eszköz. Segítségével fény derülhet arra is, hogy olykor nem is egy olyan program hallgatózik nyitott portokon, amelyeket nem használunk, vagy éppen felesleges biztonsági kockázatokat jelentenek. Ezeket a programokat mindenképpen iktassuk ki, a portokat zárjuk le. (pl: telnet)

A legegyszerűbb nmap parancs, amivel ellenőrizhetjük gépünk nyitott portjait:

# nmap -v -A 127.0.0.1 (vagy tetszőleges IP cím)

Vírusirtás, root kit védelem

Remélem senki nem harapja le a fejem a következő gondolatért, de köztudott, hogy Linuxra jóval kevesebb vírus és kártevő íródott, mint az ablakos riválisára. Ez természetesen nem jelenti azt, hogy nincs és nem is kell védekeznünk ellenük. Ha pedig levelezést is folytatunk gépünkön, esetleg céges szinten, nagyobb felhasználószámmal, akkor elengedhetetlen, hogy a levelek csatolmányait ellenőriztessük valamilyen programmal, hogy ne segítsük elő a kártevők terjedését. Erre való a jól ismert ClamAV.

Telepítsük is gyorsan:

# apt-get install clamav

A vírusdefiníciós adatbázist ezzel a paranccsal tudjuk frissíteni:

# freshclam

Egy megadott könyvtárat pedig így ellenőriztethetünk:

# clamscan -r /home

A másik hasznos kis eszköz az rkhunter nevet viseli. Átfésüli gépünket a jól ismert kártékony rootkitek és biztonsági problémák után kutatva és néhány pillanat múlva tájékoztatást ad gépünk állapotáról.

Ha telepíteni szeretnénk itt az alkalom:

# apt-get install rkhunter

Az ellenőrzést pedig így indíthatjuk el:

# rkhunter -c

Néhány enter leütése után be is fejeződik a folyamat. Ha sok 'OK' feliratot látunk, akkor fellélegezhetünk.

Végül de nem utolsó sorban a /etc/host.conf fájlban helyezzük el a következő sort az IP spoofing megelőzésére:

nospoof on

(IP-Spoofing: IP hamisítás, amikor a támadó olyan forrást szimulál, amelyben megbízik a célgép, és ezáltal a szimulált gépnek megfelelő jogosultságot kap a betolakodó.) Ajánlott még a tűzfal init scriptjében boot alatt bekapcsolni a forráscím hitelesítést is:

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

A cikk még nem ért véget, kérlek, lapozz!