Forum Debian Users Gang

Karoll · 2022-09-25 18:05:17

Najpierw dane:

Kod:

uname -a
Linux debian2 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux

Kod:

dpkg -l | grep netfilter-persistent
ii  netfilter-persistent                  1.0.15                           all          boot-time loader for netfilter configuration

Kod:

mark@debian2:~$ update-alternatives --list iptables
/usr/sbin/iptables-legacy
/usr/sbin/iptables-nft

Po zaimplementowaniu tych regol:

Kod:

iptables -F
iptables -F -t nat
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -X

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

# Załaduj moduły śledzące połączenia
modprobe ip_conntrack
modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

conntrack -F

# Błędne pakiety – tablica mangle
iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP 
iptables -t mangle -A PREROUTING -f -j DROP

iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i lo -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -j REJECT --reject-with icmp-host-prohibited 

iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix "outinvalid: "
iptables -A OUTPUT -j LOG --log-prefix "outinvalid: "
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -p icmp -m icmp --icmp-type 0 -j DROP
iptables -A OUTPUT -p tcp -m tcp --dport 23 -j REJECT --reject-with icmp-port-unreachable

# Drop everything else
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

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

Blokuje dostep do Internetu.

Ostatnio edytowany przez Karoll (2022-12-30 13:19:47)

Jacekalex · 2022-09-29 09:53:47

Kod:

iptables -P OUTPUT DROP

Domyślna polityka OUTPUTu blokuje ruch wychodzący tutaj.

Tu masz wyjaśnienie w części "trywialne firewalle":
https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netf … rzyk%C5%82ady

Na przyszłość zainteresuje się też możliwością debugowania firewalla modułem TRACE.
To bardzo ułatwia rozwiązanie podobnych problemów.

https://morfikov.github.io/post/debugowanie-regul-i … target-trace/

Pozdro

Ostatnio edytowany przez Jacekalex (2022-09-29 09:58:54)

Karoll · 2022-09-29 12:04:49

@Jacekalex
Mam wbite do glowy, ze pakiety "splywaja" po regolach z gory na dol i jezeli nie trafia na odpowiednia to ich akcje na samym koncu okresla "polityka domyslna"

Jak z powyzszego wynika, tablica INPUT powinna byc zakonczona -P INPUT DROP, tablica FORWARD odpowiednio -P FORWARD DROP a OUTPUT, -P OUTPUT DROP.
Jest jednak inaczej 3 x DROP na poczatku. Dlaczego ? Dlaczego "polityke domyslna" umieszcza sie na poczatku skryptu zamiast tak jak ja napisalem powyzej ?
https://forum.dug.net.pl/viewtopic.php?id=31730

Mam skrypta gdzie zapora jest restrykcyjna = 3xDROP a dopiero w kolejnych regolach robi sie "tunele dla uprzywilejowanych" To dzialalo. Morfik tez tak zaleca.

Najpierw blokuj dostęp do maszyny, a dopiero potem czyść łańcuchy. Jeśli robisz to w odwrotnej kolejności, to wtedy przez chwile system nie ma żadnego FW i pewne pakiety mogą dotrzeć do maszyny bez żadnego filtrowania.

Tego tez nie rozumiem. Akcja DROP na koncu trawersu jest "terminating" wiec to jest definitywny koniec trawersu pakietu po regolach.
Po co robic "tunele" dla "ubitych" pakietow, i dlaczego to dziala ?

Nigdy tego nie rozumialem.

Wszystkie Twoje wpisy byly dla nmnie zrodlem rzetelnej informacji i powodem trwania przy Debianie (Linuksie) Bardzo prosze, napisz kilka slow zebym to raz na zawsze wlasciwie zrozumial. Z wyrazami szacunku dla Twojej wiedzy i wdziecznosci za cierpliwosc wobec "uzyszkodnika"

Ostatnio edytowany przez Karoll (2022-09-29 21:36:17)

Jacekalex · 2022-09-29 23:24:49

Firewall z gotowca to gotowy problem.

Najpierw się ustala domyślne polityki, potem ustala reguły i po każdej regule sprawdza, czy net działa.

Jeżeli chcesz teraz debugować obecnego firewalla, to moduł TRACE jest jedynym wyjściem.
Masz tym wyżej sznurek do opisu po polsku.

Zobacz też, czy nie ma jakichś trywialnych problemów, np FW ubija ruch DHCP z routerem, wtedy w ogóle nie będzie netu bo nie ma adresu na karcie i domyślnej trasy routingu.
Możliwe jest też, że np jest przez arptables albo przez sysctl zablokowany lub wyłączony ruch ARP, i też nie będzie netu.

Zainteresuj się też tcpdumpem, wiresharkiem, etherape, iptstate i nethogs.
To są programy do monitorowania różnych parametrów sieci na żywo.

Ostatnio edytowany przez Jacekalex (2022-09-29 23:28:10)

Karoll · 2022-09-30 10:23:31

@Jacekalex
Punktem startowym przy pisaniu firewalla jest "default policy"
Mam z tym problemy zrozumienia, ktore przedstawilem we wpisie #3.
Bez Twojego wyjasnienia do przedstawionych tam moich pytan, nawet nie mam co zaczynac pisac regol.
Kiedy juz logika polityki domyslnej bedzie dla mnie juz wiadoma, to biore sie za debugowanie, wg Twojej sugestii .
Jeszcze raz, prosze - wroc do wpisu #3.

Ps. Wywalilem skrypt firewalla, oczyscilem pamiec za pomoca " netfilter-persistent flush " Reboot i system ma dostep do Internetu. Powodem klopotu sa bledne regoly firewalla ze wskazaniem na " polityke domyslna " Prosze come back to #3.

Jacekalex · 2022-09-30 14:12:32

TU masz po polsku instrukcję do iptables z niezłymi wyjaśnieniami:
https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netfilter#iptables

RTFW.

Albo zmigruj na nftables, ten się instaluje od razu z niezłymi domyślnymi regułami dla desktopa,
zawartymi w pliku:

Kod:

/usr/share/doc/nftables/examples/workstation.nft

z następująca zawartością:

Kod:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;

        # accept any localhost traffic
        iif lo accept

        # accept traffic originated from us
        ct state established,related accept

        # activate the following line to accept common local services
        #tcp dport { 22, 80, 443 } ct state new accept

        # accept neighbour discovery otherwise IPv6 connectivity breaks.
        ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit,  nd-router-advert, nd-neighbor-advert } accept

        # count and drop any other traffic
        counter drop
    }
}

To by było na tyle

Ostatnio edytowany przez Jacekalex (2022-09-30 14:14:04)

morfik · 2022-10-03 09:06:42

Kto pisał ten skrypt FW, bo tam jest taka patologia, że chyba komuś trzeba by zwoje mózgowe wyprostować. xD

Karoll napisał(-a):
Jak z powyzszego wynika, tablica INPUT powinna byc zakonczona -P INPUT DROP, tablica FORWARD odpowiednio -P FORWARD DROP a OUTPUT, -P OUTPUT DROP.
Jest jednak inaczej 3 x DROP na poczatku. Dlaczego ? Dlaczego "polityke domyslna" umieszcza sie na poczatku skryptu zamiast tak jak ja napisalem powyzej ?
https://forum.dug.net.pl/viewtopic.php?id=31730

Nie tablica INPUT czy FORWARD, a łańcuch. Tablice to masz mangle, raw, filter i nat. Czemu jest DROP na początku? By zablokować ruch sieciowy przed czyszczeniem reguł FW. Bo gdy wyczyścisz reguły, to pakiety będą docierać do maszyny bez filtrowania, a domyślna polityka (ustawiona na DROP) zwyczajnie je zablokuje i żaden pakiet do maszyny nie trafi na czas ustawiania FW, co znacząco poprawia bezpieczeństwo maszyny.

Karoll napisał(-a):
Tego tez nie rozumiem. Akcja DROP na koncu trawersu jest "terminating" wiec to jest definitywny koniec trawersu pakietu po regolach.
Po co robic "tunele" dla "ubitych" pakietow, i dlaczego to dziala ?

Nigdy tego nie rozumialem.

Np. dla statystyk. Ja u siebie mam np. lokalny resolver na bazie dnscrypt i u mnie żadne zapytanie DNS nie może pójść inną drogą. A mimo to, mam na zaporze takie wpisy:

Kod:

# nft list chain inet filter OUTPUT
table inet filter {
        chain OUTPUT {
                type filter hook output priority filter; policy drop;
                jump check-state
                oif "lo" accept
                ...
                udp dport 53 counter packets 8 bytes 1056 jump check-dns
                tcp dport 53 counter packets 0 bytes 0 jump check-dns
                ...
        }
}

# nft list chain inet filter check-state
table inet filter {
        chain check-state {
                ct state invalid counter packets 1036 bytes 43180 drop
                ct state { established, related } accept
        }
}

# nft list chain inet filter check-dns
table inet filter {
        chain check-dns {
                ip daddr 9.9.9.9 counter packets 0 bytes 0 accept comment "dnscrypt check"
                meta cgroup 85 counter packets 0 bytes 0 accept comment "nslookup"
                meta cgroup 86 counter packets 0 bytes 0 accept comment "dig"
                meta cgroup 87 counter packets 0 bytes 0 accept comment "host"
                meta cgroup 88 counter packets 0 bytes 0 accept comment "delv"
                meta cgroup 73 counter packets 0 bytes 0 accept comment "nmap"
                limit rate 30/minute burst 1 packets log prefix "* IPTABLES:DNS * " flags all counter packets 6 bytes 792
                counter packets 8 bytes 1056 drop
        }
}

U mnie w OUTPUT, zapytania DNS są przetwarzane przez regułę oif "lo" accept, bo dnscyrpt jest uruchomiony na interfejsie pętli zwrotnej. Do łańcucha check-dns są przekierowywane pakiety które lecą na port 53/TCP/UDP, tj. te pozostałe, które nie zostaną odebrane przez dnscrypt, np. widoczne wyżej aplikacje w komentarzu do reguł — one czasami muszą rozwiązywać nazwy przy wykorzystaniu innych adresów DNS, co pomaga w diagnostyce sieci. Ale jak widać, domyślna polityka tego łańcucha jest na DROP, czyli gdyby pominąć te regułki w tym łańcuchu to jeśli by się zdarzył pakiet wysłany przez aplikację bezpośrednio na port 53/TCP/UDP z pominięciem systemowego resolvera (tego który siedzi w /etc/resolv.conf), to tutaj zostanie zablokowany. Podobnie sprawa wygląda, gdyby ktoś/coś z jakiegoś powodu zmieniło konfigurację sieci i zapytania DNS by szły na inny adres IP, np. 8.8.8.8, wtedy rzut oka na FW do łańcucha check-dns raz dwa pomaga ustalić WTF i nie trzeba przy tym dodawać nowych reguł w czasie rzeczywistym. To tak apropo reguł blokujących, gdy domyślna polityka FW jest na DROP — to pomaga w rozwiązywaniu problemów, a poza tym, wszytko ładnie widać, że FW działa jak trza. xD

Karoll · 2022-10-03 11:14:04

Konstruktywna krytyka to konstruktywna pomoc bo odslania niewiedze badz bledy w mysleniu, dziekuje za ten wpis. Prosze zarazem o odrobine cierpliwosci zebym raz na zawsze mial to "poukladane"

Napisales:

Czemu jest DROP na początku? By zablokować ruch sieciowy przed czyszczeniem reguł FW. Bo gdy wyczyścisz reguły, to pakiety będą docierać do maszyny bez filtrowania, a domyślna polityka (ustawiona na DROP) zwyczajnie je zablokuje i żaden pakiet do maszyny nie trafi na czas ustawiania FW

Rozumiem to tak: w budynku "filter" sa 3 kondygnacje, najwyzsza to INPUT (lancuch), wewnatrz jest korytarz z drzwiami (regoly) wszystkie drzwi sa zamkniete (lub jedne otwarte), na koncu jest slepa sciana (polityka domyslna) DROP.

Co masz na mysli piszac "czyszczenie regol FW "? (milisekundy potrzebne na: wykonanie? zastosowanie? aktualizowanie? FW itp/itd)
czy tez np:
iptables -F
iptables -X
umieszczone przed polityka domyslna ?

Czy Twoim zdaniem prawdziwe jest stwierdzenie, ze "regoly polityki domyslnej zawsze piszemy na poczatku skryptu FW ale mimo tego one zawsze dzialaja po ostatniej regule danego lancucha" ??

Ps. Co Twoim zdaniem bylo najbardziej razacymi bledami w podanym powyzej skrypcie ?? Majac odpowiednie prawidlowe (Twoje) regoly moglbym przeanalizowac i skorygowac na spokojnie. Mysle oczywiscie o iptables a nie nftables !

Ostatnio edytowany przez Karoll (2022-10-03 17:15:41)

Jacekalex · 2022-10-03 18:51:36

Reguły polityki domyślnej działają na końcu danego łańcucha po zakończeniu przetwarzania reguł danego łańcucha.
Do tej polityki domyślnej nie dotrze pakiet, którego przetwarzanie skończy się w jakiejś regule kończącej jego przetwarzanie, jak ACCEPT, DROP czy REJECT.

morfik · 2022-10-03 20:10:20

Karoll napisał(-a):
Co masz na mysli piszac "czyszczenie regol FW "? (milisekundy potrzebne na: wykonanie? zastosowanie? aktualizowanie? FW itp/itd)
czy tez np:
iptables -F
iptables -X
umieszczone przed polityka domyslna ?

No to właśnie jest czyszczenie reguł. Wtedy w filtrze nie ma żadnych reguł, a jak dodatkowo ma on jeszcze polityki ACCEPT na łańcuchach, to ruch który dotrze w tym czasie do maszyny, nie jest w żaden sposób filtrowany, a to źle i dlatego lepiej miejscami to zamienić. xD

Karoll napisał(-a):
Czy Twoim zdaniem prawdziwe jest stwierdzenie, ze "regoly polityki domyslnej zawsze piszemy na poczatku skryptu FW ale mimo tego one zawsze dzialaja po ostatniej regule danego lancucha" ??

Politykę domyślną dla łańcuchów ustawia się niezależnie od reguł w tym łańcuchu. Jeśli dodajesz 10 reguł jedna po drugiej, to w takiej kolejności będą one w tym łańcuchu siedzieć (chyba, że na sztywno te reguły wpiszesz na określone miejsce korzystają z opcji iptables). Natomiast ustawianie polityki domyślnej łańcucha może nastąpić w dowolnym momencie pracy maszyny. Może to być przed załadowaniem reguł, po załadowaniu reguł, w trakcie ładowania reguł (np. załadujesz 5 reguł z tych 10). Niemniej jednak, ja zawsze zaczynam od blokowania ruchu, a dopiero zmiany reguł, tak by mi nic w między czasie nie przeszło i nie zostało oznaczone jako ESTABLISHED, co po załadowaniu reguł i ustawieniu domyślnej polityki na DROP może ominąć te reguły, bo w FW pakiety ESTABLISHED są zwykle akceptowane. Dlatego też powinno się czyścić tablicę conntrack'a po załadowaniu polityki FW, by zresetować wszystkie połączenia.

Karoll napisał(-a):
Ps. Co Twoim zdaniem bylo najbardziej razacymi bledami w podanym powyzej skrypcie ?? Majac odpowiednie prawidlowe (Twoje) regoly moglbym przeanalizowac i skorygowac na spokojnie. Mysle oczywiscie o iptables a nie nftables !

-- czyszczenie FW przed ustawieniem polityki na DROP
-- ładowanie modułów kernela w skrypcie
-- filtrowanie pakietów w tablicy mangle
-- blokowanie pingu
-- mieszanie -m state z -m conntrack --ctstate
-- w łańcuchu FORWARD jest reguła mająca interfejs pętli zwrotnej
-- brak limitowania ilości logów
-- brak konsekwencji w stosowaniu blokowania stanu INVALID przed/po ESTABLISHED
-- brak poprawnego zamykania połączeń
-- podwójne ustawienie polityki domyślnej w jednym skrypcie

Karoll · 2022-10-04 11:22:15

Twoje wczorajsze rady przyniosly wymierny skutek w postaci poprawionego skryptu:

Oczekiwane skutki dzialania FW:
- na wejsciu: logowanie i blokowanie prob nawiazania "nieuprawnionych" polaczen.
- na wyjsciu: logowanie i blokowanie prob "nieuprawnionego " trafficu zaincjonowanego z naszego komputera, np: usluga, aplikacja, biblioteka.
- blokada IPv.6 na poziomie skryptu.

Kod:

#!/bin/sh 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
conntrack -F
iptables -I INTPUT -m conntrack --ctstate NEW,INVALID -j LOG --log-prefix "ininvalid: "
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
iptables -A INPUT -f -j DROP
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -I OUTPUT -m conntrack --ctstate NEW,INVALID -j LOG --log-prefix "outinvalid: "
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

Wazny wniosek: Polityka domyslna 3xDROP nie odcina dostepu, o ile jest poprzedzona wlasciwie skonfigurowanymi regulami.

Napisales:

-- brak limitowania ilości logów

Zamierzalem to robic za pomoca logrotate"
Ze skryptu ???

Napisales:

-- brak poprawnego zamykania połączeń

Prosze o wyjasnienie, nie rozumiem.

Ps. Kolejnosc regol, czy jest wazna? W/g jakiego kryterium ustawiac ?
- rodzaj "akcji"
LOG
DROP (jak u mnie)
ACCEPT
- wielkosc transferu np z komendy"

Kod:

iptables -vnL --line-numbers

- rodzaj protokolu.

Ps. Co pominolem a Twoim zdaniem powinno byc w skrypcie ?

Ostatnio edytowany przez Karoll (2022-10-04 11:24:42)

Jacekalex · 2022-10-04 16:53:06

Zrób sobie najpierw na czystym FW domyślne polityki, a potem dodawaj po jednej regule do łańcucha, kontrolując, czy jest internet.

Jak tak próbujesz rzeźbić skrypta bez większego doświadczenia, to tylko czas tracisz, bo nie wiesz nawet, która reguła blokuje takie czy inne połączenie.
Rzeźbiąc takie skrypty możesz się nawet pół roku bawić firewallem bez żadnego sensownego wyniku.

Kod:

iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Tak wygląda podstawowy FW tablicy FILTER, możesz od niego zacząć budowę jakichś większych kombinacji, net będzie działał na tym.

Ostatnio edytowany przez Jacekalex (2022-10-04 17:03:42)

Karoll · 2022-10-04 19:13:54

@Jacekalex
To wszystko prawda co piszesz, ale korespondencja z Morfikiem daje mi bardzo wiele, pokazujac gdzie zle mysle a takze czego sie trzymac.
Odpowiedzi Morfika ustawiaja mnie na prawidlowym generalnym "kursie"
Jak poznam odpowiedzi na 3 ostatnie pytania to wtedy przystapie doi budowy FW w/g Twojej rady - regula po regule.

Ostatnio edytowany przez Karoll (2022-10-04 19:17:31)

morfik · 2022-10-05 06:18:51

Karoll napisał(-a):
Twoje wczorajsze rady przyniosly wymierny skutek w postaci poprawionego skryptu:

- blokada IPv.6 na poziomie skryptu.

Jak już tak bardzo nie chcesz ipv6, to wyłącz go w kernelu (przez sysctl, można wyłączyć cały ipv6 albo przydzielanie adresacji, obecnie appki mogą mieć problemy gdy cały stos się wyłączy, z kolei jak blokujesz pakiety na FW, to mogą się pojawić spore opóźnienia w działaniu sieci bo appki mogą preferować wysyłanie pakietów pierw po ipv6 i jak to zadanie się nie powiedzie to dopiero po ipv4, dlatego nie blokuj ipv6 na FW),

Karoll napisał(-a):
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

Takich pakietów nie powinno się zrzucać a poprawnie zamykać połączenia, np.

Kod:

$ipt -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -m comment --comment "Connections not started by SYN"

I lepiej nie loguj połączeń w stanie NEW, przynajmniej na wyjściu, bo ci zaspamią one log.

Karoll napisał(-a):
Napisales:
-- brak limitowania ilości logów
Zamierzalem to robic za pomoca logrotate"
Ze skryptu ???

Chodziło o limitowanie w regułach, np:

Kod:

-m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix "* IPTABLES: TCP-NEW * " --log-ip-options --log-tcp-options

Karoll napisał(-a):
Napisales:
-- brak poprawnego zamykania połączeń
Prosze o wyjasnienie, nie rozumiem.

Takie reguły na końcu INPUT

Kod:

$ipt -A INPUT -p tcp -j REJECT --reject-with tcp-reset
$ipt -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
$ipt -A INPUT -j REJECT --reject-with icmp-proto-unreachable

Karoll napisał(-a):
Ps. Kolejnosc regol, czy jest wazna? W/g jakiego kryterium ustawiac ?

No jest ważna, bo jak zablokujesz pakiet to jak go w następnej regule zalogujesz? xD Więc najpierw logowanie a dopiero blokowanie.

Karoll napisał(-a):
Ps. Co pominolem a Twoim zdaniem powinno byc w skrypcie ?

Komentarze do reguł via

Kod:

-m comment --comment "jakis tam opis"

Karoll · 2022-10-05 12:43:47

W tym wpisie sa 2 problemy:
1 - poprawnosc regol FW i komunikat bledu.
2 - relacje miedzy uslugami iptables i netfilter-persistent.

1.....
Zastosowalem sie i przerobilem FW skrypt:

Kod:

#!/bin/sh 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

conntrack -F

iptables -I INTPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix "ininvalid* " --log-ip-options --log-tcp-options
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -m comment --comment "Connections not started by SYN"
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP m comment --comment “Drop SYN packets with suspicious MSS value”
iptables -A INPUT -f -j DROP
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset -m comment --comment "poprawne zamykanie polaczen"
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -I OUTPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix "outinvalid* " --log-ip-options --log-tcp-options
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Wyczyscilem wszystkie regoly w pamieci za pomoca:

Kod:

sudo service netfilter-persistent flush

oraz

Kod:

iptables -F
          iptables -X

Wylaczylem netfilter-persistent zeby nie konfliktowal z iptables.

Kod:

systemctl disable netfilter.persistent
          systemctl stop netfilter.persistent

Skonfigurowalem iptables metoda skryptowa tzn:
najpierw:

Kod:

nano /etc/network/if-pre-up.d/firewall

Wpisanie regol do pliku.
Nastepnie

Kod:

chmod 755 /etc/network/if-pre-up.d/firewall

Chce zaimplementowac regoly do FW:

Kod:

sudo iptables-restore < /etc/network/if-pre-up.d/firewall

I Dzonk - komunikat:

Kod:

iptables-restore: line 2 failed

Sprawdzam basha:

Kod:

bash -x /etc/network/if-pre-up.d/firewall
+ iptables -P INPUT DROP
+ iptables -P OUTPUT DROP
+ iptables -P FORWARD DROP
+ conntrack -F
/etc/network/if-pre-up.d/firewall: line 6: conntrack: command not found
+ iptables -I INTPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix 'ininvalid* ' --log-ip-options --log-tcp-options
iptables: No chain/target/match by that name.

2.....
Jest jeszcze jedna dziwna kwestia - relacja miedzy uslugami: iptables i netfilter-persistent:

Kod:

root@debian:/home/mark# systemctl status netfilter-persistent
● netfilter-persistent.service - netfilter persistent configuration
     Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/netfilter-persistent.service.d
             └─iptables.conf
     Active: inactive (dead)
       Docs: man:netfilter-persistent(8)
root@debian:/home/mark# systemctl status iptables
● iptables.service - netfilter persistent configuration
     Loaded: loaded (/etc/alternatives/iptables.service; alias)
     Active: active (exited) since Wed 2022-10-05 10:07:56 IST; 1h 24min ago
       Docs: man:netfilter-persistent(8)
    Process: 4111 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, status=0/SUCCESS)
   Main PID: 4111 (code=exited, status=0/SUCCESS)
        CPU: 6ms

Oct 05 10:07:57 debian netfilter-persistent[4109]: Automatic flush disabled; use '/usr/sbin/netfilter-persistent flush'
Oct 05 10:07:56 debian systemd[1]: iptables.service: Succeeded.
Oct 05 10:07:56 debian systemd[1]: Stopped netfilter persistent configuration.
Oct 05 10:07:57 debian netfilter-persistent[4113]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables start
Oct 05 10:07:56 debian systemd[1]: Starting netfilter persistent configuration...
Oct 05 10:07:57 debian netfilter-persistent[4114]: Warning: skipping IPv4 (no rules to load)
Oct 05 10:07:56 debian systemd[1]: Finished netfilter persistent configuration.
Oct 05 10:07:57 debian netfilter-persistent[4113]: run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start
Oct 05 10:07:57 debian netfilter-persistent[4115]: Warning: skipping IPv6 (no rules to load)

Mowiac zwiezle, mimo ze mam usluge "netfilter-persistent" nieaktywna a usluge "iptables" aktywna to czyszczenie regol moge zrobic tylko z netfilter-persistent !
za pomoca komendy:

Kod:

sudo service netfilter-persistent flush

Ostatnio edytowany przez Karoll (2022-10-05 13:05:44)

morfik · 2022-10-05 13:49:21

No to doinstaluj sobie conntrack.

Kod:

# apt-file search bin/conntrack

iptables -I INTPUT moze INPUT? xD

Ja nie używałem nigdy systemowych usług od FW, tylko sobie sam zawsze robiłem skrypt i go wywoływałem w odpowiednim momencie startu systemu, to ci nic o tych usługach nie powiem.

Ostatnio edytowany przez morfik (2022-10-05 13:49:54)

Karoll · 2022-10-05 17:59:07

Conntrack zainstalowany i zaladowany:

Kod:

root@debian:/home/mark# dpkg -l | grep conntrack
ii  conntrack                             1:1.4.6-2                        amd64        Program to modify the conntrack tables
ii  conntrackd                            1:1.4.6-2                        amd64        Connection tracking daemon
ii  libnetfilter-conntrack3:amd64         1.0.8-3                          amd64        Netfilter netlink-conntrack library
root@debian:/home/mark# lsmod | grep nf_conntrack 
nf_conntrack_ftp       24576  1 nf_nat_ftp
nf_conntrack_netlink    57344  0
nfnetlink              16384  7 nf_conntrack_netlink,nf_tables
nf_conntrack          176128  5 xt_conntrack,nf_nat,nf_nat_ftp,nf_conntrack_netlink,nf_conntrack_ftp
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  3 nf_conntrack,nf_nat,nf_tables

Skrypt poprawiony:

Kod:

              
#!/bin/sh 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

conntrack -F

iptables -I INPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix "ininvalid* " --log-ip-options --log-tcp-options
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -m comment --comment "Connections not started by SYN"
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP 
iptables -A INPUT -f -j DROP
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT -m comment --comment "loopback"
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset -m comment --comment "poprawne zamykanie polaczen"
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -I OUTPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix "outinvalid* " --log-ip-options --log-tcp-options
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Bash nie wykazuje bledu:

Kod:

bash -x /etc/network/if-pre-up.d/firewall
+ iptables -P INPUT DROP
+ iptables -P OUTPUT DROP
+ iptables -P FORWARD DROP
+ conntrack -F
conntrack v1.4.6 (conntrack-tools): connection tracking table has been emptied.
+ iptables -I INPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix 'ininvalid* ' --log-ip-options --log-tcp-options
+ iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
+ iptables -A INPUT -p tcp '!' --syn -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -m comment --comment 'Connections not started by SYN'
+ iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss '!' --mss 536:65535 -j DROP
+ iptables -A INPUT -f -j DROP
+ iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT -m comment --comment loopback
+ iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+ iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset -m comment --comment 'poprawne zamykanie polaczen'
+ iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
+ iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable
+ iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP
+ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+ iptables -I OUTPUT -m conntrack -p tcp --ctstate NEW,INVALID -m limit --limit 30/m --limit-burst 10 -j LOG --log-level 4 --log-prefix 'outinvalid* ' --log-ip-options --log-tcp-options
+ iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
+ iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Ale kiedy usiluje przywrocic regoly z pliku:

Kod:

sudo iptables-restore -t /etc/network/if-pre-up.d/firewall
iptables-restore: line 2 failed

Regoly samoistnie powracaja po ok 2 min i odcinaja Internet ?!
Usunolem tresc skrypta i wyczyscilem regoly.
Mysle, ze z wlasna usluga odpalajaca skrypta FW to masz 200% racji.
Moglbym zobaczyc jak ja zbudowales ?

Ps. Sprobowalem poprzez "iptables-legacy-save" Regoly weszly z konsoli bez problemu, ale po komendzie:

Kod:

sudo iptables-legacy-restore

odciely Internet.
Skrypt FW jednak odcina ???
Po zmianie polityki domyslnej na wyjsciu na ACCEPT - Internet dziala.
Co zatrzymuje polityka domyslna na wyjsciu na DROP, ze pakiety z flagami: RELATED, ESTABLISHED nie sa w stanie ustanowic polaczenia ?

Ostatnio edytowany przez Karoll (2022-10-05 20:46:51)

morfik · 2022-10-06 06:01:56

No bo w OUTPUT nie masz akceptowania nowych połączeń, tj. tych w stanie NEW, to się nie dziw, że nie działa net. xD

Tutaj masz projekt FW na maszyny klienckie.

Jacekalex · 2022-10-06 06:22:16

Kod:

sudo iptables-restore -t /etc/network/if-pre-up.d/firewall
iptables-restore: line 2 failed

To akurat jest prawidłowe zachowanie, iptables-restore nie wczytuje skryptów powłoki, tylko reguły zapisane przez iptables-save.
Natomiast lokalizacja

Kod:

/etc/network/if-pre-up.d/

jest na skrypty powłoki, które maja wstać automatycznie przed podniesieniem interfejsów sieciowych.
Tam się umieszcza skrypty i daje im uprawnienia 700, właściciela i grupę root:root.
mniej więcej tak to powinno wyglądać:

Kod:

ls -l /etc/network/if-pre-up.d/nftables.sh 
-rwx------. 1 root root 57 2021-05-14  /etc/network/if-pre-up.d/nftables.sh

RTFM:

Kod:

man iptables-save

Kod:

man iptables-restore

To by było na tyle

Karoll · 2022-10-06 10:35:58

@Morfik
Twoje arty na https://morfikov.github.io/ znam bardzo dobrze, ten o FW rowniez - to lektura obowiazkowa, czytalem wielokrotnie. Szkoda tylko ze od pewnego czasu odszedles od Debiana i Linuksa bardziej w strone komorek. Mysle ze motywacje podales kiedys w jednym celnym zdaniu.

Dla Morfika, szacunek za wiedze i wdziecznosc za prace i czas

@Jacekalex
Jak zwykle bezblednie.
Tego nie wiedzialem:

Kod:

 iptables-restore nie wczytuje skryptów powłoki, tylko reguły zapisane przez iptables-save.

a teraz dziala, super,podziekowania.

Ps. Prosze nie zamykajcie watku, bo pewnie niebawem bede zaskoczony nowym problemem, jak chociazby:

1/
Morfik napisal,

No bo w OUTPUT nie masz akceptowania nowych połączeń, tj. tych w stanie NEW, to się nie dziw, że nie działa net. xD

A ja mysle tak, dlaczego nie mam akceptowania nowych polaczen skoro, uzywajac np przegladarki powoduje zainicjowanie transferu NOWYCH pakietow, ktore sa filtrowane na regolach wyjscia FW by nastepnie poprzez: DNS resolver, DNS server, inne servery i routery wrocic poprzez wejscie FW do maszyny inicjujacej. Dopiero wtedy w moim zrozumieniu uprawniona jest flaga RELATED, ESTABLISHED. Wszystko co wychodzi po raz pierwszy na wyjsciu FW powinno miec flage NEW.
Gdzie jest blad w moim mysleniu ??
2/ Ktore pakiety i dlaczego "nie zalapuja sie" na zadna regule (np, RELATED, ESTABLISHED) FW na wyjsciu i dlaczego jeszcze musza miec polityke domyslna na ACCEPT zeby "przejsc" do WAN ??

morfik · 2022-10-06 13:49:30

Każde nowe połączenie jest w stanie NEW,a u ciebie jest brak akceptowania tego stanu, więc żadne połączenie nie może się stworzyć i nie dochodzi do wymiany informacji z drugą stroną. Nie trzeba ustawiać polityki w OUTPUT na ACCEPT ale jeśli nie filtrujesz ruchu pojedynczych aplikacji via cgroups albo jakie inne rozwiązanie, to DROP w OUTPUT jest trochę bez sensu.

Jak coś to tutaj masz kawałek mojego FW (zapisz sobie bo po 24h zniknie): xD
https://pastebin.com/raw/xTt3JmSf

Ostatnio edytowany przez morfik (2022-10-06 14:36:07)

Karoll · 2022-10-06 15:24:20

Jezeli wolno mysle, to przepraszam, ale naprawde sie staram, poza tym korespondencja z Toba to "uczta intelektualna"
Napisales:

Każde nowe połączenie jest w stanie NEW,a u ciebie jest brak akceptowania tego stanu, więc żadne połączenie nie może się stworzyć i nie dochodzi do wymiany informacji z drugą stroną.

a\ Pierwsza czesc zdania zgadza mi sie absolutnie, ale dlaczego pakiety w stanie NEW umozliwiaja polaczenie dopiero kiedy w FW jest RELATED, ESTABLISHED ?
b\ Ktore pakiety w naszym powyzszym skrypcie FW byly zablokowane i nie wydostaly sie do WAN ?

Ps.Podziekowal za linka, jak poprawnie ogarne ogolny mechanizm iptables, nastepny krok to nftables.

Ostatnio edytowany przez Karoll (2022-10-06 15:28:56)

Jacekalex · 2022-10-06 15:55:30

Karoll napisał(-a):
a\ Pierwsza czesc zdania zgadza mi sie absolutnie, ale dlaczego pakiety w stanie NEW umozliwiaja polaczenie dopiero kiedy w FW jest RELATED, ESTABLISHED ?

RTFW:
https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netf … rzyk%C5%82ady
a dokładnie:

https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netfilter/iptables/przyk%C5%82ady napisał(-a):
trywialne firewalle

Wydawać by się mogło, że najprostszym firewallem (dla komputera nie będącego routerem) będzie następująca konfiguracja:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

Jednak spowoduje ona natychmiastowe odcięcie od sieci. Jest to spowodowane tym, że łańcuchy w tablicy filter widzą wszystkie pakiety. Oznacza to, że domyślna polityka DROP łańcucha INPUT dotyczyć będzie również pakietów należących do połączeń inicjowanych przez sam komputer! Poprawną konfiguracją uniemożliwiającą dostęp z zewnątrz do komputera, ale jednocześnie pozwalającą na inicjowanie połączeń będzie:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

4. reguła używa modułu conntrack, który pozwala dopasowywać stany połączeń widziane przez mechanizm śledzenia conntrack.

To by było na tyle

Ostatnio edytowany przez Jacekalex (2022-10-06 15:56:09)

Karoll · 2022-10-06 18:08:00

To musi byc kwestia mojego nieprecyzyjnego jezyka, bardzo przepraszam.
Jeszcze raz.

1 - Dlaczego na wyjsciu FW stosuje sie regoly z RELATED, ESTABLISHED, kiedy tam wszystkie pakiety sa NEW ? Przeciez one sa dopiero co utworzone i dopiero wychodza do WAN ? ( jak nowe samochody z fabryki na drogi naszego biednego kraju)

2 - Dlaczego nasz powyzszy skrypt majacy domyslna polityke DROP na wyjsciu, odcina Internet, skoro pakiety "splywajac" po regolach z gory na dol musza wczesniej trafic na regoly z: RELATED, ESTABLISHED, co powinno umozliwic nawiazanie polaczenia ?

Ps. O conntracku mysle, ze troche wiem i jego roli w "statefull firewall", bez conntracka czyli sledzenia stanu pakietow jest: "stateless firewall". Moja niewiedza dotyczy trawersu pakietow w "stanowym firewall.u" w szczegolnosci w tablicy "filter" i lancuchu "OUTPUT"

morfik · 2022-10-06 19:16:46

Karoll napisał(-a):
a\ Pierwsza czesc zdania zgadza mi sie absolutnie, ale dlaczego pakiety w stanie NEW umozliwiaja polaczenie dopiero kiedy w FW jest RELATED, ESTABLISHED ?
b\ Ktore pakiety w naszym powyzszym skrypcie FW byly zablokowane i nie wydostaly sie do WAN ?

To połączenie jest w stanie ESTABLISHED, nie FW. Tu jest kawałek mojego pliku sysctl.conf, może to ci rozjaśni jak wyglądają połączenia. xD

Kod:

# Połączenie TCP może znajdować się w jednym z następujących stanów:
#  LISTEN        - gotowość do przyjęcia połączenia na określonym porcie przez serwer.
#  SYN_SENT      - pierwsza faza nawiązywania połączenia przez klienta. Wysłano pakiet z flagą SYN.
#                   Oczekiwanie na pakiet SYN+ACK.
#  SYN_RECEIVED  - otrzymano pakiet SYN, wysłano SYN+ACK. Trwa oczekiwanie na ACK. Połączenie jest
#                   w połowie otwarte (half-open).
#  ESTABLISHED   - połączenie zostało prawidłowo nawiązane. Prawdopodobnie trwa transmisja danych.
#  FIN_WAIT-1    - wysłano pakiet FIN. Dane wciąż mogą być odbierane ale wysyłanie jest już
#                   niemożliwe.
#  FIN_WAIT-2    - otrzymano potwierdzenie własnego pakietu FIN. Oczekuje na przesłanie FIN od
#                   serwera.
#  CLOSE_WAIT    - otrzymano pakiet FIN, wysłano ACK. Oczekiwanie na przesłanie własnego pakietu
#                   FIN (gdy aplikacja skończy nadawanie).
#  CLOSING       - jednoczesne obustronne zamknięcie połączenia.
#  LAST_ACK      - otrzymano i wysłano FIN. Trwa oczekiwanie na ostatni pakiet ACK.
#  TIME_WAIT     - oczekiwanie w celu upewnienia się, że druga strona otrzymała potwierdzenie
#                   rozłączenia. Zgodnie z RFC 793 połączenie może być w stanie TIME-WAIT najdłużej
#                   przez 4 minuty.
#  CLOSED        - połączenie jest zamknięte.
#
#                              +---------+ ---------\      active OPEN
#                              |  CLOSED |            \    -----------
#                              +---------+<---------\   \   create TCB
#                                |     ^              \   \  snd SYN
#                   passive OPEN |     |   CLOSE        \   \
#                   ------------ |     | ----------       \   \
#                    create TCB  |     | delete TCB         \   \
#                                V     |                      \   \
#                              +---------+            CLOSE     \   \
#                              |  LISTEN |          ----------  |    |
#                              +---------+          delete TCB  |    |
#                   rcv SYN      |     |     SEND               |    |
#                  -----------   |     |    -------             |    V
# +---------+      snd SYN,ACK  /       \   snd SYN          +---------+
# |         |<-----------------           ------------------>|         |
# |   SYN   |                    rcv SYN                     |   SYN   |
# |   RCVD  |<-----------------------------------------------|   SENT  |
# |         |                    snd ACK                     |         |
# |         |------------------           -------------------|         |
# +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+
#   |           --------------   |     |   -----------
#   |                  x         |     |     snd ACK
#   |                            V     V
#   |  CLOSE                 +-------------+
#   | -------                | ESTABLISHED |
#   | snd FIN                +-------------+
#   |                   CLOSE    |     |    rcv FIN
#   V                  -------   |     |    -------
# +---------+          snd FIN  /       \   snd ACK          +---------+
# |  FIN    |<-----------------           ------------------>|  CLOSE  |
# | WAIT-1  |------------------                              |   WAIT  |
# +---------+          rcv FIN  \                            +---------+
#   | rcv ACK of FIN   -------   |                            CLOSE  |
#   | --------------   snd ACK   |                           ------- |
#   V        x                   V                           snd FIN V
# +---------+                  +---------+                   +---------+
# |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
# +---------+                  +---------+                   +---------+
#   |                rcv ACK of FIN |                 rcv ACK of FIN |
#   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |
#   |  -------              x       V    ------------        x       V
#    \ snd ACK                 +---------+delete TCB         +---------+
#     ------------------------>|TIME WAIT|------------------>| CLOSED  |
#                              +---------+                   +---------+
#
# Przełączenie stanów charakterystyczne dla serwera:
#  CLOSED > LISTEN > SYN_RECEIVED > ESTABLISHED > CLOSE_WAIT > LAST_ACK > CLOSED
#
# Przełączenie stanów charakterystyczne dla klienta:
#  CLOSED > SYN_SENT > ESTABLISHED > FIN_WAIT-1 > FIN_WAIT-2 > TIME_WAIT > CLOSED

Karoll napisał(-a):
1 - Dlaczego na wyjsciu FW stosuje sie regoly z RELATED, ESTABLISHED, kiedy tam wszystkie pakiety sa NEW ? Przeciez one sa dopiero co utworzone i dopiero wychodza do WAN ? ( jak nowe samochody z fabryki na drogi naszego biednego kraju)

Nie wszystkie. Zależy kto inicjuje połączenie. Jak zdalny host chce się z tobą połączyć, to on wysyła pierwszy pakiet i on jest oznaczany jako NEW (na obu maszynach, ale zwykle stacje klienckie takie pakiety blokują na FW). Jak ty chcesz nawiązać połączenie, np. wpisując adres www, to ty wysyłasz do serwera pakiet i system zaczyna tworzenie nowego połączenia. Więc, najpierw musi przejść ten pakiet przez twój FW, by móc w ogóle pójść w świat, a ty ten pakiet blokujesz. Dopiero potem jak już ten pierwszy pakiet dotrze do serwera, to serwer odpowiada i te pakiety są dopiero traktowane jako ESTABLISHED.

Karoll napisał(-a):
2 - Dlaczego nasz powyzszy skrypt majacy domyslna polityke DROP na wyjsciu, odcina Internet, skoro pakiety "splywajac" po regolach z gory na dol musza wczesniej trafic na regoly z: RELATED, ESTABLISHED, co powinno umozliwic nawiazanie polaczenia ?

No zaakceptowanie pakietów w stanie NEW na wyjściu. xD

Kod:

iptables -A OUTPUT -m conntrack --ctstate NEW -j ACCEPT

Forum Debian Users Gang

Ogłoszenie

#1 2022-09-25 18:05:17

Karoll - Użytkownik

(SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

Kod:

Kod:

Kod:

#2 2022-09-29 09:53:47

Jacekalex - Podobno człowiek...;)

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

#3 2022-09-29 12:04:49

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#4 2022-09-29 23:24:49

Jacekalex - Podobno człowiek...;)

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#5 2022-09-30 10:23:31

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#6 2022-09-30 14:12:32

Jacekalex - Podobno człowiek...;)

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

Kod:

#7 2022-10-03 09:06:42

morfik - Cenzor wirtualnego świata

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Karoll napisał(-a):

Karoll napisał(-a):

Kod:

#8 2022-10-03 11:14:04

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#9 2022-10-03 18:51:36

Jacekalex - Podobno człowiek...;)

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#10 2022-10-03 20:10:20

morfik - Cenzor wirtualnego świata

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Karoll napisał(-a):

Karoll napisał(-a):

Karoll napisał(-a):

#11 2022-10-04 11:22:15

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

Kod:

#12 2022-10-04 16:53:06

Jacekalex - Podobno człowiek...;)

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

#13 2022-10-04 19:13:54

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

#14 2022-10-05 06:18:51

morfik - Cenzor wirtualnego świata

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Karoll napisał(-a):

Karoll napisał(-a):

Kod:

Karoll napisał(-a):

Kod:

Karoll napisał(-a):

Kod:

Karoll napisał(-a):

Karoll napisał(-a):

Kod:

#15 2022-10-05 12:43:47

Karoll - Użytkownik

Re: (SOLVED) Regoly iptables blokuja dostep do Internetu

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod: