Перейти к содержимому


Фото
- - - - -

Dr.Web Security Space 11 блокирует HTTPS-сайт во внутренней сети

https dr.web ss 11 ERR_SSL_PROTOCOL_ERROR SSL_ERROR_ACCESS_DENIED_ALERT AD-Cloud

  • Please log in to reply
38 ответов в этой теме

#21 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 15:21

все домены резолвятся на _94.76.205.132_
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#22 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 15:23

rusiem тоже резолвится в малварь
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#23 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 15:26

так что все тут по делу. лечите сеть
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#24 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 15:45

Мда... Сказать что я сейчас с Вас в шоке - это ничего не сказать... "Лечите сеть", "rusiem резолвится в малварь", "все тут по делу" - извините, но это пздц.

Начнем с того, что все эти домены, которые Вы выдернули из моего лога (который я кстати Вам в личку отправил, и наверное сделал это не просто так), у всех резолвятся по-разному (отдельно отмечу что Вы резолвили эти имена в публичном сегменте Интернета), у меня сейчас из рабочей сети в _72.52.4.90_ (и там кстати никаким SSL и не пахнет), но не в этом суть.

 

Раз уж Вы решили все вывалить тут публично, то отвечу Вам тоже публично:

Есть такой продукт RuSIEM (rusiem.com) - как понятно из названия это SIEM-система, она развернута в нашей внутренней сети (IP-адрес в присланных логах видно), и так уже совпало что хостнейм (а не доменное имя, которое резолвится в DNS!) у этой системы "rusiem". Два дня после развертывания системы я не мог к ней подключиться, а виновником проблемы, как выяснилось, был именно Dr.Web Security Space, установленный на моем ноутбуке.

А теперь давайте подумаем вместе - причем тут все, что Вы написали?


Сообщение было изменено Roman Rashevskiy: 09 Март 2017 - 15:48

Best regards,
Roman Rashevskiy

#25 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 16:12

ничего приватного я не показал. я уважаю чужие данные. ваши домены резолвятся в ip интернетовский, который мы баним как малварный. значит проблема в dns.
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#26 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 16:16

>(отдельно отмечу что Вы резолвили эти имена в публичном сегменте Интернета)

мы ничего не реолвили. в этом нет смысла вне вашей сети. но в ваших логах видно куда резолвятся все эти домены, в малварный ip. без облака такой же детект. может это сама siem система балуется, или кто то пентестингом балуется в сети. это вам уже узнавать что с dns
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#27 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 16:16

Константин, еще раз - причем тут домены?!

Вы говорите про ДОМЕНЫ, а причина блокировки в данном случае (как я понял из обсуждения выше) - не домен (тем более что на SIEM я хожу по IP-адресу, а не доменному имени), а ХОСТНЕЙМ, указанный в SSL-сертификате, понимаете?


Сообщение было изменено Roman Rashevskiy: 09 Март 2017 - 16:19

Best regards,
Roman Rashevskiy

#28 Alexander Chinyakov

Alexander Chinyakov

    Member

  • Dr.Web Staff
  • 488 Сообщений:

Отправлено 09 Март 2017 - 16:22

Сделайте nslookup этих хостнеймов на ваших машинах и посмотрите, что там будет.



#29 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 18 000 Сообщений:

Отправлено 09 Март 2017 - 16:48

Константин, еще раз - причем тут домены?!
Вы говорите про ДОМЕНЫ, а причина блокировки в данном случае (как я понял из обсуждения выше) - не домен (тем более что на SIEM я хожу по IP-адресу, а не доменному имени), а ХОСТНЕЙМ, указанный в SSL-сертификате, понимаете?

хостнейм резолвится и полученный ip так же проверяется на детект
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#30 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 17:07

хостнейм резолвится и полученный ip так же проверяется на детект

Вот в этом и есть суть проблемы.

С такой логикой работы поспорить сложно (тут я говорю абсолютно серьезно), но смотрите как получается в моем случае - хостнейм, указанный в SSL-сертификате является вредоносным с точки зрения Dr.Web (и оно в принципе верно, если резолвить это имя через DNS), НО:

- хостнейм в сертификате не совпадает с доменным именем ресурса к которому идет запрос;

- зарезолвенный IP-адрес хостнейма не совпадает с IP-адресом ресурса к которому идет запрос.

 

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

ИМХО, но блочить (да еще блочить без какого-либо уведомления пользователя) ресурс ТОЛЬКО по хостнейму из SSL-сертификата - не совсем корректно.

 

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

1. Добавить проверки (хостнейм в сертификате VS реальный хостнейм, к которому идет обращение) и (IP-адрес зарезловленный из хостнейма VS IP-адрес, к которому идет обращение);

2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).


Best regards,
Roman Rashevskiy

#31 N1ke

N1ke

    Member

  • Posters
  • 374 Сообщений:

Отправлено 09 Март 2017 - 17:34

Вроде выше разработчик явно указал, что бан не по хостнейму, а по IP адресу в который он резолвится. Как я понял, мысль про странный хостнейм пришла из беглого взгляда на логи. После просьбы убрать ложняк уже посмотрели, во что это всё резолвится и выяснилось, что лочится правильно из-за адреса, в который всё резолвится.


Сообщение было изменено N1ke: 09 Март 2017 - 17:36


#32 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 17:40

N1ke, проблема в следующем:

Хостнейм "rusiem", указанный в SSL-сертификате резолвится в IP-адрес 72.52.4.90, а этот IP-адрес является вредоносным (насчет его вредоносности я не спорю), НО я работаю с ресурсом с IP-адресом 10.x.x.x, на котором установлен самоподписанный SSL-сертификат (а в этом самоподписанном сертификате указан хостнейм "rusiem"), но это не значит что ресурс с которым я работаю является вредоносным.

Я говорю о том, что логика работы с SSL-сертификатами (когда проверяется только хостнейм, с помощью резолва, без привязки к тому куда реально идет запрос) некорректна.


Best regards,
Roman Rashevskiy

#33 Alexander Chinyakov

Alexander Chinyakov

    Member

  • Dr.Web Staff
  • 488 Сообщений:

Отправлено 09 Март 2017 - 17:42

1. Добавить проверки (хостнейм в сертификате VS реальный хостнейм, к которому идет обращение) и (IP-адрес зарезловленный из хостнейма VS IP-адрес, к которому идет обращение);

 

При выключенной проверке защищенных соединений мы можем проверить только следующее:

  1. Хостнеймы из SNI и из сертификата, предоставленного сервером.
  2. IP-адреса из локального резолва хостнеймов из п.1.
  3. IP-адрес, с которым устанавливается соединение.

На основании этой информации и принимается решение о блокировке.

 

 

2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).

 

Включите показ уведомлений о блокировке ссылок компонентом SpIDer Gate.



#34 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 17:49

При выключенной проверке защищенных соединений мы можем проверить только следующее:

  1. Хостнеймы из SNI и из сертификата, предоставленного сервером.
  2. IP-адреса из локального резолва хостнеймов из п.1.
  3. IP-адрес, с которым устанавливается соединение.

На основании этой информации и принимается решение о блокировке.

Смотрите, что можно получить используя эту информацию в моем случае (т.к. я обращаюсь к ресурсу напрямую по IP-адресу, то SNI из п.1 не используется):

1. Получаем из SSL-сертификата хостнейм "rusiem";

2. Резолвим локально хостнейм из п.1 получаем IP-адрес 72.52.4.90;

3. Смотрим на IP-адрес с которым устанавливается соединение и получаем 10.x.x.x.

Отсюда получаем, что 72.52.4.90 != 10.x.x.x, а это значит что соединение устанавливается не с вредоносным ресурсом, а значит блочить его не надо.


Best regards,
Roman Rashevskiy

#35 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 17:51

 

2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).

 

Включите показ уведомлений о блокировке ссылок компонентом SpIDer Gate.

Вот мои настройки уведомлений:

Прикрепленный файл  post-2419-0-19253700-1489037010_thumb.png   34,1К   1 Скачано раз

 

ЧЯДНТ? ОС - Windows 10 Pro.


Best regards,
Roman Rashevskiy

#36 Nenya Amo

Nenya Amo

    Advanced Member

  • Posters
  • 732 Сообщений:

Отправлено 09 Март 2017 - 17:55

Я таки понимаю это:

Прикрепленные файлы:


мой девиз - служение злу, как у котика..


#37 Alexander Chinyakov

Alexander Chinyakov

    Member

  • Dr.Web Staff
  • 488 Сообщений:

Отправлено 09 Март 2017 - 17:58

3. Смотрим на IP-адрес с которым устанавливается соединение и получаем 10.x.x.x.
Отсюда получаем, что 72.52.4.90 != 10.x.x.x, а это значит что соединение устанавливается не с вредоносным ресурсом, а значит блочить его не надо.

Нет гарантии, что по адресу 10.x.x.x не находится прокси-сервер, перенаправляющий запрос на 72.52.4.90.



#38 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 18:00

Nenya Amo, слона-то я и не заметил, спасибо.


Best regards,
Roman Rashevskiy

#39 Roman Rashevskiy

Roman Rashevskiy

    Member

  • Posters
  • 482 Сообщений:

Отправлено 09 Март 2017 - 18:07

Alexander Chinyakov, тоже верно, но даже если там будет прокси:

- все, что упадет на диск будет просканировано SpIDer Guard'ом;

- все, что может  работать из браузера может быть заблокировано ProccesHeuristic'ом, ShellGuard'ом, etc. (это конечно не панацея, но блокировка по хостнейму тоже не есть гуд)

 

С учетом того, что балуны для SpIDer Gate все-таки есть - и так сойдет. Правда их бы еще не прятать в раздел "Малозначительные уведомления" :)


Сообщение было изменено Roman Rashevskiy: 09 Март 2017 - 18:07

Best regards,
Roman Rashevskiy



Also tagged with one or more of these keywords: https, dr.web ss 11, ERR_SSL_PROTOCOL_ERROR, SSL_ERROR_ACCESS_DENIED_ALERT, AD-Cloud

Читают тему: 1

0 пользователей, 1 гостей, 0 скрытых