FreeBSDでK̶D̶E̶TCPスタックにパッチを当てる方法

プロプライエタリソフトウェアとオープンソースソフトウェアのどちらを選択するかについては、後者を支持して次のような議論がしばしば行われます。必要に応じて、ベンダーの反応を数か月待つのではなく、プロジェクトのニーズに合わせてソースコードを変更したり、エラーをすぐに修正したりできます。 多くの場合、この考慮事項は実践とは異なります。SQLスケジューラを最適化するよりも、SQLクエリを修正するか、ドライバーのエラーを探して修正する代わりに問題のある機器を変更するよりもはるかに簡単です。 ただし、場合によっては、潜在的な損失とコンピューティングリソースの浪費を回避するのは、コードのオープン性だけです。 Advanced Hostingに在籍中に発生したこれらのケースの1つについてお話したい

トラフィックの急増とDDoSの最初の疑い

土曜日の夕方遅くに、サーバーの1つがダウンしました。 このプロジェクトのクラスター全体は3 + 3個で構成され、それぞれが3個の負荷全体をプルするため、1個の損失がサービスを脅かすことはありませんでした。 しかし、サーバーがこれまで毎秒10 + Kのhttp-requestsの総着信トラフィックを静かに受け入れており、パフォーマンスに多少のマージンがあるように思えたため、サーバーが突然それほど安定していないことが非常に不快でした。 RAID1が再構築され、PostgreSQLがレプリケーションに追いついている間、サーバーの残りの部分を見る時間がありました。



このクラスターがどのように機能するかを事前に説明する価値があります。 サーバーは、ヨーロッパの2つと米国の4つの異なる場所にあります。 それらはトリプルに分割され、IPグループにサービスを提供します（つまり、トリプルごとにヨーロッパの1つのサーバーとアメリカの2つのサーバー）。 トラフィックはエニーキャスト手段によって配信されます-3つのサーバーすべてに同じIPアドレスが登録され、直接ルーターとのBGPセッションが発生します。 サーバーがダウンした場合、対応するルーターはインターネット上のネットワークのアナウンスを停止し、トラフィックは自動的に残りのサーバーに送られます。



見るものは何もありませんでした。 監視データによると、秋の直前に、両方のヨーロッパのサーバーへの着信および発信トラフィックが急増し（そのうちの1つがダウンしました）、帯域幅が2倍になった場合、1秒あたりのパケット数はすでに10倍に増加し、双方向になりました。 つまり パッケージは小さく、多数（毎秒200K未満）でした。



HighLoadサービスでは、特にそのようなサイズでは、トラフィックは変化しません。 DDoSによく似ていますよね？ 言うまでもなく、多くの異なる種類のDDoSを見る必要があったことは非常に驚きでしたが、これまでのところ、プロバイダーのネットワーク機器がサーバーへの損失なくトラフィックを配信することを許可した場合、それらは常にそれらをブロックすることができました。 トラフィックの急増はヨーロッパのサーバーでのみ発生したことを警告していました。結局、ボットネットが分散されている場合、トラフィックはクラスター全体に分散されるはずです。

パケット損失とアクティブなTCPセッションの増加

サーバーを稼働させた後、「top」、「nload」を起動し、負荷の監視を開始しました。 まもなく、トラフィックは再び倍増し、sshセッションは大幅に遅れ始めました。 パケット損失があり、「mtr -ni 0.1 8.8.8.8」はこの仮説を即座に確認し、「top -SH」はOSのコアは着信ネットワークパケットのプロセッサに十分なCPUがないことであることを示しました。 さて、今ではサーバーが凍結されている理由が明らかです-パケット損失は死に似ています。



この投稿を書いている時点で、FreeBSDにはネットワークスタックに非常に不愉快な機能が1つありました。TCPセッションの数に関しては十分に拡張できません。 TCPセッションの数を数倍に増やすと、CPU消費が不均衡に大きくなります。 セッションはほとんどありませんが、問題はありません。 しかし、数万のアクティブなTCPセッションから始まる着信パケットハンドラーは、CPU不足を経験し始め、パケットをドロップする必要があります。 そして、これは連鎖反応につながります-パケット損失により、アクティブなTCPセッションはゆっくりと処理され始め、そこでセッション数が増加し始め、それによりCPU不足が増加し、パケット損失レベルがさらに上昇します。



サーバーが完全にハングしているわけではありませんが、私は緊急にBGPセッションを終了し、並行して、ヨーロッパのトラフィックを引き継いだサーバーでパケット損失チェックを実行します。 それはより強力な鉄を持っています-つまり アメリカでは何も悪いことが起こらない可能性があります。 問題のあるサーバーで何かを行う必要があります。HTTPキープアライブをオフにする最初のことは、TCPセッションが早く開始され、合計で少なくなることです。 ネットワークカードの設定の調整には数十分かかり、毎回BGPセッションを一時的に上げることでパケット損失を確認しました-ポーリングモードを終了する必要がありますが、idlepollをアクティブにしました-現在、プロセッサの1つのコアがネットワークカードによって占有されていますが、パケット損失は停止しました。



理解できない瞬間がまだありました-たとえば、攻撃中および通常の動作モードでのTCPセッションの数はそれほど変わりませんでした。つまり、問題はその数の大幅な増加ではありませんでした。 しかし、完全に理解不能なのは、この攻撃がアメリカのサーバーでまったく見えなかった理由です！ ヨーロッパのサーバーの切断中、実際の稼働トラフィックのみがShtatovskieサーバーに到達しましたが、追加のトラフィックはありませんでした！ しかし、ヨーロッパにトラフィックが戻った後、しばらくの間作業レベルにとどまり、その後、別の急増が始まりました。



朝の1時でしたが、パケット損失が停止したように思われ、これらのネットワークの異常に新鮮な心で対処できます。 そのような考えで、私はベッドに戻りましたが、数時間後に再び目が覚めました-今回は両方のヨーロッパのサーバーがすでに嘘をついていました。 これは、このケースの財務に別の奇妙さをもたらしました-時間がすでに遅れており、ピークトラフィックがかなり遅れていたためです。 ただし、DDoS攻撃に関しては、これは正常です。ほとんどの専門家が眠って攻撃に従事しているため、原則として、誰も攻撃しません。 すぐに両方のサーバーが起動されましたが、その後の状況の監視では何も新しいものは得られませんでした。その日の攻撃は繰り返されませんでした。

短期的な解決策

日曜日に私は少し仕事をしなければなりませんでした。 別のスクリプトがTCPセッションの数を既に監視しており、負荷が増加した場合にトラフィックを一時的に削除（つまり、トラフィックを状態に転送）して、結果として生じる損害を減らしました。 これまでのところ、米国のサーバーは問題なく機能しましたが、それでもこのトラフィックに対処し、ブロックする方法を学ぶ必要がありました。 httpログに異常はなく、netstatなどのユーティリティも疑わしいものは何もありませんでした。 ただし、ネットワークカードのトラフィックが増加している場合は、tcpdumpを使用して調査できます。



大量のネットワークパケットダンプをスクロールするのは難しい場合がありますが、今回は長い間検索する必要はありませんでした。通常のHTTP / HTTPS交換では、異常に多くの空のTCPパケットが表示されました。 IPおよびTCPヘッダーは正しいが、データはない正当なパケット。 HTTPがオフの場合、キープアライブの空のパケットはすでに多数です。接続を確立するために空の3つ、次に2つのデータ交換パケット（要求/応答）、そして再び空のパケットが接続を閉じます。 さらに、HTTPSを使用する場合、TLSセッションをセットアップするためのデータパケットもあります。



個々のTCPセッションの選択テストにより、一部のセッションでは実際に空のTCPパケットの非常に激しい交換が行われることが示されました。 これらのセッションのほとんどすべてがインドからのものでした！ クウェートとサウジアラビアが少しありました。 どんなunningなボットネットであるかを言うのは難しいですが、まだありません。 私は、毎秒3万パケットごとにtcpdumpを実行し、空のパケットの連続的な交換の数が指定された制限を超え、見つかったIPがすぐにブロックされるセッションを探す2番目の簡単なスクリプトを書いています。 結果はそれほど長くはありませんでした-5つのIPトラフィックのみをブロックすると、すぐに2回ドロップします。 毎分、1つまたは2つの新しいIPがブロックされました。 勝利！

症状分析と問題の特定

Advanced Hostingの同僚とこのケースについて議論した後、すべてがそれほどバラ色ではないことが判明しました。 第一に、新しいIPのブロッキング強度が増大していました-すでにトラフィックのピーク時に、ブロッキング速度は毎分数十個に達しました。 第二に、これらのサーバーだけでなく、他の多くのサーバーや他のクライアントも影響を受けました。 通常、ヨーロッパのすべてとFreeBSDのすべて。 これはDDOS攻撃ではないことが明らかになりました。



ブロックされたIPを解放する必要があり、TCPセッション自体をブロックする代わりに、現在ドロップしていました（FreeBSDには、このためのtcpdropユーティリティがあります）。 また、負荷を効果的に制御し、HTTPキープアライブを有効にしました。



再びtcpdumpを選択して、トラフィックをさらに調べる必要があります。 データの異常やパターンの検索に費やされた時間については詳しく説明しません。 TCPセッションは異なっていました。 完全に空でしたが、データ交換もあり、空のパケットを交換するサイクルに入りました。



しかし、手がかりがありました。 空のパケット交換サイクルを離れる前に、FINパケットがリモート側から来ました（FINフラグが付いたパケットはデータがなくセッションを閉じる必要があることを通知します）、時には1つではありませんが、RSTパケットも発生しました（RSTフラグが付いたパケットはセッションを示します既に閉鎖されており、有効ではありません）。



興味深いことに、FINおよびRSTパケットが存在するにもかかわらず、データパケットがサーバーに届くことがありました。 TCPスタックが非常に曲がりくねって実装されている可能性が低いか、TCPセッションに大まかな介入が行われている場所のいずれかですが、これはすでにかなりありそうです（特にモバイルオペレーターはこれにふけるのが好きなので、指をさしません）。 2番目のバージョンは、検出された悪意のあるTCPセッションのhttp-logチェックにより、それらのほとんどすべてにAndroidとiOSの両方のモバイルブラウザーがあることが示されたという事実によっても確認されました。



FINまたはRSTパケットがTCPセッションを閉じた状態にし、TCPスタックがパケットの受信を単純に確認したと仮定することは論理的でした。 どのTCP状態が面白かった



これがその動作です。tcpdropを呼び出す前に、netstat -anの出力に削除されたTCPセッションの検索を追加しました。 結果は少しがっかりさせられました-それらはすべて確立されました！ これはすでに非常にバグに似ていました-閉じられたTCPセッションはESTABLISHED状態に戻ることができません。このオプションは提供されていません。 私はすぐにソースとカーネルのチェックを開始し、二度と落胆させられました。

 tp->t_state = TCPS_ESTABLISHED
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはコードで正確に2回呼び出され、この直前に両方とも現在のt_state値がチェックされます-1つの場合はTCPS_SYN_SENT（サーバーはSYNパケットを送信して確認を受信）に等しく、2番目はTCPS_SYN_RECEIVED（サーバーがSYNを受信し、SYN / ACKを送信して受信します） ACKの確認）。 これからの結論は非常に具体的です-FINとRSTパケットはサーバーによって無視され、TCPスタックにバグはありません（少なくとも、ある状態から別の状態への誤った遷移を伴うバグがあります）。



それでも、サーバーが受信したすべてのTCPパケットに応答する必要がある理由は明らかではありませんでした。 通常、これは不要であり、TCPスタックの動作は異なります。複数のパケットを受信し、一度に1つのパケット確認を送信します-これはより経済的です。 パケットの内容、特に32ビットTCPカウンターの注意深い調査-シーケンス（SEQ）および肯定応答（ACK）は、状況を明らかにするのに役立ちました。 tcpdumpのデフォルトの動作-絶対値の代わりにパケット間のseq / ackの違いを表示する-この場合、悪いサービスを果たしました。



16:03:21.931367 IP (tos 0x28, ttl 47, id 44771, offset 0, flags [DF], proto TCP (6), length 60)

46.153.19.182.54645 > 88.208.9.111.80: Flags [S], cksum 0x181c (correct), seq 3834615051, win 65535, options [mss 1460,sackOK,TS val 932840 ecr 0,nop,wscale 6], length 0

16:03:21.931387 IP (tos 0x0, ttl 64, id 1432, offset 0, flags [DF], proto TCP (6), length 60)

88.208.9.111.80 > 46.153.19.182.54645: Flags [S.], cksum 0xa4bc (incorrect -> 0xf9a4), seq 1594895211, ack 3834615052, win 8192, options [mss 1460,nop,wscale 6,sackOK,TS val 2509954639 ecr 932840], length 0

16:03:22.049434 IP (tos 0x28, ttl 47, id 44772, offset 0, flags [DF], proto TCP (6), length 52)

46.153.19.182.54645 > 88.208.9.111.80: Flags [.], cksum 0x430b (correct), seq 3834615052, ack 1594895212, win 1369, options [nop,nop,TS val 932852 ecr 2509954639], length 0

16:03:22.053697 IP (tos 0x28, ttl 47, id 44773, offset 0, flags [DF], proto TCP (6), length 40)

46.153.19.182.54645 > 88.208.9.111.80: Flags [R], cksum 0x93ba (correct), seq 211128292, win 1369, length 0

16:03:22.059913 IP (tos 0x28, ttl 48, id 0, offset 0, flags [DF], proto TCP (6), length 40)

46.153.19.182.54645 > 88.208.9.111.80: Flags [R.], cksum 0xa03f (correct), seq 0, ack 1594897965, win 0, length 0

16:03:22.060700 IP (tos 0x28, ttl 47, id 44774, offset 0, flags [DF], proto TCP (6), length 52)

46.153.19.182.54645 > 88.208.9.111.80: Flags [.], cksum 0x3a48 (correct), seq 3834615953, ack 1594896512, win 1410, options [nop,nop,TS val 932853 ecr 2509954639], length 0

16:03:22.060706 IP (tos 0x0, ttl 64, id 3974, offset 0, flags [DF], proto TCP (6), length 52)

88.208.9.111.80 > 46.153.19.182.54645: Flags [.], cksum 0xa4b4 (incorrect -> 0x475c), seq 1594895212, ack 3834615052, win 135, options [nop,nop,TS val 2509954768 ecr 932852], length 0







絶対値を詳しく調べます。 最初のパケットには、サーバーへの応答としてseq 3834615051が含まれ、パケットseq 1594895211が送信されました。ack3834615052（out-ack goes in-seq + 1）。



その後、いくつかのRSTパケットが来ましたが、それらは私たちにとっては面白くないものです。



しかし、次のパケットには興味深いものがあります。番号seq 3834615953、ack 1594896512が含まれます。これらの番号は両方とも初期seq / ackよりもかなり大きいため、リモート側はすでに3834615953-3834615052 = 901バイトを送信し、さらに1594896512-1594895212を取得することができました= 1300バイト。



もちろん、これらのデータパケットは表示されず、表示されません-この交換はMiTMシステムで行われました。 しかし、サーバーはこれを知りません。 彼はseq 3834615953のパケットを見て、したがって901バイトのデータを受信しなかったと結論付け、したがって彼がseq 1594895212、ack 3834615052であると知っている最後の有効なseq / ack番号を持つパケットを送り返します。順番に、彼女はすべてが正常であると報告し、1300バイトのデータが正常に受信されました。 ここにループがあります。



また、米国のサーバーがこのトラフィックを認識しなかった理由も明らかになりました。実際はそうですが、インドからアメリカへのpingがインドからヨーロッパへのpingよりも大きかったのです。

最終パッチ

実際、このバグを修正する方法を見つけることは残っています。 再びソースコードを取得します。興味のあるコードはtcp_input.cファイルにあります。 tcp_input（）関数がTCPパケットのプライマリ処理に関与しているため、難しくありませんでした。 関数アルゴリズムは、パケットがすべてのチェックに合格し、TCP接続がESTABLISHED状態になったときに、最後に処理するためにtcp_do_segment（）関数に送信されるように配置されます。



もう1つチェックを追加する必要があります-相手側からのackカウンターが、サーバーが送信しなかったデータを受信したことを示している場合、パケットを無視する必要があります。 すぐに接続を切断することはできません-そうしないと、攻撃者に対して他の人のTCP接続を終了する簡単な方法を提供します。



パッチをテストすると、ack値がゼロのパケットもTCPトラフィックに存在することが示されました。それらを無視する必要はなくなりました。 最後のパッチは3行でした（コメントを除く）：

 + if(SEQ_GT(th->th_ack, tp->snd_max) && th->th_ack != 0) { + goto dropunlock; + }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PR（問題報告）が同じ日に FreeBSD開発者に送られました 。



PS LinuxとWindowsの状況はどうですか？ そこではすべて問題ありません。そのようなパッケージは無視されます（テスト済みのWindows 10およびLinux 3.10）。