Skip to main content

DNS flag day: 1 февраля 2019 года ваш сайт может перестать работать из-за DNS

Здравствуйте, уважаемые читатели!

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

Начну с предупреждающего сообщения: 1 февраля 2019 года наступит DNS Flag Day, после которого ваш сайт может быть недоступен пользователям в Интернет.

Для начала немного не занудной истории: протокол DNS был разработан в начале 1980 годов и с тех времен в него понадобилось добавить новые функции и возможности. Эти работы были проделаны аж в 1999 году, когда в RFC 2671 была опубликована первая версия расширений под названием Extension Mechanism for DNS. Данная версия позволила снять некоторые ограничения, например, на размер некоторых полей флагов, кодов возврата и тому подобные вещи. Текущая версия расширенного протокола EDNS описана в RFC 6891.
При этом, в сети Интернет продолжают существовать DNS-сервера, которые не поддерживают EDNS, не обеспечивая обратную совместимость, что приводит как к замедлению работы всей системы DNS, и к невозможности реализовать все новые возможности EDNS.

Отныне, с 1 февраля 2019 года не поддерживающие стандарт EDNS сервера будут недоступны, и попасть на них будет невозможно. Будут внесены изменения в самое популярное ПО, отвечающее за работу DNS такое как Bind, Unbound, PowerDNS, Knot Resolver, которые отныне будут принимать только соответствующий стандарту EDNS-трафик. Ну а трафик со старых и не обновлённых серверов будет рассматриваться как неприемлемый, и эти сервера далее обслуживаться не будут, что может привести к недоступности доменов и сайтов которые размещены на этих самых серверах.

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

Для проверки доступа к сайту нужно зайти на сайт dnsflagday.net, ввести там имя своего домена и получить результат, который будет иметь разные значения. В идеале вы должны увидеть картинку, аналогичную той, которая показана ниже для сайта pingmeup.ru:

dnsflagday.net - проблем с DNS не обнаружено

Если вы видите картинку, аналогичную той, которая выдается, например, для сайта ГБУК г. Москвы “Московский Международный Дом музыки», то это означает, что сайт работать будет, но без поддержки последних изменений в стандарте DNS, и не сможет в полном объеме реализовать необходимые функции безопасности и даже может стать мишенью для хакеров, которые теоретически могут взломать или атаковать этот сайт:

dnsflagday.net - DNS minor problems deteted

Если в результате проверки появились предупреждения с красными значками, как, например для сайтов nalog.ru или sberbank.ru то вам лучше всего побыстрее обновить ПО, обеспечивающее работу вашего DNS:

Nalog.ru - fatal error DNS sberbank.ru - sberbank_ru - serious problem DNS

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

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

На этом на сегодня всё – всем желаю удачи и спасибо за внимание!

Добавляем комп в домен с помощью Powershell

Здравствуйте!

Если вы начинающий админ, то вам просто необходимо прочитать эту статью.

Сегодня разберем типовую операцию добавления нового компа в доменную сеть посредством Microsoft Powershell.

Если вы добавляете компьютер в домен через GUI, то это долго и не практично. Пользуйтесь Microsoft Powershell — это удобно и сэкономит вам кучу времени и сил, к тому же позволит добавлять сотни и даже тысячи (если есть такая необходимость) компьютеров быстро и через консоль.

Сделать это можно при помощи команды Powershell Add-Computer.

Для этого откройте консоль Powershell с правами администратора, и в командной строке наберите следующую команду:

add-computer -DomainName pingmeup -credential pingmeup\admin –OUPath "OU=me,DC=pingmeup,DC=ru"; restart-computer

Эта команда включит компьютер в домен pingmeup.ru в  подразделение (Organization Unit) «me», и после выполнения перезагрузит компьютер. Точка с запятой  во второй части (;) нужна для разделения двух команд.

На этом всё.

Всем удачи, и добра! Берегите себя.

Как скрыть компьютер на ОС Windows в локальной сети

Здравствуйте!

Сегодня я поделюсь с вами небольшой заметкой о маленьком но полезном трюке — как скрыть компьютер на ОС Windows в локальной сети (корпоративной сети) от любопытных глаз.

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

— не волнуйтесь, возможность обмениваться файлами останется, компьютер лишь скроется из списка компьютеров в обозревателе сети Windows (сетевое окружение Windows), что в свою очередь может повысить безопасность. Так что фича полезная, можно пользоваться.

— Итак, погнали!

Подробнее

Просмотр процессов и TCP-портов в Windows стандартными средствами

Всем привет!

Иногда нужно промониторить сетевые порты на локальной (или удаленной машине), но дополнительного программного обеспечения на этих компьютерах нет. Тут на выручку нам придут стандартные средства и консоль cmd ОС Windows.

Вы скажете, что есть бесплатные утилиты вроде TCPView от Марка Русиновича и Sysinternals, но сегодня не об этом. Только стандартные оснастки, только хардкор.

Подробнее

Настройка DHCP сервера для защиты от конфликта IP-адресов

Всем привет!

Сегодня я коротенько про одну недооцененную, но полезную функцию DHCP сервера расскажу…

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

Тут нужно сказать, что при использовании DHCP возможность конфликта IP-адресов достаточно мала, так как DHCP-сервер не может дважды выдать один и тот же адрес. Однако, в сети может оказаться устройство со статическим адресом, входящим в пул адресов DHCP-сервера. Именно поэтому для избежания конфликта DHCP-сервер перед выдачей адреса должен проверять, не используется ли уже этот адрес. И в ОС Windows Server есть такой механизм проверки.

Для включения проверки необходимо открыть оснастку управления DHCP, кликнуть правой клавишей по узлу IPv4 (или IPv6) и в открывшемся меню выбрать пункт «Свойства» (Properties — англ.).

DHCP Conflict detection attempts
На скриншоте: Настройка DHCP — Число попыток определения конфликтов установлено в значение 1.

Затем перейти на вкладку «Дополнительно» (Advanced  — англ.) и в поле «Число попыток определения конфликтов» (Conflict detection attempts — англ.) указать число от 1 до 5, которое означает, сколько раз требуется проверить IP-адрес на конфликт перед его выдачей (см. скриншот).

В настройках по умолчанию число попыток равно 0, что означает отсутствие проверки.

Запросить текущие настройки попыток определения конфликтов DHCP можно и с помощью PowerShell.

Посмотреть текущие настройки можно командой:

Get-DhcpServerSettings

Задать количество попыток проверки, скажем 3 раза, можно так:

Set-DhcpServerSettings -ConflictDetectionAttempts 3

На этом всё!

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

Как создать и раздать wi-fi c ноутбука или настольного компьютера. Полная пошаговая инструкция.

Всем привет!

Если вы попали на эту страницу, значит вам действительно нужно полное качественное руководство на тему как раздать wi-fi c ноутбука или настольного компьютера под управлением ОС Windows, конечно же, при условии, что на настольном компьютере установлен wi-fi адаптер.

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

Данное руководство актуально для операционных систем семейства Windows 10/8.1/8/7.

Приступим к делу, как всегда объясняю всё четко, по делу и с иллюстрациями.

 

Подробнее

RDP ошибка при проверке подлинности. Исправление шифрования CredSSP

После установки майских обновлений безопасности (от 8 мая 2018 г. на платформы  Windows 7/8/10 и серверные платформы на ОС Windows Server 2008 R2 / 2012 R2 / 2016) пользователи не получают доступ к удаленной машине посредством RDP и RemoteApp, и происходит следующая ошибка:

Подключение к удаленному рабочему столу Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Причиной ошибки может быть исправление шифрования CredSSP.
Скриншот: окно ошибки CredSSP после выполнения подключения RDP к серверу с клиентской машины.

В начале весны 2018 года Microsoft выпустила обновление, предотвращающее удалённое выполнение кода с помощью уязвимости в протоколе CredSSP, и в мае было выложено обновление после установки которого по умолчанию клиентским машинам запрещено подключение к удаленным RDP-серверам с уязвимой версией протокола CredSSP. Соответственно если на клиентах весенние обновления установлены, а на серверах с ОС Windows Server — не установлены, то мы получим ошибку при подключении:

«Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Причиной ошибки может быть исправление CredSSP.»

Или английский вариант:

 

«This could be due to CredSSP encryption oracle remediation.»

Ошибка клиента RDP появляется после установки обновлений безопасности:

  • Windows 7 / Windows Server 2008 R2 — обновление KB4103718
  • Windows 8.1 / Windows Server 2012 R2 — обновление KB4103725
  • Windows 10 1803 — обновление KB4103721
  • Windows 10 1709 — обновление KB4103727
  • Windows 10 1703 — обновление KB4103731
  • Windows 10 1609 — обновление KB4103723
  • Windows Server 2016 — обновление KB4103723

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

  1. Мы временно, на компьютере с которого подключаемся по RDP, уберем уведомление безопасности, которое блокирует подключение;
  2. Подключимся к нему по уже восстановленному RDP-подключению, и установим необходимый патч безопасности;
  3. Включим обратно уведомление безопасности которое временно отключали в первом пункте плана действий.

Поехали!

Подробнее