Port number <=> application 2

[Tschibo]

Hi!
By looking at the packets sent/received by client machines and analyzing the time it took i'll try to get informations about applications and round-trip-delays.
From looking at the port number, can i definitely say, which application is communicating? I know the IANA list, but is it likely, that the ports are really used that way they're registered for?
Is there any additional information i can get from TCP packets about the status of the application on the server (e.g. special flags set)?
If an application on the server crashed, is the TCP port still listening?

Thanx for your help
Christoph Ballhause

 

[CCIEWANNABE]

You can verify the Header sizes in the packets to verify the Protocol in use. The most common ports will corresponded to IANA listing. Only on occasion will you reconfigure port assignments for security reasons. In example the usage of FTP ports. TCP, UDP, SNMP, SMTP, will always remain the same if there intend use is to communicate outside there organization. Obviously, there are many other ways to detect port scans, including dumping all the packet headers to a file and analyzing them manually (ouch).
Useful Sites Related to Port Scanning.

http://www.nessus.org/

http://www.antionline.com/index.php

Route once; switch many

 

[Tels]

Try IRIS, (network packet sniffer) I'm not selling it (I don't think it's worth the money) but you do get a full function trial, it would answer all your questions instantly.

Function-wise, all scanners should be this good (but aren't)

HTH

Tels
Mixed Linux/Win2000 Network Administrator

 

[pansophic]

One of the problems with using port numbers to identify the traffic type is when you get into the use of ephemeral ports, especially the ones between 1024 and 5000. These are the ports that are used by the client when access a server commonly, but there are several services that use them as well.

I don't know how many times I have told people that they are not actually using Lotus Notes (1352) for email. If they check their IDS log, the connection is between 1352 on their machine and port 80 on the remote. It is really someone who is web browsing.

Generically though, the port number works OK as the service criteria. Particularly if you can sort by socket (IP address and port number). Any connection to port 25 on your mail server is most certainly SMTP.

Your margin of error should be quite small using sockets for analysis.

pansophic

 

[Tschibo]

First let me thank you all for your help!

pansophic:
It is clear to inspect the target port, i.e. the port on the server when sending a request or the port on the client when receiving the answer.

One of the major problems could be, that applications use ports not registered to them or even worse registered to other applications. I guess this might happen due to sloppy programming or misconfiguration, but how likely are such things?
Because in my project i can't afford to fingerpoint at the wrong applications.

Christoph

 

[pansophic]

ChristophBallhause,

the theory is that only one application can bind (listen) on a port at any given time. In practice, this is not completely true, but for the sake of argument, let's say it is.

Commercial software makers will bind to the IANA standard port for the service that they are providing, in order to allow interoperability (which is what the Internet is all about). Comercial applications will avoid "well known service" ports at all costs if their application doesn't support that service, again for interoperability reasons.

So, what you are left with is the small subset of non-commercial applications that will mis-use (or abuse) the ports on a given machine.

So, if you are still concerned with this small (and what should be insignificant) margin of error, you should do some other things to verify packets. The easiest way that I can think of is to profile each protocol that is known, so that you can quantify the likelihood that it is real traffic.

So, watch the SYN, SYN-ACK, ACK packets bound for the mail server's port 25, then look for an SMTP header outbound and then MAIL FROM inbound in the next two packets. It is nearly 100% likely that this is an SMTP transaction.

Likewise, watch the SYN, SYN-ACK, ACK exchange to port 80 on the HTTP server, then look for GET or POST, etc. and Host=

http://www.company.com

in the next inbound packet and it is nearly 100% likely that this is a Web connection.

Of course all of this means caching a lot of information, but it is similar to the way that a stateful inspection firewall works. Also, lots of IDSs do a similar tracking of state.

Does this help with your issue?

pansophic

 

[wybnormal]

I also have several links about this sort of thing.

Sniffer here

http://www.packetattack.com/network_analysis_sniffers.html

Defense Links here

http://www.packetattack.com/1001_sub_page_3_3.html

If you have other links, just email me with them and I will include them in the various pages.

MikeS
Find me at

http://www.packetattack.com

"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu