Цитата Сообщение от Рипеец Посмотреть сообщение
Мой опыт говорит мне о том, что редкий Tier 3 озабочен безопасностью своих клиентов. Причина проста: снизить себестоимость своих услуг.
Я не имел большого опыта работы с ЦОД. Возможно вы в этом опытнее меня. Поэтому не буду спорить.
Но знаю, что некоторые организации пользуются услугами ЦОД за пределами РФ. Я предполагаю, что в такой ситуации большого выбора есть возможность найти более качественный и надёжный ЦОД.

Цитата Сообщение от Рипеец Посмотреть сообщение
Т.е. фактически мы приходим к тому, что если периметр не расковыривает https, то он может анализировать злыдней уровнем ниже (IP, TCP) и только. Что возвращает нас к тому, что периметр защищает от только от части атак.
Я полагаю, что капча(HTTP) -> access list -> ЛК(HTTPS) сделана для того, чтобы веб сервер не заморачивался на всякий там анализ трафика, а занимался своей работой. А капча - это анализатор свой/чужой. Если чужой долбится в капчу, то этот трафик анализирует периметр и принимает решение, блокировать вход на саму капчу, или нет. Если же это человек, или очень умный бот, которого не распознал периметр и который прошел через капчу, то access list открывается и дальше уже дело за сервером. И за технической поддержкой Броко.
Я уже писал, что IDS, фильтрующая протоколы всех уровней безусловно эффективнее и обеспечивает лучшую защиту. В этом я с вами согласен. Однако в данном конкретном случае мне думается, что капча очень мало поможет, не зависимо от того используется ли http или https.
Возможно редирект через капчу призван снять вредоносную нагрузку с основного сервера на вспомогательный. То есть те, кто долбится, долбятся сначала в сервер "фильтр", а потом, после прохода капчи, редиректятся на другой сервер - основной.
Да, схема "капча(HTTP) -> access list -> ЛК(HTTPS)" имеет место быть. Но мне кажется, что ACL или black/white list получают информацию запросом от веб-сервера, а не в результате анализа http трафика. То есть веб-сервер, определив успешный проход капчи направляет запрос на добавление в white list. Согласен, что слишком нагружать веб-сервер проверками не стОит, но по моему, в данном случае всё равно нагружен веб-сервер.
Я не знаю в деталях как у них реализован этот механизм защиты, но мне видится именно что то в этом роде.

Цитата Сообщение от Рипеец Посмотреть сообщение
Я имел ввиду следующее:
  • 5 - 10 тыс ботов.
  • GET / или что-нибудь в этом роде 10-100 раз в сек.
  • Форкнутые процессы, направленные на обработку этих запросов.
В такой ситуации, конечно, атака наиболее опасна именно своей распределённостью (количеством атакующих хостов). Но это не значит, что ничего нельзя сделать.
Например можно:
  • Ограничить общее количество запросов на соединение с сервером в секунду.
    Этим мы снизим общую нагрузку.
  • Ограничить количество соединений с одного IP.
    Этим мы не позволим каждому боту генерить слишком много запросов.
  • Каждый IP, который создаёт много соединений в секунду (ну например больше 5 соединений в сек.) блокировать.
    Так мы отсечём бОльшую часть ботов. Мало кто из людей, при просмотре веб-сайта, производит больше соединений за секунду.

Это самое простое, что приходит в голову. Это всё можно сделать на периметре, на уровне протоколов TCP/IP.
Кроме того я бы заблокировал, для этого сервера, UDP и даже ICMP (как экстренные меры), что бы избежать атак на уровне этих протоколов. А так же заблокировал все протоколы верхнего уровня, кроме http и https (предполагаю, что это должно было быть сделано с самого начала).

Цитата Сообщение от Рипеец Посмотреть сообщение
Истина! Поэтому защиту лучше реализовывать не на самом веб сервере, а немножко перед ним...
Считаю, что лучше не пренебрегать защитой на самом веб-сервере, в том числе на уровне движка сайта. Хотя, конечно, периметр перед ним должен брать на себя основную роль в защите. Ещё лучше, если удастся состыковать разные уровни защиты, что бы они могли взаимодействовать.

Цитата Сообщение от Рипеец Посмотреть сообщение
Мне кажется, что Броко в какой-то момент потребовалась более комплексная защита, что они, на мой взгляд, и реализовали. По истечению полутора суток я уже мог попадать на этот форум. Многие ресурсы по давлением доссеров не могут решить свои проблемы неделями. Иногда вообще не могут решить свои проблемы.
Надеюсь, что они реализуют эту защиту хорошо. И что не будут слишком затруднять клиентам вход в ЛК.

Если я не ошибаюсь, Броко воспользовалось услугами одной организации, специализирующейся на защите от DDoS атак и создании высоконагруженных проектов (http://highloadlab.com).

Цитата Сообщение от Рипеец Посмотреть сообщение
Согласен, но не со всем.
Цель имеет ценность почти всегда. Ценность не обязательно оценивается в сиюминутной денежной выгоде.
Я не имел ввиду под ценностью именно денежную выгоду, тем более сиюминутную. Я говорил о том, что каждая цель имеет свою ценность. Бывает, что эта ценность выражена в конкретном денежном выражении (заказ), а бывает, что ценность выражена не в денежной выгоде. Однако даже если ценность цели не в деньгах (нет заказа), всё равно уровень этой ценности определяют тем или иным образом (одна цель ценнее, другая менее ценна). Каждый потенциальный взломщик оценивает по каким то своим критериям.
Да, каждая цель имеет ценность, но одна цель бОльшую, другая меньшую.

Что касается "спортивного интереса": на этот счёт есть исследования разных организаций в области безопасности, которые показывают, что объём взломов ради спортивного интереса (и подобных целей) сократился в последнее время до ничтожных значений от общего объёма взломов. В подавляющем большинстве случаев это именно заказ за деньги с чётким намерением нанести вред жертве. Поэтому всё чаще встречается такие термины, как "кибер терроризм" и подобные.

Как говорил один эксперт по безопасности: "Раньше взломщики были в основном школьники (или студенты), которые производили взлом не имея конкретной цели, а именно из спортивного интереса и что бы похвастаться перед друзьями. Теперь в большинстве это серьёзные взрослые люди, которые производят целенаправленные взломы, имея конкретную вредоносную задачу и как правило по чьему-то оплаченному заказу.".