Здравствуйте, Rostov, Вы писали:

R>Каждый сеанс TCP или UDP с определенного IP — адреса, оценивать числом:
R>sess_id = Func(TTL, длительность сеанса, объем получ, объем переданной инф, текущего времени,и т.п)

R>Это вариант, для анализа сессий с определенных IP. Вопрос по этому направлению — непосредственно составление функции.
R>Теперь для общего случая. Подомным образом нужно анализировать трафик, поступаемый на наш компьютер (это и количество незакрытых сессиий и еще что-то подобное). С сигнатурами, связываться непосоветовали, т.к. уж слишком их много, и за появлением новых вирусов не уследишь.

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

Т.е. в Вашем случае я бы действовала примерно так:

1. Попыталась бы раздобыть traffic dumps с реальной сети. Посмотрела бы на них с помощью существующих IDS (хотя бы используя тот же Snort, на который Вам указали выше), tcpdump/Ethereal ну или чего Вам нравится, чтобы иметь приблизительное представление об аномальности траффика. Если вы пишете диплом для универа, в принципе симулятор какой-нибудь сгодится чтобы изготовить такой dump.

2. Подумала бы какие величины я бы хотела включить в данную функцию. Вроде я где-то видела статьи о распределении трафика по величине трансфера/длительности/другим параметрам, погуглите на эту тему. Имхо, хорошо было бы определиться какие параметры Вы точно хотите использовать (например, протокол, процент успешных соединений с данного IP), а какие можно и опустить, если они не будут улучшать модель.

3. Посмотрела бы какие параметры для функции работают для данного traffic dump. Это, конечно, много экспериментов, подгонки и т.д.

Кстати, разделите свой traffic dump на две части — одну для тренировки своей модели, другую для предсказания аномальности. Тогда Ваша модель/функция будет работать на второй части. Если Вы попытаетесь тестировать свою функцию на каком-то несвязанном dump, учтите что скорее всего ничего работать не будет, по крайней мере наладить все это будет гораздо сложнее. Но это скорее совет из серии как лучше написать диплом, а не как делать original research

Здравствуйте!

Необходимо создать приложение, реализующее анализ входящих всех пакетов и выявляющее подозрительные.
Т.е., к примеру, с определенного IP получаем серию пакетов с одинаковыми (или близкими значениями) TTL и, вдруг,
один с сильно отличающимся. Где можно почитать, про характерные признаки группы сетевых пакетов?

Спасибо.

Здравствуйте, Rostov, Вы писали:

R>Здравствуйте!

R>Необходимо создать приложение, реализующее анализ входящих всех пакетов и выявляющее подозрительные.
R>Т.е., к примеру, с определенного IP получаем серию пакетов с одинаковыми (или близкими значениями) TTL и, вдруг,
R>один с сильно отличающимся. Где можно почитать, про характерные признаки группы сетевых пакетов?

R>Спасибо.

Ага типа кул Network Intrusion Detection System
Читать нужно в первую очередь rfc по соответствующим протоколам.
Когда был студентом этим занимался, но откровенно говоря
у меня не получилось написать работоспособного приложения.
В сети такое огромное кол-во всевозможных пакетов, и
выделить из шума нужную информацию пробламатично оказалось.
Да и сам по себе tcp/ip стэк несет маловато информации.
ИМХО, максимум, что можно сделать — определить сканирование портов,
DOS и DDOS атаки.
Хотя опять же, все зависит от того, что вам нужно...

Rostov wrote:

> Т.е., к примеру, с определенного IP получаем серию пакетов с одинаковыми (или близкими значениями) TTL и, вдруг,
> один с сильно отличающимся.

Просто пакеты пошли по другому маршруту — какой-то роутер распределяет нагрузку — обычное дело...

--
Maxim Yegorushkin

Это понятно. Положим определить какое-нибудь допустимое отклонение и если будет превышение, то помечать пакет как ПОДОЗРИТЕЛЬНЫЙ, который нужно посмотреть аналитику.

Здравствуйте, MaximE, Вы писали:

ME>Rostov wrote:

>> Т.е., к примеру, с определенного IP получаем серию пакетов с одинаковыми (или близкими значениями) TTL и, вдруг,
>> один с сильно отличающимся.

ME>Просто пакеты пошли по другому маршруту — какой-то роутер распределяет нагрузку — обычное дело...

ME>--
ME>Maxim Yegorushkin

Здравствуйте, Rostov, Вы писали:

R>Здравствуйте!

Сам в свое время ковырялся по работе с этим... но ИМХО стандартный
анализ, как его себе представляют не сильно нужен. Все равно вирусы/хацкеры
работают по стандартным протоколам и поймать на массвом пинге/кривых пакетах
можно только простеньких вирусов или хацкеров-ламеров .

Вот тут более интересный подход:
http://plusik.pohoda.cz/thesis

Действительно интересный. ТОлько, насколько я понял, для опознавания опасных процессов использовались признаки работы файловой системы (запись, удаление, доступ к файлам другого владельца). Вот бы выделить что-то подобное для сетевых сеансов. Положим, для кажого IP адреса, завести
функцию от IP-адреса,времени сеанса, объема посланных данных, полученных, длительности сеанса, значений некоторых полей заголовков пакетов (TTL,...), и так далее для более качественного идентифицирования сессиии объявить её так, что при близких значениях параметров — её значение должны быть так же близкими.
Здравствуйте, aka50, Вы писали:




A>Здравствуйте, Rostov, Вы писали:

R>>Здравствуйте!

A>Сам в свое время ковырялся по работе с этим... но ИМХО стандартный
A>анализ, как его себе представляют не сильно нужен. Все равно вирусы/хацкеры
A>работают по стандартным протоколам и поймать на массвом пинге/кривых пакетах
A>можно только простеньких вирусов или хацкеров-ламеров .

A>Вот тут более интересный подход:
A>http://plusik.pohoda.cz/thesis

Здравствуйте! Может будут еще идеи по какому принципу анализировать группу пакетов?


Здравствуйте, aka50, Вы писали:

A>Здравствуйте, Rostov, Вы писали:

R>>Здравствуйте!

A>Сам в свое время ковырялся по работе с этим... но ИМХО стандартный
A>анализ, как его себе представляют не сильно нужен. Все равно вирусы/хацкеры
A>работают по стандартным протоколам и поймать на массвом пинге/кривых пакетах
A>можно только простеньких вирусов или хацкеров-ламеров .

A>Вот тут более интересный подход:
A>http://plusik.pohoda.cz/thesis

Здравствуйте, Rostov, Вы писали:


R>Действительно интересный. ТОлько, насколько я понял, для опознавания опасных процессов использовались признаки работы файловой системы (запись, удаление, доступ к файлам другого владельца). Вот бы выделить что-то подобное для сетевых сеансов. Положим, для кажого IP адреса, завести
R>функцию от IP-адреса,времени сеанса, объема посланных данных, полученных, длительности сеанса, значений некоторых полей заголовков пакетов (TTL,...), и так далее для более качественного идентифицирования сессиии объявить её так, что при близких значениях параметров — её значение должны быть так же близкими.
R>Здравствуйте, aka50, Вы писали:

А если посмотреть как это сделано в какой нибудь IDS... snort (http://www.snort.org/) например.

Спасибо за ответ, но SNORT организован на принципе сигнатур, т.е. один пакет рассматривают как структуру для анализа, мне нужно анализировать такие признаки, обладающие свойством: по одному пакету ничего нельзя сказать, по группе (сеансу) можно. Т.е., к примеру, у одного пакета из сесии — TTL=10 у остальных 63. Нужны подобные признаки, по которым можно выделить пакет из потока.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Rostov, Вы писали:


R>>Действительно интересный. ТОлько, насколько я понял, для опознавания опасных процессов использовались признаки работы файловой системы (запись, удаление, доступ к файлам другого владельца). Вот бы выделить что-то подобное для сетевых сеансов. Положим, для кажого IP адреса, завести
R>>функцию от IP-адреса,времени сеанса, объема посланных данных, полученных, длительности сеанса, значений некоторых полей заголовков пакетов (TTL,...), и так далее для более качественного идентифицирования сессиии объявить её так, что при близких значениях параметров — её значение должны быть так же близкими.
R>>Здравствуйте, aka50, Вы писали:

А>А если посмотреть как это сделано в какой нибудь IDS... snort (http://www.snort.org/) например.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте! Может будут еще идеи по какому принципу анализировать группу пакетов?


Можно смотреть на флаги, на TTL, на timeout между пакетами, на протоколы, на последовательность портов. Еще имеет смысл проанализировать, если пакеты заканчиваются соединением или нет — т.е. если видите кучу пакетов на различные порты, которые пытаются открыть соединение, это настораживает, тогда как пакеты по текущему TCP соединению, например, выглядят нормально. Это все проще делать на network, конечно, а не на отдельно стоящем компе.

Потом например у nmap есть несколько стандартных тестов, можно написать фильтр для них, пытаться их выследить. Добавить signatures для популярных/известных червей. Ну и т.д. до бесконечности. Но опять-таки, как Вам справедливо заметили раньше, чаще всего это выявляет т.н. script kiddies, а не серьезных хакеров.

Я бы посоветовала пойти на сайты MIT, Berkeley, CAIDA, еще парочки других учреждений, посмотреть какие у них есть публикации по этому поводу, и отобрать, что Вам подходит, если Вы еще этого не сделали.

Опять-таки, существует проблема keeping state — т.е. с одной стороны, хочется хранить как можно больше инфо о пакетах/соединениях, с другой стороны — в real-time анализ при большом кол-ве инфо сделать сложно, да и легко это все обойти при желании. Об этом я бы тоже хорошенько подумала когда работала бы над своим алгоритмом.

А зачем Вам, если не секрет?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте! Может будут еще идеи по какому принципу анализировать группу пакетов?

Вы бы не могли подробнее рассказать, что вы хотите получить в результате,
какие цели?
Так как "выявление подозрительных пакетов" звучит несколько расплывчато.

Спасибо за ответы. Данный вопрос — тема диплома.
Есть такая идея, она появилась после изучения статьи в одном из ответов этой ветки.
Каждый сеанс TCP или UDP с определенного IP — адреса, оценивать числом:
sess_id = Func(TTL, длительность сеанса, объем получ, объем переданной инф, текущего времени,и т.п)
Таким образом, для каждого IP, имея несколько сеансов в архиве — сформировать такую функцию
(допустим, Ip1 утром почти не выходит в Интернет, в основном после 20-00. Другой Ip2 наоборот только с 5-10.
Потом, первый в основном занитмается простым серфингом (трафик относительно небольшой), второй — скачивает музыку (обратная картина).
Т.о. для IP1 значение функции, например, сегодня 1025, завтра 1100, после 978, и вдруг 100 (т.е. большой объем, другие TTL, или еще что-то).
Поэтому на текущий сеанс следует обратить внимание.
Это вариант, для анализа сессий с определенных IP. Вопрос по этому направлению — непосредственно составление функции.
Теперь для общего случая. Подомным образом нужно анализировать трафик, поступаемый на наш компьютер (это и количество незакрытых сессиий и еще что-то подобное). С сигнатурами, связываться непосоветовали, т.к. уж слишком их много, и за появлением новых вирусов не уследишь.

Здравствуйте, Rostov, Вы писали:

R>[skipped]

1. Воспользуйтесь поиском в google по ключевым словам:
IDS, NIDS, Network Intrusion Detection System. Тема
интересная и статей должно быть много.

2. Что касается составления функции...
Можно пойти следующим путем: рассматривать все ваши
характеристики, как случайные величины. Тогда можно
сказать, что сессия — это случайный вектор
Ф = (ф1, ф2,..фn). А ваша характеристическая функция
будет иметь смысл плотности вероятности 0<=Р(Ф)<=1.
Затем определяете некое пороговое значение а, такое
что если Р(Ф) <= а — подозрительно, если P(Ф) > a —
все нормально.
Осталось определить плотность распределения(она может
быть разной для различных сетей). Таким образом первое
время ваша система должна пройти некий период обучения,
в течении которого будет формироваться выборка Ф.
Да, и вот что, в аналитическом виде вы не сможете
получить плотность распределения... Дальше читайте
мат статистику. Один из самых простых вариантов
подсчета Р — байесовские сети(поищите в google — они
много где используются).