0

I have an Ubuntu 14.04 server with Apache 2.4.7 running there, hosting one site on 80 port. Today I discovered that every request to 80 port redirects to another website with response:

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

I don't have nginx installed, bit still searched for a nginx process with ps ax | grep nginx command with one result: 25759 pts/1 S+ 0:00 grep --color=auto nginx. It didn't seem like the offending process but still: kill 25759 yielded -bash: kill: (25759) - No such process

Next, I stopped apache (it changed nothing about redirects), and decided to see, who listens to 80 port with the command lsof -i :80 | grep LISTEN which told me nothing, and if I list all listeners with the command: lsof -i | grep LISTEN I get the following list:

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)

All of which are known entities. If I start apache the following line is also there:

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

Next I thought about iptables, but iptables -L shows empty list:

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

So, the question is how do I find what causes this redirect (checked from several different computers with different internet providers) and remove it?

Update: 1. iptables -t nat -L yields this list:

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

How did I obtain the redirect response that you pasted into your question? Five ways:

  • On remote computer via Google Chrome and Charles proxy Request with 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
    

    Response was as described at the beginning of the question.

  • But remote computer via Google Chrome and Charles proxy with hostname the response was correct (no redirect). Request:

        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
    
  • On server via 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
    
  • On server via 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
    
  • On server via 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
    

So requesting pages via hostname works, but direct ip request fails.

  • How about iptables -t nat -L ? Note that the process you found was the grep command itself, which of course didn't exist anymore when you tried to kill it. How did you obtain the redirect response that you pasted into your question? Please edit your question to include that, as it may be you're getting the repsonse from somewhere else than the system you're checking... – wurtel Jan 15 '15 at 14:06
  • @wurtel added info – rfg Jan 15 '15 at 14:43
  • On the server, do ip route get $ip (replace $ip with the ip you used with curl and that gave the wrong answer). – wurtel Jan 15 '15 at 14:53
  • That show that the ip address is not local to the server! Perhaps your server is behind a load balancer or some other frontend and the ip belongs to that system and not your server. Check your server's ip addrsses with ip a. – wurtel Jan 15 '15 at 15:08
  • @wurtel thank you. That solved it. Mistyped ip address. – rfg Jan 15 '15 at 15:28
0

By using ip route get $IP and ip a it has been determined that the used IP address did not in fact belong to the server under investigation, so there is no mystery nginx running on this server but in fact on the server that does own that IP address.

1

I don't have nginx installed, bit still searched for a nginx process with ps ax | grep nginx command with one result: 25759 pts/1 S+ 0:00 grep --color=auto nginx. It didn't seem like the offending process but still: kill 25759 yielded -bash: kill: (25759) - No such process Blockquote

You are trying to kill your grep process( on ps aux command) which in the moment of displaying this should be dead by the way)

Now - to your question: Check if you don't have any virtual hosts enabled in /etc/apache2/sites-enabled/ OR if you don't have redirect in your /var/www/index.html (or wherever you keep website) defined.

Check your /etc/hosts to check if you don't have definied some aliases that redirect from your website address to another.

You can also grep/find whole /etc/ and /var/www(if the webpage is there) for "some.website.com" - if there is something in your system that redirect there - it should find the reason (file).

0

If nginx isn't running and nothing's proxying it over to another server, it's almost certainly happening outside of your server. Probably at DNS level.

  • Check an nslookup (indicative of serious DNS issues or ISP manipulation)
  • Check from another computer (/etc/hosts issues)
  • Check from another network (ISP gone rogue).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.