Comments 7
Вначале много вводной теоретической информации. А как доходит до, собственно, информации, связанной с названием статьи — всего одно предложение, без конкретики
Можете более подробно описать как может произойити DoS и DDoS-атаки? И как в итоге защищаться, если, как пишете:
Однако это не защищает от возможности DoS-атаки на определенный сервер. Дело в том, что шифрованные cookies не имеют привязки к клиенту, и, как следствие, cookies могут быть использованы для проведения атак на сервер с множества источников (например, из бот-сети).
Можете более подробно описать как может произойити DoS и DDoS-атаки? И как в итоге защищаться, если, как пишете:
Однако это не защищает от возможности DoS-атаки на определенный сервер
Да я бы сказал наоборот, сликом много воды. Можно было в приципе статью до пары предложений ужать. Название железки, формат куки, алгоритм шифрования и отсутствие привязки к клиенту описаны. Чего ещё вам не хватает? Готового скрипта для атаки?
Ну банально жи, ну. Мастер ботнета тыкает сервис, получает куку, раздаёт по сетке команду ддосить с этой кукой. Одной на всех.
В чем проблема атаки на конкретный узел? Если атакующий сосредоточит свои усилия на одном узле — он его, конечно положит. Только вот балансировщик, ежели это хороший балансировщик, перенаправит всех остальных пользователей на другие узлы — и получится красота: пользователи с атакующим вообще не пересекаются :)
PS повеселило еще и вот это:
PS повеселило еще и вот это:
Завершая сессии (по умолчанию они истекают при закрытии браузера) и заходя на сайт снова, мы сможем получить информацию о всех серверах пула.Очевидно же, что злоумышленник будет собирать информацию не браузером. В том же wget, если не предпринимать никаких мер, каждый запрос на сервер выглядит как новая сессия.
Выносим один сервер. Балансировщик его отключает. Выносим следующий.
Пока он выключает-включает будут простои, которые могут стоить бешеных репутационных потерь. И это еще если он их таки будет включать. А то мало ли…
Плюс за фронтом может быть единая точка отказа. Пусть и для некоторых конкретных задач. Пусть у нас бизнес-логика такова, что фронт забирает на себя всю нагрузку, и если атакующий пытается ложить весь пул серверов, то это не страшно, а если падает один сервер, к примеру с открытой транзакцией (не обязательно средствами СУБД, может быть какой-то свой бизнес-процесс который нельзя прервать, а надо «ручками» разруливать в случае падения сервера — будет очень больно.
Но даже просто понимание размера пула фронтов это уже подсказка атакующему — сколько стоит брать ботов в битву :)
Пока он выключает-включает будут простои, которые могут стоить бешеных репутационных потерь. И это еще если он их таки будет включать. А то мало ли…
Плюс за фронтом может быть единая точка отказа. Пусть и для некоторых конкретных задач. Пусть у нас бизнес-логика такова, что фронт забирает на себя всю нагрузку, и если атакующий пытается ложить весь пул серверов, то это не страшно, а если падает один сервер, к примеру с открытой транзакцией (не обязательно средствами СУБД, может быть какой-то свой бизнес-процесс который нельзя прервать, а надо «ручками» разруливать в случае падения сервера — будет очень больно.
Но даже просто понимание размера пула фронтов это уже подсказка атакующему — сколько стоит брать ботов в битву :)
Ну, если сервер именно что падает — тут не поможет ничего. А вот если он просто перестает отвечать на запросы (но те, которые набрал, заканчивает) — то атака будет выглядеть как периодические задержки или логауты. Оно, конечно, неприятно — но порой качество кода такое, что подобной «атаки» пользователь просто не заметит на фоне других проблем…
Впрочем, для общедоступных сервисов ситуация резко меняется и такой вектор надо закрывать.
Впрочем, для общедоступных сервисов ситуация резко меняется и такой вектор надо закрывать.
итого — кука не должна быть привязана к клиенту и (что в статье упустили) к серверу.
Т.е. для одной и той же железки куки двух разных пользователей — отличаются (hash with salt?) Это не позволяет зловреду вычислить пул серверов, а увеличение обращений по одной куке одного пользователя можно уже отследить.
Поскольку вся статья сжалась до размера одного абзаца — требую продолжения банкета, слюна то уже выделилась. Не, реально, дайте статьи с реальными кейсами, реальными ляпами, все что бы взаправду было, а не эти рафинированные how to, коих вагон в этих ваших…
Т.е. для одной и той же железки куки двух разных пользователей — отличаются (hash with salt?) Это не позволяет зловреду вычислить пул серверов, а увеличение обращений по одной куке одного пользователя можно уже отследить.
Поскольку вся статья сжалась до размера одного абзаца — требую продолжения банкета, слюна то уже выделилась. Не, реально, дайте статьи с реальными кейсами, реальными ляпами, все что бы взаправду было, а не эти рафинированные how to, коих вагон в этих ваших…
Sign up to leave a comment.
DDoS-атака в обход балансировщика: защищайте свои cookie!