☰

포트 80 리디렉션의 알 수 없는 이유

tag-icon • tag-icon ubuntu iptables webserver nginx malware
포트 80 리디렉션의 알 수 없는 이유

Apache 2.4.7을 실행하고 포트 80에서 사이트를 호스팅하는 Ubuntu 14.04 서버가 있습니다. 오늘 저는 포트 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

다음으로 아파치를 중지하고(리디렉션은 변경하지 않음) 명령을 사용하여 포트 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 25759spawned -bash: kill: (25759) - 해당 프로세스가 없습니다.

grep 프로세스(ps aux 명령에서)를 종료하려고 합니다. 그런데 이 프로세스가 표시될 때쯤에는 종료되어야 합니다.

이제 - 문제에 대해: /etc/apache2/sites-enabled/에 활성화된 가상 호스트가 없는지 또는 /var/www/index.html (또는 저장하는 모든 위치) 웹 사이트에 리디렉션이 없는지 확인하십시오. ) 정의.

/etc/hosts를 확인하여 웹 사이트 주소에서 다른 웹 사이트 주소로 리디렉션되는 일부 별칭을 정의하지 않았는지 확인하세요.

전체 /etc/ 및 /var/www(웹 페이지가 있는 경우) "some.website.com"을 grep/찾을 수도 있습니다. 시스템의 항목이 그곳으로 리디렉션되는 경우 이유(파일)를 찾아야 합니다.

답변2

사용 결과 ip route get $IP, ip a사용된 IP 주소는 실제로 조사 중인 서버에 속하지 않는 것으로 확인되었으며, 따라서 신비한 nginx가 해당 서버에서 실행되고 있는 것이 아니라 실제로 해당 서버에서 실행되고 있는 것으로 확인되었습니다.하다해당 IP 주소를 소유하세요.

답변3

nginx가 실행되고 있지 않고 이를 다른 서버로 프록시하는 것도 없다면 서버 외부에서 발생하는 것이 거의 확실합니다. 아마도 DNS 수준일 것입니다.

  • 확인 nslookup(심각한 DNS 문제 또는 ISP 조작을 나타냄)
  • 다른 컴퓨터에서 확인( /etc/hosts문제)
  • 다른 네트워크에서 확인하세요(ISP가 불량이 되었습니다).

관련 정보