Организация сети в домене: Домен в локальной сети: что это такое, создание

Домен в локальной сети: что это такое, создание

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

Что такое домен в локальной сети

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

Целесообразность организации такого доступа обусловлена несколькими факторами:

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

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

Если ЛВС организована на основе Microsoft Windows Server, то служба, которая отвечает за контролер домена называется AD (Active Directory), если под управлением *nix (Unix, Linux, FreeBSD) служба управляющая пользователями имеет название LDAP (Lightweght Directory Access Protocol).

Создание контроллера домена под Windows Server 2003/2008

Теперь разберемся, как создать домен в локальной сети. После того, как на сервер установлена операционная система и проведены предварительные настройки, можно приступить к конфигурации службы Active Directory:

• Серверу задается статический IP, желательно в начальном диапазоне адресов подсети.
• Устанавливаются компоненты, которые отвечают за работу сервера, если они не были установлены раньше — Active Directory, DNS, DHCP, WINS.
• Следующий шаг — это установка непосредственно контролера домена. Для этого нужно:
  • открыть «Диспетчер сервера» и нажать ссылку «Добавить роли»;
  • в открывшемся диалоговом окне нужно проставить галочки напротив установленных служб, чтобы мастер конфигурации смог провести настройки, добавил службы в автозапуск и другие служебные действия.
• После того как службы были установлены в «Диспетчере сервера» под ролями сервера их можно будет увидеть. При этом будет висеть ошибка запуска напротив «Доменные службы Active Directory».
• Избавиться от ошибки поможет «Мастер установки доменных служб», который запускается из командной строки «Пуск — Выполнить — cmd — dcpromo».
• Пропустив несколько информационных окон, поставить переключатель на «Создать новый домен в новом лесу».
• Следующий шаг — это придумать имя домена. О правилах выбора доменных имен написано множество статей в интернете, но все они сводятся к одному: при выборе имени необходимо придерживаться соглашения и стандартов ICANN.
• После проверки имени на совпадения в сети, требуется выбрать режим совместимости работы сервера.
• В следующем шаге мастер предупредит о том, что дополнительно будет настроен DNS сервер и на вопрос о делегировании соглашаемся.
• Дальше нужно будет выбрать каталоги, в которых будут располагаться базы данных. Можно оставить по умолчанию или выбрать другое размещение.
• И напоследок придумать и ввести пароль для учетной записи «Администратор».

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

Иногда происходит такая ситуация, что компьютер не определяет сеть, вернее ставит статус «Неопознанная сеть». Ситуация возникает из-за того, что сервер замыкает DNS сам на себя, т.е. на петлю с адресом 127.0.0.1. Чтобы избавиться от этого, необходимо в настройках соединения указать в качестве DNS адрес сервера в локальной сети.

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

Как создать локальную сеть в домене Windows / Доменная локальная сеть

Всем привет, вот наконец дошли руки чтобы написать для новичков, мануал как создать и настроить локальную сеть в домене Windows. Большую часть материала я выкладывал в разных статьях, так что давайте все разложим в хронологическом порядке. Что такое локальная сеть, википедия дает очень простой ответ Лока́льная вычисли́тельная сеть (ЛВС, локальная сеть; англ. Local Area Network, LAN) — компьютерная сеть, покрывающая обычно относительно небольшую территорию или небольшую группу зданий (дом, офис, фирму, институт). Также существуют локальные сети, узлы которых разнесены географически на расстояния более 12 500 км (космические станции и орбитальные центры). Несмотря на такие расстояния, подобные сети всё равно относят к локальным.

В идеале локальная сеть строится на ядре уровня L3, коммутаторах доступа L2, и конечные клиенты и серверы. Выглядит это приблизительно вот так

схема локальной сети

Предположим, что ваш сетевик все это настроил, теперь дело за вами. Для начала, чтобы организовать домен, нам нужно поставить операционную систему на сервер. На выбор на текущий момент два варианта это 2008R2 и 2012R2, я бы посоветовал последний. О том как поставить windows server смотрите ссылки ниже.

Далее когда вы поставили операционку нужно произвести первичные настройки, об это подробнее описано тут Первоначальная настройка сервера windows server 2008 R2

Далее задаем нашему серверу понятное имя, как это делается читайте в статье В помощь начинающим. Как сменить имя компьютера в windows server 2008 R2. После того как вы задали имя вашего сервера, который будет контроллером домена, не спешите его перезагружать, нужно дать ему статически ip адрес (Настроить статический ip адрес в windows server 2008R2 1 часть), той сети которую вы выбрали для вашей инфраструктуры (Планирование локальной сети / Как правильно спроектировать локальную сеть). Перезагружаемся, следующим шагом нам нужно установить контроллер домена и Active Directory, подробнее тут (Как установить Active Directory)

После установки Active Directory, вам нужно создать пользователей, группы и организационные подразделения, подробнее далее:

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

Все бы хорошо, но если нужно поставить 100 или более систем, тут нам поможет сервер автоматической установки WDS? установим его (Автоматизированная установка клиентских операционных систем при помощи Windows Deployment Services — Часть 1. Установка WDS). После установки WDS нам нужно создать эталонные образа для установки, об этом подробно тут (Автоматизированная установка клиентских операционных систем при помощи Windows Deployment Services — Часть 4. Добавляем образа загрузки и установки)

После, установки всех клиентских систем, не будем же мы всем вручную настраивать ip адреса, для этого поставим и настроить DHCP сервер (Как установить DHCP в windows server 2008R2)

Нам нужно прийти в итоге вот к такому виду.

Теперь все клиентские компьютеры нужно занести в домен (Как добавить компьютер в домен windows 2008 R2)

После, того как сеть заработала, встает вопрос с активацией windows, в корпоративной среде с большим количеством сотрудников, ставят KMS сервер

После активации windows, следует создать одного локального администратора, общего для всех компьютеров, сделаем это с помощью групповой политики (Как создать и добавить локального пользователя (администратора) через групповые политики в windows server 2008R2 / 2012R2)

Отключим лишние вещи через туже групповую политику, а именно (Как отключить программу по улучшению качества ПО с помощью групповой политики в Windows 7,8.1,10,2008R2,2012R2,2014R2)

Создадим, обратную зону в DNS, для того чтобы ip могли разрешаться в DNS имена (Как создать обратную зону в windows server 2008R2)

Теперь, немного защитим домен и отнимем у пользователей возможность заносить компьютеры в домен (Как изменить количество компьютеров, которое пользователь может добавить в домен в Windows Server 2008 R2)

Никто не застрахован от ошибок, и случайного удаления какой либо сущности из Active Directory, поэтому включим механизм восстановления:

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

Преимущества использования доменной сети — Первый Сервисный Провайдер

Преимущества использования доменной сети

Доменная сеть – способ взаимодействия компьютеров между собой. Такая сеть позволяет управлять компьютерами централизованно.

В доменной сети всегда есть главный компьютер – Контроллер Домена. В специальной программе на контроллере домена создаются учетные записи пользователей– имя пользователя и пароль. Например, для сотрудника Ивана Петрова создана учетная запись i.petrov. С её помощью Иван может выполнить вход в свой рабочий компьютер, работать с общими файлами и печатать на сетевом принтере.

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

Нужна ли Вам доменная сеть

 Вам стоит задуматься о доменной сети, если хотя бы одно утверждение для Вас верно:

• В Вашем офисе больше 15 компьютеров и их количество будет расти
• В Вашей сети есть файловый сервер или сервер 1С
• Необходимо единообразие в настройках компьютеров – одинаковые программы, используемые принтеры и параметры безопасности
• Вы нанимаете или увольняете сотрудников раз в два-три месяца или чаще
• Ваши сотрудники работают за одним компьютером посменно
• Один и тот же сотрудник работает за несколькими компьютерами
• Вы хотите знать, кто и когда работал с общими файлами. Кто мог удалить важный документ или занести вирус
• Нужно управлять доступом в Интернет – запретить социальные сети или разрешить доступ только к Вашему сайту и CRM

Как изменится работа в офисе с введением доменной сети?

 Доменная сеть требует выполнения правил безопасности и единообразия.

Учетные записи сотрудников уникальны. Учетная запись сотрудника в доменной сети – универсальный пропуск к рабочему пространству компании. При входе в систему пользователь получает доступ к сетевым принтерам, общим файлам, серверу 1С, почте или общему чату.

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

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

Управление пользователями в доменной сети

Учетные записи в доменной сети создаются только на Контроллере Домена. Контроллер домена сообщает всем компьютерам сети об имеющихся учетных записях сотрудников. Сотрудник Иван может использовать свою учетную запись i.petrov для работы за любым компьютером доменной сети. Файлы других сотрудников на этом компьютере Иван не увидит.

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

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

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

Безопасность доменной сети

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

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

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

Автоматизация в доменной сети

Групповые политики — набор настроек операционной системы. Эти настройки определяют отображение элементов Windows – окно входа, панели инструментов. Групповые политики позволяют запретить запуск определенных программ или автоматическую установку программ для новых пользователей. Можно даже запретить работать с внешними накопителями флешками или съемными дисками.

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

А можно без доменной сети?

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

Статью подготовил менеджер отдела проектов Заболотский Андрей.

Хотите получить более подробную консультацию по доменной сети?

Оставить заявку

Доменная организация локальных сетей — Студопедия

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

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

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

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

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

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

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

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

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

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

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

Поскольку в Active Directory хранятся не только учетные данные пользователя, но также и сведения для управления доступом, при входе пользователя в сеть осуществляется и проверка его подлинности, и авторизация для доступа к ресурсам системы.

Например, при входе пользователя в сеть система безопасности Windows 2К/XP проверят подлинность сведений о пользователе, хранящихся в Active Directory. Затем при попытке доступа пользователя к службам по сети система проверяет свойства, определенные в избирательной таблице управления доступом (DACL) для данной службы.

Доменная структура

Доменная структура

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

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

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

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

Как уже упоминалось ранее, серверная операционная система содержит в себе целый ряд инструментов, с помощью которых осуществляется администрирование локальной сети. К ним относятся Active Directory, DNS– и DHCP-сервер, хранилище сертификатов и т. д.

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

·           контролируемое подключение к локальной сети путем использования учетной записи пользователя;

·           полный контроль над участниками сети;

·           мощная система управления правами доступа;

·           контролируемая организация доступа к общим ресурсам;

·           система архивирования;

·           настраиваемые политики работы в локальной сети;

·           автоматическая установка необходимых пакетов обновления системы и программных продуктов;

·           корпоративная антивирусная защита локальной сети.

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

Одноранговые и доменные сети — Сводные таблицы Excel 2010

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

Мы уже упоминали о двух принципиальных архитектурах сети: доменной и одноранговой. Что это такое, и в каких случаях оправдано применение той и другой? Одноранговая сеть — самая простая реализация. В такой сети все узлы (компьютеры) равноправны и равноценны. Любой из них по мере необходимости может выступать и сервером, и клиентом. Учетные записи пользователей относятся к конкретным компьютерам (локальные учетные записи), а настройки безопасности каждого компьютера хранятся и применяются непосредственно на нем. Для относительного объединения компьютеров в структуру служат рабочие группы, однако значение их ограничено.

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

Понятие домена Windows тесно связано с понятием Active Directory. При такой организации сеть рассматривается как целостная структура, в которой есть компьютеры, пользователи и ресурсы. На них распространяется общая политика безопасности. При этом пользователи выступают пользователями домена: вход производится не в локальную систему, а сразу в сеть.

Управление безопасностью и назначение прав осуществляется централизованно. Один из компьютеров является центральным сервером — контроллером домена. На нем хранятся учетные записи пользователей и все политики безопасности. При запуске компьютера и вводе имени пользователя и пароля учетная запись сначала проверяется на сервере. Уже от сервера локальный компьютер получает разрешение «пустить пользователя в систему», и оттуда же получаются настройки, права доступа к ресурсам, списки ресурсов и т. д.

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

Если пойти дальше, то в домене легко организуются перемещаемые профили — личные папки пользователей, в том числе и их рабочие столы, технически хранятся на сервере. Пользователь может сесть за любой компьютер сети, войти на него под своим именем и работать в своей, уже настроенной, среде. В малой сети доменная структура неудобна лишь тем, что требует постоянно запущенного компьютера с серверной ОС. Как правило, пользователь за ним не работает, и в сервере (с учетом лицензий на ПО) «заморожена» почти тысяча долларов.

Еще раз о том, как не сделать из своей сети «решето» / Хабр

Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.

В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.

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

Не создавайте локальные учетные записи доменными политиками

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

Причина высокой опасности – сведения об этой учетной записи, в том числе ее пароль, хранятся в открытом виде в файле groups.xml, в ресурсе sysvol контроллера домена, который по умолчанию доступен ВСЕМ участникам домена на чтение. Пароль зашифрован, но шифрование симметричное, а ключ один для всех копий Windows, и написан в открытом виде в MSDN. Отсюда следует: любой пользователь может скачать этот файл, и путем простых манипуляций узнать пароль от распространяемой учетной записи. Обычно так распространяется учетная запись с правами администратора, и часто она создается без разбора везде…

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

Противодействие угону доменных учетных записей через mimikatz/wce

Администраторы, не связанные с пентестами и практической ИБ, редко знают про такие утилиты, как mimikatz и wce. Кратко об их работе – обладая правами локального администратора, можно извлечь из оперативной памяти билет доступа Kerberos, хеш пароля и даже сам пароль в открытом виде от учетных записей, которые недавно производили вход на этот хост. А так как администраторы совершают вход часто и много где, это приводит к высокому риску компрометации их полномочий.

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

Против этих утилит есть меры разной степени эффективности, например, такие, но часто они не применимы по разным причинам: старая схема AD, «зоопарк» в сети, который дошел до стадии метастаз, слишком большая инфраструктура, где есть слабо контролируемые участки.

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

Решение без дополнительных затрат: заводить для управления инфраструктурой даже не 2-3 учетные записи, как принято (надеюсь, у вас так?):

— для локальной работы;

— для администрирования серверов и ПК;

— для контроллеров домена,

а как минимум 4 учетные записи (а то и больше), в соответствии с условными «зонами доверия» в домене, и не применять их вне своей зоны. То есть, держать отдельные учетные записи:

— для работы со своей личной машиной;

— для входа на контроллеры домена и управлением ими.

— для серверов;

— для рабочих станций;

— для удаленных филиалов, если там оказался ваш домен, но при этом вы не уверены, что там происходит в конкретный момент времени;

— для зоны DMZ, если вдруг доменные хосты оказались в DMZ;

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

Запрет на ввод «тестовых» хостов в домен

По схожей причине (см. пункт выше) по возможности лучше не заводить общественные «тестовые» хосты в домен. Такие хосты наиболее часто встречаются в компаниях с подразделениями по разработке софта, «для ускорения» и экономии лицензии они часто не снабжаются антивирусами (которые, кстати, «ловят» нешифрованные mimikatz и wce), а все причастные разработчики и тестировщики имеют на них права администратора, с целью осуществления разных сомнительных действий. Используя свои администраторские права, они могут легко похитить доменные учетные записи других администраторов.

Детализация прав сервисных учетных записей

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

Обращение к SMB по именам и запрет использования NTLM

К файловым ресурсам (SMB) в домене лучше обращаться только через доменное имя, а не через IP. Помимо удобства администрирования, так вы явным образом заставите хост аутентифицироваться по протоколу Kerberos, который хоть и имеет свои недостатки, но является значительно более защищенным, чем протокол NTLMv2, который задействуется при обращении по IP файлового ресурса. Перехват NTLMv2 хеша опасен тем, что можно словарной атакой неспешно восстанавливать пароль пользователя оффлайн, то есть, никак не беспокоя атакуемую инфраструктуру. Очевидно, что это не заметно для администраторов, в отличие онлайн-атак по перебору паролей.

Касательно протокола NTLM (который без «v2») – он должен быть запрещен. Помимо атак по перебору паролей, можно использовать атаку типа «Pass-the-hash». Эта атака по сути разрешает переотправку хеша NTLM без изменения и попыток подобрать пароль на произвольный хост, где разрешен NTLM. Сам хеш может быть украден из другой сессии в ходе атаки. Если у вас разрешены оба протокола NTLM, возможна ситуация, когда атакующий может понизить предпочтение с NTLMv2 до NTLM, и хост-жертва выберет самую слабую аутентфикацию.

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

Блокировка механизма WPAD

Есть два механизма, которые включены по умолчанию, и в совокупности позволяют проводить атаку «человек посередине», причем практически не обнаруживая атакующего. Это механизм автоматического обнаружения прокси через специальное сетевое имя (WPAD), и механизм широковещательного разрешения имен LLMNR.

Через WPAD некоторое ПО (в домене это чаще всего служба обновлений WSUS и некоторые браузеры) выполняет поиск HTTP прокси, и готово при необходимости прозрачно авторизоваться на нем при помощи NTLM(v2). Таким образом, оно добровольно «выдает» хеш учетной записи, которая инициировала подключение. Его можно в последствии перебирать по словарю, и восстановить пароль. Либо применять атаку «Pass-the-hash», описанную выше, если не отключен NTLM (про это см. пункт выше).

Устройства выполняют поиск сервера WPAD через DNS, и, если это не сработает, задействуют широковещательный запрос LLMNR или NetBIOS. И тут атакующему уже значительно проще ответить на вопрос хоста, где же находится «правильный» сервер конфигурации прокси. Дополнительный негативный эффект — такой поиск прямо замедляет скорость подключения, так как тратится время на поиск прокси.

Решение – в групповых политиках запретить и автообнаружение прокси для ПО, и протокол LLMNR. На DNS адрес WPAD (wpad.domain.name) в DNS поставить заглушку. LLMNR это фактически имитация DNS на сегменте сети L2 путем широковещательных запросов. В доменной сети при нормально работающем DNS он не нужен. С NetBIOS все сложнее, он до сих пор используется во многих случаях, и его выключение может обрушить работу, так что здесь все же остается лазейка для навязывания WPAD.

Включение UAC на максимум

Не выключайте User Account Control (UAC), а лучше наоборот, установите его на максимум. UAC, конечно, реализован не очень удобно и не информативно, но вы не представляете, как обидно пентестеру получить формальную возможность удаленного выполнения команд от имени пользователя с администраторскими правами, но без фактической возможности выполнения именно привилегированных действий, которые как раз при «обычной» работе надоедают запросами о подтверждении. Обойти UAC или повысить права конечно, возможно, но это лишние препятствия.

Отключение скрытых файловых ресурсов

Хотя бы для машин администраторов, «важных» пользователей и серверов обязательно отключайте скрытые ресурсы $ADMIN, C$, D$, и т.д. Это первоочередная излюбленная цель любой сетевой malware и злоумышленников при получении более-менее привилегированных прав в домене.

Сетевые диски как ярлыки

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

Ревизия содержимого SPF

Проверьте SPF-запись вашего почтового домена. А потом проверьте ее еще раз.

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

1) «~all» в конце SPF записи почтового домена. Не знаю почему, но большинство публичных мануалов рекомендуют оставить такую настройку. Такая настройка дает письму статус «не прошло проверку, но помечено как опасное и все равно доставлено» при отправке почты от ресурсов, прямо не указанных в SPF домена. Это говорит получателю, что решение о легитимности отправляемой почты перекладывается на жесткость настроек его спам-фильтра и других механизмов фильтрации. Далее, есть вероятность, что ваш собственный спам-фильтр настроен мягко (особенно часто это бывает с «публичными» пользователями компании, которые боятся «прозевать» письма), и это приводит к тому, что любой хост Интернета отправит вам же письмо от вашего же домена, и с некоторой вероятностью оно пройдет во входящие, а не в спам. Очень забавно видеть пользователей и даже ИТ-администраторов, беспрекословно выполняющих срочные указания от «важного начальства» из подобных поддельных писем при пентестах с социальной составляющей. Конечно же, не исключена ситуация со слабыми спам-фильтрами и у ваших контрагентов, и тогда уже вы будете делать им заманчивые предложения без своего ведома.

SPF для подавляющего большинства компаний должна содержать только –all в конце, разумеется, после тщательной сверки своего содержимого.

2) Бывает, что по ошибке в SPF корпоративного домена оказываются внешние адреса, через которые пользователи компании выходят в интернет. Последствия понятны – возможность нелегитимной отправки писем от кого угодно из корпоративного домена, куда угодно. Обычно администраторы в таких ситуациях говорят – «но у нас же есть авторизация на почте», напрочь забывая про сам механизм протокола SMTP.

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

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

Организуйте DMZ

Организуйте DMZ, и навсегда перестаньте «пробрасывать» порты из Интернет в основную сеть. Правильная DMZ эта та, ресурсы в которой с двух сторон закрыты файерволами (как от внутренней сети, так и от Интернет), а трафик разрешен крайне выборочно, и только минимально необходимый. На мой взгляд, настоящий специалист по ИБ должен думать, что его хост из DMZ по уже взломан, и оценивать риски исходя из этого. На такие мысли наводит тот факт, что в DMZ очень часто оказываются нестандартные приложения, которые несут специфичную бизнес-логику, ставятся подрядчиками на потоке, как вариант – делаются на заказ и очень плохо проверяются, например, на банальные для WEB уязвимости. Штатный специалист по ИБ чаще всего в состоянии создать DMZ, но не в состоянии проверить приложения на уязвимости. Исходя из этого и нужно действовать.

Типичный вариант правильно организованной DMZ и общий принцип движения трафика. Стрелки – направления инициации трафика из/в DMZ.

Бюджетный дизайн DMZ для параноиков, в которой каждый ресурс находится в отдельной изолированной сети, и ресурсы не «кушают» много трафика:

Что касается «проброса» портов, то помимо риска «взлома» сервиса, существует неявный риск сбора информации о внутренней сети. Например, в ходе пентестов зачастую видно порты RDP, которые были «скрыты» путем смены со стандартного 3389 на какой-нибудь 12345. Разумеется, они легко обнаруживаются сканерами, легко идентифицируются именно как RDP, но помимо простого обнаружения, они могут, например, предоставить информацию об имени компьютера и домена (путем просмотра сертификата службы RDP), или информацию о логинах пользователей.

Полностью изолированный гостевой WiFi

Гостевой WiFi должен быть максимально изолирован от основной сети (отдельный VLAN, отдельный провод от маршрутизатора интернет до точки доступа, и т.д.). Дополнительно, по возможности, выключайте гостевой WiFi в нерабочее время по расписанию на оборудовании.

Здесь есть один нюанс. Многие правильно выделяют гостевой WiFi в отдельный изолированный VLAN, но при этом зачем-то выдают клиентам адреса DNS серверов Active Directory. Наиболее рациональное оправдание – «чтобы работали ресурсы из DMZ по внутренним адресам». Однако, это является уязвимостью, и это хорошо помогает злоумышленнику при несанкционированном анализе внутреннего устройства сети, ведь запросы к DNS (PTR по внутренним диапазонам IP) обычно никак не ограничиваются.

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

Не создавайте «корпоративный» WiFi на едином Preshared-ключе

Это очень частая проблема. Один ключ от WiFi часто живет годами, ведь «нельзя же беспокоить пользователей лишний раз». Это неизбежно снижает безопасность такой конфигурации до нуля с течением времени. Основные причины – текучка сотрудников в организации, кражи устройств, работа malware, возможность перебора пароля сети.

Решение: авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно. Если внутренняя сеть на самом деле не нужна для WiFi устройств, а нужен только Интернет, нужно сделать WiFi по типу гостевого. Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.

Правильная сегментация сети

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

В любом случае обязательно нужно держать ПК пользователей отдельно от серверов, иметь отдельный VLAN для management-интерфейсов устройств (сетевых устройств, интерфейсов iLO/IMPI/IP KVM, и т.д.). Все это снизит возможности подделки адресов, упростит настройку сетевого доступа, снизит вероятность атак за счет широковещательных запросов, а значит повысит и стабильность работы.

На мой взгляд как безопасника (но уже чувствую летящие помидоры от сетевиков), количество VLAN для пользователей больше зависит от количества коммутаторов доступа и от количества условных групп пользователей по административному признаку, а не от самого количества пользователей. Имеет смысл сделать количество пользовательских VLAN на уровне числа коммутаторов доступа (даже если они собраны в стек). Так очень сильно ограничится широковещательный трафик, не будет «размазывания» одного VLAN по множеству коммутаторов доступа. Это не сделает для сети лишней работы, так как чаще всего трафик пользователей идет либо в серверный сегмент, либо в Интернет (т.е. в любом случае в сторону уровня ядра сети или уровня распределения), а не между самими пользователями. В таком случае легче отлаживать сеть, и предотвращать атаки, связанные с широковещательными пакетами.

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

Защита от ARP spoofing и поддельных DHCP серверов

Два механизма, на языке технологий Cisco: DHCP snooping и ARP Inspection, помогут расстроить разных шутников-пользователей и реальных злоумышленников. После их внедрения вы получите предотвращение появлений ложных DHCP серверов в сети (которые могут появиться как по ошибке — кто-то перепутал настольный «домашний» маршрутизатор форм-фактора «мыльница советская» с такого же типа коммутатором, так и в результате атаки), и атак типа «человек посередине» через ARP протокол. В сочетании с малыми размерами VLAN (предыдущий пункт) это отлично снизит возможный ущерб.

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

Port security

Если кабельная сеть и оборудование позволяют, настройте на коммутаторах доступа port security. Это хорошо защищает, хоть и не полностью, от подключения «левых» и «лишних» устройств, несанкционированного перемещения компьютеров в пространстве.

Противодействие «левым» устройствам

Даже с описанными выше защитными мерами (port security, dhcp snooping, arp inpection), возможно появление «левых устройств», причем, как показывает практика, наиболее вероятное устройство в этом случае – «домашний» роутер с функцией «клонировать MAC-адрес компьютера на внешний интерфейс». Поэтому, есть следующий шаг развития сетевой тирании – 802.1x. Однако, это уже серьезное решение, требующее хорошего планирования, поэтому возможен более простой способ выявления самовольных роутеров (именно выявления, а не пресечения). Здесь хорошо поможет анализ трафика на промежуточном звене сети на предмет параметра протокола IP — TTL. Можно сделать span порт на коммутаторе, зеркалирующий трафик в сервер со снифером, и анализировать этот трафик на наличие пакетов с аномальным TTL. В этом поможет банальный tcpdump/Wireshark. Трафик с таких роутеров будет иметь TTL меньше на 1, чем легальный трафик.

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

Удаленный доступ

При организации удаленного подключения к сети забудьте про протокол PPTP. Он, конечно, настраивается быстро и легко, но помимо наличия уязвимостей в самом протоколе и его составляющих, он плох тем, что очень хорошо виден сканерами сети (из-за работы на TCP на одном и том же порте), зачастую плохо проходит через NAT за счет транспорта на GRE, от чего на него жалуются пользователи, и по своему дизайну не содержит второго фактора аутентификации.

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

Решение-минимум: использовать протоколы на UDP (либо свободно инкапсулирующиеся в UDP), которые не так видны при сканировании, с предварительной аутентификацией по PSK, либо по сертификату (L2TP/IPSec, OpenVPN, разные вендорские реализации IPSec). Обязательно нужно настроить перечень адресов и портов внутри сети, куда можно получить доступ, используя VPN.

Запретите прямой произвольный доступ в интернет для «пользовательской» сети

Прямой выход в интернет для пользователей – это зло, хотя с удешевлением каналов Интернет его становится все больше и больше, особенно в малых и средних компаниях. Многие администраторы ограничивают исходящие порты для пользователей на минимальный набор, вроде 80, 443, пытаясь экономить полосу. С точки зрения Malware и злоумышленников, это ничем не отличается от свободного доступа в Интернет.

На мой взгляд, всегда нужен прокси-сервер, пусть без кеширования и авторизации, даже в самых маленьких сетях, и запрет на прямой выход в интернет для пользователей. Основная причина — множество всяческой malware обращается на свои центры управления именно по HTTP(S), либо по чистому TCP c популярными портами (80/443/25/110…), но при этом она зачастую не в состоянии обнаружить настройки прокси в системе.

Возьмите под контроль IPv6

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

Трафик в межфилиальных сетях

Если у вас под контролем крупная сеть с удаленными филиалами, и в ней настроен Site-to-Site VPN, не поленитесь максимально ограничить трафик, который идет к вам в центр, причем именно на центральном оборудовании, а не в филиалах. Не воспринимайте каналы с удаленными филиалами как «свою родную» сеть. Обычно в компаниях филиалы защищены меньше центра, и большинство атак начинаются именно с филиалов, как с «доверенных» для центра сетей.

Ограничение icmp ping

Ограничьте список адресов, которые могут «пинговать» важные сервисы. Это снизит обнаружение ваших хостов, хоть и ненамного. При этом не забудьте, что ping – это не весь протокол icmp, а только один вид сообщений в icmp, и не нужно его (icmp) запрещать целиком. По крайней мере, вам точно будут нужны для корректного взаимодействия со всеми сетями некоторые сообщения видов Destination Unreachable. Не создавайте полным запретом ICMP на своих маршрутизаторах так называемую MTU Discovery Black Hole.

Сертификаты SSL для всего и везде

Не ленитесь защищать шифрованием все сервисы, куда можно пристроить SSL/TLS. Для хостов из домена Active Directory можно настроить AD Certificate Services, либо распространять сертификаты служб через групповые политики. Если нет денег для защиты публичных ресурсов, воспользуйтесь бесплатными сертификатами, например, от startssl.

Для себя, т.е. администраторов, всегда можно пользоваться легким самодельным удостоверяющим центром, например, easy-rsa, либо самоподписанными сертификатами. Вы же заметите, что на вашем внутреннем администраторском ресурсе внезапно возникла ошибка доверия к ранее одобренному сертификату?

Если вам кажется, что вашему сайту-визитке ничего не угрожает, то надо учесть, что шифрование спасет вас не только от кражи учетных данных, но и от подмены трафика. Все наверно видели на сайтах с доступом по открытому HTTP заботливо встроенную операторами связи рекламу? А если вам встроят не рекламу, а «правильный» скрипт?

Wildcard SSL сертификат

Если вы стали счастливым обладателем wildcard-сертификата (для доменов «*.ваш-домен»), не торопитесь его распространять по всем публичным серверам. Сделайте себе отдельный сервер (или кластер), к примеру, на Nginx, который будет «разгружать» от шифрования входящий трафик. Так вы сильно снизите количество каналов утечки закрытого ключа вашего сертификата, и в случае его компрометации, не будете менять его сразу на множестве сервисов.
Linux-хосты чаще всего видно в роли веб-серверов, классической связки LAMP (Linux + Apache + Mysql + PHP, или любой другой скриптовый язык), которую чаще всего и ломают за счет дыр в веб-приложении, поэтому опишу самый минимум для данной связки, который относительно легко внедряется, и не требует большого опыта настройки и отладки (вроде мер типа SELinux/AppArmor).

Доступ к серверу

Не поленитесь запретить вход по ssh для root, настроить авторизацию только по сертификатам и сместить порт ssh куда-нибудь далеко со стандартного 22.

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

Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.

Ну и конечно, классика — не работайте под рутом.

Iptables

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

Правильно настроенный iptables, как и любой другой файервол, разрешает только минимально необходимое (включая исходящие соединения через цепочку правил output). На случай минимальной конфигурации Web-сервера в iptables будет не более 10 строк. По сложности, это значительно проще настройки firewall для доменного хоста Windows, где можно нечаянно запретить динамические RPC порты, доменные службы и другие важные для работы коммуникации, так как не всегда очевидна даже последовательность коммуникации. Поэтому, для настройки iptables под web-сервер не нужны особые знания по сетям, и можно настроить файервол значительно легче.

Противодействие повышению прав в случае взлома

Отправьте Apache работать в chroot. Как вариант, сделайте отдельные разделы в файловой системе для /var/ и /tmp, смонтируйте их с флагами noexec,nosuid. Так вы защитите сервер от исполнения локальных эксплоитов в бинарном виде, которые могут повысить права атакующего. Запретите исполнение интерпретаторов скриптовых языков типа Perl, Python для «других пользователей» (chmod o-x), куда относится веб-сервер, если это не требуется веб-серверу и другим службам. Чем меньше в системе «других служб», а соответственно, пользователей под них, тем проще это сделать.

Пара слов о настройке web-сервера на примере Apache

Здесь перечислено то, что может сделать системный администратор для защиты веб-приложения, даже не зная специфики веб-программирования.

— Запретите наличие VirtualHost, который отвечает на запросы вида http(s)://ip-адрес/, даже если приложение на сервере одно. Так вы значительно снизите возможность обнаружения приложения.

— Запретите в конфигурации apache вывод ошибок (опции ServerSignature Off, ServerTokens Prod), это затруднит определение версии ОС и Apache.

— Установите через mod_headers опции для Cookies HTTP_only и Secure для вашего веб-приложения, даже если у вас веб-приложение делает это само. Это защитит вас от перехвата Cookies через прослушку нешифрованного HTTP и части атак XSS.

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

— Контролируйте, чтобы индексы директорий были выключены (опция «–Indexes» в настройках сайта или файлов .htaccess).

— Дополнительно сделайте basic-авторизацию на директорию с администраторской панелью сайта.

— Установите принудительное перенаправление с 80 порта на 443, если у вас есть настроенный TLS. Запретите устаревшие алгоритмы SSL (SSLProtocol all -SSLv2 -SSLv3), слабые алгоритмы шифрования и вариант его полного отсутствия через директиву SSLCipherSuite. Это защитит от атак на «понижение» уровня шифрования.

Проверить свою настройку SSL можно, например, через https://www.ssllabs.com/ssltest/

Настройте аудит системы

Включите и настройте auditd по показательным событиям (создание пользователя, изменение прав, изменение конфигурации) с отправкой уведомлений на удаленный сервер. Все взломы не производятся одномоментно, поэтому периодически осматривая логи, пусть даже и вручную, можно обнаружить подозрительную активность. Дополнительно это поможет при «разборе полетов» в случае инцидентов.

Ставьте только минимально необходимое в системе

ОС на основе Linux хороши тем, что можно гибко выключать/удалять ненужные компоненты. С точки зрения безопасности, в первую очередь, это относится к сетевым и локальным демонам. Если вы видите, что на вашем только что установленном сервере работают демоны, которые явно или косвенно не относятся к задаче данного сервера, задумайтесь – действительно ли они нужны. Для большинства случаев это всего лишь стандартная установка, и они легко и без последствий выключаются и/или удаляются. Например, не всем нужен RPC, который включен по умолчанию в Debian. Не ждите, пока под такие сервисы найдут уязвимости и сделают эксплойт, а вы забудете обновиться.
Даже не обладая навыками специалиста по тестированию на проникновение, можно дополнительно включить в самоконтроль минимальные «пентестерские» действия. Вам помогут:

Сканеры безопасности

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

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

Все перечисленные утилиты бесплатны. Делайте это регулярно, не забывайте обновлять сканеры.

Брутфорс учетных записей

Проверяйте учетные записи сотрудников на предмет слабых паролей. В минимальной комплектации в этом поможет файловый ресурс, доступный любому доменному пользователю после авторизации, и утилита THC Hydra. Сформируйте словари из паролей, которые подходили бы под вашу парольную политику, но при этом были бы простые, вроде «123QAZxsw». Количество слов в каждом – не более числа допустимых попыток авторизации в домене, минус 2-3 для запаса. И пропустите через брутфорс все учетные записи домена, уверен, найдете много интересного.
Разумеется, на эти проверки заранее нужно получить официальное (желательно, «бумажное») разрешение от руководства, иначе это будет походить на попытку неавторизованного доступа к информации.
Напоследок, пентестерская байка касательно паролей. Осенью 2015 года мы делали социальный пентест с применением фишинга – выманивали доменные пароли. У двух попавшихся пользователей пароль был «Jctym2015» («Осень2015»). Посмеялись, забыли. В ноябре 2015 года делаем подобный пентест в другой организации, никак не связанной с первой, опять те же пароли, и опять сразу у нескольких пользователей. Начали что-то подозревать, нашли в одной оранжевой социальной сети такое вот руководство к действию:

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

Руководство. Настройка виртуальных сетей для доменных служб Azure AD

• 06.07.2020
• Чтение занимает 8 мин

В этой статье

обеспечивает подключение к пользователям и приложениям, управляемый домен доменных служб Azure Active Directory (Azure AD DS) развертывается в подсети сети Azure.Для обеспечения подключения к пользователям и приложениям управляемый домен доменных служб Azure Active Directory (Azure AD DS) развертывается в подсети виртуальной сети Azure. Эту подсеть сети следует использовать только для ресурсов платформы, предоставляемой платформой Azure. Эта подсеть виртуальной сети должна использоваться только для ресурсов управляемого домена, предоставляемых платформой Azure.

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

В этом показано, как создать и настроить сеть, а также настроить другую сеть с помощью данной сети домена Azure AD DS.В этом руководстве показано, как создать и настроить выделенную подсеть виртуальной сети или как подключить другую сеть к виртуальной сети управляемого домена Azure AD DS.

В этом описании следующее: В этом руководстве вы узнаете, как:

• изучите варианты подключения к сети Azure AD DS для использования ресурсов домена; Изучите варианты подключения к виртуальной сети для ресурсов, присоединенных к домену, к Azure AD DS
• создайте подсдите диапазон IP-адресов и дополнительную сеть в сети Azure AD DS; Создайте диапазон IP-адресов и дополнительную подсеть в виртуальной сети Azure AD DS
• настроите пиринг с другой сетью, отличающейся от сети Azure AD DS.Настройка пиринга виртуальной сети для сети, отдельной от Azure AD DS

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

Предварительные требования

Для работы с этим учебником требуются следующие ресурсы и разрешение: Для выполнения этого урока вам потребуются следующие ресурсы и права:

• Активная подписка Azure.Активная подписка Azure.
• Связанный с вашей подпиской клиент Azure Active Directory, синхронизированный с локальным или облачным каталогом. Клиент Azure Active Directory, связанный с вашей подпиской, синхронизированный либо с локальным каталогом, либо с облачным каталогом.
• Вам потребуются привилегии глобального администратора для клиента Azure AD, чтобы настроить доменные службы Azure AD. Вам потребуются привилегий глобального администратора в вашем клиенте Azure AD для настройки Azure AD DS.
• Для создания нужных ресурсов Azure AD DS требуются привилегии Участник в подписке Azure. Для создания необходимых ресурсов Azure AD DS в подписке Azure требуются права Contributor .
• Управляемый домен доменных служб Azure Active Directory, включенный и настроенный в клиенте Azure AD. Управляемый домен доменных служб Azure Active Directory включен и настроен в вашем клиенте Azure AD.

Вход на портал Azure Вход на портал Azure

При работе с этим учебником вы создадите и настроите управляемый домен с помощью портала Azure.В этом руководстве вы создадите и настроите управляемый домен с помощью портала Azure. Чтобы начать работу, войдите на портал Azure. Для начала войдите на портал Azure.

Варианты подключения рабочих нагрузок приложения

Варианты подключения рабочих нагрузок приложения

При работе с предыдущим руководством был создан управляемый домен, с которым использовались некоторые параметры по умолчанию для сети. В предыдущем руководстве был создан управляемый домен, который использовал некоторые параметры конфигурации по умолчанию для виртуальной сети.С помощью этих параметров по умолчанию в Azure была создана виртуальная сеть и подсеть этой сети. Эти параметры по умолчанию создали виртуальную сеть Azure и подсеть виртуальной сети. Контроллеры домена Azure AD DS подключаются к этой подсети виртуальной сети. Контроллеры домена Azure AD DS, которые предоставляют управляемые доменные службы, подключены к этой подсети виртуальной сети.

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

• Создайте дополнительную подсеть в сети, настроенной для домена. Создайте дополнительную подсеть виртуальной сети в виртуальной сети управляемого домена. В этой дополнительной подсети вы будете создавать и подключать виртуальные машины.В этой дополнительной подсети вы создаете и подключаете свои виртуальные машины.
  • Так как виртуальные машины входят в ту же виртуальную сеть, они могут выполнять разрешение имен и взаимодействовать с контроллерами домена Azure AD DS. Поскольку виртуальные машины являются частью одной виртуальной сети, они могут автоматически выполнять разрешение имен и связываться с Azure Контроллеры домена AD DS.
• Настройте пиринг между виртуальными сетями Azure из нашей сети домена для одной или нескольких отдельных виртуальных сетей.Настройте пиринг виртуальной сети Azure из виртуальной сети управляемого домена в одну или несколько отдельных виртуальных сетей. В этих дополнительных виртуальных сетях вы будете создавать и подключать виртуальные машины. В этих отдельных виртуальных сетях вы создаете и подключаете свои виртуальные машины.
  • При настройке пиринга между виртуальными сетями необходимо настроить DNS обратное разрешение имен для контроллеров домена Azure AD DS. При настройке пиринга виртуальной сети необходимо также настроить параметры DNS для использования разрешения имен обратно в контроллеры домена Azure AD DS.

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

• Если вы хотите управлять Azure AD DS подключенными виртуальными машинами в одной группе ресурсов, создайте дополнительную подсеть сети для виртуальных машин.Если вы хотите управлять Azure AD DS и подключенными виртуальными машинами как одной группой ресурсов, вы можете создать дополнительную подсеть виртуальной сети для виртуальных машин.
• Если вы хотите разделить управление Azure AD DS и подключенными виртуальными машинами, лучше использовать пиринг виртуальных сетей. Если вы хотите разделить управление Azure AD DS и всеми подключенными виртуальными машинами, вы можете использовать пиринг виртуальных сетей.
  • Вы также можете использовать пиринг виртуальных сетей, чтобы подключиться к существующим виртуальным машинам в среде Azure, подключенным к существующей сети.Вы также можете использовать пиринг виртуальных сетей для обеспечения возможности подключения к существующим виртуальным машинам в вашей среде Azure, которые подключены к существующей виртуальной сети.

С помощью этого руководства можно настроить только один из вариантов подключения к сети. В этом руководстве вам нужно настроить только один из этих вариантов подключения к виртуальной сети.

См. сведения о проектировании и настройке данной сети рекомендаций по использованию сетей для доменных служб Azure AD.Дополнительные сведения о планировании и настройке виртуальной сети см. В разделе «Рекомендации по сети для доменных служб Azure Active Directory».

Создание подсети виртуальной сети Создание подсети виртуальной сети

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

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

1. На портале Azure выберите группу ресурсов домена, например myResourceGroup .На портале Azure выберите группу ресурсов управляемого домена, например myResourceGroup . В списке созданных по умолчанию виртуальную сеть, например aadds-vnet . Из списка ресурсов выберите виртуальную сеть по умолчанию, например aadds-vnet .

2. В окне виртуальной сети выберите элемент Адресное пространство . В левом меню окна виртуальной сети выберите Адресное пространство .Виртуальная сеть создается с одним адресным пространством 10.0.2.0/24 , используется для создаваемого по умолчанию. Виртуальная сеть создается с одним адресным пространством 10.0.2.0/24 , которое используется подсетью по умолчанию.

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

   В следующем примере добавляется диапазон IP-адресов 10.0.3.0/24 . В следующем примере добавлен дополнительный диапазон IP-адресов 10.0.3.0/24 . Когда все будет готово, щелкните Сохранить . Когда все будет готово, выберите Сохранить .

3. Теперь в окне виртуальной сети выберите Подсети , а затем щелкните + Подсеть , чтобы добавить подсеть. Затем в левом меню окна виртуальной сети выберите Подсети , затем выберите + Подсеть для добавления подсети.

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

   В следующем примере создается подсеть с именем workloads и диапазоном IP-адресов 10.0.3.0/24 . В следующем примере создается подсеть с именем workloads , которая использует диапазон IP-адресов 10.0.3.0/24 . :

5. Когда все будет готово, щелкните ОК . Когда все будет готово, выберите ОК . Создание подсети сети занимает несколько секунд.Создание подсети виртуальной сети занимает несколько минут.

Когда вы создаете виртуальную машину, которая должна использовать управляемый домен, убедитесь, что вы выбрали эту подсеть виртуальной сети. Не создавайте виртуальные машины в созданной по умолчанию подсети aadds-subnet . Не создавайте виртуальные машины в aadds-subnet по умолчанию. Если вы выберете другую виртуальную сеть, сетевое подключение и имен DNS не будут работать для разрешения домена, пока вы не настроите пиринг между виртуальными сетями.Если вы выберете другую виртуальную сеть, для доступа к управляемому домену не будет возможности сетевого подключения и разрешения DNS, если вы не настроите пиринг виртуальной сети.

Настройка пиринговой связи между виртуальными сетями Настройка пиринга виртуальной сети

Вы можете использовать для виртуальных машин существующую виртуальную сеть Azure или сохранить виртуальную сеть в своей отделенной от них. У вас может быть существующая виртуальная сеть Azure для виртуальных машин или вы хотите сохранить виртуальную сеть управляемого домена отдельно.Чтобы использовать управляемый домен, виртуальную машину в других виртуальных сетях, нужно обеспечить обмен данными между контроллерами домена Azure AD DS. Чтобы использовать управляемый домен, виртуальным машинам в других виртуальных сетях необходим способ связи с контроллерами домена Azure AD DS. Это можно сделать с помощью пиринга между виртуальными сетями Azure. Такое подключение можно обеспечить с помощью пиринга виртуальной сети Azure.

Пиринг между виртуальными сетями Azure подключает две виртуальные сети друг к другу без необходимости использовать дополнительные VPN-устройства.С помощью пиринга виртуальной сети Azure две виртуальные сети соединяются вместе без необходимости в устройстве виртуальной частной сети (VPN). Пиринг между сетями позволяет быстро подключать виртуальные сети и распределять потоки трафика в среде Azure.Network peering позволяет быстро подключать виртуальные сети и определять потоки трафика в среде Azure.

См. сведения о пиринге между виртуальными сетями Azure. Дополнительные сведения о пиринге см. в разделе Обзор пиринга виртуальной сети Azure.

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

1. Выберите виртуальную сеть, созданную по умолчанию для вашего домена с именем aadds-vnet . Выберите виртуальную сеть по умолчанию, созданную для вашего управляемого домена, с именем aadds-vnet .

2. В окне сети выберите элемент Пиринги .В левом меню окна виртуальной сети выберите Peerings .

3. Чтобы создать пиринг, щелкните + Добавить . Чтобы создать пиринг, выберите + Добавить . По умолчанию с именем aadds-vnet и новой сетью с именем myVnet . В следующем примере aadds-vnet по умолчанию привязан к виртуальной сети с именем myVnet . .Замените следующие параметры собственными значениями. Задайте для следующих параметров собственные значения:

   • Имя пиринга между aadds-vnet и удаленной сетью . Описательный идентификатор соединения двух сетей, например aadds-vnet-to-myvnet . Имя пиринга от aadds-vnet к удаленной виртуальной сети : описательный идентификатор двух сетей, например aadds-vnet-to-myvnet
   • Тип развертывания сети . Resource Manager Тип развертывания виртуальной сети : Resource Manager
   • Подписка : Выберите подписку сеть, для которой нужно создать пиринговое подключение, например Azure . Подписка : подписка виртуальной сети, к которой вы хотите подключиться, например Azure
   • Виртуальная сеть. Виртуальная сеть, для которой нужно создать пиринговое подключение, например myVnet . Виртуальная сеть : виртуальная сеть, к которой вы хотите подключиться, например myVnet
   • Имя пиринга между myVnet и aadds-vnet . Описательный идентификатор соединения двух сетей, например myvnet-to-aadds-vnet . Имя пиринга от myVnet к aadds-vnet : описательный идентификатор двух сетей, например myvnet-to-aadds-vnet

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

4. Потребуется несколько секунд для создания пирингового подключения между виртуальной сетью Azure AD DS и выбранной внешней сетью. Создание пиринга как в виртуальной сети Azure AD DS, так и в выбранной вами виртуальной сети занимает несколько секунд. Когда процесс завершится, параметр Состояние пиринга получит значение Подключено , как показано в следующем примере.Когда все будет готово, Peering status сообщает Connected , как показано в следующем примере:

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

Настройка DNS-серверов в сети, для которой настроен пиринг Настройка DNS-серверов в одноранговой виртуальной сети

900 виртуальные машины и приложения в сети с пиринговым подключением, которые могут обмениваться данными с управляемым доменом, необходимо изменить параметры DNS.Чтобы виртуальные машины и приложения в одноранговой виртуальной сети могли успешно взаимодействовать с управляемым доменом, необходимо обновить настройки DNS. IP-адреса контроллеров домена Azure AD DS должны быть указаны в качестве DNS-серверов для сети с настроенным пирингом. IP-адреса контроллеров домена Azure AD DS должны быть настроены как DNS-серверы в одноранговой виртуальной сети. У вас есть два способа настроить контроллеров домена в качестве DNS-серверов для сети с настроенным пирингом.Есть два способа настроить контроллеры домена в качестве DNS-серверов для одноранговой виртуальной сети:

• Настройте использование контроллеров домена Azure AD DS на DNS-серверах сети Azure. Настройте DNS-серверы виртуальной сети Azure для использования контроллеров домена Azure AD DS.
• Настройте условное перенаправление DNS на существующем DNS-сервере, который используется в сети с пиринговым подключением, чтобы направлять запросы в управляемый домен.Настройте существующий DNS-сервер, используемый в одноранговой виртуальной сети, на использование условной переадресации DNS для направления запросов в управляемый домен. Эти шаги будут отличаться в зависимости от текущего существующего DNS-сервера. Эти шаги различаются в зависимости от используемого существующего DNS-сервера.

С помощью этого руководства мы настроим на DNS-сервера виртуальной сети Azure переадресацию всех запросов к контроллеру домена Azure AD DS. В этом руководстве давайте настроим DNS-серверы виртуальной сети Azure для направления всех запросов к контроллерам домена Azure AD DS.

1. На портале Azure выберите группу ресурсов сети с настроенным пирингом, например myResourceGroup . На портале Azure выберите группу ресурсов одноранговой виртуальной сети, например myResourceGroup . В списке ресурсов виртуальная сеть с настроенным пирингом, например myVnet . Из списка ресурсов выберите одноранговую виртуальную сеть, например myVnet .

2. В виртуальной сети меню слева DNS-серверы .В левом меню окна виртуальной сети выберите DNS-серверы .

3. По умолчанию виртуальная сеть использует встроенный DNS-сервер, предоставленный Azure. По умолчанию виртуальная сеть использует встроенные DNS-серверы, предоставляемые Azure. Выберите для DNS-сервера вариант Пользовательские . Выберите Custom DNS-серверы. Введите IP-адреса контроллеров домена Azure AD DS, обычно это 10.0.2.4 и 10.0.2.5 .Введите IP-адреса для контроллеров домена Azure AD DS, обычно это 10.0.2.4 и 10.0.2.5 . Подтвердите эти IP-адреса в окне Обзор для вашего домена на портале. Подтвердите эти IP-адреса в окне Обзор вашего управляемого домена на портале.

4. Когда все будет готово, щелкните Сохранить . Когда все будет готово, выберите Сохранить . Обновление DNS-серверов для сети занимает несколько секунд.Обновление DNS-серверов для виртуальной сети занимает несколько минут.

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

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

Дальнейшие действияСледующие шаги

В этой игре вы узнали, как выполнять следующие задачи: В этом руководстве вы узнали, как:

• изучите варианты подключения к сети Azure AD DS для использования ресурсов домена; Изучите варианты подключения к виртуальной сети для ресурсов, присоединенных к домену, к Azure AD DS
• создайте подсдите диапазон IP-адресов и дополнительную сеть в сети Azure AD DS; Создайте диапазон IP-адресов и дополнительную подсеть в виртуальной сети Azure AD DS
• настроите пиринг с другой сетью, отличающейся от сети Azure AD DS.Настройка пиринга виртуальной сети для сети, отдельной от Azure AD DS

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

.

Домен. Сеть | Зарегистрируйте доменное имя .network — GoDaddy RU

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

Долл. США
Доллар США

---

AED AED
Дирхам ОАЭ

ARS $
Аргентинское песо

Австралийский доллар
Австралийский доллар

Бразильский реал
Бразильский реал

Канадский доллар канадский доллар
Канадский доллар

CHF CHF
Швейцарский франк

Чилийских песо
Чилийское песо

CNY ¥
Юань (китайский) юань

COP $
Колумбийское песо

Чешские кроны
Чешская крона

Датские кроны
Датская крона

EGP EGP
Египетский фунт

Евро €
Евро

Фунт стерлингов £
Фунт стерлингов

HKD HK $
Гонконгский доллар

HUF Ft
Венгерский форинт

IDR Rp
Индонезийская рупия

ILS ₪
Новый израильский шекель

INR ₹
Индийская рупия

JPY ¥
Японская иена

KRW ₩
Южнокорейский вон

MAD MAD
Марокканский дирхам

MXN MXN
Мексиканский песо

MYR RM
Малайзийский ринггит

NOK kr
Норвежская крона

Новозеландский доллар
Новозеландский доллар

PEN S /
Перуанский соль

PHP ₱
Филиппинское песо

PKR ₨
Пакистанская рупия

PLN zł
Польский злотый

RON лей
Румынский лей

Руб.
Русский рубль

SAR SAR
Саудовский риал

Шведские кроны
Шведская крона

SGD SG $
Сингапурский доллар

THB ฿
Тайский бат

ПОПРОБОВАТЬ TL
Турецкая лира

TWD NT $
Новый тайваньский доллар

Грн
Украинская гривна

UYU $
Уругвайское песо

VND ₫
Вьетнамский Đồng

ZAR R
Южноафриканский рэнд

.

Что такое CDN и как это работает? / Блог компании Selectel / Хабр

Цифры и факты (вместо введения)

• В 2010 средний размер веб-страницы составлял 481 кБ. В 2019 — уже 1936.7 кБ (подробная статистика). За последние три года значение этого показателя выросло на 314,7%. Как показывают исследования, тенденция к увеличению размера веб-страниц сохраняется.
• В настоящее время набирают популярность стриминговые аудио- и видеосервисы. По состоянию на апрель 2019 года число подписчиков популярного сервиса Spotify составило 217 миллионов.
• По данным опросов 25% пользователей уходят с веб-страницы, если она загружается дольше 4 секунд. 74% пользователей, загружающих сайт с мобильного устройства, предпочитают не ждать, если загрузка длится более 5 секунд. 46% пользователей отказываются иметь дело с веб-сервисом, если он медленно работает.

О чём свидетельствуют вышеприведенные факты?

О том, что в Интернете с каждым годом становится все больше «тяжелого» контента.
А также о том, что в современном мире огромную роль играет скорость работы веб-сайтов и сервисов.Это слишком малая скорость — это чревато потерей аудитории, во многих случаях — ещё и прибыли. Один из надёжных способов решения этой проблемы — использование сетей доставки контента (Content Delivery Networks, CDN).

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

Основные термины

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

CDN (Сеть доставки контента) — это географически распределённая сетевая инфраструктура, обеспечивающая быструю доставку контента пользователям веб-сервисов и сайтов. Входящие в состав CDN cерверы географически располагаются таким образом, чтобы сделать время ответа для пользователей сайта / сервиса минимальным.

Ориджин (origin) — сервер, на котором хранятся исходные файлы или данные, раздаваемые через CDN.

PoP (точка присутствия, точка присутствия) — кэширующий сервер в составе CDN, расположенный в определенной географической локации.Для обозначения таких серверов также используется термин edge.

Динамический контент — контент, генерируемый на сервере в момент получения запроса (либо изменяемый пользователь, либо загружаемый из базы данных).

Статический контент — контент, хранящийся на сервере, в неизменяемом виде (например, бинарные файлы, аудио- и видеофайлы, JS и CSS).

Немного истории и теории

Резкий рост Интернета в середине 1990-х привел к ситуации, что серверы стали с трудом выдерживать нагрузку.Стать серверами того времени (которые по техническим характеристикам иногда были слабее самого производственного современного ноутбука) приходилось идти на разные ухищрения: погуглите, например, «иерархическое кэширование» и информационная супермагистраль — сейчас эти словосочетания используются разве что в истории интернет-технологий . Чтобы понять, как развивающиеся технологии раздачи контента, сделаем небольшое теоретическое отступление.

Обратим внимание: раздача статического и динамического контента связаны с разными типами нагрузки на сервер.В случае с динамическим контентом, генерация которого контролирует базу данных, важны быстродействие процессора и объём оперативной памяти.

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

Для снижения нагрузки владельцы веб-сервисов ещё в конце 1990-х годов начали раздавать статику с разных серверов. Крупные веб-проекты с огромной аудиторией, разбросанной по всему миру, начали размещать серверы со статикой в ​​разных географических точках.

Тогда же, в конце 1990-х, стали появляться компании, которые стали одной из организаций раздачи статики, которая стала одним из основных видов бизнеса. В 1998 году студент Массачусетского технологического института Дэниэл Левин и преподаватель математики Томсон Лейтон основали компанию Akamai.Ныне она является одним из лучших (если не самым крупным) CDN-провайдером в мире.

Уже в 2004 году CDN использовали более 3000 компаний; общий объем расходов на доставку контента до 20 миллионов долларов в месяц.

Количество CDN во всём мире постоянно растет: соответствующие услуги в крупных международных компаниях (например, Akamai, Amazon, Cloudflare), так и многочисленные региональные провайдеры (подробные обзоры).

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

В течение последних 10-12 лет широкое распространение в Интернете получил еще один тип контента — стриминговый (многочисленные сервисы потокового аудио и видео, которые в наши дни имеют огромную популярность и миллионную, если не миллиардную, аудиторию). Раздача сегодня является еще одним распространенным сценарием использования CDN.

Рассмотрим принципы работы и особенности использования CDN более подробно.

Как работает CDN

Представим себе веб-сервис, которым пользуются люди на всей территории России.Основные серверы расположены в Санкт-Петербурге, а пользователи находятся в самых разных географических точках: скажем, в Краснодаре (2 604,2 км от Петербурга), Новосибирске (3 826,1 км), Иркутске (5 661, 7 км) или Владивостоке (9 602, 4 км). Чем дальше пользователь находится от оригинального сервера, тем больше время «оригинального» ответа. На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли загрузить простые веб-страницы полновесные 5, а то и все 10 минут.

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

Для ускорения раздачи динамики при использовании CDN используются другие механизмы: CDN-провайдер за счет своей сети сокращает сетевой маршрут.

Еще один интересный сценарий использования CDN — так называемый live-streaming: пользователи Интернета всего мира в браузере (а иногда и в специальном приложении) смотреть или слушать трансляцию с мест событий.Устроено это так: один или несколько ориджин-серверов принимают видеокамеры транслируемый поток, который сразу же ретранслируется на точки присутствия. Ориджин-серверы при этом контент клиенты не раздают. В состав стриминговых CDN входят также балансировщики нагрузки, перенаправляющие запросы к названию загруженным на текущий момент edge-серверам.

Как организована раздача контента?

Как правило, для настройки раздачи статического контента через CDN выполнить следующие шаги:

Шаг 1: Вынести статику сайта на отдельный домен, например, static.example.com — это будет origin.

Шаг 2: Для работы через CDN создать домен вида cdn.example.com.

Шаг 3: Подключить CDN у провайдера. Для подключения владельцу веб-сервиса необходимо сообщить о провайдеру следующее:
домен, с которого он будет забирать статику — static.example.com;
домен, с которого будет идти раздача — cdn.example.com.

Шаг 4: У своего DNS-регистратора настроить CNAME запись с cdn.example.com на домен CDN-провайдера, который CDN провайдер выделяет при подключении.
Например, в CDN Selectel такой домен имеет вид 85e77c09-bc03-43bf-b8f3-9492ae33390f.selcdn.net, где 85e72c09-bc03-43bf-b8f3-9492ae33390f создается автоматически.

Шаг 5: На своем сайте изменить домен для статики, которую планируется раздавать через CDN, на cdn.example.com.

Пользователь набирает в строке адрес адрес www.example.com, с которого он получает HTML-страницу. При этом весь статический контент, например, графические изображения, подгружается из CDN (с адреса cdn.example.com).

Статический контент, предназначенный для раздачи, часто помещается в объектные хранилища (об этом мы писали еще шесть лет назад). Существует набор плагинов и расширений для популярных CMS (WordPress, Joomla, Drupal, 1C Битрикс и других), с помощью которых можно настроить интеграцию с облачными сервисами хранения и раздачу статики через CDN.

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

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

Как CDN понимает, где находится ближайший кэширующий сервер?

Как правило, для загрузки контента из CDN используются две популярные технологии: GeoDNS и AnyCast.

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

При использовании технологии Anycast адреса общий, но маршрутизация происходит на «свои» серверы в пределах региона. При обращении к адресу www.example.com пользователь переадресуется на ближайшую точку присутствия.Провайдер пользователя получает несколько анонсов от разных сетей, в которых есть точка присутствия, и маршрутизатор провайдера выбирает из них самый близкий. Ответным аналогичным образом возвращается по наиболее короткому безопасному аналогу.

Как кэшируется контент?

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

Здесь очень важна география: например, после обращения пользователя из Рио-де-Жанейро данные будут закэшированы на сервере, находящемся на территории Бразилии, что не решит проблемы со скоростью доступа для пользователей из Парижа или Лондона.

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

В большинстве пользователей CDN, отправивший запрос на получение присутствующего контента, переадресуется к ближайшей точке доступа и получает кэшированную версию этого контента.Если ближайшая точка присутствия не найдет файлы, начнётся поиск по соседним точкам присутствия, откуда и будет перенаправлен ответ пользователю. В CDN Akamai эта процедура называется многоуровневым распределением (на русском можно перевести как «многоуровневая раздача»).

Для чего используются CDN?

Чаще всего CDN используется для уменьшения времени отклика кэшированного контента, как мы уже упоминаем выше, сокращает посетителей из-за медленной загрузки контента и тем самым сокращает возможные финансовые потери.Также CDN помогает снизить риск потери доступа к контенту из-за падения основного сервера. Контент будет доступ всё время, пока вы восстанавливаете работоспособность основного сервера.

Использование CDN легкого испытания на основной сервер, что помогает решить проблему пиковых нагрузок. Современная CDN способна переживать очень большие нагрузки. В конце 2018 года компания Akamai заявила о максимальном объеме предоставляемого через CDN трафик: 72 Тб / c.

В наше CDN активно используются также для раздачи стримингового времени контента.

О чем важно помнить при работе с CDN?

Как и любая технология, CDN обладает рядом возможностей.

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

Для доставки «свежего» контента в современных CDN имеется функция очистки кэша, то есть есть удаление контента из пула кэширования.Владельцы сайтов и сервисов могут сами управлять настройками, используя заголовки-валидаторы (см. Наши рекомендации на эту тему в опубликованной ранее статье).

Еще одна сложность, связанная с блокировками: если по той или иной причине будут заблокированы сервисы, являющиеся вашими «соседями» по IP CDN-провайдера, вместе с вами может оказаться заблокированным и ваш сайт. Но и это проблема решаема: по запросу CDN-провайдеры могут изменить ваш IP-адрес.

Кому нужны CDN?

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

CDN может пригодиться также разработчикам мобильных приложений: по статистике, пользователи часто отказываются продолжать работу с приложением из-за проблем со скоростью. В последнее время появились специальные технические решения, ориентированные на раздачу контента на мобильные устройства. Они так и называются — Мобильные CDN. Соответствующие услуги предоставляют многие крупные CDN-провайдеры — например, Akamai или Amazon.

Нужны CDN и проекта, ориентированным на распространение игрового мультимедийного контента и стриминг (об этом уже было сказано выше).

На что обратить внимание при выборе CDN-провайдера (вместо заключения)

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

На что нужно обратить внимание при выборе CDN-провайдера?

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

Во-вторых, это наличие стыков с операторами связи . Это тоже немаловажный фактор, от которого зависит скорость и эффективность работы CDN. Например, у CDN-провайдера с точками присутствия в 100 городах, но небольшое количество стыков задержка может больше, чем у провайдера, у которого точки присутствия расположены в 5 городах, но стыков с операторами связи гораздо больше.

К сожалению, такую ​​информацию в большинстве случаев проверить CDN-провайдеры не публикуют, поэтому всё можно только тестированием.

В-третьих, на наличие дополнительных услуг и функций . Многие CDN-провайдеры предоставляют такие услуги, как анализ статистики потребления, управление политиками кэширования, управление HTTP-заголовками, предзагрузка очень «тяжёлого» (от 200 МБ и более контента), полная и выборочная очистка кэша.

Кроме того, при выборе CDN-провайдера нужно проверить, поддерживает ли он необходимые вам технологии и протоколы (HTTP / 2, IPv6, сертификаты SSL и другие).

.

No related posts.