Перейти к содержимому
Калькуляторы

FastNetMon - программа для выявления входящих/исходящих атак

Ответить

Evolution23   

Evolution23
Опубликовано · Жалоба

Если IP и там и там реальные, то в целом перехват работает. Сортирует в списках он по числу полученных пакетов, то есть он что-то ловит (достаточное для появления в списке - список я не инициализирую заранее), но очень мало (недостаточно для подсчета реальных скоростей).

 

Попробуйте раскомментировать строку 869:

cout<<"Dump: "<<print_simple_packet(current_packet);

 

Тогда он начнет печатать все пакеты, которые фиксирует. Возможно, это прояснит ситуацию. Он как раз напечатает протокол, направление и размер пакета.

окей, как буду дома - проверю.

Кстати, у нас в сети Download в разы больше Upload'а. ( скачивают много, а отдают мало) Так что может быть действительно Upload слишком мал.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Возможно, дамп пакетов даст ответ на этот вопрос :) Если он их видит, но их правда мало - моя правда. Иначе придется искать траблу и отлаживать.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Сделал.

 

Запустил команду:

./fastnetmon eth2,eth3 | grep -v "unknown" | grep "> 10.х."

чтобы выцепить нужные строки.

И увидел странную фигню. Дело в том, что такие данные есть, но там в качестве source встречаются только мои же сетки. А данных о пакетах, приходящих извне - нет.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

А можете проверить, правильно ли входящий трафик (который монитор считает) определяется прокачав что-то самостоятельно и посмотрев на известный узел? Ну либо можете hping ом устроить мини ддос.

 

У меня подозрение, что проблема со смещением начала пакета. Оно временами меняется для разных типов систем/интерфейсов и как сторонний эффект - будут битые и некорректные IP в обоих направлениях.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

У меня вот такой код съема vlan тегов первого уровня:

if ( ntohs(eptr->ether_type) ==  VLAN_ETHERTYPE ) {
       // это тегированный трафик, поэтому нужно отступить еще 4 байта, чтобы добраться до данных
       packetptr += DATA_SHIFT_VALUE + VLAN_HDRLEN;
   } else {
       // Skip the datalink layer header and get the IP header fields.
       packetptr += DATA_SHIFT_VALUE;
   }

 

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

А можете проверить, правильно ли входящий трафик (который монитор считает) определяется прокачав что-то самостоятельно и посмотрев на известный узел? Ну либо можете hping ом устроить мини ддос.

 

У меня подозрение, что проблема со смещением начала пакета. Оно временами меняется для разных типов систем/интерфейсов и как сторонний эффект - будут битые и некорректные IP в обоих направлениях.

Могу, но, к сожалению уже только завтра. У меня нет из дома доступа к железке, которой бы нынешняя тестовая машина служила бы шлюзом.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

BETEPAH   

BETEPAH
Опубликовано (изменено) · Жалоба

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

обрабываете через PF_RING или ULOG?

А смысл давать внешний интерфейс, если ip адрес уже не соответствуют серой подсети, что прописана в /etc/networks_list?

Скомпилил по инструкции PF_RING, скачал уже скомпиленный бинарник fastnetmon и запустил немного опасаясь на продакшене, но отработало нормально в течении минут 3, дальше не тестил.

Виланов на внутреннем интерфейсе нет. Бондингов нет.

Изменено пользователем BETEPAH

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Могу кстати сделать, чтобы бинарик работал не от рута, чтобы было не так страшно :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

У меня вот такой код съема vlan тегов первого уровня:

if ( ntohs(eptr->ether_type) ==  VLAN_ETHERTYPE ) {
       // это тегированный трафик, поэтому нужно отступить еще 4 байта, чтобы добраться до данных
       packetptr += DATA_SHIFT_VALUE + VLAN_HDRLEN;
   } else {
       // Skip the datalink layer header and get the IP header fields.
       packetptr += DATA_SHIFT_VALUE;
   }

 

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

Есть подозрение что именно в этом дело, наверняка бонд для работы добавляет что-то в пакеты данных.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Сделал из собранного на тестовой машине pf_ring deb пакет и поставил-таки на машине из-под которой сам сижу в интернете.

После чего закинул туда же уже скомпиллированный fastnetmon и запустил.

Показывало размер пакета 40, но wireshark на моем ПК при этом показывал размер пакета - 54 (на отдачу) и 1464 (на прием).

Так что в любом случае считается как-то странно.

Еще заметил следующую картину, когда убрал grep с того, что выводит скрипт.

 

Dump: 8.0.69.0:46292 > 5.220.118.202:56567 protocol: unknown size: 10536 bytes
Dump: 10.198.115.63:2052 > 95.142.205.58:80 protocol: tcp size: 40 bytes
Dump: 8.0.69.0:2052 > 5.200.55.220:80 protocol: unknown size: 2890 bytes
Dump: 8.0.69.0:2052 > 5.220.156.39:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:2052 > 5.220.160.16:80 protocol: unknown size: 11996 bytes
Dump: 8.0.69.0:2052 > 5.220.156.40:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:2052 > 5.220.156.41:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:2052 > 5.220.156.45:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:49754 > 5.220.156.46:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:49754 > 5.220.156.47:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:49754 > 5.220.156.48:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:49754 > 5.220.156.49:80 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:49754 > 5.220.156.50:80 protocol: unknown size: 15078 bytes
Dump: 10.198.113.22:52267 > 92.50.241.14:1940 protocol: tcp size: 40 bytes
Dump: 8.0.69.0:52267 > 5.220.156.55:1940 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:52267 > 5.220.156.56:1940 protocol: unknown size: 15078 bytes
Dump: 8.0.69.0:52267 > 5.200.55.221:1940 protocol: unknown size: 2890 bytes
Dump: 8.0.69.0:52267 > 5.220.35.46:1940 protocol: unknown size: 60727 bytes
Dump: 10.198.115.62:6143 > 109.163.245.225:26248 protocol: udp size: 76 bytes
Dump: 10.198.116.147:53607 > 88.212.196.122:80 protocol: tcp size: 498 bytes
Dump: 8.0.69.0:53607 > 5.220.14.88:80 protocol: unknown size: 19795 bytes
Dump: 8.0.69.0:53607 > 5.220.14.89:80 protocol: unknown size: 19795 bytes
Dump: 8.0.69.0:53607 > 5.220.14.90:80 protocol: unknown size: 19795 bytes
Dump: 8.0.69.0:53607 > 5.220.14.91:80 protocol: unknown size: 19795 bytes
Dump: 10.198.142.17:1042 > 81.61.30.245:60397 protocol: udp size: 145 bytes
Dump: 8.0.69.0:1042 > 5.200.55.223:60397 protocol: unknown size: 2890 bytes
Dump: 8.0.69.0:1042 > 0.135.9.92:60397 protocol: unknown size: 34075 bytes
Dump: 8.0.69.0:1042 > 5.173.119.107:60397 protocol: unknown size: 4179 bytes
Dump: 8.0.69.0:1042 > 5.220.118.206:60397 protocol: unknown size: 10536 bytes
Dump: 8.0.69.0:1042 > 5.220.118.207:60397 protocol: unknown size: 10536 bytes
Dump: 10.198.143.14:30227 > 92.55.50.94:30056 protocol: udp size: 1450 bytes
Dump: 8.0.69.0:58364 > 5.220.147.26:445 protocol: unknown size: 50599 bytes
Dump: 10.198.142.17:1042 > 85.10.192.175:34122 protocol: udp size: 145 bytes
Dump: 10.198.127.42:50352 > 95.142.205.53:80 protocol: tcp size: 64 bytes
Dump: 10.198.127.42:50352 > 95.142.205.53:80 protocol: tcp size: 64 bytes

 

То есть те записи, которые имеют protocol: unknown имеют вообще необъяснимые айпи и на вход, и на выход О_О

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Да, скорее всего трабла со смещением. У меня есть машина с бондингом, попробую настроить перехват.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Да, скорее всего трабла со смещением. У меня есть машина с бондингом, попробую настроить перехват.

Спасибо большое, если будет нужна дополнительная диагностика - пишите.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

По поводу запуска без root привилегий - вполне хватает возможности cap_net_admin:

useradd fastnetmon
setcap cap_net_admin+eip fastnetmon
chown fastnetmon:fastnetmon /var/log/fastnetmon.log 
su fastnetmon
./fastnetmon eth0,eth1

 

На Debian 7 завелось влет, а вот на CentOS 6 трафик увидело (то есть PF_RING заработал), но вот отправило весь трафик в other. Если кому не лень - протестируйте, пожалуйста :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Добавил в код функцию дампа всех пакетов, которые видит анализатор, и обновил статическую версию:

DUMP_ALL_PACKETS=1 ./fastnetmon eth0

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Evolution23, еще просьба. Возьмите, пожалуйста, новый код и снимите коммент на строке:

842         // printf("Packet with non standard ethertype found: 0x%x\n", ntohs(eptr->ether_type));

 

И после этого запустите анализатор в режиме:

DUMP_ALL_PACKETS=1 ./fastnetmon eth0

 

У меня такие подозрения, что дело не только в смещении. Поймал у себя определенный процент пакетов, которые идут с совершенно неадекватными ethrtype:

Packet with non standard ethertype found: 0xb23f
Packet with non standard ethertype found: 0xb23f
Packet with non standard ethertype found: 0x0
Packet with non standard ethertype found: 0xb23f
Packet with non standard ethertype found: 0xb23f
Packet with non standard ethertype found: 0xb23f
Packet with non standard ethertype found: 0x0
Packet with non standard ethertype found: 0x0
Packet with non standard ethertype found: 0xb23f

 

То есть это уже по каким-то причинам сразу идут битые Ethernet фреймы с уже кривыми ethertype. Данный трейс взят с обычной машины с OpenVZ. Ушел в раздумья скорее всего до будней.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба 

/usr/src/fastnetmon# DUMP_ALL_PACKETS=1 ./fastnetmon eth2,eth3|grep ethertype
Dumping statistics on /proc/net/pf_ring/stats/
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000
Packet with non standard ethertype found: 0x9000

 

Как-то так.

 

Иногда еще проскакивает не 0x9000, а 0x8809

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано (изменено) · Жалоба

Нифигасебе блин. Если верить трейсу, у Вас почти весь трафик:

0x8809 - Slow Protocols (IEEE 802.3)

0x9000 - Ethernet_Configuration_Testing_Protocol

 

Честно говоря я даже не представляю откуда это и как это вышло. Появилась некоторая идея. Оказывается, можно из самого PF_RING выдернуть результаты парсинга пакета.

Изменено пользователем pavel.odintsov

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Нифигасебе блин. Если верить трейсу, у Вас почти весь трафик:

0x8809 - Slow Protocols (IEEE 802.3)

0x9000 - Ethernet_Configuration_Testing_Protocol

 

Честно говоря я даже не представляю откуда это и как это вышло. Появилась некоторая идея. Оказывается, можно из самого PF_RING выдернуть результаты парсинга пакета.

Ну это не весь трафик, я ж просто grep ethertype сделал) Там было слишком много всего и я отсеял все кроме строк с "Packet with non standard ethertype found:"

 

Если не использовать grep [и в этой куче пакетов раз в 2-3 секунды проскакивает "Packet with non standard ethertype found: 0x9000" и еще реже "Packet with non standard ethertype found: 0x8809"]

Dump: 8.0.69.0:52094 > 5.220.141.73:51413 protocol: unknown size: 12726 bytes
Dump: 8.0.69.0:52094 > 5.220.141.75:51413 protocol: unknown size: 12726 bytes
Dump: 10.198.50.41:13512 > 95.27.88.114:60294 protocol: udp size: 48 bytes
Dump: 8.0.69.0:44488 > 5.220.141.69:80 protocol: unknown size: 12726 bytes
Dump: 8.0.69.0:44488 > 5.220.141.70:80 protocol: unknown size: 12726 bytes
Dump: 8.0.69.0:44488 > 5.220.141.72:80 protocol: unknown size: 12726 bytes
Dump: 8.0.69.0:44488 > 5.220.141.74:80 protocol: unknown size: 12726 bytes
Dump: 8.0.69.0:44488 > 5.220.141.76:80 protocol: unknown size: 12726 bytes
Dump: 10.198.42.117:29870 > 188.235.75.34:61765 protocol: udp size: 48 bytes
Dump: 8.0.69.0:29870 > 5.134.4.83:61765 protocol: unknown size: 26335 bytes
Dump: 8.0.69.0:29870 > 5.220.226.230:61765 protocol: unknown size: 12035 bytes
Dump: 8.0.69.0:29870 > 5.220.226.231:61765 protocol: unknown size: 12035 bytes
Dump: 8.0.69.0:29870 > 5.134.4.84:61765 protocol: unknown size: 26335 bytes
Dump: 8.0.69.0:29870 > 5.186.39.55:61765 protocol: unknown size: 35988 bytes
Dump: 8.0.69.0:44488 > 0.40.160.152:80 protocol: unknown size: 58976 bytes
Dump: 10.198.42.29:52094 > 109.248.70.254:51413 protocol: tcp size: 1492 bytes
Dump: 10.198.42.117:29870 > 188.235.75.34:61765 protocol: udp size: 48 bytes
Dump: 8.0.69.0:29870 > 5.220.85.1:61765 protocol: unknown size: 45699 bytes
Dump: 8.0.69.0:44488 > 5.220.226.232:80 protocol: unknown size: 12035 bytes
Dump: 10.198.44.92:58813 > 37.110.40.246:33989 protocol: tcp size: 552 bytes
Dump: 8.0.69.0:58813 > 5.134.4.85:33989 protocol: unknown size: 26335 bytes
Dump: 10.198.42.29:52094 > 109.248.70.254:51413 protocol: tcp size: 1492 bytes
Dump: 8.0.69.0:52094 > 5.134.4.86:51413 protocol: unknown size: 26335 bytes
Dump: 10.198.42.29:52094 > 109.248.70.254:51413 protocol: tcp size: 1492 bytes
Dump: 8.0.69.0:52094 > 5.220.85.2:51413 protocol: unknown size: 45699 bytes
Dump: 8.0.69.0:52094 > 0.52.80.178:51413 protocol: unknown size: 311 bytes

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pppoetest   

pppoetest
Опубликовано · Жалоба
Packet with non standard ethertype found: 0x9000

Обычный поиск петель. Это нормально

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба
Packet with non standard ethertype found: 0x9000

Обычный поиск петель. Это нормально

Дык да, даже если бы это было что-то не нормальное, то таких пакетов ничтожно мало, в сравнении с другими данными. Так что меня смущает совсем другое. 

8.0.69.0:58813 > 5.134.4.85:33989 protocol: unknown size: 26335 bytes

- вот это не нормальные данные. И на каком основании скрипт их генерит не совсем понятно.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Так, друзья, есть отличные новости!

 

Я нашел отличную фичу у PF_RING - их собственный парсер пакетов, который умеет извлекать IP пакеты даже их хитроумных туннелей. В связи с этим PF_RING версия была мигрирована на него, деградаций и проблем не замечено. Зато замечена корректная работа на интерфейсах с bond0 в Linux.

 

Прошу всех стянуть новую статическую версию и попробовать. Качать рекомендую вот так: https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/fastnetmon?some_rand_params (где заменяем some_rand_params на какой-нить свой набор символов) ибо GitHub крайне любит кэшировать файлы на сутки-другие.

 

Всем большое спасибо за фидбэк!

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Так, друзья, есть отличные новости!

 

Я нашел отличную фичу у PF_RING - их собственный парсер пакетов, который умеет извлекать IP пакеты даже их хитроумных туннелей. В связи с этим PF_RING версия была мигрирована на него, деградаций и проблем не замечено. Зато замечена корректная работа на интерфейсах с bond0 в Linux.

 

Прошу всех стянуть новую статическую версию и попробовать. Качать рекомендую вот так: https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/fastnetmon?some_rand_params (где заменяем some_rand_params на какой-нить свой набор символов) ибо GitHub крайне любит кэшировать файлы на сутки-другие.

 

Всем большое спасибо за фидбэк!

СУПЕР!) Работает!) Буду тестировать! Спасибо!

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

pavel.odintsov   

pavel.odintsov
Опубликовано · Жалоба

Evolution23, ура! :) Правильный парсер пакетов творит чудеса.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Evolution23   

Evolution23
Опубликовано · Жалоба

Запустил на одной из машин, посмотрим как будет работать) Уже увидел наглядно самых активных пользователей)

Вопрос немного не по теме, ipcad можно подружить с pf_ring? а то сейчас он по ULOG работает у нас. Нагрузка терпимая, но если бы прикрутить pf_ring получилось, то было бы совсем здорово.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Перейти к списку тем Программное обеспечение, биллинг и *unix системы