(1) ntop explicitly logs this connection:
CHKVER: Checking current ntop version at version.ntop.org/version.xml
(2) There is an entire section on PRIVACY in the ntop man page. I'll copy
that to the bottom of this message.
(3) On the bottom of the 1st page, which is ALWAYS displayed when you enter
ntop is this text:
"For information on ntop and information privacy, see this page."
Which points to an entire page discussing the version.xml access. I'll copy
the entire text of that page at the bottom of this reply.
(4) The first time you run ntop a LARGE privacy notice message is generated
in the log. See displayPrivacyNotice() in util.c:
CHKVER: **********************PRIVACY**NOTICE**********************
CHKVER: * ntop instances may record individually identifiable *
CHKVER: * information on a remote system as part of the version *
CHKVER: * check. *
CHKVER: * *
CHKVER: * You may request - via the --skip-version-check option *
CHKVER: * that this check be skipped and that no individually *
CHKVER: * identifiable information be recorded. *
CHKVER: * *
CHKVER: * In general, we ask you to permit this check because it *
CHKVER: * benefits both the users and developers of ntop. *
CHKVER: * *
CHKVER: * Review the man ntop page for more information. *
CHKVER: * *
CHKVER: **********************PRIVACY**NOTICE**********************
(5) On the privacyNotice.html page are buttons to set the log message to
display once more or ALWAYS.
We've been very upfront about this and also make available some of the
reduced data at http://www.ntopSupport.com/alr.html
-----Burton
man ntop (extract):
PRIVACY NOTICE
By default at startup and at periodic intervals, the ntop program
will
retrieve a file containing current ntop program version
information.
Retrieving this file allows this ntop instance to confirm that it
is
running the most current version.
The retrieval is done using standard http:// requests, which will
cre-
ate log records on the hosting system. These log records do
contain
information which identifies a specific ntop site. Accordingly,
you
are being notified that this individually identifiable information
is
being transmitted and recorded.
You may request - via the --skip-version-check run-time option -
that
this check be eliminated. If you use this option, no
individually
identifiable information is transmitted or recorded, because the
entire
retrieval and check is skipped.
We ask you to allow this retrieval and check, because it benefits
both
you and the ntop developers. It benefits you because you will be
auto-
matically notified if the ntop program version is obsolete,
becomes
unsupported or is no longer current. It benefits the developers
of
ntop because it allows us to determine the number of active
ntop
instances, and the operating system/versions that users are
running
ntop under. This allows us to focus development resources on
systems
like those our users are using ntop on.
The individually identifiable information is contained in the
web
server log records which are automatically created each time the
ver-
sion file is retrieved. This is a function of the web server and
not
of ntop , but we do take advantage of it. The log record shows the
IP
address of the requestor (the ntop instance) and a User-Agent
header
field. We place information in the User-Agent header as follows:
ntop/<version>
host/<name from config.guess>
distro/<if one>
release/<of the distro, also if one>
kernrlse/<kernel version or release>
GCC/<version>
config() <condensed parameters from ./configure>
run() <condensed flags - no data - from the execution line>
libpcap/<version>
gdbm/<version>
openssl/<version>
zlib/<version>
access/<http, https, both or none>
interfaces() <given interface names>
For example:
ntop/2.2.98 host/i686-pc-linux-gnu distro/redhat release/9
kern-
rlse/2.4.20-8smp
GCC/3.2.2 config(i18n) run(i; u; P; w; t; logextra; m;
instantses-
sionpurge;
schedyield; d; usesyslog=; t) gdbm/1.8.0 openssl/0.9.7a
zlib/1.1.4
access/http interfaces(eth0,eth1)
Distro and release information is determined at compile time and
con-
sists of information typically found in the /etc/release (or
similar)
file. See the ntop tool linuxrelease for how this is determined.
gcc compiler version (if available) is the internal version #s for
the
gcc compiler, e.g. 3.2.3.
kernrlse is the Linux Kernel version or the xBSD a?Treleasea?T
such as
4.9-RELEASE and is determined from the uname data (if ita?Ts
available).
The ./configure parameters are stripped of directory paths,
leading -s,
etc. to create a short form that shows us what ./configure
parameters
people are using.
Similarly, the run time parameters are stripped of data and paths,
just
showing which flags are being used.
The libpcap, gdbm, openssl and zlib versions come from the
strings
returned by the various inquiry functions (if theya?Tre availabe).
Herea?Ts a sample log record:
67.xxx.xxx.xxx - - [28/Dec/2003:12:11:46 -0500] "GET
/version.xml
HTTP/1.0"
200 1568 www.burtonstrauss.com "-" "ntop/2.2.98
host/i686-pc-linux-
gnu
distro/redhat release/9 kernrlse/2.4.20-8smp GCC/3.2.2 config(i18n)
run(i; u; P; w; t; logextra; m; instantsessionpurge; schedyield; d;
usesyslog=) libpcap/0.8 gdbm/1.8.0 openssl/0.9.7a
zlib/1.1.4
access/http
interfaces(eth0,eth1,eth2)" "-"
privacyNotice.html:
ntop Privacy Notices
End Users
If you have concerns about your privacy, please read this notice.
After reading it, if you have any concerns about your privacy while using
any networked system please contact your systems administrator(s) to discuss
your concerns.
If you are seeing this notice, it is likely that the ntop program is being
used by your systems administrators to monitor network usage and that the
information collected by ntop is available to end users.
Please be aware that all ntop does is to examine the contents of the
information flowing over the networks to which it is connected. ntop has no
special privileges - this information is available to ANY similarly
connected network user.
The information collected by ntop does contain individually identifiable
information, that is information about your individual usage of this
computer network. For example, this information will indicate the sites your
computer has contacted, the protocol used (e.g. http or ftp), the amount of
information transferred and the duration of each contact. All of this is
derived from the header which is a part of each chunk of information (called
a packet) transmitted or received over the network. This header information
is similar to the destination and return address on a postal card - it's
visible to anyone who happens to see the card.
In addition, some information within the packets is also examined and
reported. This will indicate, for example, the user names used to contact
mail servers, P2P networks, etc. This information is also available to ANY
computer on the network with the same connections as the ntop host. It is ju
st not normally viewed. Thus you should expect information transmitted over
a computer network to be similar to a postal card - visible to anyone who
happens to look over it. If this is a concern for you, you should discuss
appropriate security measures, such as encryption and Virtual Private
Networks with your systems administrator(s).
The information collected by ntop may, or may not, be made available to end
users - this is entirely at the discretion of the systems administrator(s).
If it is made available, then the information discussed above is available
to other individuals. If this is a privacy concern for you, please contact
your systems administrator(s). The authors of ntop do not have any control
nor special influence over the administrator(s) of your local system. Please
do not contact the authors of ntop regarding your individual privacy
concerns.
For more information about ntop, please ask your systems administrator(s) or
visit www.ntop.org.
----------------------------------------------------------------------------
----
Systems Administrators
An abbreviated version of this privacy notice is printed by ntop in the
system log (or directed to the executing users' terminal) during the very
first run of ntop. An authorized user may click here to force ntop to report
the privacy notice at the beginning of EVERY future run. Or you may click
here to have ntop re-issue the privacy notice at the beginning of the next
ntop run and then stop issuing it for future runs.
----------------------------------------------------------------------------
----
By default at startup and at periodic intervals, the ntop program will
retrieve a file containing current ntop program version information.
Retrieving this file allows this ntop instance to confirm that it is running
the most current version.
The retrieval is done using standard http:// requests, which will create log
records on the hosting system. These log records do contain information
which identifies a specific ntop site. Accordingly, you are being notified
that this individually identifiable information is being transmitted and
recorded.
You may request - via the --skip-version-check run-time option - that this
check be eliminated. If you use this option, no individually identifiable
information is transmitted or recorded, because the entire retrieval and
check is skipped.
We ask you to allow this retrieval and check, because it benefits both you
and the ntop developers. It benefits you because you will be automatically
notified if the ntop program version is obsolete, becomes unsupported or is
no longer current. It benefits the developers of ntop because it allows us
to determine the number of active ntop instances, and the operating
system/versions that users are running ntop under. This allows us to focus
development resources on systems like those our users are using ntop on.
The individually identifiable information is contained in the web server log
records which are automatically created each time the version file is
retrieved. This is a function of the web server and not of ntop, but we do
take advantage of it. The log record shows the IP address of the requestor
(the ntop instance) and a User-Agent header field. We place information in
the User-Agent header as follows:
ntop/<version>
host/<name from config.guess>
distro/<if one>
release/<of the distro, also if one>
kernrlse/<kernel version or release>
GCC/<version>
config() - condensed parameters from ./configure&
run() - condensed flags - no data - from the execution line
libpcap/<version>
gdbm/<version>
openssl/<version>
zlib/<version>
access/<http, https, both or none>
interfaces() <given interface names>
For example:
ntop/2.2.98 host/i686-pc-linux-gnu distro/redhat release/9
kernrlse/2.4.20-8smp
GCC/3.2.2 config(i18n) run(i; u; P; w; t; logextra; m; instantsessionpurge;
schedyield; d; usesyslog=; t) gdbm/1.8.0 openssl/0.9.7a zlib/1.1.4
access/http interfaces(eth0,eth1)
Distro and release information is determined at compile time and consists of
information typically found in the /etc/release (or similar) file. See the
ntop tool linuxrelease for how this is determined.
gcc compiler version (if available) is the internal version #s for the gcc
compiler, e.g. 3.2.3.
kernrlse is the Linux Kernel version or the xBSD release such as 4.9-RELEASE
and is determined from the uname data (if it's available).
The ./configure parameters are stripped of directory paths, leading -s, etc.
to create a short form that shows us what ./configure parameters people are
using.
Similarly, the run time parameters are stripped of data and paths, just
showing which flags are being used.
The libpcap, gdbm, openssl and zlib versions come from the strings returned
by the various inquiry functions (if they're available).
Sample log record
67.xxx.xxx.xxx - - [28/Dec/2003:12:11:46 -0500] "GET /version.xml HTTP/1.0"
200 1568 www.burtonstrauss.com "-" "ntop/2.2.98 host/i686-pc-linux-gnu
distro/redhat release/9 kernrlse/2.4.20-8smp GCC/3.2.2 config(i18n)
run(i; u; P; w; t; logextra; m; instantsessionpurge; schedyield; d;
usesyslog=) libpcap/0.8 gdbm/1.8.0 openssl/0.9.7a zlib/1.1.4
access/http interfaces(eth0,eth1,eth2)" "-"
ntop access log report
Today, since Midnight US EST
Processed from logs/access.log.02.3 on Wed Jan 7 14:01:01 EST 2004
ntop OS Version Cpu kernel/rlse s n GCC http? ssl
gdbm zlib pcap interfaces
------ ------- -------------- ------- --------------- - - ------ ----- -----
- ----- ----- ---- ----------
2.2.98 Darwin 7.2.0 powerpc 7.2.0 3.3.0 http
0.9.7b 1.8.3 1.1.4 default NIC
2.2.98 Darwin 7.2.0 powerpc 7.2.0 3.3.0 http
0.9.7b 1.8.3 1.1.4 en0
...
2.2.98 Linux slackware9.0.0 i686 2.4.24 3.2.2 http
0.9.7c 1.8.0 1.1.4 eth0,
2.2.98 Solaris 8 sparc 3.3.0 both
0.9.7b 1.8.3 1.1.4 le0,le1
non-ntop from 194.65.xxx.xxx is host/i686-pc-linux-gnu distro/fedora
release/1 kernrlse/2.4.22-1.2129.nptl GCC/3.3.2 config run user dbfilepath
daemon gdbm/1.8.0 openssl/0.9.7a zlib/1.2.1 access/http interfaces(null
72 log records processed
67 version.xml records
ntop access log report
All log files - by (blinded) IP
Processed on Wed Jan 7 02:01:01 CST 2004
Count Source(ip) ntop OS Version Cpu kernel/rlse
s n
------- --------------- ------ ------- -------------- ------- --------------
- - -
1 12.41.xxx.xxx 2.2.98 Linux fedora1 i686 2.4.22-1.2135
y
2 61.171.xxx.xxx 2.2.98 Linux i686 2.4.20-proxy
4 61.220.xxx.xxx 2.2.98 FreeBSD 4.6.2 i386 4.6.2-RELEASE
...
3 219.76.xxx.xxx 2.2.98 Solaris 9 i386
1 219.76.xxx.xxx 2.2.98 Solaris 9 i386
NOTES: This report is prepared by sorting and compressing requests using the
unblinded ip address. Thus:
Adjacent lines that are completely identical are indicative of multiple
requests from different machines in the same /16 block.
Adjacent lines that have the same /16 address but are otherwise different
may be different machines or may be from the same machine running multiple
OSes/versions
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Luca
> Deri
> Sent: Thursday, April 01, 2004 11:58 PM
> To: Antoine Martin
> Cc: ntop
> Subject: [Ntop] Re: rooted
>
>
> Antoine,
> in order to avoid/reduce questions about old/unsupported ntop versions,
> we decided to develop (Burton did that) a version tracking system
> into ntop.
>
> The first time you start ntop your host queries for the latest avaiable
> ntop and reports you about this. If you don't like this policy add
> --skip-version-check to the ntop command line and you'll run without it.
>
> Cheers, Luca
>
> Antoine Martin wrote:
>
> >Sorry about that, chkrootkit seemed to think that ntop was a bindshell
> >and because ntop connected to jake.unipi.it, I thought you were using
> >that rootkit.
> >
> >It isn't really obvious when you download ntop that it will attempt to
> >connect to "jake.unipi.it", I bet I am not the first one to be surprised
> >by this.
> >
> >Also it is not clear to me why you send all this information about my
> >machine (this is not the kind of thing I would like to have publically
> >available - flying across the net in plain/text):
> >"GET /version.xml HTTP/1.0..Host: version.ntop.org..User-Agent:
> >ntop/3.0+SourceForge+.tgz host/i686-pc-linux-gnu distro/slackware
> >release/9.1.
> > 0 kernrlse/2.6.4-rc2 GCC/3.2.3 config() run() gdbm/1.8.3. gd/2.0.21+
> >openssl/0.9.7d zlib/1.2.1 access/http interfaces(eth)..Accept: */*...."
> >
> >
> >Regards
> >Antoine Martin
> >
> >On Thu, 2004-04-01 at 19:55, Antoine Martin wrote:
> >
> >
> >>Hi,
> >>
> >>I noticed a rootkit on my server,
> >>would you mind telling me how you got in?
> >>(clearly through ntop) but how?
> >>I am not aware of any remote exploits in the current ntop.
> >>
> >>Regards
> >>Antoine Martin
> >>Nagafix Ltd
> >>
> >>
> >
> >
> >
>
>
> --
> Luca Deri <[EMAIL PROTECTED]> http://luca.ntop.org/
> Hacker: someone who loves to program and enjoys being
> clever about it - Richard Stallman
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
