Доброго времени суток!

Работаю над защитой содержимого от атак CGI-сканнеров.
Вот что пока набросал - описание.

Что уже продумано и изменится в ближайшее время:
1. Пропуск указанных полей GET-метода(для текстовых форм и подобного).
2. Анализ POST-данных.
3. Создание и использование базы IP/параметров для защиты от неизвестных вхождений, но частых коннектов(например, больше 10 коннектов/секунда, более 100/минута - блок IP, притом всегда пропуская IP известных поисковых машин).

Есть ли идеи, критика и т.д.?! Очень интересная и важная для меня тема.

Ну идея хорошая, хотя и есть некоторые замечания..

Защиту от доступа к этим файлам лучше реализовывать средствами системы или веб-сервера, потому как не всегда мод-реврайт доступен, и не всегда нужен...
Потом если уж реализовывать так, то можно увеличить количество вариантов ответов, типа 301 Moved Permanently, или 302 на microsoft.com к примеру 
Флуд защита конечно прикол, но имхо лишняя нагрузка... лучше небольшие куски в цикле со sleep 1;  к примеру, пока нас вебсервер не прибьет.

Ну и сам скрипт можно порядочно прооптимизировать...

По поводу частоты попыток входа, то да это надо прорабатывать, и база известных IP тоже идея хорошая...

GoDleSS, а чем они тебе мешают?

nerezus, я же не сказал, что буду ставить ставить эту идею на любой динамический сайт, который делаю. В данном случае - это больше исследования, хотя в более полном и комплексном решении вполне применимо.
Для чего "применимо"? Для отваживание детей, которые мнят себя великими взломщиками. В случае со слип-методами - для снижения нагрузки на процессор несущего сервера.
От серьезных людей так защищаться все равно бесполезно 


Nab, многие люди используют обычные хостинги, а контролировать веб-сервер там не особо получится. Что же касается ограничение на мод_реврайт, чтож, апач много где стоит, не всегда есть резон только в универсальных решениях.


По поводу флуда - согласен, нагрузочный метод очень. Но если куплен недавно хост и кол-во посетителей мало, то использовать для отваживания можно.
Куски со слип(1), хмм... ...не очень эффективно, т.к.:
1. Для нормальной работы придется Push методом пользоваться.
2. Сканнеру главное - заголовок. Если глупые вещи, вроде той, от которой отталкиваюсь (LimpidByte Centurion2.0a), обрабатывают весь ответ, то нормально написанный сканнер скушает первый ответ в режии Push, ухватится за заголовки и прервет текущую итерацию.

Вообще в тестах больше всех мешал "жить" сканнерам слип-метод. Хотя это и вполне логично.


Частота - попыток вещь тонкая, можно случайно и подсеть с непрозрачным проксиком блокировать из-за одного человека. Думаю, что этот метод стоит отрабатывать опытным путем.


Согласен, что не лучший вариант написания, но и не катастрофически плохой. Оптимизирую со временем.
Единственное что не буду делать - переводить в объектный стиль.

Напиши, пожалуйста, как (и чем) тестировал свой "Антисканер".

Какова основная цель защиты?

1. Уменьшение входящего трафика
2. Защита от DOS-атаки (уменьшение нагрузки на Apache)
3. Уменьшение нагрузки на сервер (уменьшение нагрузки, связанной с работой CGI-скриптов и БД)

Если основная цель 3 - ИМХО лучше динамически формировать .htaccess со списком "плохих хостов", добавляя/удаляя информацию именно в него.

Добавлено @ 11:34 
При определенной изворотливости туда же можно и список проверочных файлов запихать и при их запросе сразу вызывать скрипт-блокиратор (с выбором способа "отражения" атаки).

Да и на сколько заметил, всё же стоит, и как-то уж странно выглядит правило у мод_реврайта  (это неполностью регеспы, надо и такое помнить ;) )



2пункт реализуем? 

GoDleSS, если нетрудно приведи список сканеров, с помощью которых тестировал свой "антисканер".

Вот в том-то и проблема, что с mod_rewrite пока не очень дружу, тогда как регэкспами полноценными пользоваться умею. 
Есть возможность напишите грамотные правила по следующим критериям:
1. Перенаправлять запросы вида site.ru/ и site.ru, но это ясно - ^\/?$ $script?%{QUERY_STRING}
2. Перенаправлять все остальные запросы, кроме оканчивающихся на указанные расширения(допустим .png, .jpg, .gif, .css)



В лучшем случае все три варианта.


Вот не хочу пихать все в .htaccess, ближе перлом работать.




Limpid Byte - Centurion 2.0a, Void - Eye build 461, xSpider(правда древний - 6.0, так что еще не Positive technologies).

Большего всего "забить" на происходящее было xSpider-у. Тем не менее и он лагал.

Как? Да просто скармливал адрес хоста, на который поставил сайтик на Nemesis и проводил аудит на CGI-баги(VEYE и Centurion больше ничего не умеют).

Вы должны понимать, что это лишь первый набросок. Он показал хоть какую-то работоспособность, а значит имеет право на существование(имхо). Просто над ним надо работать и работать.

Лучшим вариантом я вижу толька : когда сги-сканер сканит, обязательно несколька запрососв за единицу времени будуn не валидны, далее проста помещаем ip адрес сканящего в blackList через правило ipfw или iptables и все дела.
К примеру за 1 с екунду с 1го ip было произведено 3 некоректных запроса с ошибкой 404, вот мы и помещаем его в блакЛист.
ps: тут минус в том что будут ли у вас прова для работы с правилами .!? (

А так если у вас приложение написано без дыр то нах вам  защита от цги ? 

Станет больше причиной DDoS-атак ;)

В общем случае, только "увелиением размера снаряда" - покупкой специального оборудования и установкой его перед сервером. 



Если работает .htaccess, то перл (php, asp etc  ) просто не вызывается. Следовательно, нагрузка, связанная с работой (запуском и работой) скриптов просто отсутсвует. ИМХО, такой подход даст большую "экономию нагрузки".




Чудес не бывает. Первый вариант ИМХО, лучше реализовывать средствами управления Firewall-ом.

Zuzu, ) я как раз таки про "антисканер"  хардварными штучками имхо не тут ;)
и всё же я указал - 

 Бред. Левая трата оперативки.

 мод_рерайт есть везде. А если его нет - то пора переезжать с бесплатного хостинга.

А теперь объясняю, как лечить: делаешь кеширование(лучше многоуровневое). Ставишь IDS на сервер. Настраиваешь файрвол. Вроде все.