Nope. Or more precisely
* It's of really limited value. Except for the occasional web
server on 8000 or 8080, most services which our users care about really do use
well known ports < 1024 for which the algo we use is accurate. P2P is close
to impossible to track 100% anyway...
* It's not
infeasible, but it's not pretty.
Of the top of my
head and in no specific order, the specific issues
are:
Zeroth, we don't really care who is the sender and receiver
- that's implicit in the packet. In fact all we need is the SYN-ACK, which
is the 1st time the mapping is there, albeit inverted.
First off, you would have to SEE the 3-way - which is only
true if ntop is up at that time, which is an issue with long running
connections.
Secondly, we couldn't purge idle but long running
connections or we would lose the info. Or we would have to implement a partial
purge or make it smarter about who to purge, but then what if we simply missed
the RST - we would retain that host record for ever...
Third we would have to track every port on every host -
tons more memory. It's is either a fast array of 64Kx4 or a linked list of (some
value n)x8 bytes (but that's a lot more overhead and more complex to
track). By using the port# the way we do, we track only what we are
told to track. It just gets added to the 'http' bucket on both
hosts.
Fourth, that's true only for TCP. What about
UDP?
Fifth, what if we are outside the gateway/firewall and are
seeing NATed traffic?
Sixth, we would need to pickup the RST to tear down the
mapping.
Seventh, every packet would have to be processed
against the array/linked list (slow).
Eighth, we would need a fallback for situations where
we didn't see (for whatever reason - dropped packet, etc.) the
SYN-ACK.
-----Burton
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Art
Sent: Monday, January 30, 2006 11:06 PM
To: [email protected]
Subject: Re: [Ntop] Why edonkey and Kazaa Traffic is coming
Maybe this is what you meant by "even if we were to write the deep packet inspection code" but even if you are only passively sniffing traffic can't we derive the server/client relationship based on the three-way handshake. Actually, we probably only need to care who sends the syn and who sends the syn-ack. SYN sender is always going to be the client and SYN-ACK sender is always going to be the server. Right?
I always just assumed ntop decided the relationship this way, but after reading this thread and looking at the connection details in ntop for a local webserver which listens on port 8080 I now see that your statement is correct. The client connecting with source port 4000 and downloades data was showing up as sending data.
So I guess my question is why can't we replace the "lower port # = server" algorithm with the "SYN sender = client" algorithm. The answer might be very easy and make me feel stupid, or might be very confusing and make say "well now i understand", but I figured I would ask ask.
Thanks,
Seth
On 1/6/06, Burton
Strauss <[EMAIL PROTECTED]>
wrote:
That's the most likely answer. Esp. with p2p, VoIP and other protocols that
use random high ports. If there's enough traffic, there will be collisions
between port #s.
You do need to keep an eye on things, as some of the trojan's use those high
port #s for their servers - and if those are out there, the lower # may well
be the random port of the reply channel.
Unfortunately, these P2P protcols are problematic, since even if we were to
write the deep packet inspection code, there's no place on a switched
network to put the ntop sensor that would see all the traffic. It's one
thing if you are acting as the router (read up on Linux's connection
tracking, for example), it's another if you are passively seeing packets.
Since we can't be sure, we have to guess and that (lower port # recognition)
is our "best guess" algorithm.
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of
Vivek Kedia
Sent: Friday, January 06, 2006 1:15 AM
To: [email protected]
Subject: RE: [Ntop] Why edonkey and Kazaa Traffic is coming
Hi Burton,
You are right , it is usually a small amount of traffic (less than few MBs
)that is shown as Kazaa / edoney, so basically in layman terms it means that
there is no actual Kazaa/Edoney traffic but rather a misinterpretation of
port #
regards
vivek
--- Burton Strauss <[EMAIL PROTECTED]> wrote:
> If you check the article in docs/FAQ, you will see that ntop uses the
> lower port # of the packet for classification.
>
> Remember, part of the tcp/ip protocol involves a random port # - say
> you connect to x.y.com on port 80 - the return path uses a random port #.
>
> This works great when one of the port #s (the lower #) is obvious.
> But many protocols use two random port #s or have a high # as their
> 'well known #', and so ntop CAN be confused. In some cases we do a
> deeper analysis on the packets (e.g. ftp), but not all.
>
> Port #s are just #s. You CAN use a port for anything, as long as the
> two sides (sender and receiver) agree. That can lead to unexpected
> classification. Some protocols do this deliberately, i.e. AOL uses a
> variety of port #s if the default, 5190, is blocked for any reason.
>
> And so on. This is usually a small amount of traffic.
>
> -----Burton
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf
> Of Vivek Kedia
> Sent: Wednesday, January 04, 2006 10:45 PM
> To: [email protected]
> Subject: Re: [Ntop] Why edonkey and Kazaa Traffic is coming
>
> Hi All,
>
> I am using NTOP to moniter around 50 PCs in my office and some of the
> days i see edonkey and Kazaa traffic on few of the workstations even
> though dont have any file sharing software installed on them , what
> can be the reason that ntop is seeing some of the data trf. as being
> from kazaa / edonkey,
>
> can it be a virus / ntop misreading the data transfer.
>
> since the workstations keep on changing so i dont think that its a
> virus , maybe ntop?
>
> regards
> vivek
>
>
>
> __________________________________________
> Yahoo! DSL - Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
__________________________________________
Yahoo! DSL - Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
