Firewall Configuration: A Secure Start for a Web Server

Firewall configuration does not mean randomly blocking every connection to a server; it means identifying the traffic that is required and restricting the rest. On a web server, first record the current rules and access method, then add the administrative connection, HTTP, and HTTPS to the allowlist in a controlled manner. After making the change, retry the same connection and verify the result using new, timestamped log entries.

Identify the Environment and Access Before Firewall Configuration

These steps are suitable for a server with administrative privileges where you can manage the operating system firewall or the provider’s virtual-server network-security interface. With a shared hosting account, you may not have access to the operating system firewall; in that case, you can use only the IP-blocking, application-security, or provider-firewall options offered in the control panel. Because a rule in the panel and a rule on the server may operate at different layers, evaluate them separately.

First, note how you connect to the server, the SSH port, your administrative IP address, and the web ports actually used by the application. SSH is a protocol that provides a remote administration connection; although port 22 is used in many installations, a custom port may have been assigned. If the application serves HTTPS only, opening port 80 may not be necessary. Export the current rules or take a screenshot, and, if possible, verify that the provider’s console access is working.

Define the Required Traffic for the Web Server Narrowly

The first decision is which services the server will accept from the internet. If it only publishes a website, ports 80 and 443 are relevant; if SSH is also required for administration, the SSH port must be considered as well. Instead of exposing a database port to the internet, it may be more appropriate to keep the application and database on the same server or in a private network; if remote administration is required, restrict access to specific source IP addresses.

The second decision is to distinguish connections whose sources can be restricted from connections that must be accessible to everyone. HTTPS visitors may generally come from the wider internet; SSH, however, can be accepted only from a corporate network, VPN, or known administrator IP addresses. If the administrator’s IP changes frequently, consider the provider’s VPN or secure-access solution instead of opening a broad range. If you cannot narrow the scope, prepare alternative console access before leaving the connection open.

Rule Order and Default Behavior

In many products, firewall rules are evaluated from top to bottom or according to priority. A more general blocking rule can make an allow rule that follows it ineffective. Therefore, define administrative access first and the required web ports afterward; change the default behavior only after that. A “default deny” approach may block new connections depending on the provider, but how existing sessions are handled depends on the product and its connection-tracking feature.

Apply and Test the Rules Safely

1. Review the current state. In the operating system firewall interface or the provider panel’s inbound rules, check the default policy and the active interface. If the SSH port is not listed, prepare an allow rule for that port before changing the default blocking policy. If you see an unexpected general allow rule, do not delete it immediately; note its source and the service to which it belongs.
2. Add administrative access first. Define the correct SSH port and, if possible, use only your administrator IP as the source. Save the rule and try a new connection from a separate terminal without closing the existing SSH session. If the new connection fails, do not enable the rule or apply the default block; compare the port number, source address, and any separate firewall at the provider’s network layer.
3. Open web ports according to the application. Add HTTP and HTTPS rules using the TCP protocol, and only for ports that are actually being published. In the rule interface, check the “allow” status or equivalent permission setting and the correct network interface. If an HTTP request fails while HTTPS works, do not open port 80 automatically; examine the application’s HTTP-to-HTTPS redirection design and the web server’s listening port instead.
4. Change the default policy in a controlled manner. After verifying the required permissions, apply the provider’s “deny” or “drop” option for new inbound connections in a way that preserves existing connections. Some panels activate the change immediately, while others require a separate “apply,” “commit,” or confirmation action. Check the record screen to ensure that the rule is active and has the correct priority; make one change at a time instead of opening all ports at once.
5. Retry the same operation and look for new evidence. Repeat the previously failed SSH connection or web request using the same source and URL. Note the time of the attempt and compare the new line in the firewall event log with the server connection log and the web server access log. If the allow rule matches and a new request appears in the web access log, the network layer has been passed; if the application does not respond, the problem may be with the web service’s listening address or the application layer rather than the firewall.

Consider a concrete possibility: suppose the HTTPS connection works, but the administrator sees a timeout when making a new SSH connection. If the log shows that the connection was directed to the wrong port or that the source IP does not match the allow rule, the targeted correction is to add only the correct SSH port and the administrator’s current IP to the allow rule. By contrast, if the log shows that the connection was allowed but authentication failed, broadening the firewall rule will not solve the problem; SSH credentials and the server configuration must be examined separately. This example is hypothetical; the real interpretation should be based on evidence from the same time.

A Safe Rollback Path If There Is No Result

If both SSH and web access are lost after the change, do not continue adding new rules. If the provider offers a web console or a physical/private administration channel, use the previous rule set you recorded and roll back only the last change. If no such access is available, review the provider’s firewall-recovery or rule-reset procedure, the existing backup, and the change time before sharing them; do not send passwords, keys, or personal log contents to a public location.

After rolling back a rule, repeat the same failed operation and this time examine the records from the new time window. If access returns, identify which rule was effective in the previous step and change only one factor again. Store an export of the rules before saving the permanent configuration; in the next edit, changing only the necessary port or source is safer than making a broad correction that is difficult to reverse.

To clarify your server’s layers and administration options, review the relevant hosting information on İyibirNet; also verify separately the responsibilities of the provider firewall and the operating system firewall.