Здравствуйте, уважаемые читатели!

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

Задача была поставлена простая — настроить операционную систему и почтовый клиент в одном из филиалов нашей большой бюджетной организации.

Ничего не предвещало интересной истории, если бы не один нюанс – коллеги обнаружили, что жёсткий диск из комплекта ПЭВМ, спланированного на ввод в эксплуатацию, оказался «в работе» в составе другого ПЭВМ.

В итоге местный системный администратор создал образ системы и перенёс её на другой жёсткий диск — мне же достался диск ранее эксплуатируемый (со всеми настройками).

Но этой заметки не было бы, если бы эта система не таила в себе пару сюрпризов.

Использовалась всё та же старенькая Astra Linux SE 1.5 без обновлений. Менять систему я не планировал, так как лицензии на новую версию у них не было.

Сам же я не администрирую Astra Linux SE 1.5 с года 2018-го и готовых конфигурационных файлов с собой не имел, поэтому меня порадовал факт жёсткого диска с настроенной системой.

В целях аудита на данном компьютере была создана учётная запись администратора безопасности, с которой специалисты другого филиала следили за состоянием системы.

Я изменил настройки сети, поменял имя компьютера и приступил к настройке новых пользователей. Зашёл в директорию home, и моему взору предстало нечто вроде этого (реальные имена учётных записей изменены):

До чего техника дошла, admin2c и там, и тут показывают.

Сразу понял, что одна из букв не на латинице. Решил попробовать выполнить пару команд ls с буквой «с» кириллицей и латиницей. И действительно, в одном из вариантов использовалась буква «с» кириллицей.

То есть администратор аудита существовал (с виду) и не существовал (фактически) одновременно, а в журнале /var/log/auth.log были зафиксированы многочисленные неудачные попытки удалённого входа настоящего admin2c (с буквой «с» латиницей).

Честно сказать, довольно изощрённый метод вывода из строя учётной записи. Непонятно, зачем было так мудрить.

Дальше было ещё интереснее – каталог /etc/ имел права 777, а вот это уже более чем серьёзно.

Так как в операционной системе Astra Linux SE 1.5 нет МКЦ, любой пользователь мог заменить конфигурационные файлы — получив права супер пользователя.

Шаг 1. Копируем оригинальный group и добавляем себя в группу astra-admin.
Шаг 2. Выходим и заново заходим в систему, получаем права root, возвращаем права файлу group.

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

Возможно, права доступа 777 — это ошибка конфигурации и ничего за этим не стоит. Но файлы внутри каталога etc имеют нормальные права, поэтому сомневаюсь.

Об инциденте сообщил администраторам безопасности, в чьей зоне ответственности был этот филиал.

Как это сделали? С тем уровнем организации, что я видел – как угодно. Корпус ПЭВМ опечатан не был, крышка была открыта.

Кто это сделал? Загадка, с которой предстоит разбираться не мне, но после пары таких сюрпризов я решил переустановить систему «с нуля» и настроить самостоятельно, мало ли там ещё подводных камней.

Добавить комментарий

Ваш e-mail не будет опубликован.