Здравствуйте, Lazytech, Вы писали:
L>Заранее извиняюсь, если глупость скажу. А как же уязвимость, найденная Дэном Камински? Или это не из той оперы?
Это не из той оперы, а из той — это ошибка в протоколе TLS, вернее в реализациях, суть в том, что можно устроить так, что защищенное https соединение устанавливается повторно без повторного запроса сертификатов. Это не позволяет перехватить в смысле расшифровать https-сессию, но позволяет подменить пользователя.
DOO>Да поломаешь, поломаешь. Не забывай, что в корпоративной среде компьютеры пользователей "особые", например, они все доверяют корпоративному центу сертификации... Дальше понятно — прокси выдается сертификат подчиненного ЦС, прокси генерит нужный сертификат для каждого https соединения и терминирует соединение на себе — вот и все. Самый обыкновенный человек-по-середине.
Вот только внешний сервер вряд ли доверяет корпоративному центру сертификации. Я это к тому, что даже если соединение, скажем с gmail, и получится таким образом, всё равно, можно будет заметить, что сертификат не гугловский. И я сильно подозреваю, что немодифицированный Firefox сильно удивится этому, настолько сильно, что явно сообщит пользователю.
Здравствуйте, DOOM, Вы писали:
L>>Заранее извиняюсь, если глупость скажу. А как же уязвимость, найденная Дэном Камински? Или это не из той оперы? DOO>Ну как бы — зачем ломать DNS сервер, который ты и так контролируешь (речь же о корпоративной среде). DOO>Ну а по поводу этой "уязвимости" — если я нашел таки правильное описание, то общей идее с TID'ами сто лет в обед, идея дополнительного RR — видимо более новая и она просто сделала более применимой давно известную атаку. Вот и все. Ну а журналюги, естественно, раздули все ух как...
Не совсем. Каминский реально нашёл "новую" багу, хотя она была на поверхности.
Хотя возможность таких багов была известна давно, поэтому DJB в своём djbdns и предусмотрел заранее рандомизацию портов.
Здравствуйте, ambel-vlad, Вы писали:
AV>Ну если не верить разработчикам, то я не знаю кому уж и верить.
Каким таким разработчикам?
AV> Потому что именно устойчивость у них была первой.
Откуда дровишки?
НС>>Если они однотипные, вряд ли им нужны разные политики.
AV>Видишь ли, такое вполне может быть.
Видимо, в МС посчитали иначе. Домены ведь тоже не бесплатная вещь.
НС>>Думаю, написать на connect.microsoft.com
AV>Писать будем. Правда особых надежд не питаем.
Здравствуйте, Ночной Смотрящий, Вы писали:
AV>>Ну если не верить разработчикам, то я не знаю кому уж и верить.
НС>Каким таким разработчикам?
AV>> Потому что именно устойчивость у них была первой.
НС>Откуда дровишки?
Спрашивали у МС.
НС>>>Если они однотипные, вряд ли им нужны разные политики.
AV>>Видишь ли, такое вполне может быть.
НС>Видимо, в МС посчитали иначе. Домены ведь тоже не бесплатная вещь.
Да, не бесплатная. Однако есть большие сомнения, что эта цена в данном случае будет видна даже в микроскоп.
НС>>>Думаю, написать на connect.microsoft.com
AV>>Писать будем. Правда особых надежд не питаем.
НС>А зря. Большинство команд в МС вполне вменяемы.
А не зря. Потому что при данном подходе к snap-in это сделать несколько проблематично. Насчет вменяемости спорить не будут (хотя временами складывается иное впечатление), но сомневаюсь, что это будет исправлено в ближайшее время.
C>Не совсем. Каминский реально нашёл "новую" багу, хотя она была на поверхности.
Он нашел возможность травить весь домен за счет обработки дополнительных RR, если я правильно понял — подобных атак за последние лет дцать было штуки 3 минимум — однако никто не поднимал такой вопль...
C>Хотя возможность таких багов была известна давно, поэтому DJB в своём djbdns и предусмотрел заранее рандомизацию портов.
Это слабо поможет. Это эквивалентно тому, что TID стал 32-х битным. Для борьбы с парадоксом дней рождений это все еще слишком мало.
Здравствуйте, Michael7, Вы писали:
M>Вот только внешний сервер вряд ли доверяет корпоративному центру сертификации.
Причем тут внешний сервер?
M>Я это к тому, что даже если соединение, скажем с gmail, и получится таким образом, всё равно, можно будет заметить, что сертификат не гугловский.
А вот ты заметь. Дай бог, чтобы человек обратил внимание на предупреждение браузера о сертификате, не прошедшем проверку доверия, а уж чтоб кто-то заметил, что сертификат gmail.com выдан не Thawte, а корпоративным ЦС — это вообще фантастика.
M>И я сильно подозреваю, что немодифицированный Firefox сильно удивится этому, настолько сильно, что явно сообщит пользователю.
Ничему он не удивится. И я это не подозреваю, а знаю. Такая вот она инфраструктура открытых ключей.
причем, эта шармантка была и в 2 с чем-то, и в 3.2... Елки-палки, XXI век на дворе, кодировку определить сложно? Причем, лазил по опциям, ХЗ вообще как ее поменять.
¯\_(ツ)_/¯
И когда они были в поле, восстал Каин на Авеля, брата своего, и убил его.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Наброс окончен, спасибо за внимание. Жду аргументов о том, что OO под эти задачи не предназначен и что домохозяйки логи прокси на нем парсить не будут
Вопрос — кто виноват в том, что ты забиваешь гвозди микроскопами?
Здравствуйте, ambel-vlad, Вы писали:
НС>>Откуда дровишки?
AV>Спрашивали у МС.
И МС сказал, что домены использованы для повышения надежности? Извини, но не верю.
НС>>А зря. Большинство команд в МС вполне вменяемы.
AV>А не зря. Потому что при данном подходе к snap-in это сделать несколько проблематично. Насчет вменяемости спорить не будут (хотя временами складывается иное впечатление), но сомневаюсь, что это будет исправлено в ближайшее время.
Если об этом не писать — наверняка не будет.
AV>Кстати, а про обработку исключений есть мысли?
Мысли есть, но ковыряться в твоей специфике не особо охота. Берешь отладчики, рефлектор, и разбираешься в чем проблема.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Откуда дровишки?
AV>>Спрашивали у МС.
НС>И МС сказал, что домены использованы для повышения надежности? Извини, но не верю.
Вопросами веры занимаются в других форумах.
НС>>>А зря. Большинство команд в МС вполне вменяемы.
AV>>А не зря. Потому что при данном подходе к snap-in это сделать несколько проблематично. Насчет вменяемости спорить не будут (хотя временами складывается иное впечатление), но сомневаюсь, что это будет исправлено в ближайшее время.
НС>Если об этом не писать — наверняка не будет.
Напишу. Но при текущей модели они ничего не смогут сделать. И небольшими изменениями развертывания snap-in своих тоже ничего не изменить.
AV>>Кстати, а про обработку исключений есть мысли?
НС>Мысли есть, но ковыряться в твоей специфике не особо охота. Берешь отладчики, рефлектор, и разбираешься в чем проблема.
Выкладывай мысли. Интересно. А насчет отладчика и рефлектора, то код консоли мы уже перерыли не один раз. И если объяснение обработке исключений в основаном домене (не домене, в который загружен snap-in) можно попробовать еще как-то притянуть за уши, то невозможность словить необработанные исключения в каком-то месте вообще ни в какие ворота не лезет.
Здравствуйте, ambel-vlad, Вы писали:
НС>>И МС сказал, что домены использованы для повышения надежности? Извини, но не верю.
AV>Вопросами веры занимаются в других форумах.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И МС сказал, что домены использованы для повышения надежности? Извини, но не верю.
AV>>Вопросами веры занимаются в других форумах.
НС>Конечно. Поэтому — доказательства в студию.
Увы, но разговор сложно воспроизвести. Пока что только таким способом получалось добиваться ответов на вопросы, которые задавались в письменном виде. С чем это связано? Не знаю. Быть может вопросы достаточно узкоспециализированными были.
Я так понимаю, что по другим моментам тоже ничего больше нет?
Здравствуйте, ambel-vlad, Вы писали:
AV>Здравствуйте, kochetkov.vladimir, Вы писали:
AV>>>Есть еще куча всего. Но там уже нужно хотя бы немного описывать детали. Если кого-то заинтересует, то могу как-нибудь поделиться.
KV>>Ок, общая картинка проблем понятна. С каким открытым продуктом будем сравнивать? AV>На твое усмотрение
Прикольно. Мне неизвестен ни один открытый продукт со сходным функционалом
Здравствуйте, ambel-vlad, Вы писали:
НС>>И МС сказал, что домены использованы для повышения надежности? Извини, но не верю. AV>Вопросами веры занимаются в других форумах.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, kochetkov.vladimir, Вы писали:
k>> AB>(а почта на mail.ru или сообщения ICQ — это приватные данные) k>> А почту на mail.ru или сообщения ICQ у нас никто и не трогает, в логах отражен только факт отправки запроса, но не его содержимое AB>Тогда я не понимаю зачем на них смотреть — ну есть URI, время, размер, рефер в логе. Что это доказывает или опровергает?
А доказывать будут уже мои Большие Братья коллеги из службы безопасности. Мое дело предоставить им те имена пользователей, действия которых наиболее полно соответствует сценарию инцидента.
k>> AB>В нашей "конторе" этот процесс лишен практического смысла. k>> А это ты не мне, а вот этому человеку будешь рассказывать: http://company.yandex.ru/job/vacancies/rukovod_ib.xml
AB> Это не то.
Странно, а перечень обязанностей как-будто с моей ДИ писали
Здравствуйте, wraithik, Вы писали:
KV>>2) Во время импорта он не мешал мне работать, захватывая все доступные ему ресурсы компа. W>А это следствие того что ОО нагрузил оба ядра, а МСО только одно.
W>ЗЫ. ОО не нравится ни разу, но по второму пункту он лучше МСО.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Наброс окончен, спасибо за внимание. Жду аргументов о том, что OO под эти задачи не предназначен и что домохозяйки логи прокси на нем парсить не будут L>Вопрос — кто виноват в том, что ты забиваешь гвозди микроскопами?
Любая атака на информационную систему, как правило и представляет собой многочисленные попытки забить разные гвозди разными микроскопами под разными углами. Поэтому виноваты по-любому разработчики ОО.
L>Обрабатывать логи в Экселе — это извращение.
Почему, если в рамках моих задачи, он с этим вполне справляется лучше, чем прочие инструменты?
Здравствуйте, kochetkov.vladimir, Вы писали:
НС>>>И МС сказал, что домены использованы для повышения надежности? Извини, но не верю. AV>>Вопросами веры занимаются в других форумах.
KV>*весьма озадаченно* да?