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

Ядро системы

Операционная система Linux является плодом труда людей, а им, как известно, свойственно ошибаться, даже в коде ядра. Отсюда первая угроза безопасности – ошибки в ядре системы. Подобные ошибки обнаруживаются не столь часто, сколь ошибки во всём остальном программном обеспечении, однако же такое бывает. Защита здесь одна (одинаковая для всœех подобных проблем) – постоянное отслеживание информации безопасности (к примеру, неплохим источником информации, помимо списка рассылки от производителя дистрибутива, является сайт www.securityfocus.com и его списки рассылки) и показания сервера.

Впрочем, существуют патчи на ядро, которые позволяют повысить защищённость системы в целом и ядра в частности. Основное внимание в таких патчах (в том числе кумулятивных) уделяется возможности противостоять системе от общих атак на программы с ошибкой на переполнение буфера, от атак на программы с некорректным созданием временных файлов и также на возможность уменьшить количество информации, которую может получить атакующий о системе (http://www.openwall.com/).

Также существуют патчи, специализирующиеся на сетевом аспекте работы ядра ОС. В их задачи входит встраивание функции защиты от сканирования в ядро системы (http://www.lids.org), а также функции затруднения определœения версии ОС средствами таких сетевых сканеров, как nmap.

При объединœении всœех этих патчей получается ядро системы, ĸᴏᴛᴏᴩᴏᴇ самостоятельно сможет предохранять систему от большинства типов известных атак: атаки на переполнение буфера, атаки на программы с неправильной работой с временными файлами, сетевое сканирование машины с целью определœения открытых портов и версии операционной системы.

В большинстве случаев, по непонятным для автора причинам, на ʼʼсвежеустановленномʼʼ сервере по умолчанию запущены практически всœе возможные сервисы (к примеру, совершенно не нужный на сегодняшний день 7-ой порт, сервис echo).

Практически каждый день находятся новые ошибки программирования в программном обеспечении. В том случае если будет найдена ошибка в сервисе, работающем на сервере, то через неĸᴏᴛᴏᴩᴏᴇ (не очень большое) время можно будет ожидать желающих скопрометировать сервер (так как, к примеру, ошибки на переполнение буфера, дают возможность выполнить любой код с правами сервера, которые нередко есть права суперпользователя – root). Защититься от таких проблем можно:

во-первых, регулярно отслеживая события безопасности (и опять же www.securityfocus.com будет, пожалуй, самым авторитетным и полным источником информации);

во-вторых, немного ʼʼподковавʼʼ ядро системы (различными патчами безопасности, как описано выше);

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

Начнём, пожалуй, с ненужных сервисов. Задачи, конечно, у каждого сервера бывают специфичными, но всё же можно сказать, что в большинстве случаев ненужными и в чём-то просто опасными являются порты (с соответствующими сервисами) с первого по девятнадцатый включительно. Какие-то из них бывают полезными, но большинство из них сейчас не используется. Не стоит открывать без особых причин и такие порты как 37 (time), 69 (tftp), 79 (finger), 111 (sunrpc), 512 (TCP – exec; UDP – biff), 513 (TCP – login; UDP – who), 514 (TCP – cmd; UDP – syslog), 517 (talk), 525 (timeserver).

Теперь что касается наиболее часто используемых сервисов, а именно: HTTP/HTTPS, FTP, Telnet/SSH, SMTP, POP3/IMAP и прокси-сервисы. Рассмотрим каждый сервис подробно.


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

  • — Сетевые службы и сетевые сервисы

    (слайд №8) Рис. 2.2. Клиент-серверная природа сетевых служб Совокупность серверной и клиентской частей ОС, предоставляющих доступ к конкретному типу ресурса компьютера через сеть, называется сетевой службой. В приведенном выше примере клиентская и серверная части ОС,… [читать подробнее].

  • — Сетевые сервисы безопасности

    Следуя скорее исторической, чем предметной логике, мы переходим к рассмотрению технической спецификации X.800, появившейся немногим позднее "Оранжевой книги", но весьма полно и глубоко трактующей вопросы информационной безопасности распределенных систем. … [читать подробнее].

  • — Информационная безопасность распределенных систем. Рекомендации X.800 Часть 1. Сетевые сервисы безопасности

    Следуя скорее исторической, чем предметной логике, мы переходим к рассмотрению технической спецификации X.800, появившейся немногим позднее "Оранжевой книги", но весьма полно и глубоко трактующей вопросы информационной безопасности распределенных систем. … [читать подробнее].

  • DNS-клиент

    Служба предназначена для получения IP-адреса удаленного компьютера при известном доменном или url-адресе этого компьютера (например, www.mail.ru). При этом процесс получения IP-адреса удаленного компьютера реализуется благодаря взаимодействию службы DNS-клиент с DNS-сервером. Это взаимодействие начинается после ввода запроса на подключение к удаленному компьютеру с использованием доменного имени компьютера (например, при вводе в адресную строку браузера адреса www.mail.ru).

    После этого служба DNS-клиент пытается найти IP-адрес компьютера, соответствующий введенному доменному или url-адресу, в своем кэше (данный кэш существует до окончания работы службы DNS-клиент и хранит соответствия всех IP-адресов доменным именам, которые уже были найдены службой DNS-сервер). Если служба DNS-клиент не находит в кэше соответствующий доменному имени IP-адрес, она обращается к содержимому файла HOSTS (если, конечно, обращение к данному файлу разрешено), расположенному на локальном компьютере (в каталоге %SystemRoot%\System32\drivers\etc) и включающему в себя соответствия между доменными именами и IP-адресами компьютеров, которым эти имена принадлежат. Если же и в этом файле нет сведений об IP-адресе необходимого компьютера, то служба обращается к DNS-cep-веру, используемому для разрешения имен компьютеров по умолчанию (в сети может существовать несколько DNS-серверов, при этом один из них является основным, к которому и обращаются компьютеры для разрешения имен). DNS-клиент ищет сведения об IP-адресе компьютера, которому принадлежит данное доменное имя, в своей базе данных. Если в базе данных DNS-сервера нет сведений о соответствующем этому доменному имени IP-адресе, то DNS-сервер просматривает свой кэш уже разрешенных имен компьютеров. Если и кэш не содержит необходимого IP-адреса, то DNS-сервер обращается с запросом на разрешение имени к вышестоящему DNS-серверу (например, если данный DNS-сервер включает в себя сведения о домене narod.ru, то DNS-сервер обращается к вышестоящему DNS-серверу, содержащему сведения о домене ru и т.д.). В итоге, если разрешение IP-адреса все-таки удалось, то IP-адрес, соответствующий данному доменному имени, передается DNS-клиенту, который, в свою очередь, передает его программе, запросившей у него разрешение имени (не забыв перед этим поместить данное разрешение имен в свой кэш). Если же разрешение имени не удалось, то программа оповестит об этом пользователя, сказав ему, что компьютер с введенным именем не найден.

    ПРИМЕЧАНИЕ

    Как уже говорилось, файл hosts расположен в каталоге %systemroot%\system\drivers\ ets и используется в случае, если в кэше DNS-клиента нет сведений о разрешении данного доменного или url-имени. Файл hosts является обычным текстовым файлом, содержащим соответствия IP-адреса компьютера его url-адресу. Вы сами можете создать данные соответствия для часто открываемых в Интернете сайтов, чтобы они открывались быстрее и при открытии загружали меньше трафика (ведь браузеру не придется обращаться к DNS-серверу). Для этого достаточно в файле hosts создать строку такого вида: IP-адрес URL-адрес. Например, можно разрешить IP-адрес сайта www.mail.ru. Его url-имя у вас есть (www.mail.ru), но как узнать IP-адрес? Для этого вам понадобится программа командной строки ping.exe. Необходимо запустить командную строку и ввести команду ping www.mail.ru, после чего программа выведет IP-адрес, принадлежащий url-имени www.mail.ru. Для www.mail.ru это будет адрес 194.67.57.26, то есть в файле hosts нужно создать строку вида 194.67.57.26 www.mail.ru.

    С помощью файла hosts можно также бороться с баннерными серверами. Для этого достаточно разрешить имя сайта, который раздает другим сайтам баннеры, на IP-адрес своего компьютера (например, с помощью строки 127.0.0.1 www.banners.com), и баннеры от этого сайта больше не будут загружаться.

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

    Служба DNS-клиент занимает около 2604 Кбайт памяти и запускается с правами сетевой службы (NT AUTHORITY\NetworkService) автоматически при каждом входе пользователя в систему (при этом она запускается как отдельный процесс svchost.exe). Данная служба необходима, если в сети присутствует DNS-сервер или компьютер принадлежит к Active Directory (Active Directory уже предполагает, что в сети есть DNS-сервер, ведь без него Active Directory нельзя будет установить). Если эти условия не выполняются, то службу DNS-клиент можно отключить (можно подумать, что эта служба также необходима для подключения к Интернету, но, как показали исследования, это не так, хотя без ее использования качество поиска страниц в Интернете может пострадать, поэтому не рекомендуется отключать данную службу, если вы подключены к Интернету). Для этого необходимо DWORD-параметру Start, расположенному в ветви реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache, присвоить значение 4.

    Для запуска службы DNS-клиент необходимо, чтобы уже была запущена служба Драйвер протокола TCP/IP.

    Для работы службы DNS-клиент также необходима библиотека dnsrslvr.dll.

    Утилита DcDiag изначально была частью набора инструментов для поддержки администрирования (которые нужно было устанавливать отдельно) в ранних верси­ях Windows Server, но теперь она по умолчанию является частью установки Windows Server 2012 R2. Это инструмент, который нужно применять первым для быстрой проверки работоспособности структуры DNS. Поскольку утилита DcDiag прово­дит диагностику контроллеров домена, она должна проверить корректность работы DNS. После выполнения стандартного набора тестов вы можете заметить ошибки при попытках подключения к контроллерам домена. После этого можно запустить дополнительные тесты DcDiag, ориентированные специально на DNS. В следующем примере осуществляется проверка, может ли контроллер домена выполнять DDNS для регистрации записей SRV:

    С:\> dcdiag /test:RegisterInDNS /DnsDomain:ishankulov.ru /f: documents\dcdiagRegisterlnDNS.txt

    Ниже показан вывод этой команды:

    Starting test: RegisterlnDNS DNS configuration is sufficient to allow this domain controller to dynamically register the domain controller Locator records in DNS. The DNS configuration is sufficient to allow this computer to dynarnically register the А record corresponding to its DNS name. srv1 passed test RegisterlnDNS

    Утилита DcDiag выполняет множество тестов, относящихся к контроллеру доме­на, включая несколько тестов DNS. Выше был упомянут один из таких тестов — RegisterlnDNS. Эти тесты в первую очередь сосредоточены на интеграции между DNS-серверами внутри среды Active Directory. Тесты могут быть выполнены в отно­шении делегирования, серверов пересылки, обновлений и преобразовании внешних имен DNS.

    Ниже приведена часть справочной информации по утилите DcDiag. В ней при­сутствует список тестов, доступных для DNS. При тестировании преобразования внешних имен мы обычно полагаемся на NsLookup, поэтому никогда не пользуемся тестами /DnsForwarders и /DnsResolveExtName, но для полноты они здесь пока­заны.

     

    DNS

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

    По умолчанию запускаются все тесты кроме тех, которые проверяют преобразование внешних имен.

    /DnsBasic — базовые тесты, не могут быть пропущены

    /DnsForwarders —  тесты для серверов пересылки и корневьи подсказок

    /DnsDelegation —  тесты для делегирования

    /DnsDynamicUpdate —  тесты для динамических обновлений

    /DnsRecordRegistration —  тесты для регистрации записей

    /DnsResolveExtName —  тесты для преобразования внешних имен

    /DnsAll —  включает все перечисленные выше тесты

    /DnslnternetName:<Интернет-имя> —  для теста /DnsResolveExtName (по умолчанию www.microsoft.com)

    Количество SRV-записей, зарегистрированных контроллером домена, настолько велико, что определить на глаз, корректно ли они работают, достаточно трудно. В до­полнение к тесту /RegisterInDNS прогоняются тесты /DnsDynamicUpdate и /DnsRecordRegistration, проверяющие регистрацию записей SRV контроллерами доменов.

    В отличие от /RegisterInDNS, они не обязательно должны запускаться локально на контроллере домена. Представленная ниже команда будет верифици­ровать записи SRV для контроллера домена. Опция /v означает “verbose” (“подроб­но”). Вывод получается длинным, поскольку в нем перечислены все записи SRV для контроллера домена.

    С:\> dcdiag /s:srv1.ishankulov.ru /test:dns /dnsrecordregistration /v

    Следующая команда будет проверять работоспособность обновлений DDNS для зоны. Она зарегистрирует хост и удалит его из зоны DNS сервера. В данном случае сервером является srv2.ishankulov.ru.

    C:\> dcdiag /s:srv2.ishankulov.ru /test:dns /dnsdynamicupdate /v

    Создание зоны заглушки DNS

    Концепция зон-заглушек

    Концепция зон-заглушек является уникальной и встречается только в DNS производст­ва Microsoft. Под зоной-заглушкой (stub zone) подразумевается зона, в которой не содержит­ся никакой информации о членах домена и которая служит просто для перенаправления запросов к списку назначенных серверов имен для различных доменов.

    Если возникает необходимость получить возможности, предлагаемые зоной-заглушкой, в Windows Server 2008 R2 такую зону создать очень легко. Ниже перечислены соответст­вующие шаги.

    1. Откройте консоль Server Manager (Диспетчер сервера).
    2. Разверните последовательно узлы Roles (Роли), DNS Server (DNS-сервер), DNS и узел, название которого совпадает с именем нужного сервера.
    3. Щелкните на узле Forward Lookup Zones (Зоны прямого просмотра).
    4. Выберите в меню Action (Действие) пункт New Zone (Создать зону).
    5. На экране приветствия щелкните на кнопке Next (Далее).
    6. В списке возможных типов зон выберите вариант Stub Zone (Зона-заглушка).

      Поскольку эта зона не будет интегрироваться в AD, снимите отметку с флажка Store the Zone in Active Directory (Сохранить зону в Active Directory), если он отмечен, и для продолжения щелкните на кнопке Next.

    7. Введите желаемое имя для новой зоны и щелкните на кнопке Next.
    8. Выберите вариант Create a New File with This File Name (Создать новый файл с таким именем) и оставьте предлагаемые по умолчанию параметры, если только не требует­ся импортировать какой-то существующий файл зоны. Для продолжения щелкните на кнопке Next.
    9. Введите IP-адрес сервера или серверов, с которых должны копироваться записи для этой зоны, нажимая после ввода адреса каждого сервера клавишу <Enter> для про­верки его правильности. Для продолжения щелкните на кнопке Next.
    10. На странице Summary (Сводная информация) щелкните на кнопке Finish (Iotobo), чтобы создать зону.

    В новой созданной зоне-заглушке будут содержаться записи SOA, записи NS и связанные записи только из того домена, на который она указывает.

    DNS Службы и Протокол

    Рубрика: Сетевые протоколы, Службы и сетевые сервисы

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

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

    При рассмотрении различных протоколов и служб TCP/IP Прикладного уровня, мы будем ссылаться на стандартные номера портов TCP и UDP, которые обычно связаны с этими службами. Некоторые из этих служб:

    DNS

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

    В Интернете эти доменные имена, такие как yandex.ru, людям гораздо легче запомнить, нежели 213.180.193.11, что является фактическим числовым адресом для этого сервера. Кроме того, если адрес сайта google.ru вдруг поменяется, это произойдет незаметно для пользователя, поскольку доменное имя по прежнему останется yandex.ru. Новый адрес просто будет привязан к существующему доменному имени и возможность захода на сайт не пострадает. Когда сети были небольшими, поддержка соответствия между доменными именами и адресами, которые они представляют, была простой задачей. Однако, как только сети начали расти, а количество устройств увеличиваться, эта ручная система стала неработоспособной.

    Система Доменных Имен (DNS) была создана вместо доменного имени, чтобы решить проблему разрешения для растущих в размерах сетей.

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

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

    Далее: Утилита nslookup

    Смотрите также

    Написать

    Добавить комментарий

    Закрыть меню