Narzędzia użytkownika

Narzędzia witryny


sk1:nf

Różnice

Różnice między wybraną wersją a wersją aktualną.

Odnośnik do tego porównania

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
  
  
sk1/nf.1463474461.txt.gz · ostatnio zmienione: 2016/05/17 10:41 przez jkonczak