Ez a fejezet tartalmazza az összes olyan információt és gyakran feltett kérdéseket, amit nem tudtam elhelyezni a fentebb lévő dokumentum struktúrába.
5.1. Hogyan rendszerezd a tűzfal szabályaidat?
Ennek a kérdésnek a megválaszolása némi gondolkodást igényel. Rendszerezheted a sebesség függvényének megfelelően (minimalizálni a szabályokat a legalapvetőbb csomagokra vonatkozóan), vagy pedig a kezelhetőség szempontja is számottevő lehet.
Ha van egy csak néha-néha fenn levő kapcsolatod, mondjuk egy PPP linked, az input lánc legeslegelső szabálya valószínűleg ez lesz: '-i ppp0 -j DENY' a boot-nál, aztán jöhet valamiféle ip-up szkript, mint például:
# Re-create the `ppp-in' chain. ipchains-restore -f < ppp-in.firewall # Replace DENY rule with jump to ppp-handling chain. ipchains -R input 1 -i ppp0 -j ppp-in
Az ip-down szkripted pedig:
ipchains -R input 1 -i ppp0 -j DENY
Van pár dolog, amit tudnod kell, mielőtt mindent kiblokkolnál, amit nem akarsz megkapni.
Az ICMP csomagokat azért találták ki, hogy a többi protokoll számára hibákat jelezzen (mint pl. a tcp és udp számára is). Például a cél-elérhetetlen (destination unreachable). Ha ezeket a csomagokat kiblokkolod, az azt fogja eredményezni, hogy soha nem fogsz 'gazdagép elérhetetlen' (Host unreachable), 'nincs útvonal a gazdagéphez' (No route to host) hibákat kapni; minden kapcsolat csak várni fog a válaszokra, amik soha nem jönnek meg. Ez idegesítő, de csak ritkán végzetes.
Az egész probléma az ICMP csomagok viselkedése az MTU (Maximum Transmission Unit, maximális továbbítható egység) felfedezésben keresendő. Minden jó TCP implementáció (mint pl. Linux) az MTU felfedezést használja ahhoz, hogy kitalálja mekkora a legnagyobb csomagméret, amit a célgépnek még nem kell töredékekre bontani (a töredezés lassú, pláne ha még valamelyik töredék el is vész útközben). Az MTU felfedezés úgy működik, hogy csomagokat küld a 'ne tördelj bit' (don't fragment bit) beállításával, és ha ezek után ilyen icmp választ kap: "töredezés szükséges, de DF beállítva" (fragmentation needed, but DF set), akkor kisebb csomagokat küld. Ez a válasz a 'cél elérhetetlen' (destination unreachable) csomag egyik típusa, és ha ez sosem érkezik meg, akkor a helyi gép nem fogja az MTU-t csomagméret változtatásra bírni, akkor a teljesítmény jelentős mértékben lecsökken, vagy nem is lesz egyáltalán. Megjegyezzük, gyakori dolog blokkolni az ICMP átirányító csomagokat (típusa 5), ezek az útválasztást tudják manipulálni, amelyek gyakran elég rizikósnak tűnnek.
Ha kifele menő tcp kapcsolatokat próbálsz blokkolni, figyelj oda, hogy a DNS nem mindig udp protokollt használ; ha a szerver válasza meghaladja az 512 byte-ot, a kliens tcp kapcsolatot fog használni (persze még mindig az 53-as portra).
Ez könnyű csapda lehet, mivel a DNS működni fog attól még (legalábbis úgy fog tűnni, rendben működik), hogy megtiltod a tcp átviteleket, de néha nagyon hosszú várakozások, vagy egyéb DNS problémák következhetnek be.
Ha a DNS lekérdezéseid mindig egy külső forráshoz irányítódnak (közvetlenül megmondva az /etc/resolv.conf-ban, vagy cache-elős névszervert továbbítós módban futtatva), elég csak azokat a tcp kapcsolatokat engedni, amik a helyi gép domain portjáról a külső névszerver domain portjára mennek (ha cache-elős névszervert futtatsz), vagy a magas portokról (nagyobbak mint 1024), ha az /etc/resolv.conf-os megoldást alkalmazod.
Az FTP egy klasszikus csomagszűrő probléma. Az FTP-nek két módja van. A hagyományos módot aktívnak hívják, míg a még újabb keletűt passzívnak. A Web böngészők alapvetően a passzív módot használják, de a parancs-soros ftp kliensek az aktívat.
Aktív módban, ha a távoli gép állományt szeretne küldeni (vagy akár az ls vagy dir parancs eredményét), tcp kapcsolatot próbál nyitni a helyi géppel. Ez azt jelenti, hogy ezeket a tcp kapcsolatokat nem blokkolhatod ki anélkül, hogy meghaljanak az aktív módú ftp kapcsolataid.
Ha választhatod, hogy inkább passzív módot használsz, minden rendben; ebben az esetben az adat kapcsolat létrehozása a klienstől a szerver felé irányul, még a bejövő adatoknál is. Egyébként javasolt, hogy csak olyan tcp forgalmat engedj, amelyeknek a portja 1024 vagy afölötti, viszont 6000 és 6010 közöttit ne (6000 az X-Windowhoz való).
A Linuxos gépek mostanára immunissá váltak a közkedvelt Ping of Death-re, arra a technikára, ami illegálisan nagy ICMP csomagokat küld az áldozat gépére, így puffer-túlcsordulást okozva ezzel a TCP veremben. Az eredmény egy szép nagy lefagyás.
Ha olyan gépeket védenél, amelyek még sérülékenyek erre a technikára, egyszerűen blokkold ki az ICMP töredékeket. A normális icmp csomagok nem elég nagyok ahhoz, hogy tördelni kelljen őket, szóval nem szűrsz ki semmi egyebet, csak a túl "nagy" pingeket. Hallottam arról, hogy néhány rendszernek a fagyáshoz elég csak a túlméretezett icmp csomag utolsó töredéke, szóval csak az első töredék blokkolása nem javallott.
Eddig én csak olyan kiaknázó programokat láttam, amelyek icmp-t használnak a hekkelésre, viszont nincs egyértelmű válasz arra, hogy a tcp vagy udp töredékek használhatóak-e puffer feltöltéshez (gépfagyasztáshoz), szóval csak az icmp töredékek blokkolása csupán ideiglenes megoldás lehet.
A "Teardrop" és a "Bonk" két támadási fajta (leginkább Microsoft Windows NT ellen), amelyek az egymást átfedő töredékekre alapszanak. Ha fogod a Linux gépedet (ha több van, azt amelyik az útválasztást végzi), és belefordítod a kernelbe az "ip: always defragment"-et, vagy kiblokkolod a tűzfal kóddal az összes töredéket a bántalmazható gépeid felé, a probléma megoldható.
Néhány kevésbé megbízható tcp megvalósításnál probléma lehet a csomagok töredékeinek nagy számával, amikor nem kapja meg az összes töredéket. A Linuxnak nincs ilyen problémája. Kiszűrheted a töredékeket, vagy befordíthatod az IP: always defragment (de csak akkor, ha ez a Linux gép az egyetlen lehetséges útválasztója a csomagoknak).
Ha nem vagy óvatos, simán átmehetnek nem kívánt csomagok, miközben a tűzfal-szabályokat konfigurálod. A legjobb mód az óvatosságra a következő:
Szabály változtatások …
Ezzel, az állítgatás alatt minden csomag dobódik a francba.
Ha a változtatásaid csak egy szimpla láncra vonatkoznak, csinálhatsz egy új láncot az új szabályokkal, aztán kicseréled ('-R') a régi láncra mutató szabályt, hogy mutasson az újonnan készített láncra. Ezek után kitörölheted a régi láncot.
Az IP-spoofing az a technika, amikor egy gazdagép olyan csomagot küld, ami úgy tűnik, mintha máshonnan jött volna. Mivel a csomagszűrés forráscímen is alapszik, az IP-spoofing a bután beállított csomagszűrőkre veszélyes. Szintén használható (mármint a spoofing) arra, hogy elrejtse a támadók kilétét, ha éppen pingelgetni támad kedve, vagy esetleg SYN támadást hajt végre, netán Teardrop-ot, ésatöbbi.
A legjobb módszer a spoofing ellen a "Forráscím hitelesítés" (Source Address Verification), amit az útválasztó kód végez, nem pedig a tűzfal. Keress ilyen nevű állományt: /proc/sys/net/ipv4/conf/all/rp_filter. Ha van, akkor a forráscím hitelesítés bekapcsolása minden boot-kor a legjobb megoldás a számodra. Ehhez írd be az alábbi sorokat az indító szkriptjeid valamelyikébe, de még a hálózat felhúzása elé:
Ha ez nem megy, egyenként kell szabályokat beszúrnod az interfészeid védelme érdekében. Ehhez ismerned kell interfészeidet (meg ellenségeidet). A 2.1 és afeletti kernelek automatikus dobják a 127.* felől érkező csomagokat (loopback számára fenntartva).
Például tegyük fel, három interfészünk van, eth0, eth1 és ppp0. Az ifconfiggal megnézhetjük (meg be is állíthatjuk) a címeket és a hálózati maszkokat az interfészekre. Mondjuk, az eth0 a 192.168.1.0-hoz van csatolva 255.255.255.0-s maszkkal, az eth1 a 10.0.0.0-hoz a 255.0.0.0 maszkkal, és a ppp0 az Internethez van kapcsolva (akármilyen érvényes IP címmel, kivéve persze privátokat). A következő szabályokat tehetjük be:
Ez a megközelítés koránt sem olyan jó, mint a forráscím hitelesítése, mivel ha a hálózatod megváltozik, a szabályokat is frissítened kell.
Ha 2.0 sorszámú kernelt futtatsz, megvédheted a visszahurkoló interfészedet, ezzel a szabállyal:
Van egy felhasználói-területű könyvtár, amit jómagam írtam, mellékelvén a forrás-disztribúcióval (libfw-nek hívják). Az Ipchains szolgáltatásait használja (1.3 és afelett), ahhoz, hogy a csomagokat a felhasználó területre másolja (használván az IP_FIREWALL_NETLINK kernel konfigurálási opciót).
A jelzőérték használható a csomagok 'Szolgáltatás minősége' paramétereinek meghatározására, vagy pedig ahhoz, hogy a csomagok port továbbításon vegyenek részt. Soha nem használtam egyiket se, de ha írni akarsz róluk, kérlek vedd fel velem a kapcsolatot.
Az olyan dolgok, mint például az állapot-szemle (jobban szeretem dinamikus tűzfalazásnak hívni), implementálható a felhasználó-területtel ezt a könyvtárat használva. Több klassz ötlet is található csomagkezelésre, felhasználó-terület démont futtatva. Könnyű megcsinálni.
ftp://ftp.interlinx.bc.ca/pub/spf a lelőhelye Brian Murell SPF projektének, amely kapcsolat lekövetést végez a felhasználói területen. Jelentős biztonságot ad az alacsony sávszélességű site-ok számára.
Jelenleg van egy kis dokumentáció róla, de itt van egy üzenet a levelező listáról, amiben Brian megválaszol néhány kérdést:
A fent nevezett úriember (SuSE-nél dolgozik) írt egy kernel patch-et, amely az ftp kapcsolatokat követi nyomon az ipchains-el karöltve. Jelenleg itt található: http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
A tűzfalazás és a NAT (Hálózati címfordítás, Network Address Translation) újra lesz tervezve a 2.3-hoz. A tervek és az előkészületek dokumentumai megtalálhatóak a netdev archívban, valamint az ipchains fejlesztői archívumában. Ezek a fejlesztések le fogják tisztítani használaton kívül álló dolgokat, és nagyobb lesz a tűzfal-eszköz felxibilitása.
5.2.3. FTP Rémálmok
5.3. A halál pingjének kiszűrése (Ping of Death)
5.4. Könnycsepp (Teardrop) és Bonk szűrése
5.5. Töredék-bombák szűrése (fragment bombs)
5.6. Tűzfal szabályok megváltoztatása
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
5.7. Hogyan védekezhetek az IP-spoofing ellen?
# Ez a legjobb modszer: Bekapcsoljuk a Source Address Verification-t
# es spoof vedelmet rakunk minden mostani es jovobeni interfeszunkre
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "IP spoofing vedelem beallitasa..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo "kesz."
else
echo PROBLEMAK AZ IP SPOOFING VEDELEM BEALLITASAVAL. LEHET AGGODNI.
echo "CONTROL-D kilep a shellbol, es folytatodik a rendszerindulas"
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
5.8. SPF: Stateful Packet Filtering (talán állapot csomagszűrés)
> Úgy gondolom pontosan azt teszi, amit akarok: Telepít egy ideiglenes
"fejletlen" szabályt, hogy kiengedjen csomagokat válaszként a kívülről
érkező kérelmekre.
Igen, pontosan ezt teszi. A legtöbb protokoll megérti, a többi "fejletlen"
szabály rendben megkapja. Mostanára támogatással rendelkezik
(emlékezetből írom) az FTP (aktív és passzív mód, befele-kifele),
a RealAudio, traceroute, ICMP és az alapvető ICQ (kötetlenül az ICQ
szerverektől, és a közvetlen TCP kapcsolatoktól) részére.
> Mindez az ipchains helyett lett kitalálva, vagy ez csak annak támogatása?
Ez csak támogatás. Gondolj arra, hogy az ipchains a motor (engine) arra,
hogy megóvd a Linuxodat bizonyos csomagforgalomtól. Az SPF csak egy driver
(kezelő), amely egyfolytában monitorozza a forgalmat, és elmondja az
ipchains-nak, hogyan változtassa meg a szűrő irányelveket annak érdekében,
hogy tükrözze a változtatásokat a forgalmi mintákban.
5.8. Michael Hasenstein ftp-adat hack-ja.