因为后端同学的失误,有个获取短信验证码接口没有做二次验证。导致被人攻击。损失几万条短信。
附nginx access日志。tomcat 服务。
请问各位,如何判断攻击者是用肉鸡攻击,还是单机用代理IP进行攻击?如何查看攻击者真实IP。
因为后端同学的失误,有个获取短信验证码接口没有做二次验证。导致被人攻击。损失几万条短信。
附nginx access日志。tomcat 服务。
请问各位,如何判断攻击者是用肉鸡攻击,还是单机用代理IP进行攻击?如何查看攻击者真实IP。
15 回答8.4k 阅读
8 回答6.2k 阅读
1 回答4k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
2 回答3.1k 阅读
2 回答2.4k 阅读✓ 已解决
2 回答3.8k 阅读
没有列出来nginx的日志格式,猜测日志里的ip字段取得是$remote_addr?这样拿的是跟你这台nginx直接连接的远端的地址,从日志看有重复的ip,如果你们对于ip的限制不合理的话,可能是本地架了个代理,不断伪造客户端ip来连接的。
具体你的架构没有给出来,无法分析,你们的nginx前面是否有其他nginx做代理?例如阿里云?如果有,分析ip来源要结合$remote_addr和$http_x_forwarded_for,尤其是第二个字段。打个比方,如果你们的nginx位于阿里负载均衡之后,在你们的nginx日志中$http_x_forwarded_for字段取值为“”A,B,C”,那么只能确定跟阿里直接建立连接的客户端ip是C,同时你的日志里$remote_addr也是C,这个值是伪造不了的;同时真正客户端的地址理论上是A,为什么说理论上,因为这个值是可以被篡改的,自己本地架个代理就可以篡改。比如C是攻击者架的代理,那么理论上可以不断的修改A和B的值来规避一些ip限制。因此在实际应用中,对于IP的限制一定要明确自己的需求场景,知道怎么取IP来进行限制。
回到你的问题,从你给的日志看不出来攻击者的真实IP,只是猜测,因为你们的ip限制不是很合理,攻击者连代理池都没用,直接本地架了代理来刷。
有问题欢迎进一步讨论。