Dlaczego nie mogę korzystać z zasad REJECT w moim łańcuchu WYJŚĆ iptables?

11

Obecnie mam mój łańcuch WYJŚCIE ustawiony na DROP. Chciałbym zmienić to na ODRZUĆ, aby mieć wskazówkę, że to moja zapora ogniowa powstrzymuje mnie przed dotarciem, a nie problem z usługami, do których próbuję uzyskać dostęp (natychmiastowe odrzucenie zamiast przekroczenia limitu czasu). Jednak iptables nie przejmuje się tym. Jeśli ręcznie edytuję zapisany plik reguł i próbuję go przywrócić, otrzymuję iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy namei odmawia załadowania reguł. Jeśli spróbuję ustawić to ręcznie ( iptables -P OUTPUT REJECT), otrzymuję, iptables: Bad policy name. Run 'dmesg' for more information.ale w dmesg nie ma danych wyjściowych.

Potwierdziłem, że odpowiednia reguła jest wkompilowana w jądro i zrestartowałem się, aby upewnić się, że jest załadowana:

# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y

(Dodano gwiazdki, aby wyróżnić obowiązującą regułę)

Wszystko, co mogę znaleźć, stwierdza, że REJECT jest prawidłową polityką / celem (ogólnie), ale nie mogę znaleźć niczego, co mówi, że nie jest ważne dla łańcuchów INPUT, FORWARD lub OUTPUT. Moje Google-fu nie pomaga. Jestem na Gentoo, jeśli to robi jakąkolwiek różnicę. Czy ktoś tu ma jakiś wgląd?

networking iptables gentoo

— ND Geek
źródło

Czy potrafisz pokazać iptableszasadę, o której mowa?

— bahamat

15

REJECTjest rozszerzeniem celu , podczas gdy polityka łańcucha musi być celem . Strona podręcznika mówi, że (choć nie jest to do końca jasne), ale niektóre z jego wypowiedzi są całkowicie błędne.

Polityka może być tylko ACCEPTalbo DROPna wbudowanym w łańcuchy. Jeśli chcesz uzyskać efekt odrzucenia wszystkich pakietów, które nie pasują do poprzednich reguł, po prostu upewnij się, że ostatnia reguła pasuje do wszystkiego i dodaje regułę z REJECTrozszerzeniem docelowym. Innymi słowy, po dodaniu wszystkich odpowiednich reguł, zrób iptables -t filter -A OUTPUT -j REJECT.

Zobacz wątek „jakie są możliwe zasady łańcucha” na liście filtrów sieciowych, aby uzyskać więcej informacji.

— Shawn J. Goff
źródło

Ma to sens, a ogólny ODRZUCENIE na końcu powinno zadziałać. Z ciekawości, czy definicja rozszerzenia celu jest gdzieś dość oczywista i właśnie tego przegapiłem, czy jest to jeden ze słabo udokumentowanych bitów?

— ND Geek

1

Czytając całą stronę podręcznika, jasne jest, że REJECT jest rozszerzeniem docelowym, ale strona podręcznika jest bardzo długa, więc „TL; DR” ma zastosowanie. Oznacza to również, że DROP, ACCEPT i QUEUE są ważnymi celami polityki; z obecnego kodu, QUEUE nie jest!

— StarNamer

4

Nie mogłem znaleźć tego udokumentowanego, ale odniesienie tutaj wskazuje, że jedynymi dozwolonymi zasadami są AKCEPTACJA lub DROP. Potwierdzają to patrząc na źródło z libiptc(który jest odpowiedzialny za manipulację zasady) wokół linii 2429, gdzie kodu

2429         if (strcmp(policy, LABEL_ACCEPT) == 0)
2430                 c->verdict = -NF_ACCEPT - 1;
2431         else if (strcmp(policy, LABEL_DROP) == 0)
2432                 c->verdict = -NF_DROP - 1;
2433         else {
2434                 errno = EINVAL;
2435                 return 0;
2436         }

Oryginalny wątek sugeruje, że najlepiej jest dodać ODRZUĆ na końcu łańcucha, który powinien być iptables -A OUTPUT -j REJECT.

Zauważ, że kod tuż przed tym jest:

2423         if (!iptcc_is_builtin(c)) {
2424                 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425                 errno = ENOENT;
2426                 return 0;
2427         }
2428

Nie można więc w ogóle ustawić zasad w łańcuchu zdefiniowanym przez użytkownika.

— StarNamer
źródło

To polecenie w wątku jest niepoprawne; -psłuży do dopasowania w protokole; miał na myśli, -Ajak mówi moja odpowiedź.

— Shawn J. Goff

To całkiem interesujące. Ciekawość we mnie zastanawia się, czy kryje się za tym jakiś powód, czy może właśnie tak jest, być może ze względu na prostotę (prostszy kod oznacza mniej możliwych miejsc luk w zabezpieczeniach). Gdybym był nawet umiarkowanym programistą, mogłem mieć pokusę włamania się do niego lokalnie, ale ponieważ nie jestem, a biorąc pod uwagę, że jest to pewne zabezpieczenie, nie dotknę go.

— ND Geek

2

REJECTna OUTPUTnie ma sensu; a REJECTzwróci pakiet ICMP, który musiałby przemierzać sieć.

Dodaj nową -j LOGjako ostatnią regułę (a więc przed DROPzasadą), aby zobaczyć, co się tak daleko w OUTPUTłańcuchu.

— Aaron D. Marasco
źródło

1

Czy REJECTpakiet ICMP nie mógł zwrócić interfejsu Lo? Zgadzam się, że a LOGjest przydatne do rozwiązywania problemów, ale tak naprawdę liczyłem na sposób, aby przypomnieć mi, że „Och, tak ... to prawdopodobnie jest blokowane przez moje DROPdomyślne ustawienie iptables” zamiast rozwiązywania problemów przez 5 minut, prosi współpracownika o dostęp do serwera XYZ zdaje sobie sprawę, że jest to prawdopodobnie lokalne , co jest moim najczęstszym podejściem, ponieważ mój typowy dzień pracy rzadko uderza w rzeczy, na które nie otworzyłem już dziury. Oczywiście może lepiej o tym pamiętać, ale mieszkanie REJECTjest bardziej oczywiste.

— ND Geek

Nie sądzę, byś chciał, aby ethXinterfejs generował ruch na lointerfejsie z wielu powodów. Są bardzo niezależni; możesz łatwo sprawić, by łańcuchy dotyczyły jednego, a nie drugiego.

— Aaron D. Marasco