HackMDtags: Linux
Межсетевые экраны в OC Linux
Межсетевой экран что это?
Межсетево́й экра́н, сетево́й экра́н, фаервол — программный или программно-аппаратный элемент компьютерной сети, осуществляющий контроль и фильтрацию проходящего через него сетевого трафика в соответствии с заданными правилами.
IPtables
Фаервол iptables работает путем сравнения сетевого трафика с набором правил.
Правило — это свойства, которыми должен обладать пакет, чтобы получить доступ к серверу, а также действие, которое нужно выполнить над пакетами, соответствующими правилам.
Существует множество опций-действий, которые можно выполнить, если пакет соответствует определенному правилу. Можно установить тип протокола пакета, адрес и порт источника или назначения, используемый интерфейс, отношение пакета к предыдущим пакетам, и т.д.
Target указывает, какое действие должно быть выполнено, если пакет соответствует правилу.
Target может содержать окончательное решение относительно данного пакета (принять его или сбросить соединение), а также может передать пакет для обработки другой цепочке или же просто внести пакет в журнал. Примеры: ACCEPT, DROP, REJECT
Порядок правил в цепи имеет огромнейшее значение.
Правила должны быть расположены таким образом, чтобы пакет сначала проходил через более конкретные правила, а потом — через более общие.
Другими словами, правила в начале цепочки должны быть более специфическими и подробными, чем правила в конце. Тогда пакет будет проходить сначала специфические правила, а затем — более общие, что создает расширяющийся шаблон.
Если пакет не соответствует никаким правилам цепочки, то он отвечает самому общему правилу — политике по умолчанию.
Для начала нужно убедиться, что iptables уже содержит правила, которые сохраняют текущие соединения даже при выполнении политики сброса по умолчанию.
Это особенно важно при подключении к серверу по SSH. При неверной настройке - потеряем доступ к консоли.
Правила фаервола объединяются в группы, которые называются цепочками (chains).
Цепочка представляет собой последовательность правил, относительно которой проверяется пакет.
Если пакет совпадает с одним из правил, фаервол выполняет указанное действие - при этом пакет не проверяется остальными правилами в цепочке.
Из этого следует вывод, что верхние правила важнее!
Такие цепочки создаются пользователем по мере необходимости. По умолчанию существует три цепочки:
- INPUT: обрабатывает все входящие на сервер пакеты;
- OUTPUT: содержит правила для исходящего трафика;
- FORWARD: используется для обработки предназначенного для других серверов трафика, который не был создан на данном сервере. Эта цепочка в основном необходима для маршрутизации запросов на другие серверы.
Каждая цепочка может содержать ноль или больше правил, а также имеет политику по умолчанию (policy).
Политика определяет действие, которое необходимо выполнить в случае если пакет не соответствует ни одному правилу (такой пакет можно сбросить — drop, или принять — accept).
Теперь о самой настройке:
Итак, для начала нужно просмотреть список текущих правил iptables. Для этого используется флаг -L:
Как можно видеть, список содержит три цепочки по умолчанию (INPUT, OUTPUT и FORWARD), в каждой из которых установлена политика по умолчанию (на данный момент это ACCEPT).
Также можно видеть названия столбцов. Но в данном списке нет самих правил, поскольку Ubuntu поставляется без набора правил по умолчанию.
С помощью флага -S данный список можно просмотреть в другом формате, который отражает команды, необходимые для активации правил и политик:
Чтобы сбросить текущие правила (если таковые есть), наберите:
Прежде чем сбросить правила при удаленном подключении необходимо убедиться, что в цепочках INPUT и OUTPUT установлена политика ACCEPT. Это делается так:
Правило, которое разрешает текущее SSH-подключение:
Чтобы понять данное правило, ознакомьтесь с его компонентами:
-A INPUT: флаг -А добавляет (append) правило в конец цепочки. Эта часть команды сообщает iptables о необходимости внести правило в конец цепочки INPUT.-m conntrack: кроме набора основных функций iptables также имеет набор расширений, или модулей, которые отвечают за дополнительные возможности фаервола. Данная часть команды говорит о том, что пользователю необходим доступ к функциям модуля conntrack. Этот модуль позволяет использовать команды, решающие, что делать с пакетом, на основе его отношения к предыдущим соединениям.--ctstate: одна из команд, доступных при вызове модуля conntrack. Данная команда позволяет отслеживать отношение пакетов к другим пакетам, просмотренным ранее. Ей заданы значения ESTABLISHED (что позволяет принимать пакеты, которые являются частью существующего соединения) и RELATED (принимает пакеты, которые связаны с уже установленным соединением). Именно эта часть правила отвечает за текущую сессию SSH.-j ACCEPT: указывает действие (target), которое нужно выполнить над пакетом, который отвечает правилу. В этом случае iptables будет принимать (accept) пакеты, которые отвечают предыдущим критериям.
Данное правило нужно поместить в начало, чтобы убедиться, что уже существующие соединения совпадают с правилами, приняты и выходят из цепи, не достигнув правил DROP.
Добавить разрешение на новые подключения по портам 22, 80.
Команды:
Новые опции:
-p tcp: данная опция пропускает пакеты, использующие TCP (потоко-ориентированный протокол, который используется большинством приложений, поскольку обеспечивает надежную связь).
---dport: данная опция доступна при использовании флага-p tcp. Она указывает входящий порт, с которым должен совпасть порт пакета.
Первое правило пропускает пакеты TCP, направленные на порт 22, а второе правило принимает TCP-трафик, идущий на порт 80.
Разрешить loopback интерфейс
Теперь нужно создать еще одно правило ACCEPT, чтобы убедиться, что сервер работает должным образом.
Как правило, сервисы взаимодействуют путем обмена пакетами; для этого они используют сетевой псевдоинтерфейс кольцевой связи — так называемый loopback device, который направляет трафик обратно на его источник, а не на другие компьютеры.
То есть, если сервису 1 необходимо установить связь с сервисом 2, прослушивающим соединения на порту 4555, то сервис 1 отправляет пакет на порт 4555 с помощью loopback device.
Такое поведение нужно разрешить, поскольку оно является важным условием правильной работы многих программ.
Для этого добавьте следующее правило:
Оно немного отличается от предыдущих правил; рассмотрите его подробнее:
-I INPUT 1: флаг -I говорит iptables вставить (insert) правило. Данный флаг отличается от флага -А (который просто вносит правило в конец цепочки); он указывает цепочку, в которую нужно внести правило, и расположение правила в ней. В данном случае, правило нужно вставить в самое начало цепи INPUT, вследствие чего все правила передвинутся на одну позицию. Это правило нужно разместить в начале цепочки, поскольку оно является одним из основных правил и не должно зависеть от остальных.-i lo: данный компонент правила пропускает пакеты, которые используют интерфейс lo (lo — это другое название для loopback device). Это значит, что любой пакет, использующий данный интерфейс, должен быть принят.
Чтобы просмотреть текущие правила, используйте флаг -S, поскольку флаг -L не выводит некоторую информацию (например, интерфейс, к которому привязано правило, что очень важно в случае с последним правилом):
Запрещающие правила DROP
Итак, на данный момент было создано 4 правила, которые принимают пакеты, основываясь на определенные критерии. Тем не менее, сейчас сервер все равно не блокирует никаких других пакетов.
Если пакет проходит по цепочке INPUT и не отвечает ни одному из четырех правил, будет выполнена политика по умолчанию (ACCEPT), которая так или иначе примет данный пакет. Теперь ее нужно изменить.
Это можно сделать двумя способами, которые имеют достаточно существенные различия.
Первый способ — отредактировать политику по умолчанию цепочки INPUT; для этого наберите:
Данная политика будет отслеживать и сбрасывать все пакеты, не отвечающие ни одному из правил цепочки INPUT. Одним из последствий этого типа конструкции является то, что она будет сбрасывать пакеты даже после сброса самих правил.
Конечно, это повышает уровень безопасности сервера; тем не менее, это может повлечь за собой серьезные последствия, если у пользователя нет другого способа подключиться к серверу. Чаще всего хостинг-провайдеры предоставляют веб-консоль для подключения к серверу в случае возникновения подобных проблем. Такая консоль работает как виртуальное локальное соединение, потому iptables не отреагирует на нее.
Можно сделать так, чтобы сервер автоматически сбрасывал соединение, если правила удалены. Это сделает сервер более защищенным и труднодоступным. Также это означает, что можно вносить правила в конец цепочки, и при этом все нежелательные пакеты будут сброшены.
Альтернативный подход заключается в следующем: в конец цепочки нужно внести правило, сбрасывающее все несоответствующие пакеты, при этом сохраняя политику ACCEPT.
Чтобы вернуть цепочке INPUT политику ACCEPT, наберите:
Теперь можно внести в конец данной цепочки правило, которое будет сбрасывать все несоответствующие пакеты:
В нормальных рабочих условиях результат будет точно такой же, как при использовании политики DROP. Это правило сбрасывает каждый пакет, который достигает его, что предотвращает попадание на сервер пакетов, не соответствующих установленным правилам.
В основном, второй подход применяется в случае необходимости сохранить политику ACCEPT, которая принимает трафик.
То есть, даже если все правила сброшены, пользователь может получить доступ к машине в сети. Этот подход позволяет выполнить действия по умолчанию без необходимости менять политику, которая будет применяться к пустой цепочке. Конечно, это также означает, что любое правило, которое необходимо внести в конец цепочки, должно находиться перед правилом сброса. Это можно сделать, либо временно удалив правило сброса:
либо вставив новое правило в конец цепи (но перед правилом сброса), указав номер строки. Чтобы внести правило в строку 4, наберите:
Если правил много, вычислить номер строки вручную достаточно проблематично; в таком случае iptables может пронумеровать строки:
Это позволяет убедиться, что правило было внесено в нужную строку.
Сохранение правил
Сохранение настроек iptables
По умолчанию все несохраненные правила действуют до следующей перезагрузки сервера; сразу же после перезагрузки несохраненные правила будут потеряны.
В некоторых случаях это полезно, поскольку дает возможность пользователям, случайно заблокировавшим себя, получить доступ к серверу.
Тем не менее, в большинстве случаев все же удобнее сохранить правила и загружать их при запуске сервера.
Это можно сделать несколькими способами; самый простой из них — использовать пакет iptables-persistent, который можно загрузить из репозитория Ubuntu по умолчанию:
Во время инсталляции пакет уточнит, нужно ли сохранить текущие правила для дальнейшей автоматической загрузки; если текущие правила были протестированы (позволяют создавать SSH-подключения) и соответствуют всем требованиям, их можно сохранить.
Так же пакет спросит, нужно ли сохранить существующие правила IPv6 (они устанавливаются при помощи утилиты ip6tables, которая контролирует поступающие пакеты IPv6 почти таким же образом).
По завершении установки появится новый сервис под названием iptables-persistent, который будет запускаться при перезагрузке сервера и возобновлять установленные правила.
Правила NAT
И так представим следующую ситуацию:
Сетевая карточка eth0 подключенная с помощью PPPoE к интернету и eth1 подключенная к сети с адресом 192.168.0.1 к которой подключена сеть с адресами 192.168.0.* в которой нужно раздать интернет.
Включаем маршрутизацию:
Чтобы форвардинг автоматически включался при запуске системы открываем файл:
и добавляем в него строчку: net.ipv4.ip_forward = 1. Затем включаем NAT:
Где ppp0 название вашего интерфейса через который выходите в интернет.
Чтобы NAT работал после перезагрузки можно воспользоваться утилитой iptables-persistent как было сказанно ранее или делаем следующее, сохраняем настройки iptables в файл:
И добавляем в конец файла: /etc/networks/interfaces эту строчку, для автоматической подгрузке правил:
так же в этот файл добавляем правила маршрутизации:
NAT-PAT или NAPT
Пример проброса порта TCP с внешнего IP-адреса на внутренний IP-адрес и порт:
Пример проброса порта UDP с внешнего IP-адреса на внутренний IP-адрес и порт:
Пример проброса порта TCP с внешнего IP-адреса и порта на внутренний IP-адрес и порт:
Пример проброса порта UDP с внешнего IP-адреса и порта на внутренний IP-адрес и порт:
В этих примерах <внешний_интерфейс> относится к сетевому интерфейсу, через который проходит внешний трафик, <внешний_порт> - внешний порт, на который поступает трафик, <внутренний_IP> - внутренний IP-адрес устройства в локальной сети, а <внутренний_порт> - внутренний порт, на который перенаправляется трафик.
UFW надстройка над IPtables.
Определение:
UFW (Uncomplicated Firewall) - это простой в использовании интерфейс командной строки для настройки фаервола IPtables в Linux. UFW предоставляет простой способ управления правилами фильтрации пакетов и настройки NAT. Он предназначен для облегчения настройки и использования фаервола в Linux-системах.
Установка ufw:
Запуск UFW:
Разрешение или блокировка трафика:
Например, sudo ufw allow 22/tcp разрешает доступ к порту 22 по протоколу TCP (обычно используется для SSH).
Блокировка доступа к порту:
Управление соединениями.
Разрешение и блокировка соединений по IP-адресу:
Управление правилами NAT:
UFW и Docker
Почему Docker не работает с UFW?
UFW задуман как очень простой брандмауэр.
Проблема в том, что UFW и Docker пытаются изменить одни и те же базовые правила брандмауэра, и этот конфликт требует дополнительной настройки, если вы хотите запустить UFW и Docker вместе.
Если вы настроите базовый брандмауэр UFW на запрет по умолчанию и разрешение HTTP и SSH, это будет выглядеть безопасным, но не будет блокировать запуск контейнеров Docker, привязанных к другим портам.
Эту проблему может быть трудно поймать, поскольку UFW и Docker – это отдельные системы.
UFW неосознанно обманывает вас и не показывает открытые порты контейнеров Docker.
Это может стать серьезной проблемой, если вы не решите ее.
Например, возможно, вы хотите запустить дашборд администратора на порту 8000 и внести его в белый список для вашего собственного IP-адреса.
Хотя это не самая безопасная настройка, обычно все в порядке, особенно если даш имеет дополнительную аутентификацию.
Тем не менее, UFW покажет правило брандмауэра как правильно внесенное в белый список, и оно, конечно, будет видно вам с вашего места, внесенного в белый список.
Но если оно запущено через Docker, то по умолчанию оно будет видно на порту 8000 из любого места.
Исправление конфигурации Docker
Есть решение, которое предлагает Docker: отредактируйте /etc/default/docker или /etc/docker/daemon.json и просто отключите функциональность iptables в Docker:
Это работает, однако это лишь половинчатое решение.
Это лишает Docker возможности управлять собственными сетями и может привести к тому, что контейнеры вообще не смогут получить доступ в интернет из коробки.
Это все еще может работать, но вам придется вручную поддерживать правила iptables для контейнеров Docker и пользовательских сетей, что сложно, раздражает и лишает цель простоты UFW.
Реальное решение сложное, но, к счастью, достаточно распространенное, поэтому на Github есть полезная публикация с подробным описанием проблемы и шагов по ее устранению.
По сути, вам нужно изменить конфигурацию UFW в /etc/ufw/after.rules и добавить следующий блок в конце:
Вы можете сделать это вручную, но в этом репозитории есть хорошая утилита, которая автоматизирует это и предоставляет несколько полезных команд для проверки реального состояния брандмауэра.
Вы можете загрузить ее из этого репозитория:
После перезапуска изменения должны применяться автоматически, но если они не применяются, вам может потребоваться перезапустить Docker или вашу машину в целом.
После включения все порты должны быть правильно заблокированы.
Белые списки портов контейнеров Docker с помощью UFW
Это решение потребует от вас немного другой конфигурации портов.
В утилите ufw-docker есть команда, которая выборочно вносит порты в белый список для определенных контейнеров Docker.
Однако если вы хотите использовать более продвинутое правило, например, белый список на основе IP, вам придется использовать ufw route allow:
Fail2ban
Если ваш сервер, будь то web или какой то другой смотрит в интернет, практически сразу он будет подвергаться атакам со стороны не доброжелателей. Чтобы защитить его от явных угроз существует замечательное средство fail2ban.
Fail2ban — это инструмент для защиты серверов от атак, основанных на подборе паролей или переборе попыток входа. Он работает, анализируя логи системы и других приложений и автоматически блокирует IP-адреса, с которых обнаружена подозрительная или недопустимая активность.
Fail2Ban может снизить частоту неправильных попыток аутентификации, но не может полностью устранить риск, связанный с слабой аутентификацией. Для достижения более надежной защиты служб рекомендуется настроить использование двухфакторной аутентификации или использовать публичные/частные механизмы аутентификации. Это поможет обеспечить дополнительный уровень безопасности и уменьшить возможность несанкционированного доступа к вашим службам.
Это говорит нам о том, что Fail2ban не является чудотворным средством. Безопасность всегда будет зависеть от нас и от того, насколько серьезно мы относимся к ней в нашей системе.
Fail2ban сканирует файлы журналов (например, /var/log/apache/error_log) и запрещает IP, которые показывают признаки вредоносности — слишком много отказов пароля, поиск эксплойтов и т.д.
Из коробки Fail2Ban поставляется с фильтрами для различных сервисов (apache, courier, ssh и т.д.).
Установка fail2ban:
Fail2ban встраивается в систему и управляется как системная служба. Аналогично таким как сервисы Apache или MariaDB. Он запускается в фоновом режиме и автоматически работает при каждом запуске системы. Администраторы могут управлять и настраивать Fail2ban с использованием соответствующих инструментов и конфигурационных файлов. Также мониторить его работу и результаты через системные журналы или интерфейс командной строки. Такая системная интеграция позволяет Fail2ban эффективно выполнять свои функции по обнаружению и блокировке подозрительной активности.
После установки Fail2ban его требуется запустить, для этого выполните команду:
Конфигурация находится в файле /etc/fail2ban/jail.conf, который мы можем изменить. Но перед изменением требуется создать резервную копию.
Давайте рассмотрим некоторые из основных директив.
Первое что требуется сделать это определить время бана предполагаемого злоумышленника. Для этого найдите bantime и задайте ему подходящее значение. Например два ну или три часа.
Чтобы избежать повторных атак, можно установить время поиска.
То есть, если злоумышленник повторит атаку меньше чем через 5 минут, то он будет забанен, в противном случае счетчик запустится снова.
Директива Max Retry устанавливает количество неудач перед тем, как IP будет забанен.
Если у вас есть доверенная сеть или хост, вы можете заставить Fail2ban игнорировать их с помощью директивы ignoreip.
В этом случае вышеуказанный IP-адрес будет игнорироваться всеми этими правилами.
Если вы прокрутите страницу вниз, вы обнаружите настройки Fail2ban для каждой службы поддерживаемой им, таких как SSH или Apache. Для каждой конкретной службы, вы можете настроить параметры, связанные с обнаружением и блокировкой подозрительной активности. Это позволяет вам адаптировать работу Fail2ban к вашим конкретным потребностям и требованиям безопасности для каждой службы отдельно.
