Pokaż wyniki 1 do 7 z 7

Temat: iptables + nat +dmz

  1. #1
    Zarejestrowany
    Nov 2006
    Skąd
    Polska/Poland
    Postów
    1,191

    Question iptables + nat +dmz

    Witajcie!


    muszę zbudować filtr na iptables, który zrobi mi NAT dla lanu i obsłuży DMZ.
    znalazłem na necie taki opis:
    http://linux.howto.pl/artykuly,linux-20-9-0.html
    wszystko pasuje do mojego zadania ale nie widzę tam NAT, a może jest tylko ja jestem za cienki by to dostrzec

    bo chyba nie wystarczy że dodam do tablicy NAT taki wpis:
    -A POSTROUTING -o eth0 -j SNAT --to-source ip.mojego.eth.0
    i tamte regułki (z linux.howto zmodyfikuje) do swoich warunków...

    podrzućcie jakieś pomysły albo linki bo sam chyba nie dam rady....
    a może ktoś znajdzie chwilę zeby mi to troche przybliżyć...


    zrobiłem tak:
    interfejsy:
    ifconfig eth0 192.84.219.1 netmask 255.255.255.252 - external
    ifconfig eth1 192.84.219.2 netmask 255.255.255.0 - dmz
    ifconfig eth2 192.168.0.1 netmask 255.255.0.0 - internal

    # w pierwszej kolejności ustawiamy NAT
    *nat
    - A PREROUTING –i ! lo –j DROP
    - A POSTROUTING –i ! lo –j DROP
    - A OUTPUT –j DROP
    -A POSTROUTING -o eth0 -j SNAT --to-source 192.84.219.1
    # udostępniono porty (8000:9900) dla komputera 192.168.1.60
    -A PREROUTING -s 192.168.1.60 -p tcp -m tcp --dport 8000:9990 -j ACCEPT
    # domyślna polityka: odrzucamy wszystko na wszystkich
    # interfejsach oprócz loopback
    - A INPUT –i ! lo –j DROP
    - A OUTPUT –i ! lo –j DROP
    - A FORWARD –j DROP
    # definujemy łańcuchy, które łatwo pozwolą orientować się w regułach
    -N internal-dmz
    -N external-dmz
    -N internal-external
    -N dmz-internal
    -N dmz-external
    -N external-internal
    -N icmp-accept
    # łańcuchy dotyczące logów zapory
    -N NEVER
    -N LOGDROP
    -A NEVER -j LOG --log-level alert --log-prefix "filter ERROR: "
    -A NEVER -j DROP
    iptables -A LOGDROP -m limit -j LOG --log-prefix "filter: "
    iptables -A LOGDROP -j DROP
    # łączymy fizyczne interfejsy ze zdefiniowanymi wyżej
    # łańcuchami
    -A FORWARD -i eth2 -o eth1 -j internal-dmz
    -A FORWARD -i eth2 -o eth0 -j internal-external
    -A FORWARD -i eth1 -o eth0 -j dmz-external
    -A FORWARD -i eth1 -o eth2 -j dmz-internal
    -A FORWARD -i eth0 -o eth1 -j external-dmz
    -A FORWARD -i eth0 -o eth2 -j external-internal
    -A FORWARD -j NEVER
    # zezwolenie na niektóre odpowiedzi diagnostyczne
    -A icmp-accept -p icmp --icmp-type destination-unreachable -j ACCEPT
    -A icmp-accept -p icmp --icmp-type source-quench -j ACCEPT
    -A icmp-accept -p icmp --icmp-type time-exceeded -j ACCEPT
    -A icmp-accept -p icmp --icmp-type parameter-problem -j ACCEPT
    # główny ruch na interfejsach zapory
    -A internal-dmz -p tcp -d 192.84.219.3 --dport 25 -j ACCEPT
    -A internal-dmz -p tcp -d 192.84.219.3 --dport 110 -j ACCEPT
    -A internal-dmz -p tcp -d 192.84.219.3 --dport 20 -j ACCEPT
    -A internal-dmz -p tcp -d 192.84.219.3 --dport 21 -j ACCEPT
    -A internal-dmz -p tcp -d 192.84.219.3 --dport 80 -j ACCEPT
    -A internal-dmz -p icmp -j icmp-accept
    -A internal-dmz -j LOGDROP
    #
    -A external-dmz -p tcp -d 192.84.219.3 --dport 25 -j ACCEPT
    -A external-dmz -p tcp -d 192.84.219.3 --dport 20 -j ACCEPT
    -A external-dmz -p tcp -d 192.84.219.3 --dport 21 -j ACCEPT
    -A external-dmz -p tcp -d 192.84.219.3 --dport 80 -j ACCEPT
    -A external-dmz -p icmp -j icmp-accept
    -A external-dmz -j DROP
    #
    -A internal-external -p tcp --dport 80 -j ACCEPT
    -A internal-external -p tcp --dport 22 -j ACCEPT
    -A internal-external -p tcp --dport 21 -j ACCEPT
    -A internal-external -p tcp --dport 443 -j ACCEPT
    -A internal-external -p tcp --dport 53 -j ACCEPT
    -A internal-external -p udp --dport 53 -j ACCEPT
    -A internal-external -p tcp --dport 1024:65535 -j DROP
    -A internal-external -p icmp --icmp-type ping -j ACCEPT
    -A internal-external -j LOG
    -A internal-external -j REJECT

    -A dmz-internal -p tcp ! --syn -s 192.84.219.3 25 -j ACCEPT
    -A dmz-internal -p tcp ! --syn -s 192.84.219.3 20 -j ACCEPT
    -A dmz-internal -p tcp ! --syn -s 192.84.219.3 21 -j ACCEPT
    -A dmz-internal -p tcp ! --syn -s 192.84.219.3 80 -j ACCEPT
    -A dmz-internal -p icmp -j icmp-accept
    -A dmz-internal -j NEVER
    - A dmz-external -p tcp -s 192.84.219.3 25 -j ACCEPT
    -A dmz-external -p tcp -s 192.84.219.3 20 -j ACCEPT
    -A dmz-external -p tcp -s 192.84.219.3 21 -j ACCEPT
    -A dmz-external -p tcp ! --syn -s 192.84.219.3 80 -j ACCEPT
    -A dmz-external -p icmp -j icmp-accept
    -A dmz-external -j NEVER
    -A external-internal -p tcp ! --syn --sport 80 -j ACCEPT
    -A external-internal -p tcp ! --syn --sport 22 -j ACCEPT
    -A external-internal -p tcp ! --syn --sport 20 -j ACCEPT
    -A external-internal -p tcp ! --syn --sport 21 -j ACCEPT
    -A external-internal -p tcp ! --syn --sport 445 -j ACCEPT
    -A external-internal -p tcp ! --syn --sport 53 -j ACCEPT

    -A external-internal -p icmp --icmp-type ping -j ACCEPT
    -A external-internal -j DROP
    # kilka przykładowych dodatkowych reguł podnoszących
    # bezpieczeństwo systemu
    # odrzucamy pingi dłuższe niż 128 bitów – ochrona przed
    # atakiem Ping of death
    -A INPUT -i -p icmp --icmp-type echo-request -m length --length 128:0xffff -j REJECT
    # odrzucamy pofragmentowane pakiety
    -A INPUT -f -j DROP
    # odrzucamy ataki słownikowe na ssh
    -A INPUT -p tcp -m state --state ESTABLISHED --tcp-flags FIN,ACK FIN,ACK --dport 22 -m recent --name sshattack --set
    -A INPUT -p tcp -m state --state ESTABLISHED --tcp-flags RST RST --dport 22 -m recent --name sshattack --set
    -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 60 -m limit --limit 60/minute -j LOG --log-prefix 'SSH attack: '
    iptables -A INPUT -m recent --name sshattack --rcheck --seconds 60 --hitcount 60 -j DROP
    # koniec reguł zapory

    czy to ma prawo działać..?


    dzięki
    i pozdrawiam.
    Ostatnio edytowane przez markossx : 01-26-2007 - 22:59
    ***********
    * markossx *
    ***********

  2. #2
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Czy ma prawo dzialac? Jak dla mnie nie za bardzo...

    1. Jaka masz pule na DMZ - klasa C? Od tego zalezy jak ustawic regulki i przede wszystkim adresy na kartach...
    2. parametr iptables to -A a nie - A :-)
    3. blokowanie ruchu na PREROUTING i POSTROUTING oraz OUTPUT (pierwsze 3 regulki) nie maja sensu zwlaszcza ze pierwsze dwie odnosza sie do int. lo
    4. reszta regul moze zadzialac albo i nie - nie wczytywalem sie...

    Ad. 1.
    Interfejs eth0 i eth1 maja niespojne adresowanie - podsieci sie nakladaja. Tak nie ma prawa byc dopuki karty nie sa w trybie bridge (co i tak nie zadziala bo maja rozne maski sieciowe).
    Nie mozesz miec karty eth0 z adresem .1 i maska .252 (4 adresy) a pozniej na eth1 adresu .2 z maska .0 bo adres .2 nalezy do tej samej podsieci ktora obsluguje eth0.

    Zakladajac ze masz np 8 adresow IP na takim serwerku zrob to tak - podziel siec na 2 czesci po 4 adresy. Twoj ISP kieruje do ciebie siec 192.168.40.0/255.255.255.248 (8 adresow), wiec:
    * 192.168.40.0 - network
    * .1 - router twojego ISP (default gw)
    * .2-.6 - uzyteczne adresy
    * .7 - broadcast

    Dzielimy to teraz na eth0 z adresem .2 i maska .252 (siec 192.168.40.0/255.255.255.252) i w to sie lapia adresy od .0 do .3 (wiec .1 i .2 sa w jedne podsieci). Jako ze eth0 ma adres .2 to ustawiasz defaultowy routing na .1 i to jest twoje wyjscie na swiat.

    Druga pula idzie na DMZ - karta eth1 z adresem sieci 192.168.40.4/255.255.255.252 - adres .4 to network (od biedy mozna ustawic jako eth1), .5 to eth1, .6 do uzytku DMZ, .7 broadcast.

    Przy takiej konfiguracji routing na tym routerze jest taki, ze:
    0.0.0.0 via 192.168.40.1 dev eth0
    192.168.40.0/255.255.255.252 via 192.168.40.2 dev eth0
    192.168.40.4/255.255.255.252 via 192.168.40.5 dev eth1

    Routing zalatwiony, teraz regulki w lancuchu FORWARD

    Ad. 2.

    czeski blad :-)

    Ad. 3.
    Jaki ma sens blokowanie PRE- i POSTROUTING na interfejsach innych niz lo?
    Na lo na pewno nie ma sensu bo to loopback na nim nie ma routingu w zasadzie ale warto wyciac za to pakiety adresowane do puli adresowej 127.0.0.0/8 przychodzace spoza lo (np z WAN)...
    Blokowanie wszystkiego na PRE- i POSTROUTING nie ma moim zdaniem wiekszego sensu - ustaw policy na DROP:

    -P INPUT DROP
    -P OUTPUT DROP
    -P FORWARD DROP

    Zwroc tylko uwage, ze lancuchy INPUT i OUTPUT dotycza tylko ruchu idacego do samego routera a nie tego co idzie do DMZ czy przez NAT. Jasno mowi o tym schemat obslugi pakietow w jadrze Linux'a z serii 2.6.x.

    Jesli chcesz abym to dalej rozwinal i wyjasnil dokladnie to daj znac... podejrzewam ze szczegolnie moze sie przydac wyjasnienie, dlaczego skoro robimy NAT to nie lapie sie on w INPUT i OUTPUT :-)

    Ad.4.
    Wrocimy tu jak zalatwimy poprzednie 3 punkty

    UPDATE:
    Ad. 5. - tak, czwarta regulka robi NAT jesli masz statyczny IP na karcie WAN

    UPDATE 2:
    Znalazlem wlasnie opis fajnego projektu - miniaturowy PC zasilany z 5V, wielkosci moze paczki fajek... ma to to 2x ethernet, instalujesz na karcie CF linux'a i ustawiasz bridge miedzy kartami (przezroczyscie przesyla dane) i odpalasz firewall... mozna tak zrobic przezroczysty firewall zasilany nawet z USB :-) przydatne jak w akademiku reinstalujesz winde i nie chcesz by cie jakis smiec trafil zanim podniesiesz firewall i antywira
    Ostatnio edytowane przez TQM : 02-05-2007 - 23:25

  3. #3
    Zarejestrowany
    Nov 2006
    Skąd
    Polska/Poland
    Postów
    1,191

    Question

    ...

    ad.1 ale wymyśliłem z tą adresacją....

    a jeśli ISP przydzieli tylko 4 adresy to zewnętrzny zostanie jeden i wtedy dla DMZ trzeba przydzielić ip z puli prywatnej...? czy DMZ traci wtedy sens.., czy można DMZ umieścić w sieci z adresami z puli PRIV i w iptables przekierowywać właściwe porty na maszyne/y w DMZ..?
    ale dla jasności przykładu zostańmy przy 8 IP...

    ad2. często mi sie zdarzają...

    ad.3
    dałem tak -A PREROUTING –i ! lo –j DROP dla pewności nie zaszkodzi a ! to logiczne wyłączenie (chyba) czyli DROP wszystko w łańcuchu PREROUTING oprócz loopback..
    łańcuchów INPUT i OUTPUT używamy tylko i wyłącznie w odniesieniu do maszyny robiącej routing (ona ma juz publiczny IP na eth0 więc NAT jej nie potrzebny)
    mógłbyś przybliżyć łańcuchy PRE i POST ROUTING? w tablicy NAT również jest OUTOPUT - do czego służy...?
    nie do końca kumam co jest do czego; PREROUTING to coś w rodzaju FORWARD a POSTROUTING jest jak OUTPUT w filter...
    jest jeszcze dziwna tablica MANGLE...

    wiem, że nic nie wiem...

    pozdrawiam
    ***********
    * markossx *
    ***********

  4. #4
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Cytat Napisał markossx Zobacz post
    ...
    ad.1 ale wymyśliłem z tą adresacją....

    a jeśli ISP przydzieli tylko 4 adresy to zewnętrzny zostanie jeden i wtedy dla DMZ trzeba przydzielić ip z puli prywatnej...?
    Majac 1 IP nadal mozesz miec DMZ i to calkiem fajny
    1 publiczny IP to jednak ogranicznie, ale... mozesz ustawic router tak, ze to co przychodzi na jego adres jest przekierowywane na jakis host w sieci prywatnej, najlepiej podpiety do serwera na fizycznie osobnej karcie sieciowej. Nie martw sie tez o NAT - bedzie on nadal dzialal dla calej sieci lokalnej - dlaczego wyjasnie dalej.
    W nieco bardziej rozbudowanej wersji (jak ktos sie lubi bawic), za jednym adresem IP mozna ukryc cala farme serwerow i zrobic rozkladanie ruchu na wiecej maszyn albo system wysokiej dostepnosci (High Availability), w zasadzie oba rozwiazania sa czesto laczone.

    Cytat Napisał markossx
    ad.3
    [...]
    mógłbyś przybliżyć łańcuchy PRE i POST ROUTING? w tablicy NAT również jest OUTOPUT - do czego służy...?
    nie do końca kumam co jest do czego; PREROUTING to coś w rodzaju FORWARD a POSTROUTING jest jak OUTPUT w filter...
    jest jeszcze dziwna tablica MANGLE...
    To calkiem proste moj drogi Watsonie!
    Kluczem do zrozumienia calosci jest jednak pewien diagram:

    graph2c81ea9b75d296103cca8f42aef46a77.jpg

    Tak wlasnie netfilter widzi przeplyw pakietow w jadrze Linuxa... Nie ustalam tutaj co jest LAN a co WAN - jest wejscie pakietu i wyjscie, kierunek nie ma znaczenia - zasady sa jednakowe!

    Nalezy jednak pamietac, ze w momencie jesli pakiet wychodzi z naszej sieci i robimy na nim NAT (na POSTROUTING), to w drodze powrotnej translacja odwrotna odbedzie sie tak jakby na PREROUTING - tak jakby lustrzane odbicie obrazka (i sytuacji).

    Zacznijmy po kolei:
    1. pakiet przychodzi do systemu przez jakis interfejs (in), po czym przechodzi przez lancuch PREROUTING (zawsze!).
    2. Lancuch PREROUTING ma generalnie 2 bardzo uzyteczne tablice - nat i mangle. Jesli pakiet dotyczy jakiegos polaczenia na ktorym wczesniej zrobilismy NAT zostanie on 'magicznie' zmieniony tak aby pakiet wiedzial gdzie ma wrocic w sieci LAN. Jesli jednak nie dotyczy takiego polaczenia to mozna na nim zrobic DNAT (destination nat), czyli to co wlasnie pytasz - DMZ :-) Po prostu robiac DNAT w naglowku IP pakietu zostaje nadawca ten sam co byl (klienta) ale adres docelowy jest podmieniony na adres serwera w DMZ (chocby to byla siec prywatna). Druga tabela to 'mangle' - tu mozna sie niezle zabawic, odcinajac pakiety jeszcze zanim zapadnie decyzja co z nimi zrobic, czyli mozna odciac pakiet zanim dotrze do lancucha FORWARD albo INPUT, mozna go wykrecic, przepuscic przez wyzymaczke, co kto chce :-) Zastosowanie podam pozniej...
    3. Po przejsciu pakietu przez PREROUTING zapada decyzja co dalej - jesli jest adresowany na adres serwera to idzie na INPUT, jak nie (czyli adresowany lub przeadresowany na DMZ albo LAN) to idzie do lancucha FORWARD.
    4. Lancuchy INPUT i OUTPUT maja swoje zasady chyba jasne... nie trzeba dodawac zbednych uwag? Tutaj tez pojawia sie jedna mozliwosc - cel (parametr -j) na REDIRECT - mozna przekierowac ruch na inny port bez wiedzy klienta.
    5. Lancuch FORWARD ustala co mozna przekazac miedzy sieciami a co nie. Ogolnie nie wystarczy ustawic dobrze routingu w takim routerku, trzeba zezwolic na przekazywanie pakietow na lancuchu FORWARD. Tutaj mozna dodatkowo filtrowac co i jak i gdzie
    6. Po przejsciu przez OUTPUT albo FORWARD pakiet trafia do lancucha PREROUTING - tam jest dodatkowo maglowany znowu na 2 tablicach - mangle i nat. Na tablicy nat robimy jak nazwa mowi NAT a dokladnie SNAT (taki NAT jak potrzebujemy ukryc caly LAN za jednym adresem IP)... Oczywiscie pamietaj o odwracaniu obrazka jak bedzie pakiet wracal Tabela mangle robi to samo co ta w PREROUTING - magluje pakiety jak sie da.
    7. Po przejsciu przez caly ten mlyn (podczas ktorego zapada decyzja co do tego czy pakiet przepuscic, jesli tak to ktoredy [routing] oraz czy czegos w nim na sile nie zmodyfikowac [np. wywalic innym interfejsem niz wskazuje logika]) pakiet wychodzi przez ustalony interfejs wyjsciowy.

    Ot cala filozofia... Jesli ktos nie zna tych podstawowych zasad, to ciezko bedzie skonstruowac logicznie dzialajacy firewall. Dlatego tez zastanawialem sie jaki ma sens obcinania wszystkiego na PREROUTING'u poza interfejsem lo :-) Routing na lo? Nie jestem przekonany... Na pewno warto na tabelach mangle obciac jesl 127.0.0.1 wlazi/wylazi przez ! lo.

    Wracajac do zastosowan - na tabelach nat robisz DNAT (czyli tak jak do DMZ majac serwerek w sieci LAN) oraz SNAT (czyli ukrycie calego LANu za jednym adresem IP).

    Na zakonczenie slowo dlaczego jesli mamy 1 IP i robimy SNAT (caly LAN za 1 adresem IP) a do tego DNAT dla pakietow przychodzacych, to mamy i DMZ i NAT dla LAN dzialajace razem...
    Chodzi o kolejnosc parsowania danych wchodzacych - jesli mowimy o pakiecie wychodzacym z sielo lokalnej to przechodzi on PREROUTING bez zmian, FORWARD, zmieniany jest dopiero na POSTROUTINGu i wypuszczany w swiat.
    Gdy wraca odpowiedz na ten pakiet wpada on w PREROUTING i jest robiona odwrotna operacja jak przy SNAT, pakiet jest przeadresowywany do komputera w sieci LAN. Jesli jednak pakiet nie dotyczy zadnego z polaczen NAT a jest zrobiony DMZ przy uzyciu DNAT to pakiet tai zostanie zmieniony i przekierowany do sieci LAN do serwera ktory jest widoczny publicznie.

    Czy wystarczajaco jasno? Czy cos jeszcze?
    Ostatnio edytowane przez TQM : 02-11-2007 - 10:58

  5. #5
    Zarejestrowany
    Nov 2006
    Skąd
    Polska/Poland
    Postów
    1,191

    Post lepiej chyba się nie da...

    ... tego wytłumaczyć. wydaje mi się że połapałem choć w pukcie 6. zrobiłeś chyba pomyłkę..?

    6. Po przejsciu przez OUTPUT albo FORWARD pakiet trafia do lancucha PREROUTING - tam jest dodatkowo maglowany znowu na 2 tablicach - mangle i nat.
    powinno być chyba ze trafia do POSTROUTING....
    napiszę jak to pojąłem:
    1) host kieruje pakiet do serwera z netu:
    pakiet trafia do PREROUTING gdzie jest kierowany do INPUT - filtr określa co z nim zrobić. koniec.
    2) host kieruje pakiet do komputera w DMZ:
    pakiet trafia do PREROUTING (robimy mu DNAT), trafia do FORWARD a ten przesyła go przez OUTPUT do serwerka w DMZ (nie mam pewności czy dokońca jest tam po drodze output). FORWARD jest właściwie maskaradą... (chyba?).koniec.
    3) komp z LAN chce nawiązać połączenie z hostem z netu:
    wysyła pakiet sync, który przechodzi przez PREROUTING, FORWARD, POSTROUTING (tu zamienia pewne pola w nagłówku żeby pożyczyć mu adresik zewnętrzny) i do netu.
    host z netu odpowiada (sync,ack)pakiet dostaje się do PREROUTING - tu wiadomo, że to jest to konkretne połączenie i zostaje ono zdenatowane (że tak powiem), FORWARD, OUTPUT do odpowiedniej maszyny w LAN.koniec.
    to chyba najistotniejsze scenariusze zdarzeń jakie zachodzą w zaporze z natem.

    jak coś pokręciłem to poproszę o poprawkę...

    podrawiam
    ***********
    * markossx *
    ***********

  6. #6
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Cytat Napisał markossx Zobacz post
    ... tego wytłumaczyć. wydaje mi się że połapałem choć w pukcie 6. zrobiłeś chyba pomyłkę..?


    powinno być chyba ze trafia do POSTROUTING....
    Oczywiscie - dobra uwaga... za duzo razy chyba ten tekst przenosilem i gdzies mi umknelo

    Cytat Napisał markossx
    napiszę jak to pojąłem:
    1) host kieruje pakiet do serwera z netu:
    pakiet trafia do PREROUTING gdzie jest kierowany do INPUT - filtr określa co z nim zrobić. koniec.
    Tak
    Cytat Napisał markossx
    2) host kieruje pakiet do komputera w DMZ:
    pakiet trafia do PREROUTING (robimy mu DNAT), trafia do FORWARD a ten przesyła go przez OUTPUT do serwerka w DMZ (nie mam pewności czy dokońca jest tam po drodze output). FORWARD jest właściwie maskaradą... (chyba?).koniec.
    Nie - wchodzi najpierw przez PREROUTING i na tablicy 'nat' robimy DNAT, pozniej przechodzi przez FORWARD (lub nie ) i wychodzi przez POSTROUTING w ogolnie nie zblizajac sie do INPUT/OUTPUT
    Cytat Napisał markossx
    3) komp z LAN chce nawiązać połączenie z hostem z netu:
    wysyła pakiet sync, który przechodzi przez PREROUTING, FORWARD, POSTROUTING (tu zamienia pewne pola w nagłówku żeby pożyczyć mu adresik zewnętrzny) i do netu.
    host z netu odpowiada (sync,ack)pakiet dostaje się do PREROUTING - tu wiadomo, że to jest to konkretne połączenie i zostaje ono zdenatowane (że tak powiem), FORWARD, OUTPUT do odpowiedniej maszyny w LAN.
    Tez nie do konca... jak pakiet wraca to na PREROUTING bedzie info ze to byl SNAT (tak jak napisales), pozniej FORWARD i POSTROUTING (a nie OUTPUT) do maszyny w LAN.

    Pamietaj ze INPUT i OUTPUT dotycza tylko tego co jest adresowane do serwera i nie dotyczy polaczen na ktorych zrobilismy jakikolwiek NAT (czy to SNAT na POSTROUTINGu dla polaczen wychodzacych z sieci czy tez DNAT na PREROUTINGu dla tego co idzie do DMZ).

    To co dotyczy NAT i przekazywania miedzy interfejsami (polaczenie nie idzie np. do serwera WWW na routerze) nawet nie zblizy sie do INPUT/OUTPUT.

    To jest wlasnie miejsce gdzie prawie kazdy robi blad!

    Wszyscy uparlismy sie na INPUT i OUTPUT (bo wydaja nam sie logiczne) a pozniej wielkie zdziwko czemu firewall puszcza polaczenia ktorych nie powinien

  7. #7
    Zarejestrowany
    Nov 2006
    Skąd
    Polska/Poland
    Postów
    1,191

    Domyślnie ...

    wiedziałem, wiedziałem, wiedziałem
    (nie mam pewności czy dokońca jest tam po drodze output)
    że ten output nie pasuje do układanki
    teraz jaśniutkie jak słoneczko na Teneryfie

    dzięki i zdrówka!
    ***********
    * markossx *
    ***********

Podobne wątki

  1. jakie IP lokalne jest za NAT-em
    By markossx in forum Hacking
    Odpowiedzi: 9
    Autor: 12-04-2006, 19:15
  2. LMS + IPTables
    By szpuni in forum Linux
    Odpowiedzi: 1
    Autor: 10-10-2006, 13:59

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj