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. -F 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 http://sc-isac.sc.gov <blocked::http://sc-isac.sc.gov>
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
