14 уровни защиты сервера как основы компьютерной сети пароли пользователей и их права

Обновлено: 19.05.2024

Вопрос безопасности сервера был и будет актуальным. Рассмотрим базовые правила обеспечения безопасности серверов под управлением ОС семейства Window Server.

Регулярно устанавливать обновления операционной системы и установленного программного обеспечения.

В быту существует мнение, что Windows не нуждается в обновлениях и их вообще лучше отключить, якобы “чтобы система не тормозила”. Это одна из самых главных ошибок. Обновления важно устанавливать своевременно, особенно критические. Упрощает эту задачу специальная утилита, с которой можно ознакомиться на официальном сайте Центра обновления Windows.

Также важно поддерживать в актуальном состоянии установленное сопутствующее программное обеспечение, в том числе СУБД, различные фреймворки и прочее.

Использовать ПО из проверенных источников.

Рекомендуем перед загрузкой установочного пакета программного обеспечения, в том числе и Open Source, убедиться в надежности источника. Нередко бывает так, что визуально похожий на официальный сайт ресурс, распространяет уже скомпрометированое ПО. В пакет установки может быть добавлен файл с вредоносным кодом.

Грамотно настроить межсетевой экран.

Важно понимать, что сервер доступен из сети Интернет. По этой причине, ОС должна быть защищена любым устройством выполняющим функции файрволла. Если подобных устройств нет, то Брандмауэр Windows будет последней надеждой на защиту от несанкционированных подключений к серверу.

Чем меньше TCP/UDP портов доступно извне, тем меньше шансов провести атаку на сервер. В этом вопросе важно разобраться что блокировать. Если речь идет о web-сервере, то доступными необходимо оставить 80 и 443 TCP-порты (эти порты служба слушает по умолчанию).

Это были публичные порты, но не стоит забывать, что существуют порты, доступ к которым должен предоставляться по принципу “белого” списка, т.е. только определенному кругу лиц. Пример портов:

3389 - RDP (Remote Desktop Protocol);
135-139 - NetBIOS;
445 - Samba (общий доступ к файлам и папкам);
5000 - 5050 - FTP в пассивном режиме;
1433 - 1434 - порты SQL;
3306 - стандартный порт MySQL;
53 - DNS

Создать правило не сложно. Открываем Пуск → Панель управления → Система и безопасность → Администрирование → Брандмауэр Windows в режиме повышенной безопасности.

В окне программы кликаем правой кнопкой мыши по “Правила для входящих подключений”. В открывшемся контекстном меню выбираем “Создать правило...”.

Переименовать учетную запись администратора.

Использовать несколько аккаунтов администратора.

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

Использовать учетную запись пользователя с ограниченными правами.

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

В случае несанкционированного доступа под учетной записью администратора, злоумышленник получит полный доступ к системе.

Ограничить общий доступ к файлам и папкам, включить защиту паролем.

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

Кроме использования парольной защиты, рекомендуем ограничить разных пользователей в уровне доступа как к файлам, так и папкам (чтение, запись, изменение).

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

При использовании физического сервера (не удаленного и не виртуального), рекомендуется включить запрос пароля пользователя при выходе из режима ожидания. Данный параметр настраивается в панели управления: Панель управления → Все элементы панели управления → Электропитание.

Также важно установить лимиты бездействия пользователя, а “по возвращении” запросить пароль. Это исключит возможность входа другого лица от имени пользователя, в случае если тот отлучился или забыл закрыть RDP-сессию. Чтобы настроить этот пункт, следует воспользоваться настройкой локальных политик secpol.msc.

Использовать Мастер настройки безопасности.

Мастер настройки безопасности (SCW – Security Configuration Wizard) позволяет создавать XML-файлы политик безопасности, которые впоследствии, можно перенести на другие серверы. Эти политики включают в себя не только правила использования сервисов, но и общие параметры системы и правила Firewall.

Корректно настроить политики безопасности.

Кроме первоначальной настройки групповых политик Active Directory, периодически следует проводить их ревизию и повторную настройку. Это один из основных способов обеспечения безопасности Windows-инфраструктуры.

Использовать локальные политики безопасности.

Кроме использования групповых политик безопасности Active Directory следует использовать и локальные политики, которые затрагивают права как удаленных пользователей, так и локальные аккаунты.

Защитить службу удаленных рабочих столов (RDP).

1. Блокировать RDP-подключения для пользователей с пустым паролем.

Наличие пользователей без паролей недопустимо, но если этого миновать не удается, то можно хотя бы запретить подключение к RDP. Для этого открываем Пуск → Средства администрирования.

В открывшемся каталоге, запускаем Локальная политика безопасности.

В окне локальный политик безопасности, слева, выбираем Локальные политики → Параметры безопасности. В основной части окна, находим “Учетные записи: Разрешить использование пустых паролей только при консольном входе”.

Выбираем этот пункт двойным кликом и переводим переключатель в положение “Отключен”. Нажимаем кнопку “OK”.

2. Поменить стандартный TCP-порт RDP.

Замена номеров TCP-портов стандартных сервисов на другие значения, вполне может повысить безопасность сервера, главное не забыть новый номер порта.

Для замены порта:

1. открываем редактор Реестра Windows - Windows + R

2. На всякий случай, создаем резервную копию реестра (Файл → Экспорт)

3. Разворачиваем ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp и, в правой доле окна, находим параметр PortNumber.

4. Открываем параметр двойным кликом мыши. В открывшемся окне выбираем Систему исчисления: Десятичная, указываем новое значение порта, нажимаем кнопку “OK” и закрываем окно редактора реестра.

5. Чтобы была возможность подключиться к серверу, создаем соответствующее правило для Брандмауэра Windows. Кликаем правой кнопкой мыши по “Правила для входящих подключений”, в контекстном меню выбираем “Создать правило”.

В окне “Мастера”, выбираем “Для порта”

Затем выбираем “Протокол TCP”, “Определенные локальные порты” и указываем новый номер порта.

Следующим шагом выбираем “Разрешить подключение”

Настраиваем для каких сетей будет действовать правило, нужное отмечаем галками.

На итоговом шаге, указываем название правила и описание к нему.

6. Перезагружаем сервер чтобы применить изменения.

7. Для подключения к удаленному рабочему столу теперь используем IP-адрес или доменное имя, а через двоеточие указываем порт.

Настроить шлюз службы терминалов.

Пользователи или группы пользователей, которым разрешено подключаться к внутренним сетевым ресурсам;
Сетевые ресурсы, к которым могут подключаться пользователи;
Должны ли клиентские компьютеры иметь членство в Active Directory;
Необходимо ли клиентам использовать проверку подлинности на основе смарт-карт или пароля, или они могут использовать один из вышеперечисленных способов аутентификации.

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

Установим службу шлюза TS.

1. Открываем Диспетчер серверов.

2. Выбираем “Добавить роли и компоненты”

3. На этапе “Тип установки”, выбираем “Установка ролей и компонентов.

4. Следующим шагом выбираем текущий сервер.

5. Роль сервера - Служба удаленных рабочих столов.

6. Переходим к службе ролей. Выбираем “Шлюз удаленных рабочих столов”.

7. Переходим к этапу подтверждения, нажимаем кнопку “Установить”.

Устанавливаем SSL-сертификат.

После установки роли, в окне Диспетчера серверов, выбираем Средства → Remote Desktop Services → Диспетчер шлюза удаленных столов.

В открывшемся окне, в левой его части, нажимаем по значку сервера. В основной части окна, выбираем “Просмотр и изменение свойств сертификата”.

В открывшемся окне “Свойства” переходим на вкладку “Сертификат SSL”. Выбираем пункт “Создать самозаверяющий сертификат”, нажимаем кнопку “Создать и импортировать сертификат”.

Если у вас есть созданный ранее сертификат, можно воспользоваться одним из пунктов ниже, в зависимости от того, кем он был выдан.

В новом окне следует проверить параметры. Если все верно - нажимаем “OK”.

Новым окном система оповестит об успешном создании сертификата и выдаст путь до файла.

Переходим к окну свойств сервера. Нажимаем “Применить”.

Остается только настроить групповые политики.

В окне “Диспетчер шлюза удаленных рабочих столов”, в левой колонке, раскрываем ветку сервера, выбираем “Политики”, затем “Политики авторизации подключений”. В правой колонке того же окна, выбираем “Создать новую политику” → “Мастер”.

В новом окне выбираем ”Создать только политику авторизации подключений к удаленным рабочим столам”, нажимаем “Далее”.

Указываем желаемое имя для политики. Мы рекомендуем указывать имя латиницей.

Следующим шагом будет выбор удобного метода аутентификации - пароль или смарт-карта. Оставляем отмеченным только “Пароль”. Нажимаем кнопку “Добавить группу. ”

В окне выбора групп кликаем по кнопке “Дополнительно”.

Размер окна изменится. Кликаем по кнопке “Поиск”. В найденных результатах выбираем “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем этапе выбираем пункт “Включить перенаправление устройств для всех клиентских устройств” и нажимаем “Далее”.

Настраиваем таймауты сессий. И действия по их истечении. Рекомендуем отключать сеанс, чтобы фоновые пользовательские процессы не отнимали процессорное время. Нажимаем “Далее”.

На крайнем этапе просматриваем сводку, нажимаем “Готово”.
На подтверждение создания политики нажимаем “Закрыть”.

Настроим политику авторизации ресурсов.

Процесс выполняется подобно предыдущему.

В окне диспетчера шлюза удаленных рабочих столов, раскрываем ветку Политики → Политики авторизации подключений. В правой части окна выбираем “Создать новую политику” → “Мастер”.

В открывшемся окне выбираем “Создать только политику авторизации ресурсов удаленных рабочих столов”, нажимаем кнопку “Далее”.

Первым шагом указываем желаемое имя для политики авторизации. Настоятельно рекомендуем указывать имя латиницей. Нажимаем кнопку “Далее”.

В окне выбора групп кликаем по кнопке “Дополнительно”.

Окно изменит размеры. Нажимаем кнопку “Поиск”. В результатах поиска находим “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем шаге разрешаем подключение пользователей к любому сетевому ресурсу. Для этого выбираем соответствующий параметр и нажимаем кнопку “Далее”.

Настраиваем разрешенные порты. сли порт RDP-сервера не был изменен, то оставляем 3389. Нажимаем “Далее”.

Финальным этапом проверяем настройки и нажимаем кнопку “Готово”.

В обновленном окне нажимаем “Закрыть”.

Изолировать серверные роли. Отключить неиспользуемые сервисы.

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

Идеальный случай - один сервер выполняет одну конкретную функцию, например Контроллер домена или файловый сервер, или сервер терминалов. На практике, подобное разделение ролей труднодостижимо.

Обзор Windows Nano Server.

Дальнейшим развитием Windows Server Core стал Nano Server. Данная версия дистрибутива исключает использование графического интерфейса пользователя. Всё управление сосредоточено на WMI - инструментарий управления Windows, а также Windows PowerShell. Данный дистрибутив Windows-сервер имеет на 92% меньше критических рекомендаций безопасности. Nano Server доступен только для клиентов Microsoft Software Assurance и на платформах облачных вычислений, например, Microsoft Azure и Amazon Web Services. Начиная со сборки Windows Server 1709, Nano Server можно устанавливать только внутри хоста контейнера .

Презентация на тему: " Реализация защиты серверов ДокладчикMicrosoft. Содержание Основа безопасности серверов Основа безопасности серверов Безопасность Active Directory и защита." — Транскрипт:

1 Реализация защиты серверов ДокладчикMicrosoft

2 Содержание Основа безопасности серверов Основа безопасности серверов Безопасность Active Directory и защита контроллеров домена Безопасность Active Directory и защита контроллеров домена Защита серверов с помощью шаблонов безопасности и групповых политик Защита серверов с помощью шаблонов безопасности и групповых политик

3 Принципы безопасности серверов Принципы безопасности Конфиденциальность Конфиденциальность Защита информации от несанкционированного доступа Защита информации от несанкционированного доступа Целостность Целостность Защита информации от несанкционированной модификации Защита информации от несанкционированной модификации Доступность Доступность Надежная и бесперебойная работа информационных ресурсов Надежная и бесперебойная работа информационных ресурсов

5 Моделирование угроз Анализ окружения и конфигураций Анализ окружения и конфигураций Базовые системы и программное обеспечение Базовые системы и программное обеспечение Диаграммы потоков данных и взаимодействия систем Диаграммы потоков данных и взаимодействия систем Сегрегация систем по задачам и требованиям безопасности Сегрегация систем по задачам и требованиям безопасности Определение доверяемых систем Определение доверяемых систем Уровни доверия Уровни доверия Ограничение окружения и привилегий Ограничение окружения и привилегий Минимально допустимые права и привилегии Минимально допустимые права и привилегии Службы и порты, необходимых для работы Службы и порты, необходимых для работы Защита коммуникаций между системами и пользователями Защита коммуникаций между системами и пользователями Компромисс Компромисс Баланс между защищенностью системы и удобством работы с ней Баланс между защищенностью системы и удобством работы с ней

7 Лучшие практики по защите серверов Лучшие практики по защите серверов Своевременно устанавливать все обновления и исправления Объединять серверы по ролям и использовать Групповые политики для централизованной настройки защиты Отключить ненужные службы, переименовать встроенные учетные записи и ограничить их привилегии Ограничить физический и сетевой доступ к серверам

8 Базовые рекомендации Переименовать встроенные учетные записи Administrator и Guest Переименовать встроенные учетные записи Administrator и Guest Изменить их пароли и описания Изменить их пароли и описания Ограничить права доступа к системе для служебных учетных записей Ограничить права доступа к системе для служебных учетных записей Administrator, Support_388945a0, Guest Administrator, Support_388945a0, Guest Не использовать для работы сервисов доменные учетные записи Не использовать для работы сервисов доменные учетные записи Использовать средства файловой системы NTFS для защиты файлов и папок Использовать средства файловой системы NTFS для защиты файлов и папок

9 Содержание Основа безопасности серверов Основа безопасности серверов Безопасность Active Directory и защита контроллеров домена Безопасность Active Directory и защита контроллеров домена Защита серверов с помощью шаблонов безопасности и групповых политик Защита серверов с помощью шаблонов безопасности и групповых политик

10 Компоненты Active Directory Лес Лес Функционирует как периметр безопасности Active Directory Функционирует как периметр безопасности Active Directory Домен Домен Организационное подразделение Организационное подразделение Групповые политики Групповые политики Основной инструмент для настройки системы безопасности Основной инструмент для настройки системы безопасности

11 Политика домена Применение и наследование Групповых политик Локальная политика Политики родительских ОП Политика своего ОП Политика сайта Если контейнеру назначено несколько политик, то они применяются поочередно, снизу вверх по списку

12 Демонстрация Управление Групповыми политиками

13 Защита Active Directory Анализ инфраструктуры Анализ инфраструктуры Централизованная интранет-структура Централизованная интранет-структура Удаленный офис Удаленный офис Распределенная экстранет-структура Распределенная экстранет-структура Анализ угроз Анализ угроз Определение угроз Определение угроз Определение типов угроз Определение типов угроз Определение источников угроз Определение источников угроз Выработка мер защиты от угроз Выработка мер защиты от угроз Создание детального плана действий на случай вторжения/атаки Создание детального плана действий на случай вторжения/атаки

14 Угрозы службе каталогов Цель атакующего: Цель атакующего: Изменить поведение системы/контроллера Изменить поведение системы/контроллера Установка специальных программ Установка специальных программ Модификация базы данных каталога Модификация базы данных каталога Подключение отладчика к процессу LSA Подключение отладчика к процессу LSA Для достижения цели нужно Для достижения цели нужно Получить физический доступ к контроллеру домена Получить физический доступ к контроллеру домена Получить права администратора служб Получить права администратора служб У каждой компьютерной системы есть администратор… У каждой компьютерной системы есть администратор…

15 Угрозы службе каталогов Анонимный пользователь Аутентифицированный пользователь Физический доступ Сетевые ресурсы Корневой домен Администратор данных Администратор служб Контроллер домена a b.a

16 Защита на уровне домена Групповая политика для домена Групповая политика для домена Модификация Default Domain Policy GPO или создание новой политики для домена Модификация Default Domain Policy GPO или создание новой политики для домена Политика паролей, учетных записей, параметры протокола Kerberos Политика паролей, учетных записей, параметры протокола Kerberos Аудит системных разделов Active Directory Аудит системных разделов Active Directory Разделение администраторов по категориям Разделение администраторов по категориям Администраторы служб Администраторы служб Администраторы данных Администраторы данных Строгое делегирование и контроль административных полномочий Строгое делегирование и контроль административных полномочий

17 Группировка серверов Иерархия организационных подразделений Иерархия организационных подразделений Отдельный контейнер для каждой роли Отдельный контейнер для каждой роли Специальные групповые политики для каждой роли Специальные групповые политики для каждой роли Встроенный контейнер для контроллеров домена Встроенный контейнер для контроллеров домена Групповая политика Default Domain Controllers Policy Групповая политика Default Domain Controllers Policy Domain Policy Domain Member Server Baseline Policy Member Servers Domain Controllers Domain Controllers Policy Print Server Policy File Server Policy IIS Server Policy Print Servers File Servers Web Servers Operations Admin Web Service Admin

18 Важные параметры защиты контроллеров домена Настройка По умолчанию Высокая безопасность Доступ к компьютеру по сети Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS, Everyone, Pre- Windows 2000 Compatible Access Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS Разрешена регистрация локально Administrators, Account Operators, Backup Operators, Print Operators, Server Operators Administrators Восстановление файлов и каталогов Administrators, Backup Operators, Server Operators Administrators SYSKEY Ключ создается системой и хранится локально на машине Режим 1. Администратор задает пароль и вводит его при старте Режим 1. Администратор задает пароль и вводит его при старте Режим 2. Ключ создается системой и хранится на дискете Режим 2. Ключ создается системой и хранится на дискете

19 Демонстрация Защита контроллера с помощью SYSKEY

20 Лучшие практики по защите контроллеров Лучшие практики по защите контроллеров Создавать и настраивать контроллеры домена только в защищенном окружении Установить и соблюдать жесткие правила установки и восстановления контроллеров Установить требуемые параметры защиты в Групповой политике для контроллеров домена Обеспечить физическую защиту контроллеров

21 Содержание Основа безопасности серверов Основа безопасности серверов Безопасность Active Directory и защита контроллеров домена Безопасность Active Directory и защита контроллеров домена Защита серверов с помощью шаблонов безопасности и групповых политик Защита серверов с помощью шаблонов безопасности и групповых политик

23 Bastion Hosts Порядок защиты серверов Защита Active Directory Применение Member Server Baseline Policy Применение ролевых политик Certificate Services ServersRADIUS (IAS) ServersIIS ServersFile & Print ServersInfrastructure Servers

24 Member Server Baseline Security Базовый шаблон для всех серверов, включенных в домен определяет: Базовый шаблон для всех серверов, включенных в домен определяет: Политику аудита Политику аудита Права пользователей Права пользователей Параметры безопасности Параметры безопасности Настройки журналов Настройки журналов Настройки системных служб Настройки системных служб Domain Policy Domain Member Server Baseline Policy Member Servers Domain Controllers Domain Controllers Policy Print Server Policy File Server Policy IIS Server Policy Print Servers File Servers Web Servers Operations Admin Web Service Admin

27 Защита серверов инфраструктуры Готовый шаблон безопасности для ОП Infrastructure Servers Готовый шаблон безопасности для ОП Infrastructure Servers Рекомендуемые дополнительные настройки (где требуется): Рекомендуемые дополнительные настройки (где требуется): Журнал сервера DHCP Журнал сервера DHCP Защита от DoS-атак на сервер DHCP Защита от DoS-атак на сервер DHCP Настройка режима зон DNS Настройка режима зон DNS Active Directory-integrated Active Directory-integrated Учетные записи для сервисов Учетные записи для сервисов Блокировка ненужных портов с помощью фильтров IPSec Блокировка ненужных портов с помощью фильтров IPSec

28 Защита файловых серверов Готовый шаблон безопасности для ОП File Servers Готовый шаблон безопасности для ОП File Servers Рекомендуемые дополнительные настройки: Рекомендуемые дополнительные настройки: Отключить службы DFS и FRS, если они не используются Отключить службы DFS и FRS, если они не используются Назначить строгие права доступа к сетевым каталогам Назначить строгие права доступа к сетевым каталогам Аудит доступа к критичным файлам Аудит доступа к критичным файлам Регистрировать как успешные, так и неуспешные попытки доступа Регистрировать как успешные, так и неуспешные попытки доступа

33 Демонстрация Импорт, анализ и применение ролевых шаблонов безопасности

34 Лучшие практики защиты ролевых серверов Лучшие практики защиты ролевых серверов Защита известных встроенных учетных записей Включены должны быть только те сервисы, которые необходимы для конкретной роли Включить журнал работы сервисов Персональная модификация шаблонов для серверов, выполняющих одновременно несколько ролей Блокировка ненужных портов с помощью фильтров IPSec

35 Информация Информационный ресурс Microsoft по безопасности Информационный ресурс Microsoft по безопасности Для профессионалов IT: Для профессионалов IT: На русском языке: На русском языке: Руководства Microsoft по защите серверов Руководства Microsoft по защите серверов default.asp?url=/technet/security/prodtech/ win2003/w2003hg/sgch00.asp default.asp?url=/technet/security/prodtech/ win2003/w2003hg/sgch00.asp default.asp?url=/technet/security/prodtech/ win2003/w2003hg/sgch00.asp default.asp?url=/technet/security/prodtech/ win2003/w2003hg/sgch00.asp

применимо к: Windows Server 2022, Windows server 2019, Windows Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows 7, Windows server 2003, Windows server 2008, Windows server 2008 R2, Windows Vista

в этой статье для ит professional объясняется, как Windows реализует пароли в версиях Windows, начиная с Windows Server 2012 и Windows 8.1. В нем также обсуждаются надежные пароли, парольные фразы и политики паролей.

Как хранятся пароли в Windows

В этой статье приводятся сведения о хранении неактивных паролей.

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

операционная система Windows хранит пароли множеством различных способов для разных целей.

Пароли, хранящиеся в формате OWF

для использования в Windows сети, в том числе Active Directory доменах, по умолчанию пароли хранятся двумя разными способами: как односторонняя функция LAN Manager (LM OWF) и как NT owf. "Односторонняя функция" — это термин, который обозначает односторонняя математическое преобразование данных. Преобразуемые данные могут быть преобразованы только с помощью шифрования и не могут быть отменены. Наиболее распространенным типом односторонней функции является криптографический хэш. Хэш — это небольшой набор данных, которые математически привязаны к большому набору данных, из которого вычисляется хэш. Если изменяется больший набор данных, хэш также изменяется. Хэши полезны, например, в качестве контрольной суммы, чтобы убедиться, что данные не были изменены при передаче. Криптографический хэш — это хэш, выполняющий определенные свойства. Криптографический хэш должен, например, быть создан таким образом, чтобы он был математически невозможным в разумное время для определения большего набора данных только из хэша. Аналогично, он математически не может найти два набора больших данных, которые создают один и тот же хэш.

Существует множество различных типов односторонних функций. Все хэш-функции — это, по определению, односторонние функции. Однако обычные криптографические функции, которые обычно являются обратимыми, можно также использовать для создания односторонней функции. Это можно сделать путем переключения данных и ключа в криптографической функции и шифрования фиксированного значения (ключа) с помощью данных в качестве ключа. Таким способом вычисляются хэш-значения LM. Хэш LM вычисляются следующим образом:

Пароль дополняется ПУСТЫМи байтами до 14 символов. Если длина пароля превышает 14 символов, она заменяется на 14 байт NULL для оставшихся операций.
Пароль преобразуется в верхний регистр.
Пароль разбивается на 2 7-байтовые (56-битные) ключи.
Каждый ключ используется для шифрования фиксированной строки.
Два результата, полученные на шаге 4, объединяются и сохраняются как хэш LM.

алгоритм LM OWF включен в Windows для обеспечения обратной совместимости с программным обеспечением и оборудованием, которые не могут использовать новые алгоритмы.

Хэш NT — это просто хэш. Пароль хэшируется с помощью алгоритма MD4 и сохраняется. NT OWF используется для проверки подлинности членами домена в Windows NT 4,0 и более ранних доменах и в Active Directory доменах.

Ни хэш NT, ни хэш LM не являются Salt-кодом. Расширяющее значение — это процесс, объединяющий пароль со случайным числовым значением (соль) перед вычислением односторонней функции.

Пароли, хранящиеся в Active Directory

Несохраненные пароли хранятся в нескольких атрибутах базы данных Active Directory (NTDS. Файл DIT). Эти атрибуты перечислены в следующей таблице.

Атрибут Active Directory	Содержимое
unicodePwd	Зашифрованный хэш NT
дбкспвд	Зашифрованный хэш LM
нтпвдхистори	Зашифрованные хэши NT — журнал паролей
лмпвдхистори	Зашифрованные хэши LM — журнал паролей
супплементалкредентиалс	Ключи Kerberos, WDigest и т. д.

хранение хэшей LM по умолчанию отключено, так как Windows Vista и Windows Server 2008.

При сохранении в файл DIT хэш NT защищается двумя уровнями шифрования. в Windows Server 2016 и Windows 10 и более поздних версиях он сначала шифруется с помощью DES для обратной совместимости, а затем с помощью cng BCrypt AES-256 (см. cngBCRYPT_AES_ALGORITHM). предыдущие версии Windows шифруют хэши NT, используя два уровня шифрования DES + RC4.

Дополнительные сведения о дополнительных учетных данных см. в разделе MS-SAMR: супплементалкредентиалс и Дополнительные структуры учетных данных.

Пароли, хранящиеся в локальном SAM

На членах домена и рабочих станциях хэши паролей учетных записей локальных пользователей хранятся в локальной базе данных диспетчера учетных записей безопасности (SAM), расположенной в реестре. Они шифруются с помощью тех же алгоритмов шифрования и хэширования, что и Active Directory. Пароли в атрибуте Супплементалкредентиалс для локальных учетных записей пользователей также хранятся в локальной базе данных SAM с момента Windows Server 2016.

Кэшированные учетные данные

Windows также сохраняет средство проверки паролей в членах домена, когда пользователь домена входит в этот домен. Это средство проверки можно использовать для проверки подлинности пользователя домена, если компьютер не может получить доступ к контроллеру домена. Средство проверки паролей также обычно называется кэшированными учетными данными. Он выдается путем создания хэша NT, сцепления имени пользователя с ним и последующего хэширования результата с помощью хэш-функции MD4.

Как работают пароли в Windows

в Windows и многих других операционных системах одним из способов проверки подлинности удостоверения пользователя является использование секретной парольной фразы или пароля.

мы рекомендуем использовать безопасную многофакторную проверку подлинности, такую как смарт-карта, FIDO и Windows Hello для бизнеса. Однако в некоторых сценариях все еще требуется проверка подлинности паролей.

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

Параметры политики паролей определяют сложность и время существования паролей. политики паролей влияют Windows пароли, а не обязательно являются паролями функций.

Возможность изменения паролей пользователями регулируется политиками паролей и доступными интерфейсами. Например, в безопасном рабочем столе пользователи могут изменить пароль в любое время в зависимости от политик паролей, администрируемых администратором или администратором домена. такие функции, как Windowsное хранилище, BitLocker и шифрованная файловая система (EFS), позволяют пользователям изменять пароли, относящиеся к этой функции.

Использование паролей в Windows

При входе пользователя в систему пароль, определяемый пользователем, преобразуется в оба типа односторонних функций и удерживается в памяти процессом служба LSASS (LSASS). Если пользователь использует локальную учетную запись для проверки подлинности, NT OWF сравнивается с локально сохраненным хэшем NT, и если эти два совпадения, пользователь вошел в систему. Если пользователь проходит проверку подлинности в домене Active Directory, используя имя узла для доступа к ресурсу, то хэш NT используется в входе Kerberos для центр распространения ключей (KDC), который обычно является контроллером домена.

Kerberos не может использоваться в следующих ситуациях:

проверка подлинности в домене, работающем только Windows NT 4,0 или более ранней версии
Доступ к ресурсу в Active Directory члене домена с помощью IP-адреса, а не имени узла
Доступ к ресурсу на компьютере, который не является членом домена Active Directory
Доступ к ресурсу на компьютере, который является членом домена Active Directory, но не является доверенным для вашего домена
Доступ к любому ресурсу на компьютере, на котором выполняется, не поддерживающий протокол Kerberos

В таких ситуациях в процессе проверки подлинности используются два разных протокола, называемые LAN Manager и NTLM. Процесс начинается с клиента, запрашивающего запрос от сервера проверки подлинности. После получения запроса клиент вычислит ответ на эту проблему. Для этого сначала необходимо выполнить заполнение двух хэшей пароля со значениями null до 168 бит. Затем 168 бит каждого хэша разбивается на 3 56-битные ключи DES. После этого для шифрования запроса используются шесть ключей DES. Три текста шифров, созданных с помощью хэша LM, объединяются и становятся ответами диспетчера LAN. Три текста шифров, созданных с помощью хэша NT, объединяются и становятся ответами NTLM.

Функции, используемые для расчета ответа, могут быть изменены с помощью параметра уровень совместимости LM , установленного на уровне проверки подлинности Network Security: LAN Manager групповая политика. Если это значение равно 1 или ниже, клиент будет отправлять исходный диспетчер LAN и ответы NTLM. Если задано значение 2, отправляется только ответ NTLM. Если задано значение 3 или выше, используется новая версия обоих протоколов. Версия NTLM называется NTLMv2. Версия диспетчера LAN часто называется LMv2. Оба протокола используют хэш NT для вычисления ответа и используют запрос на стороне клиента, а не или в дополнение к запросам к серверу. Кроме того, если для параметра уровень совместимости LM задано значение 1 или выше, то время ответа NTLM будет отмечаться для предотвращения атак с помощью воспроизведения. Дополнительные сведения о настройке уровня совместимости LM см. в разделе Сетевая безопасность: уровень проверки подлинности LAN Manager.

Надежные пароли

Пароли обеспечивают первую линию защиты от несанкционированного доступа к вашей организации. начиная с Windows Server 2003 Windows проверяет сложность пароля для учетной записи администратора во время установки операционной системы. если пароль пуст или не соответствует требованиям сложности, в диалоговом окне программа установки Windows предлагается создать надежный пароль для учетной записи администратора. Если оставить этот пароль пустым, доступ к этой учетной записи по сети будет невозможен.

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

Пример надежного пароля — J * p2leO4 > F.

Пароль может соответствовать большинству критериев надежного пароля, но он по-прежнему является слабым. Например, Hello2U! — Это относительно ненадежный пароль, хотя он удовлетворяет большинству критериев для надежного пароля и соответствует требованиям к сложности политики паролей. H! elZl2o является надежным паролем, так как словарное слово вместе с символами, цифрами и другими буквами. Важно рассказать пользователям о преимуществах использования надежных паролей и научиться создавать пароли, которые действительно являются надежными.

Можно создавать пароли, содержащие символы из расширенной кодировки ANSI. Использование расширенных символов ANSI увеличивает количество символов, которое можно выбрать при создании пароля. В результате для взлома паролей, содержащих эти расширенные символы ANSI, может потребоваться больше времени, чем для взлома других паролей. Прежде чем использовать расширенные символы ANSI в пароле, тщательно протестируйте их, чтобы убедиться, что пароли, содержащие расширенные символы ANSI, совместимы с приложениями, используемыми в Организации. Будьте внимательны при использовании расширенных символов ANSI в паролях, если в организации используется несколько различных операционных систем. Например, эти системы могут стандартизировать в стандарте ISO-8859-15. фактическая реализация протокола в Windows часто использует юникод или UTF8 вместо фактической кодировки ANSI.

Парольные фразы в Windows

Парольная фраза — это другая форма пароля на основе токена, в которой маркеры являются словами, а не символами из кодировки. Примером парольной фразы является предложение, содержащее специальные символы, цифры, прописные буквы и строчные буквы. Ключевые отличия между парольными фразами и паролями:

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

Парольные фразы, которые соответствуют ограничению символов, как задано в политике, обычно являются более трудными для взлома, чем пароли, так как они содержат больше символов. Это хэш LM и NT, в котором хранится пароль или парольная фраза, а хэш LM — слабый из двух.

Существует несколько способов убедиться, что хэш LM не сохранен. одним из них является использование паролей или парольных фраз длиннее 14 символов. Также можно использовать параметр Сетевая безопасность: не хранить значение ХЭША LAN Manager при следующей смене пароля групповая политика. При использовании этого параметра политики глобально отключаются хэши хранилища LM для всех учетных записей. Изменение вступит в силу при следующем изменении пароля. Так как последствия политики не вступают в силу немедленно, вы не заметите потенциальные проблемы взаимодействия, вызванные отсутствием сохранения хэшей LM.

Локальные политики паролей, доступные в Windows

Можно реализовать параметр политики паролей, который обеспечивает требования к сложности пароля. Дополнительные сведения об этом параметре политики см. в разделе пароль должен отвечать требованиям сложности. Сведения о применении политики паролей см. в статье применение или изменение политики паролей. Сведения обо всех доступных параметрах политики паролей см. в разделе Политика паролей.

Детально детализированная политика паролей, доступная в домен Active Directory Services (AD DS)

начиная с Windows Server 2008 можно использовать детальные политики паролей, чтобы указать несколько политик паролей и применить разные ограничения паролей и политики блокировки учетных записей к разным наборам пользователей в пределах одного домена. Например, чтобы повысить безопасность привилегированных учетных записей, можно применить более четкие параметры к привилегированным учетным записям, а затем применить менее ограниченные параметры к учетным записям других пользователей. Или в некоторых случаях может потребоваться применить специальную политику паролей для учетных записей, пароли которых синхронизируются с другими источниками данных.

Для хранения детализированных политик паролей в схеме AD DS существуют два новых класса объектов:

контейнер параметров паролей
Параметры пароля

Дополнительные сведения об этих политиках см. в разделе AD DS: Fine-Grained политики паролей.

Создавая инфраструктуру для обслуживания приложения, нужно обязательно учитывать вопросы безопасности.

В этой статье вы найдете советы и рекомендации по защите серверов.

1: SSH-ключи

Пара криптографических SSH-ключей обеспечивает беспарольную аутентификацию. Открытый и закрытый ключ нужно создать заранее. Закрытый ключ следует хранить в тайне, а открытый можно разглашать.

Чтобы настроить аутентификацию на основе SSH-ключей, поместите открытый ключ пользователя на сервер в специальном каталоге. Когда пользователь подключается к серверу, сервер запрашивает закрытый ключ, связанный с имеющимся открытым ключом. Клиент SSH должен предоставить закрытый ключ, чтобы пройти аутентификацию. Если предоставленный закрытый ключ прошел проверку, клиент сможет подключиться без пароля.

Влияние SSH-ключей на безопасность

SSH-ключи шифруют любую аутентификацию, в том числе и парольную. Однако если сервер поддерживает парольную аутентификацию, злоумышленники могут попытаться подобрать пароль и получить доступ к серверу. Благодаря современным вычислительным технологиям можно автоматизировать подбор паролей.

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

Реализация SSH-ключей

SSH-ключи очень просты в реализации. Кроме того, этот метод аутентификации является рекомендуемым для удаленного доступа к серверам Linux и Unix. Вы можете сгенерировать пару ключей SSH на своей локальной машине, а затем переместить открытый ключ на сервер.

Больше информации об SSH-ключах можно найти здесь:

Как настроить SSH-ключи
Создание центра сертификации SSH для аутентификации хостов и клиентов на сервере Ubuntu
Настройка многофакторной аутентификации SSH на Ubuntu 16.04

2: Брандмауэр

Брандмауэр – это программное (иногда аппаратное) обеспечение, которое управляет доступом к сети и фильтрует трафик сервера. Брандмауэр блокирует или ограничивает доступ ко всем портам, кроме некоторых исключений.

На любом среднестатистическом сервере есть сервисы, которые запускаются по умолчанию. Их можно разделить на три группы:

Открытые сервисы, к которым могут обращаться любые пользователи интернета, включая анонимных. Хорошим примером открытого сервиса является веб-сервер, который обеспечивает доступ к сайту.
Закрытые сервисы, доступ к которым есть только из определенных мест и у отдельных групп авторизованных пользователей (например, таким сервисом является панель управления базой данных).
Внутренние сервисы, которые должны быть доступны только с самого сервера, без доступа к сети. Таким сервисом является база данных, которая принимает только локальные соединения.

Брандмауэры ограничивают доступ в соответствии с приведенными выше категориями. Открытые сервисы могут оставаться доступными для всех, а закрытые могут быть заблокированы на основе разных критериев. Доступ к портам, которые не используются ни одним приложением, в большинстве случаев блокируется полностью.

Влияние брандмауэров на безопасность

Брандмауэр – неотъемлемая часть настройки любого сервера. Даже если используемые сервисы предоставляют встроенные функции безопасности, брандмауэр послужит дополнительным уровнем защиты.

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

Реализация брандмауэра

Для систем Linux разработано много брандмауэров. Чаще всего настройка брандмауэра занимает всего несколько минут; это необходимо сделать во время начальной настройки сервера или при добавлении новых сервисов.

3: VPN, или виртуальные частные сети

Частные сети – это сети, доступные только определенным серверам или пользователям.

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

Влияние VPN на безопасность

Между частной и общей сетью всегда рекомендуется выбирать первую. Но имейте в виду: поскольку другие пользователи в центре обработки данных имеют доступ к одной и той же сети, необходимо принять дополнительные меры для обеспечения безопасной связи между серверами.

VPN – это, по сути, способ построить частную сеть, которую могут видеть только ваши серверы. Взаимодействие серверов будет полностью конфиденциальным и безопасным. Другие приложения можно настроить для передачи трафика через виртуальный интерфейс VPN. Таким образом, клиенты смогут получить доступ только к тем сервисам, которые настроены для поддержки соединений из интернета.

Реализация VPN

Реализовать частную сеть в ЦОД с поддержкой таких сетей довольно просто.

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

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

4: Шифрование SSL/TLS

Инфраструктура открытых ключей – это система, которая предназначена для создания, управления и проверки сертификатов для идентификации пользователей и шифрования связи. Сертификаты SSL или TLS можно использовать для аутентификации разных объектов. После аутентификации сертификаты также могут обеспечить шифрование связи.

Влияние SSL/TLS на безопасность

Создание центра сертификации и управление сертификатами серверов позволяет каждому объекту инфраструктуры проверять идентичность пользователей и шифровать их трафик. Это может предотвратить атаки man-in-the-middle, во время которых злоумышленник имитирует сервер в инфраструктуре для перехвата трафика.

Все серверы инфраструктуры могут доверять тому или иному центру сертификации.

Реализация TLS/SSL

Настройка центра сертификации и инфраструктуры открытых ключей может включать в себя довольно много различных этапов. Управление сертификатами требует отдельного внимания: сертификаты необходимо своевременно создавать, подписывать и отзывать.

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

5: Аудит сервисов

Ранее мы рассмотрели несколько технологий для повышения безопасности. Однако безопасность во многом зависит от анализа системы, понимания её уязвимостей и своевременного устранения ошибок.

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

Аудит сервисов позволяет узнать, какие сервисы работают в системе, какие порты и протоколы они используют. Эта информация может помочь настроить брандмауэр.

Влияние на безопасность

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

Ознакомившись с сервисами, вы можете проанализировать их. Для этого подойдет такой список вопросов:

Должен ли быть запущен этот сервис?
Работает ли он на интерфейсах, которые ему не нужны?
Привязан ли он к одному IP?
Пропускает ли брандмауэр трафик этого сервиса?
Можете ли вы получать оповещения об уязвимостях каждого из этих сервисов?

Аудит сервисов должен быть частью стандартной настройки любого нового сервера в инфраструктуре.

Реализация аудита сервисов

Выполнить базовый аудит сервисов совсем не сложно. С помощью команды netstat можете узнать, какой сервис прослушивает те или иные порты на каждом интерфейсе.

Эта команда выведет имя программы, PID и адреса, на которых прослушивается трафик TCP и UDP.

sudo netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 887/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/nginx
tcp6 0 0 . 22 . * LISTEN 887/sshd
tcp6 0 0 . 80 . * LISTEN 919/nginx

Основное внимание нужно уделить столбцам Proto, Local Address и PID/Program name. 0.0.0.0 значит, что сервис принимает соединения на всех интерфейсах.

6: Аудит файлов и системы обнаружения вторжений

Аудит файлов – это процесс сравнения текущей системы с записями и характеристиками файлов системы в исправном состоянии. Аудит позволяет обнаружить изменения в системе, для которых требуется авторизация.

Система обнаружения вторжений (или IDS) – это программное обеспечение, которое отслеживает несанкционированные операции в системе или сети. Во многих реализациях систем обнаружения вторжений на основе хоста аудит файлов используется для обнаружения изменений в системе.

Влияние IDS и аудита файлов на безопасность

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

Это позволяет вам убедиться в том, что файловая система не была изменена одним из процессов или пользователей.

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

Реализация аудита файлов и IDS

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

Кроме того, это повлияет на рутинную работу сервера. Реализация этого метода усложнит процесс обновления: каждое изменение нужно подтвердить, а после обновления настроить систему обнаружения вторжений согласно новым условиям.

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

Этот метод может значительно увеличить нагрузку на системное администрирование, однако он может гарантировать, что файлы не были изменены без вашего ведома.

7: Изолированная среда

Изолированная среда выполнения позволяет запускать компоненты в индивидуальных выделенных пространствах.

Этот метод позволяет распределить компоненты приложения между индивидуальными серверами или настроить сервисы в среде chroot или контейнерах.

Уровень изоляции зависит от требований приложения и возможностей инфраструктуры.

Влияние изолированной среды выполнения на безопасность

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

Реализация изолированной среды выполнения

Создание собственной изолированной среды достаточно просто (во многом это зависит от выбранного типа изоляции). Распределив компоненты приложения по контейнерам, вы можете быстро достичь необходимого уровня изоляции. Но помните: контейнеризация Docker в первую очередь используется не как средство повышения безопасности.

Настройка среды chroot для каждого компонента также может обеспечить некоторый уровень изоляции; к сожалению, это также не является самым надежным методом изоляции, поскольку среду chroot можно обойти. Перемещение компонентов на отдельные машины – лучший метод изоляции, и во многих случаях он может оказаться самым простым, хотя стоит гораздо дороже.

Заключение

Описанные в статье стратегии – это лишь некоторые из базовых улучшений, которые вы можете внедрить для повышения безопасности своего сервера.

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

Читайте также: