Должна ли фильтрация исходного IP-адреса быть реализована на самом уровне приложений или делегирована приложением на брандмауэр

Question

Допустим, у моего приложения есть прослушивающий сокет UDP, и оно знает, с каких IP-адресов оно может получать дейтаграммы UDP. Все, что поступает с других IP-адресов, будет считаться вредоносной дейтаграммой и должно быть удалено как можно раньше, чтобы предотвратить DoS-атаки. Сложность заключается в том, что набор этих законных IP-адресов может динамически изменяться в течение срока службы приложения (т. Е. Путем динамического получения их по каналу управления).

Как бы вы реализовали фильтрацию по IP-адресу источника в приведенном выше случае?

Я вижу два решения, где разместить эту исходную логику IP-фильтрации:

1. Реализуйте его в самом приложении после вызова recvfrom().
2. Установите политику удаления по умолчанию в брандмауэре, а затем разрешите приложению устанавливать правила брандмауэра, которые будут динамически вносить в белый список допустимые IP-адреса.

Есть плюсы и минусы для каждого решения. Некоторые, которые приходят мне в голову:

1. iptables может закончиться с O(n) сложностью фильтрации (con для iptables)
2. iptables отбрасывает пакеты еще до того, как они попадают в буфер сокета (pro для iptables)
3. iptables может быть не очень переносимым (con для iptables)
4. iptables из моего приложения может мешать другим приложениям, которые могут также устанавливать правила iptables (con для iptables)
5. если мое приложение устанавливает правила iptables, оно потенциально может стать вектором атаки (con для iptables)

Где бы вы внедрили исходную IP-фильтрацию и почему?

Можете ли вы назвать приложения, которые следуют соглашению № 2 (администратор, устанавливающий статические правила брандмауэра вручную, не считается)?

Answer 1

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

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

Надеюсь это поможет.

Answer 2

Надеемся, что эта ссылка поможет вам брандмауэры сетевого уровня или фильтры пакетов работают в стеке протоколов TCP/IP, не позволяя пакетам проходить через брандмауэр, если они не соответствуют установленному набору правил, определенному администратором или примененному по умолчанию. Современные брандмауэры могут фильтровать трафик на основе многих атрибутов пакетов, таких как IP-адрес источника, порт источника, IP-адрес или порт назначения или служба назначения, такая как WWW или FTP. Они могут фильтровать на основе протоколов, значений TTL, сетевого блока отправителя, источника и многих других атрибутов. Брандмауэры прикладного уровня работают на прикладном уровне стека TCP/IP, перехватывая все пакеты, поступающие в приложение или из приложения, отбрасывая нежелательный внешний трафик от достигаемых защищенных компьютеров без подтверждения отправителю. Дополнительные критерии проверки могут добавить дополнительную задержку к пересылке пакетов к месту назначения. Фильтрация или "песочница" принудительного контроля доступа (MAC) защищают уязвимые сервисы, разрешая или отказывая в доступе на основе MAC-адреса конкретных устройств, которым разрешено подключаться к конкретной сети. Прокси-серверы или службы могут работать на выделенных аппаратных устройствах или в качестве программного обеспечения на компьютере общего назначения, отвечая на входные пакеты, такие как запросы на соединение, и блокируя другие пакеты. Злоупотребление внутренней системой не обязательно приведет к нарушению безопасности, хотя такие методы, как подмена IP-адреса, могут передавать пакеты в целевую сеть. Функция трансляции сетевых адресов (NAT) позволяет скрывать IP-адреса защищенных устройств путем нумерации их с адресами в "частном диапазоне адресов", как определено в RFC 1918. Эта функция обеспечивает защиту от сетевой разведки