Różnice między wybraną wersją a wersją aktualną.
Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
sk1:nf [2016/05/17 10:41] jkonczak [Komendy] |
sk1:nf [2020/06/09 12:20] (aktualna) jkonczak [[Ekstra] Appendix] |
||
---|---|---|---|
Linia 10: | Linia 10: | ||
Podczas przejścia pakietu przez jądro Linuksa wykonywane są w ściśle określonej kolejności [[http://en.wikipedia.org/wiki/Hooking|hooki]] decydujące co z pakietem zrobić. | Podczas przejścia pakietu przez jądro Linuksa wykonywane są w ściśle określonej kolejności [[http://en.wikipedia.org/wiki/Hooking|hooki]] decydujące co z pakietem zrobić. | ||
- | Każdemu hookowi odpowada jeden **łańcuch** reguł (**chain**) przeglądanych w kolejności. | + | Każdemu hookowi odpowada jeden **łańcuch** reguł (**chain**). |
+ | |||
+ | Łańcuch reguły to wiele reguł które przetwarzane są **w kolejności** – jeśli któraś reguła zdecyduje o losie pakietu, późniejsze nie są brane pod uwagę. | ||
Łańcuchy są pogrupowane w **tabele** (**table**) pod względem funkcjonalności. W ''iptables'' dostępne są następujące tabele: | Łańcuchy są pogrupowane w **tabele** (**table**) pod względem funkcjonalności. W ''iptables'' dostępne są następujące tabele: | ||
Linia 26: | Linia 28: | ||
Droga pakietu przez mechanizmy filtrujące w systemie Linux podsumowana jest tutaj: | Droga pakietu przez mechanizmy filtrujące w systemie Linux podsumowana jest tutaj: | ||
- | **[[https://badsector.pl/media_colorbox/306/colorbox/pl?width=2000&height=655]|[PL] ]]** | + | ** [[https://pl.wikipedia.org/wiki/Plik:Netfilter-packet-flow-pl.svg|[PL]]] ** |
- | **[[http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg]|[EN] ]]** | + | ** [[https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg|[EN]]] ** |
Można tworzyć własne łańcuchy, ale mogą one być uruchomione tylko przez dołączenie ich do już istniejących. | Można tworzyć własne łańcuchy, ale mogą one być uruchomione tylko przez dołączenie ich do już istniejących. | ||
==== Stanowość i bezstanowość – conntrack ==== | ==== Stanowość i bezstanowość – conntrack ==== | ||
Jądro Linuksa jest zaopatrzone w mechanizm śledzenia połączeń (conntrack). Duża część reguł korzysta z dostarczanych przez niego informacji, co znacznie ułatwia konfigurację filtracji. | Jądro Linuksa jest zaopatrzone w mechanizm śledzenia połączeń (conntrack). Duża część reguł korzysta z dostarczanych przez niego informacji, co znacznie ułatwia konfigurację filtracji. | ||
+ | ==== [Ekstra] Trwałość reguł (persistance) ==== | ||
+ | Iptables nie dostarcza mechanizmu automatycznego zapisywania ustawień – po ponownym uruchomieniu lista reguł jest pusta, a polityki domyślne. Dla odtworzenia reguł przy starcie dystrybucje Linuksa dostarczają odpowiedni skrypt startowy. Zwykle zapisanie reguł odbywa się ręcznie (tj. trzeba wydać odpowiednią komendę). | ||
===== Komendy ===== | ===== Komendy ===== | ||
Komenda ''iptables'' wszędzie **rozróżnia wielkie i małe litery**, ponadto **kolejność argumentów** decyduje o zrozumieniu polecenia. | Komenda ''iptables'' wszędzie **rozróżnia wielkie i małe litery**, ponadto **kolejność argumentów** decyduje o zrozumieniu polecenia. | ||
- | |||
- | Reguły są przetwarzane **w kolejności** – jeśli któraś reguła zdecyduje o losie pakietu, późniejsze nie są brane pod uwagę. | ||
Wyświetlanie listy reguł: | Wyświetlanie listy reguł: | ||
Linia 67: | Linia 69: | ||
* ''-m comment'' pozwala na dowolny komentarz ''--comment <tekst>'' | * ''-m comment'' pozwala na dowolny komentarz ''--comment <tekst>'' | ||
* ''-m limit'' dzięki ''--limit'' ogranicza ilość pakietów na jednostkę czasu | * ''-m limit'' dzięki ''--limit'' ogranicza ilość pakietów na jednostkę czasu | ||
+ | * ''-m hashlimit'' pozwala m. inn. ustawić limit pakietów/czas dla każdego IP z osobna | ||
* ''-m time'' pozwala włączyć regułę o ''--datestart'' i wyłączyć o ''--datestop'' | * ''-m time'' pozwala włączyć regułę o ''--datestart'' i wyłączyć o ''--datestop'' | ||
* ''-m u32'' udostępnia ''--u32'' wykonujący dowolny test na danych pakietu | * ''-m u32'' udostępnia ''--u32'' wykonujący dowolny test na danych pakietu | ||
Linia 110: | Linia 113: | ||
''iptables -t mangle -A POSTROUTING -p tcp --sport 5222 -j TOS --set-tos Minimize-Delay'' \\ | ''iptables -t mangle -A POSTROUTING -p tcp --sport 5222 -j TOS --set-tos Minimize-Delay'' \\ | ||
- | ==== NAT (Network Address Translation) – translacja adresów ==== | + | ===== NAT (Network Address Translation) – translacja adresów ===== |
+ | |||
+ | Ze względu na niewystarczającą ilość adresów IPv4 zwykle komputery w sieciach lokalnych używają adresów //z bloków prywatnych//. | ||
+ | |||
+ | Na wiadomość z takiego komputera – wysłaną z adresem źródłowym z bloku adresów prywatnych – odbiorca nie ma szansy odpowiedzieć (bo gdzie miałby?). <html><small></html>Routery z publicznym IP powinny automatycznie wycinać takie wiadomości [[https://tools.ietf.org/html/rfc1918|RFC 1918, str. 5]]<html></small></html> | ||
+ | |||
+ | Dlatego konieczne jest by na styku adresacji prywatnej i publicznej adresy były tłumaczone, stąd nazwa //NAT// = //Network Address Translation//. | ||
+ | |||
+ | Ruch generowany przez komputery z wewnątrz sieci lokalnej musi mieć zmieniony adres źródłowy (source address), stąd nazwa //Source NAT// (//SNAT//). Tradycyjnie adresy źródłowe zmienia się w momencie kiedy pakiet opuszcza system. | ||
+ | |||
+ | Jeśli zachodzi konieczność by ruch z sieci publicznej trafiał do komputera wewnątrz sieci lokalnej, trzeba zmienić adres docelowy (destination address), stąd nazwa //Destination NAT// (//DNAT//). Naturalnie urządzenie na styku sieci musi zmienić adres zanim podejmie decyzję o routingu (tj. decyzję gdzie pakiet ma trafić). | ||
+ | |||
+ | ++++ Ilustracja do NATów | | ||
+ | <html><div style="border: 1px gray solid"></html> | ||
+ | {{:sk1:nat.svg|}} | ||
+ | SNAT: | ||
+ | - PC1 chce wysłać pytanie DNS pod jakim adresem znajdzie serwer put.poznan.pl | ||
+ | - PC1 adresuje wiadomość: | ||
+ | * w polu odbiorcy wpisuje 1.1.1.1 (znany adres serwera DNS) | ||
+ | * w polu nadawcy wpisuje 192.168.0.2 (swój adres IP) | ||
+ | - PC1 wysyła wiadomość przez bramę domyślną - router R1, adres 192.168.0.1 | ||
+ | - R1 wybiera trasę dla pakietu (wykonuje routing) i kieruje pakiet w stronę internetu | ||
+ | - R1 po wykonaniu trasowania (POSTROUTING) dokonuje **translacji adres źródłowego**: \\ zamienia adres źródłowy z 192.168.0.2 na 93.184.216.34 | ||
+ | - R1 wysyła wiadomość w intenet | ||
+ | - Serwer DNS (pod adresem 1.1.1.1) dostaje wiadomość adresowaną do niego z adresu 93.184.216.34 i odpowiada na nią adresując ją: | ||
+ | * od 1.1.1.1 (od siebie) | ||
+ | * do 93.184.216.34 (do adresu, z którego otrzymał pytanie) | ||
+ | - R1 otrzymuje wiadomość z adresu 1.1.1.1 kierowaną na adres 93.184.216.34 | ||
+ | - Przed wykonaniem trasowania R1 sprawdza, czy pakiet należy do połączenia dla którego już wykonuje translację adresów. W tym przypadku tak – zamienia więc adres //docelowy// z 93.184.216.34 na 192.168.0.2 | ||
+ | - R1 wykonuje trasowanie i określa, że pakiet kierowany do 192.168.0.2 ma trafić do PC1 | ||
+ | - PC1 otrzymuje odpowiedź z adresem źródłowym 1.1.1.1 i docelowym 192.168.0.2 | ||
+ | DNAT: | ||
+ | - PC1 wysyła żądanie nawiązania połączenia TCP na port 443 ze swojego do adresu 150.254.5.114 | ||
+ | - R1 wykonuje translację SNAT i wysyła w internet pakiet: | ||
+ | * z adresu 93.184.216.34 | ||
+ | * do adresu 150.254.5.114 | ||
+ | * protokołu TCP, na port docelowy 443 | ||
+ | - R2 dostaje wiadomość z 93.184.216.34 na swój adres IP | ||
+ | - Przed wykonaniem trasowania (PREROUTING) R2 sprawdza czy dla tego pakietu powinien wykonać trasowanie | ||
+ | - R2 znajduje regułę: //pakiety TCP adresowane na port 443 tego komputera mają trafiać do 192.168.0.3//, więc dokonuje **translacji adresu docelowego**: zmienia adres docelowy 150.254.5.114 na 192.168.0.3 | ||
+ | - R2 wykonuje trasowanie i określa, że pakiet kierowany do 192.168.0.3 ma trafić do //Serwer WWW// | ||
+ | - //Serwer WWW// otrzymuje pakiet: | ||
+ | * z adresu 93.184.216.34 | ||
+ | * do adresu 192.168.0.3 | ||
+ | - //Serwer WWW// generuje w odpowiedzi pakiet i adresuje go: | ||
+ | * od 192.168.0.3 (od siebie) | ||
+ | * do 93.184.216.34 (do adresu, z którego otrzymał pytanie) | ||
+ | - //Serwer WWW// przesyła odpowiedź do bramy domyślnej 192.168.0.1 (R2) | ||
+ | - R2 określa, że pakiet kierowany do 93.184.216.34 ma iść do internetu i go tam kieruje | ||
+ | - R2 po wykonaniu trasowania sprawdza, czy pakiet należy do połączenia dla którego już wykonuje translację adresów. W tym przypadku tak – zamienia więc adres //źródłowy// z 192.168.0.3 na 150.254.5.114. | ||
+ | - R2 wysyła pakiet do internetu | ||
+ | - R1 otrzymuje pakiet | ||
+ | * z adresu 150.254.5.114 | ||
+ | * do adresu 93.184.216.34 | ||
+ | - R1 wykonuje translację SNAT, wysyła pakiet do PC1 | ||
+ | <html></div></html> | ||
+ | ++++ | ||
+ | |||
+ | === iptables i stanowość firewalla === | ||
W systemie Linux translacja adresów jest **stanowa**, stąd odpowiedzi zawsze znajdą drogę powrotną. | W systemie Linux translacja adresów jest **stanowa**, stąd odpowiedzi zawsze znajdą drogę powrotną. | ||
Linia 139: | Linia 200: | ||
===== [Ekstra] Appendix ===== | ===== [Ekstra] Appendix ===== | ||
- | Bardzo dobry artykuł o nftables, z wstępem opisującym historię filtrowania pakietów w Linuksie: https://badsector.pl/w-praktyce/artykuly/nftables-nowy-firewall-linuksa-cz-1.195.html?full=1 | + | Dobry artykuł o nftables, z wstępem opisującym historię filtrowania pakietów w Linuksie:https://randomseed.pl/pub/analizy/nftables-nowy-firewall-linuksa/ ([[http://www.cs.put.poznan.pl/jkonczak/archive/Nftables_nowy_firewall_Linuksa_BADSECTOR_PL.html|kopia]]) |
Inne moduły: | Inne moduły: | ||
Linia 147: | Linia 208: | ||
*''-p icmp'' pozwala na filtrowania icmp, np: \\ ''iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT'' | *''-p icmp'' pozwala na filtrowania icmp, np: \\ ''iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT'' | ||
- | API systrmów Windows do tworzenia firewalli: https://msdn.microsoft.com/en-us/library/aa366510%28v=vs.85%29.aspx | + | API systemów Windows do tworzenia firewalli: https://msdn.microsoft.com/en-us/library/aa366510%28v=vs.85%29.aspx |