(1)   Try reading the FAQ - that is actually why I wrote it.  To answer the
questions that pop up again and again.

 

(2)   Possible?  Interesting idea, but ultimately - like any version that
doesn't maintain state - flawed.

 

Let's say you run a proprietary application - your bread and butter system -
on port 7001.  That means all of your users initiate traffic from their
workstation on a local port to 7001 for this proprietary service.  But, even
then, the service actually runs on only 2 or 3 machines.  So for a random
packet, from say 123 -> 7001?   Is it the middle of a conversation with your
proprietary service or the response from an ntp call on a server which
doesn't support the proprietary service?  In this case I would find BOTH 123
and 7001 in the protocols.list file . so what do I do??

 

Ultimately ANY classification scheme is flawed unless ntop sees EVERY packet
and runs a full connection tracking algorithm.  That would be both
prohibitory due to speed slow and prohibitory in memory usage.

 

What we have works pretty well for most users.  If you really need more, I
can only recommend that you invest in a proprietary system that does that
connection tracking.  And thus I hope you have $100K lying about.

 

-----Burton

 

  _____  

From: Vaughan Wickham [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 20, 2007 10:45 PM
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: [Ntop] 85% of Other Tcp/Udp traffic - is there a way to tell
ntophow to decode it?

 

Hi Burton,

On 6/18/07, Burton Strauss III <[EMAIL PROTECTED]> wrote:

There is one other trap here - ntop uses the lower #ed port to figure out
traffic.  This works ok for protocols which use reserved ports, such as 389
for ldap, since the tcp/ip session is from 389 <-> >1024.

Once you get into protocols which use high numbered ports, this will
mis-classify.

I have long wondered why updating protocol.list would not always classify
traffic correctly, finally an explanation.

Do you think it would be simple to change ntop so that it used protocol.list
for the classification of all traffic regardless of whether the port is <
1024 or not?

Or if there are some potential implications to that change, might it be
possible to add a switch so that optionally ntop could classify all traffic
based on the contents of protocol.list rather than just traffic with ports <
1024?

Vaughan

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.4/860 - Release Date: 6/21/2007
5:53 PM

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to