Zmniejsz reguły zapory o połowę - jedna reguła iptables dla tcp i udp

Mam wiele reguł iptables na mojej zaporze ogniowej, które wyglądają tak:

iptables -A zone_lan_forward -p tcp -d 1.2.3.0/24 -j ACCEPT
iptables -A zone_lan_forward -p udp -d 1.2.3.0/24 -j ACCEPT

Czy istnieje skrót do posiadania dwóch reguł - jednej dla TCP i jednej dla UDP - dla każdego adresu? Mam na myśli, czy mogę zrobić coś takiego:

iptables -A zone_lan_forward -p tcp,udp -d 1.2.3.0/24 -j ACCEPT

— Big McLargeHuge
źródło

Odpowiedzi:

Utwórz nowy łańcuch, który będzie akceptował wszystkie pakiety TCP i UDP, i przeskocz do tego łańcucha z indywidualnych reguł dozwolonych adresów IP / portów:

iptables -N ACCEPT_TCP_UDP
iptables -A ACCEPT_TCP_UDP -p tcp -j ACCEPT
iptables -A ACCEPT_TCP_UDP -p udp -j ACCEPT

iptables -A zone_lan_forward -d 1.2.3.0/24 -j ACCEPT_TCP_UDP

Dodaje to narzut kilku dodatkowych linii, ale zmniejsza o połowę liczbę reguł TCP / UDP.

Chciałbym nie pominąć -pargumentu, ponieważ nie jesteś tylko otwarcie zapory dla ICMP, ale także każdy inny protokół. Ze strony podręcznika iptables na -p:

Określony protokół może być jednym z tcp, udp, icmp lub wszystkich, lub może być wartością liczbową reprezentującą jeden z tych protokołów lub inny. Nazwa protokołu z / etc / protocols jest również dozwolona.

Nie można słuchać na dowolnym z wyjątkiem protokołów TCP, UDP, ICMP i teraz , ale kto wie, co przyniesie przyszłość. Złą praktyką byłoby niepotrzebne pozostawianie zapory otwartej.

Oświadczenie: Polecenia iptables są z góry mojej głowy; Nie mam dostępu do skrzynki, na której można by przetestować bankomat.

— s.co.tt
źródło

To bardzo eleganckie rozwiązanie, które nie pozostawia niepotrzebnie otwartej zapory.

— Big McLargeHuge

Ale ta metoda tworzenia nowego łańcucha nie powiedzie się, jeśli filtrowanie zostanie wykonane przez docelowy numer portu. Czy ktoś może zasugerować, jak rozwiązać powyższy problem?

— Amor,

@Amor W tym przykładzie, jeśli użyłeś -p allwszystkich --dportreguł zone_lan_forwardłańcucha, może to osiągnąć to, czego szukasz. Oczywiście zakładam, że nie ma innego sposobu, aby dostać się do tego łańcucha za pomocą protokołu innego niż TCP / UDP z powodu ACCEPT_TCP_UDPłańcucha. Oczywiście jest to ryzykowna strategia, jeśli wiele osób ma dostęp do modyfikowania reguł, a ktoś przychodzi i edytuje reguły bez zrozumienia tej subtelności.

— Samuel Harmer

Ups Nie zauważyłem kolejności łańcuchów. Musisz również zmienić kolejność łańcuchów w tym przykładzie, aby to, co powiedziałem, działało poprawnie. Więc ACCEPT_TCP_UDPskacze do, do zone_lan_forwardktórego następnie skacze ACCEPT.

— Samuel Harmer

Jeśli tak naprawdę nie zależy ci na ruchu ICMP (który i tak możesz globalnie zablokować), możesz po prostu pominąć opcję -p, która obejmie wszystkie protokoły.

— Nathan C.
źródło

Czy powinienem dbać o ruch ICMP? Najbardziej interesuje mnie dostęp HTTP.

— Big McLargeHuge

Nie całkiem. Możesz zablokować ICMP (ping), jeśli chcesz, ale ponieważ i tak obsługuje ruch HTTP, nie ma większego sensu.

— Nathan C

@NathanC, myślę, że porada, aby otworzyć WSZYSTKIE porty, gdy OP prosi o zmniejszenie o połowę swoich zasad, może prowadzić do kłopotów, teraz lub w przyszłości.

— Jed Daniels

@JedDaniels przełącznik -p określa protokoły, a nie porty. Poniższa odpowiedź ma alternatywę, jeśli chcą zablokować coś innego niż tcp i udp.

— Nathan C

@NathanC Tak, a usunięcie -p oznacza „otwórz wszystkie protokoły, nie tylko tcp lub udp”, co jest lekkomyślne, jeśli nie niebezpieczne.

— Jed Daniels