On Thu, 17 Feb 2000, Dragos Ruiu wrote: > I just peeked a NeTraMet. again - still looks neat. I looked > at it last summer or fall and had decided that I really didn't > want an SNMP mib hollering my traffic statistics to the world > so that stealth attacks can come in more easily. But I'll look ??? What do you mean? You surely block the in/out SNMP traffic to your network, right? If so, then I don't see a danger, unless the machine itself is compromised - but then you loose no matter what method you choose to collect the statistics... Or, perhaps I misunderstood you.. > at it again... Does anyone have any benchmark data for it? I've been using netramet for the last 3 years. Some revisions had some problems with lost or silently skipped packets, but the newer versions are quite good. I was able to take real-time flow dump on some large intercity trunks (usually fast-ethernet between the main routers). The traffic was around 3000 packets per second, and it followed quite closely the counters on the Ciscos. That was done with FreeBSD, 2.2.8, on a Pentium 133MHz. Although you need to make some adjustments to standard libpcap to increase its buffers. The fact that it uses SNMP doesn't have any serious significance, IMHO. The statistics are collected by the agent, and only summarised flows are transported over SNMP. Then , for the really large trunks, I was using some of the tools that Caida developed, capturing the traffic from ATM 155Mps links and creating flows. I was also using more or less standard FreeBSD on a PentiumII, but this time I wasn't using libpcap nor SNMP for that. That worked nice as well - I was able to follow closely the traffic on main international link, without loosing any packets (in fact, the instrumentation I had in the software showed that it could handle 5-10 times bigger traffic. But then the storage system becomes a problem...). The statistics followed very closely the counters on the switches, so I assumed I didn't loose anything on the way. As a bonus, the software allowed for debugging of ATM signalling, which is a nice feature when you want to connect equipment from different vendors :-) And, if you follow the PicoBSD link in my sig, you will notice that it is quite easy to build a very stripped-down system just for such purposes. > Removable drive carriers allow export of the data to analysis > stations because the sensors are so stripped as to make them virtually > useless for any other function and hopefully devoid of most > vulnerabilities. Kernel, sh, syslogd and a trivial filesystem should > suffice. Maybe only kill, cp/mv and cron for log files.... > As a matter of fact you should even be able to disable > the IP stack and have it work. Call it the data motel > security model and approach... :-) Heh.. You can always put an unnumbered interface on the ethernet, just to sniff the traffic, and collect the results over another interface. Andrzej Bialecki // <abialat_private> WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:47 PDT