Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Perl: разработка для Web > "Активная оборона" от CGI сканнеров

Автор: GoDleSS 7.3.2007, 01:24

Доброго времени суток! Работаю над защитой содержимого от атак CGI-сканнеров. Вот что пока набросал - http://nomia.ru/note/Data/32.html. Что уже продумано и изменится в ближайшее время: 1. Пропуск указанных полей GET-метода(для текстовых форм и подобного). 2. Анализ POST-данных. 3. Создание и использование базы IP/параметров для защиты от неизвестных вхождений, но частых коннектов(например, больше 10 коннектов/секунда, более 100/минута - блок IP, притом всегда пропуская IP известных поисковых машин). Есть ли идеи, критика и т.д.?! Очень интересная и важная для меня тема.

Автор: Nab 7.3.2007, 04:22

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

Автор: nerezus 7.3.2007, 07:38

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

Автор: GoDleSS 7.3.2007, 09:44

nerezus, я же не сказал, что буду ставить ставить эту идею на любой динамический сайт, который делаю. В данном случае - это больше исследования, хотя в более полном и комплексном решении вполне применимо. Для чего "применимо"? Для отваживание детей, которые мнят себя великими взломщиками. В случае со слип-методами - для снижения нагрузки на процессор несущего сервера. От серьезных людей так защищаться все равно бесполезно  Nab, многие люди используют обычные хостинги, а контролировать веб-сервер там не особо получится. Что же касается ограничение на мод_реврайт, чтож, апач много где стоит, не всегда есть резон только в универсальных решениях. Цитата Флуд защита конечно прикол, но имхо лишняя нагрузка... лучше небольшие куски в цикле со sleep 1;  к примеру, пока нас вебсервер не прибьет. По поводу флуда - согласен, нагрузочный метод очень. Но если куплен недавно хост и кол-во посетителей мало, то использовать для отваживания можно. Куски со слип(1), хмм... ...не очень эффективно, т.к.: 1. Для нормальной работы придется Push методом пользоваться. 2. Сканнеру главное - заголовок. Если глупые вещи, вроде той, от которой отталкиваюсь (LimpidByte Centurion2.0a), обрабатывают весь ответ, то нормально написанный сканнер скушает первый ответ в режии Push, ухватится за заголовки и прервет текущую итерацию. Вообще в тестах больше всех мешал "жить" сканнерам слип-метод. Хотя это и вполне логично. Частота - попыток вещь тонкая, можно случайно и подсеть с непрозрачным проксиком блокировать из-за одного человека. Думаю, что этот метод стоит отрабатывать опытным путем. Цитата Ну и сам скрипт можно порядочно прооптимизировать... Согласен, что не лучший вариант написания, но и не катастрофически плохой. Оптимизирую со временем. Единственное что не буду делать - переводить в объектный стиль.

Автор: Zuzu 7.3.2007, 11:32

Цитата(GoDleSS @  7.3.2007,  12:44 ) Вообще в тестах больше всех мешал "жить" сканнерам слип-метод. Хотя это и вполне логично. Напиши, пожалуйста, как (и чем) тестировал свой "Антисканер". Какова основная цель защиты? 1. Уменьшение входящего трафика 2. Защита от DOS-атаки (уменьшение нагрузки на Apache) 3. Уменьшение нагрузки на сервер (уменьшение нагрузки, связанной с работой CGI-скриптов и БД) Если основная цель 3 - ИМХО лучше динамически формировать .htaccess со списком "плохих хостов", добавляя/удаляя информацию именно в него. Добавлено @ 11:34  При определенной изворотливости туда же можно и список проверочных файлов запихать и при их запросе сразу вызывать скрипт-блокиратор (с выбором способа "отражения" атаки).

Автор: nitr 7.3.2007, 11:55

Цитата(GoDleSS @  7.3.2007,  09:44 ) Цитата Ну и сам скрипт можно порядочно прооптимизировать... Согласен, что не лучший вариант написания, но и не катастрофически плохой. Оптимизирую со временем.Единственное что не буду делать - переводить в объектный стиль. Да и на сколько заметил, всё же стоит, и как-то уж странно выглядит правило у мод_реврайта  (это неполностью регеспы, надо и такое помнить ;) ) Цитата(Zuzu @  7.3.2007,  11:32 ) 1. Уменьшение входящего трафика 2. Защита от DDOS-атаки (уменьшение нагрузки на Apache) 3. Уменьшение нагрузки на сервер (уменьшение нагрузки, связанной с работой CGI-скриптов и БД) 2пункт реализуем?  GoDleSS, если нетрудно приведи список сканеров, с помощью которых тестировал свой "антисканер".

Автор: GoDleSS 7.3.2007, 21:12

Цитата Да и на сколько заметил, всё же стоит, и как-то уж странно выглядит правило у мод_реврайта  (это неполностью регеспы, надо и такое помнить ;) ) Вот в том-то и проблема, что с mod_rewrite пока не очень дружу, тогда как регэкспами полноценными пользоваться умею.  Есть возможность напишите грамотные правила по следующим критериям: 1. Перенаправлять запросы вида site.ru/ и site.ru, но это ясно - ^\/?$ $script?%{QUERY_STRING} 2. Перенаправлять все остальные запросы, кроме оканчивающихся на указанные расширения(допустим .png, .jpg, .gif, .css) Цитата Какова основная цель защиты? 1. Уменьшение входящего трафика 2. Защита от DOS-атаки (уменьшение нагрузки на Apache) 3. Уменьшение нагрузки на сервер (уменьшение нагрузки, связанной с работой CGI-скриптов и БД) В лучшем случае все три варианта. Цитата Если основная цель 3 - ИМХО лучше динамически формировать .htaccess со списком "плохих хостов", добавляя/удаляя информацию именно в него. При определенной изворотливости туда же можно и список проверочных файлов запихать и при их запросе сразу вызывать скрипт-блокиратор (с выбором способа "отражения" атаки). Вот не хочу пихать все в .htaccess, ближе перлом работать. Цитата Напиши, пожалуйста, как (и чем) тестировал свой "Антисканер". Цитата GoDleSS, если нетрудно приведи список сканеров, с помощью которых тестировал свой "антисканер". Limpid Byte - Centurion 2.0a, Void - Eye build 461, xSpider(правда древний - 6.0, так что еще не Positive technologies). Большего всего "забить" на происходящее было xSpider-у. Тем не менее и он лагал. Как? Да просто скармливал адрес хоста, на который поставил сайтик на Nemesis и проводил аудит на CGI-баги(VEYE и Centurion больше ничего не умеют). Вы должны понимать, что это лишь первый набросок. Он показал хоть какую-то работоспособность, а значит имеет право на существование(имхо). Просто над ним надо работать и работать.

Автор: DiverD 9.3.2007, 11:43

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

Автор: nitr 9.3.2007, 16:40

Цитата(Zuzu @  7.3.2007,  11:32 ) Если основная цель 3 - ИМХО лучше динамически формировать .htaccess со списком "плохих хостов", добавляя/удаляя информацию именно в него. Станет больше причиной DDoS-атак ;)

Автор: Zuzu 9.3.2007, 16:46

Цитата(nitr @  7.3.2007,  14:55 ) 2пункт реализуем? В общем случае, только "увелиением размера снаряда" - покупкой специального оборудования и установкой его перед сервером.  Цитата(GoDleSS @  8.3.2007,  00:12 ) Вот не хочу пихать все в .htaccess, ближе перлом работать. Если работает .htaccess, то перл (php, asp etc  ) просто не вызывается. Следовательно, нагрузка, связанная с работой (запуском и работой) скриптов просто отсутсвует. ИМХО, такой подход даст большую "экономию нагрузки". Цитата(GoDleSS @  8.3.2007,  00:12 ) В лучшем случае все три варианта. Чудес не бывает. Первый вариант ИМХО, лучше реализовывать средствами управления Firewall-ом.

Автор: nitr 9.3.2007, 17:27

Zuzu, ) я как раз таки про "антисканер"  хардварными штучками имхо не тут ;) и всё же я указал -  Цитата(nitr @  9.3.2007,  16:40 ) Цитата(Zuzu @  7.3.2007,  11:32 )Если основная цель 3 - ИМХО лучше динамически формировать .htaccess со списком "плохих хостов", добавляя/удаляя информацию именно в него.Станет больше причиной DDoS-атак ;)

Автор: nerezus 9.3.2007, 18:51

Цитата В случае со слип-методами - для снижения нагрузки на процессор несущего сервера.  Бред. Левая трата оперативки. Цитата Что же касается ограничение на мод_реврайт, чтож, апач много где стоит, не всегда есть резон только в универсальных решениях.  мод_рерайт есть везде. А если его нет - то пора переезжать с бесплатного хостинга. А теперь объясняю, как лечить: делаешь кеширование(лучше многоуровневое). Ставишь IDS на сервер. Настраиваешь файрвол. Вроде все.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)