☰

80 端口重定向的未知原因

tag-icon • tag-icon ubuntu iptables webserver nginx malware
80 端口重定向的未知原因

我有一台运行 Apache 2.4.7 的 Ubuntu 14.04 服务器，在 80 端口上托管一个站点。今天我发现每个对 80 端口的请求都会重定向到另一个网站并响应：

HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.2
Date: Thu, 15 Jan 2015 13:37:18 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: some.website.com

我没有安装 nginx，但仍然使用ps ax | grep nginx命令搜索 nginx 进程，结果只有一个：25759 pts/1 S+ 0:00 grep --color=auto nginx。这看起来不像是一个有问题的过程，但仍然：kill 25759屈服了-bash: kill: (25759) - No such process

接下来，我停止了 apache（它对重定向没有任何改变），并决定看看谁使用命令监听 80 端口，lsof -i :80 | grep LISTEN但该命令没有告诉我任何信息，如果我使用命令列出所有侦听器： lsof -i | grep LISTEN我会得到以下列表：

sshd        673     root    3u  IPv4   7078      0t0  TCP *:ssh (LISTEN)
tinyproxy   972     root    0u  IPv4   7654      0t0  TCP *:9582 (LISTEN)
Xtightvnc  1173     root    0u  IPv4   7914      0t0  TCP *:x11-1 (LISTEN)

所有这些都是已知实体。如果我启动 apache，也会出现以下行：

apache2   25926     root    4u  IPv6 139312      0t0  TCP *:http (LISTEN)

接下来我考虑了 iptables，但iptables -L显示空列表：

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

那么，问题是如何找到导致此重定向的原因（从具有不同互联网提供商的几台不同计算机进行检查）并将其删除？

更新： 1.iptables -t nat -L产生此列表：

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

我如何获得您粘贴到问题中的重定向响应？有五种方法：

  • 在远程计算机上通过 Google Chrome 和查尔斯代理 请求ip：

        GET / HTTP/1.1
    Host: 37.139.9.156
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
    Accept-Encoding: gzip, deflate, sdch
    Accept-Language: en-US;q=0.6,en;q=0.4

    答复如问题开头所述。

  • 但是通过 Google Chrome 和 Charles 代理使用主机名的远程计算机响应是正确的（无重定向）。要求：

        GET / HTTP/1.1
    Host: hostname
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
    Accept-Encoding: gzip, deflate, sdch
    Accept-Language: en-US;q=0.6,en;q=0.4

  • 在服务器上通过curl -v http://ip

        * Rebuilt URL to: http://ip/
    * Hostname was NOT found in DNS cache
    *   Trying ip...
    * Connected to ip (ip) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: ip
    > Accept: */*
    >
    < HTTP/1.1 301 Moved Permanently
    * Server nginx/1.6.2 is not blacklisted
    < Server: nginx/1.6.2
    < Date: Thu, 15 Jan 2015 14:25:20 GMT
    < Content-Type: text/html
    < Content-Length: 184
    < Connection: keep-alive
    < Location: http://www.sputton.com/
    <
    <html>
    <head><title>301 Moved Permanently</title></head>
    <body bgcolor="white">
    <center><h1>301 Moved Permanently</h1></center>
    <hr><center>nginx/1.6.2</center>
    </body>
    </html>
    * Connection #0 to host ip left intact

  • 在服务器上通过curl -v http://localhost

        * Connected to localhost (127.0.0.1) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: localhost
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Date: Thu, 15 Jan 2015 14:24:48 GMT
    * Server Apache/2.4.7 (Ubuntu) is not blacklisted
    < Server: Apache/2.4.7 (Ubuntu)
    < Access-Control-Allow-Origin: *
    < Access-Control-Allow-Headers: Authorization
    < Access-Control-Allow-Methods: POST, GET, OPTIONS
    < CACHE-CONTROL: no-cache
    < EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT
    < PRAGMA: no-cache
    < CONTENT-LENGTH: 7134
    < Vary: Accept-Encoding
    < Content-Type: text/html; charset=utf-8
    < Correct body output
    * Connection #0 to host localhost left intact

  • 在服务器上通过curl -v http://hostname

        * Rebuilt URL to: hostname
    * Hostname was NOT found in DNS cache
    *   Trying ip...
    * Connected to hostname (ip) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: hostname
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Date: Thu, 15 Jan 2015 14:32:01 GMT
    * Server Apache/2.4.7 (Ubuntu) is not blacklisted
    < Server: Apache/2.4.7 (Ubuntu)
    < Access-Control-Allow-Origin: *
    < Access-Control-Allow-Headers: Authorization
    < Access-Control-Allow-Methods: POST, GET, OPTIONS
    < CACHE-CONTROL: no-cache
    < EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT
    < PRAGMA: no-cache
    < CONTENT-LENGTH: 7134
    < Vary: Accept-Encoding
    < Content-Type: text/html; charset=utf-8
    < Correct body output
    * Connection #0 to host hostname left intact

因此通过主机名请求页面可以，但直接 ip 请求失败。

答案1

我没有安装 nginx，仍然使用 ps ax | 搜索 nginx 进程。 grep nginx 命令有一个结果：25759 pts/1 S+ 0:00 grep --color=auto nginx。它看起来不像有问题的进程，但仍然：kill 25759产生了-bash：kill：(25759)-没有这样的进程Blockquote

您正在尝试终止您的 grep 进程（在 ps aux 命令上），顺便说一句，该进程在显示此内容时应该已死亡）

现在 - 对于你的问题：检查你是否没有在 /etc/apache2/sites-enabled/ 中启用任何虚拟主机，或者你的 /var/www/index.html 中是否没有重定向（或者你保存的任何地方）网站）定义。

检查您的 /etc/hosts 以检查您是否没有定义一些从您的网站地址重定向到另一个网站地址的别名。

您还可以 grep/find 整个 /etc/ 和 /var/www（如果网页在那里）“some.website.com” - 如果您的系统中有某些内容重定向到那里 - 它应该找到原因（文件） 。

答案2

通过使用ip route get $IP，ip a已经确定所使用的IP地址实际上并不属于被调查的服务器，因此该服务器上并没有运行神秘的nginx，而是实际上在该服务器上运行做拥有该 IP 地址。

答案3

如果 nginx 没有运行并且没有任何东西将其代理到另一台服务器，那么几乎肯定是发生在您的服务器之外。可能是在 DNS 级别。

  • 检查nslookup（表明存在严重的 DNS 问题或 ISP 操纵）
  • 从另一台计算机检查（/etc/hosts问题）
  • 从另一个网络检查（ISP 变得流氓）。

相关内容