base64でエンコードされたコンポーネントを持つユーザーエージェント？

（一番下の賞金質問）

私たちのサイトにアクセスするクライアントに問題があります。根本的な原因は、WAF（Web Application Firewall）がユーザーエージェント文字列を好きではないことです。

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

この場合、base64でエンコードされた文字列は、ユーザーエージェントがlibwww-perlであると考えるWAFで誤検知を引き起こしています。base64文字列は、読み取り可能なテキストにデコードされません。

• ユーザーエージェント内にbase64でエンコードされた文字列があるのは正常ですか、それとも異常ですか？
• User-Agent内でのbase64文字列の使用は、RFCまたは主要なベンダーの慣行でカバーされていますか？

ここで何が起こっているのかを理解しようとしています。WAFシグネチャがオブジェクトと完全に一致していないとは思わないので、無効にするだけでなく、この種のユーザーエージェント文字列を見たことがないので、一般的な方法と/またはこれが正当なユースケースです。

このサイトは、人間がブラウザで使用するように設計されており、APIなどではなく、ユーザーが「FF / IE / Chrome」でサイトにアクセスしようとして失敗したと報告されています。ただし、同じクライアントIPからOperaユーザーエージェントを使用して接続が成功したことを示しています。

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

ユーザーがIEを試したと報告するのは少し奇妙ですが、私が目にするすべてのユーザーエージェント文字列はLinuxのようです。（いつものように、エンドユーザーとの連絡は複数の当事者を介して行われるため、聞いたことを完全に信頼することはできません）。また、IPがビジネスクラスのWebプロキシの発信側である可能性もあります。これは、誰かが同じIPから問題を報告しているのに、一部のOperaが誰かのために機能しているのを説明する理由です。

更新

@PlanetScaleNetworksの例に触発されて、文字列をグーグルし、そこからUA Trackerを使用してbase64文字列（または、埋め込まれた文字列のサブセット-「=）」を検索しました）。それは約20のユーザーエージェントを返しました：

私はこの質問に賞金を追加します。私が探している回答スペースは、「どのようなソフトウェアがbase64文字列をUser-Agentに入れているのか、そしてその理由です。そして、この実践には正当性の印がありますか？」 」

マイナーポイント：

ユーザーはブラウザプラグインを使用してユーザーエージェントを変更することで問題を回避しているため、これは学術的な問題ですが、興味深い学術的な問題だと思います:)

このIPアドレスからの他のすべてのトラフィックが正当なものであれば、WAFルールがトリガーされることについて心配する必要はありません。人間が読める文字列にデコードしません。したがって、追跡目的でプロキシデバイスによって挿入された可能性があります。

RFCに関する懸念については、プラットフォーム間の一貫性はほとんどありませんが、フィールドの使用方法に関する推奨事項として書かれています。そうは言っても、それはクライアントが定義する値であり、変更するのは簡単なので信頼できません。したがって、WAFルールが必要な理由。

User-Agent文字列が問題になるのは、2つの領域です。

1. バッファオーバーフロー-サーバーまたはWebサイト/アプリケーション内でバッファをオーバーフローさせようとしています。これは、提供されている例では明らかに発生していません。
2. スクリプト/コードインジェクション-インラインスクリプトの提供、リモートファイルへの参照などを提供します。繰り返しますが、明らかにお客様の状況には適用されません。

本当に心配/パラノイアしている場合は、独自のシステムのUser-Agent文字列をこの文字列に変更し、Fiddler、Burpなどのプロキシを使用しながら同じページを参照してください。リクエスト/レスポンスは、元のユーザーエージェント文字列？

このIPからのすべてのトラフィックが悪意のあるものでない限り、提供された例に基づいてIPアドレスをブロックすることはお勧めしません。それでも、それは限られた時間だけブロックされるべきです。さらに、ブロックを解除する方法の詳細を含む「ブロックされたWebページ」を作成します。連絡があるまでそこにトラフィックをリダイレクトします。

ユーザーエージェント内にbase64でエンコードされた文字列があるのは正常ですか、それとも異常ですか？

WhichBrowserでユーザーエージェントのリストを掘り下げます。これはまれですが、おそらくマルウェア感染の結果であると結論付けるのは妥当です。

ただし、この動作を悪用して、過去に自分のサイトに別のセキュリティレイヤーを追加しました。特定のbase64 UAトークンを持つ少数のクライアントだけがログインページを表示することもありました。同様に、この一意のフィンガープリントは、攻撃ページを提供したり、他の場所にリダイレクトしたりするためにも使用できます。

User-Agent内でのbase64文字列の使用は、RFCまたは主要なベンダーの慣行でカバーされていますか？

特にありません。Geckoブラウザーのベンダー情報には何も文書化されていません。あなたが提供したUAでは、base64は製品情報の一部ではなく、コメントです。RFC7231UA文字列に追加された不要な情報と見なすことができるため、製品情報にbase64を含めることは許可されていませんが、コメントフィールドには制限がないようです。

WAFはUAを特定のものとして識別できず、おそらくlibwww-perlフィルターが不特定（誤検知）であり、base64コメントを理解できないためLinux / X11ビットに満足しすぎるために戻ります。

オンラインでチェックを行うと、サイトclosetnoc.orgでこのユーザーエージェント文字列が見つかりました。このユーザエージェントは、単一のIPアドレスにトレースされている番号の一つであると同定された192.185.1.20ことにより、スパマーとしてフラグが立てられてきたlist.quorum.to、bl.csma.bizとspamsources.fabel.dk。

このIP（さらにはそのユーザーエージェント）へのアクセスをブロックするには...

CISCOファイアウォールの使用

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 Webサーバーの使用

<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でエンコードされたユーザーエージェントも表示されます。分析の結果、Kasperskyアンチウイルスがインストールされ、アップデートを探しているクライアントであることが判明しました。