Do reserved TCP/IP ports require that a program is running and bound to the port? If no such program is running or exists, can another program use this port? For example, on Linux, port 7 is reserved for an echo server. I assume there is some program running and is bound to port 7 of the machine. The program basically echos back input. If this program is stopped, will port 7 be released?
If I wrote my own echo server and bound it to some other port, wouldn't this port be released once my custom echo server program is killed?
Does the same thing happen for reserved ports?
Also, if all these programs are running on reserved ports, wouldn't they consume system resources even if they are blocked listening for a connection? Are these programs running at all times?
Do reserved TCP/IP ports require that a program is running and bound to the port?
No.
If no such program is running or exists, can another program use this port?
Nothing to stop you, but it's still reserved, and users are entitled to complain to you if you misuse ports reserved for something else.
For example, on Linux, port 7 is reserved for an echo server. I assume there is some program running and is bound to port 7 of the machine. The program basically echos back input. If this program is stopped, will port 7 be released?
Yes.
If I wrote my own echo server and bound it to some other port, wouldn't this port be released once my custom echo server program is killed?
Yes.
Does the same thing happen for reserved ports?
Yes, of course.
Also, if all these programs are running on reserved ports, wouldn't they consume system resources even if they are blocked listening for a connection?
Yes.
Are these programs running at all times?
Either they are running or they aren't running. You're asking about both situations at the same time. If you mean 'executing', i.e. consuming CPU, the answer is no, they are blocked waiting for connections while there are no connections.
ports 1-65535 are available, and ports in range 1-1023 are the privileged ones and using for standard applications.
And there will be Ephemeral port range also exists in your system and it can be found as follows:
sysctl -A | grep ip_local_port_range
Epeheral port range is available for all your client sockets.
When there is a server, client communication most of the time communication is happening using a socket. Socket is nothing but a pair of IP address and a port number. All the port referred usually with configuration will be a server port configuration and client port is dynamically choosing from the Epeheral port range. In case of epeheral ports, system may not release the port until this range is exhausted.
You can check port availability by using command:
netstat -a | grep <port number>
[EDIT]
The idea of a reserved port is that any custom software you write should take care to avoid binding to them, to avoid interfering with an established service. Further, non-root users can't bind any ports below 1024 anyway, many of which are registered with IANA (aka reserved).
There's no requirement that a particular process be bound to any port. A port is just a system resource. Typically a master inetd starts early in the system boot sequence, binds to some low-numbered ports, and handles the trivial services such as echo itself. These algorithms are so simple, and so infrequently used in practice, that very few resources are consumed. That's why you'll not find a separate "echo server" process. If you read the inetd.conf manual page:
http://www.freebsd.org/cgi/man.cgi?query=inetd.conf&sektion=5&manpath=FreeBSD%209.2-RELEASE
The inetd utility also provides several other 'trivial' services inter-
nally by use of routines within itself. These services are 'echo',
'discard', 'chargen' (character generator), 'daytime' (human read-
able time), and 'time' (machine readable time, in the form of the number of seconds since midnight, January 1, 1900).
Related
I've been reading lately about DNS cache-poisoning attacks. Essentially they are possible simply because an attacker can guess the DNS message transaction ID, since it is only a 16-bit integer. Even if the integer is random, it's still possible for a flurry of DNS packets to coincidentally match 1 of 2^16 packets in a short time window.
So a second security measure is port randomization. If the UDP source port is random, an attacker would have to guess both the source port and the transaction ID in a short time window, which is usually not feasible. But I read that older versions of DNS software such as BIND versions before 9 did NOT perform port randomization, and are therefore vulnerable.
This brings me to the question: don't most UNIX OS's like Linux and BSD automatically assign random ports when a SOCK_DGRAM is used without a prior call to bind? I thought that was the whole idea with ephemeral ports. Why does an application (like BIND) have to go out of it's way to perform port randomization?
My understanding is that, essentially, an OS like Linux will have a RANGE of ephemeral ports available for use with each process. A process can call bind() to bind a UDP socket to a specific port. But if a UDP socket is used (i.e. send is called) without first calling bind, the OS will lazily assign a random ephemeral port to the socket. So, why were older versions of BIND not performing port randomization automatically?
This brings me to the question: don't most UNIX OS's like Linux and BSD automatically assign random ports when a SOCK_DGRAM is used without a prior call to bind? I thought that was the whole idea with ephemeral ports.
The main idea of ephemeral ports is not to be random in a secure way, but just to pick some unused port fast. Different OS use different strategies, some do it a bit random, some use a stronger random generator and some assign the ports even in a sequential way.
This means not on all OS ephemeral ports are unpredictable enough for use with DNS.
For more details I would recommend to study RFC 6506 "Port Randomization Recommendations" and the overview about port selection strategies at https://www.cymru.com/jtk/misc/ephemeralports.html.
I need to launch several instances of a game in the same computer using Linux. The game is created launching a server at a specified port number (using a command line command with --port NUMBER as an argument) and then each of the players attachs itself to that port to play the game (in a similar fashion).
I need to launch hundreds of games in parallel through a little C program that uses the stdlib.h system library function (system(const char *command)) to launch the game server and the game players.
What I need to know is: how can I check from withing that C program that a port is available before launching the game server on that port number? It´s important to note that my program itself does not bind to any port, it just launchs (with system) the program that will actually try to connect to that port.
You have to use bind() directly, and if it doesn't succeed you can try another port.
Checking if a port is free and then binding is not possible and would be a race condition: You just checked, that a port was free, but someone already used it.
Reading /proc/net/tcp can help you though, but the race condition still applies.
The simplest way is normally trying to open a port and then handle the error as a already used port. A nice example can be found here
Three simple steps:
Try to open socket on the port you desire
If it works return true and close the socket
If not, return false
In the example given, they do it remotely, but you easily can change that.
Can and will an operating system reuse a source port number for a connection to a different destination address/port combination?
If I connect() to enough hosts, and keep those connections open, eventually I'll run out of unique source ports, exhausting the ephemeral range, the non-root range (1025-65,535; assuming non-root) or the absolute range (0-65,535). I want to know if those represent real limits to the number of hosts I can simultaneously have a connection to. I'm interested in what the standards promise (or don't), as well as the reality on Linux (Windows would be a bonus).
I know that opening that many connections will likely run into a number of other limits; that's a different issue and question. If it matters, this massive number of connections would be divided among a similarly large number of processes. I'm interested in the case where I'm requesting an ephemeral port, not manually bind()ing one. If under "normal" circumstances ports won't be reused, are there ways of changing that behavior from user-space (at which point bind()ing to a specific point becomes an option)?
By default, the kernel will not reuse any in-use port for an ephemeral port, which may result in failures if you have 64K+ simultaneous ports in use.
You can explicitly reuse a port by using the SO_REUSEADDR socket option and explicitly binding to the same port. This only works if none of the ports are listening (you can't reuse a listening port), and if you connect each socket to a different remote address.
In theory yes. In practice no, because bind precedes connect, and so it can't see what you're connecting to, so can't see that the 4-tuple would be unique, so won't let you reuse an ephemeral port.
Currently, I'm working on TCP client/server implementation in C. In that, I found that I can give any random number as a port number for my PC. Is it correct procedure? Or is there any standard port number for my PC?
I don't know the standard, but I say it's not. At least, I don't like to do it like that.
You can check occupied ports by parsing the outputs of programs like netstat and avoid using those. You can also use the method that attempts connecting on one port, and upon failure, tries another port. Unless you're really really unlucky, you should get a valid port on second try.
You should use ports within the ranges of 49152–65535. Ports below 49152 are reserved/registered.
Basically, you can use any port (given sufficient access rights). But server and client have to agree on the port, and it should not be already used by another application.
Hence, many ports are already reserved for special applications. 80 is for HTTP, 22 is for SSH and so on. The file /etc/services gives more detailed information.
Port numbers 0-1023 are called Well Known Ports, numbers 1024-49151 are called Registered Ports (not all of them are, but you get the idea).
If your question is whether you can give any port number to have your server listening to,
then you are thinking wrong, TCP/IP port numbers below 1024 are special in that normal users are not allowed to run servers on them, you can use non-privileged ports(ports > 1024). just make sure that any other application is not already using that port (above 1024) using netstat
Hii All,
While running a socket programme (server side ) am getting message like
Address already in use
Am trying to connect to port 80 since port 80 is reserved for https application So before running server side programme i am closing all application that uses https application ,is it enough...
or am doing it wrong??
Am trying to make a communication between browser and termial...
You must run your application as super user(root) on Linux or administrator privileges on Windows in order to bind to port 80. This is the case for all service ports, which is < 1024. Either that or there still is another program binded to that port.
Try using netstat to find out what programs might be listening on port 80.
Example:
on Linux:
netstat -punta
on Windows:
netstat -ban
Both must be run with super user/admin privileges in order to see the program names that bind to specific ports.
If you just closed another process listening on 80 port, this port will be blocked for a certain timespan depending on your OS. This behavior is here to prevent an attacker to crash a service on your machine and immediately restart a malicious service on the same port.
This behavior can be disabled by using SO_REUSEADDR (by using setsockopt).
If your main problem is to communicate from a custom server to your broswer, you can use any port in your server for providing HTTP (8080 is common for that), just specify the port in the url http://server:port/ (ie. http://localhost:8080/)