Czy akceptowanie POWIĄZANEJ, USTANOWIONEJ dla wszystkich źródeł w iptables jest uważane za „zbyt otwarte”?

9

Często widziałem, że zasada była -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTstosowana. Chociaż nie jestem ekspertem, ta konkretna linia dotyczy mnie. Jest całkiem oczywiste, że reguła zezwala na cały ruch z jedynym wyjątkiem, że połączenie musi zostać ustanowione lub powiązane z ustanowionym połączeniem.

Scenariusz

  • Pozwolę na połączenia z domyślnym portem SSH 22z serwerów LAN w podsieci 192.168.0.0/16lub cokolwiek innego.
  • SuperInsecureApp®odsłania coś na porcie 1337, co dodaję do mojego INPUTłańcucha.
  • Dodałem conntrackregułę do akceptowania ESTABLISHEDi RELATEDze wszystkich źródeł
  • Polityka łańcucha jest DROP

Tak więc w zasadzie ta konfiguracja powinna umożliwiać połączenia SSH tylko z sieci LAN, jednocześnie dopuszczając ruch przychodzący do portu 1337 ze świata.

To tutaj rozkwita moje zamieszanie. Czy conntrackw jakikolwiek sposób ujawniłby lukę w zabezpieczeniach, która pozwoliłaby uzyskać ustanowione połączenie na 1337 (ponieważ świat jest otwarty), a następnie wykorzystać to połączenie, aby uzyskać dostęp do portu SSH (lub dowolnego innego portu w tym zakresie)?

security iptables ip tcp Dencker
źródło

Odpowiedzi:

8

Nie uważam ruchu USTANOWIONEGO i POWIĄZANEGO za zbyt otwarty. Możesz być w stanie pominąć POWIĄZANE, ale zdecydowanie powinieneś zezwolić na USTALENIE. Obie te kategorie ruchu używają stanów conntrack.

USTANOWIONE połączenia zostały już sprawdzone przez inną regułę. To znacznie ułatwia wdrażanie reguł jednokierunkowych. Pozwala to tylko na kontynuowanie transakcji na tym samym porcie.

POWIĄZANE połączenia są również sprawdzane przez inną regułę. Nie dotyczą wielu protokołów. Ponownie ułatwiają konfigurowanie reguł. Zapewniają również prawidłowe sekwencjonowanie połączeń tam, gdzie mają zastosowanie. To sprawia, że ​​Twoje zasady są bezpieczniejsze. Chociaż może to umożliwić połączenie z innym portem, port ten powinien być tylko częścią powiązanego procesu, takiego jak połączenie danych FTP. Które porty są dozwolone są kontrolowane przez specyficzne dla protokołu moduły conntrack.

Pozwalając na ustanowienie i POWIĄZANE połączenia, możesz skoncentrować się na nowych połączeniach, które zapora ma akceptować. Unika także łamanych reguł, które mają zezwalać na ruch powrotny, ale które umożliwiają nowe połączenia.

Biorąc pod uwagę, że sklasyfikowałeś program na porcie 1337 jako niepewny, należy go uruchomić przy użyciu dedykowanego ID użytkownika innego niż root. Ograniczy to obrażenia, które ktoś może wyrządzić, jeśli uda mu się złamać aplikację i uzyskać lepszy dostęp.

Jest bardzo mało prawdopodobne, aby połączenie na porcie 1337 mogło zostać wykorzystane do zdalnego dostępu do portu 22, ale możliwe jest, że połączenie z portem 1337 może zostać wykorzystane do proxy połączenia z portem 22.

Możesz upewnić się, że SSH jest zabezpieczony dogłębnie:

  • Użyj hosts.allow, aby ograniczyć dostęp oprócz ograniczeń zapory.
  • Zapobiegaj dostępowi do konta root lub przynajmniej wymagaj użycia kluczy i ogranicz ich dostęp w pliku autoryzowanych_kluczy.
  • Błędy logowania podczas inspekcji. Skaner dziennika może wysyłać Ci okresowe raporty o nietypowych czynnościach.
  • Rozważ użycie narzędzia takiego jak fail2ban, aby automatycznie blokować dostęp w przypadku powtarzających się awarii dostępu.
BillThor
źródło
Chociaż był to arbitralny przykład, pierwszą rzeczą, którą robię na nowych serwerach, jest zawsze wyłączanie dostępu do katalogu głównego i uwierzytelniania w postaci zwykłego tekstu w sshd - to bardzo dobra wskazówka. Również fail2ban jest już zainstalowany w rzeczywistej konfiguracji, z której powstał przykład. „USTANOWIONE połączenia zostały już sprawdzone przez inną regułę” - dokładnie tego nie byłem pewien i doskonale odpowiada na moje pytanie. Dziękuję za bardzo jasną odpowiedź!
Dencker,
Pytanie poboczne: Czy z punktu widzenia wydajności w ogóle coś to zmienia, jeśli conntrackreguła znajduje się na początku lub na końcu łańcucha? Z tego, co rozumiem iptables, musiałoby przetwarzać wszystkie reguły na ustanowionych połączeniach, gdyby było na końcu, i tylko tę jedną regułę, gdyby została umieszczona na początku?
Dencker,
@Dencker Najpierw chcesz regułę ESTABLISHED, RELATED. Przyjmie zdecydowanie największy ruch. Poza tym możesz chcieć mieć reguły, które akceptują największy ruch, chociaż najlepiej jest mieć duży wpływ na czytelność. Moje reguły są pogrupowane, wrażliwe na opóźnienia, duży ruch (pogrupowane według typu) i inne. Iptables ma liczniki, które pozwalają zobaczyć, ile ruchu przechodzi każda reguła. Korzystam z Shorewall, który dodaje kilka użytecznych wartości domyślnych i ma łatwy do odczytania plik reguł do budowy moich zapór ogniowych.
BillThor,
2

ESTABLISHED i RELATED to cechy „stanowego” filtrowania pakietów, w których filtrowanie nie zależy tylko od statycznego zestawu reguł, ale także od kontekstu, w jakim brane są pod uwagę pakiety. Potrzebujesz ESTABLISHED, aby umożliwić działanie połączeń, i potrzebujesz POWIĄZANE dla odpowiednich komunikatów ICMP. Filtrowanie stanowe pozwala na dokładniejsze filtrowanie w porównaniu do statycznych reguł „bezstanowych”.

Najpierw spójrzmy na ESTABLISHED. Rozważmy na przykład TCP na porcie 22. Inicjator (klient) wysyła SYNdo serverIPaddr:22. Serwer wraca SYN+ACKdo klienta. Teraz nadeszła kolej klienta, aby wysłać ACK. Jak powinna wyglądać reguła filtrowania na serwerze, aby ACKakceptować tylko „dopasowanie” ? Wyglądałaby ogólna zasada bezpaństwowca

-A INPUT --proto tcp --port 22 -j ACCEPT

co jest bardziej liberalne niż zgodnie z rządową zasadą. Reguła bezpaństwowcem umożliwia dowolne segmenty TCP, EG ACKlub FINbez nawiązaniu połączenia pierwszy. Skanery portów mogą wykorzystać takie zachowanie do pobierania odcisków palców w systemie operacyjnym.

Teraz spójrzmy na POKREWNE. Służy to do komunikatów ICMP, głównie komunikatów o błędach. Na przykład, jeśli pakiet z serwera do klienta zostanie upuszczony, do serwera zostanie wysłany komunikat o błędzie. Ten komunikat o błędzie jest „powiązany” z wcześniej ustanowionym połączeniem. Bez ZWIĄZANEJ reguły należałoby albo ogólnie zezwolić na przychodzące komunikaty o błędach (bez kontekstu), albo, jak to jest w przypadku wielu witryn, całkowicie upuścić ICMP i poczekać na przekroczenie limitu czasu w warstwie transportowej. (Należy pamiętać, że jest to zły pomysł dla IPv6; ICMPv6 odgrywa ważniejszą rolę dla IPv6 niż ICMP dla starszych IP).

przeciwdziałanie
źródło