Защита системы с помощью 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, задающие необходимые правила.
Итог
На сегодня будет достаточно. Более сложные реализации межсетевого экрана я обязательно будут публиковаться в следующих статьях.
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-протоколов, либо все сразу: