Периодическое скачкообразное использование ЦП Winlogon / LogonUI
Я заметил, что мой сервер AWS иногда без особой причины начинает использовать несколько процессоров, что выглядит примерно так:
Обратите внимание, что это не происходит в определенное время, но имеет очень определенный образец. Это длится чуть меньше часа.
Удаленное подключение к машине во время этого события неизменно останавливает его. Постоянный вход в учетную запись позволил мне получить более детальную трассировку использования ЦП. Выглядело это так:
Это правильно; процессы, которые фактически потребляют этот ЦП, отсутствуют в списке. Вместо этого они все время появляются и исчезают. ProcMon, очевидно, был инструментом для работы, поэтому я зафиксировал след. Вот что я нашел:
Также участвует Постгрес:
Однако все использование ЦП осуществляется Winlogon / LogonUI / etc:
Вот краткая выдержка из событий запуска и остановки процесса во время этого события:
Обратите внимание, что postgres не чередуется с каждым запуском / остановкой smss / winlogon / etc, а только с некоторыми из них.
Есть идеи, почему это происходит и как это предотвратить?
Для части postgres это связано с тем, что postgres создает процесс, а не поток, для каждого сеанса. Это довольно затратно для Windows (но довольно эффективно в системах Unix).
Часть Winlogon / LogonUi это довольно странно. Доступен ли сервер удаленно? Может ли в сети быть сетевой сканер, который попытается открыть порт 3389 на сервере и, таким образом, охватить сеанс rdp, что объясняет последовательность smss / winlogon / logonui? Я думаю о сетевом сканере, потому что сеанс сразу закрывается.
Итак, мое предположение о награде: у вас есть процесс nmap или какой-то инструмент «сетевого обнаружения», который сканирует порты в вашей сети, или ваш сервер открыт для Интернета без брандмауэра на порту 3389 (и, возможно, 5432).
Проблема заключалась в том, что кто-то взломал мой логин по RDP. Второстепенная проблема заключалась в том, что аутентификация на сетевом уровне была отключена, что делало каждую попытку входа в систему относительно затратной для ЦП.
Решением было изменить порт RDP с 3389, чтобы остановить атаки методом перебора., а также для включения проверки подлинности на сетевом уровне, чтобы снизить затраты ЦП при попытке входа в систему.
Совет # 1, из syneticon-dj: проверьте журналы событий. Эти всплески коррелировали с множеством неудачных попыток входа в систему с попытками использования таких имен пользователей, как «john», «admin», «test» и т. Д., Каждое с 3-5 разными паролями. Они прибыли с интервалом в 3-4 секунды.
Совет # 2, от Olivier S: этот сервер, являющийся экземпляром Amazon EC2, требует RDP. Настоящая проблема заключалась в том, что по умолчанию На машинах EC2 отключена проверка подлинности на уровне сети, по какой-то причине. Это означает, что каждый раз, когда кто-то хочет попытаться ввести пароль, запускается весь пользовательский интерфейс входа в систему, просто чтобы представить им довольно приятный сеанс удаленного рабочего стола. Это то, что вызвало полную загрузку процессора.
Я нашел ответ на этот вопрос: 15 человек пытались перебрать мой RDP через порт 3389.
Откройте командную строку и введите netstat -n ищите свой IP: 3389, если есть более одного соединения, которое не относится к вам, то кто-то пытается войти.
Решением для остановки около 100% ЦП было изменение 3389 по умолчанию на что-то другое.
Решение для этого можно гуглить, порт хранится в реестре
Вам также может потребоваться изменить правила брандмауэра соответствующим образом.
Это решило мою проблему, и мой процессор вернулся!