Rostelecomは、主要なロシアの銀行に対するモノのインターネット攻撃の撃退について報告しています

画像



本日、ロステレコム 、ロシアの5大銀行に対するモノのインターネットボットネット攻撃の反発を発表しました。 攻撃は12月5日にTCP SYN Floodを使用して実行されました。 Rostelecomによると、ピーク負荷は毎秒320万パケットでした。



プロバイダーは、一部のトラフィックがIoTデバイスから生成されたことを除いて、詳細を提供しませんでした。 また、DDoS攻撃の危険性や、モノのインターネットからボットネットを制御するサイバー犯罪者の行動にすでに苦しんでいる人々に関する一般情報も提供されました。 一般に、ロステレコムのプレスリリースでは、回答よりも多くの質問が提起されています。



最初に、会社は攻撃の強度について沈黙していました。 Pyaterochkaからの320万パケットの 数字は印象的です;さらに、SYNフラッド攻撃は実際にはパケット数で測定されます。



SYNフラッド攻撃中に、接続を確立するためのTCP要求が偽のIPアドレスから送信されます。 攻撃されたサーバーはSYN / ACK応答を送信し、SYN-RECEIVED状態に入ります。これは、要求されたパーティからの応答なしで75秒後にのみ削除されます。 同時に、最大SYNパケットサイズは64 KBですが、標準は16 KBの小さいバージョンです。 簡単な計算を使用して、最も可能性の高い51.2 GB / sの攻撃強度を取得します。



同時に、ロステレコムのプレスリリースは、最大1 Tb / s(125 GB / s)の容量を持つヨーロッパの構造および組織に対する攻撃で状況を公然とエスカレートします。



SYN Floodのような攻撃は(2000年代の初めから)長い間知られており、さまざまな成功を収めている攻撃者によって使用されています。 さらに、10年半後のそのような方法の有効性は疑わしい。



今年10月にDNSプロバイダーのDynを立ち上げた有名なMiraiボットネット(およびヨーロッパのRostelecomが言及した攻撃に起因)は、DNS再試行とも呼ばれるUDP攻撃を使用しました。



同時に、匿名を条件とする情報セキュリティの専門家の1人が、ロステレコムのプレスリリースとHabrに対する攻撃についてコメントしました。



Linux 4.7のリリース後、2つのパッチが公開されました。



Add SOCK_RCU_FREE socket flag that UDP sockets and TCP listeners can set so that their lookup can use traditional RCU rules, without refcount changes. The UDP stack is instructed to not use SLAB_DESTROY_BY_RCU, in order to speedup rx processing for traffic encapsulated in UDP; performance for a single UDP socket receiving flood traffic from many RX queues/cpus is increased. TCP listeners are changed to use SOCK_RCU_FREE as well to avoid touching sk_refcnt under synflood. Peak performance under SYNFLOOD is increased by ~33%.







Add rate limiting on ACK sent on behalf of SYN_RECV to better resist to SYNFLOOD targeting one or few flows.







syn / udp floodの並列処理の問題を解決します。つまり、最新のカーネル上の通常のLinuxサーバーであっても、これは問題を引き起こしません。



上記に基づいて、Rostelecomは真の勝利のために不自然な勝利を与え、信頼できるプロバイダーとして企業クライアントの目に「ポイント」を獲得しようとしていると結論付けることができます。



なぜ勝利は大げさなのですか? 次の2つのうちの1つ:Rostelecomはそれを望み、Linuxサーバーが多くの困難と外部からの助けなしに処理したSYN Flood攻撃の試みを単に記録したか、または顧客(銀行!)に旧式の技術ソリューションを提供しますそしてソフトウェアの面で。 このため、半年前にLinuxカーネルレベルで問題が解決されたSYNフラッドを「英雄的に」克服する必要がありました。



All Articles