Межсетевой экран linux firewall

Настройка межсетевого экрана в Linux

Внимание! Это руководство нужно применять только войдя в систему локально. Если же Вы войдете в систему удалённо (по SSH, например), то скорее всего потеряете соединение с удалённой системой.

Содержание

Немного теории [ править ]

Принцип работы [ править ]

Все пакеты пропускаются через определенные для них последовательности цепочек. При прохождении пакетом цепочки, к нему последовательно применяются все правила этой цепочки в порядке их следования. Под применением правила понимается: во-первых, проверка пакета на соответствие критерию, и во-вторых, если пакет этому критерию соответствует, применение к нему указанного действия. Под действием может подразумеваться как элементарная операция (встроенное действие, например, ACCEPT, MARK), так и переход в одну из пользовательских цепочек. В свою очередь, действия могут быть как терминальными, то есть прекращающими обработку пакета в рамках данной базовой цепочки (например, ACCEPT, REJECT), так и нетерминальными, то есть не прерывающими процесса обработки пакета (MARK, TOS). Если пакет прошел через всю базовую цепочку и к нему так и не было применено ни одного терминального действия, к нему применяется действие по умолчанию для данной цепочки (обязательно терминальное).

Встроенные действия [ править ]

ACCEPT, DROP и REJECT — базовые операции фильтрации

Таблицы [ править ]

Таблица mangle [ править ]

Данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля TTL и TOS).

Таблица nat [ править ]

Предназначена для операций stateful-преобразования сетевых адресов и портов обрабатываемых пакетов.

Таблица filter [ править ]

Предназначена для фильтрации трафика, то есть разрешения и запрещения пакетов и соединений.

Цепочки [ править ]

Таблица filter содержит следующие цепочки:

• INPUT — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.
• FORWARD — позволяет фильтровать транзитный трафик.
• OUTPUT — эта цепочка позволяет фильтровать трафик, исходящий от самого хоста.

Правила стоит располагать по возможности в порядке от наиболее частых попаданий к наиболее редким.

Персональный межсетевой экран рабочей станции [ править ]

Проверим состояние [ править ]

Вариант 1 (рекомендуется в целях безопасности) [ править ]

При отсутствии правил вывод будет примерно таким:

Если вывод отличается, то сброс настроек можно сделать командой

где empty.rules — текстовый файл, содержащий 5 строк, как в выводе выше.

Вариант 2 [ править ]

При отсутствии правил вывод будет примерно таким:

Установим политики по умолчанию [ править ]

Для цепочки «проходящая» устанавливаем блокировку, для цепочки «выходная» устанавливаем разрешение, для цепочки «входная» устанавливаем блокировку. Далее будут правила, определяющие исключения для этих политик.

Внимание! На этом этапе произойдёт отключение, если связь производилась по SSH.

Исключения (для входящих соединений) [ править ]

1. Разрешим трафик, принадлежащий установленным соединениям

2. Разрешим локальный интерфейс

3. Запретим «неправильный» трафик (не открывающий новое соединение и не принадлежащий никакому установленному соединению).

4. Разрешим новые ICMP запросы (ping). Остальные запросы ping будут обработаны первым правилом.

5. Разрешим новые входные соединения по портам

Если установлен веб-сервер

Если необходима связь по SSH

Если установлен DNS-сервер

есть возможность объединить несколько правил (для увеличения производительности):

6. Все новые входящие соединения, не обработанные предыдущими цепочками, запретим.

Сохраним правила [ править ]

Arch Linux [ править ]

RedHat Linux [ править ]

добавим демон для применения правил при загрузке компьютера

Источник

Создание и тестирование Firewall в Linux, Часть 1.1 Виртуальная лаборатория

Решил написать статью по следам курса, который я делал в прошлом семестре в институте. Конечно, тут я опишу лишь самые главные основы и максимально все упрощу. Постараюсь дать немного теоритической информации, но в основном больше ссылок, картинок и практики.

Итак, речь пойдет о написании firewall в среде Linux. Всю статью я поделю на несколько частей. То, что вы читаете сейчас – первая часть, она поделена еще на три части. Некоторые темы хорошо известны и задокументированы, поэтому я постараюсь отдельно давать минимум теории по ним и отдельно практику. Чтобы всем было интересно. А также ссылки для углубления (часто это будут английские статьи).

Содержание первой части:

Содержание второй части:

Часть 2. Еще не готова, но думаю затронуть следующие темы: краткое введение в таблицы firewall. Stateless vs statefull firewall. Добавление еще одного модуля для загрузки таблиц правил (через виртуальную файловую систему sysfs из первой части, может быть тут я просто дам исходный код, потому что принципиально ничего нового тут нет). Добавим небольшую прокси-программу в user space и пошлем нужный траффик из kernel в прокси, поработаем с содержанием траффика и на этой основе примем решения о его дальнейшей судьбе (добавим возможность блокировать отдельные сайты). А так же возьмем реальную известную атаку основанную на buffer overflow, захватим управление над удаленным компьютером с ее помощью и посмотрим как наш firewall может защитить от этого.

Возможно вторая часть будет разбита на две, или изменена. Буду очень рад вашим комментариям и пожеланиям как по первой части так и по второй.

Введение

Наша цель в этой части – написание программы, которая будет на очень простом уровне контролировать весь траффик. А именно – мы определим какие пакеты можно пропускать, а какие удалять. Создадим простую систему логов, для отслеживания результатов, а так же программу для конечно пользователя, через которую можно будет читать эти результаты и немного управлять программой. Такой вот тривиальный firewall или на русском языке — Межсетево́й экра́н, сетево́й экра́н — это комплекс аппаратных и программных средств в компьютерной сети, осуществляющий контроль и фильтрацию проходящих через негосетевых пакетов в соответствии с заданными правилами. (Wikipedia).

В нашем случае, функцию firewall будет выполнять отдельный компьютер. Выглядить это будет так:

Давайте смотреть. Мы сделаем сеть, в которой будет три виртуальных компьютера – host1, host2, fw и соединим их как на картинке выше.

host1 — получит статичный IP address – 10.0.1.1. Его мы будем защищать.
host2 — который будет в последней части аттакующим и будет иметь статичный IP – 10.0.2.2
fw — будет отслеживать весь трафик, сконфигурируем ему так же интерфейс для выхода в интернет, чтобы можно было при (читать ВК и новости) необходимости скачивать нужный софт.

В двух словах про DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) —сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. (Wikipedia).

То есть он будет сам получать различные настройки, включая IP, для того чтобы иметь возможность через этот сетевой интерфейс, выходить без лишней головной боли в интернет.

Создание виртуальной среды. Теория

Немного про виртуальные машины. В нашем случае, виртуальная машина – это программа, которая будет эмулировать копьютер, благодаря чему, мы сможем запустить на нашем компьютере сразу три операционные системы. Для тех кто совсем не знаком с темой, могут начать тут.

Мы воспользуемся бесплатной программой VirtualBox, которая позволяет создавать виртуальные сети на одном компьютере. Конечно же не принципиально чем именно пользоваться, главное иметь возможность сконфигурировать сеть. Программа бесплатна, ищем, качаем, ставим.
Следующим шагом будет добавить виртуальные машины. Я буду работать с Linux Ubuntu 12, по «историческим причинам». Вы можете скачать последнюю версию. Тем более если ваш копьютер достаточно мощный. Образ Ubuntu можно найти тут.

Я надеюсь, что читающий справится с добавление образа в virtualbox и теперь у вас есть что-то похожее на картинку. Я советую воспользоваться функцией “clone” в virtualbox, для быстрого создания еще двух машин. У меня в роли host1, host2 специально урезанные «легкие» версии ubuntu, без графического интерфейса (не хватает RAM для полноценных).

Примерно так это должно выглядеть в конце

Создание виртуальной среды. Практика

И так, я предполагаю, что у Вас уже есть три виртуальных linux машины, которые мы сейчас сконфигурирует в одну сеть и проверим, что все работает, прежде чем начать писать программу.

Идем в settings и конфигурируем как на фото:

Добавляем сетевое устройство:

Теперь, linux «будет думать», что у нашего компьютера, есть сетевая карта, а если вы посмотрите в Advanced, то увидите, что в нее еще и вставлен кабель. Отлично. Теперь надо сконфигурировать этк карту в операционной системе. Для этого запускаем host1.

На данном этапе, я предполагаю, что читателю ивестно, что такое IP адресс как он выгледит и зачем он нужен. Я буду редактировать в vi, вы можете в любом другом редакторе, но не забываем давать права администратора (запускать с sudo), чтобы иметь возможность сохранить.

«Просим» систему заново прочитать файл конфигурации (чтобы не перезагружать машину):

Запускаем ifconfig и проверяем, что у нас есть сетевая карта под именем eth0, с IP == 10.0.1.1, маской и тд и тп.

То же самое делаем с host2, только IP установить в 10.0.2.2, gateway 10.0.2.3 и не забыть «добавить» сетевую карту в настройках машины в virtualbox (у меня после изменений настроек в virtualbox, машина при загрузке подвисала на пару минут и писала waiting for network configuration… Это связано с тем, что по умолчанию, сетевой интерфейс сконфигурирован как dhcp, то есть, операционная система ждет динамически получить сетевые настройки, но в virtualbox, для этого она должна быть сконфигурирована как NAT, но мы это поменяли, поэтому ОС пытается понять, что не так. Можно сначало загрузить ОС, отредактировать interfaces, потом выключить компьютер, изменить настройки и запустить заново).

Теперь пришла очередь главной машины, которая будет выполнять роль firewall. Напоминаю, что нам понадобятся три сетевые карты, через одну мы сможем выходить в интернет в случае необходимости поэтому она будет определена как NAT. Остальные две будут ответственны пересылать трафик с host1 -> host2 и обратно с host2 -> host1.

Adapter1 – должен быть выставлен как NAT. Настройки Adapter2, Adapter3, такие же как и в предыдущих примерах (Internal network). Запускаем, начинаем конфигурировать сетевые карты. Так должен выглядеть файл interfaces.

А вот – конечный результат конфигурации, после перезапуска:

Последнее, что осталось сделать — это разрешить packet forwarding, для того чтобы компьютер мог брать пакеты с одного сетевого интерфейса(10.0.2.3) на который приходят пакеты от host2 и передать их на другой сетевой интерфейс 10.0.1.3 связннаый соответственно с host1.

Тут все подробно описано. Чтобы настройка была постоянной, нужно изменить следующую строчку в /etc/sysctl.conf:

Сделать это можно любым удобным способом, не забываем sudo. Много информации про конфигурацию интерфесов можно почитать тут.

Проверка

Осталось проверить, что все связно друг с другом и работает. Проверять будем классическим ping

Как видно на картинке, ping «прошел» с host1 -> host2, host2 -> host1, fw -> host1, fw -> host2. Готово, «лаборатория» для будущих экспериментов настроена.

Источник

Simple stateful firewall (Русский)

В статье рассмотрена настройка межсетевого экрана с контекстной фильтрацией (stateful firewall) посредством iptables, с описанием основных правил и их назначения. Для удобства статья разбита на две части. В первой объясняется настройка межсетевого экрана на одиночной машине, во второй — настройка NAT-шлюза в дополнение к файрволу.

Contents

Требования

Прежде всего установите пакет iptables с набором пользовательских утилит, если он ещё не установлен.

В статье предполагается, что в настоящий момент не заданы никакие правила iptables. Узнать текущий набор правил можно командой:

Если всё же какие-то правила существуют, можно сбросить их, загрузив базовый набор:

Другие способы сброса правил можно найти в статье iptables#Сброс правил.

Настройка межсетевого экрана

Создание необходимых цепочек

Создадим две пользовательские цепочки, которые будут использоваться для открытия портов.

В дальнейшем при назначений правил для этих цепочек мы будем всякий раз указывать тип протокола (например, флагом -p tcp ). Этим обусловлен выбор названий цепочек, но вообще говоря, названия могут быть любыми.

Цепочка FORWARD

Если вы хотите настроить свою систему в качестве NAT-шлюза, изучите раздел #Настройка NAT-шлюза. Для обычной системы можно просто задать политику DROP для цепочки FORWARD:

Цепочка OUTPUT

Цепочка OUTPUT может быть крайне полезной в деле фильтрации исходящего трафика, особено для серверов и других устройств, не использующих веб-браузеры и peer-to-peer программы для соединения с произвольными узлами сети Интернет. Тем не менее, правильная настройка цепочки OUTPUT требует понимания назначения конкретной системы. Наборы правил безопасности для настольной системы, ноутбука, облачного или домашнего сервера будут сильно отличаться.

В этом примере весь исходящий трафик разрешён, поэтому для цепочки OUTPUT задаётся политика ACCEPT. Этого недостаточно для полной безопасности, но будет работать на большинстве систем.

Цепочка INPUT

Назначаем политику DROP для цепочки INPUT на случай, если что-то каким-то образом проскочит мимо наших правил. Лучший способ создать надёжный файрвол — запретить весь трафик, отдельно указав то, что разрешено.

Все входящие пакеты, предназначенные для этой машины и пришедшие на любой сетевой интерфейс, будут проходить через цепочку INPUT. Эта цепочка позволяет принимать только те пакеты, которые действительно нужны.

Первое правило цепочки INPUT будет разрешать трафик установленных соединений и любой новый трафик, относящийся к ним, например, сообщения ICMP об ошибке или эхо-ответы (пакеты, которые хост возвращает, когда его пингуют). ICMP — протокол управляющих сообщений (Internet Control Message Protocol). Некоторые сообщения ICMP имеют важное значение для управления перегрузками и определения MTU, и мы разрешаем их этим правилом:

Состояние соединения ESTABLISHED подразумевает одну из двух ситуаций: либо первичная ( —ctstate NEW ) попытка соединения была ранее одобрена другим правилом, либо соединение уже было активно (например, удалённое SSH-подключение) на момент задания правила.

Второе правило разрешит весь трафик от петлевого (loopback) интерфейса, который необходим многим приложениям и службам:

Третье правило будет отбрасывать все пакеты с состоянием INVALID. Существует четыре категории состояния (state): NEW, ESTABLISHED, RELATED и INVALID. Именно наличие категорий отличает межсетевой экран с контекстной фильтрацией от менее безопасного экрана без оной. Состояния отслеживаются модулями ядра nf_conntrack_* , которые загружаются автоматически после добавления правил.

Следующее правило разрешает входящие ICMP эхо-запросы (ECHO_REQUEST), известные как пинги. Только первый пакет будет считаться относящимся к категории NEW, остальные будут обрабатываться правилом «RELATED, ESTABLISHED». Если компьютер не является маршрутизатором, нет необходимости разрешать какой-либо другой ICMP-трафик с состоянием NEW.

Теперь мы прикрепим TCP- и UDP-цепочки к цепочке INPUT для обработки новых входящих соединений. Если соединение разрешено цепочкой TCP или UDP, оно обрабатывается правилом «RELATED, ESTABLISHED». TCP или UDP цепочки будут либо разрешать новые входящие соединения, либо вежливо отклонять их. Новые TCP соединения должны начинаться с SYN-сегмента.

Мы отклоняем TCP-соединения пакетами TCP RESET, а UDP-потоки — сообщениями ICMP «port unreachable», если запрашиваемый порт закрыт. Это имитирует стандартное поведение Linux (в соответствии с RFC), и позволяет отправителю быстро закрыть соединение.

Для прочих протоколов мы добавляем последнее правило в цепочку INPUT, чтобы отклонить остальной входящий трафик с ICMP-сообщением «protocol unreachable». Это также соответствует стандартному поведению Linux.

Итоговый файл iptables.rules

Пример файла iptables.rules после выполнения всех команд выше:

Файл генерируется и сохраняется командой

Данный файл конфигурации можно использовать как исходный для дальнейших настроек в следующих разделах. Если вы настраиваете межсетевой экран удалённо через SSH, перед продолжением добавьте правило, разрешающее новые SSH-подключения (вместо порта 22 выберите нужный):

Цепочки TCP и UDP

Цепочки TCP и UDP содержат правила для разрешения новых TCP-соединений и UDP-потоков к определённым портам.

Открытие портов для входящих соединений

Разрешить входящие TCP-соединения на порт 80 для веб-сервера (HTTP):

Разрешить входящие TCP-соединения на порт 443 для веб-сервера (HTTPS):

Разрешить удаленные SSH-соединения (на порт 22):

Разрешить входящие TCP/UDP запросы для DNS-сервера (порт 53):

Более сложные правила, вроде проверки по нескольким портам, можно найти в iptables(8) .

Port knocking

Port knocking — способ открыть извне порты, которые файрвол по умолчанию держит закрытыми. Port knocking заключается в создании последовательности попыток соединений с заранее выбранными закрытыми портами. При получении корректной последовательности «простукиваний» межсетевой экран открывает определенный порт и разрешает соединение. Подробнее см. Port knocking.

Защита от спуфинга

Если из внешней сети пришёл пакет с зарезервированным (т.е. локальным) адресом отправителя, то имеет место подмена адреса (address spoofing). Стандартный способ блокирования таких пакетов — установить с помощью sysctl параметр rp_filter (Reverse Path Filter) в значение 1 , что включит встроенную в ядро Linux проверку адреса отправителя пакета. Встроенная проверка будет работать лучше, чем отдельные правила iptables на каждый случай. Добавьте в файл /etc/sysctl.d/90-firewall.conf (подробнее см. sysctl) следующую строку:

То же самое можно сделать посредством netfilter, если необходимо ведение статистики и лог-файлов:

Для случая асинхронной маршрутизации используйте значение rp_filter=2 . Флаг —loose в модуле rpfilter делает то же самое посредством netfilter.

Защита от обнаружения

Если вы хотите сделать вашу машину менее заметной в сети, хорошей идеей будет блокировать некоторые входящие запросы.

Блокирование ping-запросов

Запрос «ping» представляет собой ICMP-пакет, посланный с целью убедиться, что между двумя хостами есть связь. Если сеть в порядке, вы можете безопасно блокировать все ping-запросы. Нужно отметить, что это не сделает ваш компьютер необнаружимым — каждый входящий пакет будет отклоняться, поэтому вы всё ещё будете видны при простом «ping-сканировании» по диапазону IP-адресов посредством nmap. Кроме того, нужно иметь в виду, что эта элементарная «защита» усложнит вам жизнь случае возникновения необходимости отладки сети.

Чтобы заблокировать эхо-запросы (echo requests), добавьте следующую строку в файл /etc/sysctl.d/90-firewall.conf (подробную информацию можно найти в статье sysctl):

Больше сведений об этой защите вы найдёте в руководстве iptables(8) , а также в документации и примерах на странице http://www.snowman.net/projects/ipt_recent/

Обман сканеров портов

Сканирование портов производится с целью обнаружения тех из них, которые открыты в настоящий момент. Это позволит атакующему определить запущенные на машине службы и подобрать к ним эксплойты.

Состояние INVALID в правилах iptables «позаботится» обо всех типах сканирования, за исключением сканирований UDP, ACK и SYN (флаги nmap -sU , -sA и -sS соответственно).

ACK-сканирование не используется для определения открытых портов, но зато покажет порты, защищённые межсетевым экраном. Подобно SYN-пакету в TCP-соединениях с состоянием NEW, каждый пакет ACK-сканирования будет отклонен с отправкой ответа TCP RESET по обратному адресу. Некоторые межсетевые экраны вместо этого просто отбрасывают такие пакеты, что позволяет атакующему определить действующие правила.

Модуль recent поможет обмануть остальные типы сканирования портов. Он добавляет хосты к списку недавних соединений, который используется для обнаружения и блокирования попыток атак. Просмотреть списки недавних соединений можно в каталоге /proc/net/xt_recent/ .

SYN-сканирование

При SYN-сканировании сканер портов посылает синхронизационные пакеты на каждый порт с целью создать TCP-соединение. Если порт закрыт, то возвращается ответ TCP RESET, межсетевой экран просто отбрасывает входящий пакет, а открытый порт возвращает ответ SYN ACK.

Модуль recent может использоваться для отслеживания хостов с отклонёнными попытками соединения и возвращения ответа TCP RESET для каждого SYN-пакета, поступившего на открытый порт, как если бы порт был закрыт. Если открытый порт оказался первым в порядке сканирования, то будет возвращён ответ SYN ACK, поэтому приложения вроде ssh следует размещать на нестандартных портах.

Сначала добавьте правило в начало цепочки TCP. Это правило будет отвечать пакетом TCP RESET любому хосту, входившему в список TCP-PORTSCAN в течение последних 60 секунд. Флаг —update управляет периодическим обновлением списка.

Затем необходимо модифицировать правило отклонения TCP-пакетов, чтобы добавлять все хосты с отклонёнными пакетами к списку TCP-PORTSCAN :

UDP-сканирование

Сканирование UDP схоже со сканированием TCP SYN за исключением того факта, что UDP является протоколом без установления соединения. В нём нет «рукопожатий» и подтверждений. Вместо этого сканер посылает UDP-пакеты на каждый UDP-порт. Закрытые порты должны возвращать сообщение ICMP port unreachable, а открытые не возвращают ничего. Поскольку UDP — «ненадежный» протокол, у сканера нет возможности узнать о потере пакетов, поэтому он посылает серию запросов на каждый порт, с которого не вернулся ответ.

Ядро Linux посылает сообщения ICMP port unreachable довольно медленно, поэтому продолжительность полного UDP-сканирования может превысить 10 часов. Однако часто используемые порты проверяются гораздо быстрее, поэтому хорошей идеей будет применить контрмеры, аналогичные защите от SYN-сканирований.

Сначала добавляем правило отклонения пакетов от хостов из списка UDP-PORTSCAN в начало цепочки UDP:

Затем модифицируем правило отклонения пакетов для UDP:

Восстановление последнего правила

Если вы применили хотя бы один из способов защиты выше, бывшее последним правило цепочки INPUT более таковым не является. Теперь оно находится перед правилами защиты от сканирования и те по сути бесполезны. Просто удалите ( -D ) это правило, а затем добавьте его снова ( -A ), это переместит его в конец цепочки.

Защита от других типов атак

В статье sysctl#TCP/IP stack hardening можно найти описание важных с точки зрения безопасности параметров ядра.

Атака полным перебором

Доступные по внешнему IP-адресу сервисы подвергаются атакам полным перебором довольно часто. Реализовать атаку этого типа несложно, а инструментарий — обширен и доступен. К счастью, существует несколько способов защиты от атак полным перебором. Первый способ заключается в создании правил iptables , которые заносят IP-адрес в чёрный список после нескольких попыток установить соединение. При втором способе защиты запускается специализированный демон, который отслеживает лог-файл на предмет неудачных попыток соединения.

Приложения Fail2ban и (в случае sshd ) Sshguard используются для блокировки IP-адресов при превышении допустимого количества попыток аутентификации. Суть их работы состоит в обновлении правил iptables с целью временно или навсегда воспрепятствовать будущим соединениям атакующих.

Ниже представлен пример правил iptables для предотвращения атак полным перебором на сервис SSH.

Большая часть правил очевидна: первое разрешает три попытки соединения в течение 10 секунд, после чего дальнейшие попытки будут отклоняться. Второе — добавляет ограничение на четыре попытки в течение получаса. Дело в том, что атаки полным перебором обычно выполняются медленно и за несколько серий попыток. Дополнительную информацию об этих правилах и их опциях можно найти в оригинальной статье на сайте compilefailure.blogspot.com.

Предложенные выше правила могут использоваться для защиты любой службы, но демон SSH нуждается в ней наиболее часто.

Необходимо также убедиться, что правило -A INPUT -p tcp —dport ssh -m conntrack —ctstate NEW -j IN_SSH находится в верной позиции в последовательности iptables, перед точкой прикрепления цепочки TCP к цепочке INPUT. Это позволит успешно перехватывать новые попытки установления SSH-соединений. Если вы выполнили все предыдущие шаги в этой статье, порядок правил должен быть следующим:

Если вы не используете протокол IPv6, то лучше будет его отключить. В противном случае стоит создать соответствующий набор правил межсетевого экрана.

Скопируйте созданные ранее правила для протокола IPv4 и замените все IPv4-адреса на адреса формата IPv6:

Некоторые правила нужно адаптировать под IPv6. Так, для IPv6 используется обновлённая версия протокола ICMP, и коды ответов при отклонении соединений —reject-with icmp-port-unreachable и —reject-with icmp-proto-unreachable необходимо преобразовать в коды ICMPv6.

Коды ошибок ICMPv6 перечислены в RFC 4443, согласно которому при блокировке межсетевым экраном попыток установления соединения необходимо использовать код —reject-with icmp6-adm-prohibited . Это проинформирует удалённую систему о том, что соединение было отклонено брандмауэром, а не прослушивающей порт службой.

Если уведомлять удалённую систему о наличии файрвола нежелательно, то можно отклонить пакет без сообщения:

Отклонение пакетов по этому правилу будет производиться с сообщением об ошибке —reject-with icmp6-port-unreachable . Следует однако отметить, что одной из основных функций приложений-сканеров является как раз обнаружение межсетевых экранов и обмануть их этим правилом не получится.

This article or section needs expansion.

Следующее правило для протокола IPv6 настроит поведение межсетевого экрана по отношению к новым входящим пингам (ICMP echo requests):

Модуль conntrack не отслеживает действия ICMPv6 Neighbor Discovery Protocol (аналог протокола ARP), поэтому необходимо разрешить трафик ICMPv6 вне зависимости от его состояния для всех прилежащих подсетей. Следующее правило нужно вставить после правила отбрасывания некорректных пакетов —ctstate INVALID , но перед любыми другими правилами DROP или REJECT. Создаётся по одному правилу на каждую подсеть:

Если вы желаете включить DHCPv6, разрешите входящие соединения на UDP-порт 546:

Поскольку в ядре Linux нет встроенной фильтрации по обратному маршруту (reverse path filter) для протокола IPv6, то стоит включить её посредством ip6tables:

Сохранение правил

Набор правил межсетевого экрана завершён и осталось только сохранить его в файл, который будет загружаться при каждом запуске системы.

Сохраняем правила IPv4 и IPv6 командами:

Итоговый файл ip6tables.rules

Пример файла правил ip6tables.rules после выполнения представленных выше команд:

В завершение включите и запустите службы iptables.service и ip6tables.service . Проверьте статус служб, чтобы убедиться, что правила загрузились корректно.

Настройка NAT-шлюза

В этом разделе рассмотрена настройка межсетевого экрана для NAT-шлюза. Предполагается, что вы уже прочитали первую часть данного руководства и настроили цепочки INPUT, OUTPUT, TCP и UDP как было предложено. До этого момента созданные правила относились к таблице filter, при настройке NAT-шлюза нам также понадобится таблица nat.

Таблица filter

Создание необходимых цепочек

Создадим две новые цепочки — fw-interfaces и fw-open:

Цепочка FORWARD

Настройка цепочки FORWARD схожа с настройкой цепочки INPUT в первой части.

Сначала добавляем правило с модулем conntrack, идентичное правилу из цепочки INPUT:

Затем включаем пересылку для доверенных интерфейсов и пропускаем все пакеты через цепочку fw-open:

Остальные пакеты блокируются с отправкой ICMP-сообщения:

Цепочки fw-interfaces и fw-open

Назначение цепочек fw-interfaces и fw-open будет объяснено позже, когда мы будем работать с цепочками POSTROUTING и PREROUTING соответственно в таблице nat.

Таблица nat

В этом разделе предполагается, что исходящий интерфейс (с публичным IP-адресом) носит имя ppp0. Если ваш интерфейс называется иначе, то во всех приведённых ниже правилах следует заменить название на настоящее.

Цепочка POSTROUTING

Сначала мы должны определить, кому разрешено подключаться к сети Интернет. Предположим, имеется подсеть 192.168.0.0/24 (т.е. в неё входят все адреса в диапазоне 192.168.0.0-255), подключённая к интерфейсу eth0. Чтобы разрешить исходящие соединения хостам в этой подсети, настраиваем цепочку fw-interfaces в таблице FORWARD:

Затем необходимо отредактировать все исходящие пакеты, чтобы в поле «адрес отправителя» значился публичный адрес шлюза вместо локального LAN-адреса. Для этого используем таргет MASQUERADE:

Не забудьте указать параметр -o ppp0 , потому что в противном случае сеть не будет функционировать.

Предположим, что есть другая подсеть, 10.3.0.0/16 (с адресами 10.3.*.*), подключённая к интерфейсу eth1. Добавляем аналогичные правила:

Наконец, нужно разрешить пересылку пакетов (если она ещё не включена).

Хосты данных подсетей теперь могут использовать вашу NAT-систему в качестве шлюза. Возможно, вы также захотите настроить DNS- и DHCP-сервер, например, dnsmasq или комбинацию BIND и dhcpd, с целью упрощения настройки разрешения имён (DNS resolving) на клиентских машинах, но эта тема выходит за рамки данного руководства.

Цепочка PREROUTING

В некоторых случаях может понадобиться изменить адрес получателя в заголовке входящего пакета с адреса шлюза на адрес хоста в локальной сети. Для этого нужно настроить созданную ранее цепочку fw-open, а также цепочку PREROUTING таблицы nat.

Например, чтобы изменить адрес получателя входящих SSH-пакетов (порт 22) на адрес ssh-сервера 192.168.0.5 выполните команды:

Во втором примере меняется не только адрес получателя, но и порт. Порт входящего соединения 8000 заменяется на порт 80 веб-сервера по адресу 192.168.0.6:

Настройка для UDP-пакетов производится аналогично.

Сохранение правил

Чтобы сохранить новые правила межсетевого экрана для NAT-шлюза, выполните:

Источник