Назад | Перейти на главную страницу

Диагностика записей журнала событий сбоя аудита входа

Я помогаю клиенту управлять веб-сайтом, который работает на выделенном веб-сервере в хостинговой компании. Недавно мы заметили, что за последние две недели в журнале событий безопасности были десятки тысяч записей об ошибках аудита с категорией задачи входа в систему - они поступали примерно каждые две секунды, но, что интересно, полностью прекратились по состоянию на два дня назад. .

В целом описание события выглядит следующим образом:

An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:       ...The Hosting Account...
    Account Domain:     ...The Domain...
    Logon ID:       0x3e7

Logon Type:         10

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       david
    Account Domain:     ...The Domain...

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xc000006d
    Sub Status:     0xc0000064

Process Information:
    Caller Process ID:  0x154c
    Caller Process Name:    C:\Windows\System32\winlogon.exe

Network Information:
    Workstation Name:   ...The Domain...
    Source Network Address: 173.231.24.18
    Source Port:        1605

Значение в Имя учетной записи поле отличается. Выше вы видите «david», но есть такие с «john», «console», «sys» и даже такие, как «support83423» и еще много чего.

В Тип входа указывает, что попытка входа в систему была удаленной интерактивной попыткой через службы терминалов или удаленный рабочий стол. Я предполагаю, что это некие атаки методом грубой силы, пытающиеся угадать комбинации имени пользователя и пароля для входа на наш выделенный сервер. Верны ли эти предположения?

Эти типы атак довольно распространены? Есть ли способ помочь остановить подобные атаки? Нам необходимо иметь доступ к рабочему столу через удаленный рабочий стол, поэтому просто отключить эту службу невозможно.

Спасибо

Бюллетени по безопасности за март 2012 г. включали MS12-020, предназначенную для критической уязвимости в службах удаленных рабочих столов. 19 марта было сообщено, что существует доказательство концептуального кода в дикой природе.

http://www.pcworld.com/businesscenter/article/252092/patch_now_microsoft_rdp_exploit_code_is_in_the_wild.html

https://secunia.com/advisories/48395

https://technet.microsoft.com/en-us/security/bulletin/ms12-020

Я бы не стал выставлять удаленный рабочий стол без смарт-карты или решения VPN. Для оценки и тестирования доступны недорогие решения VPN (например, Hamachi). Существуют даже бесплатные версии, если вам не нужны все функции или у вас небольшое количество удаленных клиентских компьютеров.

Они обычные? Да.

Вы можете их остановить? Нет.

Вы не можете остановить кого-то от попытки атаки, но вы можете снизить его шансы на успех, обновляя систему с помощью исправлений, используя какой-либо тип IDS / IPS и регулярно проверяя свои журналы, чтобы быть в курсе частоты и объем попыток.

Как сказал Джо, это обычное дело, и лучше всего обезопасить поверхность (обновления и т. Д.). Я предполагаю, поскольку это выделенный сервер, он должен находиться за общим / выделенным межсетевым экраном. Позвоните своему хостинг-провайдеру и попросите его внести в белый список исходный IP-адрес для 3389 и сбросить весь другой трафик, не исходящий из ваших источников.