Приветствую всех! В продолжении публикую данную практическую статью о сетевом фильтре Linux . В статье рассмотрю типовые примеры реализации правил iptables в Linux, а так же рассмотрим способы сохранения созданной конфигурации iptables .
Настройка netfilter/iptables для рабочей станции
Давайте начнем с элементарной задачи - реализация сетевого экрана Linux на десктопе . В большинстве случаев на десктопных дистрибутивах линукса нет острой необходимости использовать файервол, т.к. на таких дистрибутивах не запущены какие-либо сервисы, слушающие сетевые порты, но ради профилактики организовать защиту не будет лишним. Ибо ядро тоже не застраховано от дыр. Итак, мы имеем Linux, с eth0, не важно по DHCP или статически...
Для настройки сетевого экрана я стараюсь придерживаться следующей политики: запретить все, а потом то, что нужно разрешить. Так и поступим в данном случае. Если у вас свежеустановленная система и вы не пытались настроить на ней сетевой фильтр, то правила будут иметь примерно следующую картину:
Netfilter:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Это значит, что политика по умолчанию для таблицы filter во всех цепочках - ACCEPT и нет никаких других правил, что-либо запрещающих. Поэтому давайте сначала запретим ВСЁ , и пакеты (не вздумайте это делать удаленно-тут же потеряете доступ):
Netfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -P FORWARD DROP
Этими командами мы устанавливаем DROP по умолчанию. Это значит, что любой пакет, для которого явно не задано правило, которое его разрешает, автоматически отбрасывается. Поскольку пока еще у нас не задано ни одно правило - будут отвергнуты все пакеты, которые придут на ваш компьютер, равно как и те, которые вы попытаетесь отправить в сеть. В качестве демонстрации можно попробовать пропинговать свой компьютер через интерфейс обратной петли:
Netfilter:~# ping -c2 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted --- localhost ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1004ms
На самом деле это полностью не функционирующая сеть и это не очень хорошо, т.к. некоторые демоны используют для обмена между собой петлевой интерфейс, который после проделанных действий более не функционирует. Это может нарушить работу подобных сервисов. Поэтому в первую очередь в обязательно разрешим передачу пакетов через входящий петлевой интерфейс и исходящий петлевой интерфейс в таблицах INPUT (для возможности получения отправленных пакетов) и OUTPUT (для возможности отправки пакетов) соответственно. Итак, обязательно выполняем:
Netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT
После этого пинг на локалхост заработает:
Netfilter:~# ping -c1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1 (127.0.0.1): icmp_seq=1 ttl=64 time=0.116 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 116ms rtt min/avg/max/mdev = 0.116/0.116/0.116/0.116 ms
Если подходить к настройке файервола не шибко фанатично, то можно разрешить работу протокола ICMP:
Netfilter:~# iptables -A INPUT -p icmp -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT
Более безопасно будет указать следующую аналогичную команду iptables:
Netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT
Данная команда разрешит типы ICMP пакета эхо-запрос и эхо-ответ, что повысит безопасность.
Зная, что наш комп не заражен (ведь это так?) и он устанавливает только безопасные исходящие соединения. А так же, зная, что безопасные соединения - это соединения из т.н. эфимерного диапазона портов , который задается ядром в файле /proc/sys/net/ipv4/ip_local_port_range, можно разрешить исходящие соединения с этих безопасных портов:
Netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT
Если подходить к ограничению исходящих пакетов не параноидально, то можно было ограничиться одной командой iptables, разрешающей все исхолящие соединения оп всем протоколам и портам:
Netfilter:~# iptables -A OUTPUT -j ACCEPT netfilter:~# # или просто задать политику по умолчанию ACCEPT для цепочки OUTPUT netfilter:~# iptables -P OUTPUT ACCEPT
Далее, зная что в netfilter сетевые соединения имеют 4 состояния (NEW, ESTABLISHED, RELATED и INVALID ) и новые исходящие соединения с локального компьютера (с состоянием NEW) у нас разрешены в прошлых двух командах iptables, что уже установленные соединения и дополнительные имеют состояния ESTABLISHED и RELATED, соответственно, а так же зная, что к локальной системе приходят через , можно разрешить попадание на наш компьютер только тех TCP- и UDP-пакетов, которые были запрошены локальными приложениями:
Netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
Это собственно, все! Если на десктопе все же работает какая-то сетевая служба, то необходимо добавить соответствующие правила для входящих соединений и для исходящих. Например, для работы ssh-сервера , который принимает и отправляет запросы на 22 TCP-порту, необходимо добавить следующие iptables-правила :
Netfilter:~# iptables -A INPUT -i eth0 -p TCP --dport 22 -j ACCEPT netfilter:~# iptables -A OUTPUT -o eth0 -p TCP --sport 22 -j ACCEPT
Т.е. для любого сервиса нужно добавить по одному правилу в цепочки INPUT и OUTPUT, разрешающему соответственно прием и отправку пакетов с использованием этого порта для конкретного сетевого интерфейса (если интерфейс не указывать, то будет разрешено принимать/отправлять пакеты по любому интерфейсу).
Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.
Давайте теперь рассмотрим наш Linux в качестве шлюза для локальной сети во внешнюю сеть Internet . Предположим, что интерфейс eth0 подключен к интернету и имеет IP 198.166.0.200, а интерфейс eth1 подключен к локальной сети и имеет IP 10.0.0.1. По умолчанию, в ядре Linux пересылка пакетов через цепочку FORWARD (пакетов, не предназначенных локальной системе) отключена. Чтобы включить данную функцию, необходимо задать значение 1 в файле :
Netfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Чтобы форвардинг пакетов сохранился после перезагрузки, необходимо в файле /etc/sysctl.conf раскомментировать (или просто добавить) строку net.ipv4.ip_forward=1 .
Итак, у нас есть внешний адрес (198.166.0.200), в локальной сети имеется некоторое количество гипотетических клиентов, которые имеют и посылают запросы во внешнюю сеть. Если эти клиенты будут отправлять во внешнюю сеть запросы через шлюз "как есть", без преобразования, то удаленный сервер не сможет на них ответить, т.к. обратным адресом будет получатель из "локальной сети". Для того, чтобы эта схема корректно работала, необходимо подменять адрес отправителя, на внешний адрес шлюза Linux. Это достигается за счет (маскарадинг) в , в .
Netfilter:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT netfilter:~# iptables -P FORWARD DROP netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Итак, по порядку сверху-вниз мы разрешаем уже установленные соединения в цепочке FORWARD , таблице filter , далее мы разрешаем устанавливать новые соединения в цепочке FORWARD , таблице filter , которые пришли с интерфейса eth1 и из сети 10.0.0.1/24. Все остальные пакеты, которые проходят через цепочку FORWARD - отбрасывать. Далее, выполняем маскирование (подмену адреса отправителя пакета в заголовках) всех пакетов, исходящих с интерфейса eth0.
Примечание. Есть некая общая рекомендация: использовать правило -j MASQUERADE для интерфейсов с динамически получаемым IP (например, по DHCP от провайдера). При статическом IP, -j MASQUERADE можно заменить на аналогичное -j SNAT -to-source IP_интерфейса_eth0. Кроме того, SNAT умеет "помнить" об установленных соединениях при кратковременной недоступности интерфейса. Сравнение MASQUERADE и SNAT в таблице:
Кроме указанных правил так же можно нужно добавить правила для фильтрации пакетов, предназначенных локальному хосту - как описано в . То есть добавить запрещающие и разрешающие правила для входящих и исходящих соединений:
Netfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
В результате, если один из хостов локальной сети, например 10.0.0.2, попытается связаться с одним из интернет-хостов, например, 93.158.134.3 (ya.ru), при , их исходный адрес будет подменяться на внешний адрес шлюза в цепочке POSTROUTING таблице nat, то есть исходящий IP 10.0.0.2 будет заменен на 198.166.0.200. С точки зрения удаленного хоста (ya.ru), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 198.166.0.200. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 10.0.0.2, после чего пакеты будут передаваться настоящему получателю в локальной сети. Для такого обратного преобразования никаких дополнительных правил указывать не нужно - это будет делать все та же операция MASQUERADE , которая помнит какой хост из локальной сети отправил запрос и какому хосту необходимо вернуть пришедший ответ.
Примечание: желательно негласно принято, перед всеми командами iptables очищать цепочки, в которые будут добавляться правила:
Netfilter:~# iptables -F ИМЯ_ЦЕПОЧКИ
Предоставление доступа к сервисам на шлюзе
Предположим, что на нашем шлюзе запущен некий сервис, который должен отвечать на запросы поступающие из сети интернет. Допустим он работает на некотором TCP порту nn. Чтобы предоставить доступ к данной службе, необходимо модифицировать таблицу filter в цепочке INPUT (для возможности получения сетевых пакетов, адресованных локальному сервису) и таблицу filter в цепочке OUTPUT (для разрешения ответов на пришедшие запросы).
Итак, мы имеем , который маскарадит (заменяет адрес отправителя на врешний) пакеты во внешнюю сеть. И разрешает принимать все установленные соединения. Предоставление доступа к сервису будет осуществляться с помощью следующих разрешающих правил:
Netfilter:~# iptables -A INPUT -p TCP --dport nn -j ACCEPT netfilter:~# iptables -A OUTPUT -p TCP --sport nn -j ACCEPT
Данные правила разрешают входящие соединения по протоколу tcp на порт nn и исходящие соединения по протоколу tcp с порта nn. Кроме этого, можно добавить дополнительные ограничивающие параметры, например разрешить входящие соединения только с внешнего интерфейса eth0 (ключ -i eth0 ) и т.п.
Предоставление доступа к сервисам в локальной сети
Предположим, что в нашей локальной сети имеется какой-то хост с IP X.Y.Z.1, который должен отвечать на сетевые запросы из внешней сети на TCP-порту xxx. Для того чтобы при обращении удаленного клиента ко внешнему IP на порт xxx происходил корректный ответ сервиса из локальной сети, необходимо направить запросы, приходящие на внешний IP порт xxx на соответствующий хост в локальной сети. Это достигается модификацией адреса получателя в пакете, приходящем на указанный порт. Это действие называется DNAT и применяется в цепочке PREROUTING в таблице nat. А так же разрешить прохождение данный пакетов в цепочке FORWARD в таблице filter.
Опять же, пойдем по пути . Итак, мы имеем , который маскарадит (заменяет адрес отправителя на врешний) пакеты во внешнюю сеть. И разрешает принимать все установленные соединения. Предоставление доступа к сервису будет осуществляться с помощью следующих разрешающих правил:
Netfilter:~# iptables -t nat -A PREROUTING -p tcp -d 198.166.0.200 --dport xxx -j DNAT --to-destination X.Y.Z.1 netfilter:~# iptables -A FORWARD -i eth0 -p tcp -d X.Y.Z.1 --dport xxx -j ACCEPT
Сохранение введенных правил при перезагрузке
Все введенные в консоли правила - после перезагрузки ОС будут сброшены в первоначальное состояние (читай - удалены). Для того чтобы сохранить все введенные команды iptables , существует несколько путей. Например, один из них - задать все правила брандмауэра в файле инициализации . Но у данного способа есть существенный недостаток: весь промежуток времени с запуска сетевой подсистемы, до запуска последней службы и далее скрипта rc.local из SystemV операционная система будет не защищена. Представьте ситуацию, например, если какая-нибудь служба (например NFS) стартует последней и при ее запуске произойдет какой-либо сбой и до запуска скрипта rc.local. Соответственно, rc.local так и не запуститься, а наша система превращается в одну большую дыру.
Поэтому самой лучшей идеей будет инициализировать правила netfilter/iptables при загрузке . Для этого в Debian есть отличный инструмент - каталог /etc/network/if-up.d/ , в который можно поместить скрипты, которые будут запускаться при старте сети. А так же есть команды iptables-save и iptables-restore , которые сохраняют создают дамп правил netfilter из ядра на и восстанавливают в ядро правила со соответственно.
Итак, алгоритм сохранения iptables примерно следующий :
- Настраиваем сетевой экран под свои нужны с помощью
- создаем дамп созданный правил с помощью команды iptables-save > /etc/iptables.rules
- создаем скрипт импорта созданного дампа при старте сети (в каталоге /etc/network/if-up.d/) и не забываем его сделать исполняемым:
Дамп правил, полученный командой iptables-save имеет текстовый формат, соответственно пригоден для редактирования. Синтаксис вывода команды iptables-save следующий :
# Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011 *filter:INPUT ACCEPT :FORWARD ACCEPT ....... # комментарий -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT ........... -A FORWARD -j REJECT COMMIT # Completed on Sat Dec 24 22:35:13 2011 # Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011 *raw ...... COMMIT
Строки, начинающиеся на # - комментарии, строки на * - это название таблиц, между названием таблицы и словом COMMIT содержатся параметры, передаваемые команде iptables. Параметр COMMIT - указывает на завершение параметров для вышеназванной таблицы. Строки, начинающиеся на двоеточие задают цепочки, в которых содержится данная таблица в формате:
:цепочка политика [пакеты:байты]
где цепочка - имя цепочки, политика - политика цепочки по-умолчанию для данной таблицы, а далее счетчики пакетов и байтов на момент выполнения команды.
В RedHat функции хранения команд iptables выполняемых при старте и останове сети выполняет файл /etc/sysconfig/iptables . А управление данным файлом лежит на демоне iptables.
Как еще один вариант сохранения правил, можно рассмотреть использование параметра up в файле /etc/network/interfaces с аргументом в виде файла, хранящего команды iptables, задающие необходимые правила.
Итог
На сегодня будет достаточно. Более сложные реализации межсетевого экрана я обязательно будут публиковаться в следующих статьях.
С Уважением, Mc.Sim!
Ключевыми понятиями iptables являются:
Критерий - логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, подпадает ли данный конкретный пакет под действие текущего правила. Критерии соединяются логическим «И».
Действие - описание действия, которое нужно проделать с пакетом и/или соединением в том случае, если они подпадают под действие этого правила. О действиях более подробно будет рассказано ниже.
Счетчик - компонент правила, обеспечивающий учет количества пакетов, которые попали под критерий данного правила. Также счетчик учитывает суммарный объем таких пакетов в байтах.
Базовая цепочка - цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из нее цепочек. Имена базовых цепочек всегда записываются в верхнем регистре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).
Пользовательская цепочка - цепочка, созданная пользователем. Может использоваться только в пределах своей таблицы. Рекомендуется не использовать для таких цепочек имена в верхнем регистре, чтобы избежать путаницы с базовыми цепочками и встроенными действиями.
Правило - состоит из критерия, действия и счетчика. Если пакет соответствует критерию, к нему применяется действие, и он учитывается счетчиком. Критерия может и не быть - тогда неявно предполагается критерий «все пакеты». Указывать действие тоже не обязательно - в отсутствие действия правило будет работать только как счетчик. Правила для каждой цепочки срабатывают в порядке их следования, поэтому порядок важен.
Цепочка - упорядоченная последовательность правил. Цепочки можно разделить на пользовательские и базовые.
Таблица - совокупность базовых и пользовательских цепочек, объединенных общим функциональным назначением. Имена таблиц (как и модулей критериев) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в формате -t имя_таблицы. При отсутствии явного указания, используется таблица filter.
Синтаксический анализ:
# Дамп правил таблицы filter $ sudo iptables-save -c -t filter # Таблица filter * filter # Цепочки INPUT, FORWARD, OUTPUT, их политики и счётчики :INPUT ACCEPT [ 19302 :9473669 ] :FORWARD ACCEPT [ 0 :0 ] :OUTPUT ACCEPT [ 5462736 :4247599532 ] # Правило: "" - счётчик правила, "-A INPUT" - цепочка, "-i em1 -p tcp -m tcp --dport 22" - критерии, "-j ACCEPT" - действие [ 17 :1020 ] -A INPUT -i em1 -p tcp -m tcp --dport 22 -j ACCEPT COMMITАрхитектура
В системе netfilter, пакеты пропускаются через цепочки. Цепочка является упорядоченным списком правил, а каждое правило может содержать критерии и действие или переход. Когда пакет проходит через цепочку, система netfilter по очереди проверяет, соответствует ли пакет всем критериям очередного правила, и если так, то выполняет действие (если критериев в правиле нет, то действие выполняется для всех пакетов проходящих через правило). Вариантов возможных критериев очень много. Например, пакет соответствует критерию –source 192.168.1.1 если в заголовке пакета указано, что отправитель - 192.168.1.1. Самый простой тип перехода, –jump, просто пересылает пакет в начало другой цепочки. Также при помощи –jump можно указать действие. Стандартные действия доступные во всех цепочках - ACCEPT (пропустить), DROP (удалить), QUEUE (передать на анализ внешней программе), и RETURN (вернуть на анализ в предыдущую цепочку). Например, команды
Iptables -A INPUT --source 192.168.1.1 --jump ACCEPT iptables -A INPUT --jump other_chain
означают «добавить к концу цепочки INPUT следующие правила: пропустить пакеты из 192.168.1.1, а всё, что останется - отправить на анализ в цепочку other_chain».
Цепочки
Существует 5 типов стандартных цепочек, встроенных в систему:
PREROUTING - для изначальной обработки входящих пакетов.
INPUT - для входящих пакетов адресованных непосредственно локальному процессу (клиенту или серверу).
FORWARD - для входящих пакетов перенаправленных на выход (заметьте, что перенаправляемые пакеты проходят сначала цепь PREROUTING, затем FORWARD и POSTROUTING).
OUTPUT - для пакетов генерируемых локальными процессами.
POSTROUTING - для окончательной обработки исходящих пакетов.
Также можно создавать и уничтожать собственные цепочки при помощи утилиты iptables.
Таблицы
Цепочки организованны в 4 таблицы:
Raw - просматривается до передачи пакета системе определения состояний. Используется редко, например для маркировки пакетов, которые НЕ должны обрабатываться системой определения состояний. Для этого в правиле указывается действие NOTRACK. Содержит цепочки PREROUTING и OUTPUT.
Mangle - содержит правила модификации (обычно заголовка) IP‐пакетов. Среди прочего, поддерживает действия TTL (Time to live), TOS (Type of Service), и MARK (для изменения полей TTL и TOS, и для изменения маркеров пакета). Редко необходима и может быть опасна. Содержит все пять стандартных цепочек.
Nat - просматривает только пакеты, создающие новое соединение (согласно системе определения состояний). Поддерживает действия DNAT, SNAT, MASQUERADE, REDIRECT. Содержит цепочки PREROUTING, OUTPUT, и POSTROUTING.
Filter - основная таблица, используется по умолчанию если название таблицы не указано. Содержит цепочки INPUT, FORWARD, и OUTPUT.
Цепочки с одинаковым названием, но в разных таблицах - совершенно независимые объекты. Например, raw PREROUTING и mangle PREROUTING обычно содержат разный набор правил; пакеты сначала проходят через цепочку raw PREROUTING, а потом через mangle PREROUTING.
Состояния
В системе netfilter, каждый пакет проходящий через механизм определения состояний, может иметь одно из четырёх возможных состояний:
NEW - пакет открывает новый сеанс. Классический пример - пакет TCP с флагом SYN.
ESTABLISHED - пакет является частью уже существующего сеанса.
RELATED - пакет открывает новый сеанс, связанный с уже открытым сеансом. Например, во время сеанса пассивного FTP , клиент подсоединяется к порту 21 сервера, сервер сообщает клиенту номер второго, случайно выбранного порта, после чего клиент подсоединяется ко второму порту для передачи файлов. В этом случае второй сеанс (передача файлов по второму порту) связан с уже существующим сеансом (изначальное подсоединение к порту 21).
INVALID - все прочие пакеты.
Диаграмма прохождения таблиц и цепочек
Упрощённая диаграмма прохождения таблиц и цепочек:
Детальная диаграмма:
Базовая конфигурация
Ниже приведён пример базовой статической конфигурации iptables. При сохранении и загрузке подобной конфигурации необходимо принимать во внимание возможность внесения в неё изменений со стороны других сервисов, например Fail2ban . Кроме того, при использовании IPv6-адресации конфигурацию для IPv6 следует выполнять независимо от IPv4.
IPv4
sudo iptables-saveСоздаём скрипт с дампом правил iptables:
sudo nano / etc/ network/ if-up.d/ iptables-rulesКопируем следующий код:
#!/sbin/iptables-restore -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p icmp -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-host-prohibited #-A OUTPUT -p icmp -j ACCEPT #-A OUTPUT -o lo -j ACCEPT #-A OUTPUT -j REJECT --reject-with icmp-host-prohibited COMMITДополняем нужными правилами с учётом iptables-save.
sudo chmod +x / etc/ network/ if-up.d/ iptables-rules sudo / etc/ network/ if-up.d/ iptables-rulesIPv6
Просмотр текущей конфигурации:
sudo ip6tables-saveСоздаём скрипт с дампом правил ip6tables:
sudo nano / etc/ network/ if-up.d/ ip6tables-rulesКопируем следующий код:
#!/sbin/ip6tables-restore # Таблица filter и её цепочки * filter:INPUT ACCEPT [ 0 :0 ] :FORWARD ACCEPT [ 0 :0 ] :OUTPUT ACCEPT [ 0 :0 ] # Разрешаем связанные и установленые соединения -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Разрешаем служебный icmp-трафик -A INPUT -p ipv6-icmp -j ACCEPT # Разрешаем доверенный трафик на интерфейс loopback -A INPUT -i lo -j ACCEPT # Сюда можно вставлять дополнительные правила для цепочки INPUT # Запрещаем всё остальное для INPUT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited # Порядок и смысл правил для цепочек FORWARD и OUTPUT аналогичен INPUT -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p ipv6-icmp -j ACCEPT -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited # Фильтровать цепочку OUTPUT настоятельно не рекомендуется #-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT #-A OUTPUT -p ipv6-icmp -j ACCEPT #-A OUTPUT -o lo -j ACCEPT #-A OUTPUT -j REJECT --reject-with icmp6-adm-prohibited COMMITДополняем нужными правилами с учётом ip6tables-save.
Сохраняем и закрываем: Ctrl + O , Enter , Ctrl + X
Делаем скрипт исполняемым и загружаем правила iptables:
sudo chmod +x / etc/ network/ if-up.d/ ip6tables-rules sudo / etc/ network/ if-up.d/ ip6tables-rulesДополнительные правила
Ниже приведены некоторые сравнительно часто используемые правила. Цепочки INPUT/OUTPUT применяются для фильтрации локального трафика. Для транзитного трафика необходимо использовать цепочку FORWARD.
Удалённый доступ
# remote.ssh -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 22 -j ACCEPT # remote.rdp -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 3389 -j ACCEPT # remote.vnc -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 5900 -j ACCEPT
Веб и файловые сервисы
# web.http, web.https -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 21 -j ACCEPT
Почта и мгновенные сообщения
# mail.pop3, mail.pop3s -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 110 ,995 -j ACCEPT # mail.imap, mail.imaps -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 143 ,993 -j ACCEPT # mail.smtp, mail.smtps -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 25 ,465 -j ACCEPT # im.xmpp -A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 5222 ,5223 -j ACCEPT # im.icq.oscar -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 5190 -j ACCEPT
Сетевые службы
# network.openvpn.vpn -A INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 1194 -j ACCEPT # network.squid.proxy -A INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 3128 -j ACCEPT # network.dns -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 53 -j ACCEPT # network.ntp -A INPUT -p udp -m conntrack --ctstate NEW -A INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 69 -j ACCEPT # network.dhserver.dhcp.discover-request -A INPUT -p udp -m conntrack --ctstate NEW -m udp --sport 68 --dport 67 -j ACCEPT # network.dhclient.dhcp.discover-request #-A OUTPUT -p udp -m conntrack --ctstate NEW -m udp --sport 68 --dport 67 -j ACCEPT # network.dhserver.dhcp.offer-ack #-A OUTPUT -p udp -m conntrack --ctstate NEW -m udp --sport 67 --dport 68 -j ACCEPT
Тестирование и отладка
Просмотр текущей конфигурации для IPv4 и IPv6:
sudo iptables-save sudo ip6tables-saveЛогирование
Трассировка
Модули ядра
Просмотр загруженных модулей:
lsmod | grep -E "^ip|^nf" | sortДля загрузки дополнительных модулей удобно применять автодополнение: 2x Tab
sudo modprobe nf sudo modprobe modules-load.dВ Linux существует некоторое количество решений для настройки фаервола, однако многие из них являются на самом деле только фронтэндами для настройки iptables, и некоторые не совсем удачными. В принципе, неплохо, когда можно быстро настроить фаервол, но когда вы разберетесь с iptables, вы сможете это сделать быстрее и тоньше. Тонкая настройка iptables фронтэндам обычно недоступна.
Приступим. Начнем с простого, и потом будем усложнять конфигурацию. Здесь на сайте уже есть статья про автозагрузку правил iptables, поэтому мы не будем сейчас рассматривать загрузку правил, а сосредоточимся на самих правилах. Настраивается фаервол всегда под учетной записью root.
Сценарии сетевых подключений
Перед настройкой фаервола обязательно нужно иметь точное представление о том, какие сетевые соединения и как должны устанавливаться при работе системы, чтобы все сервисы могли нормально работать. Чем точнее у нас картина работы сетевых сервисов, как работающих на нашем сервере, так и на других серверах, тем более тонко можно настроить систему. Поэтому желательно всегда сначала описывать сценарии того, как всё должно работать, и только потом начинать настраивать фаервол. Сценарий можно написать в любом текстовом редакторе. Сначала описываем все внешние сервисы, с которыми работает сервер, а затем все сервисы, которые работают на сервере. Зачем это надо? Чтобы точно представлять сам процесс работы, без углубления в техническую часть. После написания максимально точного сценария можно приступать к настройке фаервола. Описание в сценарии должно выглядеть примерно так:
1) Все пользователи могут просматривать сайт. По умолчанию сайт на русском языке.
2) Если пользователи пришли с адресов <список-адресов-или-маска-подсети>, то им должен быть показан сайт на украинском. В нашем примере это будет, допустим, интернет-магазин с одним доменным именем, отображаемый на русском или украинском языке, и имеющий в продаже свой набор для России и Украины. У нас будет просто два сайта, один на русском, второй на украинском, и по адресу, с которого пришел клиент, будет определяться, на какой сайт он попадет. Пример взят из головы, на практике, конечно, такие вопросы решаются по другому. Можно также не разрешать просмотр сайта с китайских адресов из-за постоянного спама в комментариях на китайском.
3) Из офиса должна быть доступна почта, из других мест она не должна быть доступна.
4) Извне должна быть обеспечена возможность подключения к ВПН
5) Мы можем использовать только несколько DNS-серверов, которым мы доверяем. Все остальные сервера DNS должны быть недоступны
6) …..
И так далее. Думаю, достаточно для простого примера. Смысл в том, чтобы максимально точно определить картину сетевого взаимодествия. Любой сценарий имеет только одну цель — формализовать взаимодействие с пользователями и сервисами до составления описаний соединений, включающих порт, протокол, адрес источника, адрес назначения для каждого соединения.
Настройка iptables: Самая простая конфигурация
Если говорить про боевые сервера, то настройка фаервола на двух серверах может сильно различаться, в зависимости от задач, которые выполняют эти сервера. Поэтому я постараюсь описать общие принципы, которыми можно пользоваться при настройке фаервола для любых серверов. Это только база для дальнейшей настройки.
В первую очередь, необходимо очистить загруженные правила:
Iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD
INPUT, OUTPUT, FORWARD — это три основные цепочки, по которым будут идти пакеты, входящие, исходящие и проходящие с интерфейса на интерфейс.
После этого необходимо задать политику по умолчанию. Их всего две — ACCEPT и DROP, принимать пакеты или не принимать. Для боевого сервера всегда необходимо выбирать DROP, а затем открывать всё, что необходимо и не более того.
Для задания таких политик необходимо предварительно разрешить соединения по SSH, будем считать, что мы не меняли стандартный порт (что обычно следует на боевых серверах делать сразу после установки SSH-сервера).
Iptables -t filter -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
И после этого уже можно приступать к изменению политик по умолчанию:
Iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP
Для цепочки OUTPUT пока можно оставить политику по умолчанию ACCEPT, разрешающую исходящие соединения, к ней можно переходить после настройки цепочки INPUT, когда мы запретим входящие соединения. На многих серверах достаточно бывает правильно настроить цепочку INPUT, но мы рассмотрим позже также и настройку OUTPUT для более жесткой конфигурации.
Итак. В данный момент у нас открыт только порт SSH-сервера для входящих соединений, на все остальные порты соединения проходить не будут. Теперь надо добавить прием соединений на порты остальных сервисов, если они на вашем сервере запущены.
Iptables -t filter -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
DNS (обычно достаточно разрешить UDP, но можно также добавить и TCP):
Iptables -t filter -A INPUT -p udp -m udp --dport 53 -j ACCEPT
Iptables -t filter -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
Iptables -t filter -A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
Iptables -t filter -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Но это еще не всё. Порты открыты, сервисы доступны извне, но почта не работает и доменные имена не резолвятся. Дело в том, что при запросе DNS-серверов запрос отправляется с произвольного свободного порта из числа непривелегированных, точно так же, как и соединение с другим почтовым сервером. И ответ эти сервисы отправляют на тот же самый порт. А этот порт, как вы понимаете, у нас закрыт. Мы могли бы открыть этот порт, но мы не знаем, с какого порта будет исходящее соединение. Поэтому мы можем сделать самое простое, что может быть,- разрешить соединения с определенных портов удаленного компьютера:
Iptables -t filter -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT
Iptables -t filter -A INPUT -p udp -m udp --sport 53 -j ACCEPT
Эти два правила разрешают входящие соединения с портов 25/tcp и 53/udp, поэтому, когда с этих портов приходят пакеты по соответствующему протоколу, они будут приняты. Если вы планируете обновлять систему, программное обеспечение или устанавливать пакеты, необходимые для работы, то вам придется разрешить соединения с 80 порта удаленных машин.
Вот теперь самая простая конфигурация iptables у нас готова.
После внесения правил в таблицы, необходимо их сохранить. Для этого можно воспользоваться, например, скриптом.
Обработка источника соединения
Идем дальше. соединение по определенным портам нам необходимо не со всем Интернетом, а с определенными машинами, с определенными IP-адресами. Поэтому мы можем немного усложнить правила, добавив в них адрес источника пакетов.
Iptables -t filter -A INPUT -s 123.123.123.123 -p tcp -m tcp --dport 22 -j ACCEPT
Данное правило позволяет принимать пакеты на 22 порт по протоколу TCP только из источника с адресом 123.123.123.123, на это указывает параметр «-s» (source, источник). Таким образом вы можете ограничить соединения с сервером по SSH одним определенным IP-адресом, либо определенной подсетью, если укажете маску подсети, из которой разрешены соединения вместо отдельного IP-адреса.
Если у вас всегда используется один и тот же почтовый шлюз, через который ваш сервер отправляет почту, то вы можете, например, ограничить соединения с порта 25/tcp, указав этот шлюз в качестве источника.
Правила для конкретного сетевого интерфейса или IP-адреса
На сервере может быть несколько сетевых интерфейсов. Обычно их как минимум два — внешний сетевой и так называемый loopback-интерфейс 127.0.0.1, доступ к которому извне невозможен, если отсутствует соответствующее перенаправление пакетов. У вас также может как минимум еще один IP-адрес, используемый совместно с алиасом сетевого интерфейса, или еще один физический сетевой интерфейс. И на каждом IP-адресе или сетевом интерфейсе могут работать определенные сервисы. Например, на одном веб-сервер Apache, а на втором сервер службы доменных имен bind9. И когда вы разрешаете соединения на определенный порт без указания этого сетевого интерфейса, вы открываете доступ к этому порту на всех интерфейсах. Поэтому есть два способа сузить область действия разрешения.
Первый способ — указать IP-адрес, для которого будет разрешен доступ.
Iptables -t filter -A INPUT -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT
Этот пример показывает, как можно использовать адрес назначения в правиле iptables. При этом также можно использовать адрес источника:
Iptables -t filter -A INPUT -s 123.123.123.123 -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT
В данном пример мы уже ограничиваем доступ двумя адресами, что позволяет получить доступ по SSH к серверу по адресу 234.234.234.234 с адреса 123.123.123.123, с остальных адресов доступ вы получить не сможете.
Второй способ — указать имя сетевого интерфейса. Этот способ также применим, когда внешний адрес может измениться. В случае, если изменится адрес на сетевом интерфейсе, с предыдущим вариантом вы потеряете доступ к серверу. Указание имени интерфейса осуществляется следующим образом:
Iptables -t filter -A INPUT -i eth0 -s 123.123.123.123 -p tcp -m tcp --dport 22 -j ACCEPT
Такой вариант разрешает доступ по SSH на сетевом интерфейсе eth0, на остальных сетевых интерфейсах доступ по SSH будет отсутствовать.
Всё, что мы только что рассмотрели — это только самое начало, в следующей части будет продолжение…
Iptables отвечает преимущественно за фильтрацию пакетов. Настройка Iptables вручную является довольно непростой задачей. Не надейтесь, что разберётесь в этом «снаскока». К счастью, есть много инструментов, которые могут оказать вам помощь в случае, если с iptables вы ещё не разобрались, а обезопасить систему нужно срочно: fwbuilder, firestarter, guarddog, arno firewall - по сути это GUI к iptables. Однозначного ответа что лучше нет. Выбирать вам. Однако, сегодняшняя статья посвящена именно iptables и делится на две части: теория и практика. Самые нетерпеливые могут сразу выполнить практическую часть, хотя подобный подход не рекомендуется.
Внимание! Все действия с iptables производятся от имени привелигированного пользователя!
Теория
Формат записи iptables iptables [-t таблица] [команда] [действие] Пример: iptables -t filter -A INPUT ACCEPTДействия
- ACCEPT - Принять пакет
- DROP - Отбросить пакет
- DNAT - Преобразовать адрес назначения
- SNAT - Изменить исходящий IP-адрес в заголовке пакета
- LOG - Журналирование пакетов и событий
- MARK - Установить метку на пакет
- MASQUERADE - Изменить исходящий IP-адрес в заголовке пакета (отличие от SNAT - работа с динамическими IP)
- QUEUE - Поставить пакет в очередь на обработку
- REDIRECT - Перенаправить пакет/поток на другой порт
- REJECT - Отбросить пакет+уведомить удалённую систему о том. что её пакет отвергнут
- RETURN - Прекратить движение пакета по текущей цепочке и возвратить в вызывающую цепочку
Команды
- -A - Добавить правило в цепочку
- -D - Удалить правило из цепочки
- -R - Заменить одно правило другим
- -I - Вставить новое правило
- -L - Вывести список существующих правил
- -F - Сброс правил
- -Z - Обнуление счётчиков в заданной цепочке
- -N - Создание новой цепочки с заданным именем
- -X - Удаление цепочки
- -P - Задать политику по умолчанию для выбранной цепочки
- -E - Переименовать пользовательскую цепочку
Критерии (общие)
- -p - Указать тип протокола
- -s - IP-адрес источника пакета
- -d - IP-адрес получателя пакета
- -j - Указать действие для правила
- -i - Интерфейс, с которого был принят пакет
- -o - Указать имя выходного интерфейса
- -f - Распространить правило на все фрагменты пакета
TCP критерии:
- –tcp-flags - Определить маску и флаги пакета
UDP критерии:
- –sport - Порт,с которого отправлен пакет
- –dport - Порт,на который адресован пакет
Подробнее в man iptables
Практика
Просмотр текущей конфигурации
$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Если вы узрели подобное, значит ваш файрволл ещё не настроен и разрешает всё. Исправим положение.
Настройка политики по умолчанию
- iptables -P INPUT DROP - блокирование входящих пакетов
- iptables -P OUTPUT ACCEPT - разрешить исходящие пакеты
- iptables -P FORWARD DROP - обработка пакетов, которые попали на сервер с другой машины и ожидают дальнейшего переброса. В примере блокируется. В таком случае вам придётся дописать правила для доверенных машин.
Поскольку входящие пакеты INPUT блокированы, пропишем правило:
$ sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Это разрешит принимать пакеты от ранее установленного соединения и принимать новые пакеты,порождённые этим соединением.
Либо с указанием типа протокола:
$ sudo iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT $ sudo iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
Теперь локальный интерфейс:
$ sudo iptables -A INPUT -i lo -j ACCEPT
- NEW - данные, начинающие новое соединение.
- ESTABLISHED - пакет, приходящий от уже установленного соединения.
- RELATED - новый пакет данных, но порожденный старым установленным соединением
- INVALID - итак понятно
$ sudo iptables-save > /etc/iptables.up.rules
Включить эти правила:
$ sudo iptables-restore < /etc/iptables.up.rules
И увидеть разницу:
$ sudo iptables-L
Запуск iptables при старте системы:
В каталоге /etc/init.d создаем файл с именем iptables
$ sudo touch /etc/init.d/iptables
Прописываем в нём следующее:
#!/bin/sh /sbin/iptables-restore < /etc/iptables.up.rules
Делаем файл iptables исполняемым:
$ sudo chmod +x /etc/init.d/iptables
Добавляем его в автозапуск
$ sudo update-rc.d -n iptables defaults
Запуск iptables при подключении к сети:
$ sudo echo "#! /sbin/iptables-restore" > /etc/network/if-up.d/iptables.up.rules $ sudo iptables-save >> /etc/network/if-up.d/iptables.up.rules $ sudo chmod +x /etc/network/if-up.d/iptables.up.rules
Примечание: в любой момент вы можете проверить загружены ли ваши правила, просто введя от рута iptables-save
Для archlinux сохранение правил iptables осуществляется командой:
$ sudo rc.d save iptables
Определение i ptables - утилита командной строки, является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) netfilter для ядер Linux версий 2.4, 2.6, 3.x, 4.x . Для использования утилиты iptables требуются привилегии суперпользователя (root).
Мы будем разбираться с iptables и без небольшого теоритического вступления не обойтись.
Что бы правильно составлять правила брандмауэра нужно понимать как вообще идут пакеты и что с ними происходит.
Порядок движения транзитных пакетов
| Шаг | Таблица | Цепочка | Примечание |
|---|---|---|---|
| 1 | |||
| 2 | mangle | PREROUTING | Обычно эта цепочка используется для внесения изменений в заголовок пакета, например для изменения битов TOS и пр.. |
| 3 | nat | PREROUTING | Эта цепочка используется для трансляции сетевых адресов (). выполняется позднее, в другой цепочке. |
| 4 | Принятие решения о дальнейшей маршрутизации, т.е. в этой точке решается куда пойдет пакет — локальному приложению или на другой узел сети. | ||
| 5 | mangle | FORWARD | Далее пакет попадает в цепочку FORWARD таблицы mangle. |
| 6 | Filter | FORWARD | В цепочку FORWARD попадают только те пакеты, которые идут на другой хост Вся фильтрация транзитного трафика должна выполняться здесь. Не забывайте, что через эту цепочку проходит траффик в обоих направлениях, обязательно учитывайте это обстоятельство при написании правил фильтрации. |
| 7 | mangle | POSTROUTING | Эта цепочка предназначена для внесения изменений в заголовок пакета уже после того как принято последнее решение о маршрутизации. |
| 9 | nat | POSTROUTING | Эта цепочка предназначена в первую очередь для Source Network Address Translation . Здесь же выполняется и маскарадинг (Masquerading ). |
| 9 | Выходной сетевой интерфейс (например, eth1). |
Для локального приложения(входящие пакеты)
| Шаг | Таблица | Цепочка | Примечание |
|---|---|---|---|
| 1 | Входной сетевой интерфейс (например, eth0) | ||
| 2 | mangle | PREROUTING | Обычно используется для внесения изменений в заголовок пакета, например для установки битов TOS и пр. |
| 3 | nat | PREROUTING | Преобразование адресов (Destination Network Address Translation ). |
| 4 | Принятие решения о маршрутизации. | ||
| 5 | mangle | INPUT | Пакет попадает в цепочку INPUT таблицы mangle. Здесь вносятся изменения в заголовок пакета перед тем как он будет передан локальному приложению. |
| 6 | filter | INPUT | Здесь производится фильтрация входящего трафика. Помните, что все входящие пакеты, адресованные нам, проходят через эту цепочку, независимо от того с какого интерфейса они поступили. |
| 7 | Локальный процесс/приложение (т.е., программа-сервер или программа-клиент) |
От локальных процессов(исходящие пакеты)
| Шаг | Таблица | Цепочка | Примечание |
|---|---|---|---|
| 1 | Локальный процесс (т.е., программа-сервер или программа-клиент). | ||
| 2 | Принятие решения о маршрутизации. Здесь решается куда пойдет пакет дальше — на какой адрес, через какой сетевой интерфейс и пр. | ||
| 3 | mangle | OUTPUT | Здесь производится внесение изменений в заголовок пакета. Выполнение фильтрации в этой цепочке может иметь негативные последствия. |
| 4 | nat | OUTPUT | Эта цепочка используется для трансляции сетевых адресов (NAT) в пакетах, исходящих от локальных процессов брандмауэра. |
| 5 | Filter | OUTPUT | Здесь фильтруется исходящий траффик. |
| 6 | mangle | POSTROUTING | Цепочка POSTROUTING таблицы mangle в основном используется для правил, которые должны вносить изменения в заголовок пакета перед тем, как он покинет брандмауэр, но уже после принятия решения о маршрутизации. В эту цепочку попадают все пакеты, как транзитные, так и созданные локальными процессами брандмауэра. |
| 7 | nat | POSTROUTING | Здесь выполняется Source Network Address Translation . Не следует в этой цепочке производить фильтрацию пакетов во избежание нежелательных побочных эффектов. Однако и здесь можно останавливать пакеты, применяя политику по-умолчанию DROP . |
| 8 | Сетевой интерфейс (например, eth0) |
Как мы поняли есть основные три таблицы:
- mangle — Данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля TTL и TOS).
- filter — основная таблица для фильтрации пакетов, используется по умолчанию. Собственно в этой таблице и происходит фильтрация пакетов.
- nat — обеспечивает работу nat, если вы хотите использовать компьютер в качестве маршрутизатора. Здесь задаются правила для маршрутизации.
Для таблицы nat применимы действия:
- MASQUERADE
Действие DNAT (Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.
SNAT (Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT , автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.
Маскировка (MASQUERADE ) применяется в тех же целях, что и SNAT , но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия — производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP , SLIP или DHCP .
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Выполнить MASQUERADE для всех пакетов идущих из сети 10.8.0.0 на интерфейс eth0 . Для понятности, допустим у нас две сетевые карточки и две сети. Нам надо что бы сеть 10.8.0.0/24 (первая сетевая карточка)могла выйти скажем в интернет через eth0(вторая сетевая карточка)
- raw — Предназначена для выполнения действий с пакетами до их обработки системой.
Собственно таблица по умолчанию filter .
- INPUT - обрабатывает трафик, поступающий непосредственно самому хосту.
- FORWARD - позволяет фильтровать транзитный трафик.
- OUTPUT - позволяет фильтровать трафик, исходящий от самого хоста.
Действие с пакетом.
- ACCEPT - пропуск пакета. Пакет покидает текущую базовую цепочку и следует дальше.
- REJECT - заблокировать пакет и сообщить его источнику об отказе.
- DROP - заблокировать пакет, не сообщая источнику об отказе. Более предпочтительна при фильтрации трафика на интерфейсах, подключенных к интернету, так как понижает информативность сканирования портов хоста злоумышленниками.
- LOG — сделать запись о пакете в лог файл.
Получается у нас цепочка [таблица — filter ] — [ трафик — INPUT ] — [действие — DROP ] логика действий только кажется сложной. Думаю мы с вами на примерах разберемся и станет все просто.
Команд iptables:
- -A добавить правило в конец цепочки.
- -D удалить правило.
- -I вставить правило с нужным номером.
- -L вывести все правила в текущей цепочке.
- -S вывести все правила.
- -F очистить все правила.
- -N создать цепочку.
- -X удалить цепочку.
- -P установить действие по умолчанию.
Начнем разбираться на конкретных примерах.
iptables -A INPUT -p tcp —dport 80 -j ACCEPT
-A
добавить новое правило, INPUT
для входящих пакетов, -p
протокол, один из tcp, udp, udplite, icmp, icmpv6,esp, ah, sctp,
mh, — — dport
порт назначения 80(опция только для протокола), -j
выбрать действие, если правило подошло, ACCEPT
разрешить. То есть разрешить входящий трафик по протоколу tcp на порт 80.
Перечисленные ключи также поддерживают конструкцию с использованием знака ! . Он инвертирует условие, например:
iptables -A INPUT -s ! 192.168.0.50 -j DROP
-s адрес источника - имя хоста(www.help.com), IP-адрес или подсеть в нотации CIDR(192.168.0.1/16) , ! инверсия, DROP запретить. Запретить весь входящий трафик, кроме источника 192.168.0.50 (если бы не было ! , то запретить только с 192.168.0.50 )
iptables -A INPUT -s 192.168.0.50 -j DROP
Запретить входящий трафик с ip — 192.168.0.50 .
Список критериев правил:
- -p Протокол, протокол также можно указать с помощью номера или названия согласно перечислению, приведенному в /etc/protocols . Значение «любой протокол» можно указать с помощью слова all или числа 0 . Так же для протокола есть дополнительные параметры : —sport (—source-port) Позволяет указать исходящий порт (или их диапазон). —dport (—destination-port) Позволяет указать порт назначения (или их диапазон).
- -s Определяет адрес отправителя . В качестве адреса может выступать IP-адрес (возможно с маской), доменное имя (в последних двух случаях перед добавлением правила в цепочку имя резольвится в IP-адрес).
- -i Определяет входящий сетевой интерфейс. Если указанное имя интерфейса заканчивается знаком «+» (например, eth +), то критерию соответствуют все интерфейсы, чьи названия начинаются на указанное имя(etho,eth1).
- -d Определяет адрес получателя . Синтаксис аналогичен -s .
- -o Определяет исходящий сетевой интерфейс. Синтаксис аналогичен -i .
Так же критерия можно комбинировать.
iptables -A INPUT -i eth0 -s 192
.168.0.0 -j DROP
Запретить входящие пакеты с интерфейса eth0 и ip 192 .168.0.0 . А на интерфейс eth1 пакеты пройдут.
А что делать если вы за ранние не знаете какой порт открывать , например хотите что бы FTP сервер работал в пассивном режиме. Модуль conntrack о состоянии соединения поможет, а конкретней критерий - ctstate. Модуль подключается тэгом -m .
iptables -A INPUT -m conntrack —ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack —ctstate NEW -p tcp —dport 21 -j ACCEPT # Разрешаем открывать соединения на 21 TCP-порт.
Возможные состояния:
- NEW - соединение не открыто, то есть пакет является первым в соединении.
- ESTABLISHED - пакет относится к уже установленному соединению. Обычно такие пакеты принимаются без дополнительной фильтрации, как и в случае с RELATED.
- RELATED - пакет открывает новое соединение, логически связанное с уже установленными, например, открытие канала данных в пассивном режиме FTP. Соединение получает статус RELATED если оно связано с другим соединением, имеющим признак ESTABLISHED .
- INVALID — Признак INVALID говорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса.
iptables -A INPUT -m state —state ESTABLISHED,RELATED -j ACCEPT
State и деологический предшественник conntrack, имеет единственный параметр --state , аналогичный параметру --ctstate модуля conntrack (но, в отличие от него, не поддерживающий состояния DNAT и SNAT).
Кратко рассмотрим таблицу таксировщика, которую можно найти в файле /proc/net/ip_conntrack . Здесь содержится список всех активных соединений.
Tcp 6 300 ESTABLISHED src=128.*.*.* dst=194.*.*.* sport=52524 dport=2223 src=194.*.*.* dst=128.*.*.* sport=2223 dport=52524 mark=0 use=2
Первое как понятно это протокол, потом десятичное число(что значит не знаю),потом идет время жизни соединения. Далее состояние ESTABLISHED то есть соединение уже установлено, бывает еще UNREPLIED что значит что ответного трафика еще не было. Далее расположены адреса отправителя и получателя, порт отправителя и получателя. Далее все наоборот соответственно, ASSURED этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений.
Некоторые особенности протоколов.
TCP соединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на который передается SYN/ACK пакет и подтверждает установление соединения пакет ACK .
Как только трассировщик увидел первый (SYN ) пакет, то присваивает ему статус NEW . Как только через трассировщика проходит второй пакет (SYN/ACK ), то соединению присваивается статус ESTABLISHED .
С протоколом UDP немного все по другому этот протокол не предусматривает установления и закрытия соединения, но самый большой недостаток — отсутствие информации об очередности поступления пакетов. Но с точки зрения трасировщика все так же как с TCP. Первому пришедшему пакету присваивает ему статус NEW. Как только вы отправляете ответный пакет присваивается статус ESTABLISHED. Единственное отличия что статут ASSURED присваиваться только когда обменялись уже несколькими пакетами.
Логирование применений правил.
iptables дает возможность вести логи отдельных пакетов и событий. Для этого применяется действие LOG .
iptables -A INPUT -p tcp —syn -j LOG —log-level info —log-prefix «INPUT packets «
—log-level Используется для задания уровня журналирования (log level). Полный список уровней вы найдете в руководстве (man) по syslog.conf. Обычно, можно задать следующие уровни: debug , info , notice , warning , warn , err , error , crit , alert , emerg и panic . Логи пишутся в файл syslog.
—log-prefix Ключ задает текст (префикс), которым будут предварять все сообщения iptables . Сообщения со специфичным префиксом затем легко можно найти, к примеру, с помощью grep . Префикс может содержать до 29 символов, включая и пробелы.
Jun 1 17:12:20 debian kernel: INPUT packets IN=eth0 OUT= MAC=02:1e:6d:00:e2:1c:00:01:e8:11:73:69:08:00 SRC=125.94.12.95 DST=194.87.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=38690 PROTO=TCP SPT=12557 DPT=23 WINDOW=1460$ RES=0x00 SYN URGP=0
Популярные команды управления iptables.
iptables -L -n —line-numbers Посмотреть список правил.
-n номер портов и ip в цифровом варианте.
—line-numbers номер строки.
iptables -F Полностью сбросить правила.
iptables -P INPUT ACCEPT
Правила по умолчанию для таблицы INPUT .
iptables -P OUTPUT ACCEPT
Правила по умолчанию для таблицы OUTPUT.
iptables -P FORWARD DROP
Правила по умолчанию для таблицы FORWARD.
iptables -D INPUT 1 Удаление правила по его номеру в цепочке.
iptables -D INPUT -s 123.45.67.89 -j DROP Удаление правила на основе того, что оно делает.
iptables -I INPUT … Вставка (insert) правила в начало цепочки.
iptables -I INPUT 3 … Или можно указать конкретную позицию.
REDIRECT
Действие REDIRECT предназначено для перенаправления пакетов с одного набора портов на другой внутри одной системы, не выходя за пределы хоста
.
Работает REDIRECT только в цепочках PREROUTING
и OUTPUT
таблицы nat
. Таким образом, область применения сводится только к перенаправлению. Чаще всего это используется для прозрачного прокси, когда клиент из локальной сети коннектится на 80 порт, а шлюз редиректит пакеты на локальный порт прокси:
iptables -t nat -A PREROUTING -p tcp —dport 80 -j REDIRECT —to-port 3128
Новые правила автоматически не сохраняются и после перезагрузки сервера не будут действовать. Поэтому после изменения iptables нам нужно сохранить изменения.
iptables — restore > /etc/iptables Загрузить правила из файла.
Способ сохранять и загружать правила на ваше усмотрение. Мы с вами познакомились только с основами теории iptables, возможности настройки конечно гораздо больше. Более подробно о которых расскажем в другой статье.
