Тестирование веб-серверов на устойчивость к атакам

Еще пару желающим весь процесс бесплатно. Кто следующий?

PS. Хотелось бы что-то интересное, какой-то самописный движок на коло.

slaed сможете положить?

vps debian

или DLE на крайний случай

ssh закрыт фаером а proftpd открыт тоже интересна возможность атаки

Удалено. 10 греев.

Это как-то спасет, но никак не разрешит вашу проблему.

(coreшпецам просьба не бить, т.к. стараюсь писать максимально понятно)

502 в nginx появляется в случаях когда количество исполняемых скриптов через fastcgi превышает какой-то лимит, т.е. там даже несколько ситуаций есть, но всё упирается в лимиты и тормоза со стороны скриптов, в большинстве случаев... во всех ситуациях получается 502.

Увеличивать мощность сервера можно, но если вы увеличите эту мощность в двое, то на текущей конфигурации, такое явление будет появляется и дальше... как бы это корректней сказать, не на 250*2 пользователей, а гораздо на меньшем количестве.

Надо посмотреть на этот сервер из консоли. Посмотреть на кофиги, посмотреть на "тяжесть" php скриптов. Посмотреть как раз те моменты, когда скапливается очередь из "медленных скриптов"... т.е. надо выяснить, почему они тормозят так, что лимита не хватает... возможно лимит просто надо увеличить.

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

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

Причина может быть в интенсивном IO, т.к. SATA не самое лучшее серверное решение.

Целую книгу можно написать на эту тему.

Надо конкретно на это посмотреть, т.к. разговариваем о коте в мешке.

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

Очень много движков не обрабатывают такие запросы как HEAD. Т.е. вот на PHPшный скрипт идёт HEAD, который нужен для того, что бы узнать про измения, а вместо того, что бы сказать, что никакого нового контента на странице не было, он отрабатывается... это лишнее.

Смотреть надо.. по всему остальному в личку.

PS. прастите за мой русский... 😂

Не совсем понял что такое slaed. А по всем VPS есть однозначный ответ. В конфигурации вашего сервера прописан лимит соединений, когда количество соединений его превысят, то какая-то часть этих соединений уйдёт в очередь. В любом случае, длительна атака которая состоит из пары тыс запросов в секунду на http стоит очень д,ешево... другое дело, что может быть у вас там есть какое-то php и мощность атаки можно снизить в десятки раз, а это еще дешевле и длительнее. 20-30 параллельных конектов на тормозные php можно и с gprs организовать... да даже на тестовом хостинге где-то в shell скрипт повесить и забыть... они даже там какой-то активности левой не заметят. Флуды обычно по трафику замечают, а когда по картинкам mrtg всё тихо, то и основания для беспокойства отсутствуют...

Когда HSP прикрывает свой хостинг какими-то акселераторами, т.е. кэширующими серверами, то весь контент, который динамический, можно снабдить хидерной инфой для кэшей... кэши они не какая-то vps, для простейшего oops+freebsd какие-то там 5-6 тыс активных конектов это мелочи жизни. Главное это то, что это недоходит до VPS. Можно там конечно в хидерах слать no-cache, но некоторые провайдеры достаточно лояльно к клиентам относятся... т.е. там по заявке такое дело просто порезать могут. У Зенона, кстати, есть Cisco CSS.. ради некоторых клиентов они оч активно на ней всякую пургу срезают. В большинстве случаев это как-то за спасибо там делается...

У других провайдеров, которые с акселераторами, тоже есть какие-то примочки... но иногда они просто посылают... хотя, что бы убить акселераторы mh надо постараться... тоже самое и по остальным, само собой по тем, у кого они есть. Да и у Зенона тоже... если доходит дело до всяких срезаний, то значит тебя там действительно с бот-сети из пару тыс компьютеров флудят.

Можно пытаться воспользоваться какими-то универсальными IDS, а можно написать под конкретный проект, или под какую-то его часть, так называемые правила для фильтрации. Т.е. там если к вам льют POST запросы, которых от нормальных клиентов просто быть не должно, то эти IP адреса должны попадать в список подозрительных и т.д. и т.п... вплоть от отслеживания аномалий в URL... когда готовятся к атаке, то какие-то переменные руками же щупают... сканеры есть, но это всё лирика. Тут есть конкретная цель и подозрения на уязвимости... notepad + telnet и вся картина более или менее ясна.

PS. Если ваша VPS по ab мега-супер производительная, то ей просто тормозных запросов надо чуток подкинуть и всё на свои места встанет.

Когда исчезнут проблемы с правописанием, то возможно на kostich.ru появится какой-то аля sysoev.ru, но пока... Потом попрошу кого-то из клиентов разместить это на своих зеркалах и можете тренироваться в гигабитаных флудах... там их и так достаточно, но это всё какие-то истерии и прощупывания. DNS размещу там, где в случае атаки пострадают очень авторитетные конторы... да и вообще, с больной головы переложу на здоровую и буду наслаждаться процессом дальше.

Shared ценен тем, что трафик атак канального уровня нельзя выставить клиенту в инвойс, а это уже, по сути, облегчает значительное экономическое бремя от всяких там виртуальных наездов. Если все будут знать, что я стою на colo c ценой 1$ за гиг общего, то через сотошный канал мне сделают такой подарок, что на утро я буду искать другого провайдера и думать как бы от этого отвертетьтся. Если цель атаки погасить ресурс, то как раз с помощью этого казуса она и будет достигнута.

ЗЫ. Если у HSP платный трафик, то это не значит, что это плохо. Если всякое там лишнее icmp, udp заранее отфильтровано где-то далеко, то фильтровать всяких товарисчей, который грузят трафиков не так уж и сложно... полная автоматика фактически.

Не шаред тоже не гуд

У меня на VPS щас нет ограничения на траф и разделения на российкий и зарубежный траф или же разделения на исходящий или входящий в каких то идиотических пропорциях.

Так что траф не жалко.

Однако есть VDS с 15 гигами трафа, так там кончить траф не составляет труда и не придется ложить сервер его провайдер сам отключит за неуплату.

Посмотрел. На вскидку есть ряд типичных вещей, которые очень облегчают жизнь атакующим. И без скриптов хватает... если придираться, то получается что:

1. Форма отправки e-mail. Она же без всякой защиты получается. Не совсем ясен механизм работы, но при должной интенсивность можно что-то убить... мыльник hsp там, к примеру... озадачить. В итоге будет скопление отправлеющих скриптов, которые повлияют или на ваш хостинговый аккаунт или же на весь сервер целиком. За такое обычно до утра выключают.

2. В разделе downloads есть замечательнейшие меговые файлики. Количество одновременно скачивающих желательно ограничить. Это лишний соблаз нагрузить slow коннектами.

3. Если на сайте практически всё статическое, то зачем использовать для этого php?

Мне, возможно требуються ваши услуги, в первую очередь консультационные. Не только по вопросу безопасности сайтов, но и собственно об их устойчивости и прочем. Давать заваливать свои сайты боюсь, думаю потом поднимать будет с таким скрипом, что лучше не связываться. Как с вами свзаться, скиньте в личку контакты. Желательно телефон.

Можно ФИО в студию? Слабо?

В принципе то что вы пишите что помогаете сделать выглядит довольно сдраво (я профессионал в этой области и ни раз оказывал услуги в области защиты сайтов от ddos атак), но некоторые вещи вызывают сильные сомнения:

1. Как минимум ты являешься владельцем бот сети, а это уже уголовное преступление.

2. Для тестирования веб сервера на нагрузку достаточно 1 IP адреса, зачем бот нет сеть использовать? Глупо и неразумно.

3. "касаемо PtSecurity, могу говорить (как говорит г-н Борщевский) только в двух тональностях... одна из них матом. " - сильно говорит о вашем профессиональной этике.

Если у человека есть деньги и желание защитить ресурс, он первым делом обратится к профессиональным компаниям а не к анонимным топикастерам на форуме.

Чего всем и рекомендую и крайне не советую пользоваться его услугами.