Firewall – lekcja dla zaawansowanych (iptables)

Logowanie pakietów

Logowanie z użyciem celu LOG

Bardzo często zależy nam na logowaniu pakietów, które spełniają albo nie spełniają określonych reguł. Możemy tutaj wykorzystać rozszerzenie LOG pozwalające przesłać do sysloga informację nas interesującą. Syslog sklasyfikuje je jako informacje pochodzące z jądra (KERNEL). Poziom ważności możemy sami ustalić korzystając z paramatru –log-level poziom_komunikatu (gdzie poziom komunikatu to jeden z: debug, info, notice, warning, err, crit, alert, emerg). Zapis z reguły może być także poprzedzony komunikatem ustawionym dzięki komendzie –log-prefix "komunikat".

Przykład reguły logującej do sysloga:

iptables -A syn-flood -j LOG --log-level debug --log-prefix "IPT SYN-FLOOD: "

Przykład zastosowania:
Załóżmy, iż mamy za firewallem (w jego roli występuje serwer linuksowy) ustawionego DNSa (też serwer linuksowy). Firewall dokonuje przekierowania zapytań dochodzących do niego na port 53 udp (standardowe zapytania do DNSa) właśnie na port 53 DNSa. Uzyskujemy dzięki temu to, iż wszystkie ataki skierowane na porty różne od 53 przyjmuje na siebie firewall. Załóżmy dalej, iż wszystkie inne połączenia sieciowe poza ściśle określonymi (np. możliwość zdalnego zarządzania serwerem, wykonywania updatetów z określonych serwerów ftp) są blokowane i jednocześnie logowane do sysloga-ng. Syslog-ng przesyła je do serwera logów, a tamten loguje komunikaty o nich do osobnego pliku. W ten sposób na serwerze logów uzyskujemy w osobnym pliku (trudno więc nie zauważyć zmiany jego wielkości) informacje o niepoprawnych połączeniach sieciowych mogących wskazywać na udaną próbę włamania na serwer, złej konfiguracji programów na serwerze lub uszkodzenia sprzętowego karty sieciowej.

logowanie dziwnych pakietów

Włączamy logowanie dziwnych pakietów, czyli takich, co zwyczajowo się nie pojawiają (przekierowujących, świadczących o spoofingu itp). O nich będziemy mówić dalej.

# Wlacza logowanie dziwnych (spoofed, source routed, redirects) pakietów
 /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

Syslog i separowanie logów

Komunikaty jądra systemu, w tym firewalla są oznakowane jako kerl. Jeżeli dodatkowo oznaczymy poziom logów (np. debug) jesteśmy w stanie z całego szumu wyłowić informację naszego firewalla. W takim przypadku należy przekazać komunikaty z firewalla do osobnego pliku np. firewall.log, co pozwoli nam efektywnie wykorzystać pliki logów a także podłączyć programy analizujące logi firewalla bezpośrednio do odpowiedniego pliku. Program pozwalający analizować logi z firewalla to np. fwlogwatch.

Zabezpieczenie naszego Firewalla – pakiety ICMP

Błędne pakiety ICMP

Błęde pakiety ICMP mogą nam nieźle namieszać, należy je wyłączyć na początku firewalla.

# Wlaczamy ochrone przed blednymi komunikatami ICMP error
 /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Source-route

Pakiety "source-route" pozwalają udawać iż pakiet jest z wnętrza sieci, mimo iż faktycznie jest spoza niej. Praktycznie wygląda to tak iż pakiety mają adresy źródłowe z naszej sieci i tak są traktowane przez reguły firewalli ale faktycznie wędrują z zewnątrz i tam wracają. Może to spowodować wyciek danych z naszej sieci. Technika ta rzadko jest używana w uzasadnionych celach.

# Nie aktceptujemy pakietow "source route"
 /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

pakiety ICMP redirect – zmiana tablic routingu

Niebezpieczne są również pakiety ICMP "redirect" pozwalające na zmianę tablic routingu. Należy wyłączyć obsługę tych pakietów.

# Nie akceptujemy pakietow ICMP redirect
   /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Atak Smurf i obrona

Atak ten polega na tym, że atakujący komputer wysyła pakiety ICMP echo request skierowane na adresy broadcastowe naszej sieci. Powoduje to iż wszystkie komputery naszej sieci odpowiadają na takie pakiety, co najczęściej skutkuje silnym przeciążeniem sieci.

Bardzo często adres źródłowy takiego pakietu jest zmieniony i ustawiony na komputer-ofiarę, który otrzymuje nagle dużo pakietów z odpowiedziami typu echo-reply. Jeśli w ten sposób zostanie zaatakowanych kilka podsieci, łącze ofiary może ulec zapchaniu.

Reguła blokująca ataki smurt polega na ignorowaniu pakietów ICMP kierowanych na adres BROADCAST. Najlepiej jest wyłączyć ją przez wysłanie komunikatu do jądra. Czyni to poniższa reguła.

# Nie akceptujemy pakietow skierowanych na broadcast
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Czy wyłączać odpowiedzi na pingi?

Odpowiedz na pytanie zależy od funkcji jakich pełni komputer z firewallem. Jeżeli jest to tylko firewall (ewentualnie router) można wyłączyć. Jednak bardzo często zdarza się iż komputer ten pełni także rolę serwera internetowego dostarczającego takich usług jak poczta. Wtedy o istnieniu serwera należy informować (bardzo często klienci w przypadku nie działania im serwera pingują go a następnie dzwonią iż serwer leży) o jego istnieniu. W takim przypadku należy zastosować limitowanie ilości pakietów przepuszczanych przez firewalla.

Jeżeli zdecydujemy się na blokowanie na firewallu pingów należy dodać na początku skryptu firewalla poniższą regułę, spowoduje ona ignorowanie pingów.

/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Zabezpieczenie naszego Firewalla – tabele rotuginu i adresy źródłowe

Pilnowanie tablic routingu

Możemy także zabezpieczyć się aby karty sieciowe nie przyjmowały pakietów z sieci do których nie należą. Przykład: jeżeli karta sieciowa eth1 ma adres sieciowy 192.168.1.2 i działa w sieci 192.168.1.1/24 to nie powinna przyjmować pakietów z sieci 10.0.0.1/16. Nie należy się jednak tutaj obawiać że jeżeli karta sieciowe eth0 obsługuje połączenie z Internetem to nie przyjmie z niego żadnych pakietów, gdyż tak się nie stanie.

# wszystkie karty nie będą przyjmowały pakietów z sieci innych niż te z tablicy rutingu
#(czyli karta sieciowa będzie przyjmowała pakiety tylko z sieci, do której należy)
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter;

Anty-spoofing

Istnieje także potencjalne (bo niewiadomo czy stos jest na pewno poprawnie zaimplementowany) zagrożenie iż jądro umożliwia spoofing czyli podszywanie się pod inne adresy niż własny. Poniższe reguły zabezpieczają w wystarczającym przypadku przed takim przypadkiem:

iptables -A INPUT -i eth0 -s 111.222.333.444 -j DROP

 #Pakiety z adr. źródłowycm ustawionym na nasz odrzucamy
 # Pakiety z adresow nierutowalnych, multicast i zarezerwowanych
 iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP     # class A
 iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP  # class B
 iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP # class C
 iptables -A INPUT -i eth0 -s 224.0.0.0/4 -j DROP    # multicast
 iptables -A INPUT -i eth0 -d 224.0.0.0/4 -j DROP    # multicast
 iptables -A INPUT -i eth0 -s 240.0.0.0/5 -j DROP    # reserved
 iptables -A INPUT -i eth0 -d 127.0.0.0/8 -j DROP    # na eth0 do loopbacka?
 iptables -A INPUT -i eth0 -d 111.222.333.255 -j DROP # broadcasty
 iptables -A INPUT -i eth1 -p udp -d 192.168.1.255 --dport 137:138 -j DROP

Zabezpieczenie naszego Firewalla – połączenia z portami

Zabezpieczenie przed syn-floodem

Syn-flood polega na rozpoczynaniu bardzo wielu połączeń (ale nie otwieraniu ich do końca) co powoduje iż przestaje po pewnym czasie poprawnie odpowiadać na żądania następnych klientów. W celu obrony przed takim zdarzeniem wygodnie jest utworzyć osobny łańcuch w którym zdefiniujemy reakcję na zajście syn-flooda.

Przykładem metody obrony przed synfloodem są poniższe reguły. Pierwsza tworzy nowy łańcuch o nazwe syn-flood w którym będziemy reagować na pakiety rozpoczynające połączenie. Druga zbiera pakiety z tcp z flagą syn (rozpoczynające połączenie) i przekazuje do zdefiniowanego przez nas łancucha syn-flood. Trzecia powoduje iż rozpoczynamy zliczanie pakietów. Pozwalamy aby średnio jeden pakiet na sekundę rozpoczynał połączenie ale nie więcej niż 4, dzieje się to przez ustawienie limitów oraz skierowanie pakietów z powrotem do łańucha INPUT (przez wskazanie celu RETURN). Kolejna regułka raportuje nam do sysloga dalsze pakiety (z podobnym zabezpieczeniem przed przeciążeniem). Ostatnia dalsze pakiety odrzuca.

iptables -N syn-flood
iptables -A INPUT -i eth0 -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j LOG --log-level debug --log-prefix "IPT SYN-FLOOD:"
iptables -A syn-flood -j DROP

Efektem działania tych regułek jest to iż maksymalne 4 połączenia na sekundę będą otwierane, kolejne (maksymalnie) 4 będą logowane a dalsze gubione. Powoduje to iż nasz serwer nie będzie przeciążany zbyt dużą ilością połączeń.

Uwaga: wartości limitów tutaj musisz sam ustawić na podstawie doświadczeń

Uszczelnienie reguł określających nowe połączenia

W implementacji modułu conntack istnieje pewna niekonsekwencja powodująca iż może on przepuszczać pakiety które faktycznie nie otwierają połączeń ale moduł conntack tak je traktuje. Chodzi tutaj o pakiety z nie ustawioną flagą syn ale z ustawioną flagą ack. Moduł traktuje je jako rozpoczynające połączenie (czyli NEW).

Poniższe reguły sprawdzają czy pakiety rozpoczynające połączenie nie mają ustawionych flag syn, a jeżeli tak loguje je a następnie odrzuca je

# uszczelnienie reguł dla nowych połączeń
iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j LOG --log-level debug --log-prefix "IPT BAD NEW: "
iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP

Sfragmentowanie pakietów

Podstawowym problemem z fragmentowanymi pakietami jest fakt iż tylko pierwszy z nich zawiera adres źródłowy a następne już nie. Może to pozwolić na oszukiwanie firewalla. Niestety, fragmentacja może być potrzeba, gdyż czasem po drodze znajduje się jakieś wąskie gardło dla pakietów. Należy więc najpierw przetestować czy można wyłączyć sfragmetnowane pakiety.

iptables -A INPUT -i eth0 -f -j LOG --log-level debug --log-prefix "IPT FRAGMENTS: "
iptables -A INPUT -i eth0 -f -j DROP

Dodaj komentarz