Alap tűzfal otthoni PC-re (iptables)
Tartalom
- Saját láncok létrehozása
- IP és|vagy MAC alapján történő szűrés (IP or MAC filter)
- ICMP szűrés
- Hogyan lehet korlátozni az illeszkedések számát
- Port forward
- Hálózati címfordítás (NAT)
- forgalom számlálás (transfer counting)
- Állapot követés
Jelenlegi tűzfalunk így néz ki
#!/bin/bash
# modulok betolltese
modprobe ip_conntrack_ftp
# Láncok törlése, ürítése, és alapértelmezett szabály beállítása.
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# INPUT lanc
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: "
iptables -A INPUT -j DROP (nem fontos)
# OUTPUT lanc
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dport 20,21,22,25,80,110,143,443,465,993,995,1863,6667 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT_DROP: "
iptables -A OUTPUT -j DROP (nem fontos az alapértelmezett szabály miatt)
Kipróbáltam: internet (DNS,HTTP,HTTPS,) FTP, levelezés (POP3,SMTP), irc, msn, skype. Ezeket próbáltam ki ezzel a tűzfallal és minden működött szépen.
Saját láncok létrehozása
Előfordulhat, hogy saját láncot szeretnénk létrehozni. Ennek ezer oka lehet, ha pl.: valamivel kiemelten szeretnénk foglalkozni. Mi most a hamis forráscímről érkező csomagokat „küldjük” egy saját láncra ahol külön foglalkozunk vele. Vagy én például szoktam használni egy security láncot, ahova beküldök minden TCP csomagot ellenőrzésre. Ebben a láncban megpróbálom kiszűrni a hamis, vagy érvénytelen csomagokat, és ami átmegy a láncon azt visszadobon abba a láncba ahonnan jött (-j RETURN)
Tegyük fel, hogy a mi interfészünk (ami legyen eth0) IP címe 82.321.112.321.
(Szándékosan írtam ezt a példát, hogy véletlenül se egyezzen valós IP címmel. A valóságban 255 lehet egy oktett maximális értéke, de ebbe hosszú lenne belemenni, és nem feltétlenül tartozik a témához.)
Az IP címünket az ifconfig paranccsal tekinthetjük meg.
eth0 Link encap:Ethernet HWaddr NA:ez:Az:hE:9jA:cD inet addr:82.321.122.321 Bcast:255.255.255.255 Mask:255.255.254.0 inet6 addr: fefe::100:fifi:feri:caca/ca Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:241396 errors:0 dropped:0 overruns:0 frame:0 TX packets:331809 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:27705142 (26.4 MiB) TX bytes:350623261 (334.3 MiB) Interrupt:16 Base address:0x6000
Egyszerűbb formában:
ifconfig eth0 | grep "inet addr" | cut -d ":" -f 2 | awk {'print $1'}
Ha az eth0-át elvesszük akkor megkapjuk az összes interfészük IP címét.
Az IP címeket alapvetően 5 osztályba sorolják, de hármat használunk rendszeresen a világban, A, B és C osztályú címek. Az A 24 bit, a B osztályban 16 bit a C osztályban 8 bit szolgál a gépek megcímzésére. Vannak „privát” IP címek melyeket magáncélra, belső hálózatokban használnak. Ezekről a külvilág nem tud, így akárhány alhálózatban használhatjuk őket. Privát címeket csak privát/belső hálózatban használunk. Az interneten lévő eszközöknek csak publikus IP címük lehet, melyből nem lehet kettő egyforma. (Ugyan így nem lehet egy privát belső hálózatban sem két egyforma IP-val rendelkező eszköz)
Éppen ezért nem valószínű, hogy valódi csomagokat kapnánk ilyen forrás címekről. A privát címtartományok a következők:
„A” osztályú hálózathoz: 10.0.0.0/8
„B” osztályú hálózathoz: 172.16.0.0/16 (- 172.31.0.0)
„C” osztályú hálózathoz: 192.168.0.0/16 (- 192.168.255.0)
A hálózati maszkok jelentését sem írnám le. Rengeteg erről szóló dokumentum található az interneten a TCP/IP alapok témakörben.
Ezekről tehát biztos nem kapunk fontos csomagokat, így tiltsuk le őket. De szeretnénk a biztonság kedvéért ezeket az eldobott csomagokat külön loggolni, hogy megnézhessük eredményes e a beállítás. Tegyük hát külön láncba, hogy egyszerűbb dolgunk legyen.
Ehhez létre kell hozni egy új láncot. Legyen a neve in_attack (Szándékosan írom kis betűvel). Lássuk a szabályokat:
iptables -N in_attack
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j in_attack
iptables -A INPUT -i eth0 -s 172.16.0.0/16 -j in_attack
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j in_attack
Új opció a „-s”. Ezzel adjuk meg a forráscímet|címeket. Ezzel a leírás későbbi részében részletesebben foglalkozok.
Láthatjuk, hogy a -j kapcsolóval nem egy default láncba irányítottam az eldobni kívánt csomagokat hanem a saját láncunkba ami jelenleg üres, pedig szeretnénk ezeket a csomagokat loggolni majd törölni:
iptables -A in_attack -j LOG --log-prefix "HAMIS_FORRAS_IP_CIM: "
iptables -A in_attack -j DROP
A „-A|–append” opcióval a saját láncunkba tesszük ezeket a szabályokat. Vagyis minden ebbe a láncba érkező csomagot loggol majd eldob.
Saját láncnak nem kell megadni default policy-t!
IP és|vagy MAC alapján történő szűrés (IP or MAC filter)
Talán inkább szerveren hasznos ez a funkció, de előfordulhat, hogy bizonyos szolgáltatásokhoz (a gépünkön) nem szeretnénk ha mindenki hozzáférne. Viszont akinek szeretnénk engedélyezni tudjuk az IP címét (statikus, – tehát nem változik automatikusan) vagy a MAC címét. (hálózati interfész fizikai címe).
IP szűrés
Megadhatunk egy IP címet is, vagy egy IP tartományt is.
Megadhatjuk, hogy forráscímre szűrünk vagy célcímre.
Példa:
iptables -A INPUT -i eth0 -s 82.133.122.133 -p tcp --dport 80 -j ACCEPT
Ezzel a szabállyal csak a megadott IP címről férhetnek hozzá a webszerverünkhöz ami a 80/TCP port.
Előfordulhat, hogy egy szervergépünk van ami 8 alhálózathoz kapcsolódik, és csak az egyik alhálózatnak szeretnénk tiltani a hozzáférést a webszerverünkhöz.
Ehhez nem kell írni 7 szabályt, elég egyet amit „tagadunk”.
iptables -A INPUT -i eth0 -s ! 192.168.2.32/27 -p tcp --dport 80 -j ACCEPT
A felkiáltó jellel azt mondjuk, hogy bármire jó, csak arra nem ami utána áll. A felkiáltó jel után kell egy szóköz!
MAC szűrés
Lehetőség van a forrás ethernet kártyájának a MAC címére szűrni. Kapcsolója a
-m mac –mac-source
Példa:
iptables -A INPUT -p tcp --dport 22 -m mac --mac-source 00:01:02:03:04:05 -j ACCEPT
Működik is szépen. A MAC cím csak kitalált, amikor kiróbáltam valósat használtam. Ez a szabály azt mondja, hogy csak a megadott MAC címmel rendelkező kártya felől enged be SSH kapcsolatot. (Figyelem: MAC hamisítás létezik, és nagyon egyszerű.)
ICMP szűrés
El akarunk rejtőzni? Vagy csak nem szeretnénk hogy meg lehessen pingelni minket? Ezzel nem lehet teljesen levédeni magunkat, de sokan hisznek ennek a hasznosságában.
Először is ismernünk kell az ICMP típusokat. Innen 1 perc alatt le lehet tölteni.
A -p icmp –icmlp-type kapcsolóval adhatunk meg icmp típusokat.
Ha nem szeretnénk, hogy pingeljenek minket:
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
Eldobjuk az echo kéréseket.
Szemléltetés miatt kipróbálhatjuk, ezt a négy szabályt:
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-prefix "ping_ACCEPT: "
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j LOG --log-prefix "ping_DROP: "
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP
és pingessük meg magunkat egy másik gépről. Valami ilyesmi lesz:
Aug 24 00:47:33 budacsik-desktop kernel: [16456.722458] ping_ACCEPT: IN=eth0 OUT= MAC=xxxxxxxxx SRC= 82.323.122.323 DST= 82.321.112.321 LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=30330 SEQ=1
Aug 24 00:47:33 budacsik-desktop kernel: [16456.722492] ping_DROP: IN= OUT=eth0 SRC= 82.321.112.321 DST= 82.323.122.323 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55656 PROTO=ICMP TYPE=0 CODE=0 ID=30330 SEQ=1
Aug 24 00:47:34 budacsik-desktop kernel: [16457.721670] ping_ACCEPT: IN=eth0 OUT= MAC= xxxxxxxxx SRC= 82.323.122.323 DST= 82.321.112.321 LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=1 DF PROTO=ICMP TYPE=8 CODE=0 ID=30330 SEQ=2
Aug 24 00:47:34 budacsik-desktop kernel: [16457.721703] ping_DROP: IN= OUT=eth0 SRC= 82.321.112.321 DST= 82.323.122.323 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55657 PROTO=ICMP TYPE=0 CODE=0 ID=30330 SEQ=2
A példa jól mutatja, hogy a gépünk beengedi az icmp kéréseket, de a választ nem engedjük ki. Persze ennek nincs értelme, csak szemléltetésre jó, hogy lássuk, hogyan is működik.
Hogyan lehet korlátozni a csomagok illeszkedések számát
A -m limit –limit kapcsolót nagyon jól lehet használni pl.: naplózásnál, vagy ha korlátozni szeretnénk az SSH csatlakozásának számát egy percen belül. Rengeteg indokot lehet felsorolni, hogy miért hasznos ez a kapcsoló. Lássunk is egy példát:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/m -j LOG --log-prefix "SSH_ACCEPT: "
iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/m -j ACCEPT
Megadhatunk másodpercet (s), percet(m), órát(h), napot(d). A fenti példa percenként három ssh connect-et enged, és ez látszik is a logokban. Ki lehet próbálni, szemléltetésnek szintén nagyon jó.
A ping válaszcsomagok korlátozása már okos dolog lehet!
Megjegyzés: csináltam egy tesztet, hogy ha van egy szabályunk pl.:
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 3/m -j ACCEPT
három pinget enged be percenként. A többit egyszerűen tovább engedi a listán hiszen nem match-elt a limit miatt. Így az utolsó szabályom az INPUT láncban eldobta: (iptables -A INPUT -j DROP)
Ha limitálom a pingeket pl.: 1/m, vagyis egyet engedek be percenként akkor az első 5 ping kérésre válaszol, utána viszont már csak percenként egyet. SSH kapcsolat kéréssel viszont ugyanez jól működik, de azért inkább biztosra menjünk. Ez azért van, mert fentebb nem voltam pontos. Percenként 3 alkalommal enged be 5 csomagot. Honnan jön az öt? A ?limit-burst alapértelmezett értéke 5.
Helyesen így néz ki a szabály:
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 3/m --limit-burst 1 -j ACCEPT
Ez azt jelenti, hogy 3 megfelelés percenként (–limit 3/m) egy csomagra (–limit-burst 1).
Hálózati címfordítás (NAT ? Network Address Translation)
A NAT a mi netfilter rendszerünkön áthaladó forrás vagy cél IP címeinek vagy portjainak módosítását végzi. Legáltalánosabb használata amikor egy belső hálózat számára szeretnénk internet hozzáférést biztosítani, s így a (S)NAT segítségével a szerveren keresztül haladó (kifelé) forrás privát IP címeket lehet megváltoztatni a szerver publikus címére. Így egyetlen publikus IP címmel egy egész vállalat képes a világhálóra kapcsolódni.
Három része van:
SNAT
DNAT
MASQUERADE
Erre nézünk egy példát. Erre a célra az SNAT-ot kell használni, ami a source vagyis forrás címet változtatja meg.
Belső hálózat --> Gateway(átjáró) --> Internet privát IP SNAT publikus IP
Konkrét példa:
Privát IP cím: 192.168.2.1/24
Publikus IP cím: 83.321.221.421
Az összes belső hálózati felhasználó ugyan azt az IP címet fogja használni amikor az interneten kommunikálnak. Kapcsolatkövetésnek köszönhető, hogy a csomagok vissza is találnak a megfelelő privát IP-címhez. A kapcsolatkövetés miatt egy adatfolyamnak csak az első csomagja fog illeszkedni szabályra, a többi automatikusan megy utána. Amikor visszafelé jönnek a csomagok akkor az SNAT a célcímet fogja módosítani 83.321.221.421-ről a megfelelő belső hálózati címre. Ahhoz, hogy leírjunk egy ilyen szabályt 2 új láncot kell megérteni: POSTROUTING és PREROUTING.
Az SNAT a POSTROUTING-ot fogja használni,a DNAT pedig a PREROUTING-ot.
Tehát a fogalomzavar tisztázására:
SNAT: Source-NAT, forrás cím vagy port szám megváltoztatása a POSTROUTING láncban.
DNAT: Destination-NAT: cél cím vagy port szám megváltoztatása a PREROUTING láncban.
MASQUERADE: címálcázás, (-j MASQUERADE) az SNAT egyik típusa. Megváltoztatja a kimenő csomagok forrás címét a sajátjára, mintha azok tőle mentek volna ki a világhálóra.
PREROUTING: az INPUT, OUTPUT és a FORWARD láncok után ez a kettő beépített lánc van még összesen. A PREROUTING még az INPUT lánc előtt hajtódik végre, rögtön miután egy hálózati csatolótól megérkezik a csomag.
POSTROUTING: pedig az OUTPUT lánc után hajtódik végbe, épp mielőtt elhagyná a csomag a hálózati csatolót.
Nézzünk egy kis ábrát még meg a csomagok útjáról:
Ezeket belépési pontoknak is nevezik, én is most így nevezem, hogy érthető legyen a magyarázat. Egy csomag először a PREROUTING belépési pontra érkezik a netfilter (csomagszűrés) rendszerbe. Ezután a routing eldönti, hogy lokális gépnek szól e a csomag vagy sem. Ha igen belép az INPUT belépési pontba, ha nem akkor a FORWARD belépési ponton halad keresztül.
Ha egy csomag a lokális gépről indul, rögtön az PUTPUT belépési ponton halad keresztül, majd a routing eldönti, hogy mely interfésznek szól a csomag és a FORWARD ponton keresztül haladó csomagokkal együtt a POSTROUTING belépési pontba kerülnek ahol még mindig van lehetőség a csomag megváltoztatására.
Had jegyezzem meg, hogy a POSTROUTING és a PREROUTING nem tartozik a csomagszűrés folyamatához. Az már csomag manipuláció amit ezekben a láncokban végzünk.
Nézzünk konkrét szabály példát egy belső hálózat (S)NAT-olására:
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.2.0/24 -j SNAT
A NAT táblát használva, a POSTROUTING belépési pontban megváltoztatjuk a 192.168.2.0/24-es hálózati forráscímekkel rendelkező összes csomag forráscímét az átjáró (vagy szerver, gateway) saját IP címére (arra ami az eth1-nek az IP címe). Ez az eset azt feltételezi, hogy statikus IP címünk van. Ha dinamikus akkor a -j SNAT helyett -j MASQUERADE -et kell írni, ami megbírkózik azzal is ha dinamikus IP címünk van. Ez az eset azt is feltételezi, hogy az eth1 a publikus IP-címet birtokló hálózati interfész.
Ahhoz, hogy ez működjön be kell kapcsolni a port forward-ot is két interfész között.
echo "1" > /proc/sys/net/ipv4/ip_forward
Ez a parancs egy 1-est illeszt az ip_forward fájlba, ami annyit tesz, engedélyezve. Alapértelmezetten 0.
Mikor használható a DNAT?
Vajon mikor lehet szükség arra, hogy egy csomag célcímét és|vagy célportját megváltoztassuk? Ez a következő rész fő témája.
Port forward
DNAT: akkor lehet használni ha saját publikus IP címmel rendelkező gépünk van, és szeretnénk ha a tűzfalra érkező bizonyos kéréseket egy belső gép szolgálja ki aminek privát IP címe van.
Konkrét példa: Van egy kis vállalat akiknek van 3 szerverük, egy FTP, egy web és egy levelező szerver. Mind a három fizikailag külön szerver, de a vállalatnak csak egyetlen publikus IP címe van. DNAT segítségével tudják működtetni mind a három szervert.
GW (gateway): 192.168.0.254
FTP szerver: 192.168.0.1
Web szerver: 192.168.0.2
Levelező szerver: 192.168.2.3
Publikus IP: 82.321.112.321
Iptables szabályok:
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 21 -j DNAT --to-destination 192.168.0.1:21
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.2:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.3:25
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 110 -j DNAT --to-destination 192.168.0.3:110
Nem szabad elfelejteni, hogy ezzel sikerült ugyan a port tovabbitás, de a csomagok hogyan is fognak kinézni visszafelé? A forráscím interneten ismert publikus IP lesz, ezért nem fog visszatalálni. Ezért mielőtt elhagyja a csatolónkat át kell írni a forráscimet a gw privát IP-cimére (192.168.0.254)
iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 21 -j SNAT --to-source 192.168.0.254
iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 80 -j SNAT --to-source 192.168.0.254
iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 25 -j SNAT --to-source 192.168.0.254
iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 110 -j SNAT --to-source 192.168.0.254
Igy biztosak lehetünk benne, hogy a csomagok visszatalálnak a szerverig.
Ezenkívül a sikeres port forward-hoz kell még:
iptables-A FORWARD -d 192.168.0.1 -p tcp --dport 21 -j ACCEPT
iptables-A FORWARD -d 192.168.0.2 -p tcp --dport 80 -j ACCEPT
iptables-A FORWARD -d 192.168.0.3 -p tcp --dport 25 -j ACCEPT
iptables-A FORWARD -d 192.168.0.3 -p tcp --dport 110 -j ACCEPT
Forgalom számlálás
Tegyük fel, hogy a bejövő forgalmat szeretnénk számlálni az eth0 interfészen. (Megjegyzem, ugyan így kell a kimenő vagy átmenő forgalmat is számlálni.)
Egy nagyon egyszerű szabályt kell beillesztenünk az INPUT lánc legelső szabályaként. Fontos, hogy ez legyen a legelső szabály, mert erre minden csomagnak (a későbbiekben elfogadott és visszautasított) illeszkednie kell a pontos számlálás érdekében, és a rendszer a szabályokat fentről lefelé kezdi értelmezni. Erre minden alkalommal oda kell figyelni.
iptables -A INPUT -i eth0
Ezután generáljunk egy kis forgalmat, mondjuk böngésszük a netet, vagy töltsünk le egy fájlt. Majd a következő parancsot kell kiadni:
sudo iptables -L INPUT -v -n
„-L” listáz, az „INPUT” láncot csak, „-v”-vel kérünk részletesebb információt és a „-n” kapcsolóval azt érjük el, hogy az IP címeket és a port számokat írja ki, hostnevek és portnevek helyett. Célt nem kell adni, így ezen a szabályon egyszerűen „átfolynak” a csomagok.
A legelső sorban kell nézni az első két oszlopot.
Első oszlop:
pkts (csomagszám)
bytes (össz. csomagméret)
pkts bytes target prot opt in out source destination 8902 10M 0 -- eth0 * 0.0.0.0/0 0.0.0.0/0
Az én esetemben 8902db csomag érkezett be aminek össz. mérete: 10MB.
Ha a tűzfalat újra lefuttatjuk ezek a számlálók lenullázódnak.
Állapot követés
Az állapot követésó egy igen fontos része a tűzfalnak, ezért került még a második részbe.
Mit nevezünk állapotnak? Ha egy kapcsoaltot nyitunk egy webszerver felé (de bármilyen szerverről is lehet szó), azt a szercer 80-as TCp portja felé kezdeményezzük. Egy TCP kapcsolat három lépésben áll fel.
- 1. Első lépésben egy kapcsolat kezdeményező csomagot (SYN) küldünk a szerver felé
- 2. Második lépésben a szerver küld egy kapcsolat kezdeményező csomag nyugtát (SYN ACK). Ami azt jelenti, hogy részéről mehet a kapcsolat indítása.
- 3. Harmadik lépésben mi küldünk egy nyugtát, hogy megkaptuk
Ezt három-utas kézfogásnak is szokták mondnani.
ESTABLISHED jelenti, hogy a kapcsolat felállt, és él.
Mostmár érthető miért a következő forma az ajánlott:
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
A NEW állapot egyen értékű a következővel: –tcp-flags SYN,RST,ACK SYN. Vagyis figyeljük a SYN, RST és ACK biteket, de ebből csak a SYN legyen beállítva, ami egy kapcsolat kezdeményezését jelenti.
Aztán, az ehhez a kapcsolathoz tartozó csomagok a következő szabályon keresztül fognak kimenni:
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Tudni kell, hogy ez okos némi sebesség vesztést, de nem igazán érezhető, ugyanis az állapotokat egy fájlban vezeti a kernel. Azt is meg lehet ondani a kernelnek, hogy hány állapotot tudjon megjegyezni. Nem vagyok benne biztos, hogy ha jól tudom, akkor a legtöbbet, vagyis 65535.
Ez a Mű a Creative Commons Nevezd meg!-Így add tovább! 2.5 Magyarország Licenc feltételeinek megfelelően szabadon felhasználható.
„modprobe ip_conntrack_ftp
A 3. sor egy FTP modul betöltése. Ez szükséges ahhoz, hogy működjön az aktív FTP is. A modul betöltése nélkül csak a passive FTP működik, ami nem akar visszafelé egy új portot nyitni az adat hozdozásra.”
Pont fordítva: az aktív FTP-hez kell a 20-as port, INPUT irányba (az adatkapcsolatot ilyenkor a KLIENS nyitja, ettől „aktív”); míg a passzív mód adatkapcsolata közlekedik teljesen véletlen portokon (alaphelyzet a 1025:65535 tartomány – őszinte gratuláció a protokollt tervezőknek), amire engedő OUTPUT szabály kell, különben nem jön a pr0n.
Ennek segítésére való a conntrack modul, ami figyeli a 21-es (control, hálistennek ez állandó) porton folyó kapcsolatok PORT parancsát, és megfelelő ideiglenes engedő OUTPUT szabályt illeszt be a FTP server kénye-kedve szerint nyitott adatportra.
Titkosított control kapcsolat (FTPS/FTP-TLS – nem árt, ha nem akarsz plaintext jelszóval rohangálni a neten) esetén természetesen nem működik.
Köcsi Csigaa!
Megnézem és javítom!
1) „hozdozásra”
2) http://hup.hu/node/68228#comment-734929
Csigaa és gbor: köszi javítottam.
FTPS-t is bele kellene tenni szerintetek? Ennek a dokumentációnak igazából ezt nem feladata bemutatni, csupán az iptables eszköz használatának megtanítása bizonyos szintig, ahonnan már egyedül is jól lehet folytatni.
ahogy szeretnéd, csak láttam FTPS a téma, kadlec meg tett említést róla
esetleg vannak tökjó videók iptables-ről, NIIF Video on Demand archívumában, arany végignézni: http://vod.niif.hu/index.php?lg=hu&mn=archive&eid=4&sm=listevent
amúgy tökjónak tűnik a leírás, de még nem olvastam el
gbor: Kadlecsik Jószef előadásait ép tegnap hajnalban kezdtem el nézni:
Csaek ez frissebb: http://vod.niif.hu/index.php?lg=hu&mn=archive&eid=90&sm=listevent
Próbálok témákat meríteni a folytatáshoz. Ilyeneket írtam fel magamnak eddig:
– Kititltas megadott ideig…
– támadások elleni védelnek
– ipv6
– routing
– mangle tábláról többet, és hasonló finomságok, de ez már nem az otthoni tűzfal kategóriába fog kerülni szerintem 🙂
Örülök ha tetszik, remélem marad a véleményed miután végigolvasod 🙂
budacsik: FTPS-t szerintem nem kell betenni, annyira nem elterjedt, hogy otthoni felhasználásnál problémát okozhasson (tapasztalatok szerint vállalati felhasználásnál meg direkt nem foglalkoznak vele, annyira macerás az egész).
Csak egy plussz kép 🙂
http://jengelh.medozas.de/images/nf-packet-flow.png
gbor
Ez egy baromi jó kép, ismerem, de szerintem ebbe a doksiba nem illik.
Szerinted egy újat megérne? Ami csak erről szól?
csak próbáltam hozzárakni még, videóban is volt ez a kép, ahogy jónak látod, ahogy van szabadidőd 🙂
Nem lenne rossz kihívás, viszont az ebtables rész még ismeretlen. A zöld réteg talán most is menne. De a legfontosabb, hogy érdekelheti e az embereket ilyesmi?!
aki a szakmában van/lesz, annak mindig jól jön egy leírás az adott témáról, mivel így hatékonyabb lehet megtanulni, megérteni, mint hogy összecsipegesse az ember a netről, szerintem.
Hello!
Köszönöm a „hogyan” -t. Kezdő vagyok még és nagyon tetszik hogy elég részletes ahoz hogy belekezdjek, de nekem is kell vele dolgozni egy „kicsit”.
Várom a további Linux -os írásokat. További sok sikert!
Ha valaki még nem ismerné :
http://hu.wikipedia.org/wiki/TCP_%C3%A9s_UDP_portsz%C3%A1mok_list%C3%A1ja
Ha megpróbálom futtatni a firewall_start.sh-t, akkor a -F-es 6. sortól már elhasal.
„No chain/target…”
A többi pedig már ettől a sortól „csonkolva” fut le.
„‘ptables…”
Mit kellene tenni, hogy ne egyenként írjam be a parancssorba?
Előre is köszi…
Már nem érdekes, megoldódott.
A sorvég karakterek…
🙂
ui:
Nagyon jó a leírás.
Segített feleleveníteni egy-két régi „képet” a fejemben.
De hasznosnak tartanám, – ha valaki már ott tart, hogy cikket ír – hogy kicsit sűrűbben figyelje a hozzászólásokat.
😉
Szia nenix!
Ne haragudj, kicsit elfoglalt vagyok egy ideje. Írni sincs több időm.
Viszont, talán így, hogy magad ekllett megküzdened a problémával, talán jobb is. Mellesleg sosem jöttem volna rá így látatlanból, hogy ez a hiba 🙂
egy apró javítást kéne eszközölni:
SNAT a célcímet fogja módosítani 83.321.221.421 helyett;
SNAT a forráscímet fogja módosítani 83.321.221.421
nagyon jó cikk, várok még hasonló gyakorlatiasakat a biztonságról
Szia!
Igazad van, elírtam. Javítom!
Köszönöm az észrevételt!
Örülök ha hasznos bárninek az írásom.
Üdv / budacsik
Sziasztok!
budacsik! Nagyon szépen köszönöm ezt a leírást. Sokat segítettél vele.
Üdv,
Dávid
Szia Dávid!
Örülök neki és köszönöm!
Üdv /budacsik
Tisztelt budacsik úr,
köszönet ezért a munkáért, teljesen kezdő vagyok, ez az első script amit létrehoztam, karaktarenként írtam be… …és működik… majd bekopiztam a pastebin-rol, az is működik, teljes sikerélmeny…
Üdvözlettel Tóth István
[re=224955]Toth Istvan[/re]: Orulok Istvan! Nem „mai gyerek” ez az iras 🙂
Sok sikert kivanok a tovabbi tanulashoz!
Előbb elfelejtettem megköszönni a NAT-rol szóló írását, pazar kincsesbánya
számomra, sok homályos dologra fény derült… ez volt a bonus…
Extra köszönet érte.
Üdvözlettel Tóth István