Administrace komentářů

nebijte me pisu to zhlavy, aniz bych si neco kontroloval, takze cesty/parametry iptables muzou byt nekdy blbe... no teda abych se priznal vuybec nevim o cem mluvite... nejaky widlouze, ale nez vas servu, ze ste OT ;)

paket kdyz doleze skrze sitofku z vnejsiho prostredi do stroje do ipv4 stacku, kde se rozhoduje co dal s nim, tak:
1 - si sam ip stack udela kontroly, jestli neni tak trochu vadnej a nemel by se zahodit
2 - pokud mas nastaveny Route Path filtering. poznas podle cisla "1" v "cat /proc/sys/net/ipv4/conf/*/rp_filter" tak se zahodi paket, ktery prisel na rozhranni routovany korektne treba podle MAC adresey v ethernetovym ramci, ale pokud prisel na rozhranni, kde nevede cesta k dane jeho zdrojove ipv4 adrese, tak se zahodi. typicky paket, ktery se tvari, ze prisel z loopbacku (ipv4-src=127.0.0.1) a objevi se na sitofce(interface!=lo) kde dorazil diky MAC adrese atd takovy docela stary podly druh utoku
3 - tak ip stack rozhodl, ze teda s paketem bude neco delat, ze splnuje nejaky zakladni kriteria. posle teda paket do prvniho bodu netfilteru PREROUTING
4 - v kazdem bodu paket prochazi sadou tabulek v poradi -t mangle, -t nat, -t filter. nat tabulka se tusim nenachazi ve vsech bodech.
5 - paket je teda v -t mangle -L PREROUTING a rozhoduje se o tom, jestli se pozmeni paket. treba Type Of Service (-j TOS --set-tos 0x10) , ktera ma pak vliv na nektere Quality Of Service schedulery, ktere rozhoduji o tom, kdy muze nektery paket predbehnout jiny, kolik pasma muzou takove pakety zabrat atd.
6 - tak TOS dopadl jakkoliv, tak ted je paket dostrkan do -t nat -L PREROUTING tady se rozhoduje o prepisu cilove ipv4 adresy pred tim, nez bude paket nasmerovan na nejake rozhranni.
7 - at uz prepis dopadl jakkoliv, tak jeste zbyva -t filter -L PREROUTING tedy se nerozhodne o nicem jinem, nez jestli uz nas paket dostatecne nasral, aby byl zahozen, nebo muze jit dal
8 - ted nad paketem zasahne zase ip stack a rozhodne, kam bude paket dal pokracovat podle nastaveni routovani "route -nl" "ip route show ..." "cat /proc/sys/net/ipv4/ip_forward"
9a- pokud je paket urcen pro cilovou adresu, ktera se nachazi na tomto stroji, pokracuje do -t mangle -L INPUT
9b- pokud je paket urcen jinam a prosel predchozi casti ipstacku, tedy ma 1 v /proc/.../ip_forward a nejak rozume nastaveny routovaci tabulky, tak je odeslan do -t mangle -L FORWARD
10- v INPUT, ci v FORWARD si po mangle paket odbyde uz jen -t filter
11- pokud projde skrz INPUT, tak je dorucen aplikaci do socketu a KONCI pokud vas zajima cesta paketu, ktery prisel z venku a hodla odejit zase jinam ven, nebo nejake dalsi, tak je na to docela pekny obrazek vsech bodu a cest paketu v nejakem .ps nebo .pdf souboru, ktery se tvari jako IPTables Quick Reference nebo neco podobneho. na rootu na toto tema taky bylo vicero clanku... staci hledat na google ;)
a kdyz budes cist pozorne, tak se dozvis, ze -t mangle neni jen o pozmenovani cili -j TOS, ale muze uz v nem i filtrovat -j REJECT nebo bez chybove odpovedi -j DROP, coz muze slusnemu uzivateli zpusobit neprijemne prodlevy, tobe usetrit velmi malo provozu, ale pred hackery tim nic neschovas a ani je nijak nezpomalis, takze slusnosti je -j REJECT, ale na spatnem modemu je rozumejsi -j DROP stejne jako na GPRS nebo kdekoliv, kde platis za objem odchozich/navazanych dat
dal se dozvis, ze nektere parametry jako -o funguji jen v nekterych bodech (typicky nefunguji v PREROUTING), protoze to udava odchozi rozhranni ktere je zname az od routovani, tak nebude fungovat pred provedenim routovani. a dal se dozvis nekolik uzitecnych veci jako pouziti modulu pro inspekci stavu spojeni -m state --state INVALID -j DROP, ale uz se nedozvis detaily, ze navazni spojeni -p udp -m state --state ESTABLISHED -j ACCEPT nad udp je naprosta silenost, kde se predpoklada nejaka doba, po kterou se navazuji pakety jen na zaklade (src,src-port,dst,dst-port), takze takrka kdokoliv muze podvrhnout zdrojovou adresu a poslat nebezpecny paket.