Почему журнал apache запрашивает GET http://www.google.com с кодом 200?

Меня недавно спросили: "Что вызывает такую ​​строку в нашем access.log?"

59.56.109.181 - - [22 / Feb / 2010: 16: 03: 35 -0800] "GET http://www.google.com/ HTTP / 1.1" 200 295 "-" "Mozilla / 5.0 (совместимо; MSIE 5.01; Win2000)"

Мой немедленный ответ: кто-то исследует что-то немного коварное.

Но:

  • как? Предположение... короткий скрипт на Perl или Python может легко подключиться и запросить URL с неверным хостом. но не публиковать. Если вы знаете хороший лайнер, мне было бы любопытно. Рассмотрим этот гольф на сегодня:)
  • Уязвимости? Что кто-то ищет, когда он делает это, чему он научился и стоит ли это исправлять?
  • Нужна ли мне шляпа из фольги, чтобы они не читали мои мысли?
  • И для меня реальный вопрос: разве это не ответ 404, а не 200!?

Это на стандартном сервере LAMP (Ubuntu).

Источник

3 ответа

Решение

Может быть, вы хотите прочитать http://wiki.apache.org/httpd/ProxyAbuse

особенно этот пункт: "Мой сервер правильно настроен не для прокси, так почему же Apache возвращает код состояния 200 (Успех)?", он задает ваш вопрос "Разве это не ответ 404, а не 200!?"

Если Apache Conf в порядке, просто отправка корневой страницы. Это причина, потому что вы получаете код состояния 200.

Источник

Я думаю, что это произойдет, если кто-то попытается использовать сервер в качестве прокси. Это сделало бы http://... URL "нормальным" (в отличие от только части пути, которую вы ожидаете от обычного запроса к серверу.)

Что касается кода состояния 200, то... эээ... ну, мой сервер тоже это делает. Кажется, он игнорирует часть http://hostname/ и возвращает результат с локального сервера, используя оставшийся путь. Возможно, вам придется копаться в RFC, чтобы понять, почему это имеет смысл; Я не знаю ответа от случая к случаю.

Источник

Предполагая, что вы не используете свой сервер в качестве прокси-сервера, это, вероятно, обычные попытки злоупотребления прокси-сервером , которые регулярно наблюдаются на веб-серверах, подключенных к Интернету.

Запросы, получившие код состояния 200, вероятно, вернули вашу индексную страницу. Вы можете проверить это, используяили.

Предположим, что:

  • твое имя сервераsite.example.org;

  • третьи стороны пытаются подключиться иsearch.example.com;

  • твой/index.htmlфайл содержит:

              <!DOCTYPE html>
  <html>
  <head><title>It works!</title></head>
  <body><h1>It works!</h1></body>
  </html>

Используя curlCurl, вы можете реконструировать полученные запросы следующим образом:

      $ curl site.example.org --request-target http://news.example.net/
<!DOCTYPE html>
<html>
<head><title>It works!</title></head>
<body><h1>It works!</h1></body>
</html>

Используя telnettelnet, вы можете восстановить полученные запросы следующим образом:

      $ telnet site.example.org 80
> GET http://news.example.com/ HTTP/1.1
> Host: news.example.com
>
HTTP/1.1 200 OK
...
Content-Type: text/html
...

<!DOCTYPE html>
<html>
<head><title>It works!</title></head>
<body><h1>It works!</h1></body>
</html>

Если вы получите свойindex.htmlв результате это означает, что ваш сервер не настроен как прокси-сервер, и вам не следует беспокоиться об этих запросах.

Если вы действительно получили содержимоеnews.example.comилиnews.example.netваш веб-сервер настроен как прокси. Вы можете отключить это, оставив комментарий к любомуproxy on;строки в ваших конфигурациях Nginx или отключивmod_proxyв ваших конфигурациях Apache.

Несколько интересных упоминаний по этому поводу:

Источник
Другие вопросы по тегам