Multiple services on a single port ???

[kybrd]

Good day

I am not sure if this is the correct place to post this type of question but here goes.

#############

A friend and i where sitting down one day and had a disscussion whereby if two services could share a port if a firewall was blocking all outgoing communication but allowed tcp traffic to flow through a single port.

The answer is yes as long as both services are not running at the same time.

If it was a linux server with a dedicated service binded to the port for e.g httpd -> 80 - I would then say no.

but we found that to not be true. especially if it the "e.g. victim in mind" where to be a normal pc user hiding behind a router.

Our senario....

If for example a local computer user were to be connected to the internet port 80 would then be open to browsing the net with a webbrowser all other ports would then be filtered.

If for example a e.g "netcat" session where to send information via the same port "at the same time as the browser requesting and sending info" to an attackers machine via port 80.

Why oh why does it take so long to produce output of a simple cd .. or ls command.?

It works across the internet and tried and tested multiple times "the victim always connects back to the attacker but commands are extremely slow".

[lupin]

A friend and i where sitting down one day and had a disscussion whereby if two services could share a port if a firewall was blocking all outgoing communication but allowed tcp traffic to flow through a single port.

Well the exact details of how this would work are dependant on whether the firewall is stateful and whether it is filtering based on any other criteria (e.g. source or destination IP). Assuming a stateful firewall filtering only based on destination port number, ANY outgoing session to the appropriate port will be permitted - the source system, source program or destination system or service doesnt matter - as long as the service can receive communications on that port. The filtering rules of the firewall will implement no limits to the number of sessions that can run at the same time (although other characteristics of the network topology might), so two or more sessions should not be a problem.

It is possible for two services to share a listening port on the same destination system (certain trojans can do this), but normal programs dont usually do this. Most normal (non malicious) programs wont bind to a port if another program is already listening on it.

[kybrd01]

@luping Thanks for replying....

correct me if i am wrong...i will now give you a more detailed example

but normal programs dont usually do this. Most normal (non malicious) programs wont bind to a port if another program is already listening on it.

I understand what you are saying...

1. these are not malicious programs....e.g trojans
2. the program e.g. netcat is not listening it's sending "connecting" to attacker
3. the attackers machine is in listening state waiting for connection from victim

the original idea came from a windows pc using "windows firewall" through a dialup connection "direct internet" while having "e.g netcat connecting to the attacker" all via port 80 same as a webbrowser while the normal windows pc user is viewing google all commands executed with speed.....even uploads....

now we applied the same technique but towards a windows pc hiding behind a router "NO port forwarding enabled victims side" while the user is using his webbrowser viewing google. e.g. netcat connects from the victim to the attacker "behind router - port forwarding enabled e.g netcat listening via port 80" but commands are slow or freezes the attackers terminal "always".

Why are the commands so slow or failing...?

[lupin]

@luping Thanks for replying....

correct me if i am wrong...i will now give you a more detailed example



I understand what you are saying...

1. these are not malicious programs....e.g trojans
2. the program e.g. netcat is not listening it's sending "connecting" to attacker
3. the attackers machine is in listening state waiting for connection from victim

the original idea came from a windows pc using "windows firewall" through a dialup connection "direct internet" while having "e.g netcat connecting to the attacker" all via port 80 same as a webbrowser while the normal windows pc user is viewing google all commands executed with speed.....even uploads....

now we applied the same technique but towards a windows pc hiding behind a router "NO port forwarding enabled victims side" while the user is using his webbrowser viewing google. e.g. netcat connects from the victim to the attacker "behind router - port forwarding enabled e.g netcat listening via port 80" but commands are slow or freezes the attackers terminal "always".

Why are the commands so slow or failing...?

Yep, I understand your scenario. If the firewall is allowing outbound traffic on TCP port 80 there is no reason why the filtering rules of the firewall should be preventing or slowing down your connection. The problem could be that the device performing NAT/PAT translation is getting overloaded, or the firewall is getting overloaded, or the link is saturated, or some sort of rate limiting is being applied, or a bug in one of your devices, or a number of other things. Check the stats on the various devices, and perform packet captures to troubleshoot.

But if a stateful firewall filter is configured to allow outgoing traffic based on a destination port number, its basically just checking either that the packet being processed is associated with an existing session (by checking a state table) or that it contains the right data in the TCP header (only the SYN flag set and destination port = 80). Unless application inspection is being performed (and unless you have an enterprise firewall like a Checkpoint, Sidewinder, etc its probably not) its really no more complicated than that.

There are no set limits on the amount of TCP connections internal systems can make to a particular external post. The combination of source IP, destination IP, source port and destination port for simultaneous TCP sessions have to be unique, but since source ports are chosen from a large range by the client and not reused unless previous connections using that port are freed this is not normally a problem.