tl; dr – 在/ etc / passwd中给Apache一个shell有什么危险？
我正在努力获得mod_evasive设置与Apache的斗争DOS尝试。 我使用DOSSystemCommand来运行脚本，将有问题的IP地址添加到iptables中的BANNED链。
我发现我可以使这个过程工作的唯一方法是将Apache的shell从/sbin/nologin更改为/bin/bash 。 但实际上只有脚本的一部分由于没有更改shell而失败。 这是DOSSystemCommand行和它运行的脚本：
DOSSystemCommand "/usr/bin/sudo /bin/bash /var/www/html/ban_ip.sh %s"
和脚本…（注意我只是在testing..这就是为什么我有详细的输出和短期禁止时间）
#!/bin/bash IP=$1 IPTABLES=/sbin/iptables sudo $IPTABLES -I BANNED -p tcp -s $IP --dport 443 -j DROP sudo $IPTABLES -I BANNED -p tcp -s $IP --dport 80 -j DROP echo sudo $IPTABLES -v -D BANNED -p tcp -s $IP --dport 80 -j DROP | at -m now + 1 minutes echo sudo $IPTABLES -v -D BANNED -p tcp -s $IP --dport 443 -j DROP | at -m now + 2 minutes echo rm -fv /tmp/dos-$IP | at -m now + 2 minutes
所以，Apache有一个/sbin/nologin的shell，它会添加IPTABLES规则，它会创buildat作业，但是当我得到一个包含at作业结果的电子邮件时，它表明User is currently unavailable ，所以iptables规则永远不会被删除。 如果我将Apache / bin / bash作为它的shell，添加了iptables规则，创build了at作业，iptables删除在指定的时间按预期工作。
所以我的问题是：我通过给Apache用户一个shell来让我的服务器处于危险的状态？
相关代码位于mod_evasive.c的第224行：
if (sys_command != NULL) { snprintf(filename, sizeof(filename), sys_command, text_add); system(filename); }
现在，我们来看一下man 3 system ：
DESCRIPTION system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed. During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.
那么我们可以看到，指定的命令正在shell中运行。 无可否认， system(3)文档在这一点上是混淆的，但是我们当然可以看到发生了什么，并做出适当的推断 – 它正在用户的默认shell中运行，而不仅仅是/bin/sh 。
正确的解决scheme是相对简单的：只需用fork(2)和execve(2) （或者大致类似的东西execve(2)replacesystem(3)调用即可。 如果你不想这样做，你也可以写一个非常小的，限制性的shell来适当地locking事情。
巧合的是，这个问题引起我再次检查，你会很高兴知道，一个能够编写.htaccess文件的用户不能仅凭借mod_evasive正在安装（ RSRC_CONF是正确的设置，所以在这一点上mod_evasive的作者的荣誉）。 然而，考虑到你如何描述你的configuration，至less有一个很好的机会，至less有任何用户能够运行代码为Apache（例如，禁止mod_su*等，任何人可以运行PHP，Perl，CGI，等），可以禁止你使用IPTables你自己的服务器。
为什么Apache需要运行这个脚本？ 看起来你正在将apache升级到root，并且当你可以以root身份运行脚本的时候为它分配一个shell。
给Apache的sudo访问就像lockingbuild筑物的所有门窗一样…而且还为运输docker安装高架门，并将其敞开。 （理论上用户只能在航运海湾中获得某些东西……但是他们没有进入该build筑物的更less的入口，并且可以开始撬动进一步的入口点。
为apache用户提供一个shell来与sudo访问一起使用就像在所述的运输区域留下一个关键的切割器一样。 有了足够的运气，攻击者可以使他/她需要的密钥（获得访问/权限）。
https://unix.stackexchange.com/questions/78985/deleting-users-with-nologin-shell根据上述问题：/ bin / nologin shell可以防止任何人以有问题的用户身份login（请参阅：console， SSH，素等）。
你也可以看一下： https ： //security.stackexchange.com/questions/5707/recommendations-for-changing-the-default-shell-for-service-accounts – 关于nologin vs / dev / null作为shell。