在我的一个网站上，我logging了对服务器所做的所有url请求。 我将这些数据logging下来以改进网站。
日志看起来像
http://example.com/search 2016-01-12 23:03:09 http://example.com/post/1234 2016-01-12 23:03:12 .......... 所以，这看起来很正常。 我现在在日志中发现了一些对我没有意义的东西，我有几百个具有不同域的条目
http://dhg.example.org/httptest.php 2016-01-10 20:12:15
在过去，我有一些类似的，我的域名或服务器的IP地址
http://example.com/httptest.php http://192.0.123.12/httptest.php
我想知道这是怎么可能的要求，我的服务器有这个url，而不是我的网站的url或服务器IP。
我应该担心吗？ 这是对我的服务器的某种types的攻击？
具体来说，服务器上运行的应用程序正在logging这些URL，而不是服务器本身。 所以在每个页面请求我的脚本logging$_SERVER数组中的URL
当你说$_SERVER的值正在被使用时，大概你的意思是$_SERVER['HTTP_HOST'] 。
将这个值设置为任何值都是非常容易的 – 它来自HTTP请求服务器发送的“主机：”头。 例如，你的服务器的IP是1.2.3.4：
curl -H 'Host: otherserver.com' http://1.2.3.4/httptest.php
您的日志logging系统可能重新组装，看起来像http://otherserver.com/httptest.php的请求。
尝试在您的Web服务器上这样的请求，看看你的日志发生了什么！
我只能猜测为什么有人会这样做。 人们可能想要testing运行在IP地址上的HTTP服务，但不知道那里的任何有效主机名。 一些Web服务器可能会拒绝没有“Host：”头的请求，所以发送/ some /'Host：'头可能比没有。
此外，有时恶意url似乎被发送到服务器，以便他们最终在日志中，服务器pipe理员可能会看到的URL，并可能点击它们。
一个很好的安全做法是放弃连接到Nginx的默认server{}块。 这是连接丢失或无效的Host:头去的地方。 这是一个例子：
server { listen 80 default_server; server_name _; # some invalid name that won't match anything return 444; }
444响应代码是Nginx特定的。 它只是closures连接，不返回任何内容，最大限度地减less了您在这些连接上的带宽和资源使用。
信息收集是攻击成功的第一步。 我做了一个小小的研究，发现httptest.php是在github上的一个叫做Kohana的账户上引用的，searchKohana引导我进入Swift实现 。 但是有人可能会使用相同的文件名来尝试混淆日志阅读器。 虽然一个主持人在由合适的人创build时可能同样危险，但是当你看到多个主题，特别是大量的404错误时，你希望非常勤奋，因为这可以显示你的networking有明确的意图，一个项目可能只是代表有人尝试了一个失败的新的漏洞，他们继续前进。