(/ etc / sysconfig / iptables) "Налаштування цього файлу вручну не рекомендується". Чому?


20

Редагування цього файлу безпосередньо

/etc/sysconfig/iptables 

може врятувати мені стільки головних болів, стільки часу і так далі ...

і все ж на самому верху файлу написано ..

Manual customization of this file is not recommended.

ось "/ etc / sysconfig / iptables", який щойно з'явився з абсолютно новим хмарним сервером 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

щоб відкрити порт 80, я можу просто клонувати рядок ..

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

а потім змініть "22" на "80", а потім збережіть цей файл, а потім перезавантажте всю систему.

це відкриє порт 80 для мене.

це досить проста операція. але в файлі написано, що вручну редагувати не рекомендується.

чому я повинен дотримуватися порад?

Відповіді:


18

Оскільки цей інструмент керує інструментом, який називається system-config-firewall(або це брат на основі ncurses system-config-firewall-tui). Кожен раз, коли ви використовуєте цей інструмент для створення нових правил iptables, він буде перезаписаний /etc/sysconfig/iptables.

Пов’язана сторінка: 28.1.16. / etc / sysconfig / iptables-config

Ось чому це не рекомендується, але не забороняється . Найкращий спосіб зберегти свої правила за допомогою CentOS або будь-якої іншої версії EL версії 6 - це використання послуги iptables після додавання деяких правил у пам'яті:

# service iptables save

Пов'язане запитання: Чому iptables не отримує інформацію з / etc / sysconfig / iptables у centOs?

Причини не редагувати цей файл ( /etc/sysconfig/iptables) безпосередньо:

  • Тому що це автоматично створений файл. Вміст його походить зі сценарію / демона /etc/init.d/iptables.
  • Деякі дії, такі як скидання або зупинка демона iptables, можуть призвести до втрати даних, оскільки це замінить файл. Цікаві змінні на цю тему: IPTABLES_SAVE_ON_STOP=""і IPTABLES_SAVE_ON_RESTART=""всередині /etc/sysconfig/iptables-configфайлу. Можливо, налаштування цих змін зробить ваші зміни всередині /etc/init.d/iptablesпостійними.
  • Оскільки в документації так сказано. Red Hat радить, що це найкращий метод використовувати їхню інфраструктуру брандмауера.

Альтернативне рішення цього "перезаписати мої правила брандмауера" mindf *** - це повністю відключити ці сценарії та покластися на індивідуальний метод управління брандмауером, як той, що піддається золотистим кодам .


Це звучить більше як аргумент проти змішування та відповідності редагування файлу безпосередньо та додавання правил за допомогою system-config-firewallінструменту. Чи можете ви розширити, чому погано редагувати файл замість того, щоб коли-небудь використовувати інструмент?
Мішель

Додана додаткова інформація. Дякую за підказку @Michelle

8

і все ж на самому верху файлу написано ..

Гммм, це дивно. На вершині шахти написано:

# Manual customization of this file is strongly encouraged.

Хтось, мабуть, змінив її;) А насправді навіть вийшов з /etc/sysconfigнеї, щоб не отримати "автоматичне непристосування" менеджером пакунків чи чим-небудь ще;);)

Я думаю, що в цілому з такими файлами конфігурацій є сенс, якщо ви не знаєте, що робите, не робіть цього. Іноді також є попередження про те, що файл періодично перезаписується системою. Це може бути менеджером пакунків при оновленнях - хоча іноді прем'єр-міністр зазначає, що файл був змінений вручну, і не перезаписує його, або зберігає копію тощо - і це може бути якийсь інший інструмент, який відповідає за цю конфігурацію в зокрема (див . відповідь nwildner ).

Частина "знати, що ти робиш" - це знати про такі кути. Я також налаштував службу init для iptables, щоб використовувати інше місце для конфігураційного файлу, і найголовніше: я єдиний, хто використовує цей комп'ютер.

Припускаючи, що є інші люди з кореневим доступом, я б не робив цього на сервері, за який я відповідаю, якщо б не було кращої причини, ніж "я вважаю за краще це так", тому що це, ймовірно, призведе до плутанини і призведе до головного болю у когось іншого в деякій точці. Але якщо ви єдиний користувач, і ніхто більше не залежить від системи, то ви вільні робити те, що хочете. Мій "бажаний метод" для налаштування брандмауера виглядає так:

#!/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.currentстворюється при завантаженні за допомогою копіювання /etc/iptables(яке служба iptables налаштована для завантаження спочатку). Таким чином я можу змінювати речі на льоту, зберігаючи орієнтир, з якого починається система.

Це призводить нас до важливого моменту, якщо ви хочете обдурити конфігурації, що містять таке попередження: Завжди створюйте резервну копію оригіналу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.