Как выбрать эффективную политику брандмауэра для обеспечения безопасности ваших серверов

Введение

Использование брандмауэра также связано с принятием интеллектуальных политических решений, как и с изучением синтаксиса. Брандмауэры типа iptables предназначены для обеспечения выполнения политики путем интерпретации правил, установленных администратором. Однако вам, как администратору, необходимо знать, какие типы правил имеют смысл для вашей инфраструктуры.

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

Выбор основной политики

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

Политика Default Drop против Default Accept

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

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

Политика Default Drop против Конечного правила Drop

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

Различие между этими двумя методами заключается в том, что происходит, если правила брандмауэра сброшены.

Если функция встроенной политики брандмауэра установлена на значение DROP и правила брандмауэра когда-либо сброшены (сброс), или если определенные сопоставленные правила удалены, ваши службы мгновенно станут недоступными удаленно. Это часто является хорошей идеей при настройке политики для некритических служб, чтобы ваш сервер не был подвержен вредоносному трафику, если правила будут удалены.

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

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

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

Сбрасывание vs Отклонение трафика

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

Первый способ, которым пакеты могут быть отклонены, – это с помощью DROP. Отбрасывание может использоваться в качестве политики по умолчанию или как цель для правил совпадения. Когда пакет отбрасывается, iptables просто отбрасывает его. Он не отправляет никакого ответа обратно клиенту, пытающемуся подключиться, и не дает никаких указаний на то, что он вообще когда-либо получил рассматриваемые пакеты. Это означает, что клиенты (законные или нет) не получат подтверждения о получении своих пакетов.

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

Альтернативой отбрасыванию трафика является явное отклонение пакетов, которые вы не разрешаете. ICMP, или Протокол управления сообщениями Интернета, является мета-протоколом, используемым во всем Интернете для отправки сообщений о состоянии, диагностики и ошибок между хостами как внебандовый канал, не зависящий от обычных протоколов связи, таких как TCP или UDP. Когда вы используете цель REJECT вместо цели DROP, трафик блокируется, и отправителю возвращается пакет ICMP, уведомляющий их о том, что их трафик был получен, но не будет принят. Также может быть включено сообщение о состоянии, чтобы предоставить объяснение.

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

Есть много аспектов, которые следует учесть при принятии решения о том, отбрасывать или отклонять трафик. Одним из важных соображений является то, что большая часть злонамеренного трафика фактически осуществляется автоматизированными сценариями. Поскольку эти сценарии обычно не контролируются, отбрасывание нелегитимного трафика не будет иметь смысла для их эффективного устрашения и окажет негативное воздействие на законных пользователей. Подробнее по этой теме можно узнать на веб-сайте Питера Бени.

Таблица сравнения таблиц ответов на сброс и отклонение

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

Первый столбец указывает тип пакета, отправленного клиентом. Второй столбец содержит команды nmap, которые можно использовать для тестирования каждого сценария. Третий столбец указывает политику порта, применяемую к порту. Четвертый столбец – это ответ, который сервер отправит обратно, а пятый столбец – то, что клиент может заключить о порте на основе полученного ответа.

Политики ICMP

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

ICMP – это протокол, используемый для многих целей. Как упоминалось ранее, его часто отправляют для предоставления информации о состоянии запросов, используя другие протоколы. Одной из его наиболее популярных функций является отправка и ответ на сетевые пинги для проверки возможности подключения к удаленным хостам. Существует много других использований ICMP, которые не так широко известны, но все еще полезны.

ICMP-пакеты организованы по “типу”, а затем дополнительно по “коду”. Тип указывает общий смысл сообщения. Например, Тип 3 означает, что пункт назначения недоступен. Код часто используется для предоставления дополнительной информации о типе. Например, ICMP Тип 3 Код 3 означает, что порт назначения недоступен, в то время как ICMP Тип 3 Код 0 означает, что сеть назначения недоступна.

Типы для блокировки в зависимости от конфигурации сети

Некоторые типы ICMP полезны в определенных сетевых конфигурациях, но должны быть заблокированы в других.

Например, сообщения ICMP redirect (тип 5) могут быть полезными для выявления неправильного дизайна сети. ICMP redirect отправляется, когда для клиента непосредственно доступен более хороший маршрут. Таким образом, если маршрутизатор получает пакет, который должен быть направлен на другой хост в той же сети, он отправляет сообщение ICMP redirect, чтобы сообщить клиенту направлять пакеты через другой хост в будущем.

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

Другие типы ICMP, которые полезны в некоторых сетях и потенциально вредны в других, – это объявление маршрутизатора ICMP (тип 9) и запрос маршрутизатора (тип 10). Пакеты объявления и запроса маршрутизатора используются в рамках протокола обнаружения маршрутизаторов Интернета ICMP (IRDP), системы, которая позволяет хостам при включении или присоединении к сети динамически обнаруживать доступные маршрутизаторы.

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

Типы, которые часто безопасно разрешить

Типы ICMP, которые обычно безопасно разрешить, перечислены ниже, но вы можете отключить их, если хотите быть особенно осторожными.

• Type 8 — Запрос эха: Эти запросы ping направлены на ваш сервер. Обычно безопасно разрешить их (отказ от этих пакетов не скрывает ваш сервер, так как существует множество других способов для пользователей выяснить, активен ли ваш хост), но вы можете заблокировать их или ограничить адреса источников, на которые вы отвечаете, если хотите.

• Type 13 — Запрос метки времени: Эти пакеты могут использоваться клиентами для сбора информации о задержке. Их можно использовать в некоторых техниках определения ОС, поэтому вы можете заблокировать их или ограничить диапазон адресов, на которые вы отвечаете.

Нижеперечисленные типы обычно можно разрешить без явных правил, настроив ваш брандмауэр на разрешение ответов на запросы, которые он сделал (используя модуль \texttt{conntrack} для разрешения трафика \texttt{ESTABLISHED} и \texttt{RELATED}).

• Type 0 — Ответы на эхо: Это ответы на запросы эха (пинги).

• Type 3 — Недоступность места назначения: Легитимные пакеты с сообщением о недоступности места назначения – это ответы на запросы, созданные вашим сервером и указывающие, что пакет не может быть доставлен.

• Type 11 — Время превышено: Это диагностическая ошибка, возвращаемая, если пакет, созданный вашим сервером, умер до достижения места назначения из-за превышения его TTL значения.

• Type 12 — Проблема с параметром: Это означает, что исходящий пакет от вашего сервера был искажен.

• Type 14 — Ответы на метку времени: Это ответы на запросы метки времени, сгенерированные вашим сервером.

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

Ограничение соединений и ограничение скорости

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

Ограничение соединений

Ограничение соединений можно реализовать с использованием расширений, таких как connlimit, чтобы проверить, сколько активных соединений у клиента открыто. Это можно использовать для ограничения количества одновременно разрешенных соединений. Если вы решите ввести ограничение соединений, у вас будут некоторые решения:

• Вы ограничиваете на основе адреса, сети или глобально?
• Вы соответствуете и ограничиваете трафик для конкретной службы или для всего сервера?

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

Ограничение скорости

Ограничение скорости позволяет создавать правила, регулирующие скорость или частоту принятия трафика вашим сервером. Существует несколько различных расширений брандмауэра, которые можно использовать для ограничения скорости, включая limit, hashlimit и recent. Выбор используемого расширения будет зависеть в основном от способа ограничения трафика.

Расширение limit приведет к совпадению правила до достижения лимита, после чего дальнейшие пакеты будут отброшены. Лимит, например, 5/сек, позволит совпадать с 5 пакетами в секунду, после чего правило перестанет совпадать. Это полезно для установки глобального ограничения скорости для службы. Вы также можете использовать дополнительную службу, такую как Fail2ban, для блокировки повторных попыток подключения.

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

Расширение recent динамически добавляет IP-адреса клиентов в список или проверяет существующий список, когда правило совпадает. Это позволяет распределить логику ограничения по различным правилам для сложных шаблонов. Оно имеет возможность указать количество совпадений и временной диапазон, как и другие ограничители, но также может сбросить временной диапазон, если виден дополнительный трафик, заставляя клиента остановить весь трафик, если он ограничен.

Монолитное управление против управления на основе цепочек

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

Переименованные пользовательские цепочки вторичны и неотъемлемо связаны со своей «цепочкой вызова», от которой они происходят. У пользовательских цепочек нет политики по умолчанию, поэтому, если пакет проходит через пользовательскую цепочку, он вернется к цепочке вызова и продолжит оценку. Принимая это во внимание, пользовательские цепочки в основном полезны для организационных целей, чтобы сделать условия сопоставления правил более поддерживаемыми и улучшить читаемость, разбивая условия сопоставления.

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

Решение о том, объединять ли все ваши правила в одну из встроенных цепочек или создавать и использовать дополнительные цепочки, зависит от сложности вашего набора правил.

Заключение

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

Если вы хотите узнать больше о брандмауэрах и iptables в частности, ознакомьтесь со следующими статьями:

• Как работает брандмауэр Iptables
• A Deep Dive into Iptables and Netfilter Architecture

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

• Как настроить брандмауэр с использованием Nftables на Ubuntu 22.04
• Как настроить брандмауэр с помощью UFW на Ubuntu 22.04
• Как настроить брандмауэр с использованием FirewallD на Rocky Linux 9