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

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)?

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.

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).