[Ntop-dev] A couple of Ntop issues
feargle at cio.sc.gov
Fri May 8 16:58:43 CEST 2009
We use ntop at around 100 locations to gather statistics along with Snort
IDS¹s. All of the ntop¹s are monitoring span ports along with the Snorts.
Initially we had many of the ntops crashing with no error events logged. I
found out through trial and error that it is usually data flow related.
Turning off decoders, session support and in worst cases rrd seemed to keep
them up and running. Many of them were fixed with BPF¹s limiting the data
ntop sees to IP or in some cases TCP and UDP. The versions we use are 3.3.6
and 3.3.8 from Dag¹s repository. The ntops are running on Centos 4.6. I
make this statement mainly so that developers will know where to look or at
least be aware of where some issues were. I¹ve never run ntop in debug
mode, mainly because the links being monitored are 100+ Mb/sec and the
sensors don¹t have the additional horsepower to do debugging. That and the
fact that the crashes are very unpredictable. When they have been
predictable, one of the fixes above always has fixed it.
Second issue is a little more problematic for us. We access the ntop¹s
through an OpenVPN connection. We have a test box at our office that uses
the same VPN. When accessing all of the ntops, especially on busy sensors,
even 8 way boxes with 8Gb of ram, the ntop becomes unresponsive to the
browser. This apparently is NOT dependant on SSL or regular http. It does
appear to be more prevalent on boxes that are higher traffic. Reverse
proxying with squid or apache makes ntop fly initially, but after it has
been running a couple of hours this doesn¹t seem to help at all. When it is
so unresponsive I see in the squid logs ³normal² 304 refresh events, mostly
against Mochikit/Base.js. Doing a tcpdump showed the application not
responding to the requests from the client browser. I am willing to work on
this issue as it is so critical to our project. Of note is that the svn or
3.3.10 seems to have the same issue. In all versions, restarting ntop makes
it faster for a while. Can anyone give me a little guidance on where to
look into this problem? I thought it may be something related to MTU on the
vpn, but it seems to have the same issue with even very small MTU settings.
I debated turning off Nagle, but the small MTU having the same problem told
me that was likely the wrong place to look.
On the positive side, this is an incredible work. Thanks to all that have
worked so hard on it. I have contacted Burton, and I will have a new .spec
file soon for RHEL and Centos. I assume it would be better than the
existing Fedora one as well. I want to finish up getting GeoIP and Lua into
separate (provided) RPM¹s as the current .spec file will over write parts of
those packages. I look forward to being hosed at my newbie attempt at
writing an RPM.
Frank Eargle II
Information Security Analyst
SC Computer Incident Response Team
The Division of State Information Technology (DSIT)
4430 Broad River Rd
Columbia, SC 29210
803-896-1650 SC-ISAC Response Center
803-896-0711 Direct Line
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ntop-dev