Странные ссылки в лог-файлах Apache: пустая строка и то, что выглядит как код MySQL

0

Я прочитал свои логфайлы в R, и когда я смотрю на реферера, есть некоторые странные записи:

> logs <- read.table("logfile")
> referer <- data.frame(table(logs$referer))
> head(referer, 2)
Var1              Freq
1                  157
2             - 250290

Apache использует тире (-) для обозначения недостающего реферирования. Эта строка 2. Итак, что означает пустая строка ('') в строке 1? Как я вижу, это могло произойти только в том случае, если Apache "забыл" написать референт в файл журнала.

Вот одна из 157 записей с пустой строкой реферирования (я анонимизировал клиентский ip и URL моего сайта):

173.244.xxx.xxx - - [17/Apr/2018:08:07:46 +0200] "GET /feeds/atom.xml HTTP/1.1" 200 18820 www.my-website.com "" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36; [email protected]" "-"

Но самые таинственные референты выглядят так:

554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:"num";s:280:"*/ union select 1,0x272f2a,3,4,5,6,7,8,0x7b24617364275d3 ...

Я отключил строку в конце (это продолжается довольно долго), потому что я не знаю, содержит ли она конфиденциальную информацию. У меня около 20 посещений с подобными рефери, все из одного и того же клиентского ip, большинство из которых запрашивают ресурсы, которые не существуют на моем сервере, такие как //user.php и //cm.php.

Мне кажется, что это, по крайней мере частично, запросы MySQL. a:2:{s:3:"num";s:459:" - это начало сериализованного массива. Я использую этот формат для хранения некоторых данных из веб-формы в базе данных MySQL. Но эта обработка происходит с серверов и никогда не отправляется в браузер пользователя. И как в любом случае запрос MySQL заканчивается как референт? Я могу понять, что кто-то может попытаться ввести код MySQL в веб-форму, но это не делает эту часть реферирования.

Любые объяснения были бы приятными.

  • 0
    Есть пакет R - webreadr разработанный специально для лог-файлов Apache. Я бы предложил использовать это в будущем.
Теги:
http-referer
logfile

2 ответа

0

Это нападение на внутреннюю инфраструктуру. Многие организации используют централизованные системы для сбора журналов, а затем используют инфраструктуру отчетности для поддержки журналов запросов. Разработчики довольно плохо разрабатывают безопасные системы, и SQL в поле Referer пытается воспользоваться этим.

Атакующие также могут пытаться хранить фрагменты в полях Referer а затем использовать их при других типах атак.

Если вы не используете плохо обработанное программное обеспечение для запросов журналов, вы должны быть в порядке.

Это - https://resources.infosecinstitute.com/sql-injection-http-headers/ - содержит дополнительную информацию.

Кроме того, как отмечается в комментарии, рассмотрите пользователя webreadr для чтения в файлах журналов веб-сервера.

И, после дальнейшего рассмотрения, это, по-видимому, кампания группы злоумышленников, стремящейся скомпрометировать систему управления контентом "Ecshop" (https://github.com/SecWiki/CMS-Hunter/tree/master/Ecshop/ecshop2.x_code_execute), Если вы работаете, вы можете проверить свой сервер втрое.

  • 0
    Спасибо. Любые дополнительные мысли о том, что означает этот пустой строковый реферер или как он мог появиться?
  • 0
    Вы используете read.table поэтому это может быть "` `" или даже неразрывный пробел.
Показать ещё 3 комментария
0

Это похоже на попытку SQL-инъекции. Журналы не будут отображаться, если попытка SQL выполнена успешно.

Хотя это обычно отображается в поле URL-адреса, нет причин, по которым он не может отображаться в поле HTTP-реферера в ваших журналах.

  • 0
    Спасибо. Любые дополнительные мысли о том, что означает этот пустой строковый реферер или как он мог появиться?
  • 0
    Пустая строка ссылки появится, если кто-то нажмет на ссылку, или введет URL-адрес, или установит плагин / параметры конфиденциальности, которые запрещают его передачу, или представляет собой скрипт.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню