Является ли принятие RELATED, ESTABLISHED для всех источников в iptables «слишком открытым»?

9

Я часто видел, как -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTприменяется правило . Пока я не эксперт, эта конкретная линия касается меня. Совершенно очевидно, что правило разрешает весь трафик за исключением того, что соединение должно быть установлено или связано с установленным соединением.

сценарий

  • Я разрешаю подключения к стандартному порту SSH 22из локальной сети серверов в подсети 192.168.0.0/16или что-то еще.
  • SuperInsecureApp®выставляет что-то на порт 1337, который я добавляю в свою INPUTцепочку.
  • Я добавил conntrackправило, чтобы принять ESTABLISHEDи RELATEDиз всех источников
  • Цепная политика DROP

Таким образом, в основном эта конфигурация разрешает SSH-соединения только из локальной сети, в то время как разрешает входящий трафик через порт 1337 из мира.

Вот где расцветает мое замешательство. Будет ли conntrackкаким-либо образом обнаружен недостаток безопасности, который позволит получить установленное соединение на 1337 (поскольку оно открыто для всех), а затем использовать это соединение для получения доступа к порту SSH (или любому другому порту в этом отношении)?

security iptables ip tcp Денкер
источник

Ответы:

8

Я бы не стал считать УСТАНОВЛЕННЫЙ и СВЯЗАННЫЙ трафик слишком открытым. Возможно, вы сможете опустить RELATED, но определенно следует разрешить ESTABLISHED. Обе эти категории трафика используют состояния conntrack.

УСТАНОВЛЕННЫЕ соединения уже были проверены другим правилом. Это значительно упрощает реализацию однонаправленных правил. Это позволяет только продолжить транзакции на том же порту.

СВЯЗАННЫЕ соединения также подтверждаются другим правилом. Они не применяются ко многим протоколам. Опять же, они значительно упрощают настройку правил. Они также обеспечивают правильную последовательность соединений, где они применяются. Это на самом деле делает ваши правила более безопасными. Хотя это может позволить подключиться к другому порту, этот порт должен быть только частью связанного процесса, такого как FTP-соединение для передачи данных. Какие порты разрешены, контролируются специальными модулями контратаки протокола.

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

Учитывая, что вы классифицировали программу на порту 1337 как небезопасную, ее следует запускать с использованием выделенного пользователя без полномочий root. Это ограничит ущерб, который может нанести кто-либо, если ему удастся взломать приложение и получить расширенный доступ.

Крайне маловероятно, что подключение к порту 1337 может использоваться для удаленного доступа к порту 22, но возможно, что подключение к порту 1337 можно использовать для прокси-подключения к порту 22.

Вы можете убедиться, что SSH обеспечен в глубине:

  • Используйте hosts.allow для ограничения доступа в дополнение к ограничениям брандмауэра.
  • Запретите root-доступ или, по крайней мере, потребуйте использования ключей и ограничьте их доступ в файле авторизованных ключах.
  • Аудит сбоев входа в систему. Сканер журналов может отправлять вам периодические отчеты о необычной активности.
  • Подумайте об использовании такого инструмента, как fail2ban, чтобы автоматически блокировать доступ при повторных сбоях доступа.
BillThor
источник
Хотя это был произвольный пример, первое, что я делаю на новых серверах, всегда отключаю root-доступ и аутентификацию в виде открытого текста в sshd - это очень хороший совет. Кроме того, fail2ban фактически уже установлен на реальной установке, из которой был взят пример. «УСТАНОВЛЕННЫЕ соединения уже были проверены по другому правилу» - это была та вещь, в которой я не был уверен, и прекрасно отвечает на мой вопрос. Спасибо за ваш очень четкий ответ!
Денкер
Дополнительный вопрос: с точки зрения производительности это вообще что-то меняет, если conntrackправило находится в начале или в конце цепочки? Насколько я понимаю iptables, он должен был бы обработать все правила на установленных соединениях, если бы он был в конце, и только это единственное правило, если бы он был помещен в начало?
Денкер
@Dencker Вы хотите сначала установить УСТАНОВЛЕННОЕ, СВЯЗАННОЕ правило. Это примет большинство трафика. Кроме того, вы можете захотеть иметь правила, которые принимают наибольшее количество трафика, хотя лучше всего сильно взвесить их для удобства чтения. Мои правила сгруппированы, чувствительны к задержке, высокий трафик (сгруппированы по типу), другие. Iptables имеет счетчики, которые позволяют вам видеть, сколько трафика проходит каждое правило. Я использую Shorewall, который добавляет некоторые полезные настройки по умолчанию и имеет легко читаемый файл правил для построения моих брандмауэров.
BillThor
2

ESTABLISHED и RELATED - это функции «пакетной» фильтрации пакетов, где фильтрация зависит не только от статического набора правил, но и от контекста, в котором рассматриваются пакеты. Вам нужно ESTABLISHED, чтобы позволить соединениям работать, и вам нужно RELATED для соответствующих сообщений ICMP. Фильтрация с учетом состояния позволяет выполнять фильтрацию более точно по сравнению со статическими правилами без сохранения состояния.

Давайте сначала посмотрим на ESTABLISHED. Например, рассмотрим TCP на порту 22. Инициатор (клиент) отправляет SYNв serverIPaddr:22. Сервер возвращается SYN+ACKк клиенту. Теперь очередь за клиентом отправлять ACK. Как должно выглядеть правило фильтрации на сервере, чтобы ACKпринималось только «соответствие» ? Общее правило без гражданства будет выглядеть так

-A INPUT --proto tcp --port 22 -j ACCEPT

который является более либеральным, чем соответствующее государственное правило. Правило апатридом позволяет произвольные сегменты TCP, например , ACKили FINбез установив соединение в первую очередь. Сканеры портов могут использовать такое поведение для снятия отпечатков ОС.

Теперь давайте посмотрим на СВЯЗАННЫЕ. Это используется для сообщений ICMP, в основном сообщений об ошибках. Например, если пакет от сервера к клиенту отброшен, то сообщение об ошибке отправляется на сервер. Это сообщение об ошибке «связано» с ранее установленным соединением. Без правила RELATED нужно было бы либо разрешить входящие сообщения об ошибках вообще (без контекста), либо, как это принято для многих сайтов, вообще отбросить ICMP и дождаться истечения времени ожидания на транспортном уровне. (Обратите внимание, что это плохая идея для IPv6; ICMPv6 играет более важную роль для IPv6, чем ICMP для прежних версий IP.)

countermode
источник