Firewall

Hubfly Firewall protects public HTTP traffic before it reaches your container or load-balanced service. It gives each exposed domain a practical edge security layer for IP access policies, bot filtering, restricted path blocking, request throttling, TLS termination, HTTPS redirection, DDoS mitigation, traffic inspection, and live request logs.

Use this page when you need to secure a public application, API, admin panel, webhook endpoint, CMS, internal tool, or high-traffic service running on Hubfly.

What Hubfly Firewall does

Hubfly Firewall sits between the internet and your public HTTP endpoint. Requests are evaluated at the edge, then either blocked, rate limited, logged, or forwarded to the target service.

When to use Firewall

Use Firewall for any service that accepts public HTTP traffic and should not trust every inbound request equally.

Good fits include:

• Public web applications with login pages, dashboards, or admin routes
• APIs that need rate limits or source restrictions
• Webhook receivers that should only accept traffic from known IP ranges
• WordPress, PHP, CMS, and legacy apps that attract automated scanners
• Preview environments that should be accessible only to a team or customer
• Load-balanced services where the same domain routes to multiple containers
• Emergency traffic control during bot floods or suspicious spikes

Firewall is not a replacement for application authentication, database permissions, secret management, dependency updates, or secure coding. Treat it as a defense-in-depth layer that reduces unwanted traffic before the request reaches your container.

How Firewall fits with Hubfly networking

Hubfly networking has three important layers:

For production, keep databases, queues, Redis, object storage, and internal APIs private. Put Firewall in front of services that must be public, and use private networking for everything else.

Accessing Firewall

To configure Firewall:

1. Open the project that owns the public service.
2. Open the network topology or network management view.
3. Select the Firewall node.
4. Choose the domain you want to protect.
5. Configure rules, rate limits, templates, or logs for that domain.

The domain selector matters. A project can have multiple domains, and each domain can have its own firewall configuration.

Domain-level protection

Firewall rules are attached to a domain, not directly to a container image, volume, or project. This is important for rollouts and scaling:

• If a domain points to a single container, Firewall protects that container’s public HTTP traffic.
• If a domain points to a load balancer, Firewall protects the domain before traffic is distributed across targets.
• If you replace a container behind the same domain, the firewall posture remains tied to the domain.
• If you create a new domain for a preview or test environment, configure firewall rules separately for that domain.

This model works well for production because security follows the public entry point users actually access.

IP access policies

IP access policies let you allow or deny client addresses at the edge. Rules can target a single IP address or a CIDR range.

Examples:

Use IP policies for:

• Blocking repeated abuse from a known network
• Restricting staging apps to company VPN ranges
• Limiting admin panels to trusted static IP addresses
• Protecting customer-specific preview environments
• Reducing noise from unwanted regions or networks when you know the source ranges

Be careful with allow rules. If you allow only trusted addresses, users outside those ranges can lose access immediately. Keep a break-glass path available when locking down an admin domain.

User-agent blocking

User-agent rules block requests based on the client identifier sent in the HTTP request. Hubfly includes quick selections for common clients and crawlers such as curl, wget, python-requests, Go-http-client, PostmanRuntime, Googlebot, Bingbot, and SEO crawler signatures.

Use user-agent blocking to reduce:

• Basic scripted scraping
• Unwanted automated clients
• Low-effort vulnerability scans
• Non-browser access to browser-only pages
• Known crawler families that should not index or harvest the service

User-agent headers can be spoofed, so this should not be your only protection for sensitive resources. For high-value routes, combine user-agent rules with rate limiting, IP policies, authentication, and application-level authorization.

Restricted paths

Restricted path rules block sensitive URL paths before they reach your service.

Common examples include:

Restricted paths are useful even when the file or route does not exist. Automated scanners often probe predictable paths across the internet; blocking them at the edge keeps that noise away from your container logs and app runtime.

Rate limiting

Rate limiting controls request frequency per client. Hubfly Firewall exposes three controls:

Recommended starting points:

Rate limits should match real user behavior. A webhook provider, monitoring service, or API customer may legitimately send bursts. Start with a moderate limit, observe logs, then tighten gradually.

Security templates

Security templates apply prebuilt rule sets to the active firewall configuration. They are useful when you want a fast baseline or an emergency posture.

Templates merge rules into the current configuration. Review the confirmation screen before applying a template, especially on production domains.

Logs and traffic inspection

Firewall logs help you understand what is happening at the edge. The logs view supports traffic and anomaly streams, live tailing, search, historical time ranges, and request detail inspection.

You can inspect:

• Timestamp
• HTTP status
• Method
• Path and query string
• Response size
• Client IP
• Upstream target
• Edge latency
• Request headers
• User-agent
• Referer
• Error details when available

Use logs to answer operational questions such as:

• Which IP address is generating the most failed requests?
• Are blocked requests coming from one network or many?
• Did a new firewall rule block legitimate users?
• Which path is being scanned repeatedly?
• Is the issue at the edge, in the upstream container, or in the application?

Production firewall patterns

Public app baseline

Use this for most production web apps:

• Enable Standard Guard.
• Block /.env, /.git, and known admin paths that should never be public.
• Add a moderate rate limit such as 20 r/s with burst 50.
• Watch logs after deployment and adjust rules based on real traffic.
• Keep application authentication and authorization enabled.

Private admin dashboard

Use this for dashboards, back offices, CMS admin pages, and internal tools:

• Put the admin interface on a separate domain or subdomain when possible.
• Add allow rules for company VPN or office CIDR ranges.
• Block generic scanner paths.
• Use strict rate limiting.
• Keep application login, MFA, and role-based permissions active.

API protection

Use this for public API services:

• Rate limit around expected client behavior.
• Avoid blocking common programmatic user agents unless your API is browser-only.
• Use IP allow rules for partner-only APIs or webhooks with known source ranges.
• Keep API keys, signatures, OAuth, or application auth as the source of truth.
• Monitor 429, 401, 403, and 5xx patterns in logs.

CMS hardening

Use this for WordPress, PHP, and similar applications:

• Apply CMS Shield.
• Block /.env, /.git, /xmlrpc.php, /wp-login.php, and install/setup paths that should not be reachable.
• Add stricter rate limits around login-heavy domains.
• Keep the CMS, plugins, and themes patched.
• Use backups and persistent storage correctly for uploaded media and config.

Under attack mode

Use this temporarily during abnormal spikes:

• Apply Under Attack.
• Add deny rules for clear abusive IPs or CIDR ranges.
• Tighten rate limits while watching false positives.
• Review logs for paths, methods, user agents, and client IP concentration.
• Relax emergency limits once traffic returns to normal.

Firewall and load balancers

When a public domain routes through a Hubfly load balancer, Firewall should be treated as the first security gate for that hostname. Requests are evaluated before they are distributed to targets.

This is useful for scaled services because one domain-level rule set protects all replicas behind the load balancer. You do not need to duplicate the same edge rules for every target container.

Recommended pattern:

1. Attach the production domain to the load balancer.
2. Configure Firewall for that domain.
3. Keep health checks enabled for the load balancer targets.
4. Use logs to distinguish edge blocks from upstream application errors.
5. During rollouts, keep firewall rules stable while changing target weights or replicas.

Firewall and scaling

Firewall works well with manual replicas and vertical auto-scale because it protects the public entry point, not the internal runtime shape.

For horizontally scaled services:

• Put replicas behind a load balancer.
• Attach the public domain to the load balancer.
• Configure Firewall on that domain.
• Use rate limits to protect all replicas from request floods.
• Use application-level session, cache, and database design for stateful behavior.

For vertically scaled services:

• Firewall does not replace CPU/RAM capacity planning.
• Rate limits can reduce traffic pressure, but they do not fix slow queries or overloaded upstream dependencies.
• Watch both edge logs and container metrics when diagnosing performance issues.

Security considerations

Follow these practices for production domains:

• Do not expose databases, queues, object storage, or Redis publicly.
• Use private networking for service-to-service communication.
• Keep public TCP endpoints limited to protocols that truly need raw TCP access.
• Prefer HTTPS domains for user-facing services.
• Treat user-agent blocking as a low-cost filter, not a trust boundary.
• Use IP allow rules for sensitive admin tools when your team has stable access ranges.
• Avoid overbroad deny rules that can block legitimate NAT, mobile, or corporate traffic.
• Test firewall templates on staging before production when possible.
• Keep application authentication, authorization, input validation, and secrets management in place.

Troubleshooting

FAQ

Is Hubfly Firewall a full network firewall?

It is an edge firewall for public HTTP domains. It protects requests entering through Hubfly’s HTTP edge. Private networking and internal container traffic are handled separately by the project network model.

Does Firewall protect load-balanced services?

Yes. Configure Firewall on the domain that points to the load balancer. The domain-level rules apply before traffic is sent to the load-balanced targets.

Can I block a single IP address?

Yes. Add an IP access policy with a deny action and the client IP address. You can also use CIDR ranges for network-level policies.

Can I allow only my office or VPN?

Yes. Add allow policies for trusted CIDR ranges. Test carefully, because users outside those ranges will lose access.

Should I block Googlebot or Bingbot?

Only block search crawlers if you do not want the domain indexed or crawled. For public marketing pages and docs, blocking major search crawlers can hurt discovery.

Are rate limits per app or per domain?

Firewall settings are configured on the selected domain. Treat the rate limit as protection for that public entry point.

Do I still need authentication?

Yes. Firewall reduces unwanted traffic, but it does not replace login, MFA, API keys, OAuth, signed webhooks, role-based permissions, or application authorization.

Related docs

• Networking
• Load Balancers
• Scaling
• HubTunnels
• Platform