IPTABLES阻止用户代理

首先： 你不想这样做 ，如下所述。

第二：在这里http://spamcleaner.org/en/misc/w00tw00t.html回答了一个非常类似的问题。 我正在把他们的解决scheme转交给你的具体问题。 有一个iptables string模块可以用来匹配浏览器代理。 然而，iptables将检查每个数据包…我们可以用connmark模块来优化这个。 我没有尝试过，所以我的回答只是朝正确的方向发展：

 <other rules> iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD1 -j DROP iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD0 -j ACCEPT iptables -t mangle -A PREROUTING -p tcp --dport 80 -m string --string "User-Agent: " -j CHECK_UAGENT iptables -t mangle -A CHECK_UAGENT -m string --string "User-Agent: WordPress/4.0" -j CATCH iptables -t mangle -A CHECK_UAGENT -j CONNMARK --set-xmark 0xBAD0 <otherrules> iptables -t mangle -N CATCH iptables -t mangle -A CATCH -j LOG --log-level alert --log-prefix "WordPress attack " iptables -t mangle -A CATCH -j CONNMARK --set-xmark 0xBAD1 iptables -t mangle -A CATCH -j DROP 

这是这个想法。 connmark模块和相关的目标将按照你的意愿标记一个数据包，并且该连接数据stream中的任何后续数据包将被类似地标记。 所以我们寻找朝向端口80的数据包，并且有一个“User Agent”string。 如果他们有不良用户代理，我们将其标记为0xBAD1 – blaclisting它。 然后我们logging下来。 否则，一旦我们看到“用户代理”，而不是不希望的，它就会被用0xBAD0列入白名单。 通过白名单，我们减less了包检查器的负载（这是一个优化步骤）。 否则，我们会在每个上传的图片的每个数据包中search – 毫无意义的浪费。

**为什么上述是一个坏主意**一：HTTPS不能在包过滤级别解码。 二：因为有了上述的DDOS攻击是可能的。 连接开始，在您的networking服务器上打开连接，然后消失 （从您的networking服务器的angular度来看）。 等待很长时间才放弃不再允许通过的客户端。 同时，更多的尝试将通过。 最终，HTTP将耗尽资源并且没有请求通过。 （解决这个问题的一种方法是使用recent模块，更彻底的方法是让一个进程监视日志文件中的“WordPress攻击”，让它logging远程IP和端口，并强制连接closures切割器 ，或交叉引用与它关联的服务器PID的连接，然后杀死该进程。）

一个类似的问题提出并回答：使用反向代理。 这是最好的select，但需要大量的重新configuration，也许是一个干预服务器。

用这种方法来代替使用mod_rewrite（在Apache / * ngnx中）来匹配User-Agentstring，为logging目的设置一个环境variables，并返回403错误状态。 这closures了偏远的一面。 现在，为了使它更加永久，有一个单独的进程监视这种丢弃连接的日志文件，并将remote-ip添加到recent表中，iptables将在接下来的5分钟内删除新的连接。 所以…

 # Apache config RewriteCond %{HTTP_USER_AGENT} ^WordPress/4\.0 RewriteRule - [L,R=403,E=WordPress] LogFormat "%t\t%a\t%{remote}p\t%{User-Agent}i" CustomLog wordpress wordpress.log env=WordPress 

自定义日志格式使我们的外部过程更容易解​​码。 IPtables只是一个规则：

 iptables -A INPUT --syn -m recent --name WordPress --rcheck --seconds 300 -j DROP 

和外部进程（以root身份运行）如下所示：

 #!perl open(STDIN,"tail -f /var/log/http/wordpress.log|") while (<>) { my ($time,$ip,$port,$useragent)=split('\t'); open(RECENT,"> /proc/net/xt_recent/WordPress") print RECENT "+$ip\n" close RECENT } 

时间戳和用户代理string就是这样，你可以validation事情正在工作/不工作，如你所料。 我会用mod改写的方式来补充，你有更多的灵活性来拒绝/禁止。

运行以下命令将阻止这个特定的攻击：

 iptables -N WordPress-PingVerify iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j WordPress-PingVerify iptables -A WordPress-PingVerify -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN iptables -A WordPress-PingVerify -p tcp --dport 80 -m string --to 300 --algo bm --string 'verifying pingback from' -j DROP iptables -A WordPress-PingVerify -j RETURN 

上面的规则假定攻击注定是HTTP（端口80），如果你通过HTTPS命中改变端口443（或者你可以使用多端口来指定端口80和443）。

作为替代scheme，您可以使用这些规则来阻止所有的WordPress pingbacks请求 – 这不仅会阻止pingbackvalidation，还会导致pingbacks：

 iptables -N WordPress-PingBacks iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j WordPress-PingBacks iptables -A WordPress-PingBacks -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN iptables -A WordPress-PingBacks -p tcp --dport 80 -j DROP iptables -A WordPress-PingBacks -j RETURN 

来源： https ： //sysadminblog.net/2016/05/blocking-wordpress-pingback-verification-ddos/