向日誌文件中具有不同域/url 的網站發出的請求，黑客企圖？

在我的一個網站中，我正在記錄對伺服器發出的所有 url 請求。我記錄這些數據用於統計目的，以改進網站。

日誌看起來像

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。

我應該擔心嗎？這是對我的伺服器的某種攻擊嗎？

編輯

具體來說，在伺服器上執行的應用程序正在記錄這些 url，而不是伺服器本身。因此，在每個頁面請求上，我的腳本都將 url 記錄在$_SERVER數組中

當您說$_SERVER正在使用 from 的值時，大概是指$_SERVER['HTTP_HOST'].

將此值設置為任何值都非常容易——它來自伺服器請求中發送的 HTTP ‘Host:’ 標頭。例如，您的伺服器的 IP 是 1.2.3.4：

curl -H 'Host: otherserver.com' http://1.2.3.4/httptest.php

您的日誌系統可能會重新組裝它，看起來像是對http://otherserver.com/httptest.php的請求。

在你的網路伺服器上嘗試這樣的請求，看看你的日誌會發生什麼！

我只能猜測為什麼有人會這樣做。人們可能想測試在 IP 地址上執行的 HTTP 服務，但不知道那裡的任何有效主機名。一些 Web 伺服器可能會拒絕沒有 ‘Host:’ 標頭的請求，因此發送 /some/ ‘Host:’ 標頭可能總比沒有好。

此外，有時惡意 URL 似乎被發送到伺服器，以便它們最終出現在日誌中，伺服器管理員可能會看到這些 URL 並可能點擊它們。

一個好的安全做法是刪除與server{}Nginx 中預設塊的連接。這是使用失去或無效Host:標頭建立的連接的地方。這是一個例子：

server {
   listen       80  default_server;
   server_name  _; # some invalid name that won't match anything
   return       444;
}

444 響應程式碼是 Nginx 特定的。它只是關閉連接並且不返回任何內容，從而最大限度地減少您在這些連接上花費的頻寬和資源使用。

引用自：https://serverfault.com/questions/750455