Dns over tcp что это
DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах.
TLS (англ. transport layer security — Протокол защиты транспортного уровня) — обеспечивает защищённую передачу данных между Интернет узлами.
Вся разница между TCP и UDP DNS пакетами:
4.2.2. TCP usage
Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it.
То есть делаем туда:
- берём пакет из UDP
- добавляем к нему в начале пару байт в которых указан размер этого пакета
- отправляем в TCP канал
И в обратную сторону:
- читаем из TCP пару байт тем самым получаем размер пакета
- читаем пакет из TCP
- отправляем его получателю по UDP
Как работает обнаружение приложений в трафике
Одной из задач анализа приложений является обнаружение трафика приложений, которые специально созданы, чтобы их соединения не видели. Возьмем для примера Skype. Люди, которые научились отличать зашифрованные UDP пакеты Skype от других зашифрованных UDP пакетов – очень большие молодцы.
Есть еще класс устройств, которые так умеют: Deep Packet Inspection (далее DPI). Такие устройства стоят сейчас у крупных провайдеров и позволяют манипулировать трафиком приложений: применять QoS или перенаправлять в нужном направлении. Иногда NGFW и DPI сравнивают. Разница: DPI предназначен для управления качеством трафика, а NGFW безопасностью, хотя в NGFW тоже есть функции QoS.
Методы обнаружения приложений в трафике отличаются.
В базе данных приложений находятся тысячи приложений, поэтому по сути разбор форматов и алгоритмов каждого приложения – это долгая и кропотливая работа аналитиков. После того как поняли как приложение работает, начинают работать программисты, которые реализуют обнаружение приложения по трафику. И эти несколько тысяч приложений постоянно меняются. Соответственно, продукт должен постоянно поддерживаться, изучать новые приложения и контролировать изменения в старых и добавлять в базу измененные детекторы. Базу всех возможных приложений генерирующих трафик можно посмотреть тут.
Иногда вендоры L7 firewall пытаются меряться числом приложений которые есть у них в базе, но это больше похоже на профанацию. Включив критическое мышление вы понимаете, что вам в реальности нужно детектировать только приложения на периметре (в среднем это в районе 300 разных приложений), в ЦОД (10-15 штук), в ICS/SCADA сетях (2-3 приложения), между внутренними сегментами (возможно это всего несколько десятков). И если вам предлагают детектировать тысячи приложений — это всего лишь маркетинг и детект каких-то неизвестных приложений, которыми никто не пользуется.
Пример приложений в сети компании:
Внутренняя сегментация внутри компании – это постоянное требование стандартов ИБ, которое почти никто не выполняет. Между сегментами, где сидят программисты, финансисты, HR и бухгалтерия тоже ходят приложения. Как минимум нужно контролировать сеть Windows (протокол SMB), особенно это стало понятно после эпидемии криптолокера WannaCry, который распространялся именно по SMB. То есть во внутренних сетях тоже нужен анализ приложений 7 уровня и сопутствующие методики поиска вредоносного кода песочницей и IPS, да хотя бы контроля передаваемых типов файлов.
Самая частая проблема, которая заметна в сетях: межсетевой экран якобы 7 уровня, но в реальности детектирует приложения по портам. Как это проверить?
L7 Firewall безопаснее
У меня под рукой есть Palo Alto Networks NGFW. Я написал на нем три разных правила. Давайте разберем чем они отличаются.
Если вы настраивали когда-либо firewall, то вы видите, что для разных групп пользователей: vip, marketing и programmers я разрешил SSL тремя разными способами.
- vip пользователи смогут ходить по порту 443 и смогут пользоваться SSL внутри него, поскольку он является портом по-умолчанию для SSL. Если они попытаются пойти по 443 порту, например обычным telnet, то у них не получится – межсетевой экран проверит, что это не SSL и заблокирует. И это то что нужно!
- marketing может ходить по любому порту приложением SSL, потому что в поле Service, где указываются порты разрешен любой порт. Вопрос, хотел ли я чтобы маркетинг использовал SSL по нестандартным портам? Нет. Это частая ошибка настройки. Указывать порт как any логично, если правило запрещающее — то есть, если мы хотим запретить SSL по любому порту.
- programmers могут ходить по порту 443 любым приложением, что вообще-то является дыркой, потому что я изначально хотел открыть только SSL. И именно так и работают L4 firewall – он открывает порт и дальше ему уже все равно что там и какие приложение этим портом пользуются. Любой программист из группы programmers может воспользоваться любым туннелем.
Например, для правила ниже, где всем сотрудникам разрешено ходить в Интернет только по портам по-умолчанию, NGFW будет постоянно проверяться, что они хотят по 53 порту только DNS клиентом, а никак не TCP-over-DNS. И конечно же это повышает безопасность, ведь вы не просто разрешаете приложения, а контролируете, что по открытым каналам ходят только не приложения, которые вы разрешили.
Пишем скрипт
Я пишу на Lua 5.3. В нём уже доступны бинарные операции с числами. Ну и нам понадобится модуль Lua Socket.
UDP в TCP и обратно
Пишем две функции которые будут оперировать двумя каналами передачи данных.
Обе функции сразу после запуска выполняют coroutine.yield(). Это позволяет первым вызовом передать параметры функции а дальше делать coroutine.resume(co) без дополнительных параметров.
А теперь main функция которая выполнит подготовку и запустит главный цикл.
Запускаем главную функцию. Если вдруг будет закрыто соединение мы через секунду установим его заново вызвав main.
Пример туннеля TCP-Over-DNS
По собранным пакетам трафика на картинке видно, что идут соединения по 53 порту TCP, что обычно рассматривается как работа протокола DNS. Однако, если присмотреться, то видно, что в поле Text протокола DNS находится какой-то зашифрованный текст. Это реализация туннеля TCP-Over-DNS, которую я часто встречаю в корпоративных сетках. Слева список других туннелей, которыми могут воспользоваться и ваши пользователи или хакеры. Дает ли такую информацию L4 firewall? Нет. Поэтому, если нужно обезопасить компанию от несанкционированных туннелей, то нужно анализировать содержимое передаваемых данных и именно по ним разбирать какое же приложение в данный момент использует это TCP соединение.
Заключение
Во-первых, управлять безопасностью на L7 firewall проще. Раньше вы долго читали документацию производителя приложения и открывали порты, что там перечислены. Теперь просто: указываете название приложения в правиле NGFW и нужные порты будут разрешаться автоматически в зависимости от состояния соединений данного приложения.
Во-вторых, вы сможете обнаружить и заблокировать туннелирование, поскольку L7 firewall безопасно разрешает только явно указанное приложение и если кто-то попытается туннелировать другое приложение по открытому порту, то сразу будет обнаружен и заблокирован.
В-третьих, вы можете разрешить нужное приложение по любому нужному порту и по этому порту будет ходить только нужное приложение, а не все сразу. Например, только веб-браузер будет использовать 80 порт.
P.S. Не даём гуглу лишней информации о нас
Сразу после соединения Windows пытается зарегистрировать нас на DNS серверах гугла через наш туннель. Это отключается в продвинутых настройках DNS снятием галочки.
Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS.
Со временем ответ на довольно примитивный вопрос начинает интересовать каждого специалиста, так или иначе имеющего отношение к информационным технологиям и безопасности:
На этот вопрос отвечает действующий документ RFC5966 , раздел 4. Transport Protocol Selection , в котором фигурируют следующие утверждения:
Это означает, что все реализации DNS-серверов в общем случае должны поддерживать использование обоих протоколов транспортного уровня: TCP и UDP.
То есть, авторитативный сервер, хранящий зону, должен поддерживать TCP. Как минимум, чтобы передавать зону тому, кто имеет право ее запросить.
Рекурсивный же сервер должен поддерживать TCP для того, чтобы передавать полученные большие ответы от серверов клиентам, проверяя отсутствие подмены адреса инициатора запроса.
Stub resolver - это маленький тупой рекурсивный сервер, использующийся для небольшого количества клиентов. Например, домашний маршрутизатор, к которому подключаются клиенты. Он транслирует запросы вышестоящим серверам провайдера.
Как видим, RFC дает поблажку производителям маломощных устройств для того, чтобы снизить нагрузку на сервера в том окружении, где либо большие ответы от DNS маловероятны, либо они предполагается, что не будут вредить. Например, домашний маршрутизатор доступа, к которому подключены пользователи одной квартиры (2-3 устройства). В этом случае попытка выполнить DDoS второго устройства бессмысленна, и, как следствие, маловероятна.
То есть, (маленький тупой) рекурсивный сервер должен сначала пробовать выполнять DNS-запрос с использованием UDP, но при высокой вероятности большого и усеченного ответа, либо при наличии открытой TCP-сессии к запрашиваемому серверу (по которому обрабатывается другой запрос или запрос другого клиента), не возбраняется использование TCP.
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
DNS-туннелирование превращает систему доменных имён в оружие хакеров. DNS – это, по сути, огромная телефонная книга интернета. А ещё DNS является базовым протоколом, позволяющим администраторам делать запросы в базу данных DNS-сервера. Пока вроде всё понятно. Но хитрые хакеры осознали, что можно скрытно общаться с компьютером-жертвой путём внедрения управляющих команд и данных в протокол DNS. Эта идея и лежит в основе DNS-туннелирования.
Как работает DNS-туннелирование
Для всего в интернете есть свой отдельный протокол. И DNS поддерживает относительно простой протокол типа запрос-ответ. Если вы хотите посмотреть, как он работает, то можете запустить nslookup – основной инструмент для подачи DNS-запросов. Вы можете запросить адрес, просто указав интересующее доменное имя, например:
В нашем случае протокол ответил IP-адресом домена. В терминах DNS-протокола, я сделал запрос адреса или запрос т.н. «А»-типа. Существуют и другие типы запросов, при этом DNS-протокол будет отвечать с различным набором полей данных, которыми, как мы это позже увидим, могут воспользоваться хакеры.
Предположим, злоумышленник управляет DNS-сервером. Тогда он может передавать данные — например, персональные данные, — и не обязательно будет обнаружен. В конце концов, с чего вдруг DNS-запрос может стать чем-то нелегитимным?
«Туннелирующая» часть данной атаки заключается в сокрытии данных и команд от обнаружения системами мониторинга. Хакеры могут использовать наборы символов base32, base64 и т.д., или даже шифровать данные. Такая кодировка пройдёт незамеченной мимо простых утилит обнаружения угроз, которые осуществляют поиск по открытому тексту.
И это и есть DNS-туннелирование!
Выявление DNS-туннелирования
Существует два основных метода обнаружения злоупотреблением DNS: анализ нагрузки и анализ трафика.
При анализе нагрузки защищающаяся сторона ищет аномалии в данных, передаваемых в обе стороны, которые могут быть обнаружены статистическими методами: странно выглядящие имена хостов, тип DNS записи, которая не используется настолько часто, или нестандартная кодировка.
Утилиты DNS-туннелирования
Если вы хотите провести собственный пентест и проверить, насколько хорошо ваша компания сможет обнаружить и отреагировать на такую активность, то для этого есть несколько утилит. Все они умеют туннелировать в режиме IP-Over-DNS:
-
– доступна на многих платформах (Linux, Mac OS, FreeBSD и Windows). Позволяет установить SSH-шелл между целевым и управляющим компьютером. Вот неплохой гайд по настройке и использованию Iodine. – проект DNS-туннелирования от Дэна Каминского, написанный на Perl. С ним можно подключаться по SSH. – «DNS-туннель, от которого не тошнит». Создаёт зашифрованный C2-канал для отправки/скачивания файлов, запуска шеллов и т.д.
проверяем
Запускаем наш скрипт
Проверяем работу скрипта командой
На этот раз без '-vc' так так мы уже написали и запустили прокси который заворачивает UDP DNS запросы в TCP тунель.
Если всё нормально можно указать в настройках соедидения как DNS сервер "127.0.0.1"
Риски, связанные с DoH
DNS over TLS (DoT)
В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS ( RFC 7858 , Раздел 3.1 ).
Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.
Обеспечение видимости и контроля трафика DoT
В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:
• Настройте NGFW для расшифровки всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
Новое поколение межсетевых экранов удобнее и безопаснее, благодаря новой архитектуре движка и новой идеологии управления сетевыми потоками.
L7 firewall проверяет содержимое поля данных, L4 firewall нет
Основная проблема, с которой мы боремся, что сейчас программы сразу пишут так, чтобы они обходили защиту L4 firewall.
У разработчиков есть термин User Experience – у клиента после установки загорелся Skype зелененьким = клиент счастлив. А то, что Skype прошел периметр компании нелегально по соединению, которое было открыто для работы только браузера по портам TCP/80 и 443 – L4 firewall игнорирует, потому что это не его задача смотреть в содержимое пакетов — ему важны лишь в их заголовки.
Утилиты DNS-мониторинга
Ниже представлен список нескольких утилит, который будет полезен для обнаружения туннелирующих атак:
Почему появилась эта статья?
Неоднократно приходил к коллегам-безопасникам, которые пользуются межсетевым экраном нового поколения и видел, что они продолжают писать правила по номерам портов. На мое предложение перейти писать по имени приложений, слышал «А вдруг так не заработает?». Если вам тоже «страшно» или непонятно зачем писать правила по приложениям, от эта статья для вас.
Какие новые проблемы создает новый подход к написанию правил по L7
Нужно понимать, что определение приложения по контенту пакета очень нагружает процессора L7 firewall. Если обычный L4 firewall проверял только несколько байт заголовка TCP пакета и затем остальные мегабайты flash ролика пропускал без проверки, то L7 firewall должен считывать все что хранится в поле данных TCP/IP и постоянно проверять что за контент находится внутри соединения TCP/IP, вдруг оно изменилось или несет угрозу для компании. Поэтому, когда появился такой функционал, как анализ контента, то все устройства стали тормозить. Поэтому для анализа контента нужны более мощные устройства.
Обеспечение видимости и контроля трафика DoH
Настраиваем Stunnel
- Скачиваем корневой сертификат Root-R2.crt в директорию с конфигом Stunnel
- Конвертируем сертификат в PEM
Пишем в stunnel.conf:
То есть Stunnel:
- примет не шифрованное TCP по адресу 127.0.0.1:53
- откроет шифрованный TLS туннель до адреса 8.8.8.8:853 (Google DNS)
- будет передавать данные туда и обратно
Работу тунеля можно проверить командой:
Опция '-vc' заставляет nslookup использовать TCP соединение к DNS серверу вместо UDP.
Риски, связанные с DoT
Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях , при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.
Настраиваем Stunnel
- Скачиваем корневой сертификат Root-R2.crt в директорию с конфигом Stunnel
- Конвертируем сертификат в PEM
Пишем в stunnel.conf:
То есть Stunnel:
- примет не шифрованное TCP по адресу 127.0.0.1:53
- откроет шифрованный TLS туннель до адреса 8.8.8.8:853 (Google DNS)
- будет передавать данные туда и обратно
Работу тунеля можно проверить командой:
Опция '-vc' заставляет nslookup использовать TCP соединение к DNS серверу вместо UDP.
заключение
Теперь наши DNS запросы под защитой TLS.
Микро FAQ по DNS-туннелированию
В: Что такое туннелирование?
О: Это просто способ передачи данных поверх существующего протокола. Лежащий в основе протокол обеспечивает выделенный канал или туннель, который потом используется для сокрытия информации, передающейся в действительности.
В: Когда был осуществлена первая атака по DNS-туннелированию?
О: Мы не знаем! Если вы знаете – дайте, пожалуйста, нам знать. Насколько нам известно, первое обсуждение атаки было инициировано Оскаром Пирсаном в почтовой рассылке Bugtraq в апреле 1998 года.
Хотите, чтобы мы помогли с обнаружением DNS-туннелирования? Ознакомьтесь с нашим модулем Varonis Edge и попробуйте бесплатное демо!
Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Одной из областей, которой часто не уделяется должного внимания, является DNS. Контролируете ли вы свой DNS трафик?
Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.
Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.
Что такое зашифрованный DNS?
Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или перехвата и перенаправления в нежелательные пункты назначения. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. В частности, зашифрованные протоколы DNS защищают от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.
Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.
Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.
История атак через DNS-туннелирование
У всего есть начало, включая идею захвата DNS-протокола для хакерских целей. Насколько мы можем судить, первое обсуждение такой атаки проводилось Оскаром Пирсаном (Oskar Pearson) в почтовой рассылке Bugtraq в апреле 1998 года.
К 2004 году, DNS-туннелирование было представлено на Black Hat как хакерский метод в презентации Дэна Каминского (Dan Kaminsky). Таким образом, идея очень быстро переросла в настоящий инструмент атаки.
На сегодня DNS-туннелирование занимает уверенные позиции на карте потенциальных угроз (и блогеров в сфере информационной безопасности часто просят его объяснить).
Слышали ли вы о Sea Turtle ? Это действующая кампания киберпреступных группировок — скорее всего, спонсируемая государством, — направленная на захват легитимных DNS-серверов с целью перенаправления DNS-запросов на собственные сервера. Это означает, что организации будут получать «плохие» IP-адреса, указывающие на поддельные веб-страницы под управлением хакеров, — например, Google или FedEx. При этом злоумышленники смогут заполучить учётные записи и пароли пользователей, которые те неосознанно введут их на таких поддельных сайтах. Это не DNS-туннелирование, но просто ещё одно скверное последствие контроля DNS-серверов хакерами.
L7 Firewall удобнее
Если посмотреть на процесс обучения сетевых инженеров, то чаще всего люди, проходят курсы известной компании-производителя сетевого оборудования и это дает хорошее знание технологий работы сетей.
Свежеиспеченному сетевому специалисту может показаться, что все можно сделать правилами на транспортном уровне, где нужно лишь разрешить нужный протокол и порт. Нужно разрешить браузер в Интернет? Открываем TCP/80. Нужно открыть DNS? Открываем TCP/53 или UDP/53. Нужно открыть RDP? Открываем TCP/3389. И написание правил на L4 firewall становится стандартом в компании.
Надо сказать, что многие ИТ специалисты в курсе про понятие statefull inspection. Но одновременно для многих является откровением, что разные firewall поддерживает satefull inspection для разного набора приложений. У меня есть определенная статистика, поскольку работал преподавателем курсов по Firewall в учебном центре компании Информзащита. Что же я вижу? Кто-то думает, что statefull inspection – это только про разрешение принимать обратно ответы протоколов TCP/UDP/ICMP. А как быть с более сложными приложениями? Например, как отследить два TCP соединения, которые делает протокол FTP на 21 и 20 порты — они зависят друг от друго? Там нужно не просто принимать ответ, так еще и второе соединение разрешать в зависимости от команды PORT внутри управляющего соединения на 21 порту. А сколько еще команд на открытие новых соединений внутри себя дают приложения? Резюмируя, в сетях сейчас используются и обычные access list, которые не понимают команду PORT внутри FTP протокола, и есть L4 firewall, которые разбирают команду PORT и автоматически открывают нужный порт, есть кто пошел дальше и смотрит в более сложные команды протоколов MS RPC или ICS/SCADA протоколов. Но все возможные приложения L4 firewall не смотрит и эти firewall тоже в общем-то отличаются количеством реализованных внутри Application Layer Gateway (ALG).
К чему я клоню? Убежденность, что достаточно помнить основные порты TCP/UDP – не работает.
В мире уже несколько тысяч приложений и все они пользуются компьютерными сетями. И никакой сетевой инженер не в состоянии помнить все эти порты.
Откровением для сетевых инженеров являются задачи открыть порты для приложения посложнее, например, VNC. Никто не помнит какие там порты и приходится уже использовать google.
При публикации первой части я провел опрос и вижу, что до сих пор люди готовы запоминать номера портов — мнения разделились 50 на 50: кто-то ответил, что готов помнить все 4 порта приложения VNC.
Пожалуй рекордсменом по числу портов является Lync (он же Skype for Business). Около 40 портов. Реально ли их запомнить?
Если вы заглянете в Microsoft TechNet, где описано, какие порты нужно открыть, то хочется написать правило permit any to any, потому что там порядка 40 портов и часть из них должны открываться динамически. А это катастрофически неудобно прописывать в L4 firewall.
Получается, что сетевому инженеру удобнее писать в правилах приложения L7 и нужно, чтобы firewall сам автоматически открывал нужные порты.
Нужно открыть VNC? Пишешь в правиле слово VNC и уже firewall понимает какие протоколы нижележащие нужно открыть. Это ведь удобно.
Пример. Отчет NGFW по отдельным категориям трафика.
В среднем доступом в Интернет из корпоративной сети пользуется 200-300 приложений. Межсетевой экран уровня приложений показывает какие это приложения и может эти приложения фильтровать для всех или для конкретных пользователей и фильтровать файлы по типам или контенту, которые идут в разрешенных приложениях у всех пользователей корпоративной сети. Также не забываем что в NGFW, параллельно работают функции безопасности: IPS, антивирус, anti-spyware, URL фильтр, DNS фильтр, Threat Intelligence и так далее. То есть мы не просто разрешаем приложения, а делаем это безопасно.
Содержание
Приложения изменились – изменился ли ваш firewall
Нужно анализировать содержимое передаваемых данных и именно по ним разбирать какое же приложение в данный момент использует это TCP соединение.
Приложения, использующие порт 80
Проблема многих средств защиты – игнорирование приложений на нестандартных портах
Перемещение стандартного приложения на нестандартный порт, тоже позволяет злоумышленнику уйти из-под контроля. Этот контроль восстанавливает только устройство, которое анализирует содержимое всего трафика, а не только заголовки.
Проблема L4 firewall: port-hopping (туннелирование)
Туннелирование неразрешенных приложений внутри разрешенных соединений – это стандартная картина в современных сетях. Естественно, хакеры пользуются тем же приемом: они создают туннели в разрешенных соединениях. А безопасники даже не в курсе.
Ограничения технологии анализа 7 уровня
L7 firewall требуется больше памяти для хранения состояния одного соединения, поэтому параметр «число одновременных соединений» у L7 firewall всегда ниже чем у L4 Firewall при одинаковом количестве оперативной памяти в обоих устройствах, причем значительно, раз в 10. Это уже объяснялось выше в разделе Statefull Inspection. И это цена за безопасность ваших приложений. Поэтому если вы сравниваете L4 и L7 инспекцию, то задавайте вопрос производителю как он измерял параметр «число одновременных сессий»: с включенной безопасностью на 7 уровне или с выключенной.
То же самое и с производительностью: процессор L4 firewall проверяет лишь несколько байт заголовка пакета и затем уже сами данные передает на скорости маршрутизации без проверки, а L7 firewall проверят и заголовок и все те мегабайты данных, которые содержатся в последующих пакетах соединения. А это уже совершенно другая работа. Поэтому такую работу нужно делать на специализированных для этого аппаратных платформах, где ускорен анализ приложений, ускорена работа потокового антивируса, ускорена работа IPS и других функций безопасности. Лучше всех в создании чипов для ускорения безопасности преуспела компания Cavium, чипами которой, например, пользуется компания Palo Alto Networks. Кроме того использование специализированных чипов FPGA(ПЛИС) позволяет прошивать сигнатуры антивируса и IPS в сам чип и проверка сигнатур идет на аппаратной скорости чипа FPGA. Сейчас даже у личных компьютеров есть ускорение графических функций на выделенных графических процессорах, так что использование чипов для ускорения безопасности — логичное развитие технологий.
Угрозы DNS-туннелирования
DNS-туннелирование – это как индикатор начала стадии плохих новостей. Каких именно? Мы уже рассказали о нескольких, но давайте их структурируем:
Читайте также: