On Mon, Dec 31, 2001 at 11:09:08AM -0600, Burton M. Strauss III wrote:
Hi,
> 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...
Umm. I haven't looked at the code (and little good would it do), but isn't a
potential solution just something like tcp_traffic_counter[port]++ and
udp_traffic_counter[port]++?
> 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.
Yes, although that's 'only' UDP.
> 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.
Oh, they did get it right, did they? :) Yes, I know it would be difficult.
Perhaps a better (than now) approximation of actual traffic could be
obtained the following way:
Build a static-sized table of 'most recent outgoing and incoming
communication'. This table could be used in an LRU fashion. It contains
entries of the type (originating IP; port; IP protocol; destination IP;
port). Any further communication is matched against these table entries; if
a match is found, the traffic is assigned to the protocol associated with
the destination port used when the entry was created.
Example:
our box at 1.1.1.1 queries a DNS server at 2.2.2.2; the source port is 5900,
the destination port is 53, and the protocol is udp.
We'de have the following table entry:
1.1.1.1; 5900; 17 (for udp); 2.2.2.2; 53
When 2.2.2.2 answers, the program sees that there already is an entry for
2.2.2.2:53 (udp) in the table, and assigns the traffic to DNS.
I'm not sure if I'm making myself clear...?
The size of the lookup table could be a run-time parameter. I guess it's not
its memory consumption that would limit its useful size; lookup times are
more of an issue. A data structure with efficient searching and 'shifting'
would have to be used. ('Shifting' because new entries replace the oldest
ones.)
I'm not saying this is a good solution, just something that could be
considered.
> All Ntop sees is the stream, one packet at a time. Analyzing packet content
I agree; it's not ntop's business to analyze packet contents.
> You could TRY patching the UDP code to try the lower port # first:
This does sound like a good idea, actually. I don't think 'low' port numbers
are often used for outgoing connections (and when they are, the source port
number typically equals the destination port number, as in NTP), so if one
end of the communication uses a privileged port, that is likely to be a
better indication of the protocol than the high client port.
If both ports are 'high', well... It'd be nice if I could tell ntop that for
example anything having to do with my local tcp port 5900 is VNC and should
be classified as such, never mind the other end.
Some kind of 'static mapping' file could be specified on the command line,
with contents like this:
# protocol IP port
tcp 1.1.1.1 1234
udp 2.2.2.2 8080
Later, for communication that matches any of the above lines, source or
destination, is classified using the port number on the line (and the
information from protocols.list).
Actually, a feature like this would solve almost all of my problems
regarding this traffic distribution metering problem.
The only thing left to do would be monitoring protocols other than tcp, udp
and icmp. :)
A happy new year to everyone!
Andrew
--
Andrew Korn (Korn Andras) <[EMAIL PROTECTED]>
Finger [EMAIL PROTECTED] for pgp key. QOTD:
The human race, to which so many of you belong...
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
