Утечка памяти в flow_fanout flow_capture. И странный IP в flow_capture производится
1) Вы могли (проверить себя), устанавливают ssh и пытаются видеть, показывают ли в другом компьютере с nmap порт 22 как открытый. 2) Это - большой ответ. Необходимо знать точно, какую защиту делают Вы хотите дать своим сервисам... 3)? 4) закройте inetd сервис
Несколько лет назад было жалоб на утечки памяти под BSD в версии 0.68 , но я не знаю, были ли они исправлены с тех пор.
Я заметил, что вы используете -E тег с очень большим числом. Если вы попробуете использовать что-то гораздо меньшее (скажем, -E1M) и объем памяти останется под контролем, я буду склонен винить в этом использование памяти.
Я не уверен, о чем вы спрашиваете в своем другой вопрос. Может быть, это просто совпадение со всеми сеансами, для которых одна конечная точка равна 127.0.0.1?[122ptingEdit: Думаю, теперь я понимаю, о чем вы говорите. Если бы это был NetFlow v9, я бы сказал, что это вероятная ошибка шаблона (которая может привести к считыванию неправильных байтов из структуры), но я не встречал этого для NetFlow v5. Я полагаю, есть четыре возможности:
- flow_capture неверно сообщает о том, что он получает
- flow_fanout каким-то образом искажает потоки, которые он ретранслирует
- ваш экспортер NetFlow в первую очередь неверно сообщает трафик
- есть какой-то (вредоносный?) в вашей сети, открывая сеансы на случайные IP-адреса.
Я бы использовал утилиту захвата пакетов, такую как Wireshark, чтобы проверить записи NetFlow и убедиться, что они правильно ретранслируются flow_fanout и правильно сообщаются в командной строке. Однако у меня никогда не было такой проблемы с flow_fanout, поэтому я бы лично посмотрел на №3.