How to manage ports on a VPS or dedicated server

What are ports? The easiest way to explain this is by analogy with buildings, where your server can be represented as a building or fortress, and ports are doors leading into that building. Some of them must always be open, while others must be strictly locked. And no one should even know about the existence of the third ones. And while the server looks like a single IP address or domain from the outside, inside it is bustling with activity. Inside, there are web servers, databases, control panels, mail services, APIs, queues, monitoring, and much more. All of these services communicate with each other and with external services through specific ports.

Improper port management is one of the most common sources of problems when working on VPS and dedicated servers. A poorly thought-out security strategy and an accidentally left open port on which one of the important services is running can lead to catastrophic consequences, from the trivial “why can't I open the site” in the case of a DDoS attack to full-fledged hacks, data leaks, and sudden blockages by providers. At the same time, the topic of ports seems simple only at first glance, but in practice it has many nuances, especially if the server is used not for trivial hosting of a single site on Apache, but as a full-fledged working infrastructure.

In this article, we will try to figure out how to properly manage ports on a VPS or dedicated server, what tools to use for this, and where even experienced administrators most often make mistakes.

 

 

 

 

What are ports and why are they critical for a server?

So, to simplify, a port is a logical number through which a service receives or sends network connections. And if an IP address answers the question of where to send packets, then a port answers the question of which service these data packets are intended for.

Classic examples of ports are known to everyone:

• 22 - SSH
• 80 - HTTP
• 443 - HTTPS
• 3306 - MySQL
• 5432 - PostgreSQL

 

But modern servers are rarely limited to this standard set. Add control panels, Docker containers, internal APIs, webhooks, monitoring systems, and the number of active ports can easily exceed several dozen.

The problem is that every open port is a potential entry point. Not necessarily for hacking, sometimes just for extra load, scanning, or automated bots. Therefore, port management is not a one-time configuration after system installation, but becomes an ongoing process.

 

Types of ports in a real server infrastructure

For ease of management, it is useful to divide ports by purpose:

Port type	Examples	Purpose
Public	80, 443	Accessible to all users
Administrative	22, 2087, 8443	Server management
Internal services	3306, 5432, 6379	Communication between services
Service / temporary	8080, 9000	Testing, migrations, debugging

 

This division helps you immediately understand which ports should be accessible from the internet and which can be accessible strictly within the server or private network.

 

 

 

 

How to see which ports are open on the server

The first step in any audit is to simply understand what is happening on the server here and now. Very often, the administrator is sure that only SSH and the website itself are open, because these are the services that he consciously configured. But the reality is almost always more complicated.

In practice, the server may be listening to a dozen other ports, because other services are running on the server, such as monitoring services, databases, temporary web servers for testing, containers, control panels, backup agents, etc. Some of them may have appeared automatically when packages were installed, some may have simply remained after experiments or migrations, and some may have been simply forgotten by the administrator.

The problem is that the server does not care whether you remember these ports or not, and if a port is listening and is not closed by a firewall, it is accessible from the outside. Therefore, before closing or configuring anything, it is important to first see the real picture: which ports are currently active, which processes are behind them, and on which interfaces they are accessible. This is where competent port management begins.

 

Checking ports on the server side

There are several basic tools available on Linux. The most universal way to see which ports are actually being listened to by services is:

ss -tulpen

 

This command shows:

• the protocol (TCP/UDP),
• the port,
• the process and user,
• the IP address on which the service is listening for connections.

 

There are also several alternative options for viewing open ports:

 

Key point: it is important to see not only the port, but also which process is using it. Often, a port is open not because you consciously enabled it, but because the service started with the default settings.

Checking ports from the outside

The server may be listening on the port, but it may be closed by a firewall. Therefore, it is useful to look at the situation from the perspective of an external client:

lsof -i -P -n

or

netstat -tulpen

 

And if you want to look at your server from the outside, then you can use the powerful tool nmap:

nmap -Pn your.server.ip

 

This is how browsers, bots, and scanners see the server.

 

 

 

 

Firewall as the main port management tool

Ports are not managed by services or specific applications, but by a firewall. It is the last and most important line of defense that decides who can connect to what on the server. A service can listen on a port, but if the firewall prohibits incoming connections, that port effectively “does not exist” for the outside world.

On VPS and dedicated servers running Linux, the following system firewalls are most commonly used:

• UFW - a simple and easy-to-use tool, popular on Ubuntu
• iptables / nftables - low-level mechanisms with maximum flexibility
• firewalld - a solution with zones and profiles, often used in corporate environments

 

Regardless of the specific tool, the principle is the same for all of them: only what is explicitly allowed is allowed. Everything else must be prohibited by default. This is a basic security model that has been in use for decades, described in a huge number of manuals, but is still regularly violated.

A typical situation is that the firewall is either not configured at all or allows too much, just in case. As a result, the server becomes accessible not only to the necessary services, but also to scanners, bots, and automated attacks. At the same time, problems may not manifest themselves immediately. For example, first the background load begins to grow, then strange connections appear, and then the server's IP suddenly ends up on blacklists.

A properly configured firewall solves several key problems at once: it reduces the attack surface, reduces unnecessary network traffic, and makes server behavior predictable. That is why port management should always start with a firewall, not with individual services or applications.

 

Which firewall to choose

The choice of firewall depends not so much on choosing the “right tool” as on the context of server use and your level of involvement in administration. All modern firewalls in Linux solve the same task of controlling network connections, but they do so at different levels of abstraction.

If you have a single VPS, a typical stack, and no need to build complex network logic, it is usually wise to choose UFW. It covers 90% of practical scenarios and allows you to quickly understand the current state of the rules without delving deeply into network details. This is a good option if the server needs to be secure but also easy to maintain.

iptables and nftables are suitable in situations where complete control is required, such as when using non-standard network schemes, fine-grained traffic filtering, high load, or integration with other security systems. The price of such control is complexity. These firewalls require accuracy, documentation, and an understanding of exactly how packets pass through the system.

firewalld is usually chosen in more structured environments, such as corporate servers, clusters, and systems with trust zones. It is convenient when there are many servers and it is important to manage rules logically, rather than with a set of disparate commands.

Whichever tool you choose, it is important to remember that a firewall is not a one-time configuration, but part of the infrastructure. It must be understandable to you and your team, otherwise over time the rules will turn into a chaotic set of exceptions that no one dares to touch.

Tool	Best suited for	Key features
UFW	VPS, single servers	Simple and readable syntax
iptables / nftables	Advanced configurations	Maximum control and flexibility
firewalld	Enterprise environments	Zones, profiles, service-based rules

 

A common mistake is to leave the firewall “for later.” It seems that the server is up, the services are working, the site is open, and that's it. But after a couple of months, strange requests appear, the load increases, the IP gets blacklisted, etc., etc.

A competent strategy is always the same:

• allow only ports that are actually used;
• restrict access by IP where possible;
• close everything unnecessary without regret; it's better to open it later if you cut off something you need.

 

 

 

 

 

Port management for SSH

SSH is perhaps the most attacked service on any server. And this is not an abstract threat from security textbooks, but an everyday reality. Just look at the logs a few minutes after installing the system to see dozens of automatic connection attempts from different IP addresses.

Bots constantly scan the internet for open SSH, try different logins, standard passwords, and outdated configurations. They don't care what exactly is running on the server or who it belongs to; any available port is seen as a potential target, sometimes for fun, learning, or self-affirmation, and sometimes for malicious purposes. That is why SSH requires special attention when managing ports and should never be left configured by default.

 

Minimum secure SSH configuration by port

Basic measures that have long become standard:

• use of a non-standard port;
• disabling password login;
• restricting access by IP;
• using fail2ban or its analogues.

 

Of course, simply moving SSH from port 22 does not make the server “invisible,” but it greatly reduces the noise from automatic bots. This is a filter, not full-fledged protection. Real security is built on keys, firewalls, and access control.

 

 

 

 

HTTP, HTTPS, and the hidden risks of web services

Ports 80 and 443 are almost always open by default, and in most cases, this is justified. It is through these ports that users access websites and APIs. However, even in this seemingly familiar area, there are nuances that often go unnoticed.

If the server is used exclusively under HTTPS, then port 80 is actually only needed for redirection to a secure connection. In all other cases, it simply accepts incoming connections, creating unnecessary network noise and an additional attack surface. This is especially noticeable on servers with high traffic or when bots are actively scanning.

A separate category of problems is forgotten test and auxiliary services. During configuration, it is easy to launch an additional web server on 8080, 8000, or 3000 “temporarily” to check something. But after the work is completed, this port is often forgotten. As a result, months or even years later, the service is still accessible from the Internet, even though it is no longer used or updated.

In complex configurations with reverse proxies, load balancing, and multiple sites, the risk increases even more. Over time, the server becomes overgrown with temporary solutions, migrations, and experiments, and without regular checks, it becomes difficult to understand which ports are really needed for operation and which are left over from previous stages of infrastructure development.

 

 

 

 

Ports that should almost never be public

Open database ports are one of the most dangerous and, unfortunately, common mistakes in server infrastructure. Often, this is not due to malicious intent, but rather carelessness or incorrect default settings.

MySQL, PostgreSQL, MongoDB, and other DBMSs were originally designed to work within a trusted environment, within a single server, on a private network, or within a cluster. Therefore, they are not designed for direct access from the Internet, and if a database port is accessible from the outside, it almost always indicates a problem in the architecture or security settings.

Even with complex passwords and user restrictions, an open DBMS port becomes a constant target for automated scanners, credential brute-forcing, and attempts to overload the service. At best, this will lead to unnecessary load and logs, and at worst, to confidential data leaks or complete system compromise.

 

The correct operating scheme

• When the database listens to localhost or a private interface;
• When external access is prohibited by a firewall;
• When external connections are established via SSH tunnels or VPN.

 

What happens if the database port is open to the internet

• Constant password guessing
• Automatic scans
• DoS attacks
• Risk of data leaks

 

So, even with complex passwords and roles, an open database port is categorically wrong.

 

 

 

 

Port chaos in Docker and Kubernetes

Containers easily create a sense of isolation and security. Docker visually separates services from each other, creating the false impression that everything running in a container is hidden from the outside world by default. But in practice, Docker port publishing works directly through the host system.

A single line in docker-compose.ymlis enough to make the service accessible from the internet:

ports: - “8080:8080” 

 

After that, Docker binds the container port to the host's network interface, most often to 0.0.0.0.

If the firewall does not restrict access, the service becomes public, regardless of whether this was planned or not. It is particularly dangerous that such forwardings are often added temporarily, for testing or debugging, but then remain in the configuration for a long time.

That is why Docker requires the same careful attention to ports as any other service on your server, as every published port must be deliberate, documented, and protected.

To summarize: When working with containers, situations often arise that should be avoided. These situations include:

• the container is only needed for internal communication;
• the port is forwarded to 0.0.0.0;
• the firewall does not restrict access;
• the service is open to the whole world.

 

How Docker and Kubernetes actually open ports

Mechanism	What it does	Risk level
Docker ports	Direct port mapping	High
NodePort	Opens a port on all nodes	Medium
LoadBalancer	Exposes a public IP	Controlled
Ingress	Single entry point for services	Most secure

 

Therefore, without understanding the network model, it is easy to end up with dozens of open ports that no one remembers, which can attract the attention of attackers to your server.

 

 

 

 

Summary or typical mistakes in port management

Over time, the same scenarios repeat themselves in server administration, regardless of experience and infrastructure size. Mistakes accumulate gradually and often seem harmless at the moment, but they are the ones that create most of the problems in the future:

• a port was opened “temporarily” for testing or migration and forgotten to be closed;
• instead of one specific port, a whole range was allowed “just in case”;
• relying only on the provider's firewall, ignoring the system firewall;
• not recording which service uses a particular port and why;
• they are afraid to close ports because they are no longer sure what is behind them.

 

Ports like order and transparency. When there is no order, the server gradually turns into a chaotic structure where any change becomes risky: a seemingly unnecessary port was closed - the service went down; a new port was opened - incomprehensible behavior appeared in the logs. In this state, the infrastructure ceases to be manageable and begins to work against the administrator rather than helping them.

 

 

 

 

Frequently asked questions about ports on VPS and dedicated servers

 

Should I close the port if the service is turned off?

Yes. If the service is not in use, the port should be closed by a firewall. Even if the process is not currently running, the configuration may change, the service may start automatically after an update or reboot, and the port will again become accessible from the outside without your knowledge. A closed port is a clear signal to the system and the administrator that access to it is not intended.

 

Is it safe to use non-standard ports?

Using non-standard ports does reduce the number of automatic scans and brute force attacks, as most bots focus on standard values. However, this is only an additional filter, not a complete security measure. A non-standard port should always be combined with a firewall, IP restrictions, and reliable authentication.

 

Can you rely solely on your provider's firewall?

No. Your provider's firewall is an external layer of protection that does not know which services and ports are used within the system. It does not replace the system firewall and does not protect against configuration errors on the server itself. A reliable scheme always includes both levels, external and local.

 

Is it dangerous to open a port temporarily?

It is dangerous if you do not close it immediately after completing the task. Temporary ports often remain open longer than planned, especially in the hustle and bustle of work. Over time, such exceptions accumulate and turn into an uncontrollable set of rules that are difficult to analyze and maintain.

 

Is it possible to open a port and restrict access to IP only?

Yes, and this is one of the best options if the service needs to be available to a limited group of customers or administrators. IP restriction significantly reduces the risk of attacks and allows you to safely use administrative and internal services without publishing them on the Internet.

 

How often should open ports on the server be checked?

Regularly. At a minimum, every time the infrastructure is changed, new services are installed, or containers are updated. Ideally, port auditing should be part of routine server maintenance, just like checking for updates or backups.

 

 

 

 

Conclusions

Port management on a VPS or dedicated server is not a set of commands or a one-time configuration after system installation. It is part of the overall discipline of administration and understanding how the server interacts with the outside world, users, and other services.

Every open port should be a conscious decision and a specific commitment. It should be backed by a clear service, limited access, and a clear understanding of why the port exists and who has access to it. Anything that does not fulfill this role should be closed, without exceptions or “just in case” scenarios.

When ports are treated systematically, i.e., regularly audited, using a firewall as the primary control tool, and working carefully with Docker and databases, the infrastructure becomes predictable and stable. In this state, the server ceases to be a source of unexpected problems, incidents, and nighttime accidents, and begins to perform its main task - working stably and securely for your business.