Sok különböző linwin flame-nek voltam tanúja és részese errefelé. Gyakran hangoztatott érv a Linux rendszerek mellett, hogy alapból mennyivel biztonságosabbak, mint a Windowsok. A legújabb trendek azonban mintha lazítanának a Linuxok biztonságán, ezért kicsit ráerősítünk az alapból létező biztonsági megoldásokra. Íme az általam használt eszközcsokor Ubuntun...

Nmap

Okos kis programocska, feltérképezi a hálózatot és felfedi a gyenge pontokat - kiválóan alkalmas saját gépünk feltérképezésére is. Felismeri a futó szolgáltatásokat, nyitott portokat, alkalmas operációs rendszer detektálásra is. Igen gyakran használom otthoni gépem vizsgálatára, főleg, ha hozzányúlok bizonyos beállításokhoz, amik esetleg rést nyithatnak a pajzson. Amikor először használtam, láttam, hogy a cupsysd (nyomtatókezelő alrendszer) ott csücsül egy nyitott porton és hallgatózik. Mivel én nem használok otthon nyomtatót, ezért leállítottam a cupsysd-t, hogy ne is induljon el (előfordulhat, hogy ez lehetetlenné teszi a pdf-be nyomtatást).
Nem teszek kísérletet a program opcióinak bemutatására, az egy külön könyv története (árulnak is ilyet). A program elérhető a http://nmap.org oldalról, vagy a tárolókból.

IPTables

A Linuxok tűzfala. Kezdőknek rémisztő lehet, de én power userként sem vettem rá magam minden csínjának-bínjának elsajátítására, inkább körülnéztem az Interneten kész megoldások után - elvárásaimban nem is csalatkoztam, ami a Hálón nincs, az nem is létezik. Léteznek grafikus front-endek a beállításához, Firestarter és GUFW néven ismeretesek. Én próbálkoztam ezekkel, de szerintem nem elég egyértelmű a kezelésük, így az Interneten talált scriptet faragtam át a saját szükségleteimnek megfelelően. Szintén nem törekszem a teljességre, hiszen itt is nagyon sok dolgot lehet állítani, de az általam használt scriptet megosztom veletek.

sh4d0w@reactor:~$ cat firewall-init.sh
#!/bin/bash
# Ez egy tuzfal script, ami engedi a forgalmat az ssh szerver fele

# Az iptables parancs helye, igy nem kell mindig a teljes utvonalat beirni
IPTABLES=/sbin/iptables

# Toroljuk az eddigi szabalyokat
$IPTABLES --flush

# Minden meglevo extra lancot torlunk
$IPTABLES --delete-chain

# A harom alapertelmezett lancot DROP-ra allitjuk
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# Kihasznaljuk, hogy lehetseges az allapot ellenorzese
# es csak olyan bejovo kapcsolatokat engedelyezunk, amelyeket mi inditottunk
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Engedelyezzuk az ssh szerver portjat
# termeszetesen igy az egesz vilag hozzaferhet
$IPTABLES -A INPUT -p tcp --dport 5353 -j ACCEPT

# Ezt a kesobbi esetleges befejezesi-ertek vizsgalatokhoz tesszuk ide
exit 0

A fenti konfiguráció nem akadályozza a mindennapi használatot, ugyanakkor az ssh szerver kivételével minden egyéb kapcsolatot eldob. Apropó...

SSH szerver

Tárolókból telepíthető, segítségével távolról is kapcsolódhatunk gépünkhöz akár konzolon, akár GUI-n keresztül. Az iptables beállításakor azt láthattátok, hogy nem a standard 22-es porton hallgatózik az sshd, hanem az 5353-ason. Elárulom: szándékos a dolog :)
Sok esetben az sshd alapbeállítása megfelelő, néhányban nem. Amikor csak és kizárólag szerverek kommunikálnak egymással, felesleges egyéb opciókkal megbonyolítani a konfigurációt, nekem, mint paranoiás júzernek viszont ez nem tetszik. Nem azért, mert bármi olyan információ lenne a gépemen, amivel világvégét lehetne előidézni, hanem mert nem kívánok botnetek tagja lenni és tudtomon kívül bármilyen (D)DoS vagy egyéb támadásban részt venni. Így vettem a fáradtságot és utánanéztem, mit lehetne kezdeni az ssh szerver alapértelmezett beállításaival - de előrebocsátom, most csak azokról a lehetőségekről írok, amelyeket én megváltoztattam az alapértelmezett beállításokhoz képest.

A file, amit szerkesztenünk kell: /etc/ssh/sshd_config. Csak semmi rémület, egész olvasható a tartalom.

# What ports, IPs and protocols we listen for
Port 5353

# Authentication:
.
PermitRootLogin no
.

#UseLogin no

AllowUsers sh4d0w

Beszéljük ki! Portot 22-ről 5353-ra állítottam. A script-kiddie-ktől megvéd, aki komolyan kutakodik, azt lelassíthatja picit. A PermitRootLogin alapbeállításánál a fejemhez kaptam, alapból engedélyezve volt, gyorsan átállítottam "no"-ra. Nem tudom, ez hogyan és honnan jött, de néztem én is nagyokat... A Login program használatát kiiktattam az ssh-ból, így most csak RSA-kulcsokkal lehet belépni a gépemre. RSA-kulcsok használatához forduljatok ide. Utolsó opcióként csak a saját usernevemet engedélyeztem ssh-belépéshez (láttam olyan támadási próbálkozást, amiben valószínűleg szótárból öntötték a userneveket a(z akkor még) 22-es porton hallgatózó sshd-mre).

Természetesen lehetőség van akár fail2ban használatára is, de ezt egy alapvetően semmi titkot nem tartalmazó otthoni gépre azért túlzásnak érzem :) Lépjünk tovább, van még két eszköz, amivel röviden szeretnélek megismertetni Titeket, aztán leülök magamtól is.

rkhunter

Habár Linuxon igen ritkán találkozunk vírusokkal, rootkitek azért vannak szép számmal, nem árt szemmel tartani a rendszerünket. Persze igen valószínűtlen, hogy találkozunk rootkittel, ha csak megbízható forrásból telepítünk programokat. Említettem már, hogy paranoiás vagyok...? Mivel nem lehetek elég nyugodt, ezért a tárolóból telepítettem a programot, ami nem a legfrissebb verzió, de most megfelel. Telepítés után frissítsük az adatbázisát és a file-ok tulajdonságainak adatbázisát, különben hamis riasztásokat kapunk:

sh4d0w@reactor:~$ sudo rkhunter --update --propupd
[ Rootkit Hunter version 1.3.2 ]
File updated: searched for 154 files, found 127

Checking rkhunter data files...
Checking file mirrors.dat [ No update ]
Checking file programs_bad.dat [ No update ]
Checking file backdoorports.dat [ No update ]
Checking file suspscan.dat [ No update ]
Checking file i18n/cn [ No update ]
Checking file i18n/en [ No update ]
Checking file i18n/zh [ No update ]
Checking file i18n/zh.utf8 [ No update ]

Első alkalommal javaslom, hogy a -c opcióval indítsuk az ellenőrzést, hogy lássuk, hogyan is működik. Íme egy kis részlet ebből:

sh4d0w@reactor:~$ sudo rkhunter -c
[sudo] password for sh4d0w:
[ Rootkit Hunter version 1.3.2 ]

Checking system commands...

Performing 'strings' command checks
Checking 'strings' command [ OK ]

Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preload file [ Not found ]
Checking LD_LIBRARY_PATH variable [ Not found ]

Performing file properties checks
Checking for prerequisites [ OK ]
.
.

Ez minden alapértelmezett tesztet végigfuttat, az egyes tesztek között pedig Enter-re vár a folytatáshoz. A későbbiek folyamán bőven elég, ha csak a figyelmeztetéseket kapjuk, erre is van lehetőség az indítási paraméterek között. A lehetséges opciókat megkaphatjuk, ha paraméterek nélkül indítjuk az rkhuntert.

Lynis

Ezt a programot az rkhunter oldalán találtam. Ez is egy audit eszköz (lásd még nmap), szintén alkalmas a biztonsági beállítások vizsgálatára. Ubuntura megtalálható ugyan a tárolókban, de a projekt oldalán lévő verzió frissebb, kicsomagolás után azonnal indítható, anélkül, hogy telepíteni kellene. Kezdjük frissítéssel:

sh4d0w@reactor:~/lynis/lynis-1.2.6$ sudo ./lynis --check-update

== Lynis ==
Version : 1.2.6
Release date : 5 April 2009

== Databases ==
Current Latest Status
-----------------------------------------------------------------------------
Malware : 2008062700 2008062700 Up-to-date
File perms : 2008053000 2008053000 Up-to-date


Copyright 2007-2009 - Michael Boelen, http://www.rootkit.nl/

Mivel a szerzője ugyanaz, mint az rkhunternek, működése, konzolos színvilága is meglehetősen hajaz rá. Az egyes tesztek között Enter-rel folytatódik a program futása, a munka befejeztével pedig javaslatokat kapunk, amiket vagy megfogadunk, vagy nem:

================================================================================

-[ Lynis 1.2.6 Results ]-

Tests performed: 126
Warnings:
----------------------------
- [13:00:30] Warning: No password set on GRUB bootloader [test:BOOT-5121] [impact:M]
- [13:02:12] Warning: No running NTP daemon or available client found [test:TIME-3104] [impact:M]

Suggestions:
----------------------------
- [13:00:30] Suggestion: Run grub-md5-crypt and create a hashed password. After that, add a line below the line saying timeout=<value>: password --md5 <password hash> [test:BOOT-5121]
- [13:00:40] Suggestion: Install a PAM module for password strength testing like pam_cracklib [test:AUTH-9262]
- [13:00:40] Suggestion: When possible set expire dates for all password protected accounts [test:AUTH-9282]
- [13:01:15] Suggestion: Enable logging to an external logging host for archiving purposes and additional protection [test:LOGG-2154]
- [13:02:11] Suggestion: Enable auditd to collect audit information [test:ACCT-9628]
- [13:02:12] Suggestion: Check if any NTP daemon is running or a NTP client gets executed daily, to prevent big time differences and avoid problems with services like kerberos, authentication or logging differences. [test:TIME-3104]
- [13:02:17] Suggestion: Confirm that freshclam is properly configured and keeps updating the ClamAV database [test:MALW-3286]
- [13:02:26] Suggestion: Harden the system by removing unneeded compilers. This can decrease the chance of customized trojans, backdoors and rootkits to be compiled and installed [test:HRDN-7220]
================================================================================
Files:
- Test and debug information : /var/log/lynis.log
- Report data : /var/log/lynis-report.dat
================================================================================
Hardening index : [64] [############ ]
================================================================================
Lynis 1.2.6
Copyright 2007-2009 - Michael Boelen, http://www.rootkit.nl/
================================================================================

A program logja sokkal részletesebb, mint amit képernyőre megkapunk, érdemes belenézni. Ha továbbra is aggódunk otthoni gépünk biztonsága miatt, lehet még azt fokozni, viszont elképzelhető, hogy az már komfortérzetünk rovására is megy.

Ez az írás nem azt tárgyalja, hogyan tudunk ultrabiztonságos rendszert üzemeltetni, hanem inkább egészséges távolságtartással fordul a Hálóhoz és az ott elérhető szolgáltatásokhoz. Egészen biztosan sokmindent lehetne másképp és máshogy, más eszközökkel, más beállításokkal (pl. ssh-nál). A cél csak az volt, hogy a parancssorral már megbirkózott felhasználók ne idegenkedjenek ezektől az eszközöktől sem, igen hasznosak lehetnek a mindennapi számítógéphasználatban. Köszönöm a figyelmet.