Pull to refresh
17
0
Владимир Фисейский @fiseisky

Разработка IT-продуктов, IT-управление, DevOps

Send message
Я тоже использовал ELK, писал шаблоны в Кибане 3 и 4 версии, пробовал уведомления. Одно время в базе было больше 100 Гб лога. И я даже не сомневаюсь в его мощи, но в данной ситуации он реально выглядел излишним.
Да,… и какой глубины ящички, на которых он висит.
Можно, но каждой задаче свой инструмент.
В моем случае Zabbix справляется хорошо.
Разворачивать ELK стек для мониторинга 5-10 событий лога излишне. Да, Logstash может работать и отдельно, но хотелось более легкий в плане ресурсов инструмент.
Да, все работает, на всякий случай сейчас даже перепроверил.

Лог я использую для выдачи в триггере. То есть Heka фильтрует нужные записи, те, что подпадают под фильтр отправляются в Zabbix, а там стоит траппер, который поднимает соответствующий триггер при приходе сообщения. Сам Zabbix для парсинга и фильтрации логов не используется.


В статье, кратко описано как это устроено: в Zabbix настроены трапперы, и Heka при приходе определенного сообщения отправляет его на соответствующий траппер, а тот вызывает срабатывание триггера. Ну и заодно, лог сохраняется в Zabbix.

Все верно, Heka давно не развивалась, но как показывает правктика, она вполне себе еще работает.
Из нашей практики это бывает нужно, когда логов еще не настолько много чтобы держать под них специальную систему хранения.
Что касается физической защиты, Япония и США — это однозначно слабая скорость, что далеко не всем подходит, в европе-то найти что-то качественно работающее не всегда тривиальная задача. Что касается юридической защиты это очень индивидуальная история. Компаниям, которым нужно столь тщательное продумывание, правильно сначала проработать все свои модели угроз, затем выработать требования к скорости и отказоустойчивости и на основании этого, искать правильное решение.

Против лома нет приема. В ИБ задача всегда сводится к тому, чтобы сделать процесс взламывания более дорогим чем та ценность, которая будет получена в результате этого взлома.
Согласен, давайте подумаем вместе, вед интересно теоретически рассмотреть любые сценарии. Предположим, идет чисто юридическая атака, логика не совсем понятна, но допустим. Наверно правильным будет ответить на такую атаку: "к какому телу?" ведь пока нет адреса сервера, нет предмета для экспертизы.
Ага, возможно это на 175.15.236.151, но только это не наш сервер
Хотя нет, совпадения есть: это IP релей-сервера номер 2, просто записан наоборот.
Как связан метод, с местоположением серверов,- это же просто математика. Если у вас хотя бы один узел в РФ, то СОРМ не дремлет (при желании), а это значит, что можно составить граф коннектов и полей заголовков, а по большей плотности сразу видны «места наибольших коннектов», т.е. плотность трафика между 2-3-4-5 узлами значительно выше плотности остальных соединений, что приводит к абсолютной деанонимизации всей вашей сети.

Смотря какой узел. Если в под контролем СОРМ оказывается точка доступа, то вычислить можно только адрес расположения маршрутизатора и пользователей. Ничего больше.

А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.

Так получается, что задача провалена чуть более, чем полностью, ведь анализатор трафика (тот же пассивный СОРМ, даже без DPI) дает полное и исчерпывающее понимание всей структуры вашей сети.


Не соглашусь. Во-первых, киберразведка это не только про СОРМ. Во-вторых, рассмотрим ситуацию:
1) Опубликованные (например, как в нашем эксперименте) релей-сервера — фронтенды располагаются вне РФ, пусть даже СОРМ собирает весь трафик между пользователями и точками входа.
2) Сервер-маршрутизатор расположен где-то.
3) Защищаемый сервер, давайте теоретически считать, в соответствии с ФЗ152 расположен где-то в РФ.
Как найти с чем сопоставлять данные СОРМ уходящие от пользователей в заграницу, ведь не известно где располагается защищаемый сервер? Значит надо мониторить все эксчендж интернет узлы, а это сами понимаете что за задача. Тем более, что данные уходящие за границу, возвращаются уже пережатые vpn. Нет тут даже предмета для математического исследования.

Кроме всего прочего, вы сильно заблуждаетесь в том, что мерами групповых политик и ограничения доступа пользователей к сокрытию информации (как вы писали в комменте ) что-то защищаете. Ведь сокрытие алгоритма, например, не делает алгоритм шифрования устойчивее, иногда даже наоборот (см. работы Шеннона и доказательства стойкости), у вас же средством обеспечения надежности является операционная система, НДВ которой, мягко говоря, не исследовано.

Абсолютно согласен, но это вне нашей задачи. Это вопрос к клиенту какой сервис и ОС использовать, впрочем, это всегда черный ящик, про который никто ничего не гарантирует.

Более правильным было бы создать «виртуальную» сеть, с серой адресацией, строилась бы которая на независимых маршрутизаторах, что вообще избавило бы от проблем настройки конечных пользовательских систем, забывчивости администраторов и, как вы писали, административного ресурса с применением социальной инженерии, т.е. для пользователя систему все выглядело бы как простая внутренняя локальная сеть; вы же, закрывая доступ, вызываете нездоровые вопросы и интерес.

Если вы про tor — согласен, возможно это и есть альтернатива. Но только надо понимать, что в этой схеме есть и минусы: система на самом деле централизованная, контролируется не вами, не гибкая в настройках (например, вы не можете выбрать маршрут), с точки зрения скорости работы — не гарантированная и не управляемая вами. Из нашего опыта, не все клиенты к этому готовы.
Внутри все по vpn, верно, а наружу в этом кейсе у нас все по 80-му порту идет в открытую.
Смею уверенно утверждать, что ее там нет.
Да, мы тоже по сути эту схему в начале делали с точками "входа", потом поняли, что некоторые виды трафика по условиям задачи нужно отдавать через другие точки "выхода". Типа в сторону gmail трафик один с одного адреса, в сторону сбербанка с другого. Но потом когда задумались о тиражируемой коробке, переработали схему. теперь у нас универсальные "точки доступа" они могут смотреть как в сторону клиента, так и в сторону сервиса.

Отдельная история с NAT когда SIP через него пытаешься гнать, тут мы тоже неслабое число граблей собрали. Но по факту, получили не просто криптофон, а анонимный криптофон, при звонке или чате с которого нельзя, прослушивая трафик, установить даже кому ты звонил или писал.

Еще мы поняли, что чтобы клиенту нужно отдавать сервис без нашего к нему доступа, то есть клиенту отдается коробка, к которой у нас нет ни доступа, но и даже информации о том на каких адресах она работает. Тут пришлось пилить систему управления, легкую и удобную.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity