首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >flow_fanout flow_capture中的内存泄漏。和奇怪的ip在flow_capture输出

flow_fanout flow_capture中的内存泄漏。和奇怪的ip在flow_capture输出
EN

Server Fault用户
提问于 2013-03-27 04:31:47
回答 1查看 285关注 0票数 0

在我的freebsd盒子上:

代码语言:javascript
复制
#uname -rimp
9.1-STABLE amd64 amd64 GENERIC

flow_tools:

代码语言:javascript
复制
> pkg_info -x flow
Information for flow-tools-0.68_7:

Comment:
Suite of tools and library to work with netflow data


Description:
Tools to capture, replicate, print, filter, send and other works
on Cisco's NetFlow Export.

WWW: http://www.splintered.net/sw/flow-tools/

收集器是ng_flow,从

代码语言:javascript
复制
    /usr/sbin/ngctl mkpeer ipfw: netflow 30 iface0
    /usr/sbin/ngctl name ipfw:30 netflow

    /usr/sbin/ngctl msg netflow: setdlt {iface=0 dlt=12}
    /usr/sbin/ngctl msg netflow: setifindex {iface=0 index=5}
    /usr/sbin/ngctl msg netflow: settimeouts {inactive=15 active=150}
    /usr/sbin/ngctl mkpeer netflow: ksocket export inet/dgram/udp
    /usr/sbin/ngctl msg netflow:export connect inet/127.0.0.1:9995

和ipfw规则:

代码语言:javascript
复制
02750  59239017674  33111253913522 ngtee 30 ip from any to any via em0

使用flow_fanout为flow_capture导出。

代码语言:javascript
复制
# ps axww | grep flow
15106 ??  Ss        2:50,08 /usr/local/bin/flow-fanout -p /var/run/flow-capture/flow-fanout.pid 127.0.0.1/0.0.0.0/9995 127.0.0.1/127.0.0.1/9556
16367 ??  Ss       11:28,63 /usr/local/bin/flow-capture -n 95 -N 3 -z 5 -S 5 -E270G -w /var/netflow -p /var/run/flow-capture/flow-capture.pid 127.0.0.1/0.0.0.0/9556

出于未知的原因,flow_capture在日志中报告了:

代码语言:javascript
复制
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=103.247.29.1 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=116.115.58.13 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=186.85.188.1 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=186.84.72.1 d_ver=5 pkts=2 flows=60 lost=480 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=186.85.212.1 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=190.149.28.1 d_ver=5 pkts=2 flows=60 lost=0 reset=0 filter_drops=0
Mar 27 10:20:00 rubin flow-capture[16367]: STAT: now=1364358000 startup=1364227269 src_ip=127.0.0.1 dst_ip=190.149.4.1 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0
 ....
Mar 27 10:25:00 rubin flow-capture[16367]: STAT: now=1364358300 startup=1364227269 src_ip=127.0.0.1 dst_ip=0.0.0.0 d_ver=5 pkts=8253374 flows=246879659 lost=71012 reset=0 filter_drops=0
  ....
Mar 27 10:25:28 rubin flow-fanout[15106]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=0.0.0.0 d_version=5 expecting=895162410 received=895162440 lost=30

我不明白:为什么这里有这么多ips?

我没有关于ips的任何配置,比如190.149.4.1和186.85.212.1以及其他任何配置。

而且,flow_fanout和flow_capture都会消耗越来越多的内存。上一次在我重新启动这些恶魔之前,它大约是3Gb的内存。

请帮我把这个奇怪的ips放在日志里。我是不是有什么错位?还是已知的窃听器?

UPD:我关于flow_capture日志的问题措辞很糟糕。再试一次:

在另一个配置类似于flow_capture的服务器上,我在日志中只看到一个记录,每15分钟记录一次:

代码语言:javascript
复制
Mar 28 08:55:00 flow-capture[45410]: STAT: now=1364439300 startup=1356501324 src_ip=127.0.0.1 dst_ip=127.0.0.1 d_ver=5 pkts=41948436 flows=1256544938 lost=0 reset=0 filter_drops=0 

看看dst_ip=127.0.0.1。

当我返回具有相同配置的第一台服务器时,我会在日志中看到

代码语言:javascript
复制
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=65.121.97.1 d_ver=5 pkts=1 flows=30 lost=0 reset=0 filter_drops=0                                                                        
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=255.127.0.0 d_ver=5 pkts=1458 flows=43711 lost=21989 reset=1395 filter_drops=0                                                           
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=109.112.100.32 d_ver=5 pkts=446 flows=13380 lost=15933 reset=401 filter_drops=0                                                          
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=12.79.228.1 d_ver=5 pkts=4 flows=120 lost=0 reset=3 filter_drops=0                                                                       
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=105.110.100.44 d_ver=5 pkts=465 flows=13950 lost=16443 reset=411 filter_drops=0                                                          
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=8.0.0.0 d_ver=5 pkts=88 flows=2611 lost=210 reset=85 filter_drops=0                                                                      
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=82.111.119.115 d_ver=5 pkts=449 flows=13412 lost=11044 reset=409 filter_drops=0                                                          
Mar 28 09:05:00 rubin flow-capture[16367]: STAT: now=1364439900 startup=1364227269 src_ip=127.0.0.1 dst_ip=0.0.0.0 d_ver=5 pkts=14965070 flows=447566910 lost=130355 reset=0 filter_drops=0

看看所有这些dst_ip,例如8.0.0.0。它看起来像是错误或错误配置。但我不知道怎么解决这个问题。

EN

回答 1

Server Fault用户

回答已采纳

发布于 2013-03-28 01:36:58

几年前有0.68年BSD下内存泄漏的投诉,但我不知道从那以后它们是否被修复了。

我确实注意到,您使用的-E标记具有非常大的数字。如果您尝试使用一些小得多的东西(例如,-E1M),并且内存占用保持在控制范围内,我将倾向于将内存使用归咎于内存的使用。

我不知道你在另一个问题上问了什么。它是否只是与一个端点为127.0.0.1的所有会话进行匹配?

编辑:我想我明白你现在在说什么了。如果是NetFlow v9,我会说有一个可能的模板错误(这可能导致从结构中读取错误的字节),但是对于NetFlow v5,我还没有遇到这种情况。我想有四种可能性:

  1. flow_capture错误地报告了它收到的信息
  2. flow_fanout在某种程度上破坏了它所中继的流
  3. 你们的NetFlow出口商一开始就错误地报告了流量
  4. 有某种(恶意的?)应用程序在您的网络打开会话的随机IP地址。

我会使用像Wireshark这样的数据包捕获实用程序来检查NetFlow记录,并确保它们被flow_fanout正确地转发,并在命令行中正确地报告。不过,我从来没有遇到过flow_fanout这样的问题,所以我会亲自看看#3。你可以下载一些自由流动的出口商,与你当前的出口商一起运行,并与目前的出口商进行比较。

票数 1
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/491690

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档