How should one go about choosing a default TCP/IP port for a new service? - networking

When developing an app that will listen on a TCP/IP port, how should one go about selecting a default port? Assume that this app will be installed on many computers, and that avoiding port conflicts is desired.

Go here and pick a port with the description Unassigned

First step: look at IANA listing :
There you will see at the tail of the list
"The Dynamic and/or Private Ports are those from 49152 through 65535"
so those would be your better bets, but once you pick one you could always google on it to see if there is a popular enough app that has already "claimed" it

If by widely-used, you mean you want to protect against other people using it in the future, you can apply to have it marked as reserved for your app by IANA here

The most comprehensive list of official IANA port numbers and non-official port numbers I know is nmap-services.

You probably want to avoid using any ports from this list (Wikipedia).
I would just pick one, and once the app is used by the masses, the port number will become recognized and included in such lists.

Choosing an unassigned one from the IANA list is usually sufficient, but if you are talking about a commercially-released product, you really should apply to the IANA to get one assigned to you. Note that the process of doing this is simple but slow; the last time I applied for one, it took a year.

As others mention, check IANA.
Then check your local systems /etc/services to see if there are some custom ports already in use.
And please, don't hardcode it. Make sure it's configurable, someway, somehow -- if for no other reason that you want to be able to have multiple developers using their own localized builds at the same time.

If this is for an application that you expect to be used widely, then register a number
here so no-one else uses it.
Otherwise, just pick an unused one randomly.
The problem with using one in the dynamic range is that it may not be available because it may be being used for a dynamic port number.

Well, you can reference some commonly used port numbers here and try not to use anyone else's.
If by "open to the public at large" you mean you're opening ports on your own systems, I'd have a chat with your system administrators about which ports they feel comfortable with doing that with.

Choose a number that is not very common

Choose a default port that doesn't interfere with the most common daemons and servers. Also make sure that the port number isn't listed as an attack vector for some virus -- some companies have strict policies where they block such ports no matter what. Last but not least, make sure the port number is configurable.

Use iana list. Download the csv file from :
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv
and use this shell script for searching for unregistred ports:
for port in {N..M}; do if ! grep -q $port service-names-port-numbers.csv; then echo $port;fi; done;
and put 2 numbers instead of N and M.

Related

Would it be possible to create a Chromebook extension that would toggle the "Configure IP address automatically" network setting on and off?

Chromebooks at a certain facility will not work with static IPs, and they have reserved IP addresses, but for some odd reason they will not grab those from the DCHP server. By toggling Configure IP address automatically off for a few seconds and back on, the Chromebook gets its reserved IP and works fine. In about 6-8 months we will be changing the entire network and resolving this issue, but in the meantime if I could create a shortcut method for the end users to be able to do this easily it would be a big stone out of my shoe...
I had forgotten I posted this. In order to resolve the issue, I did use "code" and "programming" to create a script that would do what I described above. So, it wasn't a networking question, it was a programming question.

Looking for SFTP-Stresser/Fuzzer

I am working for a company that is providing File-Share-Software for all sorts of Protocols such as FTP, SFTP, FTPS and so on. One of our customers is facing an issue with Key-Auth and spontaneously login-problems.
Going trough the code I am pretty certain that the server collapses with too many requests at the same time. What I need right now is a simple tool to test a situation just like this. I need a simple SFTP-Fuzzer or Stresser, sending invalid or broken Auth-Attempts to the SFTP-Server.
I am not a developer but a technician and instead of writing something myself (which would take forever) I would love to have a simple script or toolset to go...if there is one.
Ok, found one faster than I thought.
Steps:
Download Kali Linux (or any Distro that contains Metasploit)
Fire up Kali Linux and put it in the same subnet as your SFTP-Server
Start Metasploit and use the SSH-Fuzzer /auxiliary/fuzzer/ssh/ssh_version_2
Set RHOST and RPORT to the relevant IP and port your server is listening to
Exploit and see what will happen

Using OpenWRT with OLSR to connect routers using HNA

As you may assume I need a little assistance here.
I have four routers (TP-Link WDR3600) that I need to use to create an Ad-Hoc network. Currently I am only dealing with two of the four routers for simplicity. All of the routers have OpenWRT Chaos Calmer 15.05 OS installed on them and all of them are running the OLSR routing protocol. My question is super simple but the answer eludes me and I would love some direction on the matter.
How do I get these two (and eventually four) routers to talk to each other using HNA (Host and Network Association) and the setup specified above?
Edit: they need to be connected to each other wirelessly too. End edit.
I have followed this specific guide to the T but as soon as it gets to "HOW TO Step 4" the guide breaks down in terms of application because the file they point to (/etc/olsrd.conf) does not exist in my setup. When continuing anyway and running "olsrd start" it spits out: Notice how it says "Could not find specific config file /etc/olsrd/olsrd.conf" and how that differs from earlier when it asked me to modify "/etc/olsrd.conf"
In addition, the folder "/etc/olsrd" also does not exist in case you are wondering. I'm at a loss regarding this. Does anybody have any input on the matter? I'm certain that I'm missing something simple.
Thanks in advance.
I had to create /etc/olsrd.conf using the template provided and uncomment the third line of /etc/config/olsrd. I would also recommend installing olsrd-mod-httpinfo using opkg like he recommends.
One thing I noticed is that he never specifies giving the wireless interface (wlan0 in my case) an IP address to communicate with the mesh. Since I believe that is required, I had to use LuCI to give the interface an IP. I think I have my setup working but I am trying to get my new OpenWRT node to communicate with my previous DD-WRT nodes right now. Might just have to change them all to OpenWRT since it offers more "customization" due to it's bare-bones type configuration.
Can you try to run :
/usr/sbin/olsrd -d -f /etc/olsrd.conf

Let two UDP-servers listen on the same port?

I have a client which sends data via UDP-broadcast. (To let's say 127.0.0.255:12345)
Now I want to have multiple servers listening to this data. To do so on a local machine, they need to share the port 12345 for listening.
My question is, if that is possible, if there are any disadvantages and if there could be problems with this approach.
There is one alternative which unfortunately brings with a lot of overhead:
Implement some kind of registration-process. On startup, each server tells the client its port. The client then sends the messages to each port (having to send the data multiple times, some kind of handshaking needs to be implemented...)
Do you know any better alternative?
If that matters:
I'm using C++ with Boost::Asio. The software should be portable (mainly Linux and Windows).
You will have to bind the socket in both processes with the SO_REUSEPORT option. If you don't specify this option in the first process, binding in the second will fail. Likewise, if you specify this option in the first but not the second, binding in the second will fail. This option effectively specifies both a request ("I want to bind to this port even if it's already bound by another process") and a permission ("other processes may bind to this port too").
See section 4.12 of this document for more information.
This answer is referenced to the answer of cdhowie, who linked a document which states that SO_REUSEPORT would have the effect I'm trying to achieve.
I've researched how and if this option is implemented and focused mainly on Boost::Asio and Linux.
Boost::Asio does only set this option if the OS is equal to BSD or MacOSX. The code for that is contained in the file boost/asio/detail/reactive_socket_service.hpp (Boost Version 1.40, in newer versions, the code has been moved into other files).
I've wondered why Asio does not define this option for platforms like Linux and Windows.
There are several references discussing that this is not implemented in Linux:
https://web.archive.org/web/20120315052906/http://kerneltrap.org/mailarchive/linux-netdev/2008/8/7/2851754
http://kerneltrap.org/mailarchive/linux-kernel/2010/6/23/4586155
There also is a patch which should add this functionality to the kernel:
https://web-beta.archive.org/web/20110807043058/http://kerneltrap.org/mailarchive/linux-netdev/2010/4/19/6274993
I don't know if this option is existing for Windows, but by defining portable as an attribute for software which runs on Linux too, this means, that SO_REUSEPORT is OS specific and there is no portable solution for my question.
In one of the discussions I've linked it is recommended for UDP to implement a master-listener which then provides the incoming data to multiple slave-listeners.
I will mark this answer as accepted (though feeling kind of bad by accepting my own answer), because it points out why the approach of using SO_REUSEPORT will fail when trying to use it with portable software.
Several sources explain that you should use SO_REUSEADDR on windows. But none mention that it is possible to receive UDP message with and without binding the socket.
The code below binds the socket to a local listen_endpoint, that is essential, because without that you can and will still receive your UDP messages, but by default your will have exclusive ownership of the port.
However if you set reuse_address(true) on the socket (or on the acceptor when using TCP), and bind the socket afterwards, it will enable multiple applications, or multiple instances of your own application to do it again, and everyone will receive all messages.
// Create the socket so that multiple may be bound to the same address.
boost::asio::ip::udp::endpoint listen_endpoint(
listen_address, multicast_port);
// == important part ==
socket_.open(listen_endpoint.protocol());
socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true));
socket_.bind(listen_endpoint);
// == important part ==
boost::array<char, 2000> recvBuffer;
socket_.async_receive_from(boost::asio::buffer(recvBuffer), m_remote_endpoint,
boost::bind(&SocketReader::ReceiveUDPMessage, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)

Do I need to register ports as "in-use" with ICANN?

The application I'm currently working on requires three ports to be opened. At the moment these are 5024 through 5026 but on reading around I discovered that these lie in the ICANN registered range (i.e. ports < 49151).
Is there any need for me to inform any organisation that I plan to use these ports if it's within a local network only or can I just go ahead and use them?
You can just go ahead and use them. The only way you'd need to notify ICANN is if you were going to have a significant number of clients using those ports in general use; in that case, you would want to try to register the application with the port to prevent potential collisions with other applications using those ports.
How big of a project is it? If there are more than a few thousand internet-exposed users, you may want to investigate informing them somehow. If its on a closed LAN of any size, it doesn't matter at all.
the language in the relevant RFC is that applications SHOULD NOT use unregistered ports. Nobody's going to sue you if you use them; the only issue you'll get is that if someone else decides to (1) use the same port (2) not register it, you'll confuse the heck out of each other. As McWafflestix says, you can go ahead and use them.

Resources