Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Coraz jasniej !
Mylilem stan polaczenia z flagami pakietow w odniesieniu do reguly nawiazywania polaczenia TCP tzw "three-hand-shake".
To stan polaczenia w konfrontacji z regulami FW decyduja o poprawnosci FW.
Moja niewiedza caly czas dotyczy pierwszego etapu nawiazywania polaczenia TCP, kiedy pakiet SYN w lancuchy OUTPUT (wylacznie) wydostaje sie/lub nie do WAN, w zaleznosci od rodzaju relacji regol FW do polityki domyslnej
Wszedzie (FW) byly zastosowane stany: RELATED, ESTABLISHED w lancuchu OUTPUT.
Napisales:
iptables -A OUTPUT -m conntrack --ctstate NEW -j ACCEPT
Napisales rowniez:
No bo w OUTPUT nie masz akceptowania nowych połączeń, tj. tych w stanie NEW
Jak to rozumiec ?
Piszesz:
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
To moj pakiet SYN jest blokowany przez co ostatecznie w przypadku naszego FW?
a - brak regoly ACCEPT dla polaczen NEW w lancuchu OUTPUT? (chyba nie)
b - na wyjsciu polityke domyslna DROP ? (tego dowiodla praktyka)
c - inne ?
Jezeli w lancuchu OUTPUT polityka domyslna jest DROP (hipotetycznie), to jedyna droga dla pakietu SYN do nawiazania polaczenia z serverem zewnetrznym jest:
a - regula ACCEPT dla polaczen NEW w lancuchu OUTPUT?
b - cos innego ?
Ostatnio edytowany przez Karoll (2022-10-06 21:02:01)
Offline
Karoll napisał(-a):
Coraz jasniej !
Mylilem stan polaczenia z flagami pakietow w odniesieniu do reguly nawiazywania polaczenia TCP tzw "three-hand-shake".
Raczej three-way handshake. xD
Karoll napisał(-a):
Wiem, ze podana przez Ciebie regula jest prawidlowa:
Kod:
iptables -A OUTPUT -m conntrack --ctstate NEW -j ACCEPTTylko nigdy jej nie widzialem bo wszedzie (FW) byly zastosowane stany: RELATED, ESTABLISHED w lancuchu OUTPUT.
Bo nikt (poza nielicznymi wyjątkami, np. ja) nie ustawia domyślnej polityki OUTPUT na DROP. Jak masz w domyślnej polityce ACCEPT to stan NEW jest domyślnie akceptowany. Dlatego się go nie widuje.
Karoll napisał(-a):
Piszesz:
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
To moj pakiet SYN jest blokowany przez co ostatecznie w przypadku naszego FW?
a - brak regoly ACCEPT dla polaczen NEW w lancuchu OUTPUT?
b - na wyjsciu polityke domyslna DROP ? (tego dowiodla praktyka)
c - inne ?
A tak po polsku, bo nie rozumiem? xD
Karoll napisał(-a):
Jezeli w lancuchu OUTPUT polityka domyslna jest DROP (hipotetycznie), to jedyna droga dla pakietu SYN do nawiazania polaczenia z serverem zewnetrznym jest:
a - regula ACCEPT dla polaczen NEW w lancuchu OUTPUT?
b - cos innego ?
No reguła akceptująca połączenia w stanie NEW, choć niekoniecznie trzeba wszystkie pakiety puszczać, np. można ograniczyć to do konkretnych portów, czyli np. przepuść połączenia na docelowe porty 80/443 w stanie NEW i wtedy tylko http/https będzie działał. Albo można tak jak ja to mam zrobione przez cgroups, gdzie mam rozdzielony ruch na pojedyncze aplikacje i im zezwalam na dostęp w OUTPUT.
Offline
A tak po polsku, bo nie rozumiem? xD
W jaki sposob blokuje pakiet SYN na FW w lancuchu OUTPUT, przez polityke domyslna DROP? Z tego wniosek, ze pakiet SYN ma 2 drogi z localhosta na zewnatrz:
1 - Domyślna polityka ACCEPT gdzie stan NEW jest domyślnie akceptowany (wszystko wychodzi na zewnatrz)
2 - Warianty regoly "iptables -A OUTPUT -m conntrack --ctstate NEW -j ACCEPT" (wyszczegolnione wychodzi na zewnatrz)
Ostatnio edytowany przez Karoll (2022-10-06 21:20:39)
Offline
No pakiety SYN wpadają w domyślną politykę, bo nie masz reguł żadnych, które by je akceptowały. Więc skoro masz domyślną politykę na DROP, to są blokowane.
Offline
Moglem sie tego domyslic.
Bardzo, bardzo dziekuje za dzisiaj.
Ostatnio edytowany przez Karoll (2022-10-06 21:25:35)
Offline
Juz byl w ogrodku, juz wital sie z gaska a tu...Dzonk.
Napisalem sobie takiego FW, ktory w/g mnie powinien dzialac.
#! /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 --tcp-flags ALL NONE -j DROP -m comment --comment "Blocking null packets” 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 -p icmp --icmp-type echo-request -j DROP -m comment --comment "DROP ping from outside to inside” 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 -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -m comment --comment "przegladarka” 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 -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -o wlp5s0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT -m comment --comment "Allow outbound DHCP request” iptables -A OUTPUT -o wlp5s0 -p udp -m udp --dport 53 -j ACCEPT -m comment --comment "Outgoing DNS lookups” iptables -A OUTPUT -i wlp5so -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT -m comment --comment "Allow outbound email”
3x sprawdzalem palcowke bo edytor popelnia bledy.
Zapisalem jako skrypt powloki "firewall" w "pre-up.d"
Nadalem prawa "chmod 755 sciezka"
Reboot.
Podczas podnoszenia systemu komunikat:
Nieudane podniesienie interfejsow sieciowych
Desktop odciety od Internetu.
????
Ostatnio edytowany przez Karoll (2022-10-08 15:28:07)
Offline
Jak nie potrafisz debugować firewalla (moduł TRACE), to lepiej nie pisz
Napisalem sobie takiego FW, ktory w/g mnie powinien dzialac.
FW się pisze, dodając po jednej regule do ostatniej działającej konfiguracji,
inaczej z Twoim doświadczeniem będziesz się bawił co najmniej pół roku bez żadnego rezultatu.
Online
No jak masz akceptowanie połączeń w stanie ESTABLISHED jedynie dla portów 80/443 to się nie dziw, że ci nie działa, bo nie działa ci DNS czy DHCP i cała masa innych protokołów czy usług operujących na innych portach niż te dwa wyżej.
Ostatnio edytowany przez morfik (2022-10-09 05:07:32)
Offline
Niedziela spedzona z iptables, efektem jest niepelny zestaw dzialajacych regol:
iptables -S | ccze -m ansi -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "ininvalid* " --log-tcp-options --log-ip-options -A INPUT -m conntrack --ctstate INVALID -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP -A INPUT -f -j DROP -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "outinvalid* " --log-tcp-options --log-ip-options -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -m conntrack --ctstate INVALID -j DROP
Tylko kilka regol pracuje:
iptables -L -v -n --line-numbers | ccze -m ansi
Chain INPUT (policy DROP 6 packets, 600 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all — lo * 127.0.0.0/8 127.0.0.0/8
2 64788 85M ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3 13 563 LOG tcp — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW limit: avg 30/min burst 10 LOG flags 6 level 4 prefix "ininvalid* "
4 12 480 all — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
5 0 0 DROP tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
6 1 83 REJECT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 ctstate NEW reject-with tcp-reset
7 0 0 DROP tcp — * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcpmss match !536:65535
8 0 0 DROP all -f * * 0.0.0.0/0 0.0.0.0/0
9 1 48 DROP icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
2 0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 128 7672 LOG tcp — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW limit: avg 30/min burst 10 LOG flags 6 level 4 prefix "outinvalid* "
2 15905 1659K ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3 797 204K ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
4 0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
Obserwacja zmian licznikow FW na biezaco:
watch --interval=5 'iptables -nvL | grep -v "0 0"'
Moje uwagi do FW z polityka domyslna 3xDROP:
- INPUT:
a\ - po ustawieniu regoly z logowaniem na pierwszej pozycji - odcina Internet.
b\ - po ustawieniu regol z DROP,ami na poczatku INPUT - odcina Internet
c\ - na poczatku FW MUSI byc regula odwolujaca sie do stanu polaczenia ESTABLISCHED.
- OUTPUT:
a\ - sama regula z ESTABLISCHED lub NEW nie daje polaczenia, dopiero obydwie razem.
Moim zdaniem, regola odwolujaca sie do stanu polaczenia ESTABLISCHED jest bardzo "pojemna" i mieszcza sie w niej: DNS, DHCP, SMTP, POP, SSH i "kto wie co jeszcze ???"
Powoduje ona ze zastosowana w FW daje iluzje bezpieczenstwa, to tylko moje podejrzenie.
Mysle, ze wlasciwy firewall musi byc znacznie bardziej "granularny" tzn "schodzacy" do uslug i aplikacji, jak firewalle aplikacyjne.
Jestem absolutnie pewien, ze moje obserwacje moga byc zweryfikowane przez Morfika w 1 minute, oby tylko ja znalazl zeby nas oswiecic.
Offline
-A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "outinvalid* " --log-tcp-options --log-ip-options
Limitowanie nowych połączeń było zamierzone?
Offline
Tak, bylo zamierzone., zeby logi nie zasypaly.
Offline
Ok, źle spojrzałem.
Myślałem, że to będzie limitować liczbę nowych połączeń do 30 na minutę.
Offline
Offline
ESTABLISHED to stan połączenia. Jak dwa hosty się dogadają co do wymiany informacji, to wtedy mają połączenie w stanie ESTABLISHED. Dlatego się ogranicza jedynie stan NEW, by tych połączeń nie mogły nawiązywać. Jak zablokujesz stan NEW, to stan ESTABLISHED nigdy się nie pojawi. Dlatego reguła ze stanem ESTABLISHED powinna być jedną z pierwszych, by pakiety od nawiązanych już połączeń nie przebywały długiej drogi przez filtr i nie utylizowały procesora i przy tym by nie generowały zbędnych opóźnień, bo przejście pakietu przez każdą kolejną regułę generuje dodatkowe opóźnienie zanim ten pakiet zostanie wysłany. Dlatego też się nie filtruje OUTPUT, no może za wyjątkiem zrzucania stanu INVALID, przynajmniej na normalnych maszynach. xD Ja u siebie filtruje OUTPUT bo mam domyślnie zablokowane wyjście na świat i żaden proces bez mojej świadomej i dobrowolne zgody nie ma prawa się z siecią połączyć, co znacząco podnosi bezpieczeństwo. xD
Offline
Rozumiem to tak:
Klient inicjuje polaczenie FTP.
sudo iptables -A OUTPUT -p TCP -dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
Pakiet zainicjowany na kliencie korzystajac ze statusu NEW,ESTABLISHED ma zgode na udanie sie do --destination-port 21 na serwerze.
Server odpowiada polaczeniem.
sudo iptables -A INPUT -p tcp -sport 21 -m state --state ESTABLISHED -j ACCEPT
Serwer odpowiada wysylajac pakiet ze statusem ESTABLISHED do --source-port 21 na kliencie.
Polecenia te umożliwiają dwukierunkowy przepływ pakietów z dwóch hostów, jeśli połączenie już istnieje, a także akceptuje nowe połączenie od klienta.
Mam nadzieje, ze to jest wlasciwe rozumienie zagadnienia.
Zaczynam lekture o cgroups, moze jakis sprawdzony link do nauki, tutoriala, howto ?
Ostatnio edytowany przez Karoll (2022-10-10 20:52:22)
Offline
Karoll napisał(-a):
Rozumiem to tak:
Klient inicjuje polaczenie FTP.
Do ftp był/jest specjalny moduł Netfiltera - ftp-conntrack-helper
tu masz opis:
https://home.regit.org/netfilter-en/secure-use-of-helpers/
Inna sprawa, że FTP to jest protokół prehistoryczny, praktycznie już nie używany.
Zainteresuj się SFTP (z protokołu SSH).
Ten chodzi na jednym porcie, jest w pełni szyfrowany, umożliwia bezpieczną autoryzację kluczami SSH albo certyfikatami x509, do tego nie otwiera pasywnych portów, czego nie da się uniknąć przy FTP z SSL.
SFTP używa min Winscp, Filezilla, Rsync, SSHFS. czy standardowe polecenie unixa scp, np:
scp file.txt remote_host:/home/user/file.txt
To by było na tyle
Ostatnio edytowany przez Jacekalex (2022-10-11 17:38:00)
Online
@Jacekalex
Bardzo dziekuje za aktualizacje, chociarz dzisiejszy wieczor zamierzam spedzic na nauce cgroups .v1 oraz .v2. - w kontekscie iptables oczywiscie.
Moze jakies male naprowadzenie zebym nie bladzil po omacku ?
Edyta:
Napisalem dzialajacy skrypt FW z 3xDROP i filtrowaniem na wyjsciu:
#!/bin/bash iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP conntrack -F 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 INVALID -j DROP iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i wlp5s0 -p udp --dport 53 -j ACCEPT iptables -A INPUT -i wlp5s0 -p tcp --dport 53 -j ACCEPT iptables -I INPUT -p udp -i wlp5s0 --dport 67 -j ACCEPT iptables -A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix 'ininvalid* ' --log-tcp-options --log-ip-options iptables -A INPUT -m state --state NEW -p udp --dport 123 -j ACCEPT iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -m tcp '!' --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset 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 -p tcp -j REJECT --reject-with tcp-reset 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 RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix 'outinvalid* ' --log-tcp-options --log-ip-options iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p udp -m udp -m multiport --dports 123 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Potem:
sudo nano /etc/network/if-pre-up.d/firewall
sudo chmod 755
restart.
Efekt: Mimo ze wyczyscilem uprzednio plik firewall
Po restarcie mialem w konsoli tylko jakies zalosne szczatki pliku firewal, wymagajace usuniecia.
Dlaczego nie ma kompletnego przywrocenia wszystkich regol z pliku konfigu "firewall" ?
Probowalem rowniez metoda wprowadzania regol do konsoli:
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP conntrack -F 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 INVALID -j DROP iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i wlp5s0 -p udp --dport 53 -j ACCEPT iptables -A INPUT -i wlp5s0 -p tcp --dport 53 -j ACCEPT iptables -I INPUT -p udp -i wlp5s0 --dport 67 -j ACCEPT iptables -A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix 'ininvalid* ' --log-tcp-options --log-ip-options iptables -A INPUT -m state --state NEW -p udp --dport 123 -j ACCEPT iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -m tcp '!' --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset 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 -p tcp -j REJECT --reject-with tcp-reset 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 RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix 'outinvalid* ' --log-tcp-options --log-ip-options iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p udp -m udp -m multiport --dports 123 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Zarowno komenda:
sudo service netfilter-persistent save
Zeby zapisac zmiany
sudo service netfilter-persistent reload
Zeby zmiany byly trwale.
Nie przywracaja regol z pliku "rules.v4"
Rowniez komendy:
sudo iptables-save > /etc/iptables/rules.v4 sudo iptables-restore < /etc/iptables/rules.v4
Nie przywracaja regol z pliku "rules.v4"
Dlaczego ?
Jak sobie z tym poradzic ?
Ostatnio edytowany przez Karoll (2022-10-12 17:02:59)
Offline
Stan połączenia jest jeden w danej chwili. Pierwszy pakiet, który system widzi (czy to na wejściu czy wyjściu) zawsze ma stan NEW. Każdy kolejny pakiet na ten sam port źródłowy/docelowy, adres IP źródłowy/docelowy i protokół przełącza połączenie w stan ESTABLISHED. Jak nawiązujesz połączenie, to ty wysyłasz pierwszy pakiet, i dlatego na wyjściu przepuszczasz połączenia w stanie NEW. Druga strona odpowiada i ten pakiet już jest traktowany jako ESTABLISHED, a nie NEW. Dlatego w INPUT nie akceptujesz NEW, tylko ESTABLISHED. Jak zaakceptujesz stan NEW, to ktoś będzie mógł nawiązać połączenie z twoim hostem, a tego nie chcesz. xD
Offline
Przepraszam powinienem juz to wiedziec, ogromnie dziekuje za te korekty, teraz widze jak wiele nie wiem i ile pracy musze jeszcze wlozyc.
Mozna poprosic o slowo w sprawie nieudanego przywracania regol, o ktorym pisalem powyzej ?
Piszesz:
Jak nawiązujesz połączenie, to ty wysyłasz pierwszy pakiet, i dlatego na wyjściu przepuszczasz połączenia w stanie NEW. Druga strona odpowiada i ten pakiet już jest traktowany jako ESTABLISHED, a nie NEW. Dlatego w INPUT nie akceptujesz NEW, tylko ESTABLISHED.
a tutaj sa odwrotne przyklady.
https://www.digitalocean.com/community/tutorials/ip … -and-commands
Przerobilem regoly ale odcina od Internetu.
iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -i wlp5s0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A INPUT -i wlp5s0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i wlp5s0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "ininvalid* " --log-tcp-options --log-ip-options -A INPUT -p udp -m state --state NEW -m udp --dport 123 -j ACCEPT -A INPUT -p tcp -m tcp --dport 25 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 143 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 993 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 110 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 995 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset -A INPUT -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP -A INPUT -f -j DROP -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP -A OUTPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "outinvalid* " --log-tcp-options --log-ip-options -A OUTPUT -m conntrack --ctstate INVALID -j DROP -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p udp -m udp -m multiport --dports 123 -m state --state NEW -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Ps. Czuje sie zazenowany zabierajac tak wiele Twojego czasu, gdyby byla gdzies ksiazka, obszerny artykul to bym sie przygotowal, a tak to troche po omacku.
Moje sciagi:
https://www.baeldung.com/linux/new-established-related
Consider a NEW packet a telephone call before the receiver has picked up. An ESTABLISHED packet is their, "Hello." And a RELATED packet would be if you were calling to tell them about an e-mail you were about to send them. (The e-mail being RELATED.)
For the server:
on receiving an incoming SYN packet, iptables think it's NEW in the PREROUTING chain.
on sending the SYN+ACK packet, it's ESTABLISHED in the POSTROUTING chain.
For the client:
on sending the SYN packet, it's NEW in the POSTROUTING chain
on receiving the SYN+ACK packet, it is ESTABLISHED in the PREROUTING chain.
.
Ostatnio edytowany przez Karoll (2022-10-12 21:51:02)
Offline
W nawiązaniu do tego podlinkowane artykułu -- ten kto pisze coś w stylu:
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT ... -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
jest idiotą i nie rozumie co te reguły oznaczają. xD Więc bym się zbytnio tym artykułem i jego treścią nie przejmował za bardzo. xD
Co do FW, to weźże w końcu daj na pierwszej pozycji w INPUT:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
i wywal wszystkie reguły, mające ESTABLISHED. Wywal też wszystkie reguły z OUTPUT i przestaw jego politykę na ACCEPT -- naprawdę, w obecnej chwili cały syf lata na porcie 443, tym samym co SSL/TLS i jeśli nie filtrujesz ruchu per aplikacja, to nie ma sensu dawać filtrowania w OUTPUT bo to nic nie daje. Jak chcesz mieć możliwość oglądania stron WWW, to musisz przepuścić stan NEW na port 443, i jak ci się jakiś syf wgra do systemu, to przez tą regułę wyjdzie w świat i masz pozamiatane. Więc albo daruj sobie filtrowanie OUTPUT, bo to bez sensu, albo twórz firewall procesowy ale to jest bardziej skomplikowane. xD
Ostatnio edytowany przez morfik (2022-10-13 11:33:59)
Offline
Potrzebne mi jeszcze jedno uscislenie, w tym watku. Dotyczy czyszczenia tablicy conntrack.
Aktualny - dzialajacy zestaw regol:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :conntrack - [0:0] -A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "ininvalid* " --log-tcp-options --log-ip-options -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -f -j DROP -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A INPUT -p tcp -m tcp --dport 23 -j REJECT --reject-with icmp-port-unreachable -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "outinvalid* " --log-tcp-options --log-ip-options -A OUTPUT -m conntrack --ctstate INVALID -j DROP -A OUTPUT -p tcp -m tcp --dport 23 -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -o lo -j ACCEPT COMMIT
Problem, kiedy wpisuje na poczatku:
conntrack -F
wyrzuca bledy.
Jak powinien wygladac prawidlowy wpis zeby conntrack kazdorazowo czyscil tablice ?
W takiej sytuacji stworzylem zadanie (task) dla crona zeby co 5 minut wykonywal conntrack -F w conntrack.sh.
Edyta. Zauwazylem ze w lancuchu "Output" regula "LOG" wylapuje ok 10xwiecej pakietow INVALID anizeli upuszcza regola "DROP" w tym samym lancuchu. Co to sa za tajemnicze pakiety, ktore sa logowane jako "INVALID" ale mimo tego nie sa zzucane na regole "DROP" tylko trawersuja dalej ? Szukalem odpowiedzi w Internecie, ale bezskutecznie - moze ktos ma jakies wytlumaczenie ?
Ostatnio edytowany przez Karoll (2022-12-26 10:56:59)
Offline
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.
Offline
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 !
Offline