(As stated elsewhere, I'm nothing more than a (noisy) user). I think I
understand - finally - what you're saying.
Yes, distinguishing between UDP and TCP would solve this specific case. And
that's probably a good thing. Complex, however... you would have to
potentially double a lot of memory structures or implement some type of
sparse array...
Programs (be they daemons, or anything else) that pick random unprivileged
ports collide with port assumptions in other ways too. For example, a
common firewall rule allows a small # of ports outbound for traceroute. Any
packet that happens to pick a port in that range will be passed, regardless
of whether it's from traceroute or not.
To accurately apportion traffic, NTop has to either go from the data in the
packets alone, or implement full connection tracing. That's a performance
nightmare, and difficult - we know how complex that is, look at what it took
to get it right in 2.4 kernels.
All Ntop sees is the stream, one packet at a time. Analyzing packet content
is complex and error prone, not to mention the number of poorly documented,
ad hoc or private streams of data NTop might look at...
Back to your case:
>However, some of my DNS queries went out from ports in the above range
>(5900-5960), obviously to port 53 (udp); the replies came from port 53 to
>the high port between 5900 and 5960.
So NTop saw packets out with sport=5900 and dport=53 and in with sport=53
and dport=5900 and classified one as DNS and the other as VNC.
I think that the logic you would want to fix is in pbuf.c in static void
processIpPkt (which starts at 2721), around line 3262 (UDP) vs at 3050 (TCP)
:
case IPPROTO_TCP:
...
/* choose most likely port for protocol traffic accounting
* by trying lower number port first. This is based
* on the assumption that lower port numbers are more likely
* to be the servers and clients usually dont use ports <1024
* This is only relevant if both port numbers are used to
* gather service statistics.
* e.g. traffic between port 2049 (nfsd) and 113 (nntp) will
* be counted as nntp traffic in all directions by this heuristic
* and not as nntp in one direction and nfs in the return direction.
*
* Courtesy of Andreas Pfaller <[EMAIL PROTECTED]>
*/
if(dport < sport) {
if(handleIP(dport, srcHostIdx, dstHostIdx, length, isPassiveSession)
== -1)
handleIP(sport, srcHostIdx, dstHostIdx, length, isPassiveSession);
} else {
if(handleIP(sport, srcHostIdx, dstHostIdx, length, isPassiveSession)
== -1)
handleIP(dport, srcHostIdx, dstHostIdx, length, isPassiveSession);
}
vs.
case IPPROTO_UDP:
...
if(handleIP(dport, srcHostIdx, dstHostIdx, length, 0) == -1)
handleIP(sport, srcHostIdx, dstHostIdx, length, 0);
...
(handleIP invokes mapGlobalToLocalIdx to lookup the port and if it's not
found returns -1) (So if you weren't monitoring VNC, it would try VNC, fail
and then class it as DNS)
You could TRY patching the UDP code to try the lower port # first:
if(dport < sport) {
if(handleIP(dport, srcHostIdx, dstHostIdx, length, 0) == -1)
handleIP(sport, srcHostIdx, dstHostIdx, length,
} else {
if(handleIP(sport, srcHostIdx, dstHostIdx, length, 0) == -1)
handleIP(dport, srcHostIdx, dstHostIdx, length, 0);
}
I don't know what else this would "break"
-----Burton
PS: as for your PS, you may be technically correct, but almost every usage
in RFCs etc. assumes you can distinguish between the two in the text. After
all, IP the protocol is really confusing itself - TCP/IP is Transmission
Control Protocol/Internet Protocol...
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of KORN
Andras
Sent: Sunday, December 30, 2001 12:44 PM
To: [EMAIL PROTECTED]
Subject: [Ntop] More info on previously reported traffic mis-assignment bug
Hi,
You may recall that I have constantly been going on about a problem where
ntop would not correctly identify the application level protocol (i.e. port
number) of some traffic.
I now have an example, obtained with ntop 2.0beta20011016.
I use the following protocols.list:
ssh=22,direct_http=80,http_squid=3128|31280,http_junk=8000,ICQ=4000|5190,YIM
=5050,ftp=21|20,telnet=23,whois=43,DNS=53,bootp=67|68,finger=79,smtp=25,pop3
=110,auth=113,ntp=123,netbios=137|138|139|445,imap2=143,xdmcp=177,irc=6666|6
667|6668|6669|66670,ldap=389,notes=1352,ipp=631,ldaps=636,rsync=873,ftps=990
|989,telnets=992,imaps=993,pop3s=995,socks=1080,cvs=2401,dict=2628,icpv2=313
0,vnc=5900-5960,X11=6000-6015,xfont=7100|7101|7102|7110,swat=901,ssmtp=465,z
ebra=2600-2606,dnetc=2064,bzflag=5155|5156,cddb=8880
The part the concerns us now is 'vnc=5900-5960'.
I ran 'tcpdump -l -n | adnsresfilter' for a while. This generates huge
amounts of DNS traffic. I did not run anything else, and I certainly did not
run a VNC client.
However, some of my DNS queries went out from ports in the above range
(5900-5960), obviously to port 53 (udp); the replies came from port 53 to
the high port between 5900 and 5960.
ntop reported that I have had VNC traffic, which is incorrect. I merely had
DNS traffic whose client port happened to be one of the VNC server ports.
The correct behaviour would have been to recognize the incoming UDP packet
as a DNS reply and file it under 'DNS traffic'.
(Also note that VNC uses TCP while DNS primarily uses UDP, so implementing
the protocol distinction I requested in my previous message would also
reduce the confusion caused by this bug.)
To sum it up, ntop behaves incorrectly when the protocol list includes port
numbers that will be used as client ports as well as server ports.
Best regards,
Andrew
Ps. I believe the word 'protocol' is used somewhat misleadingly throughout
ntop and its documentation; you actually mean 'tcp or udp based application
level protocol' or 'tcp or udp port number' in most cases. (Note that the
mapping between application level protocols and port numbers is not 'hard',
so ntop does not actually log protocol distribution, only port number
distribution, but this is almost irrelevant.) Sometimes the word 'protocol'
is used to mean 'IP level protocol' or 'transport protocol'. Please consider
adding appropriate qualification to each use of the term.
--
Andrew Korn (Korn Andras) <[EMAIL PROTECTED]>
Finger [EMAIL PROTECTED] for pgp key. QOTD:
Ultimate office automation: networked coffee.
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
