RHEL / CentOS Teraz, aby dodać reguły nftable do zapory ogniowej podczas rozruchu systemu?

Dec 15 2020

Używam firewalld na RHEL 8 i muszę dodać kilka reguł nftable.

(Reguły nftable są oparte na odpowiedzi na CentOS 8 jako router NAT z nft i firewalld - jak sprawić, by przeszedł przez TFTP? )

W działającym firewallu działa to dobrze z poleceniem nft -f.

Jednak zostaje to utracone po ponownym uruchomieniu.

Dokumentacja RedHat (za paywallem) sugeruje użycie usługi nftables.service do ładowania reguł przy ponownym uruchomieniu, ale nie działa to w połączeniu z firewalld. Te dwie usługi są wymienione jako sprzeczne, a nawet gdyby tak nie było, firewalld prawdopodobnie opróżniłby reguły nftable.

Czy istnieje inny sposób na załadowanie reguł nftable przy ponownym uruchomieniu?

Odpowiedzi

2 A.B Dec 15 2020 at 18:45

Narzędzie firewalld , podczas korzystania z zaplecza nftables , nie opróżni tabel, które do niego nie należą :

Opróżnij tylko reguły firewalla

Ponieważ nftables zezwala na przestrzenie nazw (poprzez tabele), firewalld nie wykonuje już całkowitego czyszczenia reguł zapory . Spowoduje to tylko opróżnienie reguł z tabeli zapory ogniowej . Pozwala to uniknąć scenariuszy, w których niestandardowe reguły użytkownika lub reguły zainstalowane przez inne narzędzia są nieoczekiwanie usuwane po ponownym uruchomieniu lub ponownym załadowaniu zapory firewalld.

To samo należy zrobić podczas zarządzania innymi tabelami.

Właściwie w poprzedniej odpowiedzi, to już zrobione: the nftables rządzi idempotently usuwa tylko własną tabelę: handletftp.

Niestety nie nftables.servicedotyczy to akcji zatrzymania :

ExecStop=/sbin/nft flush ruleset

Należy po prostu upewnić się, że część zatrzymująca usługi systemd nie usuwa bezpośrednio wszystkich reguł, nadal wykonując zadanie. To zadanie zostanie przekazane do dedykowanych reguł nftables dla akcji zatrzymania .

Oto praktyczna metoda: zduplikuj (np . systemctl cat nftables.services:) i zmień nftables.servicena wersję z instancją [email protected]do umieszczenia w /etc/systemd/system/[email protected]:

[Unit]
Description=Idempotent nftables rules for %I
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ProtectSystem=full
ProtectHome=true
ExecStart=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# As the rules are idempotent, ExecReload is same as ExecStart
ExecReload=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# The stop rules should only have the first boilerplate parts
ExecStop=/sbin/nft -f /etc/nftables/idempotent/stop-%I.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Utwórz dedykowany katalog konfiguracyjny używany powyżej:

mkdir -p /etc/nftables/idempotent

Umieść reguły, które dla każdej zdefiniowanej tabeli zawsze zaczynają się w ten sposób, więc ładowanie reguł jest niezależne od innych tabel i idempotentne (przykład z tabelami ip fooi bridge bar):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

table ip foo {
    ...
}

table bridge bar {
    ....
}

lub po prostu użyj jednej tabeli na plik. flush rulesetOświadczenie jest zabronione, ponieważ jest to globalny.

Powodem tworzenia, usuwania i ponownego tworzenia tabeli jest uzyskanie wyniku idempotentnego: podczas usuwania nieistniejącej tabeli jest błędem i niepodzielnie spowodowałoby niepowodzenie całego ładowania, deklarując istniejącą tabelę bez jej definiowania (przez dodanie pustej tabeli) nigdy nie zawodzi i nie robi nic poza stworzeniem go jako pustego, jeśli wcześniej nie istniał. W obu przypadkach (nie istniał podczas startu, istnieje przy przeładowaniu) usuwanie może teraz działać, pozostawiając miejsce na rzeczywiste zdefiniowanie tabeli zaraz po. Wszystko to dzieje się w tej samej transakcji i nadal jest atomowe: żaden pakiet nigdy nie zostanie oceniony z brakującą tabelą IP foo, jeśli istniał wcześniej.

Przygotuj wersję zatrzymania powyższego, która tylko usunie (tutaj puste deklaracje nie są ściśle potrzebne i można je usunąć, jeśli była tylko jedna tabela, ale należy je zachować, jeśli jest więcej niż jedna tabela: niepowodzenie dotyczy całej transakcji):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

i umieść wszystko na swoim miejscu:

/etc/nftables/idempotent/foobar.nft
/etc/nftables/idempotent/stop-foobar.nft

Można to teraz aktywować za pomocą:

systemctl enable --now local-idempotent-nft@foobar

Przykład z poprzedniego pytania OP:

w /etc/nftables/idempotent/handletftp.nft:

table ip handletftp
delete table ip handletftp

table ip handletftp {
    ct helper helper-tftp {
        type "tftp" protocol udp
    }

    chain sethelper {
        type filter hook forward priority 0; policy accept;
        ip saddr 192.168.1.0/24 ip daddr 10.0.10.10 udp dport 69 ct helper set "helper-tftp"
    }
}

W /etc/nftables/idempotent/stop-handletftp.nft

table ip handletftp
delete table ip handletftp

Włączanie i uruchamianie:

systemctl enable --now local-idempotent-nft@handletftp

Zatrzymanie tego:

systemctl stop local-idempotent-nft@handletftp

co pozostawi reguły firewalla na miejscu. Podobnie, zatrzymanie lub ponowne uruchomienie zapory ogniowej pozostawi te reguły na miejscu.

Prawdopodobnie istnieją ulepszenia do zrobienia:

  • nftables zawiera instrukcję include , której można w jakiś sposób użyć, aby uniknąć powielania standardowych elementów.
  • konkretny przykład dotyczący TFTP polega na tym, że ładowanie nf_nat_tftpnie nastąpi automatycznie (w przeciwieństwie do tego, nf_conntrack_tftpktóre jest ładowane automatycznie z odniesienia w regułach lub w przeciwieństwie do firewalld, który ładowałby się nf_nat_tftpjawnie). Należy pamiętać o tak powiązanych, ale nie ściśle nftables konfiguracji (to jedno ustawienie można po prostu wprowadzić /etc/modules-load.d/).