Causa desconhecida para redirecionamento na porta 80

Navegue suas respostas
0

Eu tenho um servidor Ubuntu 14.04 com o Apache 2.4.7 sendo executado lá, hospedando um site na porta 80. Hoje descobri que todas as solicitações para 80 portas redirecionam para outro site com resposta: 

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

Eu não tenho o nginx instalado, o bit ainda procurou por um processo nginx com o comando ps ax | grep nginx com um resultado: 25759 pts/1 S+ 0:00 grep --color=auto nginx . Não parecia o processo ofensivo, mas ainda: kill 25759 produziu -bash: kill: (25759) - No such process

Em seguida, parei o apache (ele não mudou nada sobre redirecionamentos), e decidi ver, quem escuta a 80 porta com o comando lsof -i :80 | grep LISTEN que não me disse nada, e se listo todos os listeners com o comando: lsof -i | grep LISTEN Eu obtenho a seguinte lista: 

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)

Todos eles são entidades conhecidas. Se eu iniciar o apache, a seguinte linha também está lá: 

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

Em seguida, pensei sobre o iptables, mas iptables -L mostra uma lista vazia: 

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

Então, a questão é como encontrar o que causa esse redirecionamento (verificado em vários computadores diferentes com provedores de internet diferentes) e removê-lo?

Atualização: 1. iptables -t nat -L produz esta lista: 

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

Como obtive a resposta de redirecionamento que você colou na sua pergunta? Cinco maneiras:

  • No computador remoto via Google Chrome e Proxy Charles Pedido com 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

    A resposta foi descrita no início da pergunta.

  • Mas o computador remoto via Google Chrome e o proxy Charles com hostname estavam corretos (sem redirecionamento). Pedido: 

        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

  • No servidor 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

  • No servidor 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

  • No servidor 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

Portanto, a solicitação de páginas por meio do nome do host funciona, mas a solicitação ip direta falha.

    
por rfg 15.01.2015 / 15:03

3 respostas

0

Usando ip route get $IP e ip a , determinou-se que o endereço IP usado não pertencia ao servidor sob investigação, portanto, não há nginx misterioso em execução neste servidor, mas, na verdade, no servidor que < em>> possui esse endereço IP.

    
por 15.01.2015 / 16:59
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

Você está tentando matar o seu processo no grep (no comando ps aux), que no momento de exibir isso deve estar morto, a propósito)

Agora - à sua pergunta: verifique se você não tem nenhum host virtual habilitado em / etc / apache2 / sites-enabled / OR se você não tiver redirecionado em seu /var/www/index.html (ou onde quer que você mantenha o site) definido.

Verifique seu / etc / hosts para verificar se você não definiu alguns aliases que redirecionam do endereço do seu site para outro.

Você também pode encontrar / grep / etc / e / var / www (se a página estiver lá) para "algum.website.com" - se houver algo em seu sistema que redirecione lá - ele deve encontrar o motivo (arquivo).

    
por 15.01.2015 / 15:26
0

Se o nginx não estiver em execução e nada estiver fazendo proxy para outro servidor, é quase certo que isso esteja acontecendo fora do seu servidor. Provavelmente no nível do DNS.

  • Verifique um nslookup (indicativo de sérios problemas de DNS ou manipulação de ISP)
  • Verifique em outro computador ( /etc/hosts issues)
  • Verifique em outra rede (ISP ido desonesto).
por 15.01.2015 / 15:16

Tags

incapaz de ler a saída para executar o próximo comando [closed] Configuração de rede do hypervisor KVM?