(/ etc / sysconfig / iptables) „Ręczne dostosowywanie tego pliku nie jest zalecane.” Dlaczego?

Edycja tego pliku bezpośrednio

/etc/sysconfig/iptables 

może zaoszczędzić mi tyle bólów głowy, tyle czasu i tak dalej ...

a jednak na samym początku pliku jest napisane ...

Manual customization of this file is not recommended.

oto „/ etc / sysconfig / iptables”, który właśnie został dostarczony z zupełnie nowym serwerem chmurowym Centos 6.4.

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

aby otworzyć port 80, mogę po prostu sklonować linię ..

    -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

a następnie zmień „22” na „80”, a następnie zapisz ten plik i uruchom ponownie cały system.

otworzy mi to port 80.

jest to dość prosta operacja. a jednak plik mówi, że ręczna edycja nie jest zalecana.

dlaczego powinienem stosować się do porady?

Ponieważ narzędzie o nazwie system-config-firewall(lub brat oparty na ncurses system-config-firewall-tui) zarządza tym plikiem. Za każdym razem, gdy użyjesz tego narzędzia do tworzenia nowych reguł iptables, zostanie ono zastąpione /etc/sysconfig/iptables.

Powiązana strona: 28.1.16. / etc / sysconfig / iptables-config

Dlatego nie jest to zalecane, ale nie zabronione . Najlepszym sposobem na zapisanie reguł za pomocą CentOS lub dowolnej innej wersji EL 6 jest skorzystanie z usługi iptables po dodaniu kilku reguł dotyczących pamięci:

# service iptables save

Powiązane pytanie: Dlaczego iptables nie pobiera informacji z / etc / sysconfig / iptables na centOs?

Powody, dla których nie można bezpośrednio edytować tego pliku ( /etc/sysconfig/iptables):

• Ponieważ jest to plik automatycznie generowany. Jego zawartość pochodzi ze skryptu / demona /etc/init.d/iptables.
• Niektóre działania, takie jak resetowanie lub zatrzymywanie demona iptables, mogą spowodować utratę danych, ponieważ spowoduje to zastąpienie pliku. Interesujące zmienne na ten temat: IPTABLES_SAVE_ON_STOP=""i IPTABLES_SAVE_ON_RESTART=""wewnątrz /etc/sysconfig/iptables-configpliku. Może ich dostrojenie sprawi, że twoje zmiany będą /etc/init.d/iptablestrwałe.
• Ponieważ dokumentacja mówi tak. Red Hat radzi, że jest to najlepsza metoda korzystania z infrastruktury zapory.

Alternatywnym rozwiązaniem tego „nadpisania moich reguł zapory” mindf *** jest całkowite wyłączenie tych skryptów i poleganie na niestandardowej metodzie zarządzania zaporą, takiej jak ta ujawniona przez goldilocks .

a jednak na samym początku pliku jest napisane ...

Hmmm, to dziwne. Na górze jest napisane:

# Manual customization of this file is strongly encouraged.

Ktoś musiał go zmienić;) I nawet go wyprowadził, /etc/sysconfigżeby nie został „automatycznie spersonalizowany” przez menedżera pakietów lub cokolwiek innego;);)

Myślę, że ogólnie rzecz biorąc, w przypadku takich plików konfiguracyjnych chodzi o to, że jeśli nie wiesz, co robisz, nie rób tego. Czasami pojawia się również ostrzeżenie, że system czasami nadpisuje plik. Może to być spowodowane przez menedżera pakietów przy uaktualnieniach - chociaż czasami PM zauważy, że plik został zmieniony ręcznie i nie nadpisze go, nie zapisze kopii itp. - i może to być inne narzędzie, które jest odpowiedzialne za tę konfigurację w szczególnie (patrz odpowiedź nwildnera ).

Częścią „wiedzy o tym, co robisz” jest świadomość takich kątów. Dostosowałem także usługę init dla iptables, aby używała innej lokalizacji dla pliku konfiguracyjnego, a co najważniejsze: jestem jedyną, która korzysta z tego komputera.

Zakładając, że istnieją inne osoby z dostępem do roota, nie zrobiłbym tego na serwerze, za który jestem odpowiedzialny, chyba że istniałby lepszy powód niż „wolę to w ten sposób”, ponieważ prawdopodobnie doprowadzi to do zamieszania i sprawi komuś ból głowy w pewnym momencie. Ale jeśli jesteś jedynym użytkownikiem i nikt inny nie zależy od systemu, możesz robić, co chcesz. Moja „preferowana metoda” konfiguracji zapory wygląda następująco:

#!/bin/bash

if [[ ! -n "$IPTSET_FILE" ]]; then
        IPTSET_FILE=/etc/iptables.current
fi

if [[ ! -e $IPTSET_FILE ]]; then
        echo "$IPTSET_FILE does not exist!"
        exit 1
fi

vim $IPTSET_FILE
iptables-restore < $IPTSET_FILE

/etc/iptables.currentjest tworzony podczas rozruchu przez kopiowanie /etc/iptables(które usługa iptables jest skonfigurowana do ładowania początkowo). W ten sposób mogę modyfikować rzeczy w locie, zachowując punkt odniesienia, od którego zaczyna się system.

To prowadzi nas do ważnej kwestii, jeśli chcesz wygłupiać się z konfiguracjami zawierającymi tego rodzaju ostrzeżenie: zawsze najpierw utwórz kopię zapasową oryginału.