Server Firewall Setup: Protecting Your Server Against DDoS Attacks and Bots

Setting up a server firewall involves keeping only the necessary ports open and blocking all unnecessary access; it serves as the first line of defense against DDoS, brute force attacks, and malicious bot traffic. The practical goal is to limit SSH access, open web services in a controlled manner, rate-limit suspicious requests, monitor logs, and, if possible, filter traffic before it reaches the server using higher-level protections like CDN/WAF.

Once you expose a web server to the internet, you could encounter port scans, SSH attempts, vulnerability bots, and fake user agents within minutes. For structures running WordPress, e-commerce, panels, APIs, or game servers, a firewall is not just a technical preference; it's essential for continuity. In this guide, we will establish a step-by-step firewall architecture applicable to Linux servers, addressing UFW, firewalld, nftables, Fail2ban, web application firewalls, and DDoS mitigation strategies.

Let's start with an important fact: a local server firewall alone cannot stop large-scale DDoS attacks. When a 20 Gbps, 80 Gbps, or higher volume attack reaches the data center or network backbone, the packets can fill up the bandwidth before they even reach the ruleset in your operating system. Therefore, the right approach is layered security: DDoS protection at the provider level, CDN/WAF, operating system firewall, application rate limiting, and regular log analysis should work together. For appropriate infrastructure selection, you can refer to the Hostragons VPS and VDS Server Solutions page, and for secure hosting options on the website side, check the Hostragons Web Hosting Packages page.

What Does a Server Firewall Do?

A server firewall is a security layer that filters network traffic based on source IP, destination IP, port, protocol, connection state, and certain packet characteristics. To give a simple example: your website should have ports 80 and 443 open, but the database port 3306 should not be exposed to the internet. Instead of allowing everyone to attempt connections on port 22 for SSH, it's safer to permit connections only from your office IP address.

The primary goal of a firewall is not to magically eliminate all attacks. The main objective is to reduce the attack surface. The smaller the attack surface, the fewer options an attacker has to exploit. For example, a newly set up Linux server may have SSH, web panel, mail service, database, monitoring agents, and test services all open at the same time. Each of these creates a separate risk. A well-configured firewall operates on the principle of "deny by default, allow what is needed."

Understanding DDoS and Bot Traffic

What Makes DDoS Attacks Different?

DDoS, or Distributed Denial of Service, aims to make a targeted service inaccessible by overwhelming it with traffic from many sources. The attack can fill up bandwidth, consume server CPU and RAM resources, or trigger expensive operations at the application layer. For instance, a small application server receiving 50,000 HTTP requests per second may become unresponsive not because the network line is full, but due to PHP-FPM, Node.js, or database connection pooling issues.

Are All Bots Bad?

No. Googlebot, Bingbot, and some monitoring bots are beneficial. However, malicious bots can perform panel scraping, open directory searches, form spam, content copying, exploit XML-RPC, create fake registrations, and attempt logins. Therefore, the goal in bot management is not to block all bots but to differentiate based on behavior. High error rates, a large number of requests in a short time, headers that do not behave like real browsers, and suspicious URL patterns are significant signals.

Pre-Installation Checklist

When writing firewall rules on a live server, the biggest risk is locking yourself out of the server. Therefore, it's essential to prepare briefly before making changes. The checklist below outlines a commonly used secure starting approach in production environments.

• Do not close your active SSH session; test using a second terminal.
• Ensure your server provider offers console, VNC, or recovery access.
• List the currently open ports: review the output of ss -tulpn or netstat -tulpn.
• Note which ports are used by web, mail, DNS, database, panel, and monitoring services.
• If using IPv6, plan for IPv6 firewall rules as well.
• Apply allow rules first, then deny rules.
• Ensure the ruleset is persistent; it should not be lost on server restart.

For example, in a typical server hosting only a website, the ports that need to be open are often 80, 443, and a limited SSH port. If there is no mail server running, ports like 25, 465, 587, and 993 do not need to be open. If the database is used only from the same server, ports 3306 or 5432 should remain closed to the outside world.

Which Firewall Tool Should You Choose?

In the Linux world, there are multiple tools, most of which manage the same core filtering infrastructure with different ease of use. For beginners, UFW is simple and fast. Firewalld is common in enterprise or Red Hat-based systems. For more advanced scenarios, nftables offers a modern and flexible structure. The table below simplifies the selection process.

Step-by-Step Server Firewall Setup

1. Identify Open Ports and Services

The first step is to see what is open. The ss -tulpn command on a Linux server shows which services are listening on which ports. For example, if nginx is listening on 0.0.0.0:80 and 0.0.0.0:443, it means that web traffic is accepted from all interfaces. If MariaDB is listening on 0.0.0.0:3306, this is usually risky; in most websites, the database should run on 127.0.0.1.

The practical rule here is: No service that does not need to be accessed from the internet should listen on 0.0.0.0. It's healthier to fix the service configuration first, then close it with the firewall. Because even if the firewall is disabled, the service should not be exposed to the outside world.

2. Set the Default Policy to Deny

In secure rule sets, incoming traffic is denied by default, while outgoing traffic is allowed as needed. This approach prevents services that are set up later from being mistakenly exposed to the internet. On an Ubuntu server using UFW, the logic is as follows: first, allow SSH, then open 80 and 443, and after that, set the default incoming policy to deny and activate the firewall.

Example flow: Allow access for your admin IP address for SSH, open HTTP and HTTPS traffic, close unnecessary ports, and then activate. One of the most common mistakes is to open the firewall without granting SSH permission first, especially on remote servers.

3. Limit SSH Access

SSH is one of the services most targeted by attackers. A server with the default open port 22 can see hundreds or even thousands of password attempts daily. The safest approach is to limit SSH access to specific IP addresses. If you have a static IP, only allow your office or VPN IP address. If you do not have a static IP, at least use key-based authentication and disable password logins.

• Disable direct SSH logins as root.
• Use SSH keys instead of passwords.
• Restrict users with AllowUsers or AllowGroups.
• Automatically block failed attempts with Fail2ban.
• If using a control panel, also apply IP restrictions to the panel port.

Changing the port alone does not provide security, but it can reduce automated bot noise. Still, real protection comes from IP restrictions, strong authentication, and log monitoring.

4. Open Web Ports in a Controlled Manner

For most servers hosting websites, ports 80 and 443 are necessary. However, today, port 443, i.e., HTTPS, should be the primary traffic port, while port 80 should only be used for HTTPS redirection. Sites without an SSL certificate negatively impact both user trust and SEO performance. At this point, the Hostragons SSL Certificates link provides a natural internal link opportunity to guide readers towards secure HTTPS setup.

When opening web ports, pay attention to the behavior of the real IP. If you are using a CDN or reverse proxy, it's more robust to allow traffic on ports 80 and 443 only from the IP ranges of the CDN rather than exposing them directly to the entire internet. This way, even if an attacker knows the real server IP address, they cannot access the web service directly.

5. Close Database and Internal Services to the Internet

Having services like MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, and MongoDB open to the internet poses serious risks. Lack of authentication for Redis, unauthorized index access for Elasticsearch, or an open management port for MongoDB has led to numerous data leaks in the past. These services should listen only on localhost or via a private network whenever possible.

For example, for a WordPress site running on the same server, the database should work over 127.0.0.1. If you are using a separate application and database server, allow access only from the private IP address of the application server. Leaving ports 3306 or 5432 open to the general internet is a known mistake that bots continuously scan for.

6. Prevent Brute Force Attempts with Fail2ban

Fail2ban monitors log files to detect repeated failed login attempts and temporarily blocks the associated IP address. Jail definitions can be made for SSH, nginx, Apache, Postfix, Dovecot, WordPress login, and some panel services. For example, blocking an IP address that makes 5 failed SSH attempts within 10 minutes for 1 hour is a simple but effective starting point.

Be cautious when using overly aggressive rules in Fail2ban configuration. Incorrect log patterns can also block real users. Therefore, it is safer to keep the bantime value reasonable at the initial stage, monitor the logs, and then gradually tighten the rules.

7. Add Rate Limiting and Connection Limits

Rate limiting at the operating system level can help against DDoS and bot traffic. For example, if an excessive number of new connections come from the same IP address per second, limits can be applied. On the web server side, nginx's limit_req and limit_conn modules, Apache's mod_evasive, or similar solutions can be used. On the application side, rate limits should also be imposed on login, search, cart, payment, and API endpoints.

A concrete example: For a login page, 10 attempts per minute per IP address may be reasonable. For a search endpoint, 2-5 requests per second may suffice. If you are offering an API, user-based token limits, IP limits, and behavioral analysis should be designed together, so an attacker cannot simply bypass all limits by changing their IP.

Example Secure Setup Scenario with UFW

A simple secure starting scenario on an Ubuntu or Debian-based web server can be established with the following logic: first, check current services, allow SSH access from your admin IP address, open ports 80 and 443, deny incoming traffic by default, and verify the status of UFW. If your SSH access cannot be limited to a static IP, you can temporarily allow SSH from all IPs and later switch to a VPN or static IP solution.

The example decision set could be as follows: let 203.0.113.10 be the admin IP address. Allow SSH only from this IP. Keep web traffic open for everyone on 80 and 443. Close the database, Redis, panel, and test ports to the outside. This structure is a good starting point for many small and medium-sized corporate websites. For correct routing on the domain and DNS side, you can link to the Hostragons Domain Lookup and Registration page.

Zone Logic with firewalld

Firewalld is commonly used on AlmaLinux, Rocky Linux, and RHEL-based servers. Firewalld operates with the concept of zones. The public zone is meant for internet-facing interfaces, the trusted zone for trusted private networks, and the drop zone quietly drops unwanted traffic. The most important point is the difference between runtime and permanent rules. A runtime rule is applied immediately but may be lost on restart; a permanent rule is persistent but may require a reload.

When using firewalld in corporate environments, service-based definitions simplify things. For example, you can open HTTP and HTTPS services on the public zone while ensuring that the SSH service is only accessible from specific source IP addresses. If the management network, backup network, and user traffic are on separate interfaces, the zone structure enhances security and readability.

CDN, WAF, and Provider-Level DDoS Protection

A local firewall makes decisions after packets reach the server. In large DDoS attacks, the goal is to filter traffic before it reaches the server. Therefore, CDN, WAF, and provider-level DDoS protection are critical. A CDN delivers static content at edge locations, a WAF filters malicious requests at the application layer, and provider protection absorbs or cleans up large-scale attacks at the network level.

In an ideal model, your DNS records pass through the CDN, your real server IP address is hidden, and your server firewall only accepts 80 and 443 from the CDN IP ranges. Management ports must be accessible only via VPN or static IP. Such a model reduces the likelihood of direct attacks on the IP and allows you to filter bot traffic before it reaches the application. For content that addresses both web security and performance topics, you can use the Website Acceleration and Security Guides link.

Application Layer Measures Against Bots

Bot blocking is not just about IP ban lists. Modern bots can use proxies, mobile networks, data center IPs, and variable user agents. Therefore, a behavior-based approach is necessary. Analyzing short bursts of numerous login attempts from the same IP, continuous 404 errors, wp-login.php or xmlrpc.php density, clicking patterns that differ from normal users, and suspicious headers is essential.

• Use rate limiting on login and registration forms.
• Disable or limit unnecessary XML-RPC access.
• Protect the management panel with a different URL, IP restrictions, and multi-factor authentication.
• Filter suspicious user-agent and referrer patterns at the WAF level.
• Balance the use of CAPTCHA or invisible bot verification mechanisms in forms.
• For API endpoints, add key, signature, quota, and timestamp checks.

It is crucial to manage bots without compromising the user experience. Overuse of CAPTCHA, aggressive blocking, or incorrect country blocks can harm your real customers. Therefore, measurement, testing, and gradual hardening are the healthiest methods.

Log Monitoring and Alert Rules

Thinking that the installation is finished is a common mistake. A firewall is a live system and must be monitored regularly. SSH attempts in auth.log or secure files, abnormal request volumes in nginx access logs, increases in 404 and 500 errors in error logs, and monitoring system metrics for CPU and connection counts should all be tracked. Even a simple alert can save minutes when an attack begins.

Example threshold values for a starting point could be: more than 100 404 requests from the same IP within 5 minutes, more than 20 attempts to the login page within 1 minute, CPU usage remaining above 90% for 10 minutes, or the number of connections tripling from the norm. These thresholds vary for each site; the important thing is to know your normal traffic profile.

Common Mistakes and How to Avoid Them

• Enabling the firewall without granting SSH permission: This could lead to losing access to a remote server. Always test with a second session.
• Forgetting about IPv6: Services may remain open over IPv6 when the IPv4 side is closed.
• Leaving the database open to the internet: Ports like 3306, 5432, 6379, and 9200 are constantly scanned by bots.
• Using a CDN but leaving the real IP open: Attackers can bypass the CDN and attack the server directly.
• Changing rules without documentation: In emergencies, it becomes difficult to understand what each rule does.
• Not creating a backup access plan: If there is no console access due to a wrong rule, downtime can extend.

Practical Example of a Firewall Policy

A feasible summary policy for a small corporate website could be: incoming traffic is closed by default; 443 is open to all visitors; 80 is open only for HTTPS redirection; SSH is accessible only from a VPN or fixed admin IP address; the database is on localhost or a private network; if using a CDN, 80 and 443 are only allowed from CDN IP ranges; Fail2ban monitors SSH and web login attempts; log files are sent to a centralized monitoring tool.

For a medium-sized e-commerce site, in addition to this, payment callback IPs are allowlisted, the management panel is moved behind a VPN, user-based quotas are applied for APIs, SQL injection and XSS rules are activated on the WAF, and a temporary filtering plan based on country or ASN is prepared. It is crucial for this plan to be documented; applying a predefined procedure instead of making decisions during an attack reduces downtime.

Testing: Are the Rules Really Working?

After firewall setup, testing is essential. Perform open port scanning from a different network, verify that SSH access works only from allowed IPs, check that the website is accessible over HTTPS, and ensure the database port is closed to the outside. If you are using a CDN, confirm that direct HTTP requests to the real server IP are blocked.

During the testing process, avoid aggressive scans that could damage production systems. The goal is to perform secure validation. Also, after every change, export or note down the ruleset. This way, it will be easier to revert to a previous healthy configuration in case of any issues.

Maintenance and Update Plan

Server security is not a one-time setup but a regular maintenance process. When a new service is added, the port requirements should be reviewed, permissions should be removed when an old service is removed, security updates should be applied on time, and logs should be checked periodically. Conducting an open port audit at least once a month and reviewing the firewall ruleset every three months is a good practical start.

Moreover, a backup plan is part of the security strategy. A DDoS attack may cut off access, but ransomware or unauthorized access can lead to data loss. Secure hosting, SSL, domain management, and backups should be considered together. In this context, the Considerations for Choosing Secure Hosting and How to Install SSL Certificate contents are natural follow-up links.

Conclusion

Setting up a server firewall does not make your server completely invisible to DDoS and bots; however, it significantly reduces the attack surface, lowers the risk of unauthorized access, and enables you to respond to incidents more controllably. The best results are achieved by implementing provider-level DDoS protection, CDN/WAF, strict port policies, SSH restrictions, Fail2ban, rate limiting, and regular log monitoring together.

If you are launching a new project, planning the firewall policy from the outset is easier than making corrections later. While evaluating your server, hosting, domain, and SSL infrastructure on Hostragons, consider your security needs to create a more resilient web environment. If needed, start with a small checklist: close open ports, limit SSH, enforce HTTPS, and monitor logs.

Frequently Asked Questions

Does a server firewall completely block DDoS attacks?

No. A local firewall can mitigate small-scale and some protocol-level attacks, but for large-scale DDoS attacks, provider-level DDoS protection, CDN, and WAF are necessary.

Which ports should remain open on a web server?

On a typical web server, ports 80 and 443 remain open. The SSH port should only be allowed from admin IP addresses. Database and internal service ports should be kept closed to the internet.

Should I use UFW or firewalld?

UFW offers an easier start for Ubuntu and Debian. Firewalld is common in AlmaLinux, Rocky Linux, and RHEL-based systems. For advanced and specific scenarios, nftables may be preferred.

Can I stop bot traffic by just blocking IPs?

Generally no. Modern bots use different IPs and proxies. In addition to IP blocking, rate limiting, WAF rules, behavior analysis, CAPTCHA, and application-based quotas should be utilized.

What is the biggest risk when setting up a firewall?

The biggest risk is cutting off your own SSH access due to an incorrect rule. Therefore, SSH permissions should be defined first, tested with a second session, and console access from the provider should be readily available.