Pull to refresh

Comments 21

Даже в адресную строку посмотрел — хабр ли это?
А чем мог бы в данной ситуации помочь WAF? Ему же приходилось бы точно так же «на лету» расшифровывать HTTPS-трафик, что потребовало бы таких же диких вычислительных мощностей…
Или использовалась бы какая-то другая технология, не требующая расшифровки трафика?
Хотелось бы этот момент уточнить поподробнее.
Да, если говорить о расшифровке HTTPS, то ничем бы не помог. Этот вопрос был решен в лоб переносом шифрования на более производительные серверы. WAF тут мог бы помочь, по нашему опыту, в трех вопросах:
1) Мониторинг трафика. Средствами WAF намного проще разобраться, что происходит в данный момент и как можно блокировать очередную волну.
2) К WAF можно прикрутить скрипты, которые позволяют по-разному обрабатывать различные запросы. Например, делать задержки.
3) С точки зрения возможного развития атаки. Злоумышленник увидел, что наиболее пробивной является маскировка под реальных пользователей. Когда сайт перестал валиться из-за SSL, логично было бы переключиться на «тяжелые» запросы. Тем более в рамках разведки за день до атаки хакер их явно нащупал. Тут WAF бы очень пригодился для отделения реальных пользователей от ботов и мониторинга запросов.

Конечно, все это можно сделать и без WAF, но не так удобно и быстро. Самое обидное, что WAF был, стоял чуть ли не в соседней стойке, но воспользоваться им возможности не было.
Спасибо, интересно было узнать мнение эксперта. Ещё два вопроса, если позволите.
1. Я правильно понимаю, что в пунктах 2 и 3 всё равно потребовалась бы расшифровка трафика «на лету» (иначе у нас не будет возможности увидеть сами запросы, отделив их от коннектов) и, как следствие, пришлось бы сам WAF переносить на более мощный сервер (так как для расшифровки HTTPS «на лету» требуются значительные вычислительные мощности)? Или железо, отданное под WAF, уже заведомо мощнее железа, отведённого под веб-серверы?
2. Как технически организуется прозрачная для пользователей расшифровка трафика «на лету»? В WAF импортируется сертификат с закрытым ключом веб-сервера?
Ответили с Сергеем по пунктам:

1. Разумеется, железо, отдаваемое под WAF, планируется с учетом необходимости обработки SSL. Сама по себе нагрузка от выполнения криптографических операций никуда не исчезает, но ее перенос именно на WAF необходим для обеспечения работы с данными на L7. При этом нагрузка на серверы приложений может быть существенно снижена не только за счет переноса точки обработки SSL, но и за счет возможности фильтрации паразитного трафика или выполнения дополнительной оптимизации на стороне WAF.
Железо WAF рассчитывается на такие нагрузки, поддерживает кластеризацию, балансировку, может иметь аппаратную ssl-акселерацию и т.п.

2. Да, в общем случае на WAF импортируются ключ и сертификат, или же ключевая пара генерируется прямо на WAF, после чего сертификат подписывается и импортируется. Таким образом круг пользователей, которым доступен ключ, сокращается до администраторов ИБ. Далее функция ssl offloading'а выполняется на WAF, чаще всего в режиме reverse proxy с балансировкой, но возможны и более экзотические варианты. Для передачи от WAF до серверов приложений может использоваться как http, так и ssl в случае архитектурных ограничений и отсутствия по каким-либо причинам доверия к среде передачи данных.
Большое спасибо за ответ, было интересно узнать про эти вещи.)
WAF — это не самая алгоритмически легкая задача, и при хорошо поставленной атаке — умрет первой. Именно поэтому работает только в связке с ddos mitigation.

Абсолютно согласен. С точки зрения DDoS, WAF — это уже последние рубежи обороны.
Да, если говорить о расшифровке HTTPS, то ничем бы не помог. Этот вопрос был решен в лоб переносом шифрования на более производительные серверы.
Ну это вам очень сильно повезло, что в атаке не участвовали ни Mirai, ни Wordpress. Иначе вам бы не то что серверов, а даже и аплинка могло бы не хватить.
Злоумышленники явно распыляли силы на большое число банков. Это видно и по небольшому объему атаки, и по тому, как они с задержкой реагировали на блокировку очередной волны.
Будь это полноценный Mirai, такую драматичную историю можно было бы писать уже не от лица банка, а от лица Ростелекома:)
Но не все же Брайны Кребсы. Обычные атаки, которым российские компании подвергаются каждый день, гораздо менее эпичны.
После слов:
Оценив серьезность атаки, банк начал экстренно подключаться к одному из российских облачных сервисов по защите от DDoS.


Сомневаюсь вот в этом утверждении:
Он даже был установлен, но его не успели ввести в эксплуатацию и сайт банка не был к нему подключен.


Такие сервисы должны быть изначально под защитой от DDoS. Как минимум потому, что хорошие сервисы используют анализ трафика за несколько недель, чтобы отделить легитимный трафик.
А вообще обидно когда терапевту к порогу доставляют покойника. Приходится подрабатывать реаниматологом. Очень нервная работа.
Рассказываем, как есть. Реальность, увы, всегда отличается от идеальных «правильных» случаев.
Облачные сервисы оказываются по подписке и их можно подключить быстро. А ставить ненастроенный WAF в режиме блокирования в разрез — лучший способ полностью положить сайт. Но тут были и орг проблемы с его установкой.
Я больше негодую про то, что подключать сервис защиты от DDoS во время атаки — очень дурной тон. Выше flx хорошо пояснил ситуацию. Сомневаюсь, что для банка так уж накладно постоянно оплачивать такие услуги.
Я думаю, большая часть клиентов облачного Anti-DDoS подключается после первого пожара. Хорошего в этом, конечно, мало.
А что с такими атками делают на правовом уровне? Вы\компания подают потом заявление в отдел по киберпреступлениям(или как он там)?
По факту компании заявления подают только после хищения денег вследствие взлома, да и то не всегда. Если кто-то и пытался по факту DDoS возбудить уголовное дело, я не знаю ни одного случая в России, когда бы это принесло какие-то плоды.
Наше законодательство сейчас абсолютно устарело в части компьютерных преступлений. Есть 272, 273 и 274 статьи УК РФ, которым сто лет в обед. Если кого-то и ловят из серьезных хакеров (например, выводящих деньги со счетов банков), то они идут по несколько притянутым за уши «смежным» статьям.
В этот момент специалисты нашей компании проводили внешний пентест инфраструктуры банка

Довольно странное совпадение, похоже информация о тестировании утекла от пентестера или банка, а злоумышленники пользовались расслабленной CSIRT банка.
Не думаю. По опыту, спецы заказчиков во время пентеста наоборот бдят вдвойне.
Гораздо более распространенный кейс, когда сам DDoS маскирует направленную атаку на компанию.
В данном случае интриги и вовсе нет. Атака была массовая, сразу на десяток банков. Ее автор сообщил, что это заказ политически мотивирован и связан с местью за вмешательство России в выборы в США. Сам злоумышленник активно пиарился, надеясь найти новых заказчиков.
1) Можно поставить простенький центр детектирования, чтобы потом понимать тип атаки, источник и цель атаки.
2) Ручками настроить ACL на маршрутизаторе.

Скорее всего атака была куплена, возможно этот банк обидел не того человека. Атаки сейчас не так дорого стоят, а от низко скоростных атак уровня приложений — защиты не так много, но и заказать такую атаку в разы дороже. К примеру на тестах эмулировали 20Гб/c простых атак, когда понадобилось эмулировать сложные, тот же сервер с трудом давал 2Мб/c.

В целом тема DDos актуальна в последнее время, а в 2016 к примеру зафиксированы атаки до 400Гб/c на отдельные ресурсы.
Sign up to leave a comment.