Я прочитал свои логфайлы в 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 в веб-форму, но это не делает эту часть реферирования.
Любые объяснения были бы приятными.
Это нападение на внутреннюю инфраструктуру. Многие организации используют централизованные системы для сбора журналов, а затем используют инфраструктуру отчетности для поддержки журналов запросов. Разработчики довольно плохо разрабатывают безопасные системы, и 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), Если вы работаете, вы можете проверить свой сервер втрое.
read.table
поэтому это может быть "` `" или даже неразрывный пробел.
Это похоже на попытку SQL-инъекции. Журналы не будут отображаться, если попытка SQL выполнена успешно.
Хотя это обычно отображается в поле URL-адреса, нет причин, по которым он не может отображаться в поле HTTP-реферера в ваших журналах.
webreadr
разработанный специально для лог-файлов Apache. Я бы предложил использовать это в будущем.