我们收到了一个发送到服务器的 POST 请求，其中包含以下内容：
%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%F%69%6E%70%75%74+%2D%6E
使用 url 解码可转换为：
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n
它似乎类似于Ubuntu 14.04 上通过 Nginx 发出奇怪的 URL 请求，恶意用户想要做什么？。请求在什么情况下会起作用？我从日志中看到我们发送了一个 404，但我想确保我们没有任何其他可能受到此漏洞影响的盒子。
答案1
很多年前，人们曾经将 PHP 作为 CGI 脚本运行（甚至不是 FastCGI，那时还不存在！），部分原因是他们可以将 Apache 从其低性能的 prefork MPM 切换到新的、性能略高的工作 MPM。（而且 nginx 当时还不为人所知，那是很久以前的事情了。）如果服务器设置为将 PHP 作为 CGI 脚本运行，那么您可以直接在 调用 PHP 解释器/cgi-bin/php。
从技术上讲，PHP 仍可以作为 CGI 安装，但事实证明它的性能不如人们所希望的那样，因此发明了 FastCGI。所有当前高性能 PHP 站点都使用 FastCGI/FPM，通常使用 nginx，有时使用 Apache 的事件 MPM。FastCGI/FPM 不易受此影响，因为它们不允许直接通过 调用 PHP /cgi-bin。
如果您的服务器不是一堆以 CGI 形式运行的古老而腐烂的 PHP，那么您不必担心这个请求。
答案2
普遍的问题是命令注入. 旧的不安全的 CGI 配置允许 php 执行指令，这使得这种情况变得更容易发生，尽管发送 404 的现代 Web 服务器并不容易受到这种攻击。
您可以通过删除不需要的 CGI、使用文件权限和可能的 SELinux 锁定 Web 服务器以及保护 Web 应用程序来防止这种情况。打开Web应用程序安全项目测试项目 有一些一般性建议。
答案3
恶意攻击者或想要从您的漏洞赏金中分一杯羹的渗透测试人员会测试您的网站，以查找在编写 Web 应用程序或配置 Web 服务器时出现的常见错误。这些攻击依赖于这样一个事实：您、您的供应商、Web 应用程序开发人员或您的 IT 团队可能会犯一个小错误，或者忘记更新软件或配置以应对新发现的安全问题，因此他们只是试图利用大量已知问题来攻击互联网上的每台服务器。如果您不及时更新系统并了解所使用的平台或软件堆栈中的最新安全问题，最终您的安全（或访问者的安全）将受到损害。
有几种方法可以加强你的 Web 应用程序抵御成功攻击的能力：
- 培训您的 Web 开发人员使用良好的安全实践，OWASP 始终是一个很好的起点：https://www.owasp.org/index.php/OWASP_Guide_Project
- 将您的应用程序置于 Web 应用程序防火墙 (WAF) 后面。WAF 将扫描所有传入请求，并直接丢弃那些看起来不怀好意的请求。一种易于使用的云解决方案是https://www.cloudflare.com/lp/waf-a/但还有很多其他的选择，比如云、可以在数据中心安装的设备、可以在服务器上运行的软件（比如 Palo Alto、Fortigate、CheckPoint、Watchguard），或者还有免费的选择，比如https://modsecurity.org（目前看来，发行版的包管理器似乎需要选择 nginx 插件/模块，但是已经有一个 apache 模块了）
- 让渗透测试人员定期调查您的基础设施，如果您向他们提供有关系统的文档和信息，他们将能够比互联网上的随机攻击者更准确地执行这些测试，他们很可能会比随机攻击者更快地发现问题，然后您就可以修复它们。如果您想自己做这件事，OWASP 是一个很好的资源：https://www.owasp.org/index.php/OWASP_Testing_Project
- 除了 WAF，你还可以安装软件来阻止发出过多无效请求的用户。例如暴力（ssh、basic auth、ftp、mysql...）登录、生成过多内部服务器错误，甚至过多页面无法找到。我最喜欢的软件是安装 fail2ban (https://www.fail2ban.org/) 将扫描您的日志文件并使用防火墙规则阻止有问题的 IP 几分钟。
这两个选项都不能 100% 保证，我建议全部都做。
有关可以在 centos7 系统上采取的所有安全/强化措施的详尽列表，您可以按照 RedHat 的本指南进行操作：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/index/index
答案4
补救措施
消毒
URL 和表单数据需要过滤掉无效字符。一个“黑名单”字符是一个选项，但可能很难想出所有要验证的字符。也可能有一些字符尚未发现。应该创建一个仅包含允许字符或命令列表的“白名单”来验证用户输入。这个列表应该消除遗漏的字符以及未发现的威胁。
可以包含用于命令注入的通用黑名单
| ; & $ > < ' \ ! >> #转义或过滤窗口的特殊字符，
( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + ,转义或过滤 Linux 的特殊字符，
{ } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + ,权限
Web 应用程序及其组件应在严格的权限下运行，不允许执行操作系统命令。尝试从灰盒的角度验证所有这些信息以进行测试。
https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)
还使用 comodo 规则在 Nginx 中安装 modsecurity。