Настройка брандмауэра в основном заключается в поиске разумной политики. Брандмауэры типа iptables могут реализовать политики, наследуя правила администратора. Однако для этого администратору нужно знать, какие типы правил необходимы его инфраструктуре.
Читайте также:
В этой статье вы найдете полезные советы по настройке брандмауэра. Вы узнаете, как повлиять на поведение брандмауэра и оценить уровень защиты сервера. В качестве примера в статье используется iptables, но большинство описанных здесь советов сработают и с другими инструментами.
Выбор политики по умолчанию
При настройке брандмауэра одним из основополагающих решений, которые вы должны принять, является политика по умолчанию. Она определяет, что происходит, когда трафик не отвечает правилам брандмауэра. По умолчанию брандмауэр может принимать любой трафик, не отвечающий его правилам, или же сбрасывать этот трафик.
Политики по умолчанию drop и accept
Политика accept по умолчанию означает, что любой трафик, который не отвечает правилам брандмауэра, может попасть на сервер. Эту политику обычно не рекомендуется применять, потому что это означает, что вам придется поддерживать черный список. Черным списком сложно управлять, потому что для его настройки вы должны предвидеть и заблокировать все типы нежелательного трафика. Это усложняет поддержку списка; более того, в черных списках часто бывают ошибки конфигурации и непредвиденные отклонения от установленной политики.
Альтернативной политикой по умолчанию является drop. Эта политика сбрасывает весь трафик, не соответствующий правилам. При этой политике вам нужно поддерживать белый список. Для этого нужно явно разрешить все необходимые сервисы. Сначала кажется, что для этого нужно выполнить большую работу. Однако это обеспечит более высокую безопасность сервера. К тому же, вы будете точно знать, какой трафик может обрабатываться сервером.
В основном при настройке брандмауэра рекомендуется блокировать весь трафик, который не был явно разрешен правилами. Потому обычно по умолчанию используется политика drop.
Политика drop и правило drop
В iptables и других подобных брандмауэрах политика по умолчанию может быть задана с помощью встроенных функций или реализована путем добавления общего правила drop в конец списка правил.
Различие между этими двумя методами заключается в том, что происходит при сбросе правил брандмауэра.
Если установлена встроенная политика брандмауэра drop, то при сбросе правил (или удалении некоторых из них) сервисы мгновенно станут недоступными удаленно. Это часто используется при настройке политики не очень важных сервисов, чтобы сервер не подвергался вредоносному трафику, если правила были удалены.
Недостатком этого метода является то, что все сервисы будут полностью недоступны до тех пор, пока вы не установите новые правила. Вы даже потенциально можете заблокировать себя на собственном сервере, если у вас нет локального или стороннего способа доступа, чтобы устранить проблему. Если же вы намеренно хотите сбросить правила брандмауэра, вы можете перед этим переключиться на политику accept.
Вместо того чтобы использовать политику drop, вы можете установить политику accept и добавить правило drop в конец списка. Вы можете добавить правило брандмауэра в конце своей цепочки, которая собирает и сбрасывает весь трафик, который не прошел брандмауэр.
В этом случае при сбросе правил брандмауэра все сервисы будут доступны, но не защищены.
В зависимости от вашей ситуации это может быть необходимым злом (что позволит вам подключиться к серверу даже после сброса правил). Если вы решите использовать этот вариант, вы должны помнить, что общее правило сброса всегда идет последним в наборе правил.
Сброс и отклонение трафика
Брандмауэр может отказать в приеме пакетов несколькими способами. Это влияет на то, как клиент воспринимает попытку подключения и как быстро клиент сможет определить, что запрос не будет обслуживаться.
Первый способ – это сброс пакетов, или drop. Drop может использоваться как политика по умолчанию. При этом iptables просто отбрасывает пакет. Брандмауэр не отправляет ответ клиенту и не дает никаких указаний о том, что он когда-либо получал подобные пакеты. Это означает, что клиенты не узнают ничего о своих пакетах.
TCP-соединения, не прошедшие брандмауэр, будут ожидать обработки до достижения предела таймаута. Поскольку UDP является протоколом без установления соединения, отсутствие ответа может запутать клиентов. По факту невозврат пакета может означать, что пакет был принят. Если клиент UDP заботится о своих пакетах, он должен будет повторно отправить их, чтобы попытаться определить, были ли они приняты. Это может увеличить количество времени, которое злоумышленнику придется потратить, чтобы получить правильную информацию о состоянии портов вашего сервера, но это также может вызвать проблемы с трафиком обычных пользователей.
Альтернативой сбросу трафика является явное отклонение пакетов. ICMP (или Internet Control Message Protocol) – это мета-протокол, который используется для отправки сообщений о состоянии, диагностике и ошибках в качестве внеполосного канала, который не полагается на обычные протоколы связи типа TCP или UDP. Когда вы используете цель reject, трафик отклоняется, и ICMP-пакет возвращается отправителю, чтобы сообщить, что трафик получен, но не принят. Сообщение о состоянии может подсказать причину.
Это имеет ряд последствий. Предполагая, что ICMP-трафик может достичь клиента, клиент сразу же узнает, что его трафик заблокирован. При этом обычные клиенты могут связаться с администратором или проверить свои параметры подключения и убедиться, что они обращаются к правильному порту. А злоумышленникам это поможет завершить сканирование и обнаружить открытые, закрытые и отфильтрованные порты за более короткий период времени.
Выбирая между сбросом и отклонением трафика, нужно понимать, что большая часть вредоносного трафика отправляется автоматизированными сценариями. Поскольку сценарии могут работать сколько угодно долго, сброс такого трафика не поможет, кроме того, это будет иметь негативные последствия для обычных пользователей.
Эта таблица покажет, как сервер реагирует на разные запросы в зависимости от политики целевого порта.
| Тип пакета клиента | Команда NMap | Политика | Ответ | Предполагаемое состояние порта |
| TCP | nmap [-sT | -sS] -Pn <server> | Accept | TCP SYN/ACK | Открыт |
| TCP | nmap [-sT | -sS] -Pn <server> | Drop | (нет) | Отфильтрован |
| TCP | nmap [-sT | -sS] -Pn <server> | Reject | TCP RESET | Закрыт |
| UDP | nmap -sU -Pn <server> | Accept | (нет) | Открыт или отфильтрован |
| UDP | nmap -sU -Pn <server> | Drop | (нет) | Открыт или отфильтрован |
| UDP | nmap -sU -Pn <server> | Reject | ICMP Port Unreachable | Закрыт |
В первом столбце указан тип пакета, отправленного клиентом. Во втором столбце перечислены команды nmap, которые можно использовать для тестирования каждого сценария. В третьем столбце указывается политика порта. Четвертый столбец – это ответ, который сервер отправит обратно, а пятый столбец – это то, что клиент узнает о порте на основе полученного ответа.
Политики ICMP
Также существует много разных мнений по поводу того, стоит ли принимать ICMP-пакеты.
Протокол ICMP используется для разных целей. Он часто отправляет ответы, чтобы предоставить информацию о состоянии запросов, отправленных с использованием других протоколов. Возможно, наиболее важной его функцией является отправка и ответ на сетевые пинги для проверки возможности подключения к удаленным хостам.
ICMP-пакеты организованы по типу, а затем по код». Тип определяет общий смысл сообщения. Например, Type 3 означает, что пункт назначения недоступен. Код часто используется для предоставления дополнительной информации о типе. Например, ICMP Type 3 Code 3 означает, что целевой порт недоступен, а ICMP Type 3 Code 0 – что недоступна целевая сеть.
Типы, которые можно заблокировать навсегда
Некоторые типы ICMP устарели, поэтому их, вероятно, следует блокировать безоговорочно. Среди них – подавление ICMP (type 4 code 0) и альтернативный хост (type 6). Типы 1, 2, 7, 15 и выше все устарели, зарезервированы для будущего использования или являются экспериментальными.
Типы, которые следует заблокировать в зависимости от настроек сети
Некоторые типы ICMP полезны при определенных конфигурациях сети, но должны блокироваться в других случаях.
Например, сообщения переадресации ICMP (тип 5) могут помочь выявить неправильную структуру сети. Переадресация ICMP используется, когда для клиента есть лучший маршрут. Поэтому если маршрутизатор получает пакет, который должен быть перенаправлен на другой хост в той же сети, он отправляет сообщение переадресации ICMP, чтобы предложить клиенту в дальнейшем отправлять пакеты через другой хост.
Это полезно, если вы доверяете своей локальной сети и хотите повысить эффективность своих таблиц маршрутизации во время начальной настройки (исправление маршрутов – лучшее долгосрочное решение). Однако в ненадежной сети злоумышленник может отправлять ICMP-перенаправления для управления таблицами маршрутизации на хостах.
Другие типы ICMP, которые полезны в некоторых сетях и потенциально вредны для других, – это объявление маршрутизатора ICMP (тип 9) и вызов маршрутизатор (тип 10). Эти пакеты используются как часть системы IRDP (ICMP Internet Router Discovery Protocol), которая позволяет хостам динамически обнаруживать доступные маршрутизаторы при загрузке или подключении к сети.
В большинстве случаев хосту лучше настроить статические маршруты для шлюзов, которые он будет использовать. Эти пакеты должны приниматься в тех же ситуациях, что и пакеты переадресации ICMP.
Типы, которые можно не блокировать
Ниже перечислены типы ICMP, которые безопасно использовать в большинстве случаев (но вы можете отключить некоторые из них, чтобы повысить безопасность).
- Тип 8 – эхо-запрос. Это пинг-запросы, которые направлены на ваш сервер. Обычно можно не блокировать этот тип, но вы можете заблокировать эти пакеты в случае необходимости или ограничить список адресов, которые могут их отправлять. Блокировка этих пакетов не поможет скрыть ваш сервер – существует еще много способов узнать о существовании вашего хоста.
- Тип 13 – запрос временной метки. Эти пакеты используются клиентами для сбора информации о задержке. Они используются в контрольных суммах. Вы можете заблокировать эти пакеты в случае необходимости или ограничить список адресов, которые могут их отправлять.
Следующие пакеты можно поддерживать без специальных правил путем настройки брандмауэра для ответов на запросы, которые он сделал (используя модуль conntrack, чтобы разрешить трафик ESTABLISHED и RELATED).
- Тип 0 – это ответ на эхо-запрос.
- Тип 3 – цель недоступна. Такие пакеты – это ответы на запросы, созданные вашим сервером, которые сообщают, что пакет не может быть доставлен.
- Тип 11 – это диагностическая ошибка, которая выдается, если сгенерированный сервером пакет был утерян до того, как достиг назначения, из-за превышения его значения TTL.
- Тип 12 – проблема с параметрами: исходящий пакет с вашего сервера был искажен.
- Тип 14 –это ответы на запросы метки времени, сгенерированные вашим сервером.
Некоторые эксперты по безопасности по-прежнему рекомендуют полностью заблокировать трафик ICMP, однако многие пользователи поддерживают его.
Ограничение скорости и количества соединений
Вы можете разрешить доступ к некоторым сервисам и шаблонам трафика, если клиенты не будут злоупотреблять этим доступом.
Ограничение количества соединений
Ограничение количества соединений можно реализовать с помощью расширений типа connlimit. Оно проверит, сколько активных соединений создал клиент. Вы можете ограничить количество этих соединений. Для этого нужно решить:
- Как ограничивать соединения: по адресу, по сети или глобально?
- Ограничивать трафик только для определенного сервиса или к серверу в целом?
Соединения можно ограничить на основе хоста или по сегменту сети (с помощью сетевого префикса). Вы также можете установить глобальное максимальное количество соединений для сервиса или всей машины. Имейте в виду, что их можно комбинировать для создания более сложных политик.
Ограничение скорости
Также вы можете создать правила, которые управляют частотой/скоростью, с которой сервер обрабатывает трафик. Для этого существует ряд расширений – limit, hashlimit и recent. Каждое из расширений управляет скоростью по-своему.
Расширение limit будет пропускать отвечающий правилу трафик до тех пор, пока не будет достигнут предел, после чего оно будет сбрасывать пакеты. Если вы установите лимит 5/sec, правило будет пропускать 5 пакетов в секунду, после чего оно будет недействительно. Это позволяет настроить глобальную скорость сервиса.
Расширение hashlimit более гибкое, оно позволяет указать некоторые из значений, которые iptables будет хэшировать, чтобы оценить соответствие трафика. Например, для создания хэша каждой записи iptables может посмотреть исходный адрес и порт, целевой адрес и порт или произвольную комбинацию этих четырех значений. Он может ограничиваться полученными пакетами или байтами.
Расширение recent динамически добавляет IP-адреса клиента в список или проверяет существующий список, если трафик отвечает правилу. Это позволяет распространить логику ограничения на несколько правил и создать сложный шаблон. Это расширение позволяет указывать количество совпадений и временной диапазон, но также может сбросить временной диапазон, если появится дополнительный трафик.
Управление iptables
Все политики брандмауэра iptables основаны на расширении встроенных цепочек. В простых брандмауэрах это часто принимает форму изменения политики цепочек и добавления правил. В более сложных брандмауэрах часто бывает полезно расширить структуру управления, создав дополнительные сети.
Пользовательские цепочки наследуют вызываемые ими цепочки. У пользовательских цепочек нет политики по умолчанию, потому если пакет проходит по такой цепочке, он вернется в вызываемую цепочку для дальнейшей проверки. Пользовательские цепочки хорошо применять в организационных целях и для повышения надежности правил.
Если вы повторяете определенное условие во многих правилах, возможно, целесообразно будет вместо этого создать правило перехода в новую цепочку. Внутри новой цепочки вы можете определить этот набор правил с общим для всех условием соответствия.
Такой подход имеет много преимуществ. К примеру, разумное использование цепочек для очень похожих наборов правил позволяет упростить создание новых правил и уменьшить количество ошибок. Кроме того, такую политику легче воспринимать.
Заключение
Чтобы узнать больше о брандмауэре iptables, читайте статью Как работает фаервол IPTables.
Следующие мануалы помогут вам настроить правильную политику:
- Настройка фаервола с помощью IPTables на Ubuntu 14.04
- Настройка брандмауэра UFW на сервере Ubuntu 14.04
- Настройка брандмауэра FirewallD в CentOS 7