Dr.Web Security Space 11 блокирует HTTPS-сайт во внутренней сети
#21
Отправлено 09 Март 2017 - 15:21
Doctor Web, Ltd.
#22
Отправлено 09 Март 2017 - 15:23
Doctor Web, Ltd.
#23
Отправлено 09 Март 2017 - 15:26
Doctor Web, Ltd.
#24
Отправлено 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
Roman Rashevskiy
#25
Отправлено 09 Март 2017 - 16:12
Doctor Web, Ltd.
#26
Отправлено 09 Март 2017 - 16:16
мы ничего не реолвили. в этом нет смысла вне вашей сети. но в ваших логах видно куда резолвятся все эти домены, в малварный ip. без облака такой же детект. может это сама siem система балуется, или кто то пентестингом балуется в сети. это вам уже узнавать что с dns
Doctor Web, Ltd.
#27
Отправлено 09 Март 2017 - 16:16
Константин, еще раз - причем тут домены?!
Вы говорите про ДОМЕНЫ, а причина блокировки в данном случае (как я понял из обсуждения выше) - не домен (тем более что на SIEM я хожу по IP-адресу, а не доменному имени), а ХОСТНЕЙМ, указанный в SSL-сертификате, понимаете?
Сообщение было изменено Roman Rashevskiy: 09 Март 2017 - 16:19
Roman Rashevskiy
#28
Отправлено 09 Март 2017 - 16:22
Сделайте nslookup этих хостнеймов на ваших машинах и посмотрите, что там будет.
#29
Отправлено 09 Март 2017 - 16:48
хостнейм резолвится и полученный ip так же проверяется на детектКонстантин, еще раз - причем тут домены?!
Вы говорите про ДОМЕНЫ, а причина блокировки в данном случае (как я понял из обсуждения выше) - не домен (тем более что на SIEM я хожу по IP-адресу, а не доменному имени), а ХОСТНЕЙМ, указанный в SSL-сертификате, понимаете?
Doctor Web, Ltd.
#30
Отправлено 09 Март 2017 - 17:07
хостнейм резолвится и полученный ip так же проверяется на детект
Вот в этом и есть суть проблемы.
С такой логикой работы поспорить сложно (тут я говорю абсолютно серьезно), но смотрите как получается в моем случае - хостнейм, указанный в SSL-сертификате является вредоносным с точки зрения Dr.Web (и оно в принципе верно, если резолвить это имя через DNS), НО:
- хостнейм в сертификате не совпадает с доменным именем ресурса к которому идет запрос;
- зарезолвенный IP-адрес хостнейма не совпадает с IP-адресом ресурса к которому идет запрос.
Очевидно, что в самоподписанном сертификате SIEM-системы (который используется исключительно для того зашифровать данные передаваемые в сессии между клиентом и сервером, а не для подтверждения валидности ресурса) может быть указан любой хостнейм.
ИМХО, но блочить (да еще блочить без какого-либо уведомления пользователя) ресурс ТОЛЬКО по хостнейму из SSL-сертификата - не совсем корректно.
С причиной возникновения проблемы разобрались и чтобы сохранить конструктивное обсуждение в данной теме хотел бы высказать свои фичреквесты (естественно, я ни на что не претендую, просто высказываю свое видение):
1. Добавить проверки (хостнейм в сертификате VS реальный хостнейм, к которому идет обращение) и (IP-адрес зарезловленный из хостнейма VS IP-адрес, к которому идет обращение);
2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).
Roman Rashevskiy
#31
Отправлено 09 Март 2017 - 17:34
Вроде выше разработчик явно указал, что бан не по хостнейму, а по IP адресу в который он резолвится. Как я понял, мысль про странный хостнейм пришла из беглого взгляда на логи. После просьбы убрать ложняк уже посмотрели, во что это всё резолвится и выяснилось, что лочится правильно из-за адреса, в который всё резолвится.
Сообщение было изменено N1ke: 09 Март 2017 - 17:36
#32
Отправлено 09 Март 2017 - 17:40
N1ke, проблема в следующем:
Хостнейм "rusiem", указанный в SSL-сертификате резолвится в IP-адрес 72.52.4.90, а этот IP-адрес является вредоносным (насчет его вредоносности я не спорю), НО я работаю с ресурсом с IP-адресом 10.x.x.x, на котором установлен самоподписанный SSL-сертификат (а в этом самоподписанном сертификате указан хостнейм "rusiem"), но это не значит что ресурс с которым я работаю является вредоносным.
Я говорю о том, что логика работы с SSL-сертификатами (когда проверяется только хостнейм, с помощью резолва, без привязки к тому куда реально идет запрос) некорректна.
Roman Rashevskiy
#33
Отправлено 09 Март 2017 - 17:42
1. Добавить проверки (хостнейм в сертификате VS реальный хостнейм, к которому идет обращение) и (IP-адрес зарезловленный из хостнейма VS IP-адрес, к которому идет обращение);
При выключенной проверке защищенных соединений мы можем проверить только следующее:
- Хостнеймы из SNI и из сертификата, предоставленного сервером.
- IP-адреса из локального резолва хостнеймов из п.1.
- IP-адрес, с которым устанавливается соединение.
На основании этой информации и принимается решение о блокировке.
2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).
Включите показ уведомлений о блокировке ссылок компонентом SpIDer Gate.
#34
Отправлено 09 Март 2017 - 17:49
При выключенной проверке защищенных соединений мы можем проверить только следующее:
- Хостнеймы из SNI и из сертификата, предоставленного сервером.
- IP-адреса из локального резолва хостнеймов из п.1.
- 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, а это значит что соединение устанавливается не с вредоносным ресурсом, а значит блочить его не надо.
Roman Rashevskiy
#35
Отправлено 09 Март 2017 - 17:51
2. Прикрутить нотификацию (например, в виде балуна) при блокировках ресурсов по протоколу HTTPS при отключенной проверке SSL (т.е. при отсутствии возможности показать уведомление прямо в браузере).
Включите показ уведомлений о блокировке ссылок компонентом SpIDer Gate.
Вот мои настройки уведомлений:
post-2419-0-19253700-1489037010_thumb.png 34,1К 3 Скачано раз
ЧЯДНТ? ОС - Windows 10 Pro.
Roman Rashevskiy
#36
Отправлено 09 Март 2017 - 17:55
Я таки понимаю это:
Прикрепленные файлы:
мой девиз - служение злу, как у котика..
#37
Отправлено 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
Отправлено 09 Март 2017 - 18:00
Nenya Amo, слона-то я и не заметил, спасибо.
Roman Rashevskiy
#39
Отправлено 09 Март 2017 - 18:07
Alexander Chinyakov, тоже верно, но даже если там будет прокси:
- все, что упадет на диск будет просканировано SpIDer Guard'ом;
- все, что может работать из браузера может быть заблокировано ProccesHeuristic'ом, ShellGuard'ом, etc. (это конечно не панацея, но блокировка по хостнейму тоже не есть гуд)
С учетом того, что балуны для SpIDer Gate все-таки есть - и так сойдет. Правда их бы еще не прятать в раздел "Малозначительные уведомления"
Сообщение было изменено Roman Rashevskiy: 09 Март 2017 - 18:07
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
Русские форумы →
Общие вопросы →
Dr. Web и VirusTotalАвтор: AT2000 , 12 фев 2022 url, web, Link Checher, https и еще 3… |
|
|
||
Русские форумы →
Dr.Web для Windows →
Рабочие станции →
Dr. Web Link Checker pluginАвтор: AT2000 , 24 янв 2022 Link Checker, plugin, web, http и еще 2… |
|
|
||
Русские форумы →
Антивирусная лаборатория →
Помощь по лечению →
сайт и обновления в украины недоступныАвтор: lz4 , 01 янв 2021 https, Unable to connect |
|
|
||
Русские форумы →
Dr.Web для Windows →
Рабочие станции →
ошибка SSL_ERROR_ACCESS_DENIED_ALERTАвтор: riskk , 27 ноя 2018 SSL_ERROR_ACCESS_DENIED_ALERT |
|
|
||
Русские форумы →
Dr.Web Enterprise Suite →
Блокировка HTTPS-траффика субдоменов через DrWeb ES 10Автор: repsac1987 , 17 сен 2018 https, teamviewer |
|
|
Читают тему: 1
0 пользователей, 1 гостей, 0 скрытых