Есть ли способ предотвратить раскрытие getaddrinfo истинного IP-адреса имени хоста?

Допустим, есть программа, которая открывает файл HOSTS, чтобы убедиться, что он никуда не перенаправляется. (Он хочет подключиться к www.example.com, но гарантирует, что у вас нет для этого записи в файле HOSTS).

Поэтому вместо этого вы решаете добавить запись DNS, чтобы www.example.com действительно указывал на 123.123.1.123. Так что это работает.

Но затем программа становится умнее и вызывает getaddrinfo, чтобы определить, перенаправляется ли он на 123.123.1.123. Есть ли способ скрыть эту информацию или какие-либо альтернативные способы изменения IP-адреса данного имени хоста?

Есть ли способ заставить обычный IP-адрес www.example.com указывать на 123.123.1.123?

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

Или есть способ подделать пакеты, чтобы казалось, что они приходят с «www.example.com»? (Предположим, что у меня есть полный контроль над отправкой/получением пакетов программного обеспечения)


dns hosts getaddrinfo
person jcao219    schedule 22.04.2014    source источник
comment
Извините, я не понимаю. Вы хотите сказать, что добавили запись для www.example.com 123.123.1.123 в файл HOSTS, а программа вызывает getaddrinfo("www.example.com") и получает результат, отличный от 123.123.1.123? Или программа явно проверяет specific IP-адрес 123.123.1.123?   -  person Frank Schmitt    schedule 22.04.2014
comment
@Frank Извините, я должен был уточнить. Программа фактически открывает файл HOSTS и ищет в нем запись с www.example.com. Если находит, жалуется.   -  person jcao219    schedule 22.04.2014
comment
Как насчет настройки локального DNS-сервера, который разрешает www.example.com в 123.123.1.123 и перенаправляет все остальное на ваш настоящий DNS-сервер?   -  person Frank Schmitt    schedule 22.04.2014
comment
Однако getaddrinfo("www.example.com") обнаружит, что он разрешается в 123.123.1.123. Есть ли способ скрыть это?   -  person jcao219    schedule 22.04.2014
comment
Вы уверены, что это то, что происходит? Зачем кому-то использовать DNS в первую очередь, если они потом проверяют правильный IP-адрес? Кроме того, можно ли исправить DLL?   -  person dax    schedule 26.04.2014

Ответы (1)


arrow_upward
2
arrow_downward

getaddrinfo() ищет разрешения сетевых имен из разных источников. Давайте упростим и скажем, что сначала он просматривает файл HOSTS, а затем на DNS-сервере. Вот несколько способов, которыми вы можете попытаться обмануть свою умную программу, заставив ее думать, что «www.example.com» — это законный адрес 123.123.1.123 (с возрастающей сложностью):

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

  2. Использование локального DNS-сервера. В зависимости от того, насколько умной может быть ваша программа, это может быть нелегко сделать — в конце концов, мы говорим о спуфинге DNS. В простом случае вы можете просто настроить этот сервер как полномочный DNS-сервер для зоны «example.com», но если вы хотите быть действительно убедительным (и мы выходим за рамки getaddrinfo() здесь), вы также можете необходимо внести некоторые изменения в конфигурацию корневых серверов, просто чтобы избежать двойной проверки программы с каким-либо корневым сервером или сервером TLD "com" (я знаю, что всю эту настройку можно выполнить в привязке, я не знаю о других DNS-серверы). Даже в этом случае программа может утверждать, что не будет доверять локальному DNS-серверу. Даже если вы использовали не «127.0.0.1», а свой сетевой IP-адрес, он может обнаружить, что адрес DNS принадлежит локальному компьютеру. Итак, давайте немного продвинемся дальше.

  3. Использование удаленного DNS-сервера. Здесь мало что можно сказать. Все то же самое, что и раньше, только на внешнем компьютере. Если программа не хочет принимать DNS из вашей собственной сети или из любой частной сети (например, 192.168.1.X), возможно, вам придется разместить ее на общедоступном IP-адресе. В этот момент программа должна быть чрезвычайно скрупулезной, чтобы найти дыру в обмане. Но предположим, что это так, и предположим, что IP-адреса корневых DNS-серверов жестко закодированы, и он обнаружит, что все это время был заговор! Тогда еще один шаг.

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

    Верно?

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

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

person jdehesa    schedule 27.04.2014
comment
Если используется DNSSEC, следующим шагом будет использование QUANTUMINSERT. :-D Если доступ к целевому серверу осуществляется не через TLS, изменить трафик несложно. Если он использует TLS, то, если программа не использует закрепление сертификата, можно легко использовать скомпрометированный центр сертификации, чтобы позволить вам подделать сервер в любом случае. ;-) - person Chris Jester-Young; 27.04.2014
comment
@ChrisJester-Young Вы правы, я не знал об этом (на самом деле я не эксперт по безопасности). Мальчик, разве жизнь не проще в NSA/GCHQ. - person jdehesa; 27.04.2014