winlogon / LogonUIによる定期的なスパイク状のCPU使用率
AWSサーバーが特別な理由もなくCPUの束を使用し始めることがあり、次のようになっていることに気付きました。
特定の時間に発生するわけではありませんが、非常に明確なパターンがあることに注意してください。それは1時間弱続きます。
この発生中にマシンにリモート接続すると、必ず発生が停止します。アカウントを永続的にログオンしたままにしておくと、より詳細なCPU使用率のトレースをキャプチャできました。それはこのように見えました：
そのとおり;そのCPUを実際に消費するプロセスはリストに含まれていません。代わりに、それらは常に現れたり消えたりします。 ProcMonは明らかにこの仕事のツールだったので、トレースをキャプチャしました。これは私が見つけたものです：
Postgresも関係しています：
ただし、すべてのCPU使用率はWinlogon/LogonUI/etcによるものです。
この発生中のプロセス開始イベントと停止イベントの短い抜粋を次に示します。
Postgresは、smss/winlogon/etcの各開始/停止ではインターリーブされず、それらの一部のみでインターリーブされることに注意してください。
なぜこれが起こるのか、そしてそれを防ぐ方法はありますか？
問題は、誰かが私のRDPログインをブルートフォース攻撃していたことでした。 2番目の問題は、ネットワークレベルの認証が無効になり、各ログイン試行で比較的CPUコストがかかることでした。
解決策は、ブルートフォース攻撃を停止するためにRDPポートを3389から変更することでした、ネットワークレベル認証を有効にして、ログオン試行のCPUコストを削減しました。
ヒント＃1、syneticon-djから：イベントログを確認してください。これらの急増は、「john」、「admin」、「test」などのユーザー名を試し、それぞれが約3〜5の異なるパスワードを使用して、多くのログオン失敗と相関していました。彼らは3-4秒間隔で到着しました。
ヒント＃2、Olivier Sから：このサーバーはAmazon EC2インスタンスであるため、RDPが必要です。本当の問題は、デフォルトでEC2マシンではネットワークレベル認証が無効になっている、何らかの理由でした。これは、誰かがパスワードを試行するたびに、ログオンUI全体が起動され、かなりリモートのデスクトップセッションが表示されることを意味します。これがすべてのCPU使用率の原因です。
Postgresの部分では、これはpostgresがセッションごとに（スレッドではなく）プロセスを作成するためです。これはWindowsではかなりコストがかかります（UNIXシステムではかなり効率的です）。
Winlogon/LogonUiの部分これはかなり奇妙です。サーバーはリモートアクセスできますか？サーバーのポート3389を開こうとし、rdpセッションにまたがるネットワークスキャナーがネットワーク上にある可能性があります。これは、smss/winlogon/loginuiシーケンスを説明しますか？セッションがすぐに閉じられるので、ネットワークスキャナーを思い浮かべます。
したがって、私の推測では、ネットワーク上のポートをスキャンするnmapプロセスまたは「ネットワーク検出」ツールがあるか、サーバーがポート3389（およびおそらく5432）でファイアウォールなしでインターネットに開かれています。
これに対する答えは、ポート3389で私のRDPをブルートフォースしようとしている15人であることがわかりました。
コマンドプロンプトを開き、netstat -nと入力してIP：3389を探します。自分以外の接続が複数ある場合は、誰かが侵入しようとしています。
CPUがほぼ100％停止する解決策は、デフォルトの3389を別のものに変更することでした。
あなたはこれに対する解決策をグーグルすることができます、ポートはレジストリに保存されます
それに応じてファイアウォールルールを変更する必要がある場合もあります
これで問題は解決し、CPUが元に戻りました。