По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Система доменных имен (DNS – Domain Name System) обеспечивает сетевую коммуникацию. DNS может показаться какой-то невидимой силой или сущностью до тех пор, пока что-то пойдет не так, потому что если DNS выйдет из строя, то ничего работать не будет.
В данной статье будут рассмотрены передовые методы и наиболее важные меры безопасности для поддержания работоспособности вашей инфраструктуры DNS. Чтобы создать безопасную и надежную DNS, обязательно изучите перечисленные ниже пункты.
Передовые технологии для обеспечения высокой производительности DNS
Обеспечение избыточности и высокой доступности DNS
DNS является основой сетевых приложений, поэтому инфраструктура DNS должна быть высоко доступной. А чтобы обеспечить необходимый уровень избыточности, в вашей организации должно быть, как минимум, два DNS-сервера, первичный и вторичный.
Чтобы обеспечить работу критически важных для бизнеса систем, необходимо иметь, как минимум, два внутренних DNS-сервера. Все системы активного каталога, обмена данными и электронной почты полагаются на корректную работу DNS. Без исправно функционирующих внутренних DNS-серверов внутренние устройства не будут иметь возможности обмениваться данными.
Если на одном DNS-сервере возникнет проблема, то второй сразу же заменяет его. Администраторы настраивают оборудование так, чтобы автоматически использовался вторичный DNS, если первичный не отвечает. IP-адрес внутреннего DNS-сервера может быть любым в диапазоне IP-адресов частной сети.
Обеспечивая избыточность DNS-серверов, вы можете добиться высокой доступности инфраструктуры DNS. Непрерывная репликация с первичных серверов на вторичные обеспечит синхронизацию ваших DNS-записей и защитит систему от сбоев. Вы можете быть уверены в том, что конечный пользователь всегда будет иметь возможность получить доступ к системам.
Сокрытие DNS-серверов и DNS-информации
Не каждый DNS-сервер и не каждая информация должна быть доступна для всех пользователей.
Во-первых, откройте только те серверы и данные, которые необходимы лицам, непосредственно использующим эти серверы. Это особенно важно, если ваши доменные имена являются общедоступными.
Во-вторых, скройте свой основной DNS-сервер. Внешние пользователи не должны видеть первичные серверы. Записи для этих серверов не должны быть видны ни в одной общедоступной базе данных серверов имен. Запросы от пользователей должны обрабатывать только вторичные DNS-серверы.
Если DNS-сервер доступен за пределами вашей сети, то это должен быть авторитативный DNS-сервер. Внешним пользователям не нужно обращаться к вашим рекурсивным DNS-серверам. Системная конфигурация будет высокопроизводительной только тогда, когда сервер будет отвечать только на итеративные запросы для соответствующих зон, за которые он отвечает.
В довершение ко всему, иметь доступ к первичным серверам должны только системные администраторы и IT-персонал вашей организации. Если ваши первичные DNS-серверы будут открыты для всех внутренних пользователей, то это может создать серьезную угрозу для безопасности. Как показывает практика, лучше скрывать DNS-серверы и некоторые данные от пользователей, которым доступ к ним не нужен.
Нужно ли использовать внешний или внутренний DNS-сервер?
Ответ на данный вопрос зависит от внутренней настройки.
Чтобы устройства в одном домене могли общаться друг с другом, вам необходимо указать внутренний DNS-сервер. Внешние DNS-серверы не могут работать с именами хостов внутренних устройств.
Например, когда компьютер DESKTOP1 отправляет DNS-запрос для офисного принтера или сервера hr-1, только внутренняя DNS может предоставить запись ресурса. Если вы настроите устройство на использование внешнего DNS, например, 8.8.8.8 Google, то вы не сможете использовать внутренние ресурсы.
Во внутренних средах необходимо установить, как первичный, так и вторичный DNS на внутренний сервер имен. Даже если основной DNS-сервер даст сбой, проблем с подключением не будет. Дополнительный DNS-сервер содержит все записи и действует как резервная копия. В случае возникновения какой-либо проблемы, этот сервер отвечает на все запросы до тех пор, пока не заработает основной сервер.
Использование локального или ближайшего DNS-сервера
Офисы крупных организаций часто расположены по всему миру. В таком случае следует настроить локальный DNS-сервер в каждом офисе, если позволяет инфраструктура.
А все потому, что локальный сервер сокращает время ответа на DNS-запросы. Если же запрос проходит через глобальную сеть к удаленному серверу имен, то время загрузки увеличивается.
При большом количестве клиентов, естественно, увеличивается количество DNS-запросов. Одна централизованная группа DNS-серверов, конечно, может обрабатывать все эти запросы, но с большой задержкой. Если компьютеры пользователей будут направляться на локальный или ближайший сервер имен, то время отклика может существенно сократиться.
В таком случае задержка не превышает 50 мс. Более того, это значение обычно даже намного ниже. Использование ближайшего DNS-сервера сокращает время загрузки для всех устройств. Таким образом, вы также уменьшаете нагрузку на удаленный сервер в штаб-квартире и повышаете его производительность. Здесь также остается актуальной рекомендация иметь, как минимум, два DNS-сервера.
Передовые методы обеспечения безопасности DNS
DNS-серверы очень часто становятся целью кибератак. Важным шагом в предотвращении вторжений в вашу организацию является защита инфраструктуры DNS. Чтобы избежать серьезного нарушения настроек DNS, обязательно изучите меры безопасности, описанные ниже.
Ведение журнала DNS-сервера
Ведение журнала DNS-сервера – это один из самых эффективных способов отслеживания активности DNS. Журналы сообщают вам, если кто-то пытается вмешаться в ваши DNS-серверы. Помимо активности пользователей, журналы отладки сообщают вам о проблемах с DNS-запросами или обновлениями.
Журналы DNS также показывают следы отравления кэша. При таком виде атаки злоумышленник изменяет хранящиеся в кэше данные и сбивают пользователей с курса. Например, IP-адрес www.youtube.com может быть заменен на IP-адрес вредоносного сайта. Когда пользователь отправляет запрос в DNS для youtube.com, сервер теперь возвращает неверный IP-адрес. В результате чего пользователи попадают на тот веб-сайт, который они не хотели посещать и становятся мишенью для хакеров.
Несмотря на то, что ведение журнала отладки DNS повышает уровень безопасности, некоторые системные администраторы решают этим пренебречь. Основная причина такого решения – повышение производительности. Отслеживание сетевой активности может помочь вам обнаружить некоторые атаки, такие как DDoS, но не отравление кэша. Поэтому мы настоятельно рекомендуем использовать ведение журналов отладки DNS.
Блокировка кэша DNS
Всякий раз, когда появляется запрос от клиента, DNS находит информацию и сохраняет ее в кэше для будущего использования. Этот процесс позволяет серверу быстрее отвечать на одни и те же запросы. Злоумышленники могут воспользоваться этой функцией путем изменения сохраненной информации.
Следующий шаг после использования журналов отладки DNS – это блокировка кэша DNS. Это функция определяет, когда кэшированные данные могут быть изменены. Сервер хранит информацию о поиске в течение времени, определяемого TTL (Time To Life - время жизни). Если блокировка кэша не используется, то информация может быть перезаписана до истечения TTL. Это оставляет место для атак с отравлением кэша.
В некоторых операционных системах блокировка кэша может быть включена по умолчанию. Масштаб блокировки кэша может достигать 100%. Когда установлено значение 70, то перезапись данных невозможна до истечения 70% TTL. При определении блокировки кэша равным 100 изменение кэшированной информации блокируется до истечения всего TTL.
Фильтрация DNS-запросов для блокировки вредоносных доменов
Фильтрация DNS – это эффективный способ ограничить доступ пользователей к веб-сайту или домену. Основная причина для блокировки разрешения имен для домена – наличие информации о вредоносности этого домена. Когда клиент отправляет запрос на заблокированный веб-сайт, DNS-сервер прекращает любую связь между ними.
DNS-фильтрация значительно снижает вероятность проникновения вирусов и вредоносных программ в вашу сеть. Когда пользователь не может получить доступ к вредоносной странице, то и количество угроз, которые могут проникнуть в вашу инфраструктуру, крайне мало. Таким образом, вашему IT-персоналу не требуется круглосуточно работать, чтобы очищать систему от вирусов.
Помимо соображений безопасности, есть еще одна причина, по которой организации могут заблокировать домен – бизнес-политика или по соображениям производительности. В список заблокированных доменов могут входить социальные сети, азартные игры, порнография, страницы потокового видео или любые другие веб-сайты. DNS может фильтровать запросы по пользователю, группе или блокировать доступ для всех пользователей.
Современные системы обеспечения защиты ПО и брандмауэры имеют DNS-фильтрацию в стандартной комплектации. Некоторые из них предоставляют списки плохих доменов, которые регулярно обновляются. Вы можете использовать готовое программное решение и таким образом автоматизировать фильтрацию DNS, а не добавлять новые записи вручную.
Проверка целостности данных DNS с помощью DNSSEC
Модули безопасности службы доменных имен (DNSSEC – Domain Name System Security Extensions) гарантируют, что пользователи получат действительные ответы на свои запросы. Целостность данных достигается за счет цифровой подписи DNSSEC на данных DNS, предоставляемых серверам имен. Когда конечный пользователь отправляет запрос, DNS-сервер предоставляет цифровую подпись с ответом. Стало быть, пользователи знают, что они получили достоверную информацию в качестве ответа на отправленный ими запрос.
Этот дополнительный уровень безопасности помогает бороться с атаками на протокол DNS. Атаки «спуфинга» DNS и отравления кэша успешно предотвращаются, поскольку DNSSEC обеспечивает целостность данных и авторизацию их источника. В дальнейшем пользователи будут уверены, что посещают именно те страницы, которые хотели посетить.
Настройка списков контроля доступа
Списки контроля доступа (ACL – Access Control Lists) – это еще один способ защиты DNS-серверов от несанкционированного доступа и атак «спуфинга». К вашему основному DNS-серверу доступ должны иметь только системные и IT-администраторы. Настройка ACL для разрешения входящих подключений к серверу имен с определенных хостов гарантирует то, что только определенная часть персонала сможет обращаться к вашим серверам.
Кроме того, ACL должны определять, какие серверы могут выполнять передачу зон. Злоумышленники могут попытаться определить настройки вашей зоны, отправив запросы на передачу зоны через вторичные DNS-серверы. Если вы заблокируете все запросы на передачу зоны через вторичные серверы, то злоумышленник не сможет получить информацию о зоне. Эта конфигурация не позволяет третьим лицам получить представление о том, как организована ваша внутренняя сеть.
Заключение
Всегда есть возможности для улучшения системной архитектуры DNS и ее безопасности. Постоянные угрозы скрываются и ждут, когда появится уязвимость в вашей информационной системе, чтобы воспользоваться ей.
Но тем не менее, если вы будете следовать рекомендациям, описанным в данном руководстве, то вы охватите наиболее важные аспекты, которые необходимы для обеспечения безопасности и отказоустойчивости вашей инфраструктуры DNS.
Веб-сервер - это серверное приложение, предназначенное для обработки HTTP-запросов между клиентом и сервером. HTTP - это базовый и широко используемый сетевой протокол.
Apache HTTP Server сыграл важную роль в разработке веб-сайтов. Только у него доля рынка 37,3%. Nginx занимает второе место в списке, с долей рынка 32,4%. Microsoft IIS и LiteSpeed с долей рынка 7,8% и 6,9% занимают 3 и 4 места соответственно.
Но недавно я наткнулся на веб-сервер с названием Caddy. Когда развернул его для тестирования и попытался узнать о его функциях, был приятно удивлён. Это переносимый веб-сервер с минимальной конфигурацией. Я решил, что это очень крутой проект и захотел поделиться им с вами.
Что такое Caddy?
Caddy с его простотой в настройках и использовании является альтернативой популярному веб-серверу Apache. Мэтью Холт - руководитель проекта Caddy утверждает, что их продукт является веб-сервером общего назначения, и он предназначен для обычных людей, и, вероятно, является единственным в своем роде.
Caddy является первым и единственным веб-сервером, который может автоматически получать и обновлять сертификаты SSL/TLS с помощью сервиса Let 's Encrypt.
Функции Caddy
Быстрое выполнение HTTP-запросов с использованием HTTP/2.
Веб-сервер с наименьшей конфигурацией и беспрепятственным развертыванием.
TLS шифрование обеспечивает безопасную связь между приложениями и пользователями через Интернет. Вы можете использовать собственные ключи и сертификаты.
Простота развертывания/использования. Только один файл без зависимости от платформы.
Установка не требуется.
Портативные исполняемые файлы.
Запуск нескольких ЦП/ядер.
Усовершенствованная технология WebSockets - интерактивный сеанс связи между браузером и сервером.
Разметка документов на лету.
Полная поддержка нового протокола IPv6.
Создает журнал в пользовательском формате.
Поддержка Fast CGI, обратного прокси, перезаписи и перенаправления, чистый URL-адрес, сжатия Gzip, просмотра каталогов, виртуальных хосты и заголовков.
Доступно для всех известных платформ - Windows, Linux, BSD, Mac, Android.
Чем отличается Caddy?
Caddy стремится обслуживать интернет, как это должно быть в 2020 году, а не в традиционном смысле.
Обладает новейшими функциями - HTTP/2, IPv6, Маркдаун, WebSockets, CreateCGI, шаблоны и другие стандартные функции.
Запуск исполняемые файлы без установки.
Подробная документация с наименьшим техническим описанием.
Разработан с учетом потребностей конструкторов, разработчиков и блоггеров.
Поддержка виртуального хоста можете создавать любое количество сайтов.
Подходит для всех - независимо от того, является ли ваш сайт статическим или динамическим.
Вы фокусируетесь на том, чего достичь, а не на том, как этого добиться.
Доступность поддержки большинства платформ - Windows, Linux, Mac, Android, BSD.
Обычно на каждый сайт приходится по одному файлу Caddy.
Возможность настройки буквально за 1 минуту, даже для тех, кто не сильно дружит с компьютером.
Тестовая среда
Я буду тестировать его на сервере CentOS, а также на сервере Debian, но те же инструкции работают и на дистрибутивах RHEL и Debian. Для обоих серверов я буду использовать 64-разрядные исполняемые файлы.
Установка веб-сервера Caddy на Linux
Независимо от используемой платформы и архитектуры Caddy предоставляет готовые установщики, которые можно запустить с помощью встроенного в систему пакетного менеджера.
Установка Caddy на Fedora, RedHat, CentOS
Мы установим последнюю версию веб-сервера Caddy из репозитория CORP на Fedora и RHEL/CentOS8.
# dnf install 'dnf-command(copr)'
# dnf copr enable @caddy/caddy
# dnf install caddy
На RHEL/CentOS 7 используйте следующие команды:
# yum install yum-plugin-copr
# yum copr enable @caddy/caddy
# yum install caddy
Установка Caddy на Debian и Ubuntu
$ echo "deb [trusted=yes] https://apt.fury.io/caddy/ /"
| sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
$ sudo apt update
$ sudo apt install caddy
Установив веб-сервер Caddy, с помощью следующих команд systemctl его можно запустить, активировать или же проверить статус:
# systemctl start caddy
# systemctl enable caddy
# systemctl status caddy
Теперь откройте браузер и введите следующий адрес, и вы должны увидеть страницу приветствия Caddy:
http://Server-IP
OR
http://yourdomain.com
Настройка доменов в Caddy
Чтобы настроить домен, сначала необходимо указать DNS-записи A/AAAA домена на этом сервере на панели управления DNS. Затем создайте корневой каталог документа для веб-сайта "example.com" в папке/var/www/html, как показано на рисунке.
$ mkdir /var/www/html/example.com
При использовании SELinux необходимо изменить контекст безопасности файлов для веб-содержимого.
# chcon -t httpd_sys_content_t /var/www/html/example.com -R
# chcon -t httpd_sys_rw_content_t /var/www/html/example.com -R
Теперь откройте и отредактируйте файл конфигурации caddy по адресу /etc/caddy/Caddyfile.
# vim /etc/caddy/Caddyfile
Замените :80 на название вашего домена и измените корень сайта на /var/www/html/example.com, как показано на рисунке.
Чтобы изменения вступили в силу перезапустите службу Caddy:
# systemctl reload caddy
Теперь создайте какую-нибудь HTML-страницу (можно создать собственную) и сохраните её в корневом каталоге веб-сайта.
# touch /var/www/html/example.com/index.html
Добавьте следующий HTML-код в только что созданный файл.
# echo '<!doctype html><head><title>Caddy Test Page at TecMint</title></head><body><h1>Hello, World!</h1></body></html>' | sudo tee /var/www/html/index.html
А теперь перезагрузите страницу, и вы должны увидеть нечто подобно скриншоту ниже:
Если все настроено правильно, домен будет доступен по протоколу HTTPS, что означает на вашем сайте настроено безопасное SSL подключения.
Заключение
Если вы новичок и хотите настроить веб-сервер, не заморачиваясь долгой настройкой, этот инструмент идеально подходит для вас. Даже если вы опытный пользователь, который нуждается в мгновенном и простом веб-сервере, то стоит обратить внимание на Caddy. Если необходим более навороченный сервер с расширенными возможностями, то можно с минимальными конфигурациями задать разрешения на папки, управлять аутентификацией, страницей ошибок, архивацией, перенаправлением HTTP запросов и другими настройками.
Конечно же нельзя воспринимать Кэдди в качестве замены Apache или Nginx. Caddy не предназначен для работы в среде с высоким трафиком. Но он хорошо подойдёт в тех случаях, где нужно быстро настроить надежный веб-сервер.
В прошлой статье мы создали и настроили контроллер домена (DC), настало время наполнить наш домен пользователями и рабочими станциями.
Конфигурация
Открываем Server Manager и выбираем опцию Roles.
Из доступных ролей выбираем недавно установленную - Active Directory Domain Services, далее Active Directory Users and Computers и находим созданный нами домен (в нашем случае - merionet.loc). В выпадающем списке объектов находим Users и кликаем по данной опции правой кнопкой мыши и выбираем New → User.
Отметим также, что вы можете создать свою группу и добавлять пользователей туда.
Перед нами откроется окно добавления нового пользователя. Заполняем учетные данные нового пользователя. Как правило, в корпоративных доменах, принято создавать именные учетные записи для того, чтобы в дальнейшем можно было отслеживать действия конкретного пользователя в целях безопасности и однозначно его идентифицировать.
Далее, нас просят ввести пароль для новой учетной записи и выбрать дополнительные опции:
User must change password at next logon - при включении данной опции, пользователя попросят сменить пароль при следующем логине;
User cannot change password - пользователь не сможет самостоятельно изменить свой пароль;
Password never expires - срок действия пароля пользователя никогда не истечет;
Account is disabled - учетная запись пользователя будем отключена и он не сможет залогиниться с доменными учетными данными, даже если они будут введены верно.
После того, как все данные будут заполнены, нас попросят подтвердить создание нового объекта.
Отлично, новый пользователь домена создан. Теперь нам нужно зайти на компьютер пользователя и ввести его в домен. Для этого логинимся на компьютер пользователя с локальными учетными данными и открываем Свойства компьютера. Как видите, наш компьютер пока еще не стал частью домена, он ещё является частью рабочей группы WORKGROUP/. Убедитесь, что компьютер пользователя имеет версию Windows не ниже Professional. Чтобы ввести его в домен выбираем Change Settings
Важно! Поддержка доменной инфраструктуры начинается только с версии Windows Professional. На версиях Starter, Home Basic, Home Premium подключиться к домену не получится!
Далее напротив опции "To rename this computer or change its domain or workgroup, click Change" нажимаем собственно Change
Важно! Для того, чтобы наш компьютер узнал о существующем контроллере домена нам нужно указать ему на DNS сервер, который имеет такую информацию. В нашем случае – контроллер домена является по совместительству DNS сервером для пользовательских машин. Поэтому мы указываем контроллер домена в качестве DNS сервера для настраиваемого компьютера.
Далее в открывшемся окне в опции "Member of" вместо Workgroup выбираем Domain и вводим имя нашего домена (в нашем случае – merionet.loc)
Далее нас попросят ввести учетные данные для учетной записи, которая уже создана и имеет право присоединиться к домену. Вводим учетные данные ранее созданного пользователя.
Если все было сделано корректно, то мы увидим сообщение, свидетельствующее о том, что наш компьютер теперь является частью домена (в нашем случае - merionet.loc)
После чего, нас попросят перезагрузить компьютер для применения изменений.
После перезагрузки, мы можем логиниться уже с учетными данными доменного пользователя.
Теперь, если мы откроем свойства компьютера, то увидим, что наш компьютер принадлежит домену (в нашем случае – merionet.loc)