aabc

@kid79 ой, это я не про то написал. Не про "No such file or directory".

@kid79 Стандартная проблема с bash, echo режет строки, так что в файл они записываются по частям. Лучше использовать perl, python, etc, чтоб строка записывалась одним write().

Я, кстати, думал что есть возможность добавить к каждому flow первые n-байт из его содержания. Анализаторы протоколов уже могли бы определить тип соединения (для IDS, например), может влезть начало http запроса, dns запросы, начало ответов на них (в обратные flows). Есть две проблемы - 1) нет стандарта для такого, хоть и определён элемент ipPayloadPacketSection, но он для PSAMP, а следовательно per-packet, в то время как идея чтоб было per-flow; 2) нет софта который бы это ожидал и парсил. Ну и недостаток что это будет занимать больше памяти и увеличивать нагрузку на экспорт.

Каких доменов? ps. Какой элемент вам нужен из этих https://www.iana.org/assignments/ipfix/ipfix.xhtml?

По-умолчанию он не выключен, а равен 0. Если у вас один экспортер, то так и оставьте. Если несколько, то сделайте им номера по порядку.

Он есть. https://github.com/aabc/ipt-netflow/blob/master/README#L582

@alexkar hashsize поставьте 220000.

@Susanin ipt-netflow экспортирует информацию, которая есть в ядре. Номеров AS там нет. (FYI Ранее был сторонний патч к quagga, который помещал AS в маршрут в поле realm, но он давно заброшен.) Вы могли бы закодить netflow proxy (полностью в userspace), который бы добавлял к flows номера AS. Минус такого метода, что AS бы не попадала во flow key (кому-то это может было бы нужно, кому-то нет). Как-то внедрять в ядро информацию никак не влияющую на роутинг (и не актуальную в каждый момент) в статистику, которая, подразумевается, что она от роутинга, с моей точки зрения, было бы странно.

Да.

Это версия из git, она однозначно идентифицирует коммит, который вы используете. Я не делал тег v0.3, поэтому там версия относительно 0.2. Надеялся, что люди потестят и тогда можно будет сделать релиз 0.3. Но пока никто не репортит успех.

В non-interactive bash ограничение на размер stdout буфера 1008 байт. Полагаю, нужно юзать, например, perl или запускать скрипт через stdbuf -o8K.

Инсталлируете на centos 6.

В nftables нет поддержки модулей.

Пара вопросов. Если 1гбит, то не справляется? Перефразирую ваше довод: нет смысла фильтровать SYN-flood на конечном сервере, с 1гбит картой и интерфейсом, так как такой канал легко забить 1.1гбит SYN-floodа. То есть аргумент основывается на ширине канала, который можно забить строго SYN-floodом. Вопрос: что мешает забивать его не SYN-floodом, а любым другим floodом? SYN-flood позволяет небольшими ресурсами положить сервис так как SYN-queue имеет конечную длину. То есть, нет необходимости генерировать 1.1гбит SYN-floodа, чтоб положить конечный сервер в котором нет SYN-cookies, и нет необходимости генерировать 1.1гбит SYN-floodа, чтоб положить конечный сервер в котором есть SYN-cookies, но 1гбит канал. Следовательно, при чём тут SYN-cookies?

boco, чтоб работал редирект, в if (match) { сделать par->hotdrop = true, а в } else { сделать match = true (как при включенном :match). ps. Какая религия мешает заюзать ipset?