「第三者」がどのようにクライアントの仕事を妨害しようとしたのか、そしてこの問題がどのように解決されたのかについての素晴らしい話をしましょう。
それがすべて始まった方法
すべては月末の 31 月 XNUMX 日の朝に始まりました。この日、多くの人が緊急かつ重要な問題を解決するためにどうしても時間が必要です。
パートナーの 9 人は、サービスを提供するクライアントの複数の仮想マシンを当社のクラウドに保管していますが、10 時 9 分から 20 時 XNUMX 分にかけて、当社のウクライナのサイトで実行されている複数の Windows サーバーがリモート アクセス サービスへの接続を受け付けなくなり、ユーザーがアクセスできなくなったと報告しました。デスクトップにログインしようとしましたが、数分後には問題が自動的に解決されたように見えました。
通信チャネルの運用に関する統計を収集しましたが、トラフィックの急増や障害は見つかりませんでした。 コンピューティング リソースの負荷に関する統計を調べましたが、異常はありませんでした。 そして、それは何でしたか？
その後、当社のクラウドで約 XNUMX 台以上のサーバーをホストしている別のパートナーが、一部のクライアントが指摘したのと同じ問題を報告しました。その結果、サーバーは全体的にはアクセス可能 (ping テストやその他のリクエストに適切に応答している) であることが判明しました。これらのサーバー上のサービス リモート アクセスは、新しい接続を受け入れるか拒否するかのどちらかであり、私たちは異なるサイト上のサーバー、つまり異なるデータ伝送チャネルからのトラフィックについて話していました。
このトラフィックを見てみましょう。 接続リクエストを含むパケットがサーバーに到着します。
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
サーバーはこのパケットを受信しますが、接続を拒否します。
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
これは、問題の原因がインフラストラクチャの運用上の問題ではなく、明らかに別の原因であることを意味します。 おそらくすべてのユーザーがリモート デスクトップのライセンスに問題を抱えているのではないでしょうか? おそらく、ある種のマルウェアがなんとかシステムに侵入し、数年前と同様に今日それがアクティブ化されたのでしょう。 Xデータ и ペチャ?
問題を整理している間に、さらにいくつかのクライアントやパートナーからも同様のリクエストを受けました。
これらのマシンでは実際に何が起こっているのでしょうか?
イベント ログには、パスワードを推測しようとするメッセージが大量に記録されます。
通常、このような試みは、標準ポート (3389) がリモート アクセス サービスに使用され、どこからでもアクセスが許可されているすべてのサーバーに登録されます。 インターネットには、利用可能なすべての接続ポイントを常にスキャンし、パスワードを推測しようとするボットが溢れています (これが、「123」の代わりに複雑なパスワードを使用することを強く推奨する理由です)。 しかし、その日のこれらの試みの強度はあまりにも高かった。
どうすればいいですか？
膨大な数のエンド ユーザーが別のポートに切り替えるように設定を変更するのに多くの時間を費やすことを顧客に推奨しますか? 良いアイデアではありません。顧客は満足しません。 VPN 経由でのみアクセスを許可することをお勧めしますか? 急いでパニックになり、IPSec 接続を確立していない人のために IPSec 接続を確立する - おそらく、そのような幸福はクライアントにも微笑みかけません。 いずれにせよ、これは神がかり的なことだと言わざるを得ませんが、私たちはサーバーをプライベート ネットワークに隠すことを常に推奨しており、設定を手伝う準備ができています。また、自分で解決したい人のために手順を共有します。サイト間またはロード モードでクラウドに IPSec/L2TP をセットアップする場合は、戦士です。また、自分の Windows サーバーに VPN サービスをセットアップしたい場合は、いつでもセットアップ方法に関するヒントを共有する準備ができています。標準 RAS または OpenVPN。 しかし、私たちがどれほど冷静だったとしても、ユーザーのストレスを最小限に抑えながらできるだけ早く問題を解決する必要があったため、この時期はクライアント間で教育活動を行うのに最適な時期ではありませんでした。
私たちが実装した解決策は次のとおりです。 当社では、ポート 3389 への TCP 接続を確立しようとするすべての試行を監視し、その中から 150 秒以内にネットワーク上の 16 を超える異なるサーバーとの接続を確立しようとするアドレスを選択するような方法で、通過トラフィックの分析を設定しました。 - これらは攻撃のソースです (もちろん、クライアントまたはパートナーの 150 つが同じソースから非常に多くのサーバーとの接続を確立する必要がある場合は、いつでもそのようなソースを「ホワイト リスト」に追加できます。さらに、この 32 秒間に 3 つのクラス C ネットワークで 300 を超えるアドレスが識別された場合、ネットワーク全体をブロックするのが合理的です。ブロックは XNUMX 日間設定されており、この期間中に特定の送信元から攻撃が実行されなかった場合、このソースは「ブラック リスト」から自動的に削除されます。ブロックされたソースのリストは XNUMX 秒ごとに更新されます。
このリストは次のアドレスから入手できます。 に基づいて ACL を構築できます。
私たちはそのようなシステムのソース コードを共有する準備ができています。そこには過度に複雑なものは何もなく (これらは文字通り膝の上で数時間かけてコンパイルされたいくつかの単純なスクリプトです)、同時に適応させて使用することができます。このような攻撃から保護するだけでなく、ネットワークをスキャンしようとする試みを検出してブロックすることもできます。
さらに、監視システムの設定にいくつかの変更を加えました。これにより、RDP 接続を確立しようとするクラウド内の仮想サーバーのコントロール グループの反応がより厳密に監視されるようになりました。第二に、これが注意を払う理由です。
このソリューションは非常に効果的であることが判明しました。クライアントとパートナーの両方から、また監視システムからの苦情はなくなりました。 新しいアドレスとネットワーク全体がブラックリストに定期的に追加されます。これは、攻撃が継続しているものの、クライアントの動作にはもう影響を与えていないことを示しています。
フィールドに戦士はいません
今日、他のオペレーターも同様の問題に遭遇していることが分かりました。 Microsoft がリモート アクセス サービスのコードに何らかの変更を加えたと今でも信じている人がいます (覚えていると思いますが、私たちは初日に同じことを疑ったのですが、すぐにこのバージョンを拒否しました) し、解決策を迅速に見つけるためにあらゆる手段を講じると約束しています。 。 単に問題を無視して、クライアントに自分自身を守るようにアドバイスする人もいます (接続ポートを変更する、プライベート ネットワークにサーバーを隠すなど)。 そして、その初日に、私たちはこの問題を解決しただけでなく、開発を計画している、よりグローバルな脅威検出システムのための基礎も作りました。
沈黙せず、いつか敵の死体が川に流れてくるのを川岸に座って待つのではなく、ただちに私たちの注意をこの問題に向けさせ、私たちに問題を排除する機会を与えてくれたクライアントとパートナーに特に感謝します。それは同じ日に。
出所： habr.com