Re: Packet Tracing (linux klog patch)

[abial () WEBGIRO COM (Andrzej Bialecki)]

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

//  <abial () webgiro com> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----