Каждая компания имеет рядовые серверы разной емкости. Некоторые компании имеют только несколько таких серверов, а другие имеют их тысячи. Такие рядовые серверы являются рабочими лошадками вашей сети, обеспечивая основные производительные сервисы для компании. От поддержки интранета, обеспечения сервисов печати, SQL баз данных, почтовых сервисов, хранения файлов, до поддержки приложений. Рядовые серверы, обеспечивающие все эти основные функции, идут рука об руку с фактом, что вам необходимо защитить эти серверы. Эта статья обсуждает некоторые ключевые вопросы защитных конфигураций, которые могут помочь защитить ваши рядовые серверы.
Рядовые серверы – это те серверы в вашем Active Directory окружении, которые не обеспечивают авторизацию для учетных записей пользователей домена. Эта задача оставлена для контроллеров домена. Даже хотя рядовые серверы не обеспечивают авторизацию для пользователей домена, они все еще обеспечивают основные функции для вашей компании. Когда становится необходимо, рядовые серверы обеспечивают основу сервисов, приложений, хранилищ файлов и многое другое для вашей компании.
Рядовые серверы бывают любых размеров, доступности и функций. Вот некоторые из наиболее общих задач, за которые отвечают рядовые серверы:
Когда рядовые серверы управляют и содержат такую важную информацию и данные, то нет сомнений, что такие серверы должны стоять вверху списка, когда решается вопрос о защите компьютеров в сети. Существуют, конечно, ясные меры безопасности, которые вы можете предпринять, такие как замыкание серверов в отдельной комнате и в замыкаемой клетке внутри комнаты. Однако существуют логические конфигурации, которые также могут вам помочь защитить эти серверы. Здесь мы рассмотрим эти области и обсудим наилучшие способы повышения защищенности ваших рядовых серверов.
Существует множество областей безопасности, которые следует принимать во внимание, когда защищаете ваши рядовые серверы. Некоторые из наиболее важных областей также являются наиболее легко конфигурируемыми, если вы знакомы с доступными инструментами для проверки корректности конфигурации безопасности. Наиболее важные области, которые нужно защищать для всех рядовых серверов, включают:
Мы изучим каждую из этих областей, определим наиболее эффективные методы, доступные для конфигурирования каждого рядового сервера, чтобы убедиться, что эти установки являются корректными и устойчивыми. Один из наиболее полезных инструментов для конфигурирования безопасности рядовых серверов или любых других компьютеров в сети Active Directory – это Group Policy (Политика Групп). Каждое из решений будет включать использование Политики Групп, которая на сегодня используется компаниями в той или иной степени. (Для получения дополнительной информации по Политике Групп читайте “The Group Policy Guide” (Руководство по Политике Групп), выпущенную Microsoft Press.)
Локальный SAM на каждом рядовом сервере уникален, поэтому, каждый рядовой сервер должен учитываться, когда защищается имущество, расположенное на сервере. Локальный SAM содержит и конфигурации, и объекты, которые являются основными для рассмотрения, когда блокируется доступ к серверу. Внутри Локального SAM вы захотите рассмотреть следующие области для защиты:
Account Policies (Политики учетных записей) – политики учетных записей для рядового сервера управляют политиками паролей и политиками блокировки учетных записей для всех пользовательских учетных записей, хранящихся в Локальном SAM. Это наилучшая практика для гарантирования, что политики учетных записей соответствуют или превосходят политики учетных записей, установленные для пользовательских учетных записей домена, которые настроены на контроллере домена. По умолчанию, рядовые серверы будут иметь такие же политики учетных записей, как и контроллеры домена, но очень легко это изменить, используя Group Policy Object (GPO – Объект Политики Групп).
User Accounts (Пользовательские учетные записи) – всегда есть одна активная пользовательская учетная запись на каждом рядовом сервере по умолчанию, которая является учтенной записью Администратора. Эта учетная запись нуждается в защите всеми средствами. Если атакующий захватывает управление сервером с помощью этой учетной записи, то не будет ничего, чего бы не смог сделать атакующий или к чему он не имел бы доступ. Некоторые рекомендуемые настройки для защиты этой учтенной записи включают: ее переименование, не использование ее для чего-либо, кроме восстановления сервера, установка сложного пароля/идентификационной фразы и запрещение ее. Все эти опции доступны через GPO, за исключением установки сложного пароля/идентификационной фразы. Однако, с помощью такого инструмента, как PolicyMaker (www.desktopstandard.com/policymaker), пароль может быть установлен, используя настройку GPO.
Groups (Группы) – каждый рядовой сервер имеет набор локальных групп. Некоторые группы обеспечивают повышенные привилегии для выполнения задач администрирования на этом сервере. Эти группы должны быть как следует защищены и настроены, для гарантирования, что только нужные пользователи имеют членство в этих группах. Есть GPO настройка, называемая “Restricted Groups” (Ограниченные Группы), которая может управлять членством в существующих группах, как показано на Рисунке 1.
Рисунок 1: “Restricted Groups” управляют членством в существующих группах на рядовом сервере
Снова PolicyMaker поднимает управление логическими группами на новый уровень, позволяя ограниченное управление членством в группе, включая опции фильтрации только для определенных рядовых серверов.
Права Пользователей являются привилегиями, которые настроены на рядовом сервере на основе рядовых серверов. Некоторые из наиболее общих и влияющих на безопасность прав пользователей включают:
Вне зависимости от прав пользователя, список пользователей и групп, которым присвоены эти привилегии на рядовом сервере, должен быть изучаемым и управляемым. Лучший способ управлять правами пользователя для рядового сервера – это использовать GPO, как показано на Рисунке 2.
Рисунок 2: Правами Пользователей для рядовых серверов можно управлять централизовано, использованием GPO
Часто порты и сервисы идут рука об руку, так как некоторые сервисы требуют использование определенных портов. Например, Internet Information Services (IIS) отвечает за World Wide Web (WWW) Publishing Service, который по умолчанию настроен на порт 80. Множество сервисов, подобно IIS и WWW, обеспечивают превосходные услуги, но могут повышать уязвимость защиты. Если рядовой сервер не требует разрешения сервиса или порта, то этот сервис или порт должен быть запрещен.
Управление портами и сервисами не такая простая задача, как другие в этой статье. Сервисами можно управлять с помощью GPO, но не всеми основными настройками, связанными с сервисами. Управление сервисом будет идеально, если вы управляете режимом запуска сервиса и его учетной записью. Встроенные GPO настройки для сервисов поддерживают только управление режимом запуска, но не учетнной записью сервиса. С помощью PolicyMaker вы можете включить управление учетной записью сервиса в GPO.
Если вы выполняете Windows 2000 Server на вашем рядовом сервере, управление портами является ручным процессом. Это может привести к тому, что некоторые порты могут быть незащищены, что вызовет уязвимость сервера. Однако, если вы выполняете Windows Server 2003, Microsoft только что поместила новый инструмент в Service Pack 1, который может помочь вам управлять и портами, и сервисами. Этот инструмент называется Security Configuration Wizard (Мастер Конфигурации Безопасности). Этот мастер создает политики безопасности (которые затем можно превратить в GPO), которые разрешают и запрещают соответствующие порты и сервисы, в зависимости от того, какую роль выполняет этот сервер. (Для дополнительной информации о Security Configuration Wizard смотрите http://www.windowsecurity.com/articles/Security-Configuration-Wizard-Windows-Server-2003-SP1.html).
Если вы хотите управлять портами и сервисами независимо от ролей, которые определила Microsoft, вы можете прочитать о том, какие порты и сервисы являются основными и кто за что отвечает, в Руководствах по Безопасности Microsoft (которые могут быть расположены на http://www.microsoft.com/technet/security/topics/ServerSecurity.mspx).
При ваших рядовых серверов, которые выполняют одно или более приложений, вы можете попасть в типичную ситуацию. В основном, вы хотите иметь одного или более пользователей, которые имеют администраторское управление над приложением, но не над сервером. Со встроенной конфигурацией, которую обеспечивает Microsoft, нет способа указать, что пользователь имеет администраторское управление над одним приложением, а не над сервером. Если вы попали в данную ситуацию, ваше лучшее решение – это попытаться поместить этого пользователя в группу Power Users на рядовом сервере, и надеяться, что ему хватит привилегий для выполнения приложения. Если нет, то вам может потребоваться добавить пользователя в группу Администраторов для предоставления ему нужных привилегий для поддержки приложения.
Если вы хотите перенести ваше решение на следующий уровень, инсталлируйте Application Security (http://www.desktopstandard.com/PolicyMakerApplicationSecurity.aspx) для управления тем, какие группы могут управлять какими приложениями, на базе сервер-сервер. Это перенесет безопасность ваших серверов приложений на совершенно новый уровень, позволяющий полностью управлять тем, кто какое приложение может администрировать.
Рядовые серверы отвечают за большинство данных компании, финансовые приложения, кадры и другие ресурсы компании, критичные к миссиям. Общепринято, что рядовые серверы являются защищенными для гарантирования, что данные, размещенные на них, будут защищены от нападений. Это лучше осуществлять использованием встроенных настроек GPO, и может быть расширено использованием некоторых превосходных инструментов расширения GPO сторонних производителей. После того, как Локальный SAM, права пользователей, порты, сервисы и приложения будут защищены, вы хорошо продвинетесь по пути обеспечения хорошей защиты ваших рядовых серверов.
Источник www.windowsecurity.com