У нас были следующие правила iptables, которые существуют в наших интерфейсных окнах для предотвращения IP-спуфинга:
-A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
-A INPUT -s 255.0.0.0/8 -j DROP
-A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
-A INPUT -s 0.0.0.0/8 -j DROP
Мы хотим добавить следующие правила сейчас, чтобы еще больше усилить защиту от IP-спуфинга
-A INPUT -s 224.0.0.0/3 -j LOG --log-prefix "Spoofed source IP"
-A INPUT -s 255.0.0.0/8 -j DROP
-A INPUT –s 169.254.0.0/16 -j LOG --log-prefix "Spoofed source IP"
-A INPUT -s 169.254.0.0/16 -j DROP
-A INPUT –s 240.0.0.0/5 -j LOG --log-prefix "Spoofed source IP"
-A INPUT -s 240.0.0.0/5 -j DROP
Вы предлагаете добавить приведенные выше правила в производственную коробку, в которой Apache httpd работает в качестве обратного прокси? Эта производственная коробка находится за балансировщиком нагрузки F5.
Кроме того, нужно ли нам включать указанные ниже параметры ядра, чтобы указанные выше правила работали эффективно?
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.default.log_martians=1
Добавленные вами правила - хороший пример «культа груза».
На шлюзах (маршрутизаторах) должны быть приняты меры антиспуфинга; шлюзы - правильные устройства, потому что они действительно информация о маршруте. Серверы обычно не имеют этой информации. Часто серверы имеют только один канал и маршрут по умолчанию к нему. Если они получили запрос, они должны его обслужить, если у них нет некоторых ACL («эти URL-адреса должны быть доступны только из этого диапазона IP-адресов» и т. Д.). OTOH, когда на серверах есть общедоступные и частные сети и существует политика разделения этих сетей, rpfilter можно использовать для достижения этого автоматически. Обратите внимание, что в настоящее время netfilter есть такое расширение, sysctl не единственный способ реализовать это.
IP-спуфинг часто используется для DoS-атак. Злоумышленники «внедряют» исходные пакеты в сеть, используя IP-адрес жертвы в качестве своего источника. Их цель - заставить ваш сервер отвечать, отправляя ответы жертве.. Ваш сервер не сможет узнать, был ли это поддельный IP-адрес в получаемых запросах; это не будет странный IP вроде 0.2.3.4 что ваши правила брандмауэра отфильтровывают. Если ваш сервер получает поддельные запросы из Интернета, обычно это не та проблема, которую вы можете решить на «последней миле», если вы точно не знаете, что это подделка. и обычно вы можете знать это только в том случае, если в качестве источника используются ваши собственные общедоступные IP-адреса.
Сам по себе спуфинг - это не вопрос "эй, смотри, они использовали 0.2.3.4 исходный IP-адрес в запросах, теперь мы все обречены, если не отбросим такие пакеты ».
Единственная проблема, которую я вижу в этом, заключается в том, что если запрос от 240.0.0.0 БЫЛ законно, он затем заблокирует его, не позволяя ему достичь сервера.
При использовании IP Spoofing действительно сложно определить, является ли это подделкой или нет, поскольку можно сгенерировать законный адрес (говоря как программист).
Единственный вариант, который был бы более «безопасным», - это блокировать только определенные адреса, которые наводняют ваши серверы.