Muscári

Однажды отсортировав лог веб-сервера увидел over 1k запросов вида:

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

I. дропаем GET запросы w00tw00t.at.ISC.SANS.DFind
Для этого надо добавить следующее правило:

* где 178.63.227.44 – ip вашего сервера

Теперь эти запросы будут блокироваться и в логах веб-сервера не будет флуда.

Это можно легко проверить, попробовав зайти на один из ваших хостов в браузере с таким запросом:

Вроде бы всё.. ааа нет (=

II. логирование в iptables

Захотелось логировать ip таких запросов в iptables, для статистики или just for fun.

чтобы логировать нужно добавить следущее правило:

Правило логирования должно стоять выше/первее правила блокировки запросов “w00tw00t.at.ISC.SANS”, иначе в лог ничего не упадёт.

Теперь история таких запросов будет складываться в /var/log/debug ..хм, а также в /var/log/syslog & /var/log/messages & /var/log/kern.log

Как-то не камильфо, да?

Чтобы iptables скидывался в отдельный лог нужно настроить syslog и изменить правило логирования в iptables.

1. меняем правило логирования в iptables

* где 178.63.227.44 – ip вашего сервера
* –log-level 4 – уровень важности сообщений warning в syslog

2. нужно добавить следущую строку в /etc/syslog.conf

перезапускаем syslog от рута:

теперь лог iptables будет скидываться в /var/log/iptables.log

3. Не смотря на то, что kern.warning вывели в отдельный лог, в /var/log/syslog & /var/log/messages & /var/log/kern.log всё равно будет параллельно логироваться iptables.

Это я исправил следующим образом в /etc/syslog.conf, строки:

изменил на:

опять перезапускаем syslog от рута:

Всё, теперь лог с нашего правила в iptables будет скидываться только в /var/log/iptables.log

Фактически мы все сообщения от ядра уровня warning перенаправили в /var/log/iptables.log
Но при нормальном ходе дел кроме iptables туда ничего попадать не будет.
При необходимости можно повысить/изменить уровень важности с warning на другой, более удобный вам.

Если вдруг пакеты с запросами w00tw00t.at.ISC.SAN дропаются, но логирования нет, то следует проверить порядок правил в iptables:

мы видим, что правило логирования идёт первее правила блокировки, как и должно быть.

III. ограничение и сортировка лога iptables

Также наверно будет актуально выставить лимит логирования, особенно если на сервере сильно ограничено дисковое пространство, это можно сделать так:

где:

Максимальная средняя частота совпадений/пакетов в минуту, которые запишутся в лог.

Максимальное число совпадений/пакетов, при котором условие ещё считается выполненным.
Это число увеличивается на единицу каждый раз когда условие выполняется.
По истечению интервала –limit 5/m значение –limit-burst уменьшается на единицу.

IV. отлючаем ротацию syslog’ом файла /var/log/iptables.log

По умолчанию syslog будет ротировать наш iptables.log раз в неделю, возможно вас это не устроит, как и меня.
За ротацию отвечают несколько скриптов: /etc/cron.daily/sysklogd и /etc/cron.weekly/sysklogd
Открываем /etc/cron.weekly/sysklogd и находим строки:

ага, вот и список файлов, которые будут ротироваться:

ну что, традиционно grep?

хотя.. постойте:

ага, как видем есть специальынй ключ “-s”, поэтому будет правильнее воспользоваться именно им:

Итак, заменяем в /etc/cron.weekly/sysklogd

на

сохраняем файл, всё, теперь sysklogd не будет ротировать наш iptables.log

Как видим ежедневный /etc/cron.daily/sysklogd я не изменял, так как он не трогал мой iptables.log, но если что мысль думаю ясна.

—-
Ну и напоследок, смотрим результаты в /var/log/iptables.log:

#тестировалось на Ubuntu 9.04 Jaunty