Account Lockout: мифы и реалии

Система блокировки учётных записей Windows при неоднократном введении неправильного пароля существует с самой первой редакции ОС Windows (Windows NT 3.1 Advanced Server, 1993), но новички продолжают прокалываться на элементарных вещах. В данной статье я попробую разобрать основные ошибки начинающих администраторов. Ну и на кусочек Тайного Знания можете рассчитывать тоже.

Миф первый: Account Lockout работает в Windows «из коробки».

Реалии: нет, Account Lockout по умолчанию не включён.

Не сочтите за труд зайти Администратором и таки настроить Group Policy. Точный путь: Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. Какие конкретно параметры брать? Я обычно указываю следующие:

• Account lockout duration = 10 minutes;
• Account lockout threshold = 8 invalid logon attempts;
• Reset account lockout counter after = 5 minutes

Этого хватит, чтобы система могла относительно быстро (8 попыток) обнаружить атаку перебора паролей, в то же время учитывая природную косорукость некоторых пользователей. Если человек встал не с той ноги, порекомендуйте ему выпить кофе и попытаться зайти ещё раз — через 10 минут блокировка будет снята автоматически, а кофе поможет обнаружить лампочку включенного режима Caps Lock или неверную раскладку клавиатуры.

Миф второй: Account Lockout распространяется на все виды учётных записей и протоколов.

Реалии: нет, Windows задействует Account Lockout только на Windows-пользователей.

SQL Accounts — это другое. Учётные записи веб-форума, который работает на вашем сервере — это другое. Пароль на VNC — это другое. Учётные записи стороннего почтового или FTP-сервера — это другое. Учётные записи вашей складской или финансовой программы — это другое. И в каждом названном случае Account Lockout должен обеспечивать производитель программы. Что самое интересное, обычно производители программ такими вещами не заморачиваются. Что может привести к обидам и огорчениям в случае атаки «заинтересованных персон».

На что реально распространяется Account Lockout в Windows?

• На локальные логоны в Windows, как в доменные, так и недоменные машины;
• На сетевые логоны через SMB/CIFS, а также LDAP на контроллеры домена;
• На логоны Remote Desktop Protocol (RDP);
• На логоны через интегрированные сервисы (например, SQL/Exchange). При этом не надо забывать, что в том же SQL могут оставаться локальные учётные записи, а некоторые сервисы с интеграцией с Active Directory могут просто копировать доменные учётные записи к себе, что по сути интеграцией не является.

Миф третий: Защищать нужно только доменные учётные записи.

Реалии: защищать следует и доменные, и локальные учётные записи.

В каждой второй компании на маршрутизаторе открывается прямое пропускание порта RDP на рабочую станцию пользователя, чтобы тот мог работать из дому в случае болезни или отпуска. А что интересного даёт рабочая станция? Локального администратора, ведь далеко не везде он заблокирован. Сам видел в реальном времени, как китайцы через RDP убеждали рабочую станцию, что пароль локального администратора — «маоцзедун». Смена порта RDP не помогает, те же китайцы моментально вычисляют, что за портом 80 на самом деле кроется самый что ни на есть RDP.

То же самое касается и терминальных серверов компании, и множества домашних компьютеров, на которые «продвинутые пользователи» дистанционно подключаются либо с различного рода pad-ов, либо с работы.

Миф четвёртый: Account Lockout срабатывает только при атаке перебора паролей.

Реалии: это не всегда так.

Примите во внимание нюансы конфигурации сторонних сервисов. Например, если у пользователя хватило ума сохранить пароль доступа к Outlook Web Access (OWA) в свой смартфон, после очередной смены пароля почтовый клиент получит отказ входа и может продолжать ломиться на OWA раз в минуту (то есть, 5 попыток за пять минут).

Ещё одним тонким моментом может оказаться двойная попытка логона со стороны некоторых операционных систем (Windows XP? Surprise!). Они что делают: при неудаче залогониться по сети через NTLM пробуют ещё раз, но уже через LM, тем самым тратя дополнительную попытку входа. А если это недоменная XP с включённым Welcome Screen, то простой тык в учётную запись пользователя тоже тратит попытку входа с пустым паролем (включите аудит и почитайте журнал Security). В этих случаях можете чуть увеличить счётчики политики до, например, 15-12-10.

Если что, с Windows XP вообще всё в этом смысле прекрасно. Попробуйте на досуге запустить программу Cain & Abel на одном компьютере, а на втором (XP) открыть My Network Places. Заходить никуда не нужно, достаточно просто открыть иконку сети. Увидите, сколь радостно и многократно XP рассылает пароль вашей учётной записи всем подряд в сети .))

А теперь представьте, что кто-то подключился к вашей сети — например, работник партнёрской организации принёс свой мобильный компьютер или подключился к вашей сети через VPN. Он дважды щёлкает на имени вашего компьютера (или сервера компании), желая получить доступа к зашаренным ресурсам. Разумеется, он вышлет вам свои реквизиты. Да и чёрт с ними, пароль перехватим и расшифруем позже. Главное, что при условии совпадения имён пользователей у вас с лёгкостью случится Account Lockout.

В общем, подобного рода ситуации ещё долго можно перечислять. Просто подходите к «закручиванию гаек» с пониманием.

Миф пятый: Account Lockout срабатывает для всех пользователей.

Реалии: это не так.

Встроенный администратор (.\Administrator или Domain\Administrator) не блокируются. Вернее, они делают вид, что блокируются, но на самом деле это не так. Проблема имеет место быть на всех версиях Windows, включая самые актуальные. Давайте сравним поведение Account Lockout для учётных записей любого пользователя и встроенного Администратора:

Как мы видим, результаты разные. При этом учётная запись как бы и блокируется, запись в журнал безопасности заносится:

То есть, на самом деле блокировки нет. Ещё раз: это касается не всех администраторов, а только одного встроенного. Доменного тоже. Что с этим делать? Вам поможет магическая утилита PASSPROP.EXE из комплекта Windows NT 4.0 Resource Kit. Запустите её с ключом «/adminlockout» и читайте внимательно про последствия: «при наступлении блокировки Администратора он всё же сможет залогониться интерактивно.»

Внесите настройку Account Lockout и запуск Passprop в протокол конфигурации серверов и рабочих станций.