Javaslat egy Iptables tűzfal konfigurációjára Számítógép hálózatok esszé Készítette : Veress Krisztián

Átírás

1 Javaslat egy Iptables tűzfal konfigurációjára Számítógép hálózatok esszé Készítette : Veress Krisztián A mai internetre kapcsolt hálózatok és egyéni számítógépek tulajdonosai, karbantartói mind nagyobb figyelmet kell hogy szenteljenek rendszerük biztonságára. A hálózaton terjedő vírusok, worm-k, trójai falovak, és más rosszindulatú kódok veszélyeztetik biztonságunkat, dokumentu-mainkat, személyes adatainkat. A rendszerünk állandóan veszélynek van kitéve, ha a hálózati kábel a géphez van csatlakoztatva, ha a WiFi kártyánk aktiválva van, ha a GPRS telefonunk adatátvitelre van konfigurálva. A megfelelő biztonság eléréséhez többlépcsős védelmi vonalakat kell létrehoznunk, melybe beletartozik a rendszerek megfelelő fizikai kiépítése, az operációs rendszer, az alkalmazottak megfelelő tájékoztatása, helyes rendszeradminisztráció, stb. Az operációs rendszer keretében nyílik lehetőségünk a GNU/Linux rendszereken az iptables használatára, mely az adott számítógépen szoftveres tűzfalat valósít meg. A következőkben egy megfelelően specifikált hálózati struktúrára kiépített tűzfalkonfigurációt fogok bemutatni, mely természetesen nem teljes, nem hibátlan, gyarlóság lenne ezt kijelenteni. Az ismertetett konfiguráció más topológiák esetében nem nyújthat megfelelő védelmet, így a hálózati struktúra a tűzfal elsődleges szempontja. A hálózati struktúra Képzeljünk el egy olyan lokális hálózatot, melyben egy kitüntetett számítógép routolási és tűzfal feladatokat lát el. A LAN további számítógépei számára a hálózati hozzáférést ez a kitüntetett gép adja, tehát fizikailag az internetre csak a kitüntetett számítógép (továbbiakban router) van csatlakoztatva. Ennek megvalósításához a routernek két hálózati csatolóval kell rendelkeznie, az egyik fog az internettel kapcsolatot teremteni, ezt hívjuk külső interfésznek, a másikat amely a belső hálózattal tartja majd a kapcsolatot belső interfésznek. INTERNET ROUTER SZÁMÍTÓGÉP GÉP #1 GÉP #2 GÉP #3 GÉP #4

2 Az iptables konfigurációja Itt nem szeretném ismertetni az iptables csomagszűrő program működési elvét, paraméterezését, ez az esszé feltételezi a parancs alapszintű ismeretét. Az alapelv a következő : minden csomagot eldobunk, kivéve azokat, amelyek biztonságosak, minden portot blokkolunk, kivéve azokat, amelyekre szükségünk van. A hálózati struktúra alapján 6 db szűrési láncot hozhatunk létre a csomagok iránya szerint: 1. inet_to_fw : Az internetről a router (tűzfal) -re érkező csomagok 2. lnet_to_fw : A belső hálózatról a tűzfalra érkező csomagok 3. fw_to_inet : A routerről az internetre kimenő csomagok 4. fw_to_lnet : A routerről a belső hálózatra kimenő csomagok 5. inet_to_lnet : Az internetről a belső hálóra bejövő csomagok 6. lnet_to_inet : A belső hálózatról az internetre kimenő csomagok Nyilvánvaló, hogy minden olyan lánc, mely az internetről fogad csomagokat szűrést igényel. Természetesen lehetőség van a belső hálózat felhasználóit korlátozni a lnet_to_inet ill. lnet_to_fw láncokon, ám ettől most eltekintek. A számunkra nagyon is lényeges láncok a következők: inet_to_fw, inet_to_lnet. Először is állítsunk be egy pár változót a könnyebb kezelés érdekében: IPTABLES=/sbin/iptables SYSCTL=/sbin/sysctl INET_IF= Ide írjuk a külső interfészt, pl : ppp0 LNET_IF= Ide írjuk a belső interfészt, pl : eth0 INET_ADDR= Ide írjuk a router külső IP címét, pl : " " FW_ADDR= Ide írjuk a router belső IP címét, pl : " " LNET_ADDR= Ide írjuk a belső hálózat címtartományát pl : " /24" A következő címek foglaltak, tehát innen nem érkezhetnek csomagok: CLASS_A=" /8" CLASS_B=" /12" CLASS_C=" /16" CLASS_D_MULTICAST=" /4" CLASS_E_RESERVED=" /5" Beállítjuk az alapértelmezett policykat: DROP. Eldobunk minden csomagot alapból, előtte válogatunk. $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP Létrehozzuk a szűrési láncokat: $IPTABLES -N fw_to_inet $IPTABLES -N inet_to_fw $IPTABLES -N lnet_to_inet $IPTABLES -N inet_to_lnet $IPTABLES -N lnet_to_fw $IPTABLES -N fw_to_lnet

3 A létrehozott láncokra irányítjuk a csomagokat irányuk szerint, és ne felejtsük el a visszacsatoló hurkot (loopback) sem : $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A INPUT -i $INET_IF -j inet_to_fw $IPTABLES -A INPUT -i $LNET_IF -s $LNET_ADDR -j lnet_to_fw $IPTABLES -A OUTPUT -o $INET_IF -j fw_to_inet $IPTABLES -A OUTPUT -o $LNET_IF -d $LNET_ADDR -j fw_to_lnet $IPTABLES -A FORWARD -i $INET_IF -o $LNET_IF -d $LNET_ADDR -j inet_to_lnet $IPTABLES -A FORWARD -i $LNET_IF -o $INET_IF -s $LNET_ADDR -j lnet_to_inet Ezekután koncentráljunk az inet_to_fw láncra. A továbbiakban alkalmazott szűrési feltételeket alkalmazhatjuk (sőt alkalmazzuk is) az inet_to_lnet láncra is! Először is detektáljuk az IP-spoof-t (IP cím hamisítást): $IPTABLES -A inet_to_lnet -s $CLASS_A -j LOG --log-prefix "fake IP source " $IPTABLES -A inet_to_lnet -s $CLASS_A -j DROP $IPTABLES -A inet_to_lnet -s $CLASS_B -j LOG --log-prefix "fake IP source " $IPTABLES -A inet_to_lnet -s $CLASS_B -j DROP $IPTABLES -A inet_to_lnet -s $CLASS_C -j LOG --log-prefix "fake IP source " $IPTABLES -A inet_to_lnet -s $CLASS_C -j DROP $IPTABLES -A inet_to_lnet -s $CLASS_D_MULTICAST -j LOG --log-prefix "fake IP" $IPTABLES -A inet_to_lnet -s $CLASS_D_MULTICAST -j DROP $IPTABLES -A inet_to_lnet -s $CLASS_E_RESERVED -j LOG --log-prefix "fake IP" $IPTABLES -A inet_to_lnet -s $CLASS_E_RESERVED -j DROP Manapság gyakran alkalmazott DoS (Denial of Service Szolgáltatás-megtagadás alapú támadás) illetve DDoS (Distributed Denial of Service) technikák egyik alapeleme az un. SYN-Flood, mely során a támadó SYN flagekkel beállított csomagokkal bombázza portjainkat, melyre adott válaszaink lefoglalják a portot, így a tényleges felhasználók elesnek a szolgáltatásunktól. Ezt megelőzvén definiáluk a következőket: $IPTABLES -A inet_to_lnet -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j ACCEPT $IPTABLES -A inet_to_lnet -p tcp --syn -j LOG --log-prefix "$TITLE : SYN-Flood attack " $IPTABLES -A inet_to_lnet -p tcp --syn -j DROP A méltán népszerű nmap portscanner számos módon ki tudja deríteni egy célpont nyitott portjait. Ezt sem szeretnénk, hogy bárki megtudja, milyen portjaink vannak nyitva, detektáljuk hát az nmap által küldött csomagokat : # Nmap FIN/URG/PSH $IPTABLES -A inet_to_lnet -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 5/m -j LOG --log-prefix "$TITLE : Nmap XMAS scan " $IPTABLES -A inet_to_lnet -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP # SYN/RST $IPTABLES -A inet_to_lnet -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 5/m -j LOG --log-prefix "$TITLE : SYN/RST scan " $IPTABLES -A inet_to_lnet -p tcp --tcp-flags SYN,RST SYN,RST -j DROP #SYN/FIN $IPTABLES -A inet_to_lnet -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit

4 5/m -j LOG --log-prefix "$TITLE : SYN/FIN scan " $IPTABLES -A inet_to_lnet -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP Sokan azt gondolhatják, most már mindent bebiztosítottunk, kész a tökéletes tűzfal. Mi legyen a Ping of Death támadásokkal? Mitévő legyünk a közvetett DoS támadásokkal szemben? Hogyan kezeljük a PING echo-kéréseket? Milyen portokat nyissunk ki? Adjunk-e gyors reagálási metódusokat a script-hez? A kérdésekre a válaszokat a következőkben leírom. Szűrjük ki a Ping of Death, és más portscannelő csomagokat: $IPTABLES -A inet_to_fw -p tcp --tcp-flags ALL ALL -j LOG --log-prefix "$TITLE : XMAS-tree scan " $IPTABLES -A inet_to_fw -p tcp --tcp-flags ALL NONE -m state --state! ESTABLISHED -j LOG --log-prefix "$TITLE : NULL scan " $IPTABLES -A inet_to_fw -p icmp --icmp-type echo-request -m limit --limit 3/s -j ACCEPT $IPTABLES -A inet_to_fw -p icmp --icmp-type echo-request -j LOG --log-prefix "$TITLE : PoD attack " $IPTABLES -A inet_to_fw -p icmp --icmp-type echo-request -j DROP A közvetett DoS -t arról lehet megismerni, hogy egy kapcsolat felvételére nem helyes TCP SYN csomag érkezik, helyette egy SYN/ACK flagekkel beállított loggoljuk, és dobjuk el: $IPTABLES -A inet_to_fw -p tcp! --syn -m state --state NEW -j LOG --log-prefix "$TITLE : hidded portscan " $IPTABLES -A inet_to_fw -p tcp! --syn -m state --state NEW -j DROP Hogyan viselkedjünk azokkal a csomagokkal, melyek már egy létrehozott, érvényes kapcsolathoz tartoznak? Természetesen tovább kell engednünk őket, nehogy az adatátvitelben fennakadás legyen: $IPTABLES -A inet_to_fw -m state --state ESTABLISHED,RELATED -j ACCEPT És most egy találós kérdés: a ping kérésekre reagáljunk, jelezvén, hogy a rendszerünk él és virul, szolgáltatásai (elvileg) működnek, avagy inkább rejtsük el magunkat, gondolván arra, hogy aki a szolgáltatásunkat szeretné igénybe venni, úgysem fog először ping requesteket küldeni. Erről a kérdésről megoszlik a vélemény internetes biztonsági fórumokon, én az utóbbira szavazok. Ugyan vannak olyan programok, melyek ping-re támaszkodnak, ám ezekre nagy valószínűség szerint ilyen topológia mellett nem lesz szükségünk. $IPTABLES -A inet_to_fw -m state --state NEW -p icmp -j DROP/ACCEPT Ezekután mondhatni bevédtük magunkat, természetesen csak az eddig ismert leggyakoribb támadási módszerek ellen. Hátra van még a szolgáltatások engedélyezése: $IPTABLES -A inet_to_fw -m state --state NEW -p tcp --dport 22 -j ACCEPT # ssh $IPTABLES -A inet_to_fw -m state --state NEW -p udp --dport 22 -j ACCEPT # ssh $IPTABLES -A inet_to_fw -m state --state NEW -p tcp --dport 80 -j ACCEPT # HTTP $IPTABLES -A inet_to_fw -m state --state NEW -p udp --dport 80 -j ACCEPT # HTTP

5 Az inet_to_lnet láncra is alkalmazhatjuk ezeket a szűrési szabályokat, ám szükségünk van egy routolási szabály beállítására is a nat táblában: $IPTABLES -t nat -A POSTROUTING -o $INET_IF -j MASQUERADE A fent említett két láncon kívül van még hátra 4 db láncunk. Mint már említettem a belső hálózatot használókat korlátozhatjuk, én ettől most eltekintek. Ilyen esetben mind a 4 láncon a következőt kell beállítanunk: $IPTABLES -A fw_to_inet -j ACCEPT Ahhoz, hogy a tűzfalunkat kernel-szinten is bebiztosítsuk, számos beállítási lehetőségünk adódik a /proc fájlrendszeren. Ilyen pl. az ICMP redirect fogadásának kikapcsolása, bash script formájában: $SYSCTL -w net.ipv4.conf.`basename $f`.accept_redirects=0 > /dev/null; A forrás routolás csomagok is DoS-veszélyesek, kapcsoljuk ki őket : $SYSCTL -w net.ipv4.conf.`basename $f`.accept_source_route=0 > /dev/null; Az IP-spoofing ellehetetlenítése, routolási háromszögelés, a biztonságos ICMP redirektek engedélyezése az átjáróknak, a veszélyesek kikapcsolása: $SYSCTL -w net.ipv4.conf.`basename $f`.log_martians=1 > /dev/null; $SYSCTL -w net.ipv4.conf.`basename $f`.rp_filter=1 > /dev/null; $SYSCTL -w net.ipv4.conf.`basename $f`.secure_redirects=1 > /dev/null; # Ha a gép router, írjuk át 1-re, és a többi host kap ICMP redirect-t $SYSCTL -w net.ipv4.conf.`basename $f`.send_redirects=0 > /dev/null; Kiszűrhetjük a hibás broadcast-pingeket (Smurf), illetve engedélyezzük az IP routolást a nat táblához: $SYSCTL -w net.ipv4.icmp_echo_ignore_broadcasts=1 > /dev/null $SYSCTL -w net.ipv4.icmp_ignore_bogus_error_responses=1 > /dev/null $SYSCTL -w net.ipv4.ip_forward=1 > /dev/null Természetesen a fenti konfiguráció gyors és hatékony használatához mindezt érdemes egy script-be foglalni, mely a tűzfal gép bootolásakor még a hálózat kiépítése előtt inicializálódik.

6 A teljes script kiegészítve számos függvénnyel, beállítási lehetőséggel, illetve a hibák javításával - elérhető a honlapomon: Készítette: Veress Krisztián