作業ラウンドを引き起こす脆弱性に注意してください。 パート 1: フラグメントスマック/セグメントスマック

こんにちは、みんな！ 私の名前はドミトリー・サムソノフです。Odnoklassniki で主任システム管理者として働いています。 当社には 7 台を超える物理サーバー、クラウド内に 11 個のコンテナー、および 200 個のアプリケーションがあり、さまざまな構成で 700 個の異なるクラスターを形成しています。 大多数のサーバーは CentOS 7 を実行しています。
14 年 2018 月 XNUMX 日に、FragmentSmack の脆弱性に関する情報が公開されました。
(CVE-2018-5391) およびセグメントスマック (CVE-2018-5390）。 これらはネットワーク攻撃ベクトルを持ち、かなり高いスコア (7.5) を持つ脆弱性であり、リソース枯渇 (CPU) によるサービス妨害 (DoS) の脅威となります。 FragmentSmack のカーネル修正はその時点では提案されておらず、さらに、脆弱性に関する情報が公開されるよりもずっと後に発表されました。 SegmentSmack を排除するには、カーネルを更新することが提案されています。 アップデートパッケージ自体も同日にリリースされたので、あとはインストールするだけだった。
いいえ、カーネルのアップデートにまったく反対しているわけではありません。 ただし、ニュアンスもあります...

本番環境でカーネルを更新する方法

一般に、複雑なことは何もありません。

1. パッケージをダウンロードします。
2. これらを多数のサーバー (クラウドをホストしているサーバーを含む) にインストールします。
3. 何も壊れていないことを確認してください。
4. すべての標準カーネル設定がエラーなく適用されていることを確認してください。
5. 数日待ってください。
6. サーバーのパフォーマンスを確認します。
7. 新しいサーバーの展開を新しいカーネルに切り替えます。
8. データセンターごとにすべてのサーバーを更新します (問題が発生した場合にユーザーへの影響を最小限に抑えるために、一度に XNUMX つのデータセンター)。
9. すべてのサーバーを再起動します。

カーネルのすべてのブランチに対してこれを繰り返します。 現時点では次のとおりです。

• 標準版 CentOS 7 3.10 - ほとんどの通常のサーバー用。
• Vanilla 4.19 - 私たちのために 一つの雲、BFQ、BBRなどが必要なため。
• Elrepo kernel-ml 5.2 - 用 高負荷のディストリビュータ4.19 は動作が不安定だったためですが、同じ機能が必要です。

ご想像のとおり、何千台ものサーバーを再起動するには最も時間がかかります。 すべての脆弱性がすべてのサーバーにとって重大なわけではないため、インターネットから直接アクセスできる脆弱性のみを再起動します。 クラウドでは、柔軟性を制限しないように、外部からアクセス可能なコンテナを新しいカーネルを備えた個々のサーバーに関連付けず、例外なくすべてのホストを再起動します。 幸いなことに、その手順は通常のサーバーよりも簡単です。 たとえば、ステートレス コンテナは、再起動中に別のサーバーに簡単に移動できます。

ただし、まだ多くの作業があり、数週間、新しいバージョンに問題がある場合は最大で数か月かかる場合があります。 攻撃者はこのことをよく理解しているため、プラン B が必要です。

フラグメントスマック/セグメントスマック。 回避策

幸いなことに、一部の脆弱性については、そのようなプラン「B」が存在し、それは回避策と呼ばれます。 ほとんどの場合、これはカーネル/アプリケーション設定の変更であり、起こり得る影響を最小限に抑えたり、脆弱性の悪用を完全に排除したりできます。

FragmentSmack/SegmentSmackの場合 提案されました 次のような回避策:

«net.ipv4.ipfrag_high_thresh および net.ipv3.ipfrag_low_thresh (および ipv4 net.ipv4.ipfrag_high_thresh および net.ipv6.ipfrag_low_thresh の対応するもの) のデフォルト値 6MB および 6MB を、それぞれ 256 KB および 192 KB に変更できます。より低い。 テストでは、ハードウェア、設定、条件に応じて、攻撃中に CPU 使用率が小規模から大幅に低下することが示されています。 ただし、一度に再アセンブリ キューに収まるのは 262144 つの 64K フラグメントのみであるため、ipfrag_high_thresh=XNUMX バイトにより、パフォーマンスに多少の影響が生じる可能性があります。 たとえば、大きな UDP パケットを扱うアプリケーションが壊れるリスクがあります。'。

パラメータ自体 カーネルのドキュメントにある 次のように説明されています。

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

本番サービスには大規模な UDP がありません。 LAN 上には断片化されたトラフィックはありません。WAN 上には断片化されたトラフィックがありますが、重大ではありません。 兆候はありません - 回避策を展開できます。

フラグメントスマック/セグメントスマック。 最初の血

私たちが遭遇した最初の問題は、クラウド コンテナーが新しい設定を部分的にのみ (ipfrag_low_thresh のみ) 適用する場合と、まったく適用しない場合があり、単に開始時にクラッシュするということでした。 問題を安定して再現することはできませんでした (すべての設定は手動で問題なく適用されました)。 コンテナが開始時にクラッシュする理由を理解するのも、それほど簡単ではありません。エラーは見つからなかったのです。 XNUMX つ確かなことは、設定をロールバックすると、コンテナーのクラッシュの問題が解決されるということです。

ホストに Sysctl を適用するだけでは不十分なのはなぜですか? コンテナは独自の専用ネットワーク名前空間に存在するため、少なくとも ネットワーク Sysctl パラメータの一部 コンテナ内の内容はホストとは異なる場合があります。

Sysctl 設定はコンテナにどのように正確に適用されますか? 私たちのコンテナには特権がないため、コンテナ自体にアクセスして Sysctl 設定を変更することはできません。単に十分な権限がないだけです。 コンテナを実行するために、当時のクラウドでは Docker を使用していました (現在は ポッドマン）。 新しいコンテナのパラメータは、必要な Sysctl 設定を含め、API 経由で Docker に渡されました。
バージョンを調べたところ、Docker API がすべてのエラーを返していないことが判明しました (少なくともバージョン 1.10)。 「docker run」経由でコンテナを起動しようとすると、最終的に少なくとも何かが見えました。

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

パラメータ値が無効です。 しかし、なぜ？ そして、なぜそれが時々のみ有効ではないのでしょうか? Docker は Sysctl パラメーターが適用される順序を保証していないことが判明しました (最新のテスト済みバージョンは 1.13.1)。そのため、ipfrag_low_thresh がまだ 256M、つまり上限が低いときに ipfrag_high_thresh を 3K に設定しようとすることがありました。下限を下回ったため、エラーが発生しました。

その時点で、起動後にコンテナを再構成するための独自のメカニズム (起動後にコンテナをフリーズする) をすでに使用していました。 グループ冷凍庫 そして、コンテナの名前空間でコマンドを実行します。 IPネット)、この部分に Sysctl パラメーターの書き込みも追加しました。 問題は解決しました。

フラグメントスマック/セグメントスマック。 ファーストブラッド2

クラウドでの Workaround の使用法を理解する前に、まれにユーザーから最初の苦情が届き始めました。 その時点で、最初のサーバーで Workaround の使用を開始してから数週間が経過していました。 初期調査では、苦情は個々のサービスに対して受け取られたものであり、これらのサービスのすべてのサーバーに対して受け取られたわけではないことが判明しました。 問題は再び極めて不確実なものとなった。

もちろん、まず第一に、Sysctl 設定をロールバックしようとしましたが、効果はありませんでした。 サーバーやアプリケーションの設定をさまざまに操作しても役に立ちませんでした。 再起動が役に立ちました。 Linux を再起動するのは、昔の Windows では普通だったのと同じくらい不自然です。 しかし、それは役に立ったので、Sysctl で新しい設定を適用するときの「カーネルの不具合」であると考えました。 なんて軽薄だったんだろう…。

504週間後、問題が再発しました。 これらのサーバーの構成は非常に単純で、プロキシ/バランサー モードの Nginx でした。 交通量はあまり多くありません。 新しい導入メモ: クライアント上の XNUMX エラーの数は毎日増加しています (ゲートウェイタイムアウト）。 グラフは、このサービスの 504 日あたりの XNUMX エラーの数を示しています。

すべてのエラーは同じバックエンド、つまりクラウド内にあるバックエンドに関するものです。 このバックエンドのパッケージ フラグメントのメモリ消費量グラフは次のようになります。

これは、オペレーティング システムのグラフの問題の最も明白な兆候の XNUMX つです。 クラウドでは、ちょうど同時に、QoS (トラフィック制御) 設定に関する別のネットワーク問題が修正されました。 パケット フラグメントのメモリ消費量のグラフでは、まったく同じように見えました。

仮定は単純で、グラフ上で同じように見える場合は、同じ理由があるということです。 さらに、このタイプのメモリに関する問題は非常にまれです。

修正された問題の本質は、QoS のデフォルト設定で fq パケット スケジューラを使用したことでした。 デフォルトでは、100 つの接続に対して XNUMX パケットをキューに追加できますが、チャネル不足の状況では、一部の接続がキューの容量を詰まらせ始めました。 この場合、パケットはドロップされます。 tc 統計 (tc -s qdisc) では、次のように表示されます。

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

「464545 flows_plimit」は、464545 つの接続のキュー制限を超えたためにドロップされたパケットであり、「dropped 1」は、このスケジューラのすべてのドロップされたパケットの合計です。 キューの長さを XNUMX に増やしてコンテナーを再起動すると、問題は発生しなくなりました。 座ってスムージーを飲むこともできます。

フラグメントスマック/セグメントスマック。 ラストブラッド

まず、カーネルの脆弱性の発表から数か月後、ついに FragmentSmack の修正版が登場しました (7.5 月の発表と同時に、SegmentSmack のみの修正版もリリースされました)。これにより、回避策を放棄する機会が与えられました。それは私たちに多大な迷惑をかけました。 この間、すでに一部のサーバーを新しいカーネルに移行することに成功していましたが、今度は最初からやり直す必要がありました。 FragmentSmack の修正を待たずにカーネルを更新したのはなぜですか? 実際、これらの脆弱性から保護するプロセスは、CentOS 自体の更新プロセスと同時 (および統合) されています (カーネルのみを更新するよりもさらに時間がかかります)。 さらに、SegmentSmack はより危険な脆弱性であり、その修正はすぐに公開されたため、いずれにせよ理にかなっていました。 ただし、CentOS 7.6 のときに発生した FragmentSmack の脆弱性はバージョン 7.5 でのみ修正されたため、CentOS 上のカーネルを単純に更新することはできませんでした。そのため、7.6 への更新を中止し、XNUMX への更新からやり直す必要がありました。 そして、これも起こります。

第二に、まれにユーザーから問題に関する苦情が戻ってくることがあります。 これらはすべて、クライアントから一部のサーバーへのファイルのアップロードに関連していることはすでにわかっています。 さらに、これらのサーバーを経由したアップロードは、全体のうち非常に少数でした。

上記の話から覚えているように、Sysctl をロールバックしても役に立ちませんでした。 再起動は役に立ちましたが、一時的でした。
Sysctlに関する疑惑は払拭できなかったが、今回は可能な限りの情報を収集する必要があった。 また、何が起こっているのかをより正確に調査するために、クライアント上でアップロードの問題を再現する能力も大幅に不足していました。

入手可能なすべての統計とログを分析しても、何が起こっているのかを理解することはできませんでした。 特定のつながりを「感じる」ために問題を再現する能力が著しく欠如していました。 最後に、開発者は特別なバージョンのアプリケーションを使用して、Wi-Fi 経由で接続したテスト デバイス上で問題を安定して再現することに成功しました。 これは調査における画期的な出来事でした。 クライアントは Nginx に接続し、バックエンド (Java アプリケーション) にプロキシしました。

問題に関するダイアログは次のとおりです (Nginx プロキシ側で修正されました)。

1. クライアント: ファイルのダウンロードに関する情報の受信を要求します。
2. Java サーバー: 応答。
3. クライアント: ファイル付きで POST。
4. Java サーバー: エラー。

同時に、Java サーバーはクライアントから受信したデータが 0 バイトであることをログに書き込み、Nginx プロキシはリクエストに 30 秒以上かかったことが書き込みます (30 秒はクライアント アプリケーションのタイムアウトです)。 なぜタイムアウトになり、なぜ 0 バイトになるのでしょうか? HTTP の観点から見ると、すべてが正常に機能しますが、ファイルを含む POST がネットワークから消えているように見えます。 しかもクライアントとNginxの間では消滅してしまいます。 Tcpdump を使用して武装する時期が来ました。 ただし、最初にネットワーク構成を理解する必要があります。 Nginx プロキシは L3 バランサーの背後にあります NFウェア。 トンネリングは、L3 バランサーからサーバーにパケットを配信するために使用され、サーバーはパケットにヘッダーを追加します。

この場合、ネットワークは Vlan タグ付きトラフィックの形式でこのサーバーに到達し、独自のフィールドもパケットに追加します。

また、このトラフィックは断片化することもできます (回避策のリスクを評価するときに説明した、断片化された受信トラフィックのごく一部と同じです)。これにより、ヘッダーの内容も変更されます。

繰り返しになりますが、パケットは Vlan タグでカプセル化され、トンネルでカプセル化され、断片化されます。 これがどのように起こるかをよりよく理解するために、クライアントから Nginx プロキシまでのパケット ルートを追跡してみましょう。

1. パケットは L3 バランサーに到達します。 データセンター内で正しいルーティングを行うために、パケットはトンネル内にカプセル化され、ネットワーク カードに送信されます。
2. パケット + トンネル ヘッダーは MTU に収まらないため、パケットはフラグメントに分割されてネットワークに送信されます。
3. L3 バランサ以降のスイッチはパケットを受信すると、Vlan タグを付加して送信します。
4. Nginx プロキシの前にあるスイッチは、(ポート設定に基づいて) サーバーが Vlan でカプセル化されたパケットを予期していることを認識するため、Vlan タグを削除せずにそのまま送信します。
5. Linux は、個々のパッケージの断片を取得し、それらを XNUMX つの大きなパッケージにマージします。
6. 次に、パケットは Vlan インターフェイスに到達し、最初の層 (Vlan カプセル化) が削除されます。
7. Linux はそれをトンネル インターフェイスに送信し、そこで別の層 (トンネル カプセル化) が削除されます。

難しいのは、これらすべてをパラメータとして tcpdump に渡すことです。
最後から始めましょう。VLAN とトンネルのカプセル化が削除された、クライアントからのクリーンな (不要なヘッダーのない) IP パケットはありますか?

tcpdump host <ip клиента>

いいえ、サーバー上にそのようなパッケージはありませんでした。 したがって、問題はもっと前に存在しているはずです。 Vlanカプセル化のみが解除されたパケットはありますか?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx は、XNUMX 進数形式のクライアント IP アドレスです。
32:4 — トンネル パケット内の SCR IP が書き込まれるフィールドのアドレスと長さ。

インターネット上では 40、44、50、54 と書かれていますが、そこには IP アドレスがなかったため、フィールド アドレスは総当たりで選択する必要がありました。 また、XNUMX 進数のパケット (tcpdump の -xx または -XX パラメーター) を調べて、既知の IP アドレスを計算することもできます。

VLAN とトンネルのカプセル化が削除されていないパケット フラグメントはありますか?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

この魔法は、最後のものを含むすべての断片を表示します。 おそらく、同じものを IP でフィルタリングできると思いますが、そのようなパケットはそれほど多くなく、必要なパケットは一般的なフローで簡単に見つけられるため、試しませんでした。 どうぞ：

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

これらは、写真付きの 53652 つのパッケージ (同じ ID XNUMX) の XNUMX つの断片です (Exif という単語は最初のパッケージに表示されます)。 このレベルのパッケージは存在するが、ダンプ内にマージされた形式ではないという事実により、問題は明らかにアセンブリにあります。 ついにこれを証明する文書が登場しました！

パケット デコーダでは、ビルドを妨げるような問題は検出されませんでした。 ここで試してみました: hpd.gasmi.net。 まず、そこに何かを詰め込もうとすると、デコーダはそのパケット形式を好みません。 Srcmac と Ethertype の間に余分な XNUMX オクテットがあることが判明しました (フラグメント情報とは関係ありません)。 それらを削除すると、デコーダーが動作し始めました。 しかし、問題はありませんでした。
何と言っても、これらの Sysctl 以外には何も見つかりませんでした。 あとは、規模を理解し、さらなるアクションを決定するために、問題のあるサーバーを特定する方法を見つけるだけでした。 必要なカウンターはすぐに見つかりました。

netstat -s | grep "packet reassembles failed”

これは、snmpd の OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

「IP 再構成アルゴリズムによって検出された障害の数 (何らかの理由: タイムアウト、エラーなど)。」

問題が調査されたサーバーのグループのうち、このカウンタは XNUMX 台では速く増加し、XNUMX 台では遅くなり、XNUMX 台ではまったく増加しませんでした。 このカウンターのダイナミクスを Java サーバー上の HTTP エラーのダイナミクスと比較すると、相関関係が明らかになりました。 つまり、メーターを監視することができます。

Sysctl のロールバックが役立つかどうかを正確に判断できるように、問題の信頼できる指標を用意することは非常に重要です。これは、前の話から、アプリケーションからはこれをすぐに理解できないことがわかっているからです。 この指標を使用すると、ユーザーが発見する前に、本番環境におけるすべての問題領域を特定できるようになります。
Sysctl をロールバックした後、監視エラーが停止したため、問題の原因が証明され、ロールバックが役立つという事実も判明しました。

他のサーバーのフラグメンテーション設定をロールバックし、そこで新しい監視が機能し、以前のデフォルトよりもさらに多くのメモリをフラグメントに割り当てました (これは UDP 統計であり、一般的な背景に対して部分的な損失は目立ちませんでした)。 。

最も重要な質問

L3 バランサーでパケットが断片化されるのはなぜですか? ユーザーからバランサーに到着するパケットのほとんどは SYN と ACK です。 これらのパッケージのサイズは小さいです。 しかし、そのようなパケットの割合が非常に大きいため、それらを背景に、断片化し始めた大きなパケットの存在に気づきませんでした。

原因は構成スクリプトの破損でした advmss VLAN インターフェイスを備えたサーバー上で実行できます (当時の実稼働環境では、タグ付きトラフィックを備えたサーバーはほとんどありませんでした)。 Advmss を使用すると、トンネル ヘッダーをパケットに付加した後に断片化する必要がないように、こちらの方向のパケットのサイズを小さくする必要があるという情報をクライアントに伝えることができます。

Sysctl のロールバックでは解決せず、再起動では解決したのはなぜですか? Sysctl をロールバックすると、パッケージのマージに使用できるメモリの量が変更されました。 同時に、明らかにフラグメントのメモリ オーバーフロー自体が接続の速度低下を引き起こし、その結果、フラグメントがキュー内で長時間遅延することになりました。 つまり、プロセスはサイクルで行われました。
再起動するとメモリがクリアされ、すべてが正常に戻りました。

回避策なしで実行できましたか? はい、ただし、攻撃が発生した場合にユーザーがサービスを受けられなくなるリスクが高くなります。 もちろん、回避策の使用により、ユーザー向けサービスの XNUMX つが遅くなるなど、さまざまな問題が発生しましたが、それでも、その措置は正当なものだったと考えています。

Andrey Timofeev に感謝します (アティモフェエフ）捜査の実施に協力していただいたほか、アレクセイ・クレネフ（デバイスx) - サーバー上の Centos とカーネルを更新するという大規模な作業用。 この場合、プロセスを最初から何度も開始する必要があったため、何ヶ月もかかりました。

出所： habr.com