Схема работы серверов такова. dns распределяет клиентов на load balancer, load balancer распределяет нагрузку уже на бэкенды.
/ > nginx backend
/ nginx balancer - > nginx backend
Client > DNS Round Robin >
\ nginx balancer - > nginx backend
\ > nginx backend
Неважно какой клиент, DDoS или рядовой пользователь, обращается на веб-сервер, запрашивая абсолютно любой документ.
Идея в том, чтобы NGINX Load Balancer защищал бэкеды от ддос-атаки средством которое я только что придумал «Cookie Terminate», по аналогии с уже известным «SSL Terminate».
Клиент заходит на сайт первый раз, NGINX Load Balancer устанавливает клиенту Cookie, в которой содержится аналог CSRF-токена, — пароль, известный только серверу. Без этой Cookie сервер не пропускает запросы дальше на бэкенды, никогда.
Впервый раз у клиента ещё нет Cookie, она ему только что была установлена, поэтому показываем ему статическую заглушку, HTML-страничку с использованием JavaScript, на котором JavaScript всего-навсего перезагружает страницу, таким образом делая повторное обращение к серверу, но уже с использованием этой Cookie из браузера, и если Cookie установлена (а она уже была установлена), нам покажут уже отдачу реального бэкенда, который NGINX Load Balancer пропустил т.к. кука имеется.
Вооот.. При всех повторных обращениях никакой заглушки показано не будет, NGINX Load Balancer по наличию этой куки с аналогом CSRF-токена всегда пропускает клиента.
То есть, что имеем. NGINX Load Balaner устанавливает Cookie если её нет, и отдает заглушку с JavaScript, JavaScript заглушка перезагружает страницу спустя несколько секунд, повторяя тем самым запрос на сервер, а сервер уже отдает реальный контент по ссылке, т.к. Cookie при повторном имеется.
Сама Cookie что из себя представляет. это hash-токен, который генерируется на этом же NGINX Load Balancer'е, который невозможно сгенерировать на стороне клиента чтобы тебя всегда пропускали. hash-токен таким образом должен содержать информацию и соль известную только серверу.
К примеру, установим туда IP-адрес клиента и соль... md5($remote_addr.$salt) грубо говоря.
И при последующих запросах клиента серверу — сервер смотрит на куку, восстанавливает хэш и сверяет их, реально ли кука соответствует данным или нет. Если нет — посылаем клиента нафиг, выдаём всё ту же заглушку.
ЛОР, взлетит ли такой метод защиты от DDoS? Какие подводные камни?
Как быть, если DDoS'ящий клиент сперва зашёл на сайт, получил эту куку, а затем начинает DDoS атаку уже с использованием этой куки, по которой Load Balancer всегда клиента пропускает, с того же IP-адреса, который содержится в hash-токене. Думаю над этим =)
Как быть с поисковыми движками... А шо, можно просто включать эту защиту только на время DDoS атак. Вот. А всё остальное время пусть выключено будет.
Какие ещё будут предложения?
