Hi Craig, There's also the issue of protocols that don't used fixed ports, e.g.
Microsoft Exchange, so unless you write a protocol decoder/handler, you'll never be 100% accurate (and this isn't an option if you're using [s|net]flow feeds).
I would agree that would pose a problem from a protocol.list perspective and that a protocol decoder would be needed in that instance (is that something a user can "write" or is that a development effort). I think you've also miss-interpreted what Burton said. Ntop does use your protocols.list file, it's just that when one of the ports is < 1024, it must be the port that defines the protocol, since outbound connections are on ports >1024. The assumption that all ports < 1024 defines the connection does not always
hold and this is what stuffs up ntop's classification of network traffic in some instances. I think there ought to be a way to override that assumption perhaps via the use of a switch which basically says to ntop to use the protocol.list to define traffic. Maybe this approach will not work for everybody in every scenario, which is why it ought to be a switch that a user can use when the situation warrants it.
I know for a fact that presently ntop does not classify rdp traffic and
eMule traffic correctly on my network even though I have identified the ports in the protocol.list file - in both cases that traffic uses ports above 1024 (which finally makes sense to me now given Burton's earlier post). It would seem to me the "solution" to the classification of this traffic, is a switch that tells ntop to use the protocol.list file regardless of the port to classify traffic. What I like about this approach, is that it is easy for a user to implement, you don't need to know how to write protocol decoders.
Vaughan
_______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
