Перебор паролей 1С: как увидеть по журналу регистрации
Перебор паролей 1С обычно замечают постфактум: пользователь жалуется, что его «заблокировало», или в базе появляется вход, которого никто не делал. Между тем каждая неудачная попытка входа уже записана в журнал регистрации базы — нужно только знать, какое событие искать и как его читать. Разбираем, где лежат эти записи, как отличить подбор пароля от забытой интеграции со старым паролем и какие пороги ставить на алерты.
Где 1С записывает неудачные попытки входа?
В журнал регистрации каждой информационной базы. Неудачный вход — это событие «Сеанс. Аутентификация (ошибка)», во внутреннем словаре журнала оно называется _$Session$_.AuthenticationError. Успешный вход — соседнее событие «Сеанс. Аутентификация».
В клиент-серверном варианте журнал лежит в каталоге кластера: reg_<порт менеджера кластера>/<GUID базы>/1Cv8Log. На Linux это по умолчанию домашний каталог пользователя usr1cv8 (…/.1cv8/1C/1cv8/reg_1541), на Windows — каталог srvinfo службы сервера 1С. Соответствие GUID и имени базы — в файле 1CV8Clst.lst того же каталога reg_<порт>.
Форматов два. Последовательный: 1Cv8.lgf — словарь (пользователи, компьютеры, приложения, события), файлы *.lgp — сами записи по периодам. И формат SQLite — один файл 1Cv8.lgd. Для автоматического разбора проще последовательный: файлы дописываются в конец, их можно читать «хвостом» и не мешать серверу.
В записи о неудачном входе есть время, введённое имя пользователя, имя компьютера, приложение (толстый или тонкий клиент, веб-клиент, COM-соединение, консоль кластера), номера сеанса и соединения. Важная деталь: код события в словаре свой в каждой базе, поэтому искать нужно по имени события, а не по числу из соседней базы.
Как найти перебор паролей в журнале регистрации вручную?
Самый быстрый способ — штатный просмотр: «Администрирование → Журнал регистрации» в конфигураторе или в режиме «1С:Предприятие», отбор по событию «Сеанс. Аутентификация (ошибка)» за последние сутки. Дальше смотрите на три колонки: пользователь, компьютер и приложение.
Признаки подбора видны сразу. Десятки ошибок за минуты под одним логином — подбирают пароль конкретного пользователя. Много разных логинов с одного компьютера — подбирают учётные записи: пробуют типовые имена вроде «Администратор», «Бухгалтер», «Admin» с одним-двумя популярными паролями. Попытки ночью и в выходные, когда в базе никто не работает, — ещё один сигнал.
Проблема ручного способа очевидна: журнал смотрят, когда уже что-то случилось, и по одной базе за раз. На сервере с десятком баз перебор в «забытой» тестовой копии никто не увидит.
Перебор паролей или забытый обмен: как отличить?
Большая часть ошибок аутентификации в реальных базах — не атака. Сменили пароль служебному пользователю, а обмен, внешняя обработка по расписанию или сервис интеграции продолжают стучаться со старым. Картина в журнале у них характерная: один и тот же логин, один и тот же компьютер, ровный интервал — раз в минуту или раз в пять минут, круглые сутки.
Перебор выглядит иначе: всплеск, много попыток за короткое время, часто — разные логины, иногда несуществующие. Поэтому полезно разделять два сигнала: много неудачных входов на сервере вообще и много разных логинов с одного компьютера. Первый ловит подбор пароля одного пользователя, второй — перебор учётных записей, который не превышает порог ни по одному отдельному логину.
Ещё один источник шума — консоль администрирования кластера (RAS): одна попытка из неё может дать пару записей в одну секунду. Такие попытки разумно считать отдельно или не считать вовсе, а пары записей одного соединения в одну секунду склеивать в одну попытку.
Почему блокировки после неудачных попыток недостаточно?
В параметрах информационной базы (конфигуратор, «Администрирование → Параметры информационной базы») есть максимальное количество неуспешных попыток аутентификации и длительность блокировки; значение 0 защиту выключает. Включить её стоит, но у неё три ограничения.
Первое — блокировка работает на одного пользователя. Перебор учётных записей, когда с каждым логином пробуют один пароль, её не задевает. Второе — блокировка молчит: пользователь попадает в список «Блокировки аутентификации», а администратор узнаёт об этом из звонка «не могу войти». Третье — блокировку можно использовать против вас: перебором по логину главного бухгалтера можно на время закрыть ему вход.
Поэтому блокировка — защита, а не наблюдение. Об атаке должен узнать дежурный, а не только сама база.
Какие пороги ставить на алерты?
Пороги зависят от размера базы и привычек пользователей, но логика такая. Окно — 5 минут: ошибки ввода пароля живым человеком дают 2–3 попытки, подбор — десятки. Порог по всем базам сервера вместе — например, от 20 неудачных входов за 5 минут: так видна и атака, размазанная по нескольким базам. Отдельный порог на разные логины с одного компьютера — от 5 за 5 минут: обычный пользователь не входит под пятью именами подряд.
Алерт должен держаться ещё 10–15 минут после последней попытки, иначе перебор с паузами будет давать серию коротких «загорелось — погасло». И в тексте алерта нужен ответ на вопрос «куда смотреть»: сервер, база, логин, компьютер. Если интеграция со старым паролем шумит постоянно, её нужно починить, а не поднимать порог под неё.
Если базы опубликованы на веб-сервере, неудачные входы через веб-клиент и HTTP-сервисы, как правило, тоже попадают в журнал. Отдельно проверьте, что сама публикация не пускает без пароля, — об этом наша статья открыт ли OData без пароля. Неудачные входы — часть общего мониторинга 1С наравне с сеансами, лицензиями и rphost.
Что проверить у себя
— Откройте журнал регистрации каждой рабочей базы с отбором по событию «Сеанс. Аутентификация (ошибка)» за неделю.
— Найдите логины с ошибками по расписанию — это интеграции со старым паролем, их нужно исправить.
— Проверьте, включены ли в параметрах базы максимальное количество неуспешных попыток и длительность блокировки.
— Посмотрите, нет ли пользователей с типовыми именами («Администратор», «Admin») и пустыми или простыми паролями.
— Не забудьте тестовые и архивные копии баз на том же сервере — в них часто остаются старые учётные записи.
— Убедитесь, что о переборе узнаёт дежурный по алерту, а не по жалобе пользователя.
Видно ли в журнале регистрации IP-адрес, с которого подбирают пароль?
Нет. В записи есть только имя компьютера, которое сообщил клиент 1С, и его можно подменить. При входе через веб-публикацию в этом поле, как правило, сам веб-сервер, поэтому адрес клиента нужно искать в журнале доступа веб-сервера по времени попытки.
Сообщает ли 1С администратору о блокировке пользователя?
Нет. Заблокированные пользователи видны в списке «Блокировки аутентификации», но уведомления платформа не отправляет. Если хотите узнавать о переборе сразу, нужен внешний мониторинг журнала регистрации с алертом.
Достаточно ли одной ошибки входа для алерта?
Нет, это будет шум: пользователи ошибаются в пароле каждый день. Алерт имеет смысл на всплеск — десятки попыток или несколько разных логинов с одного компьютера за несколько минут.
Как это сделано в Voltir
Агент Voltir на сервере 1С (Linux и Windows) раз в минуту дочитывает хвост журнала регистрации каждой серверной базы в последовательном формате — только на чтение, не меняя права файлов 1С, — берёт из записей только время, базу, логин, компьютер и приложение. Платформа поднимает алерты «Перебор паролей 1С» и «Перебор логинов 1С» с порогами 20 входов и 5 логинов за 5 минут (меняются в настройках), а подробности показывает на дашборде «Безопасность»; формат .lgd пока не поддерживается. Как устроены события безопасности, описано в документации по безопасности, дашборды можно посмотреть в живом демо.
Если на такие алерты должен реагировать дежурный, есть мониторинг как услуга; стоимость — на странице тарифов.