на одном из своих веб-сайтов я регистрирую все запросы URL, отправленные на сервер. Я регистрирую эти данные для статистики, чтобы улучшить сайт.
Журналы выглядят как
http://example.com/search 2016-01-12 23:03:09
http://example.com/post/1234 2016-01-12 23:03:12
..........
Итак, это выглядит нормально. Я обнаружил в журналах что-то, что не имеет для меня смысла, у меня несколько сотен записей с другим доменом
http://dhg.example.org/httptest.php 2016-01-10 20:12:15
И в прошлом у меня было несколько подобных, с моим доменом или с IP-адресом сервера
http://example.com/httptest.php
http://192.0.123.12/httptest.php
Мне было интересно, как это возможно, что запросы, отправленные на мой сервер, имеют этот URL-адрес, а не URL-адрес моего веб-сайта или IP-адрес сервера.
Я должен беспокоиться? Это какая-то атака на мой сервер?
Чтобы быть конкретным, приложение, работающее на сервере, регистрирует эти URL-адреса, а не сам сервер. Итак, при каждом запросе страницы мой скрипт регистрирует URL-адрес в $_SERVER массив
Когда вы говорите значение от $_SERVER используется, по-видимому, вы имеете в виду $_SERVER['HTTP_HOST'].
Это значение довольно легко установить на любое значение - оно поступает из HTTP-заголовка Host:, отправленного в запросе на ваш сервер. Например, если IP вашего сервера - 1.2.3.4:
curl -H 'Host: otherserver.com' http://1.2.3.4/httptest.php
Ваша система ведения журнала может перекомпилировать это как запрос на http://otherserver.com/httptest.php.
Попробуйте выполнить такой запрос на своем веб-сервере и посмотрите, что происходит в ваших журналах!
Я могу только догадываться, почему кто-то может это сделать. Люди могут захотеть протестировать службы HTTP, работающие на IP-адресе, но не знают ни одного действительного имени хоста. Некоторые веб-серверы могут отклонять запросы без заголовка «Host:», поэтому отправка заголовка / some / «Host:» может быть лучше, чем отсутствие заголовка.
Кроме того, иногда кажется, что вредоносные URL-адреса отправляются на серверы только для того, чтобы они попадали в журналы, где администратор сервера может видеть URL-адреса и, возможно, нажимать на них.
Хорошая практика безопасности - сбросить соединения, сделанные по умолчанию server{} блок в Nginx. Здесь установлены соединения с отсутствующим или недействительным Host: заголовок идти. Вот пример:
server {
listen 80 default_server;
server_name _; # some invalid name that won't match anything
return 444;
}
Код ответа 444 специфичен для Nginx. Он просто закрывает соединение и ничего не возвращает, сводя к минимуму полосу пропускания и использование ресурсов, которые вы тратите на эти соединения.
Первый шаг в успешной атаке - это сбор информации. Я провел небольшое исследование и обнаружил, что httptest.php упоминается в учетная запись github что-то под названием Кохана, поиски Коханы приводят меня к Быстрая реализация. Однако кто-то может использовать то же имя для файла, чтобы попытаться запутать читателя журнала. Хотя один вход может быть столь же опасным, если его создает правильный человек, к которому вы должны быть очень внимательны, когда вы видите несколько входов и особенно ошибки 404 в большом количестве, поскольку это может показать явное намерение против вашей сети, один элемент может просто представлять кто-то попробовал новый эксплойт, который потерпел неудачу, и они двинулись дальше.