Добрый день. Собственно говоря вот статья: https://dislic.net/2015/11/06/advanced-limiting-request-with-nginx-or-openresty/ в которой предполагается ограничивать кол-во запросов по cookie, так как масса пользователей сидят за NAT!
На практике в $cookie_userid на стороне клиента злоумышленник может поместить все что угодно, и как следствие каждый новый запрос злоумышленник может снабжать новым уникальным $cookie_userid, и не важно что такого user_id на стороне бэкэнда не существует, главное для злоумышленника это то, что на стороне nginx новый $cookie_userid будет восприниматься как новый key (новый пользователь) с не превышенным кол-вом запросов. Таким образом можно слать сотни тысяч запросов и каждый с новым $cookie_userid. Вопрос: Что если в location использовать связку ngx+lua+jwr_access_token? То есть, когда запросы будут попадают в защищаемый от ddos location, первое что будем делать помощи lua, это: вычислять HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload),secret) и если вычисленная и полученная сигнатуры access токена совпадут, то токен настоящий, его смело можно использовать для ограничения, и key для limit_req_zone будет иметь что то вроде: limit_req_zone $binary_remote_addr$cookie_hash zone=one:10m rate=90r/m; где set_md5 $cookie_hash $cookie_jwt; так мы установим ограничение для каждого аутентифицированного пользователя в разрезе IP адресов. Таким образом даже 10000 сидящим за NAT пользователям не грозит отказ в обслуживании! Если сигнатуры не совпали, значит JWT токен поддельный, и тогда: limit_req_zone $binary_remote_addr$cookie_hash zone=three:10m rate=90r/m; где $cookie_hash="" (не уверен что это правильно, но имею ввиду что ключ $binary_remote_addr$cookie_hash будет содержать только IP адрес учитывая что в $cookie_hash мы присвоим пустую строку) таким образом запросы не аутентифицированных пользователей (потенциально это могут быть и 1000 ботов сидящих за одним IP) будут ограничиваться одним IP адресом. В случае если, злоумышленник пройдет аутентификация и получит jwt access токен и будет подставлять его в атаках для 1000 ботов то все равно будут действовать ограничения на один токен+ip. 1. На сколько подобное решение РЕАЛЬНО? Только изучаю эти вопросы. 2. Создаст ли оно не оправдано высокую вычислительную нагрузку на nginx, что сделает такую схему перегружающей nginx? 3. Может есть какие то дополнения от опытных пользователей? Всем большое спасибо, буду очень признателен за ваше мнение! С уважением и наилучшими пожеланиями Руслан. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286037,286037#msg-286037 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
