Chrome: DNS-запросы со случайными DNS-именами: вредоносная программа?

За эти годы (с 2005 года) я видел журналы странных случайных DNS-запросов на нескольких DNS / BIND-серверах, которые я обслуживал.

May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#24123 (verxkgiicjmcnxg): view internal: query: verxkgiicjmcnxg IN A + (1.1.1.1)
May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#29159 (epqoaqsayo): view internal: query: epqoaqsayo IN A + (1.1.1.1)
May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#27411 (qlllglwcjglu): view internal: query: qlllglwcjglu IN A + (1.1.1.1)

Я обычно связывал это с некоторыми вредоносными программами Windows. Тем не менее, я начал замечать, что это также исходит от клиентов Linux и Mac, в последнее время. Я снова подумал, что это может быть связано с некоторыми вредоносными подключаемыми модулями браузера.

Однако при отладке проблемы браузера Google Chrome в моем недавно установленном Macbook Pro / Chrome с использованием URL-адреса chrome: // net-internals / # dns я обнаружил похожие запросы на своей странице статистики Chrome DNS.

В моем браузере Chrome установлены довольно безобидные плагины и нет явных признаков вредоносного ПО .

У меня есть свои честные сомнения, должна ли это быть злонамеренная деятельность или нет. Что случилось?

(Как видно на рисунке, запросы DNS-имен pnxcygqqemww , ryzypwbheguutkd и snplueo, сделанные Chrome).

Отслеживание активности DNS при открытии браузера Chrome с помощью:

sudo tcpdump -n port 53

Я могу видеть следующие запросы DNS и снова случайные запросы в 10:20:34:

Открытие Chrome:

tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
10:20:27.119736 IP 1.1.1.2.12568 > 1.1.1.1.53: 10990+ A? apis.google.com. (33)
10:20:27.119962 IP 1.1.1.2.34930 > 1.1.1.1.53: 13828+ A? disconnect.me. (31)
10:20:27.120078 IP 1.1.1.2.17860 > 1.1.1.1.53: 37420+ A? mxr.mozilla.org. (33)
10:20:27.120314 IP 1.1.1.1.53 > 1.1.1.2.12568: 10990 2/4/4 CNAME plus.l.google.com., A 216.58.214.174 (206)
10:20:27.120479 IP 1.1.1.1.53 > 1.1.1.2.34930: 13828 3/4/8 A 54.197.255.152, A 54.225.94.202, A 204.236.239.134 (339)
10:20:27.120666 IP 1.1.1.1.53 > 1.1.1.2.17860: 37420 1/4/5 A 63.245.215.42 (234)
10:20:27.123394 IP 1.1.1.2.51642 > 1.1.1.1.53: 58375+ A? ssl.gstatic.com. (33)
10:20:27.123658 IP 1.1.1.2.17933 > 1.1.1.1.53: 48570+ A? www.google.pt. (31)
10:20:27.123726 IP 1.1.1.1.53 > 1.1.1.2.51642: 58375 1/4/4 A 216.58.214.163 (192)
10:20:27.123897 IP 1.1.1.2.57779 > 1.1.1.1.53: 7559+ A? www.gstatic.com. (33)
10:20:27.123946 IP 1.1.1.1.53 > 1.1.1.2.17933: 48570 1/4/4 A 216.58.207.163 (193)
10:20:27.124192 IP 1.1.1.1.53 > 1.1.1.2.57779: 7559 16/4/4 A 194.210.238.166, A 194.210.238.170, A 194.210.238.174, A 194.210.238.176, A 194.210.238.177, A 194.210.238.181, A 194.210.238.185, A 194.210.238.187, A 194.210.238.144, A 194.210.238.148, A 194.210.238.152, A 194.210.238.154, A 194.210.238.155, A 194.210.238.159, A 194.210.238.163, A 194.210.238.165 (432)
10:20:27.432926 IP 1.1.1.2.29865 > 1.1.1.1.53: 62300+ A? clients4.google.com. (37)
10:20:27.433219 IP 1.1.1.2.28193 > 1.1.1.1.53: 23734+ A? translate.googleapis.com. (42)
10:20:27.433703 IP 1.1.1.1.53 > 1.1.1.2.29865: 62300 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)
10:20:27.464772 IP 1.1.1.1.53 > 1.1.1.2.28193: 23734 1/4/4 A 216.58.198.202 (201)
10:20:28.430622 IP 1.1.1.2.46792 > 1.1.1.1.53: 1963+ A? accounts.google.com. (37)
10:20:28.431046 IP 1.1.1.1.53 > 1.1.1.2.46792: 1963 1/4/4 A 216.58.201.141 (189)
10:20:32.348765 IP 1.1.1.2.16654 > 1.1.1.1.53: 39847+ A? www.google.com. (32)
10:20:32.349362 IP 1.1.1.1.53 > 1.1.1.2.16654: 39847 1/4/4 A 216.58.213.164 (184)

Через пару секунд упомянутые случайные DNS-запросы действительно появляются:

10:20:34.159229 IP 1.1.1.2.5042 > 1.1.1.1.53: 47676+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.159829 IP 1.1.1.2.63360 > 1.1.1.1.53: 55094+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.159893 IP 1.1.1.1.53 > 1.1.1.2.5042: 47676 NXDomain* 0/1/0 (104)
10:20:34.160230 IP 1.1.1.1.53 > 1.1.1.2.63360: 55094 NXDomain* 0/1/0 (104)
10:20:34.160872 IP 1.1.1.2.29339 > 1.1.1.1.53: 22434+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.161290 IP 1.1.1.1.53 > 1.1.1.2.29339: 22434 NXDomain* 0/1/0 (111)
10:20:34.162489 IP 1.1.1.2.64592 > 1.1.1.1.53: 49055+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.162859 IP 1.1.1.1.53 > 1.1.1.2.64592: 49055 NXDomain* 0/1/0 (104)
10:20:34.164105 IP 1.1.1.2.50225 > 1.1.1.1.53: 1276+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.164386 IP 1.1.1.2.52389 > 1.1.1.1.53: 59022+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.164472 IP 1.1.1.1.53 > 1.1.1.2.50225: 1276 NXDomain* 0/1/0 (104)
10:20:34.164751 IP 1.1.1.1.53 > 1.1.1.2.52389: 59022 NXDomain* 0/1/0 (111)

Открытие новой вкладки в Chrome:

10:20:44.106915 IP 1.1.1.2.26171 > 1.1.1.1.53: 14460+ A? clients2.google.com. (37)
10:20:44.139387 IP 1.1.1.1.53 > 1.1.1.2.26171: 14460 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)

Также, согласно ссылке @Gilles, при использовании прокси (Squid) в Chrome вы можете увидеть случайные DNS-имена в соответствующем access.logфайле журнала Squid , когда Chrome загружается:

1494276554.709    216 127.0.0.1 TCP_MISS/504 277 HEAD http://vgifrooogs/ - DIRECT/vgifrooogs text/html
1494276554.731    238 127.0.0.1 TCP_MISS/504 277 HEAD http://cbwknhka/ - DIRECT/cbwknhka text/html  
1494276554.875    382 127.0.0.1 TCP_MISS/504 277 HEAD http://vtjhiag/ - DIRECT/vtjhiag text/html

Я нашел серию сообщений / сообщений об ошибках о случайных DNS-запросах, сделанных Chrome. Вывод таков: случайные DNS-запросы не генерируются ни вредоносными программами, ни плагинами или надстройками.

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

Лучшее объяснение, которое я нашел, приведено ниже по этой ссылке .

Если вы вводите поисковый запрос, состоящий из одного слова, chrome необходимо отправить DNS-запрос, чтобы проверить, может ли это быть имя хоста, состоящее из одного слова: например, «test» может быть поиском «test» или переходом к http: // test ". Если запрос оказывается хостом, Chrome отображает информационную панель, которая спрашивает: «Вы вместо этого хотели перейти к« тестированию »». По соображениям производительности DNS-запрос должен быть асинхронным.

Теперь некоторые интернет-провайдеры начали показывать объявления для несуществующих доменных имен ( http://en.wikipedia.org/wiki/DNS_hijacking ), что означает, что Chrome всегда будет отображать эту информационную панель для каждого запроса из одного слова. Поскольку это раздражает, chrome теперь отправляет три случайных DNS-запроса при запуске, и, если они все разрешаются (на один и тот же IP, я думаю), теперь он знает, что не нужно отображать информационную панель «Вы имели в виду» для запросов из одного слова, которые разрешают на этот IP.

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

Вот еще одна ссылка, связанная с темой из @Gilles: Необычные запросы HEAD на бессмысленные URL-адреса из Chrome . Отсюда добавление к вопросу темы настройки прокси-теста. В конечном итоге вы видите журналы прокси, потому что, когда прокси настроен, запросы выполняются через прокси; и это до прокси для разрешения запросов DNS.

Не имея более подробной информации в Интернете, я скачал и просмотрел исходный код Chromium с помощью команды ниже.

git clone https://chromium.googlesource.com/chromium/src 

Приведенная ниже цитата была скопирована из комментариев исходного кода Chromium:

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

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

Триггер: «При запуске и при изменении IP-адреса компьютера».

Мы генерируем случайное имя хоста длиной от 7 до 15 символов.

Мой вывод заключается в том, что эти случайные имена DNS-запросов не являются проявлением вредоносного поведения ; они являются зондами для Chromium (и Google Chrome), чтобы узнать, что он может делать, по крайней мере, в поиске .

Не имея более подробных сведений в Интернете, я загрузил источники Chromium в своем расследовании. Логика работы с этой функциональностью может быть найдена в файле, src/chrome/browser/intranet_redirect_detector.ccи src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Ниже приводится выдержка из src/chrome/browser/intranet_redirect_detector.cc:

void IntranetRedirectDetector::FinishSleep() {
  in_sleep_ = false;

  // If another fetch operation is still running, cancel it.
  fetchers_.clear();
  resulting_origins_.clear();

  const base::CommandLine* cmd_line = base::CommandLine::ForCurrentProcess();
  if (cmd_line->HasSwitch(switches::kDisableBackgroundNetworking))
    return;

  DCHECK(fetchers_.empty() && resulting_origins_.empty());

  // Create traffic annotation tag.
  net::NetworkTrafficAnnotationTag traffic_annotation =
      net::DefineNetworkTrafficAnnotation("intranet_redirect_detector", R"(
        semantics {
          sender: "Intranet Redirect Detector"
          description:
            "This component sends requests to three randomly generated, and "
            "thus likely nonexistent, hostnames.  If at least two redirect to "
            "the same hostname, this suggests the ISP is hijacking NXDOMAIN, "
            "and the omnibox should treat similar redirected navigations as "
            "'failed' when deciding whether to prompt the user with a 'did you "
            "mean to navigate' infobar for certain search inputs."
          trigger: "On startup and when IP address of the computer changes."
          data: "None, this is just an empty request."
          destination: OTHER
        }
        policy {
          cookies_allowed: false
          setting: "This feature cannot be disabled by settings."
          policy_exception_justification:
              "Not implemented, considered not useful."
        })");

  // Start three fetchers on random hostnames.
  for (size_t i = 0; i < 3; ++i) {
    std::string url_string("http://");
    // We generate a random hostname with between 7 and 15 characters.
    const int num_chars = base::RandInt(7, 15);
    for (int j = 0; j < num_chars; ++j)
      url_string += ('a' + base::RandInt(0, 'z' - 'a'));
    GURL random_url(url_string + '/');
    std::unique_ptr<net::URLFetcher> fetcher = net::URLFetcher::Create(
        random_url, net::URLFetcher::HEAD, this, traffic_annotation);
    // We don't want these fetches to affect existing state in the profile.
    fetcher->SetLoadFlags(net::LOAD_DISABLE_CACHE |
                          net::LOAD_DO_NOT_SAVE_COOKIES |
                          net::LOAD_DO_NOT_SEND_COOKIES |
                          net::LOAD_DO_NOT_SEND_AUTH_DATA);
    fetcher->SetRequestContext(g_browser_process->system_request_context());
    fetcher->Start();
    net::URLFetcher* fetcher_ptr = fetcher.get();
    fetchers_[fetcher_ptr] = std::move(fetcher);
  }
}

void IntranetRedirectDetector::OnURLFetchComplete(
    const net::URLFetcher* source) {
  // Delete the fetcher on this function's exit.
  auto it = fetchers_.find(const_cast<net::URLFetcher*>(source));
  DCHECK(it != fetchers_.end());
  std::unique_ptr<net::URLFetcher> fetcher = std::move(it->second);
  fetchers_.erase(it);

  // If any two fetches result in the same domain/host, we set the redirect
  // origin to that; otherwise we set it to nothing.
  if (!source->GetStatus().is_success() || (source->GetResponseCode() != 200)) {
    if ((resulting_origins_.empty()) ||
        ((resulting_origins_.size() == 1) &&
         resulting_origins_.front().is_valid())) {
      resulting_origins_.push_back(GURL());
      return;
    }
    redirect_origin_ = GURL();
  } 

....

Ниже приведена выдержка из файла src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc:

// Returns true if |final_url| doesn't represent an ISP hijack of
// |original_url|, based on the IntranetRedirectDetector's RedirectOrigin().
bool IsValidNavigation(const GURL& original_url, const GURL& final_url) {

....

void ChromeOmniboxNavigationObserver::NavigationEntryCommitted(
    const content::LoadCommittedDetails& load_details) {
  load_state_ = LOAD_COMMITTED;
  if (ResponseCodeIndicatesSuccess(load_details.http_status_code) &&
      IsValidNavigation(match_.destination_url,
                        load_details.entry->GetVirtualURL()))
    OnSuccessfulNavigation();
  if (!fetcher_ || (fetch_state_ != FETCH_NOT_COMPLETE))
    OnAllLoadingFinished();  // deletes |this|!
}

...

void ChromeOmniboxNavigationObserver::OnURLFetchComplete(
    const net::URLFetcher* source) {
  DCHECK_EQ(fetcher_.get(), source);
  const net::URLRequestStatus& status = source->GetStatus();
  int response_code = source->GetResponseCode();
  fetch_state_ =
      (status.is_success() && ResponseCodeIndicatesSuccess(response_code)) ||
              ((status.status() == net::URLRequestStatus::CANCELED) &&
               ((response_code / 100) == 3) &&
               IsValidNavigation(alternate_nav_match_.destination_url,
                                 source->GetURL()))
          ? FETCH_SUCCEEDED
          : FETCH_FAILED;
  if (load_state_ == LOAD_COMMITTED)
    OnAllLoadingFinished();  // deletes |this|!
}

Ссылка по теме: DNS-запросы в смешанном регистре - Вредоносные программы в моей сети? ,

Немного связано: почему Chromium не кэширует DNS более минуты?