38 ответов в этой теме

[Konstantin Yudin]

все домены резолвятся на _94.76.205.132_

[Konstantin Yudin]

rusiem тоже резолвится в малварь

[Konstantin Yudin]

так что все тут по делу. лечите сеть

[Roman Rashevskiy]

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

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

 

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

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

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

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

[Konstantin Yudin]

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

[Konstantin Yudin]

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

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

[Roman Rashevskiy]

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

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

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

[Alexander Chinyakov]

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

[Konstantin Yudin]

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

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

[Roman Rashevskiy]

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

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

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

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

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

 

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

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

 

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

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

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

[N1ke]

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

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

[Roman Rashevskiy]

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

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

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

[Alexander Chinyakov]

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

 

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

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

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

 

 

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

 

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

[Roman Rashevskiy]

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

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, а это значит что соединение устанавливается не с вредоносным ресурсом, а значит блочить его не надо.

[Roman Rashevskiy]

 

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

 

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

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

 post-2419-0-19253700-1489037010_thumb.png   34,1К   3 Скачано раз

 

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

[Nenya Amo]

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

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

•  Безымянный2.png   3,09К   5 Скачано раз

[Alexander Chinyakov]

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

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

[Roman Rashevskiy]

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

[Roman Rashevskiy]

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

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

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

 

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

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