Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 След.
RSS
Перекуем мечи на орала!
 
Обсуждение статьи Перекуем мечи на орала!
 
Если я правильно понял, речь идет о подмене серитификата сервера (с которым
клиент соединяется через CF), на сертификат, который выдается тем же СА
который выдал сертификат серверу (с которым соединяется клиент), причем
выдается "на имя" того же сервера. В реальной ситуации это малореально исходя
хотя бы из того что серьезные СА так просто сертификат никому не выдадут.
Потому что теряется сама суть PKI, которая заключается не только в
централизованном распространении и хранении   сертификатов, но и в том что к выданному данным
центром сертификату может оказываться ДОВЕРИЕ. Грубо говоря, если данный ключ
подписан на ключе некоего СА то этому ключу (сертфикату)  можно доверять,
потому что это не вася пупкин сам подписал, а подписал уважаемый СА. А тут
какой нафиг уважаемый СА если он автоматом всем направо и налево ключи
раздает.
 
Я понял статью несколько иначе. Как можно осуществлять мониторинг сетевой активности с помощью IDS, если трафик зашифрован? Автор(ы) предлага[ет|ют] пусть не оригинальное, но всё же решение проблемы, пусть лишь теоретически, но и в этом случае большой им респект. Буду рад видеть продолжение темы.
 
Цитата
tokza пишет:
Если я правильно понял, речь идет о подмене серитификата сервера

Именно так. Только сертификат выдает не тот же CA, который выдал изначальный сертификат для Web сервера, а наш, корпоративный. Ему наши пользователи так же доверяют (это несложно сделать, особенно в среде AD).
Раздает он ключи не направо-налево, а только для нашего прокси. Кроме того, я предлагаю использовать не корневой, а подчиненный CA, что бы в случае ахтунга (компрометации закрытого ключа) его было просто засунуть в CRL.
Коммерческий (серьезный) CA можно использовать для получения сертификата корневого (ROOT-CA в тексте). И он выдаст только один сертификат, для CF-CA, который и будет заниматся выдачей промежуточных сертификатов.
 
Принцип был и остается прежним - для анализа содержимого его необходимо расшифровать, т.е. нарушить конфиденциальность. Причем это не зависит от технической реализации конфиденциальности. Разве только оставлять незашифрованной информацию для самих сетевых анализаторов (чтобы не лезли куда не надо), но, IMHO, до сих пор это технически не реализовано.

Что ж, будем ждать.
 
Могу назвать систему обнаружения атак, которая работает с зашифрованным трафиком SSL - RealSecure Server от Internet Security Systems.

Что касается проблемы с шифрованием, то она решается 2-мя путями:
 1. установкой CF, IDS, AV и т.п. на конечных узлах. в этом случае проверка данных будет осуществляться до их зашифрования.
 2. оргмеры, когда передача зашифрованного трафика просто запрещается.
Luka
 
"Вуаля, имея секретный сессионный ключ, мы спокойно расшифровываем и анализируем содержимое клиентской сессии, клиентам не выдаются страшные предупреждения, данные передаются по сети в зашифрованном виде, и все счастливы! "

Бред, секрет раскрывается только тогда, когда объединяются открытый и секретный ключ, принадлежащие разным людеям.
 
Хотя все-таки внесу ясность, атака "человек посередине" будет удачная только если использовался анонимный алогоритм Диффи-Хеллмана (алгоритм распределения временных ключей). Но по спецификации это настоятельно не рекомендуется.
 
Что касается "Могу назвать систему обнаружения атак, которая работает с зашифрованным трафиком SSL - RealSecure Server от Internet Security Systems.
", то вот что написано в документации к данному продукту: Event detection at the
application layer: The server sensor can monitor traffic that is encrypted with software, such as SSL,
IPSEC, or SKIP, because the traffic is not encrypted above the stack.
Но это тоже бред чистейшей воды, то что трафик не шифруется на прикладном уровне, при использовании этих алгоритмов, вовсе не означает что трафик прикладного уровня передается в открытом виде. Учите мат.часть стека TCP/IP.
 
Все описано классно, за исключением двух мелочей:
- В нормально развернутой PKI просто так доп. сертификат  не получишь, будь ты хоть трижды админ. Ибо софт/железо CA управляются специально обученными людьми из СБ, а не из асуизации.
- Вменяемый юзер всегда может ткнуть на свойства соединения и посмотреть на сертификат. Я бы очень удивился, если бы увидел, что сертификат удаленного узла во Франции выпущен нашим корпоративным CA. И пошел бы отрывать йенг админу ;)
 
Цитата
Гость пишет:
Вот что написано в документации к данному продукту: Event detection at the
application layer: The server sensor can monitor traffic that is encrypted with software, such as SSL,
IPSEC, or SKIP, because the traffic is not encrypted above the stack.
Но это тоже бред чистейшей воды, то что трафик не шифруется на прикладном уровне, при использовании этих алгоритмов, вовсе не означает что трафик прикладного уровня передается в открытом виде. Учите мат.часть стека TCP/IP.

Имеется ввиду то, что канальное шифрование, являющееся преградой для сетевых IDS, уже не является преградой для host-based IDS, которые имеют дело с расшифрованным трафиком. Разумеется, существуют некоторые ограничения и в параноидальных случаях к трафику доступа не будет, но так ли часто это применяется?
Luka
 
Цитата
Cybervlad пишет:
Все описано классно
Согласен, хотя воды ака лиричиских отступлений на мой вкус многовато.

Цитата
Cybervlad пишет:

- В нормально развернутой PKI просто так доп. сертификат  не получишь, будь ты хоть трижды админ. Ибо софт/железо CA управляются специально обученными людьми из СБ, а не из асуизации.
Ну так и за активностью тоже следит СБ, так что одна половина СБ вполне может получить сертификат у другой половины. Для уменьшения "нагрузки на ключ" - пусть выдачей временных (на 1 день, нам для сессии больше не надо :) ) сертификатов занимается отдельный СА

Цитата
Cybervlad пишет:

- Вменяемый юзер всегда может ткнуть на свойства соединения и посмотреть на сертификат.
Это в експлорере/мозиле, а в большом количестве приблуд "для SSLизации" данный сервис не предоставляется.

Цитата
Cybervlad пишет:

Я бы очень удивился, если бы увидел, что сертификат удаленного узла во Франции выпущен нашим корпоративным CA. И пошел бы отрывать йенг админу ;)
Если не противоречит текущей политике безопасности - perce no?
 
2 Luka:
Я-я, серверный сенсор! Каждому пользователю по IDS на машину и пускай она проксирует этот трафик системе фильтрации контента? Или каждая машина будет сама свой SSL трафик контролировать? А пользователь берет - и сносит этот серверный сенсор с своей машины, что бы не тормозил.
 
>софт/железо CA управляются специально обученными >людьми из СБ, а не из асуизации.

Согласен.
Но если сами люди из СБ оч. хотять ццл трафик
просматривать?


>- Вменяемый юзер всегда может ткнуть на свойства >соединения и посмотреть на сертификат.

Может. Но перед этим вообще-то он должен подписать бамашку, где написано что он в трезвом уме и здравой памяти согласен с тем что его рабочий траффик ему не пренадлежит [IMG]http://www.securitylab.ru/forum/smileys/smiley2.gif[/IMG]
 
Цитата
asu4ka пишет:
2 Luka:
Я-я, серверный сенсор! Каждому пользователю по IDS на машину и пускай она проксирует этот трафик системе фильтрации контента? Или каждая машина будет сама свой SSL трафик контролировать? А пользователь берет - и сносит этот серверный сенсор с своей машины, что бы не тормозил.
Подобные средства, как правило, инсталлируют на те станции, где есть необходимость в контекстном анализе трафика. Обычно в этой роли выступают сервера.
Можно инсталлировать и на рабочие станции, проблему деинсталляции продукта решается другими уровнями.
 
Цитата
asu4ka пишет:
2 Luka:
Я-я, серверный сенсор! Каждому пользователю по IDS на машину и пускай она проксирует этот трафик системе фильтрации контента? Или каждая машина будет сама свой SSL трафик контролировать? А пользователь берет - и сносит этот серверный сенсор с своей машины, что бы не тормозил.

1. А чем плохо каждому пользователю по собственной IDS? Очень даже неплохо. Тут тебе все в одном флаконе - AV, ID&PS, CF и т.п. И стоят они недорого по сравнению с серверными решениями.
2. А снести что-то непозволит либо сама система защиты, либо это реализуется путем отсутствия у пользователя административных привилегий на своем компе, либо орг.мерами - оторвать шаловливые ручки.
Luka
 
Цитата
Luka пишет:
2. А снести что-то непозволит либо сама система защиты, либо это реализуется путем отсутствия у пользователя административных привилегий на своем компе

Вах!

Научите меня пожалуста заперетить пользователю на любой операционной системе что-то сносить при наличии у него физического доступа к машине. Без ремня в рукаве и соболя в кармане.
 
Цитата
asu4ka пишет:
Научите меня пожалуста заперетить пользователю на любой операционной системе что-то сносить при наличии у него физического доступа к машине.
Легко!!! [IMG]http://www.securitylab.ru/forum/smileys/smiley17.gif[/IMG]
ключевые слова - орг.меры и контроль.
 
Цитата
asu4ka пишет:
Цитата
Luka пишет:
2. А снести что-то непозволит либо сама система защиты, либо это реализуется путем отсутствия у пользователя административных привилегий на своем компе

Вах!

Научите меня пожалуста заперетить пользователю на любой операционной системе что-то сносить при наличии у него физического доступа к машине. Без ремня в рукаве и соболя в кармане.

А это уже клиника, батенька. Запишетесь на курсы, например Информзащиты, Лукацкий будет доволен:-)) (без обид)
 
И в каком же курсе Информзащиты меня этому научат [IMG]http://www.securitylab.ru/forum/smileys/smiley3.gif[/IMG] ?
Подскажите?
оргмеры=ремень [IMG]http://www.securitylab.ru/forum/smileys/smiley17.gif[/IMG]
Страницы: 1 2 След.
Читают тему