» Iptables. Начальная настройка.

Есть сервер (Linux Fedora Core 9), на который приходит инет, и который с помощью Сквида раздает интернет в локалку. Есть необходимость запуска WebMoney и других программ, которые не могу работать со Сквидом. Принял решение пробросить NAT (SNAT).

Сел изучать доку по Iptables 1.1.19, автор Oskar Andreasson.
Изучил, ознакомился, проникся душой.

Приступил к практике. И вот здесь овзник вопрос. Мне понравился вариант, который предлагает автор - вариант написания сценария типа rc.firewall, rc.DHCP.firewall и другие. И вносить изменения в таблицы через сценарий. Т.е. внес изменения в сценарий, перезапустил его и все уже пашет и педалит. Т.к. вносить изменения из консоли крайне неудобно т.к. имхо, можно запутаться и накосячить, а в сценарии удобочитаемый вид + туда можно скрипты добавлять для обработки полученных данных.

Собственно вопрос. Как этот сценарий, пусть он будет называться rc.iptables поместить в автозагрузку по запуску системы?
Вообще такой вариант внесения изменений в фаерволл нормальный (с помощью сценария, постановка сценария на автозапуск), с вашей точки зрения???

Цитата:

Как этот сценарий, пусть он будет называться rc.iptables поместить в автозагрузку по запуску системы?

Часто видел как советуют дописать скрипт с правилами в rc.local
Этот способ имеет существенный недостаток.
С момента поднятия сетевых интерфейсов до момента выполнения rc.local может пройти относительно много времени если много сервисов. Потому что rc.local выполняется последним. В течении этого времени тазик уязвим.

Лично добавляю правила при автозапуске сразу после поднятия сетевых интерфейсов и получения ими IP адресов (не Fedora).

Для конкретного дистрибутива надо выяснять как интегрируется запуск firewall в его boot scripts. В iptables tutorial, насколько я помню, этот вопрос не затрагивается. Это в принципе логично, так как дистрибутивов море и их boot scripts различаются.

Смотри документацию про boot scripts в Fedora, наверняка оставили место для firewall.

В директории /etc/rc.d есть директории rcN.d для каждого уровня запуска. Например, для init 5 - rc5.d

В них - ссылки на скрипты из директории /etc/rc.d/init.d

Цифры в названии ссылки определяют последовательность запуска и останова. Если посмотреть - видно, что iptables запускается раньше большинства сервисов, а убивается одним из последних.

В скрипте /etc/rc.d/init.d/iptables устанавливается переменная IPTABLES_DATA, ее значение - это путь к файлу с правилами. Например, по умолчанию /etc/sysconfig/iptables (не путать с /etc/sysconfig/iptables-config)

Вот в этот файл и будет правильно прописывать правила. Можно вручную, а можно с помощью утилиты system-config-securitylevel

Излагал на примере CentOS 4 и ASPLinux 11.2, основанной на четвертой Федоре. Не думаю, что к девятой Федоре что-то фундаментально поменялось, это достаточно базовые настройки. Последний раз менялось когда с ipchains на iptables переходили.

Цитата:

В скрипте /etc/rc.d/init.d/iptables устанавливается переменная IPTABLES_DATA, ее значение - это путь к файлу с правилами. Например, по умолчанию /etc/sysconfig/iptables (не путать с /etc/sysconfig/iptables-config)

Вот в этот файл и будет правильно прописывать правила. Можно вручную, а можно с помощью утилиты system-config-securitylevel

Он скриптом моим туда и записывает (/etc/sysconfig/iptables).
Я создаю переменную $ipt, через которую и записываю правила, типа: $iptables -A INPUT -p tcp -s 0/0 -j DROP

Я хочу чтобы при запуске системы он перезаписывал правила по этому скрипту (как бы рабочий на 100% вариант) - во избежание появления различных казусов.
Поэтому путь по-умолчанию должен остаться, но перед этим он дожен запустить мой скрипт по записи правил ))

Ramaloke

Цитата:

Я хочу чтобы при запуске системы он перезаписывал правила по этому скрипту (как бы рабочий на 100% вариант) - во избежание появления различных казусов.
Поэтому путь по-умолчанию должен остаться, но перед этим он дожен запустить мой скрипт по записи правил ))

Тогда или прописать вызов этого скрипта из /etc/rc.d/init.d/iptables до применения правил или сделать этот скрипт самостоятельным init-скриптом, выполняемым при загрузке до /etc/rc.d/init.d/iptables.

Спасибо. Поэкспериментирую.

Еще такой вопрос. В различных источниках говорится, что фильтрация должна происходить только в таблице filter. В таблицах mangle и nat ее ни в коем случае делать нельзя. Т.е. политика по-умолчанию ACCEPT. С чем это связано? Просто ACCEPT подразумевает под собой пропуск всех и вся, если открыт тот же NAT.

Цитата:

Т.е. политика по-умолчанию ACCEPT

Это _совершенно_ недопустимо!!! Политика по умолчанию должна быть DROP!


Код:
iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Не, я имею в виду, что политика по-умолчанию для таблиц nat и mangle ACCEPT. Для таблицы filter конечно же DROP.

Ramaloke

Имхо, имеет место явное непонимание как работают iptables. Через таблицу filter, то есть через одну из цепочек INPUT, OUTPUT или FORWARD проходят _все_ пакеты. И если они здесь дропаются, то это безотносительно к правилам nat или mangle.

Подробнее здесь -
http://www.opennet.ru/docs/RUS/iptables/#TRAVERSINGOFTABLES

aut
Ммм, значит я неверно выразился, а омжет и неправильно допонял.
В любом случае пакет проходит через какую-либо из чепочек в таблице filter, как вы и сказали. Т.е. если пакет не удовлетворяет ни одному из условий, то он дропается и к нему не применяются правила таблиц nat и mangle. Значит все отлично, защищены.

Но, вот смотрю я на рисунок (http://www.opennet.ru/docs/RUS/iptables/misc/iptables-tutorial/images/tables_traverse.jpg) и наверное что-то так и не допонимаю. Цепочку PREROUTING таблицы nat пакеты проходят до таблицы filter т.е. это пакеты которые nat'ом до нас дошли. Фильтрация будет на уровне протоколов, портов и мест назначения (если указано такое ограничение в правиле цепочке PREROUTING). Т.е. это нормальное положение вещей, я правильно понимаю???

Цитата:

Т.е. это нормальное положение вещей, я правильно понимаю???

Нормальное, только надо учитывать разницу между INPUT и FORWARD.
Т. е., если в цепочке PREROUTING таблицы nat для входящего пакета заменяется destination, и он, соответственно, будет маршрутизирован на другой хост - то он пойдет дальше не через цепочку INPUT, а через FORWARD, и применятся к нему будут правила, установленные именно для FORWARD.

Политику по-умолчанию DROP я делаю для цепочек INPUT, OUTPUT и FORWARD. Тем самым предусматриваю обо варианта прохождения пакета ))

Спасибо за разъяснение.

Ramaloke

Цитата:

Как этот сценарий, пусть он будет называться rc.iptables поместить в автозагрузку по запуску системы?
Вообще такой вариант внесения изменений в фаерволл нормальный (с помощью сценария, постановка сценария на автозапуск), с вашей точки зрения???

или настраиваеш сценарий - запускаеш его - и
service iptables save - пожеш в конце сценария прописать и все

или сценарий (или его вызов) прописываеш в /etc/rc.d/rc.local - это типа autoexec.bat

Цитата:

или настраиваеш сценарий - запускаеш его - и
service iptables save - пожеш в конце сценария прописать и все

Кстати, такой вот вопрос возник.
При загрузке, iptables считывает данные с /etc/sysconfig/iptables. Т.е. если я запустив сценарий, не сделаю после iptables-save > /etc/sysconfig/iptables то после перезагрузки настройки сбрасываются. В iptables-config в пункте "сохранять значения после перезагрузки" стоит "нет" (из личных соображений).

В связи с чем хотелось бы узнать куда он помещает настройки "временные" после применения сценария? И это правило (iptables-save > /etc/sysconfig/iptables) и как следствие поведение iptables применимо к любой UNIX системе (при такой настройке iptables-config), или это в Linux Red Hat / Fedora такое???

Ramaloke
Да никуда он не помещает. Этот сценарий - фича редхата - прост набор команд для iptables. Iptables все свои настройки только в оперативке хранит. Когда ты выполняешь команду сохранения, скрипт просто сбрасывает текущие настройки iptables в файл в своем формате. А при загрузке системы скрипт эти настройки загружает в iptables - последовательным выполнением команды iptables с параметрами этого файла.

ptaha
Т.е. если в Red Hat / Fedora можно не придумывать "финты ушами" для загрузки сценария при загрузке системы, то в других все же придется извращаться методами, которые подсказали выше?

Ramaloke

ну, примерно так. но в баше можно более гибкий скрипт своять.

Я, например, в дебиане использую скрипт post-up в /etc/network/interfaces для активации правил iptables

Возник вопрос теперь другого характера.
Был IP статический, а стал IP динамический, да к тому же DSL (pptp). Как вариант в сценарий rc.iptables в шапку добавить функцию, которая будет вычислять IP и подставлять его в значения ниже. НО при первой перезагрузке или обрыве коннекта нам присвоится другой IP. И придется очищать таблицы, затем снова запускать скрипт.

Отсюда вопрос: можно ли как-то отказаться от привязки скрипта к IP, т.е. убрать его из обращения, а вместо этого использовать скажем только имя интерфейса? Тогда при перезагрузке сервера или при переподключении коннекта важность момента смены IP приравняется к 0.

Говоря о привязке к IP я говорю о следующем:
INET_IP="10.0.0.1"
INET_IFACE="eth1"
INET_BROADCAST="10.0.0.255"

Заранее спасибо за помощь.

Хм, довольно любопытно.
Т.е. вы намекаете, что:
INET_IP="10.0.0.1"
INET_IFACE="eth1"
INET_BROADCAST="10.0.0.255"
спокойно заменяется на:
INET_IFACE="eth1"
а строки типа:
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
меняются на:
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -i $INET_IFACE -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE

???

Вопрос по VPN.
Некоторым компьютерам посредством инета надо подключеться к удаленной БД по VPN. В iptables я так понял надо прописать следующее:
#eth0 - INET_IFACE
$IPTABLES -A INPUT -p 47 -i eth0 -s 0/0 -j ACCEPT
$IPTABLES -A INPUT -p TCP -s 0/0 --dport 1753 -j allowed
#eth1 - LAN_IFACE
$IPTABLES -A OUTPUT -p 47 -i eth1 -s 0/0 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP -s 0/0 --sport 1753 -j allowed

???

Цитата:

В iptables я так понял надо прописать следующее:

неа. если у вас есть цепочка alllowed - тогда в нее можно отправить данные. А если ее нет?
у вас не INPUT (вход) а FORWARD (проход сквозь шлюз)

Цитата:

неа. если у вас есть цепочка alllowed - тогда в нее можно отправить данные. А если ее нет?
у вас не INPUT (вход) а FORWARD (проход сквозь шлюз)

Цепочка allowed есть.

VPN-клиентом выступает сервер, локальные компы его соединением пользоваться будут. В таком случае все-равно Forward надо вместо Input ???
Кстати, возможен вариант, что будет выступать в качестве впн-клиента маршрутизатор, он же дсл-модем.

Есть пара вопросов по реализации файрвола (iptables) в редхатовских (типа CentOS) дистрибутивах.

Мне интересно как другие админы реализуют файрвол. Пишут самостоятельно правила (rc.firewall) или используют редхатовский /etc/sysconfig/iptables ?

Кто знает как в редхатовском варианте задавать переменные ? Т.е. я хочу многократно использовать подстановку $MYIP=192.168.1.1 Сейчас приходится писать явно айпишник в каждой строке, что неудобно.

Bratella

Цитата:

Мне интересно как другие админы реализуют файрвол

свой скрипт с заменой стандартного
/etc/init.d/iptables

если Вам трудно самому написать скрипт пробуйте Easy Firewall Generator for iptables (изначально ориентирован на RedHat\Centos)

AnDySs1
Спасибо за ответ.
Т.е. большинство админов работают по старинке?
И шлют стандартный редхатовский файрвол куда подальше. Мне он тоже показался не очень понятным, но хотелось бы использовать задумки разработчиков.

Кто-то знает как делать подстановки строк через $ в новых редхатовских скриптах для iptables или может хитрость есть какая-то ? Никак не могу найти решение

единственое, что я придумал, что можно написать конфигурационный скрипт, который будет написан по привычному и будет менять редхатовский конфиг.
приблизительно как тут:
http://wiki.centos.org/HowTos/Network/IPTables

AnDySs1

Цитата:

а поиграйтесь

очень интересно, спасибо за ссылку

Такой вопрос:

У Iptables нет ли какой не будь GUI (графический интерфейс) ? а то никогда надо учиться с ним работать, и хочу для начало в графическом интерфейсе понять что к чему, а потом уже с терминала фигачить.