Наверное off-topic, но не поделитесь причиной использования Proxy в ваших офисах?
NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…
> Кому нужны 2.7Гб\сек чтение, когда их с такой скоростью просто НЕКУДА сливать?
Почему некуда? В память будут литься с приемлемой скоростью. А вот с замечанием про отсутствие минимальных характеристик, я совершенно согласен: они интересны в первую очередь…
Будьте осторожны. Где-то читал что спирт и спирт-содержащие кремы/жидкости зачастую запускают процессы деградации «soft-touch» покрытий. Ссылки под рукой нет но почитайте инструкцию по уходу — у этих покрытий есть своя «ахиллесова пята»…
По-моему проблема в том что «statefull» межсетевые экраны (те которые appliance а не на конечном сервере) в принципе не могут нормально работать: они не знают и не могут знать реального состояния сетевого стека на стороне клиента и/или сервера, их вычислительная мощность на порядок ниже клиент-серверной. Отсюда и растут ноги бесконечных «drop» политик и «експирящиеся» сессии которые приводят к случайно залипающим/отваливающимся коннектам. В смысле отладки — полный кошмар.
Помню их FAQ, читал. Но они про DSN то и пишут — может быть «злом» но тем не менее это часть стандарта. Лет 5-10 было у меня пару запросов на эту тему (может и от них уж не помню сейчас). Ответил кратко «DSN is mandatory part of RFC.» и развернуто «если проблема столь острая можете делать по простому: дискардить любые входящие ДСНы (глупость), или можете делать по интеллектуальному: дискардить входящие ДСНы для которых нет соответствующих исходящих писем». Если проблема может быть решена на стороне клиента то там она и должна решаться…
Мой опыт/ощущение «фишинга» — если в вкратце — техника тут бессильна: пользователи заполняют формуляры и кликают на ссылки в письмах которые, мне кажется, даже в пятном угаре нельзя принять за настоящие. Недавно то-ли на семинаре то ли в частной обсуждении слышал любопытную гипотезу:
Фишеры специально оставляют массу «аномалий/ошибок» в своих письмах/формулярах — это психологический прием позволяет отсечь «слишком умных» — их трудно «разводить», они могут поднять тревогу, и.т.д.
SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?
SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…
SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…
200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:
Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)
Честно говоря так и не понял вашей радости от "-all"… Объективная польза от SPF близка к гомеопатической. Прописывать ее конечно нужно, а вот выставлять "-all" я бы не советовал…
Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?
50 дверей: ну если у вас уже 50 дверей то действительно поздно пить боржоми… В таком сценарии DLP поможет хотя-бы вам качественно ценить с какой скоростью у вас воруют данные…
Аудит: такие системы разрабатываются индивидуально вместе с конкретной системой. Точка отбора — обычно хватает логов активности. Ну а далее по-большому счету та-же математика что и для ловли спама. В «умных» и больших системах, например, через k-means строятся стандартные профили и отслеживаются заметные отклонения хотя бывает и обычная эвристика.
«чем они будут принципиально лучше с точки зрения ИБ»: не нужен доступ к чувствительным данным. Для фиксации факта аномалии достаточно данных о активности и несколько метрик — грубо говоря важно не что именно делает пользователь а то насколько это отличается от обычных видов активности пользователей такого типа.
Мы с вами не согласимся… Я пытаюсь обратить ваше внимание на то что две двери хуже чем одна, а слышу в ответ что ничего страшного просто запирайте покрепче, привязывайте собак потолще и в любом случае не стоит волноваться так как вас все-равно обворуют… Мы явно работаем в разных областях. Так бывает.
По поводу «плотного аудита»: кража практически всегда сопровождается аномальной активностью пользователя (слишком «широкая» и/или частая выборка, и т.д.) — такая активность детектируется по логам активности баз данных или на уровне сервера бизнес логики. Такие системы имеют высокую эффективность но и их можно обойти:
https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D0%BE_Soci%C3%A9t%C3%A9_G%C3%A9n%C3%A9rale
«Так что позвольте с Вами, как бы это помягче сказать, не согласиться. »:
Вынужден продолжать не соглашаться с вашим несогласием. Вы написали развернутый ответ включающий, в том числе, ответ от "@Amihailov". Позвольте развить мою мысль чуть детальней:
— Фундаментальная проблема DLP №1 — чтобы что-то найти надо знать что искать. Ваш DLP получит доступ к вашим «секретным» данным. Можно конечно обсуждать разные имплементации как оно там хашиться или обсурцируеться но суть одна: кроме клиента и сервера появляется третья сторона. Та самая сторона которая зачастую имеет доступ ко всем источникам «секретных» данных без сегментации по пользователям (или у вас по DLP на базу? ;-)) Как бы ваш DLP не был реализован он самим своим существованием увеличивает экспозицию «секретных» данных — то есть ухудшать безопасность.
— Фундаментальная проблема DLP №2 — чтобы что-то найти надо чтобы вам никто не мешал это делать. Общая тенденция последних лет — систематическая защита клиент-серверных коммуникаций: сетевой трафик шифруется, а система/антивирусы/и т.д. следят чтоб никто не навешивал хуки на системные вызовы и не внедрялся в чужую память. Как бы ваш DLP не был реализован он вынужден ломать/обходить эти механизмы — то есть ухудшать безопасность.
— Фундаментальная проблема DLP №3 — проблема черного ящика. Ваш DLP (любой) — использоваться маржинально и как правило не является открытым. Такое положение значит что на сертификацию хотя-бы на уровеь EAL4 банально не хватает средств и код никто даже случайно не аудитирует. Это позволяем спокойно существовать ошибкам архитектуры, реализации и имплементации. Дыра в Symantec Scan Engine на прошлой неделе как и регулярные дыры в топовых решениях безопасности (за последних несколько месяцев помнятся фатальная «критика» в Juniper, PaloAlto, FortiNet) — яркая тому иллюстрация. Посмотрите эти дыры, там и «arbitrary execution» и фиксированные ключи шифрования, полный фарш вобщем… Как бы ваш DLP не был реализован он привнесет в вашу информационную систему свои дыры при этом он привнесет их в критическом месте — то есть ухудшит безопасность.
Если вы ставите DLP просто для анализа «зеркалированого» сетевого трафика на стандартные маркеры типа «TOP SECRET» и DLP что-то ловит — слава богу — вы нашли удачное решение: срочно латайте дыры. Во всех остальных случаях вы привносите гарантированное ухудшение безопасности в надежде на гипотетическую надежду что-то, когда-то поймать… Как по мне — это неоправданный риск. Адекватной реализаций клиентов и плотным аудитом можно получить тот-же результат без ухудшения безопасности.
«Я не вижу зла в DLP»:
Что бы DLP работал вам в общем случае нужно для начала ослабить безопасность до уровня допускающего внедрение DLP — убрать шифрование с каналов связи, всунуть свой корневой сертификат на машины или сделать любую аналогичную глупость. Нельзя своими руками ослаблять «реальную» защиту в надежде что DLP чтонибуть поймает. Ваш DLP — потенциально дополнительный канал утечки…
Ваш пример, по большому счету, опять из области «цензуры/шпионажа/контроля пользователей»: если ваши пользователи могут себе ставить «дропбокс» то они без труда себе поставят как «обходилку» вашего мониторинга так и нахватаются всякой другой малвари. Последняя кстати тоже успешно обходит все эти «специальные железки» уже не первый год банально интегрируя свой трафик в параметры тех-же GET/POST обычного веб-трафика.
Обеспечение безопасности рабочих станций надо на них и реализовывать — именно там где есть наиболее полная информация о контексте и адекватности того или иного действия пользователя. Если-бы эффективность ваших железок была-бы сколько-нибудь значимой то, я думаю, все страны уже давно бы скинулись на парочку: одна-бы уничтожила все вирусы а вторая весь спам ;-)
Я надеялся что вы представите пример реалистичного сценария при котором экспозиция ключей шифрования третей стороне (= серьезное глобальное ослабление безопасности) компенсируется чем-либо другим (укрепляющим безопасность и невозможным получить другим способом (более простым и безопасным))
Безусловно оставим в стороне потребности вроде цензуры/шпионажа/контроля пользователей: такие сценарии изначально исходят из потребности ослабить безопасность до уровня допускающего внедрение «наблюдателя»…
Вам не кажется что ваше «решение» хуже «проблемы»? У нас тут тоже кроме всего прочего ваш «расшифровать» стоит (тот самый за много сотен килобаксов). Были попытки пропихнуть эту функцию в продакшен… не прошло. Не буду расписывать — просто посмотрите топовые фаерволы за последний 10 лет и найдите хотя-бы один который (задним числом конечно) не оказался-бы критически дырявым — это общая проблема «черных ящиков». Нельзя своими руками ослаблять «реальную» защиту в борьбе с «гипотетическими» рисками.
Бест практики и глобальные тенденции подразумевают что сегодня практически любой коннект клиент-сервер или сервер-сервер завернут в TLS туннель (ну или как-либо иначе зашифрован). Что именно и как вы собираетесь анализировать?
«Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов. »:
SPF декларировать безусловно нужно хотя-бы потому что SPF используется большинством анти-спам систем и в случае отсутствия SPF записи, зачастую, применяются параметры хуже любой пермисив политики SPF. С дугой стороны я-бы поостерегся советовать не ставить "?all" или "~all": «рядовые компании» тоже пишут письма клиентам/партнерам. Эти письма будут/могут теряться при перенаправлениях возникающих регулярно и оправданно (компании покупают и продают, они сливаются и разделяются, возникают/исчезают филиалы, ребрендеринг и т.д.). Установка систем которые переписывают шапку или перепаковывают письмо — скорее исключение чем правило. Просто нужно помнить что мир не будет подстраиваться под «рядовые компании» и если нашей гипотетической «рядовой компании» важно/нужно держать связь с миром надо принимать мир таким как он есть.
PS Если хочется запретить письма с вашим «from»ом приходящие к вам из вне — просто запретите их на вашем MXе — это куда надежней.
«и почему они его приняли, мы не узнаем»:
Собственно я вам написал почему. У меня / у нас та-же ситуация: научное/университетское учреждение, почтовая система используется практически с момента создания протокола. За десятилетия складываются определенные традиции:
— почта ученых перенаправляется вслед за ними (они публикуют свои адреса в научных статьях)
— выпускники (алюмни) получают пожизненные адреса
и т.д.
Все это в разумных пределах конечно.
Видимо создатели SPF надеялись что весь инернет все переделает. Так обычно не бывает и в конкретном случае для прозрачного перехода требуются гигантские ресурсы при совершенно не очевидном/посредственном результате.
ПС С фишингом борются так-же как с обычным спамом. SPF в этом контексте имеет практически нулевую эффективность.
Вы не правы: ?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети, он-же обеспечивает нормальную пересылку почты(forward), он-же ограничивает фривольную интерпретацию вашего SPFа у получающей стороны, и т.д. Собственно такие политики — стандартная практика научных/университетских учреждений.
Пара примеров:
# dig txt yale.edu
…
yale.edu. 10800 IN TXT «v=spf1 ip4:130.132.50.0/24 ip4:130.132.232.0/24 include:_spf.google.com include:spf.protection.outlook.com include:_spf.qualtrics.com ~all»
NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…
Почему некуда? В память будут литься с приемлемой скоростью. А вот с замечанием про отсутствие минимальных характеристик, я совершенно согласен: они интересны в первую очередь…
Фишеры специально оставляют массу «аномалий/ошибок» в своих письмах/формулярах — это психологический прием позволяет отсечь «слишком умных» — их трудно «разводить», они могут поднять тревогу, и.т.д.
SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?
SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…
SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…
200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:
Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)
Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?
Аудит: такие системы разрабатываются индивидуально вместе с конкретной системой. Точка отбора — обычно хватает логов активности. Ну а далее по-большому счету та-же математика что и для ловли спама. В «умных» и больших системах, например, через k-means строятся стандартные профили и отслеживаются заметные отклонения хотя бывает и обычная эвристика.
«чем они будут принципиально лучше с точки зрения ИБ»: не нужен доступ к чувствительным данным. Для фиксации факта аномалии достаточно данных о активности и несколько метрик — грубо говоря важно не что именно делает пользователь а то насколько это отличается от обычных видов активности пользователей такого типа.
Ну в общем спасибо за беседу.
По поводу «плотного аудита»: кража практически всегда сопровождается аномальной активностью пользователя (слишком «широкая» и/или частая выборка, и т.д.) — такая активность детектируется по логам активности баз данных или на уровне сервера бизнес логики. Такие системы имеют высокую эффективность но и их можно обойти:
https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D0%BE_Soci%C3%A9t%C3%A9_G%C3%A9n%C3%A9rale
Вынужден продолжать не соглашаться с вашим несогласием. Вы написали развернутый ответ включающий, в том числе, ответ от "@Amihailov". Позвольте развить мою мысль чуть детальней:
— Фундаментальная проблема DLP №1 — чтобы что-то найти надо знать что искать. Ваш DLP получит доступ к вашим «секретным» данным. Можно конечно обсуждать разные имплементации как оно там хашиться или обсурцируеться но суть одна: кроме клиента и сервера появляется третья сторона. Та самая сторона которая зачастую имеет доступ ко всем источникам «секретных» данных без сегментации по пользователям (или у вас по DLP на базу? ;-)) Как бы ваш DLP не был реализован он самим своим существованием увеличивает экспозицию «секретных» данных — то есть ухудшать безопасность.
— Фундаментальная проблема DLP №2 — чтобы что-то найти надо чтобы вам никто не мешал это делать. Общая тенденция последних лет — систематическая защита клиент-серверных коммуникаций: сетевой трафик шифруется, а система/антивирусы/и т.д. следят чтоб никто не навешивал хуки на системные вызовы и не внедрялся в чужую память. Как бы ваш DLP не был реализован он вынужден ломать/обходить эти механизмы — то есть ухудшать безопасность.
— Фундаментальная проблема DLP №3 — проблема черного ящика. Ваш DLP (любой) — использоваться маржинально и как правило не является открытым. Такое положение значит что на сертификацию хотя-бы на уровеь EAL4 банально не хватает средств и код никто даже случайно не аудитирует. Это позволяем спокойно существовать ошибкам архитектуры, реализации и имплементации. Дыра в Symantec Scan Engine на прошлой неделе как и регулярные дыры в топовых решениях безопасности (за последних несколько месяцев помнятся фатальная «критика» в Juniper, PaloAlto, FortiNet) — яркая тому иллюстрация. Посмотрите эти дыры, там и «arbitrary execution» и фиксированные ключи шифрования, полный фарш вобщем… Как бы ваш DLP не был реализован он привнесет в вашу информационную систему свои дыры при этом он привнесет их в критическом месте — то есть ухудшит безопасность.
Если вы ставите DLP просто для анализа «зеркалированого» сетевого трафика на стандартные маркеры типа «TOP SECRET» и DLP что-то ловит — слава богу — вы нашли удачное решение: срочно латайте дыры. Во всех остальных случаях вы привносите гарантированное ухудшение безопасности в надежде на гипотетическую надежду что-то, когда-то поймать… Как по мне — это неоправданный риск. Адекватной реализаций клиентов и плотным аудитом можно получить тот-же результат без ухудшения безопасности.
Что бы DLP работал вам в общем случае нужно для начала ослабить безопасность до уровня допускающего внедрение DLP — убрать шифрование с каналов связи, всунуть свой корневой сертификат на машины или сделать любую аналогичную глупость. Нельзя своими руками ослаблять «реальную» защиту в надежде что DLP чтонибуть поймает. Ваш DLP — потенциально дополнительный канал утечки…
Обеспечение безопасности рабочих станций надо на них и реализовывать — именно там где есть наиболее полная информация о контексте и адекватности того или иного действия пользователя. Если-бы эффективность ваших железок была-бы сколько-нибудь значимой то, я думаю, все страны уже давно бы скинулись на парочку: одна-бы уничтожила все вирусы а вторая весь спам ;-)
Безусловно оставим в стороне потребности вроде цензуры/шпионажа/контроля пользователей: такие сценарии изначально исходят из потребности ослабить безопасность до уровня допускающего внедрение «наблюдателя»…
SPF декларировать безусловно нужно хотя-бы потому что SPF используется большинством анти-спам систем и в случае отсутствия SPF записи, зачастую, применяются параметры хуже любой пермисив политики SPF. С дугой стороны я-бы поостерегся советовать не ставить "?all" или "~all": «рядовые компании» тоже пишут письма клиентам/партнерам. Эти письма будут/могут теряться при перенаправлениях возникающих регулярно и оправданно (компании покупают и продают, они сливаются и разделяются, возникают/исчезают филиалы, ребрендеринг и т.д.). Установка систем которые переписывают шапку или перепаковывают письмо — скорее исключение чем правило. Просто нужно помнить что мир не будет подстраиваться под «рядовые компании» и если нашей гипотетической «рядовой компании» важно/нужно держать связь с миром надо принимать мир таким как он есть.
PS Если хочется запретить письма с вашим «from»ом приходящие к вам из вне — просто запретите их на вашем MXе — это куда надежней.
Собственно я вам написал почему. У меня / у нас та-же ситуация: научное/университетское учреждение, почтовая система используется практически с момента создания протокола. За десятилетия складываются определенные традиции:
— почта ученых перенаправляется вслед за ними (они публикуют свои адреса в научных статьях)
— выпускники (алюмни) получают пожизненные адреса
и т.д.
Все это в разумных пределах конечно.
Видимо создатели SPF надеялись что весь инернет все переделает. Так обычно не бывает и в конкретном случае для прозрачного перехода требуются гигантские ресурсы при совершенно не очевидном/посредственном результате.
ПС С фишингом борются так-же как с обычным спамом. SPF в этом контексте имеет практически нулевую эффективность.
Пара примеров:
# dig txt yale.edu
…
yale.edu. 10800 IN TXT «v=spf1 ip4:130.132.50.0/24 ip4:130.132.232.0/24 include:_spf.google.com include:spf.protection.outlook.com include:_spf.qualtrics.com ~all»
# dig txt princeton.edu
…
princeton.edu. 43200 IN TXT «v=spf1 ip4:128.112.128.212 ip4:128.112.128.213 ip4:128.112.128.214 ip4:128.112.128.215 ip4:128.112.128.216 ip4:140.180.223.12 ip4:140.180.223.155 ip4:140.180.223.156 mx ?all»