How to Make Firewall Configuration Safe

Firewall configuration determines which connections are accepted for network traffic entering and leaving a server. As a safe starting point, record the current access method and open listening ports, allow the port used by your management connection, and then open only the services that are genuinely in use. Do not apply rules if you do not yet have console access or a recovery plan in place before making the change.

Clarify the environment before firewall configuration

This process applies to a Linux VDS, physical server, or cloud server where you have administrative privileges on the operating system. With a shared hosting account, you cannot access the operating system firewall; in that case, use IP blocking, an application firewall, or network rules provided through the hosting panel or provider. If a network security group in the panel works together with the firewall inside the server, traffic must pass through both layers.

First, write down which channel you use to connect to the server: the SSH port, a web console, the provider console, or another management tool. If you are working through a remote SSH session, verify the provider’s emergency console access in advance. Keep a screenshot or exportable copy of the current rules; change only one factor at a time during the process. This makes it possible to identify which rule had an effect if the connection is interrupted.

Prove which port must be opened instead of assuming

The fact that a port is open in the firewall does not mean that a service is running on that port. First compare the server’s local listening list with the application’s actual configuration. If you have administrative privileges, the read-only ss -tulpen command can help display TCP and UDP listeners. Because the port number, address, and service name in the output may vary by version, do not treat this alone as proof that internet access is required.

For example, on a server used only to publish a website, HTTP and HTTPS traffic may be required from outside, while the database port may listen only on the local interface if the application runs on the same server. If a management port must be reachable from an external network, restrict it to the administrator’s fixed IP address instead of the entire internet whenever possible. Follow this decision process: if the service is not used externally, do not open the port; if it will be used externally, first check whether a source IP restriction can be applied; if it cannot be restricted, evaluate strong authentication and the provider’s additional network controls.

Apply rules in a safe order

1. Record the current state. In the firewall management panel or in UFW, firewalld, or a similar tool used by the server, review whether the firewall is active, the default behavior for incoming traffic, and the existing permissions. Save a backup of the rules and the current SSH port. If the firewall is disabled, verify that the provider console is working before applying a policy that could directly block remote access.
2. Allow the management connection first. Determine the port actually used by SSH and, if possible, the administrator’s IP range. Create the rule with only the necessary protocol and source; adding a rule for the wrong port will not preserve access. Once the rule is saved, check that it appears as active and in the correct order in the panel.
3. Evaluate the default incoming-traffic policy. If the policy rejects or drops incoming connections, each service that must be reachable from outside, such as a web server, requires a separate permission. If the policy allows connections but the application port appears closed, the problem may be that the service is not listening or that a network rule exists at the provider layer rather than in the firewall. Do not open all ports at once without making this distinction.
4. Add only verified application ports. For each rule, explicitly select the TCP or UDP type, the destination port, and, where necessary, the source address. For example, if the recorded list shows that the web service is listening on a TCP port while the database is listening only on a local address, allow the web port but do not expose the database to the internet. Including the service name and date in the rule description makes later review easier.
5. Repeat the same operation after the change. Retry the same URL, SSH connection, or application request that failed initially; using a different test makes the result harder to interpret. Note the test time and look for new, time-stamped records in the firewall event log and in the application’s own access or error log. If the connection is still rejected, check whether the source IP matches the range in the rule and whether the provider’s security group is blocking the same port.
6. Make a targeted correction based on the result. If the log shows a firewall rejection, correct only the rule for the matching source, protocol, or port. If permission appears in the firewall but the new record shows a result such as “connection refused,” the service may not be listening; inspect the application service status and its local bind address. If the problem continues after a new test, undo the latest change and inspect the provider’s network rules separately while preserving console access.

Interpret possible findings correctly

Suppose an external HTTPS request fails, but the local listening list shows the relevant TCP port for the web service and the firewall log contains an incoming-connection rejection at the same minute. These findings call for first examining a narrow permission rule for the relevant source range and port; opening the database port or allowing all incoming traffic is not the correct fix. After changing the rule, open the same HTTPS address again and verify in a new time-stamped record that the rejection has disappeared.

Recovery and limitations if the connection does not improve

If the rules appear correct but there is still no connection, separate the three layers: the firewall on the server, the provider’s network security group, and the application’s own listening setting. If the rejection appears only in the firewall record, correct the firewall rule; if there is a block in the provider panel, a change inside the server cannot bypass it. If the application is not listening at all, check the application configuration and service status instead of weakening the firewall.

If you lose remote access, do not add new random permissions. Use the provider console to undo the latest firewall change or carefully load the previous rule set you saved; then try again by adding a narrow rule only for the management port. Keeping changes small and reversible reduces the risk of permanently closing management access while protecting the server. You can also review the relevant service information on İyibirNet when considering the server and network security options together.

As the next step, compare the current listening ports, the source of SSH access, and the provider-side network rules in a single list; do not add permission for any port that has no corresponding entry in that list.