На мой веб-сервер Apache в Linux поступают массовые запросы на несуществующий файл. Немедленное влияние - быстрый рост журнала доступа и ошибок. Я уже позаботился об этом, не записывая эти запросы (если они совпадают с конкретной строкой). Мы говорим о 40-50 запросах в секунду с нескольких IP-адресов (для того же файла).
Сначала я думал, что это ботнет, но я считаю, что это какой-то скрипт-кидди, подделывающий исходный ip. Я запускаю iptables на сервере, и мне было интересно, как эти пакеты достигли уровня приложения (HTTP-сервера), минуя первоначальное рукопожатие TCP / IP? Если бы у меня был:
--Default Policy for INPUT chain is to DROP
<snip>
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
<...>
<snip>
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
... не следует ли SYN / ACK, на который отвечает мой сервер, после первоначального запроса на соединение, отправлять на поддельный IP-адрес? И поэтому проиграли? И если пакеты создаются так, как будто они исходят от установленного соединения, не должен ли механизм отслеживания состояния netfilter обрабатывать это (через строку RELATED, ESTABLISHED выше) и распознавать их как не часть установленного сеанса и, следовательно, УДАЛЯТЬ их (через политику по умолчанию: DROP)?
Заранее спасибо, Craconia
p.d. запросы поступают с действительных интернет-адресов.
Даже если они подделывают исходный IP-адрес, требуется подтверждение SYN / ACK TCP, прежде чем можно будет установить соединение с Apache. Это эффективно предотвращает поддельное TCP-соединение. Таким образом, вы можете быть уверены, что все соединения выполняются с IP-адресов, которые вы видите в журналах.
Скорее всего, виноват бот-сеть или открытый прокси. Это или уязвимость где-то на веб-странице. Классический эксплойт встраивает ссылку на большой объект на вашем веб-сервере в HTML-код веб-сайта, заставляя всех клиентов заходить на ваш веб-сервер, пытаясь получить объект с вашего сервера ...
Теперь ваши правила IPTABLES имеют смысл;)
Ваш iptables правила в порядке. В контексте вашего брандмауэра вы больше ничего не можете сделать, кроме как убедиться, что вас не поймает кто-то, использующий маршрутизацию от источника. В ядре Linux есть параметр, называемый rp_filter (фильтр обратного пути), который можно включить, чтобы блокировать пакеты, указывающие исходный маршрут. Поскольку маршрутизация от источника почти никогда не используется вне диагностического контекста, такие пакеты можно безопасно блокировать.
Большинство систем Linux имеют /etc/sysctl.conf, который содержит настройки ядра. Добавьте в этот файл следующие строки:
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
а затем перезагрузитесь, чтобы убедиться, что эти переменные установлены. В качестве альтернативы вы можете установить их во время выполнения на своих индивидуальных сетевых интерфейсах обычными способами, например
echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/rp_filter
...
или
sysctl -w net.ipv4.conf.eth0.rp_filter=1
sysctl -w net.ipv4.conf.eth1.rp_filter=1
...
Как вы исключили возможность ботнета?
Может ли злоумышленник использовать Маршрутизация IP-источника?
из вышеуказанного URL
К сожалению, маршрутизацией от источника часто злоупотребляют злоумышленники в Интернете (и в других местах) и заставляют машину (A) думать, что она обращается к другой машине (B), тогда как на самом деле она обращается к третьей машине ( C). Это означает, что C для некоторых целей контролирует IP-адрес B.
Согласно Статья Microsoft
Удаленный злоумышленник может попытаться получить доступ к системе UNIX, защищенной оболочками TCP, или к серверу Internet Information Server (IIS) Windows NT, защищенному списком доступа на основе адресов источника. Если злоумышленник просто подделывает один из разрешенных адресов источника, злоумышленник может никогда не получить ответ. Однако, если злоумышленник подделывает адрес и устанавливает параметр свободной маршрутизации от источника чтобы заставить ответ вернуться в сеть злоумышленника, атака может быть успешной.
(мой акцент)