“Allrequestsallowed.com”… Попытка взлома?

11

У меня много попыток на моем (маленьком, личном и абсолютно неважном) веб-сервере, и apache и fail2ban обычно делают свою работу правильно. Но есть запись в журнале, которая беспокоит меня:

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

Проблема в том, что ответом был не код 404, а 200. Все хорошо? Мне кажется странным, но мои знания в этой области (и многих других), мягко говоря, ограничены.

server security webserver Лури
источник
1
Похоже , я не разрешается размещать новый ответ, но мы нашли запись , как это в наших журналах, и мы были в состоянии проверить , что это не опасно, воспроизводя запрос с завитком: curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Кажется, что конфигурация по умолчанию возвращает страницу "Welcome to nginx" без содержательного содержимого в нашей системе Ubuntu. Таким образом, это ответ 200, но это простая всеобъемлющая страница - на самом деле мы не передаем запрос в другом месте или что-то в этом роде.
Фрэнк Фармер

Ответы:

12

Во-первых, я не знаю, что пытается совершить предполагаемый злоумышленник. Может быть, есть сценарий PHP или версия PHP, уязвимая для какой-то странной атаки ID сессии, я не знаю. Вам, вероятно, не о чем беспокоиться.

Ваш сервер вел себя точно так, как ожидалось. 200 - ожидаемый код в данной конкретной ситуации из-за того, как Apache интерпретирует передаваемый ему URL.

Во-первых, http://allrequestsallowed.comобрабатывается как более обычный заголовок «Host:» ( обратите внимание, что я не думаю, что это указано в RFC, и другие серверы могут не интерпретировать это так, как я ошибался, это указано в RFC 2616 в разделе 5.1. 2, хотя клиенты, кажется, редко используют эту форму. Извините, мне нужно исправить реализацию сервера HTTP, которую я написал некоторое время назад ...).

Теперь, по-видимому, у вас нет сайта с именем «allrequestsallowed.com». Так что же происходит, когда Apache получает Host:заголовок (или эквивалент) для имени хоста, которое он не распознает? Первый виртуальный хост выбирается по умолчанию. Это хорошо определенное и задокументированное поведение для Apache. Таким образом, какой бы ни был ваш первый виртуальный хост (или просто конфигурация основного сервера, если нет никаких vhosts), все равно, независимо от того, как он называется.

Теперь оставшаяся часть URL состоит из двух частей - пути /и параметра GET ( ?PHPSESSID...бит).

Теперь путь /должен присутствовать практически на каждом веб-сервере. В большинстве случаев он сопоставляется с чем-то вроде index.htmlили, возможно, index.phpсценарием, хотя вы, конечно, можете переопределить все это.

Если он отображается в статический HTML-файл, абсолютно ничего необычного не происходит - возвращается содержимое файла, и все, параметр просто игнорируется. (Предполагая, что у вас нет определенных расширенных директив конфигурации, и вы почти наверняка этого не сделаете.)

С другой стороны, если это какой-то скрипт, эта PHPSESSIDпеременная будет передана в скрипт. Если сценарий фактически использует эту переменную (в данном конкретном случае, вероятно, только сценарии PHP, использующие встроенную обработку сеансов PHP), его поведение будет зависеть от содержимого.

Однако, по всей вероятности, даже если вам /случится сопоставить скрипт PHP с использованием сессий, ничего удивительного не произойдет. Идентификатор сеанса, вероятно, в любом случае не будет существовать и будет либо проигнорирован, либо скрипт выдаст ошибку.

В маловероятном случае, когда идентификатор сеанса существует, злоумышленник может предположительно захватить чужой сеанс. Это было бы плохо, но это на самом деле не дыра в безопасности - дыра была бы там, где злоумышленник получил информацию об идентификаторе сеанса (прослушивание беспроводной сети - хороший кандидат, если вы не используете HTTPS). На самом деле они не смогут сделать ничего, чего не смог бы сделать пользователь, для которого он изначально был сеансом.

Изменить: Кроме того, «% 5C» внутри SESSIONID отображается на символ обратной косой черты. Похоже, что это тест для атак через каталоги на хостах Windows.

Николас Найт
источник
У меня были похожие запросы 404, 500, 403 и 20x на моих серверах, запущенных nginxили lighttpd, и после отправки IP-адресов / исходных хостов в фирму кибер-анализа было подтверждено, что это были попытки использовать дыры в сервере среди прочего , Запросы, аналогичные тем, которые были заданы OP, для разных хостов. Вы говорите, что они должны быть полностью проигнорированы? Потому что, если они действительно обеспокоены, они могут заблокировать хост (ы) в iptables.
Томас Уорд
@ The Evil Phoenix: Хост в URL-адресе - это не то место, откуда поступает запрос, это просто эквивалент заголовка «Host:». Фактический IP-адрес клиента, который ОП скрыл, может быть заблокирован с помощью iptables, если он пожелает, но, если он не наводнен запросами, это действительно не имеет значения. То, что кто-то пытается использовать дыру, не означает, что дыра присутствует. Я управляю множеством (Linux) серверов, которые записывают много странных запросов, предназначенных для использования дыр каждый день - большинство из них дыр в Windows / IIS! Это просто слепое сканирование. Если он не получил попадание, он переходит к следующему IP-адресу.
Николас Найт
@The Зло Феникс: Кроме того, если отверстие было присутствовать, блокирование IP - адрес, эксплуатируемый он не будет делать один бит добра. Ваш сервер уже будет скомпрометирован и будет по-прежнему уязвим к той же атаке из других источников, а источников множество. Каждая зомби-система (а их много миллионов) является потенциальным источником вредоносного сканирования.
Николас Найт
Хорошее и подробное объяснение .... Большое спасибо. Я скрыл оскорбительный IP в случае, если он / она ip-ego-surfes :). Мои / отображаются на Apache по умолчанию "Это работает" (я знаю, как непрофессионально ... но я сказал, что это личное, смеется). Поэтому я предполагаю, что ничего не должен делать, если один и тот же IP не станет проблемой, и в этом случае я заблокирую его с помощью iptables (или даже hosts.deny?). Еще раз спасибо.
Лури
1

Я получил разрешение на все запросы на ip, который используется как запись A для всех наших парковочных доменов.

Мой выстрел в том, что это имя хоста используется в сочетании с локальным файлом хоста «злоумышленника», указывающим на целевой хост.

Фактический веб-сервер 31.44.184.250 предназначен только для обработки внешних запросов.

Мое мнение: полное безвредность. Не вижу никакой пользы от этого, кроме вещей, которые вы можете сделать с любым другим поддельным доменным именем в вашем хост-файле.

Kajje
источник