User-Agent с компонентом в кодировке base64?

(Вопрос щедрости внизу)

У меня проблема с клиентом, обращающимся к нашему сайту, и основная причина в том, что WAF (брандмауэр веб-приложений) не нравится их строка User-Agent:

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0

В этом случае строка в кодировке base64 вызывает ложный положительный результат в WAF, который считает, что User-Agent является libwww-perl. Строка base64 не декодируется для любого читаемого текста.

• Является ли строка в кодировке base64 внутри User-Agent нормальной или необычной?
• Охвачено ли использование строк base64 внутри User-Agent какими-либо RFC или рекомендациями основных поставщиков?

Я пытаюсь понять, что здесь происходит; Я не чувствую, что подпись WAF полностью не соответствует линии, поэтому я бы предпочел не просто отключить ее, но я раньше не видел такого рода строки User-Agent, так что я бы лучше понял, насколько распространены и / или законный вариант использования это.

Сайт предназначен для использования людьми с браузерами - это не API или что-то в этом роде - и мне сообщили, что пользователь попытался зайти на сайт с помощью «FF / IE / Chrome» и потерпел неудачу. Однако я показываю успешные соединения с того же IP-адреса клиента с пользовательским агентом Opera:

User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

Немного странно, что пользователь сообщает, что попробовал IE, но все строки User-Agent, которые я вижу, выглядят как Linux. (Как обычно, контакт с конечным пользователем осуществляется через несколько сторон, поэтому я не могу полностью доверять тому, что слышу). Также вероятно, что IP является исходящей стороной веб-прокси бизнес-класса, что объясняет, почему я вижу, как какая-то Opera работает на кого-то, а кто-то другой сообщает о проблемах с того же IP.

Обновить

Вдохновленный примером @PlanetScaleNetworks, я погуглил строку и оттуда в конечном итоге использовал UA Tracker для поиска строк base64 (или подмножества из них, которые были дополнены - я искал "=)"). Возвращено около 20 User-Agent:

Я собираюсь добавить вознаграждение к этому вопросу, и пространство для ответов, которое я ищу, это «какое программное обеспечение помещает строки base64 в User-Agents и почему? И есть ли какой-либо знак легитимности для этой практики? "

Незначительная точка:

Пользователь обошел нашу проблему, используя плагин браузера для изменения своего User-Agent, так что теперь это академическая проблема - но я думаю, что это интересная академическая проблема :)

Если весь другой трафик с этого IP-адреса является законным, я бы не стал беспокоиться о срабатывании правила WAF. Он не декодируется в читаемую человеком строку. Так что, скорее всего, он был вставлен прокси-устройством для целей отслеживания.

Что касается вашей озабоченности по поводу RFC, они написаны в качестве рекомендации о том, как следует использовать поле , хотя между платформами существует небольшая согласованность. При этом это значение, определенное клиентом, которому нельзя доверять, поскольку его тривиально изменить. Таким образом, зачем нужны правила WAF.

Есть две области, в которых я вижу, что строки User-Agent становятся проблемой:

1. Переполнение буфера - либо попытка переполнить буфер на сервере или внутри веб-сайта / приложения. Это явно не происходит в приведенном примере.
2. Сценарий / внедрение кода - предоставление встроенных сценариев, ссылок на удаленные файлы и т. Д. Опять же, явно не применимо к вашей ситуации.

Если вы действительно обеспокоены / параноидальны, измените строку User-Agent вашей собственной системы на эту и просматривайте те же страницы, используя прокси-сервер, такой как Fiddler, Burp и т. Д. Как запрос / ответы сравниваются с использованием вашего исходного Строка User-Agent?

Я бы не рекомендовал блокировать любые IP-адреса на основе предоставленного примера, если весь трафик с этого IP-адреса не является вредоносным. Даже тогда он должен быть заблокирован только на ограниченное время. А еще лучше создайте «заблокированную веб-страницу» с подробной информацией о том, как ее разблокировать. Перенаправляйте трафик туда, пока не свяжетесь.

Является ли строка в кодировке base64 внутри User-Agent нормальной или необычной?

Копаем список пользовательских агентов на WhichBrowser . Разумно сделать вывод, что это редко, но, возможно, является результатом заражения вредоносным ПО.

Однако в прошлом я также злоупотреблял этим поведением, чтобы добавить еще один уровень безопасности на свой собственный сайт, где только несколько клиентов с конкретным токеном base64 UA даже отображали страницу входа. Точно так же эта уникальная дактилоскопия может также использоваться для обслуживания страницы атаки или перенаправления в другое место.

Охвачено ли использование строк base64 внутри User-Agent какими-либо RFC или рекомендациями основных поставщиков?

Не специально. Ничто не документировано ни в одной информации о поставщиках браузеров Gecko. В предоставленной вами базе данных base64 это не часть информации о продукте, а комментарий. По-видимому, нет никаких ограничений для поля комментария, хотя наличие base64 в информации о продукте не допускается, так RFC7231как это может рассматриваться как ненужная информация, добавляемая к строке UA.

Вероятно, ваш WAF не может идентифицировать UA как что-то конкретное и, возможно, возвращает, libwww-perlпотому что фильтр неспецифичен (ложно положителен) и слишком доволен битом Linux / X11, поскольку не может иметь смысла в комментарии base64.

При онлайн-проверке эта строка агента пользователя встречалась на сайте closetnoc.org . Этот пользовательский агент был идентифицирован как являющиеся одним из ряда , которые были прослежены к одному IP - адресу , 192.185.1.20который был помечен как спаммер от list.quorum.to, bl.csma.bizи spamsources.fabel.dk.

Чтобы заблокировать доступ к этому IP-адресу (и, в свою очередь, к этому User-Agent) ...

Использование CISCO Firewall

access-list block-192-185-1-20-32 deny ip 192.185.1.20 0.0.0.0 any
permit any ip

Использование Nginx

Отредактируйте nginx.conf и вставьте include blockips.conf; если его не существует Отредактируйте blockips.conf и добавьте следующее:

deny 192.185.1.20/32;

Использование Linux IPTables Firewall

/sbin/iptables -A INPUT -s 192.185.1.20/32 -j DROP

Использование веб-сервера Microsoft IIS

<rule name="abort ip address block 192.185.1.20/32" stopProcessing="true">           
    <match url=".*" />   
    <conditions>    
        <add input="{REMOTE_ADDR}" pattern="^192\.185\.1\.20$" />   
    </conditions>  
    <action type="AbortRequest" /> 
</rule>

Использование Apache .htaccess

RewriteCond %{REMOTE_ADDR} ^192\.185\.1\.20$ [NC] 
RewriteRule .* - [F,L]

Источник: closetnoc.org

Я также вижу пользовательские агенты в кодировке simil-b64. После некоторого анализа выясняется, что клиенты, на которых установлен антивирус Касперского, ищут обновления.