User-Agent com componente codificado em base64?

(Pergunta de recompensa na parte inferior)

Estou tendo um problema com um cliente acessando nosso site, e a causa principal é que o WAF (Web Application Firewall) não gosta da string do User-Agent:

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

Nesse caso, a cadeia codificada em base64 está disparando um falso positivo no WAF, que considera o agente do usuário libwww-perl. A cadeia base64 não decodifica para nenhum texto legível.

• Ter uma string codificada em base64 dentro de um User-Agent é normal ou incomum?
• O uso de seqüências de caracteres base64 dentro de um User-Agent é coberto por quaisquer RFCs ou práticas de grandes fornecedores?

Estou tentando entender o que está acontecendo aqui; Eu não acho que a assinatura WAF esteja completamente fora de linha para objetar, portanto, prefiro não apenas desabilitá-la, mas nunca vi esse tipo de string User-Agent antes, para entender melhor como é comum e / ou legítimo caso de uso.

O site foi projetado para ser usado por humanos com navegadores - não é uma API ou algo parecido - e me foi relatado que o usuário tentou acessar o site com "FF / IE / Chrome" e falhou. No entanto, mostro conexões bem-sucedidas do mesmo IP do cliente com um agente do Opera:

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

É um pouco estranho o fato de o usuário relatar ter tentado o IE, mas todas as sequências User-Agent que vejo parecem ser Linux. (Como de costume, o contato com o usuário final é mediado por várias partes, por isso não posso confiar totalmente em nada que ouço). Também é provável que o IP seja o lado de saída de um proxy da web de classe empresarial, o que explicaria por que vejo alguns Opera trabalhando para alguém enquanto outra pessoa relata problemas do mesmo IP.

Atualizar

Inspirado no exemplo @PlanetScaleNetworks, pesquisei a string no Google e, a partir daí, acabei usando o UA Tracker para procurar por strings base64 (ou o subconjunto delas preenchidas - procurei por "=)"). Ele retornou cerca de 20 User-Agents:

Vou adicionar uma recompensa a essa pergunta, e o espaço de resposta que procuro é "que tipo de software está colocando as seqüências de base64 nos agentes do usuário e por quê? E há algum selo de legitimidade para essa prática?" "

Ponto menor:

O usuário resolveu o nosso problema usando um plug-in do navegador para modificar seu User-Agent, então agora é um problema acadêmico - mas acho que é um problema acadêmico interessante :)

Se todo o outro tráfego desse endereço IP for legítimo, não me preocuparia se a regra WAF fosse acionada. Não decodifica em uma sequência legível por humanos. Por isso, provavelmente foi inserido por um dispositivo proxy para fins de rastreamento.

Com relação à sua preocupação com o RFC, eles são escritos como uma recomendação de como o campo deve ser usado, embora haja pouca consistência entre as plataformas. Dito isto, é um valor definido pelo cliente que não pode ser confiável, pois é trivial modificá-lo. Assim, por que as regras WAF são necessárias.

Há duas áreas nas quais vejo as seqüências User-Agent se tornando uma preocupação:

1. Estouro de buffer - tentando estourar o buffer no servidor ou no site / aplicativo. Isso claramente não está acontecendo no exemplo fornecido.
2. Injeção de script / código - fornecendo scripts em linha, referências a arquivos remotos, etc. Novamente, claramente não se aplica à sua situação.

Se você estiver realmente preocupado / paranóico, altere a string User-Agent do seu próprio sistema para esta e navegue pelas mesmas páginas enquanto usa um proxy como Fiddler, Burp, etc. Cadeia de agente do usuário?

Eu não recomendaria bloquear nenhum endereço IP com base no exemplo fornecido, a menos que todo o tráfego desse IP seja malicioso. Mesmo assim, ele deve ser bloqueado apenas por um tempo limitado. Melhor ainda, crie uma "página da web bloqueada" com detalhes de como ser desbloqueado. Redirecione o tráfego para lá até ser contatado.

Ter uma string codificada em base64 dentro de um User-Agent é normal ou incomum?

Cavando a lista de agentes do usuário no WhichBrowser . É razoável concluir que isso é raro, mas possivelmente o resultado de uma infecção por malware.

No entanto, eu também abusei desse comportamento para adicionar outra camada de segurança ao meu próprio site no passado, onde apenas alguns clientes com um token de base64 UA específico seriam exibidos na página de login. Da mesma forma, essa impressão digital exclusiva também pode ser usada para exibir uma página de ataque ou redirecionar para outro local.

O uso de seqüências de caracteres base64 dentro de um User-Agent é coberto por quaisquer RFCs ou práticas de grandes fornecedores?

Não especificamente. Nada está documentado em nenhuma das informações do fornecedor dos navegadores Gecko. No UA que você forneceu, o base64 não faz parte das informações do produto, mas um comentário. Aparentemente, não há restrições no campo de comentário, embora não seja permitido ter base64 nas informações do produto RFC7231, pois pode ser visto como informações desnecessárias anexadas à string do UA.

É provável que seu WAF não consiga identificar o UA como algo específico e talvez retorne libwww-perlporque o filtro não é específico (falso positivo) e fica muito feliz com o bit Linux / X11, pois não pode entender o comentário base64.

A verificação on-line encontrou essa sequência de agentes do usuário no site closetnoc.org . Este agente de usuário foi identificado como sendo um de uma série que tem sido atribuída a um único endereço IP 192.185.1.20que foi sinalizado como um spammer por list.quorum.to, bl.csma.biz, e spamsources.fabel.dk.

Para bloquear o acesso a esse IP (e por sua vez a esse User-Agent) ...

Usando o firewall CISCO

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

Usando o Nginx

Edite nginx.conf e insira include blockips.conf; se não existir. Edite o arquivo blockips.conf e adicione o seguinte:

deny 192.185.1.20/32;

Usando o Linux IPTables Firewall

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

Usando o servidor Web 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>

Usando o Apache .htaccess

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

Fonte: closetnoc.org

Também estou vendo agentes de usuário codificados com simil-b64. Após algumas análises, verifica-se que são clientes com o antivírus Kaspersky instalado e procurando atualizações.