Защита системы с помощью netfilter & iptables. управление правилами

Критерии для пакетов

Общие критерии — допустимо употреблять в любых правилах, они не зависят от типа протокола и не требуют подгрузки модулей расширения:

  • (или ) — используется для указания типа протокола (, , , )
  • (или ) — используется для указания ip-адреса источника; можно указать единственный ip-адрес (10.10.10.10) или диапазон ip-адресов (10.10.10.0/24)
  • (или ) — используется для указания ip-адреса места назначения; можно указать единственный ip-адрес (10.10.10.10) или диапазон ip-адресов (10.10.10.0/24)
  • (или ) — интерфейс, с которого был получен пакет, допускается только в цепочках , и ; при отсутствии этого критерия предполагается любой интерфейс
  • (или ) — интерфейс, с которого будет отправлен пакет, допускается только в цепочках , и ; при отсутствии этого критерия предполагается любой интерфейс

Неявные критерии — неявно подгружают модули расширений и становятся доступны при указании критерия . Рассмотрим некоторые из них:

  • (или ) — исходный порт, с которого был отправлен TCP-пакет. В качестве параметра может указываться номер порта или название сетевой службы. Соответствие имен сервисов и номеров портов можно найти в файле . Номера портов могут задаваться в виде интервала из минимального и максимального номеров.
  • (или ) — порт или диапазон портов, на который адресован TCP-пакет. Аргументы задаются в том же формате, что и для .
  • (или ) — исходный порт, с которого был отправлен UDP-пакет. В качестве параметра может указываться номер порта или название сетевой службы. Соответствие имен сервисов и номеров портов можно найти в файле . Номера портов могут задаваться в виде интервала из минимального и максимального номеров.
  • (или ) — порт или диапазон портов, на который адресован UDP-пакет. Аргументы задаются в том же формате, что и для .

Явные критерии — требуют явной подгрузки модулей расширения с помощью опции или . Например, если планируется использовать критерий , то нужно явно указать левее используемого критерия. Рассмотрим некоторые из них:

  • — проверяет признак состояния соединения: , , и . Состояние подразумевает, что пакет открывает новое соединение или пакет принадлежит однонаправленному потоку. Состояние указывает на то, что пакет принадлежит уже установленному соединению, через которое пакеты идут в обеих направлениях. Состояние указывает на то, что пакет принадлежит уже существующему соединению, но при этом он открывает новое соединение. Состояние подразумевает, что пакет связан с неизвестным потоком или соединением и, возможно содержит ошибку в данных или в заголовке.
  • (устарел, не рекомендуется) — проверяет признак состояния соединения: , , и .
  • — служит для указания списка исходящих портов, можно указать до 15 различных портов. Названия портов в списке должны отделяться друг от друга запятыми, пробелы в списке недопустимы. Может использоваться только совместно с критериями или . Главным образом используется как расширенная версия обычного критерия .
  • — служит для указания списка входящих портов, можно указать до 15 различных портов. Названия портов в списке должны отделяться друг от друга запятыми, пробелы в списке недопустимы. Может использоваться только совместно с критериями или . Главным образом используется как расширенная версия обычного критерия .
  • — проверяет как исходящий так и входящий порт пакета. Формат аргументов аналогичен критерию и . Данный критерий проверяет порты обоих направлений, если задан критерий — под него попадают пакеты, идущие с порта 80 на порт 80.
  • — MAC адрес сетевого узла, передавшего пакет, в формате . Имеет смысл только в цепочках , и и нигде более.
  • — позволяет указать диапазон ip-адресов источника, например 192.168.1.10-192.168.2.20
  • — позволяет указать диапазон ip-адресов места назначения, например 192.168.1.10-192.168.2.20

Предоставление доступа к сервисам в локальной сети

Предположим, что в нашей локальной сети имеется какой-то хост с 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/) и не забываем его сделать исполняемым:
# cat /etc/network/if-up.d/firewall
#!/bin/bash
/sbin/iptables-restore < /etc/iptables.rules
exit 0
# chmod +x /etc/network/if-up.d/firewall

Дамп правил, полученный командой 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, задающие необходимые правила.

Итог

На сегодня будет достаточно. Более сложные реализации межсетевого экрана я обязательно будут публиковаться в следующих статьях.

Navigation menu

Our experts are sharingtheir knowledge with you.

Categories

▼ Server Hardware

► Hard Disk Drives

no subcategories

► HBAs

no subcategories

► Intel

no subcategories

▼ Modular Server

► Modular Server Ethernet Switch

no subcategories

▼ Motherboards

► BIOS Settings

no subcategories

▼ RAID Controllers

► 3ware

no subcategories

▼ Adaptec

► Adaptec SmartRAID

no subcategories

► LSI

no subcategories

▼ Server

► Backplanes

no subcategories

► LES

no subcategories

▼ SSDs

► Intel SSDs

no subcategories

▼ Server Software

▼ Linux

► Debian

no subcategories

► Linux Basics

no subcategories

► Linux Networking

no subcategories

▼ Linux Performance

► Fio

no subcategories

► TKperf

no subcategories

► Linux Software RAID

no subcategories

▼ Linux-Storage

LVM

no subcategories

► Smartmontools

no subcategories

► Ubuntu

no subcategories

▼ Windows

► Windows Server 2012

no subcategories

► Windows Server 2016

no subcategories

► Windows Server 2019

no subcategories

▼ Storage

► FreeNAS

no subcategories

▼ Virtualization

► Hyper-V

no subcategories

► Proxmox

no subcategories

► VirtualBox

no subcategories

▼ VMware

▼ VMware

▼ VMware

► VMware

► VMware vSphere 5

► VMware vSphere 5.1

► VMware vSphere 5.5

► VMware vSphere 6.0

► VMware vSphere 6.5

► VMware vSphere 6.7

► VMware vSphere 5

no subcategories

► VMware vSphere 5.1

no subcategories

► VMware vSphere 5.5

no subcategories

► VMware vSphere 6.0

no subcategories

► VMware vSphere 6.5

no subcategories

► VMware vSphere 6.7

no subcategories

► VMware vSphere 5

no subcategories

► VMware vSphere 5.1

no subcategories

► VMware vSphere 5.5

no subcategories

► VMware vSphere 6.0

no subcategories

► VMware vSphere 6.5

no subcategories

► VMware vSphere 6.7

no subcategories

▼ Focus Topics

► Git

no subcategories

► UEFI

no subcategories

▼ Network+Accessories

► Load Balancer

no subcategories

► Monitoring

no subcategories

▼ OPNsense

► OPNsense Business Edition

no subcategories

▼ Remote Management

► IPMI

no subcategories

► TKmon

no subcategories

▼ Archive

► AMD

no subcategories

► Areca

no subcategories

► Fusion-io

no subcategories

► News

no subcategories

► Server Hardware Archive

no subcategories

► STEC

no subcategories

Коллекция аддонов Xtables-addons

Проект patch-o-matic (-ng), предлагавший различные расширения для iptables, уже некоторое время не развивается, его место занял Xtables-addons (xtables-addons.sf.net). Главная его особенность — для установки модулей не требуется пересборка ядра и/или iptables. В итоге добавление новых функций происходит очень просто, нет проблем и при обновлении ядра. Если ядро собиралось вручную, проверь наличие CONFIG_NETFILTER_XTABLES в параметрах:

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

…выдаст два пакета: один с инструментами и библиотеками, другой — с исходниками.

Как правило, в репе находится не самая актуальная версия, поэтому качаем с сайта архив с исходными текстами, распаковываем и даем стандартную последовательность команд: «./configure; make; make install».

Проверяем загрузку модуля:

Теперь можно создавать правила. В состав пакета входит более 20 модулей и утилит различного назначения. Документации на сайте как таковой нет, но практически все, что нужно для старта, описано в «man xtables-addons». Разберем самые популярные из них.Отфильтровать шныряющих сканеров и ботов вручную по IP-адресам невозможно, но можно существенно уменьшить поток, отрезав страны, имеющие «скверную репутацию». Модуль GeoIP позволяет применять правила к пакетам на основании страны источника/ назначения. Но чтобы фильтр работал, необходимо скачать и установить базы. Для этой цели используются два скрипта, лежащие в каталоге /usr/ libexec/xtables-addons (или /usr/lib/xtables-addons). Для обработки CSV потребуется соответствующий модуль Perl:

После выполнения последней команды будет выведена таблица стран, которые затем указываются через запятую в параметрах ‘—src-cc’ (страна источник), ‘—dst-cc’ (назначение). Все параметры можно узнать, выполнив «iptables -m geoip –help».

Используя GeoIP, можно маркировать трафик, чтобы его обрабатывать по-другому или считать отдельно:

Все привыкли, что атакуемый хост отражает нападение, просто блокируя IP-адрес, и никак активно не противодействует злоумышленнику. В комплекте аддонов доступно несколько модулей, позволяющих ответить или ввести в заблуждение. Самый известный из них носит название TARPIT. Работает он просто: при подключении соединение открывает, но вот закрыть «забывает» (посылает в ответ пакет с размером TCP окна равным нулю). Удаленная система правильно обработать такой посыл не может и отправляет в ответ сообщение о закрытии соединения, которое игнорируется. В итоге соединение «висит» около двадцати минут, потребляя ресурсы удаленной системы. Например, SSH-сервер часто подвешивают на порт, отличный от 22. Это спасает от некоторых сканеров, для остальных ставим ловушку:

Теперь все, кто попробует подключиться к 22 порту, попадут в расставленные сети.

Модуль DELUDE позволяет ввести в заблуждение сканер, показывая, что запрашиваемый порт открыт и принимает подключения. Если ты еще не решил, какой лучше, TARPIT или DELUDE, используй CHAOS, который в ответ на запрос применяет в основном DROP (по умолчанию к большинству пакетов), но иногда — TARPIT, DELUDE или REJECT. Поведение модуля можно изменить, установив параметры при загрузке при помощи ‘—delude’/’—tarpit’ или в процессе выполнения в файле /sys/modules/ xt_CHAOS/parameters.

Проект IPP2P прекратил свое существование, но в аддонах доступен соответствующий модуль, позволяющий распознавать P2P-трафик, который затем можно блокировать или ограничить. В качестве доппараметров можно указать один из P2P-протоколов, либо все сразу:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector