"Cloud Firewall Best Practices"

A cloud firewall is only as effective as the rules you configure. Poorly designed rules can leave your servers exposed, while overly restrictive rules can block legitimate traffic and disrupt your services. This guide presents best practices for configuring your Data Mammoth cloud firewall for maximum security without sacrificing functionality.

1. Start with Default Deny

The most important firewall principle is default deny — block all traffic by default and explicitly allow only what you need. This is the opposite of "default allow," where everything is open unless specifically blocked.

With default deny:

• New services are not accidentally exposed to the internet.
• Forgotten or unused ports are automatically blocked.
• You have a clear, auditable list of exactly what traffic is permitted.

Data Mammoth's cloud firewall uses a default deny stance for inbound traffic. When you create a new rule group with no rules, all inbound traffic is blocked. Add allow rules only for the ports and protocols your services require.

2. Apply the Principle of Least Privilege

Every firewall rule should grant the minimum access necessary:

• Restrict by port. Allow specific ports, not all ports. Allow port 22, not ports 1-65535.
• Restrict by protocol. If a service uses TCP, specify TCP — do not allow all protocols.
• Restrict by source IP. If only your office needs SSH access, allow only your office IP — not the entire internet.
• Restrict by direction. Most rules should be inbound. Only create outbound rules if you need to restrict outgoing traffic.

Example: Restricted vs Permissive SSH Rules

Permissive (not recommended):

Restricted (recommended): The restricted rule allows SSH only from a specific IP address, only on the correct port, and only via TCP.

3. Separate Rule Groups by Server Role

Create distinct firewall rule groups for each type of server in your infrastructure:

• Web server group — SSH (restricted), HTTP, HTTPS.
• Database server group — SSH (restricted), database port (restricted to application server IPs).
• Game server group — SSH (restricted), game-specific ports.
• Internal/management group — SSH only, from specific IPs.

This separation ensures that:

• Each server type has only the access it needs.
• Updating rules for one server type does not affect others.
• You can quickly audit what each server type is allowed to do.

4. Restrict SSH Access

SSH is the most targeted port on any server. Restrict it as much as possible:

• Allow from specific IPs only. If you always connect from the same office or VPN, whitelist those IPs.
• Consider changing the default SSH port on the server itself (e.g., from 22 to 2222) as an additional layer of obscurity. Update your firewall rule to match.
• Use SSH key authentication on the server and disable password-based SSH login. This is a server-level setting, not a firewall setting, but it complements your firewall rules.

If your IP changes frequently (e.g., you work from multiple locations), consider using a VPN. Connect to the VPN first, then use the VPN's fixed IP as your SSH whitelist address.

5. Never Expose Database Ports to the Public Internet

Database ports (MySQL 3306, PostgreSQL 5432, MongoDB 27017, Redis 6379) should never be accessible from the public internet. Instead:

• Allow database access only from your application server's IP address. This ensures only your application can connect to the database.
• If the database and application are on the same server, the database should listen on localhost (127.0.0.1) only, and no firewall rule for the database port is needed.

Exposing database ports to the internet is one of the most common and dangerous misconfigurations. Automated bots scan for open database ports constantly.

6. Allow ICMP Selectively

ICMP (the protocol used by ping) is useful for monitoring and troubleshooting but can also be used in reconnaissance attacks.

• Allow ICMP if you use monitoring tools that rely on ping to check server availability.
• Block ICMP if you want to minimize your server's visibility to network scanning tools.

A reasonable compromise is to allow ICMP from your monitoring systems' IP addresses only.

7. Document Your Rules

Every firewall rule should have a clear purpose. Use the description or name fields to document why each rule exists:

• "SSH access from office VPN (203.0.113.50)"
• "HTTP/HTTPS for public website"
• "MySQL access from app-server-01 (203.0.113.20)"

Documentation makes auditing easier and prevents the accumulation of "mystery rules" that no one understands or is willing to delete.

8. Audit Rules Regularly

Schedule periodic firewall audits (at least quarterly):

• Remove unused rules. If a service was decommissioned, remove its firewall rule.
• Update IP addresses. If your office IP changed, update SSH access rules.
• Verify rule accuracy. Confirm that each rule is still necessary and correctly configured.
• Check for overly permissive rules. Look for rules that allow all ports or all IPs when they should be more restrictive.

9. Use Cloud Firewall and Software Firewall Together

The cloud firewall provides network-level protection. A software firewall on the server (iptables, nftables, ufw) provides application-level protection. Using both provides defense in depth:

• Cloud firewall — Blocks unwanted traffic before it reaches the server. Broad access control.
• Software firewall — Fine-grained rules, rate limiting, connection tracking, and application-specific filtering.

See Cloud Firewall vs iptables for a detailed comparison.

10. Test After Every Change

After adding, modifying, or removing firewall rules:

Test allowed access. Verify you can still reach your services (SSH, web, etc.).

Test blocked access. Verify that blocked ports are actually blocked (try from a different IP or device).

Keep a backup plan. Before changing SSH rules, make sure you have an alternative access method (web console in the Data Mammoth dashboard).

Common Mistakes to Avoid

• Locking yourself out of SSH. Always verify you have console access before modifying SSH rules.
• Allowing all traffic to avoid firewall complexity. This defeats the purpose of having a firewall.
• Forgetting to apply the rule group to your server. Creating rules without assigning them does nothing.
• Using the same overly permissive rule group for all servers. Different servers have different needs.
• Not updating rules when IP addresses change. Old IP whitelists grant access to someone else.

What to Do Next

• How to Set Up Cloud Firewall Rules — Create your first rule group.
• Common Firewall Rules — Copy pre-built rules for popular services.
• Cloud Firewall vs iptables — Understand when to use each firewall type.
• Troubleshooting Cloud Firewall Issues — Diagnose and fix firewall problems.