Debian rendszerünk biztonsága

  • (f)
  • (p)
Tudástár – Írta: | 2009-12-11 12:57

...avagy védekezni fontos.

Kulcsszavak: . linuxdebianubuntubiztonságvédelem

[ Új teszt ]

Bevezető

Természetesen akár lehetett volna az is a cím, hogy (Linux) rendszerünk biztonsága, de mivel az itt szereplő példákat konkrétan Debian alatt üzemeltem be, ezért azt hiszem így a korrekt. Ennek ellenére természetesen a rövid kis leírásomban található módszerek egyéb Linux disztribúciókra is megtalálhatók/felpakolhatók, a tippek, tanácsok globálisan értendők. A bemutató korántsem teljes, mindössze egy rövid kis betekintést szeretnék nyújtani azon módszerek felé, amiket jómagam hasznosnak vélek, és amik sokszor megkönnyíthetik az életünket és megszabadíthatnak a nem várt hajtépésektől. Amennyiben igény lesz rá, úgy folytatás is készül majd, persze szigorúan konyhanyelven, úgy, hogy bárki megértse, azok is, akik még csak most ismerkednek a pingvines rendszerrel, de szeretnék magukat és az adataikat biztonságban tudni.

Tehát Debian. Akik kicsit is járatosak az informatika világában, azok körében nem hiszem, hogy magyarázatra szorulna ez a név. Széles körben ismert, ingyenes, GPL licensz alatt futó Linux disztribúció, főként szerver célú felhasználása miatt vált ismertté, de az otthoni, desktop rendszerek terén sem okoz csalódást, hiszen gnome felhasználói felülettel rendelkezik. A Debianra épül a mindenki által jól ismert Ubuntu is (tehát az itt szereplő programok is működni fognak Ubi alatt is.) Jelenleg az 5.0-ás verziószámnál tartanak, ez a „lenny” kódnevet kapta, én viszont még az egyel régebbi, 4.0-ás „etch” verziót használom. Ez azonban nem jelent kompatibilitási problémát, ami egyiken fut, az szinte minden esetben tökéletesen működik a másikon is, ha mégsem, akkor egy kis buherálás után azonban biztosan. Legyen szó akár otthoni, egyszerű „LAMP” (Linux-Apache-Mysql-PHP) szerverről, akár profi, céges megoldásról, mindkét esetben ideális választás lehet a fentebb említett rendszer, hiszen ingyenes és az egyik legnagyobb támogatói, valamint fejlesztői bázissal rendelkezik és nehezen futni olyan problémába, amelyre ne lenne megoldás alatta. Egy dolog azonban biztos: Bárhol és bármilyen célra is üzemeltetünk szervert, a biztonságra mindig nagy hangsúlyt kell fektetnünk, ugyanis támadási felület mindig van. Ez pedig egyet jelent azzal, hogy csak idő kérdése, míg valaki fel nem fedezi, és ki nem használja azt. Tökéletes védelem nem létezik, de igyekeznünk kell minimálisra csökkenteni a biztonsági kockázatokat. Ehhez szeretnék néhány alap, majd néhány komplexebb tippet és megoldást adni a folytatásban.

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

Apache webszerverünk védelme

mod_evasive

Előbb vagy utóbb szinte mindenkit megtalálnak az Apache webszerverre irányuló DoS támadások, abban az esetben pedig jóval több félnivalónk van, ha több oldalt is üzemeltetünk, esetleg webhosting célra használjuk szerverünket. Ilyenkor egy, vagy több gépről annyi lekérdezést küldenek a webszervernek, hogy az teljesen felemészti az erőforrásait, és ezért a látogatók számára lassan, vagy egyáltalán nem lesz elérhető az oldalunk. Ennek a problémának az enyhítésére született meg a mod_evasive névre hallgató Apache modul. Hatékonysága abban rejlik, hogy képes felismerni ezeket a kéréseket és eldobja a felesleget, tehát nem szolgálja ki mindet.

Telepítése:

A telepítés menete:

apt-get install libapache2-mod-evasive

Majd kell egy log könyvtár:

mkdir -p /var/log/apache2/evasive

és ezt tegyük írhatóvá:

chown -R www-data:root /var/log/apache2/evasive

A következő sorokat pedig a httpd.conf filehoz kell adni:

DOSHashTableSize 3097
DOSPageCount 6
DOSSiteCount 100
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 600

Majd indítsuk újra az Apache-ot:

# /etc/init.d/apache restart

mod_security

Ez a beépülő modul egy komplett védelmi alkalmazás, egy mini tűzfal, melynek segítségével szinte az összes fontosabb támadási felület és forma kivédhető. Azonban komplexitása és bonyolultsága miatt most nem fejteném ki részletesebben, ugyanis a leírás majdnem olyan hosszú lehetne, mint ez a cikk maga.

Akik mégis szeretnék kipróbálni azoknak itt egy HowtoForge leírás a használatáról és üzembe helyezéséről: [link]

A folytatásban pedig következzen néhány hasznos program.

Fail2ban

A program egyszerű és mégis nagyszerű. Elemzi a rendszer és a főbb szolgáltatások logjait, ezekben megadott mintákra keres, például azokra, amikor valaki helytelen névvel/jelszóval próbál bejelentkezni. Megadott sikertelen próbálkozás után pedig automatikusan hozzáadja a támadó IP címét az iptables (vagy egyéb tűzfal) ban listájához, ergo nem fog tudni többet próbálkozni addig, míg le nem telik a kitiltás ideje, amit szintén mi szabunk meg. Ideális a brute force betörések megelőzésére. Sokan azt hiszik elég csak az alapértelmezett portokat áthelyezni, de ez csak ideig-óráig megoldás, hamarosan újra fognak kezdődni a támadások.

A támogatott programok, melyek logjait elemzi: sshd, apache, qmail, proftpd, vsftpd, wuftpd, postfix, couriersmtp, sasl

Telepítés Debian alatt mindössze csak ennyi:

# apt-get install fail2ban

Természetesen lehet kódból is fordítani, az pedig ITT érhető el.

Ezután nincs is más dolgunk, mint átfutni az alapvető beállításokat és megadni, hogy mire szeretnénk aktívvá tenni a figyelést:

# nano /etc/fail2ban/jail.conf

ignoreip = IP vagy DNS, amelyet hagyjon figyelmen kívül, 127.0.0.1 értelemszerűen
bantime = az idő, amire bannolásra kerül az IP. Legyen 900
maxretry = a sikertelen próbálkozások száma, ami után kiosztásra kerül a ban. Legyen 3
destemail = érvényes e-mail cím

Lentebb görgetünk és elkezdődik a figyelni kívánt folyamatok listája. Amit monitorozni szeretnénk, annál az „enabled” után levő „false” szót cseréljük ki „true”-ra. Természetesen nem kell mindent bekapcsolni csak azt, amit telepítettél és használsz. Ha megvan, akkor mentsd el a változtatásokat (ctrl + o) majd indítsd újra a Fail2ban-t.

# /etc/init.d/fail2ban restart

A program működését figyelemmel kísérheted, ha a /var/log/fail2ban.log fájlt megnyitod. Amennyiben tisztességesen teszi a dolgát ilyesmit kell látnod:

2009-12-06 19:44:55,850 fail2ban.actions: WARNING [ssh] Ban 80.16.181.212
2009-12-06 19:59:55,889 fail2ban.actions: WARNING [ssh] Unban 80.16.181.212
2009-12-06 20:42:16,986 fail2ban.actions: WARNING [ssh] Ban 83.13.245.58
2009-12-06 20:57:17,098 fail2ban.actions: WARNING [ssh] Unban 83.13.245.58
2009-12-07 13:48:50,582 fail2ban.actions: WARNING [ssh] Ban 83.170.106.142
2009-12-07 14:03:50,673 fail2ban.actions: WARNING [ssh] Unban 83.170.106.142

A program tudása nem ér véget itt, a vállalkozó kedvűek saját szűrési feltételeket is hozzáadhatnak, így szinte mindegyik program logjának figyelésére képessé válik.

PSAD (Port Scan Attack Detector)

Segítségével blokkolni tudjuk a port szkenneléseket (nmap), figyeli a gyanús hálózati forgalmat, elemzi a tűzfal és a rendszer logjait, beállításoktól függően közbeavatkozik. (Megjegyzés: Amennyiben nem szimpatikus, vagy nem sikerül működésre bírni valamiért, akkor használhatjuk a portsentry nevű programot is, ugyanerre a célra készült és talán valamivel kisebb az erőforrásigénye is.)

Telepítés:

# apt-get install psad

Kiadjuk a következő parancsot:

# echo -e ’kern.info\t|/var/lib/psad/psadfifo’ >> /etc/syslog.conf

Újraindítjuk a logolásért felelős rendszert:

# /etc/init.d/sysklogd restart
# /etc/init.d/klogd

Végrehajtjuk a szükséges módosításokat a psad konfigurációs fájljában:

# nano /etc/psad/psad.conf

EMAIL_ADDRESSES e-mail címed;
HOSTNAME géped hostja;
HOME_NET NOT_USED;
IGNORE_PORTS udp/53, udp/5000; (portok, amelyeken nem végzünk figyelést)
ENABLE_AUTO_IDS Y;
IPTABLES_BLOCK_METHOD Y; (bekapcsoljuk az automatikus bannolást)

Újraindítjuk a psad-ot:

# /etc/init.d/psad restart

Bekapcsoljuk az iptables tűzfalban a logolást:

# iptables -A INPUT -j LOG
# iptables -A FORWARD -j LOG

Ha mindent sikeresen végrehajtottunk, akkor lekérjük a statisztikát:

# psad –S

Ilyesmit kell látnunk:

[+] psadwatchd (pid: 2540) %CPU: 0.0 %MEM: 0.0
Running since: Sun Jul 27 07:14:56 2008

[+] kmsgsd (pid: 2528) %CPU: 0.0 %MEM: 0.0
Running since: Sun Jul 27 07:14:55 2008

[+] psad (pid: 2524) %CPU: 0.0 %MEM: 0.8
Running since: Sun Jul 27 07:14:55 2008
Command line arguments: -c /etc/psad/psad.conf
Alert email address(es): mail@mailod.hu

src: dst: chain: intf: tcp: udp: icmp: dl: alerts: os_guess:
117.32.xxx.149 xx.22.zz.121 INPUT eth0 1 0 0 2 2 -
118.167.xxx.219 xx.22.zz.121 INPUT eth0 1 0 0 2 2 -
118.167.xxx.250 xx.22.zz.121 INPUT eth0 1 0 0 2 2 -
118.167.xxx.5 xx.22.zz.121 INPUT eth0 1 0 0 2 2 -
122.167.xx.11 xx.22.zz.121 INPUT eth0 4642 0 0 4 50 -
122.167.xx.80 xx.22.zz.121 INPUT eth0 0 11 0 1 2 -
123.134.xx.34 xx.22.zz.121 INPUT eth0 20 0 0 2 9 -
125.161.xx.3 xx.22.zz.121 INPUT eth0 0 9 0 1 4 -
125.67.xx.7 xx.22.zz.121 INPUT eth0 1 0 0 2 2 -

Netfilter prefix counters:
"SPAM DROP Block": 161519
"Drop Syn Attacks": 136

Total scan sources: 95
Total scan destinations: 1

Total packet counters:
tcp: 5868
udp: 164012
icmp: 2

DDoS Deflate

A DoS és a DDoS (Distributed Denial of Service) másnéven szolgáltatás megtagadásos támadások ma már szinte mindennapossá váltak. Többféle formája létezik, olykor csak egy bizonyos gép támad, vannak esetek viszont, amikor azonos időben akár több száz IP címről is érkeznek olyan csomagok (pl: SYN) vagy ICMP (ping) kérések, amik ellehetetlenítik az egész gép vagy bizonyos szolgáltatás működését. Néha elég csak kitiltani a támadó IP címet, viszont sokszor ez nem lehetséges, főleg nem nagyobb botnetek és zombi hálózatok esetében. Ilyenkor szoftveres szinten szinte lehetetlen védekezni a támadás ellen. Azonban ezek ellenére is meg kell próbálnunk felállítani egy alapvető védelmet a gyengébb intenzitású DoS és DDoS támadások ellen. A legfőbb segítségünk a tűzfal, amelyhez több olyan szabályt is hozzáadhatunk, amivel szűrhetjük az egy időben, egy IP címről történő SYN, FIN, ACK stb csomagok számát.

Persze létezik erre a problémára egy apró program is, ez pedig a DDoS Deflate. Megadott időközönként lefutva vizsgálja, hogy egy IP címről hány csatlakozás érkezik gépünkre, ha pedig túl magas ez a szám, akkor az az IP tiltásra kerül.

Telepítsük:

# wget http://www.inetbase.com/scripts/ddos/install.sh
# chmod 0700 install.sh
# ./install.sh

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

# nano /usr/local/ddos/ddos.conf

Ezt az értéket 0-ra állítjuk, így az iptables tűzfalat fogja használni a program bannolásra.

APF_BAN=0

Megváltoztatjuk az e-mail címet:

EMAIL_TO="mail@mailod.hu"

Elmentjük a beállításokat (ctrl + o) és kész is.

A program valójában nagyon egyszerűen működik, ezt a kódot futtatja le időszakosan (cronjob):

# netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Ha bemásoljuk a terminálba magunk is láthatjuk a kimenetét és az aktuális csatlakozások számát IP-kre szűrve. Amelyik IP előtt 100 fölötti szám látható az már kezdhet gyanús lenni.

Végszó, konklúzió

Az itt bemutatott tippek és programok segítségével egy komoly lépést tehetünk rendszerünk és adataink biztonságának megőrzése felé. Persze egy otthoni kis letöltő vagy webszerver esetében felesleges az itt felsorolt összes lehetőséget alkalmazni, de nem árt tisztában lenni vele, hogy mi is a teendő, ha esetleg elér minket a baj. Ahogy korábban is írtam, tökéletes védelem nincs, de törekednünk kell rá. Ne tároljuk gépünkön banki fiókunk jelszavát és eléréseit, a számunkra különösen fontos és értékes információkat rendszeresen archiváljuk, írjuk lemezre és ne engedjük ki a netre. Azt is fontos megjegyezni, hogy mindez mit sem ér, ha őrizetlenül és jelszó mentesen hagyjuk ott a gépünket, amikor elugrunk valahova. Legyünk körültekintőek, óvatosak, olykor nem árt a paranoia sem.

A fentebbi programok mind kis erőforrás igényűek, egyik sem terheli le a gépet, tehát használatuk akkor is javasolt, ha gyengébb vassal rendelkezünk.

Előfordulhat, hogy hibát vétettem valahol a cikk írása közben, ezért előre is elnézést kérek, én sem vagyok mindent tudó, de még vérprofi Linux guru sem. A korrekciókat, tippeket szívesen fogadom és remélem néhányotoknak segíteni tudtam ezzel a kis összefoglalóval. A jövőben készülhet még hasonló, rajtatok áll, hogy milyen témában szülessen meg. A javaslatokat az írás topikjában várom.

Felhasznált források:

wikipedia.org
google.hu
man