33. Проблемы безопасности

1. Пароли

Доступ с правами администратора — наиболее опасная атака уровня ОС, поэтому именно защита административных полномочий должна в первую очередь решаться. Однако, доступ с правами обычного пользователя также может многое дать злоумышленнику. Поэтому защищённость операционной системы во многом определяется политикой в отношении пользовательских паролей.

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

Алгоритм, используемый Windows для получения LAN Manager password hash, предлагает несколько подходов к значительному сокращению перебора. Во-первых, так как пароли конвертируются в верхний регистр, это значительно сокращает пространство возможных паролей. Во-вторых, так как пароль разделяется на две 7-байтные части, каждая из которых шифруется отдельно, нет необходимости перебирать N в 14 степени комбинаций, а достаточно 2 раза по N в 7 степени. В частности, можно сразу же выделить пароли длиной до 7 символов, так как вторая половина LAN Manager password hash для них представляет собой известное постоянное значение. Существуют общедоступные утилиты для взлома паролей, реализующие эти методы.

Для предотвращения такой атаки можно использовать программу syskey. Эта программа позволяет наложить на базу данных учетных записей дополнительный уровень шифрования, с ключом, в скрытом виде, хранящемся в системе, на диске, или получаемом из пароля, заданного администратором. Эта методика позволяет значительно повысить защищенность базы данных учетных записей.

2. Права пользователей

Построение защищённой системы предполагает правильную настройку прав пользователей и ACL объектов. Это, главным образом:

• Права пользователей по отношению к службам

• Допуски к папкам и файлам

• Допуски к ключам реестра

3. Службы

Многие системные службы, например планировщик задач или сервер баз данных, предоставляют в распоряжение пользователей механизмы запуска команд, исполнять которые будет сама служба. Некоторые планировщики умеют выполнять команды от имени учетной записи пользователя, иначе команда выполняется с привилегиями учетной записи самой службы. Например, в состав Microsoft SQL Server входит собственный планировщик задач и SQL-команд, что дает пользователям SQL Server возможность выполнять команды операционной системы. В этом случае существует два способа защиты. Во-первых, можно ограничить права пользователей на выполнение команд настройкой самой службы. Большинство служб, таких, как SQL Server и Microsoft Exchange Server, снабжены механизмами аутентификации и контроля доступа. Необходимо убедиться, что такие механизмы корректно сконфигурированы, и следить за их настройкой. Во-вторых, часто подобные службы запускаются от имени системной учетной записи Local System Account, которая мощнее, учетной записи администратора. Чтобы этого избежать, нужно создать отдельную учетную запись для службы и предоставить ей только те права и разрешения, которые необходимы для работы. В результате если кто-то получит возможность работать с данной службой, у него будут лишь те права доступа к системе, которые предоставлены учетной записи службы.

Такой подход особенно важен системной службе планировщика Scheduler. По умолчанию эта служба работает от имени системной учетной записи. Если это не имеет значения, ее можно запускать от имени непривилегированного пользователя.