Which of the following ports is the best one to use for a program. I'm working on using a custom protocol still under development. I'm looking for one that will be accessible to virtually every host that is connected to the public Internet (that is, every host that can view websites can use this port). The three main options are:
port 53 UDP (DNS)
port 80 TCP (HTTP)
port 443 TCP (HTTPS)
Which of these is most widely accessible over the Internet, including all ISPs, corporate firewalls, etc.
All of those ports are used by well-known services, and you should use none of them (if your product is not a webserver or a DNS server.) DCCP Well Known ports SHOULD NOT be used without IANA registration. If your service is commercially viable or has benefits for the network as a whole, consider registering it for a lower port number: The registration procedure is defined in RFC4340, Section 19.9.
For experimental use, use a port between 1024 and 49151. Remember that even those ports should be registered with the IANA as soon as your service goes "live".
Regarding firewalls: You cannot predict if your service will be available to any network at all. Even if you use port 80, you probably will run against firewalls that do content checking.
Not port 53. Toss-up between 80 and 443. If you make your protocol look sufficiently like HTTPS that a proxy will forward it the same way, then maybe 443 is your best choice.
As all the ports you've nominated are used for particular well-specified protocols, it's a very bad idea to use these for a different protocol. There's a convention that for a well-known port, there's a corresponding protocol, and if you break this convention, then at the least you're going to cause confusion, and at worst be suspected of nefarious intentions and be blocked. Martin's answer points you in the right direction.
Related
I've been investigating networking for use in a two-player game I'm writing, and I'm still not clear on when a device must have a port forwarded in order to communicate with the outside world.
From what I've seen in other games, port forwarding is always required in order to host a server, but is not required on the client. In addition, there are other situations, such as skype (which, to my understanding is ultimately client to client), where neither end must forward a port.
So my question is, in over-the-Internet communication, when is and isn't port forwarding necessary, and what steps can i take as a developer to make it so my users don't have to worry about it? Thanks in advance!
Port forwarding is needed when a machine on the Internet needs to initiate a connection to a machine that's behind a firewall or NAT router. If the connection is initiated by the machine behind the firewall, the firewall/router automatically recognizes the reply traffic and sends it to the machine that opened the connection.
But if a packet arrives on the external interface, and it's not a part of such a connection, the router needs to know what to do with it. By default, it will reject it. But if forwarding is configured for the port, that tells it what internal machine to send it to.
Put another way: you need port forwarding if you want to run a server behind the NAT firewall/router, you don't need it if you're just running a client.
There is reason why Skype don't (not always) need manual setting of port forwarding:
When you install Skype, a port above 1024 is chosen at random as the
port for incoming connections. You can configure Skype to use a
different port for incoming connections if you wish, but if you do,
you must open the alternative port manually.
If the port chosen for incoming connections becomes unavailable, by
default ports 80 and 443 will be used as alternatives. If another
application (such as Apache HTTP server or IIS) uses these ports, you
can either configure the application to use other ports, or you can
configure Skype to not use these ports.
Port forwarding is must if you host a server.
You can use same technique as Skype...
I am not sure if there is any other option...
Port forwarding (occurs) when a NAT, firewall or some other device blocks communication on all or some ports.
To answer your question as an example, most commercial routers use NAT to allow multiple people to use the same IP(As view from the outside world) provided by ISPs. Most ISP's use NAT to allow multiple customers to use the same IP(As viewed from the outside world). To get this to work, the NAT changes the internal IP and the port number of a communication to THE(there is only one for the entire sub network) external IP and a new port number. By doing this, the router/isp/ect can tell which internal IP and port each external communication goes to.
Anytime one of the computers communicating over the internet are behind a NAT, port forwarding is required. I'm sure there are way more situations than this, and the solution to each can be quite complicated. But this covers the vast majority.
I am required to implement a p2p communicator and read about nat hole punching. There are a few questions I don't quite understand:
Do I really require a server if I know the public IP address and destination of my peer?
In real life scenario, does it really work and what are some network policies that may cause it to fail
For Skype, why does it optionally also require 443 and 80 if theoretically works for any Ports?
The main purpose of a server is for helping to detect how private addresses are translated into public adresses, and this is only visible from outside the LAN.
Do I really require a server if I know the public IP address and destination of my peer?
No.
In real life scenario, does it really work and what are some network policies that may cause it to fail
Unless the port your are trying to reached is bloqued by a firewall, there should be no issue if you know the public address of your peer.
For Skype, why does it optionally also require 443 and 80 if theoretically works for any Ports?
Because those ports are usually open (i.e., not blocked by NATs/Firewall), while others are not necessarily open.
Port Number is the logical connection to a specific software on the hardware machine. Then there should be a relation between the set of softwares in the Web Server and the Port number used in the Requested URL. However, it seems that there is a relation between Port No and the Application Layer Protocol (from Internet Protocol Suite) used such as HTTP (80), FTP (21), Telnet(23), etc.. Why is it so??
I referred a similar question here on stackoverflow. As answered by Aaron Maenpaa, there is not a strict one-to-one correspondence between a Protocol and a Port. It is just a convention used. We can have HTTP listen on some other port as well (say 8080). Then how can we do it??
This leads to another question.
How do we map a custom server program to some non-standard TCP port number?
Any application can bind() to any available port, with the exception of low-numbered ports which may require administrative privileges. There is absolutely no enforcement of what type of application listens to what port number, just convention. That's because the port number itself is just a 16-bit field in the packet headers and there is no practical way for the operating system to know what is going on at the application level.
Typically, the port number an application listens to is determined by the application itself: it has to decide what port to hand to the bind() call. External to an application you can use NAT (Network Address Translation) in a router or firewall to redirect any port number to any other port number.
Note that TCP ports are completely independent from UDP ports. An application using TCP port 12345 has absolutely nothing at all to do with an application using UDP port 12345. A firewall which allows or blocks one does not automatically allow or block the other.
Unfortunately, this point is often confused by the fact that IANA (keepers of the unenforced conventions as to what applications use what port numbers) has decided to assign service names to both UDP and TCP ports even if the service only uses one of them.
I don't really understand the differences between the different ports. I couldn't find any useful resources online that would go into detail about it. From what I can understand, it acts as some kind of filter that blocks out any other request not using the same port number.
When will I, if ever, need to change the port number when typing in a website in my browser? What about if I am running my own website? Are there any risks I take when using port 80? As in, are there ways to use different port numbers to hack into a website?
And since a Simple Mail Transfer Protocol uses port 25, could I use this knowledge to send emails using self written programs?
By conventions and standards, defined protocols generally listen on defined ports by default. You can set any service to listen on any port you want, just be aware that changing from a standard port means that standard tools would need to be explicitly told to use your non-standard port.
For example, if you run a web server then by default it's probably listening on port 80. So all someone needs to do to visit your server is use the address:
http://www.yourserver.com
However, if you change it to listen on a non-standard port, such as 81, then any user who wants to visit your site will need to specify the port number:
http://www.yourserver.com:81
The standard convention of just using the address wouldn't be sufficient, because you've broken convention. Now, this is fine if you don't want people randomly using your site and only want it to be available to people to whom you've told the port number. This is called "security through obscurity." It doesn't actually secure your site in any way or filter out anything, it just adds an additional step to the use of the site.
As for SMTP, yes, you can write programs to connect to port 25 on SMTP services and send data to those services. You may indeed be able to spoof emails in this manner. However, most services have other built-in checks and balances to prevent such spoofing.
TCP/IP supports 2^16 ports on a machine. A server program is said to listen on a specific port; other machines contact a server program at a machine using the port number and the name of the machine. It's like the address on a letter.
Some port numbers are "well known", which just means they're officially assigned for a particular service: port 80 is for web servers, port 25 for SMTP, port 25 for telnet, etc.
But any server can run on any port; it's just a matter of changing the code or the configuration. Sometimes you may way to run two separate web servers on one machine; one might listen on port 80, and the second one on some other port (8080 is a common choice for servers used during development.)
So the client can't meaningfully change the port to some random number: there has to be something listening on that port, on that machine, or it doesn't do anything.
There is no 'difference' between running a web server on any port number, from a purely technical perspective, as long as the client and the server both know which port to use. When the client connects to the server, it has to know the IP address as well as the port.
By convention, several ports are used by standard services. For example, port 25 is SMTP, port 80 is the http port, 22 is the ssh port, etc. Because of these conventions, ports less than 1024 are reserved by the operating systems and can only be opened by a root process.
Unless there is a specfiic reason, it is generally a good idea to stick with the standard port numbers. Advanced port scanners/ analysis tools will try all ports on a system, so there isn't much benefit to running a service on a non-standard port.
The port numbers are a way of multiplexing communications over IP links. This is commonly used to provide specific services on accepted port numbers. HTTP servers have been allocated port 80 for listening for incoming client connections, though this is not a lock - there is nothing stopping you constructing/configuring an HTTP server that listens on port 9001, or whatever. If you did use a non-standard port number for your server, then you would have to specifically instruct a browser to connect to that port, rather than defaulting to 80 as it normally does.
SMTP in port 25 using your own program - sure, you can do this. Any mail app is some developers' 'own program' .
Rgds,
Martin
I have two dedicated servers and no hardware firewall. I'd like to forward all requests that come into the primary server on port 1008 to be fulfilled by another dedicated server on the same network. I know I need to set up some kind of TCP proxy, but I first heard of IPTables yesterday. Any quick tips?
The easiest way is to use something which is just a TCP proxy. It is possible to achieve this using iptables, but not easy.
It is easy to forward requests from A intended for B to C (using DNAT) but harder to get C's responses to go back to A via B (because DNAT does not change the sender address). A would then ignore the responses as they'd be coming from C rather than B.
Essentially the way of doing it would be to set up B as C's default gateway, and using forwarding, however, this places an additional point of failure in B; if B fails, C's outbound traffic (including responses to requests sent to C directly) would end up going down a black hole.
Using IPtables it is possible without this routing trick I think, but you'd need to have the same connection SNAT'd and DNAT'd, which is tricky at best.
Normally in such situations, most people put another host (firewall) in front of the two machines and have it make DNAT decisions - of course this introduces a point of failure as well, which is why in critical setups, the firewall typically has a rendundant backup (its configuration is synchronised and sometimes its connection tracking table is)
Carson is right: put a bridging firewall between servers and clients. Shorewall (IP tables) can then redirect traffic to different ports and different machines.
With the firewall being a bridge, you don't have to change your network settings, yet the bridge interface has to be assigned one IP address of each network clients and servers are in. Else the redirection won't work.
Caveat: the machine where the connection originally was pointed to has to be online (means: its IP address has to be in use), else the redirect won't work.
If the redirection is meant as a means of failover for high-availability, I would consider a load balancer (cluster) instead of the firewall, which leads to linux virtual server (for a general approach) or to a load balancer software like Apache (with mod proxy_balancer), balance or pount (if only http request are to be balanced). There's also hardware appliances like from f5 for load balancing.
First off I would recommend you get a firewall in place. I've used Shorewall for a long time to manage iptables and it is pretty easy to configure. Second if you use something like Shorewall there are easy guides on how to do DNAT (port fowarding).