Кто сканирует Интернет. Время ковать железо

    Не хочу отказываться от заголовка. Ведь он выполняет свою задачу – привлекает внимание. Искренне прошу не сердиться, если содержание статьи не оправдало ваших ожиданий. Время теперь такое. «Такие материалы», — говорили они «нужно размещать на форумах для любителей, а на Хабре только высокоинтеллектуальная IT публика рассказывает о том, чего вам и не понять никогда да и пытаться понимать не нужно». Однако, Слава Хабру! Он достаточно демократичен.

    Что-то зацепила меня тема сетевой безопасности в части анализа сетевого трафика и обнаружения Несанкционированной Сетевой Активности (далее по тексту НСА).

    Аспекты НСА, которые меня интересуют:

    • несанкционированное сканирование ресурсов(портов, web-таргетов) защищаемой сети(далее — ЗС) из открытой сети (далее — ОС);
    • — несанкционированный трафик из/в ЗС. Это самостоятельная сетевая активность приложений;
    • несанкционированная вставка нежелательного контента (далее — НК). Это реклама, контент сомнительного содержания.
    • известные виды сетевых атак (далее — СА).

    Что меня пока не интересует: все, что не касается сети. Это антивирусная защита непосредственно рабочих станций и серверов, почтовый спам, взлом паролей и т.д. и т.п.

    Почему я решил изобретать велосипед? Ведь существует много железа и софта вроде бы выполняющего эти же функции и вроде бы не плохо. Но вот в чем вопрос: мы тратим огромные деньги на гиперконвергентныесуперфаерволыследующегопоколения, а толку нет. Пришло обновление и завалило все ПК. Пользователи сидят с правами админов, тыкают в рекламу в браузерах и ловят шифровальщиков. «Ой, мы сегодня закрыты по техническим причинам» — приходится говорить владельцу бизнеса. Админы выпускают свежий сервер в Сеть обновиться со всеми открытыми портами, его тут же и «обновляют как надо». А потом начинает тормозить сеть, домен попадает в спамеры и прочие прелести IT жизни. Ну, Бизнес как-то вроде пытается платить админам чтобы они шевелились. Они и шевелятся, но не долго – привыкают. Все знают, что IT инциденты происходят всегда внезапно как зима для коммунальщиков. Что касается госсектора, то тут как обычно – «дураки и дороги». С одной стороны — огромные затраты на «модернизацию сети», закупки дорогого оборудования, которые ничего кроме обоснованного подозрения в распилах бюджета вызвать не могут. С другой стороны низкая оплата труда IT специалистов, которая приводит к текучке кадров и общему низкому профессиональному уровню админов. В итоге имеем дорогое оборудование и студента, который не умеет, не знает и знать не хочет что с этим делать. То есть проблема безопасности не в железе. Человеческий фактор, вот что определяет общую безопасность систем.

    К чему это я? К тому, что наверное для каждого владельца бизнеса будет интересно иметь «админа» выполняющего свои обязанности одинаково хорошо в режиме 24/7 практически «за еду».

    Вот именно такого «железного админа» я и хочу реализовать.

    Начать решил с сетевой безопасности. Ограничить или исключить внешнее влияние на ЗС это уже 50% дела.

    Итак, Общая концепция:

    Главные исходные (идеальные?) условия:

    1. Низкая стоимость. Железка, в базовом варианте должен быть доступен по цене всем категориям, от отдельного пользователя с одним ПК и выше.
    2. Железка не должен требовать для выполнения своих обязанностей постоянного внимания квалифицированного персонала. Поставил и забыл.
    3. Железка должен легко заменяться, не требуя при этом дополнительной настройки.
    4. Железка должен быть интерактивен – сообщать заранее определенному кругу лиц о текущих или предполагаемых угрозах, своем состоянии, самостоятельно принимать решения на основе анализа ситуации. То есть не админ должен постоянно заглядывать в лог, а Железка должен сообщать что что-то пошло не так и что он сделал чтобы это «не так» исправить.
    5. Интерфейс взаимодействия с Железкой должен быть прост и понятен даже для начинающего IT специалиста. Никаких консолей и регулярных выражений. Оставим небо птицам.

    Это что касается Стратегических целей. Теперь вернемся на землю. Пусть Железка будет состоять из Коллекторов, собирающих информацию, и Центра анализа и принятия решений(далее -ЦАПР). Есть какие-то аналогии с «Умным домом», IoT. Пусть это будет «Умный осьминог»(фу, гадость). Но, почему бы и нет? Похоже ведь – Коллекторы это щупальца, а мозг -ЦАПР

    Предполагается несколько вариантов ЦАПР:

    1. Интегрированный – Коллектор и ЦАПР на одной железке.
    2. Локальный – работающий с ограниченным списком оборудования. Допустим в пределах одной организации или территории.
    3. Глобальный – ресурс в Интернет, работающий с Коллекторами в пределах сети Интернет.
    4. Региональный(опция) – для распределения нагрузки Глобального.

    Все ЦАПР нижних уровней могут взаимодействовать с Глобальным ЦАПР, хранящим наиболее полную базу признаков НСА.

    Действие первое. Создаем интегрированный ЦАРП-Коллектор для контроля НСА.

    Что представляет из себя Коллектор НСА на текущем этапе? Это, по сути, компьютер под Linux помещенный в 1U корпус. Коллектор имеет 3 сетевых интерфейса. Двумя включен вразрез сети. Один интерфейс управления. ЦАПР располагается на этой же платформе.

    Вот текущая схема включения:

    image

    Любое внешнее взаимодействие коллектора идет только через интерфейс управления. Для Интернет трафика Коллектор прозрачен.

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

    Что делает Коллектор? Собирает заданные части трафика. Заголовки и при необходимости, содержимое пакетов. Это настраивается правилами. Нет смысла собирать весь трафик. Данные о трафике за небольшой период времени (зависит от нагрузки и объема рабочего диска, неделя-месяц) хранятся на коллекторе. Таким образом Коллектор может выступать в качестве одновременной замены источника, коллектора и системы отображения статистики по типу Netflow. Конечно, поскольку Коллектор содержит информацию о каждой сессии, он не предназначен для хранения статистики за долгие периоды времени. Если в этом есть необходимость то статистика может сбрасываться в сетевое хранилище или на подключаемый диск в виде файлов, и в дальнейшем, анализироваться и отображаться средствами ЦАПР.

    Коллектор не туп. Он анализирует трафик на основе определенных ЦАПР правил и отправляет в ЦАПР информацию в случае срабатывания фильтров-триггеров определенных из ЦАПР. Кроме того, Коллектор самостоятельно фильтрует трафик.

    Как-то так.

    По мере работы над Коллектором пришла мысль нагрузить его и другими функциями. Про все планируемые функции рассказывать не буду. Но вот есть желание интегрировать в Коллектор SYSLOG сервер и коллектор SNMP Trap. Это необходимо, в том числе для анализа корреляции некоторых событий.

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

    Проект открыт для участия.

    Если у кого есть собственные интересные наработки по теме SYSLOG, SNMP пишите в личку, создадим совместный продукт.

    Основные условия:

    1. Никаких «на основе…», только свое, уникальное, и если есть front-end то обязательно user-friendly! Чтобы можно было работать без клавиатуры. Никаких тормозных и кривых Java. Zabbix-ы и Logstash- ы тоже идут к Kibane. Приветствуются C, Python, Perl, PHP, HTML, CSS, JS (чистый, без фрамеворкофф. Даже без JQuery, да).
    2. Ориентация только на современные ОС и браузеры. Никаких совместимостей с MS-DOS на IBM XT и Internet Explorer 1.0.
    3. Linux-only.

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

    Для высокоинтеллектуального сообщества предлагаю задачку от Коллектора (сам пока не решил):
    Исходная схема как на рисунке выше. Роутер подключен к ISP по PPPoE и на нем адрес 91.122.49.173. Адрес уже засвечен из предыдущих статей. Но это и хорошо для тестирования– наблюдается постоянный интерес.

    Вот что показал Коллектор:

    image

    Красный маркер это пример НСА. В данном случае признаком является то, что ни адрес источника ни адрес назначения не принадлежат ЗС. Протокол UDP, порт назначения 5000. Тема про трояны известная. Но ЗС имеет только один внешний адрес PAT (91.122.49.173). То есть я ожидаю, что в канале ISP-Router увижу только пакеты, у которых адрес источника или адрес назначения — внешний адрес роутера.

    Посмотрим историю за сегодня:

    image

    Здесь видим что по одной и той же схеме пакеты с одним адресом источника, но с разными адресами назначения пролетают через наш Коллектор.

    Каким образом прилетает этот трафик я пока не разобрался. Если у кого-то есть мысли – изложите пожалуйста в комментах. Встречая такую НСА Коллектор ставит ловушку на этот трафик и при следующем его появлении собирает более подробную информацию, а затем банит его. Это, конечно только один случай. Просто для меня он необъясним пока;

    С уважением,
    R_voland.
    Поделиться публикацией
    Комментарии 11
      0
      «Дорогой» админ будет дешевле, имхо
        +2
        Погодите, я правильно понимаю, что тут заново изобретают IDS?
          0
          Красный маркер это пример НСА. В данном случае признаком является то, что ни адрес источника ни адрес назначения не принадлежат ЗС.… Каким образом прилетает этот трафик я пока не разобрался.

          Это мультикаст-траффик.

            0
            Вот мультикастовый диапазон:
            Сеть: 224.0.0.0 / 4
            Минимальный IP: 224.0.0.1
            Максимальный IP: 239.255.255.254
              0
              Ну и? Там 225-я сеть. 224 < 225 < 239
                0
                Да, но какое это имеет отношение к адресу 91.122.49.173?
                Насколько я понимаю порт должен быть подписан на IGMP группу чтобы в него лился этот трафик. Иначе это броадкаст. И в это время не наблюдается активности по IGMP.
                  0
                  Я не знаю всех деталей, чтобы ответить на заданный вопрос. IGMP мог быть выполнен ранее. IGMP — протокол сетевого уровня, наравне с IP, и вы его можете вообще не фильтровать, сосредоточившись только на IP. Да мало ли что. Вы спросили про красный маркер — я ответил.
                    0
                    Ok. Спасибо. Вы мне подали отличную идею -ловить подписки на мультикаст.
                      0

                      посмтрите вначале вайршарком, что именно валится в этом UDP-мултикасте.

            0

            У меня есть объяснение — почему к Вам добирается левый трафик.
            Все адреса после 224.0.0.0 используются для служебных целей.
            225 сеть — скорей всего multicast трафик, возможно цифровое телевидение.

              0
              Не возможно, а это точно мультикаст, судя по адресации.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое