Компания NetUP объявляет об открытии исходных кодов

SvinkaVJeansah

Компания NetUP объявляет об открытии исходных кодов коллектора статистики ndsad по лицензии GPL.
Демон ndsad предназначен для сбора информации по трафику с интерфейсов PC-маршрутизатора и экспорта ее в формате NetFlow. Проект будет базироваться на SourceForge. Получить последнюю версию
исходных кодов ndsad можно через CVS:
cvs -dcvs.sourceforge.net:/cvsroot/ndsad login
cvs -z3 -dcvs.sourceforge.net:/cvsroot/ndsad co -P

sergey_m

cvs -cvs.sourceforge.net:/cvsroot/ndsad login 


cvs -d:pserver:cvs.sourceforge.net:/cvsroot/ndsad login

cvs -z3 -cvs.sourceforge.net:/cvsroot/ndsad co -P 


cvs -z3 -d:pserver:cvs.sourceforge.net:/cvsroot/ndsad co -P ndsad

sergey_m



        struct iphdr *ih = (struct iphdr *) (p);

        struct udphdr *uh;

        struct tcphdr *th;

поскипано

        if( proto == IPP_UDP ) {

                uh = (udphdr *) (ih + 1);

                nf->sport = uh->uh_sport;

                nf->dport = uh->uh_dport;

        } else if( proto == IPP_TCP ) {

                th = (tcphdr *) (ih + 1);

                nf->sport = th->th_sport;

                nf->dport = th->th_dport;

                nf->tcp_flags = th->th_flags;

        }

Авторы когда нибудь слышали о IP options?

sergey_m



        if( h->caplen < ETHER_HDR_LEN + IP_HDR_SZ + TCP_HDR_SZ ) return;

Внимание, конкурс! Кто в сети ГЗ напишет туннель на 19-байтовом IP payload быстрее, чем компания NetUP пофиксит свой продукт, тот будет иметь халявный трафик как минимум в сети GZ-V, а возможно и в сети Кири, если последний тоже пользуется ndsad.

Marinavo_0507

> Внимание, конкурс! Кто в сети ГЗ напишет туннель на 19-байтовом IP payload
Внимание, опрос! Кто в сети ГЗ понимает, о чём тут речь, и до сих пор не имеет халявного трафика?

sergey_m

> Внимание, опрос! Кто в сети ГЗ понимает, о чём тут речь, и до сих пор не имеет халявного трафика?
Ты имеешь, и afaik у тебя халявный трафик.

irinkina

Я ушел с NDSAD-а уже более полугода.

Julie16

>Внимание, опрос! Кто в сети ГЗ понимает, о чём тут речь, и до сих пор не имеет халявного трафика?
Ну я например Хотя мне в общем-то уже не актуально

Agent_068

Читаем RFC - ftp://ftp.rfc-editor.org/in-notes/rfc894.txt
"The minimum length of the data field of a packet sent over an
Ethernet is 46 octets. If necessary, the data field should be padded
(with octets of zero) to meet the Ethernet minimum frame size. This
padding is not part of the IP packet and is not included in the total
length field of the IP header."
В результате весь пакет "добивается" мусором (00, ff) до 60 байт. Из них 14 на ethernet, 20 на IP-заголовок и соответсвенно 26 на то, что будет за IP. Попробуй послать 1 байт за IP-заголовком и поснифать на другом конце - увидим "добитый" до 60 байт пакет (точнее 60 -14). В результате от lbpcap на ethernet-интерфейсе всегда получаем как минимум 60 байт.
В общем ничего не получится в этом плане ...

ruler

sergey_m

Да, в случае входящих пакетов Ethernet этот баг нивелируется. А исходящие в NetFlow типа не считаются. Как у вас всё пиздато.

Marinavo_0507

Ух ты, считается только входящий на интерфейс трафик, причём весь?
То есть, если к каждому клиенту отдельный ppp-интерфейс ведёт, то нужно смотреть на ifindex, иначе один клиент сможет другого поставить на бабло с помощью спуфинга. А соответствие ifindex клиентам динамическое. Вот гемор

sergey_m

IP адрес обычно статический. Кстати про ifindex: когда я запускал ndsad, то он мне в ifindex писал какую-то полную пургу.

Marinavo_0507

> IP адрес обычно статический.
Адрес могут указать любой (ты ведь знаешь, что такое спуфинг? и libpcap всё равно захватит пакет (можно поставить фильтр, но придётся для каждого интерфейса отдельно, на этапе установки соединения, да и потянет ли демон несколько сотен интерфейсов?)

sergey_m

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

Marinavo_0507

> Мне кажется что проблемы спуфинга от своих клиентов надо решать не
> пассивными методами, а активными.
Ну хз, нам хватает обычного RPF. (место для смайлика :cool: )
Можно, конечно, пытаться определять флуд, сравнивая показатели счётчиков пакетов до фильтра, и после, и отключать клиентов, только зачем?
Единичные пакеты c неверным src ip относительно нормальны для хостов с несколькими IP, то есть для всех сетей ГЗ в частности.

sergey_m

> Ну хз, нам хватает обычного RPF. (место для смайлика )
При условии, что счёт делается после фильтрования. В случае libpcap (ndsad) это не так.

Marinavo_0507

> При условии, что счёт делается после фильтрования.
Ну конечно, считаем после.
> В случае libpcap (ndsad) это не так.
Дык.
А как кошководы справляются?

sergey_m

> А как кошководы справляются?
Не ябу.
Оставить комментарий
Имя или ник:
Комментарий: