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

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

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

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

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

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

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

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

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


linux firewall sockets network-programming denial-of-service
person user389238    schedule 28.10.2015    source источник
comment
iptables — это уровень ядра, приложение — это пользовательское пространство. Там есть существенная разница. Я бы ожидал реализации, подобной tcpwrapper, если бы вы делали что-то в пользовательском пространстве ... но, как правило, вся причина для этого - общая инфраструктура, такая как правила разрешения / запрета Apache.   -  person Mike Guelfi    schedule 28.10.2015

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Joel C    schedule 29.10.2015

arrow_upward
-3
arrow_downward

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

person user5496545    schedule 28.10.2015