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

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

Другой вариант – воспользоваться протоколом IPSec. Если IPSec работает поверх Kerberos, то часть работы по аутентификации клиентов и серверов за вас уже проделана; есть уверенность, что любая система, соединившаяся с вашей, как минимум, находится в той же области Kerberos (в терминологии Windows, домене или лесу). IPSec на основе сертификатов тоже работает неплохо, хотя для корректного конфигурирования и эксплуатации инфраструктуры открытых ключей (PKI) потребуется приложить некоторые усилия. Недостатком всех решений на базе IPSec является то, что информация о структуре сети недоступна прикладному уровню, стало быть, ваше приложение отдано на милость сетевому администратору. Есть еще один способ: потребовать наличия IPSec–защищенного участка сети между вашей системой и DNS–сервером. Тогда, по крайней мере, есть гарантия, что вы общаетесь именно с вашим DNS–сервером, поэтому степень доверия к разрешению внутренних имен повышается. Обратите внимание: мы НЕ сказали, что проблема решена, она лишь несколько утратила остроту.

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

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

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