Comments 22
То есть, таким образом можно идентифицировать, что происходит внутри VPN?
Что будет, если внутри VPN одновременно активно передают данные несколько приложений?
Что будет, если внутри VPN одновременно активно передают данные несколько приложений?
Если какое-то одно приложение передаёт заметно больше данных, чем все остальные, его теоретически можно будет выявить даже сквозь VPN. Если высокая активность у нескольких приложений, способ «в лоб» скорее всего не сработает, но всё равно можно попытаться что-то придумать и сделать какие-то выводы. К примеру, трафик HTTP имеет свойство передаваться всплесками, и если провести кластеризацию передаваемых пакетов во времени и скормить классификатору выявленные кластеры, вполне вероятно, что HTTP будет определён. Более равномерный трафик тоже можно как-нибудь вычленить как принадлежащий конкретному приложению — тут широкое поле для исследований.
UFO just landed and posted this here
Спасибо за дельные замечания, исправил введение.
Можете рассказать поподробнее про блокировки без DPI? Например, сайтов по спискам Роскомнадзора.
Можете рассказать поподробнее про блокировки без DPI? Например, сайтов по спискам Роскомнадзора.
UFO just landed and posted this here
Не смог промолчать! Так сказать на больную мозоль =)
Нужно:
Linux + quagga + iproute2
Реализация:
Две таблицы маршрутизации, в default один маршрут в интернет, в zapret заносим все ip адреса запрещенных ресурсов, маршрутом в null. Запускаем bgpd на таблице zapret, аннонсируем все на маршрутизатор. Теперь трафик запрещенных ресурсов падает к нам на сервер. На маршрутизаторе, помещаем ip адрес сервера в policy route (d'link аля), чтобы он имел доступ к интернету. На сервере настраиваем squid для http и mitmproxy для https. В сквиде делаем так чтобы source ip сохранялся абоненский (мы у себя забили). Как то так собственно.
Нужно:
Linux + quagga + iproute2
Реализация:
Две таблицы маршрутизации, в default один маршрут в интернет, в zapret заносим все ip адреса запрещенных ресурсов, маршрутом в null. Запускаем bgpd на таблице zapret, аннонсируем все на маршрутизатор. Теперь трафик запрещенных ресурсов падает к нам на сервер. На маршрутизаторе, помещаем ip адрес сервера в policy route (d'link аля), чтобы он имел доступ к интернету. На сервере настраиваем squid для http и mitmproxy для https. В сквиде делаем так чтобы source ip сохранялся абоненский (мы у себя забили). Как то так собственно.
Дело всё в том, что быстро определить протокол прикладного уровня по шаблону, коих могут быть тысячи — задача очень ресурсоёмкая.
А почему вы считайте Random Forest эффективным? С каждым новым классом сложность будет расти, а точность будет падать. Т.к. используется one vs rest, то считайте что для 100 классов у вас будет 100 отдельных моделей.
К тому же на реальной задаче 27 деревьев это очень мало, вы точность кросс-валидацией проверяли?
Ну и тренировать на данных, которые получены только от одного компьютера — неправильно.
Уверен, что на реальной задаче результаты будут совсем другими.
Спасибо, про эффективность я сгоряча. Переместил акценты во введении.
вы точность кросс-валидацией проверяли?Конечно, результаты примерно такие же (в посте я привёл лучшие результаты среди подвыборок).
Ну и тренировать на данных, которые получены только от одного компьютера — неправильно.Строго говоря, компьютеров было два и доступ в Интернет они получали по-разному (один даже через 3G + Wi-Fi), но я понимаю, что репрезентативность здесь низкая. Собирал там, где была возможность. Если можете посоветовать, где можно достать дампы трафика побольше и с разных точек, буду благодарен.
Не совсем понял, как используется forest у автора, но насколько я помню, у алгоритмов на основе деревьев решений вполне себе «естественная» поддержка мультиклассовой классификации, без использования one-vs-all
А есть ли ценность только в детекции типа трафика без его содержания? Думал-думал, но не очень понял — для чего это?
Для получения глобальной статистики канала или для действий по категориям: например, заблокировать торренты, или зажать их по скорости, а веб, наоборот, разжать. Впрочем, если вы скажете, что при нынешних скоростях это не так актуально, я с вами соглашусь.
UFO just landed and posted this here
Ну, например операторам большой тройки, резать канал, если идет скачка торентов, о чем зачастую написано в договоре.
Кроме всего выше перечисленного, это ещё и способ работать с шифрованным трафиком. Анализировать контент не получится, но вот понять хотя бы, что это за прикладной протокол — вполне.
В перспективе также можно придумать способ решать задачи, не решаемые при помощи DPI. Например, определять вредоносный трафик по таким вот характеристикам, не привязываясь к прикладному протоколу.
В перспективе также можно придумать способ решать задачи, не решаемые при помощи DPI. Например, определять вредоносный трафик по таким вот характеристикам, не привязываясь к прикладному протоколу.
Интересная идея, я как раз сейчас плотно занимаюсь DPI, блокировками сайтов и нейронными сетями, но объединить это в один проект не пришло в голову.
В свое время, когда внедрял библиотеку nDPI, мне было интересно — как быстро (за сколько пакетов) библиотека определит протокол. Так вот, там тоже количество невелико. Точное (среднее) количество уже не вспомню, но с тех пор у меня стоит ограничение на анализ первых 64 пакетов потока, и это с большим запасом. Если за 64 пакета nDPI не определил протокол, то скорее всего уже и не определит. А чаще всего определение происходит за первые несколько пакетов. И вот тут интересно — а что будет работать быстрее — nDPI с его анализом пакетов, или «обученная машина»? Я думаю, что nDPI все-таки пошустрее. К тому же, для nDPI нужно хранить меньше данных для каждого потока.
В свое время, когда внедрял библиотеку nDPI, мне было интересно — как быстро (за сколько пакетов) библиотека определит протокол. Так вот, там тоже количество невелико. Точное (среднее) количество уже не вспомню, но с тех пор у меня стоит ограничение на анализ первых 64 пакетов потока, и это с большим запасом. Если за 64 пакета nDPI не определил протокол, то скорее всего уже и не определит. А чаще всего определение происходит за первые несколько пакетов. И вот тут интересно — а что будет работать быстрее — nDPI с его анализом пакетов, или «обученная машина»? Я думаю, что nDPI все-таки пошустрее. К тому же, для nDPI нужно хранить меньше данных для каждого потока.
Тоже склоняюсь ко мнению, что nDPI будет быстрее.
А какие данные надо хранить для nDPI на один поток?
А какие данные надо хранить для nDPI на один поток?
Только самый минимум: src/dst IP, src/dst port, detected_protocol. Зависит, конечно, от конечной цели.
Ну так если мы делаем классификацию трафика «на месте», то точно такие же данные и после применения машинного обучения будут храниться. А вот если здесь и сейчас у нас нет DPI, но есть вероятность, что проанализировать трафик потребуется, то для nDPI придётся хранить по 64 пакета каждого потока. В случае применения машинного обучения, хранить надо только 256 байт на поток.
nDPI, насколько я понял его код (сильно глубоко не лез), анализирует пакеты вне контекста, то есть смотрит каждый пакет независимо от предыдущих. Поэтому ему не нужно хранить предыдущие пакеты — взял текущий, обработал, пошел дальше. при машинном обучении нужно хранить дополнительные данные, чтобы посчитать нужные параметры: средний размер пакета, количество пакетов и т.д. Впрочем, этих данных не много.
Вы меня извините, но DPI это и классификация потоков даннных и управление ими. Причем без управления, по большей части, нет потребности и в классификации.
Опять ж непонятно, в первой части статьи упоминается, что метод рассматривается как средство для классификации шифрованного трафика, но при том трафик рассматрвиается нешифрованный. При том, что шифрованный трафик имеет свое поведение и указанные метрики не применимы к нему.
Кстати, такой метод классификации трафика уже применяется в DPI (естественно вкупе с традиционными методами).
Опять ж непонятно, в первой части статьи упоминается, что метод рассматривается как средство для классификации шифрованного трафика, но при том трафик рассматрвиается нешифрованный. При том, что шифрованный трафик имеет свое поведение и указанные метрики не применимы к нему.
Кстати, такой метод классификации трафика уже применяется в DPI (естественно вкупе с традиционными методами).
Я и не замахивался на решение всех задач DPI (в начале статьи сказано — «одной из главных задач»).
Данная статья — это «proof of concept», что такое вообще возможно — определить прикладной протокол, не видя полезной нагрузки. Трафик поэтому рассматривается нешифрованный. Для работы с шифрованным трафиком метод придётся изменять, не спорю.
Данная статья — это «proof of concept», что такое вообще возможно — определить прикладной протокол, не видя полезной нагрузки. Трафик поэтому рассматривается нешифрованный. Для работы с шифрованным трафиком метод придётся изменять, не спорю.
Кстати, такой метод классификации трафика уже применяется в DPIКонечно, но в открытом доступе информации о таких технологиях я не нашёл. Данная статья — моё собсвенное исследование на тему.
Sign up to leave a comment.
Машинное обучение вместо DPI. Строим классификатор трафика