DEV Community

禾
禾

Posted on

Why I Will Not Whitelist an IP Until SafeLine Documents the Control

#waf #allowlist #checklist #ratelimit

An IP whitelist request usually arrives as a shortcut. A health check failed, a scanner was blocked, or an office address saw a block page, and someone wants that source marked safe. I do not treat that shortcut as a procedure, because the official pages used here never describe one. They do describe a reverse proxy that is supposed to inspect traffic before the origin. Exempting an address, if a later control even allows it, is a reduction of that inspection. The work is to decide whether the reduction is justified, not to guess a button.

Published boundaries, not invented menus

SafeLine is a self-hosted web application firewall that protects web apps by filtering and monitoring HTTP traffic between an application and the Internet. Deployed in front of the app, it is a reverse proxy: clients pass through it before they reach the server. It filters, monitors, and blocks malicious HTTP/S traffic, and it uses policies to decide what is malicious and what is safe. The overview also says it can prevent unauthorized data from leaving the app. Those statements are the reason a blanket source exception is expensive. Source: https://docs.waf.chaitin.com/en/home

The same page names core capabilities: defenses for web attacks, proactive bot abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a Web Access Control List. The attack coverage called out there includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse, among others. Rate limiting is specifically throttling that exceeds defined limits, aimed at denial-of-service patterns, brute-force attempts, traffic surges, and other abuse. None of that text says to add an IP and skip detection. A Web Access Control List is listed, but these pages do not define its match fields, its actions, or an allow entry. I will not pretend the label is a tutorial.

Application placement is documented in the configuration guide. SafeLine is an nginx-based firewall that receives traffic for the original site, cleans malicious attack traffic, and forwards the remaining traffic to the upstream application. In the console you add an application with a domain, hostname, or IP, a listen port, and an upstream address. HTTPS apps use the SSL option on that port. After that, the domain should resolve to the SafeLine server so visitors hit the proxy. The same guide shows sample probes for SQL injection, XSS, path traversal, code injection, and XXE, and it says a block page means the attack was defended. Operators then review the attack list and open detail for a specific event. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Installation docs confirm a web console at https://:9443/ and an initial administrator account created from the management container. That is access to the console, not a documented allowlist command. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

The decision checklist I actually use

I keep the ticket in this order. If any step is incomplete, the answer is to keep inspection on.

First, identify the source as observed, not as described in chat. One address on a dedicated monitor is not the same as a corporate NAT, a cloud build agent, or a scanner that rotates egress. These pages never state that an access-control object accepts a single address, a range, or a list. I record the uncertainty instead of inventing a syntax.

Second, attach an event. The configuration guide says the console has an attack list and a detail view. I want the application, the time, and the reported issue from that detail view. A screenshot of a block page without the event is not evidence that the source is harmless. It is evidence that the proxy did what the overview says it does: block traffic the policy treated as malicious.

Third, separate a false positive from a trust request. A bad signature on a known health URL is a tuning problem. A partner who wants every request from an office range to skip SQL injection, XSS, and path checks is asking to step outside the policy model. IP-based rate limiting does not settle either case. The documented behavior is a throttle on excess traffic, not a permanent trust mark.

Fourth, bind the ask to one application. Protection starts when that application is proxied and the domain resolves to SafeLine. The exception request must name the domain, the listen port, and the upstream. A change made for the scanner with no application name will drift into every site on the same proxy.

Fifth, require an owner and an end time. I want the person who benefits, the person who removes the exception, and the date it dies. A short window for a broken health check can be reasonable. A shared office address with no expiry is not, because that address also represents browsers, plugins, and compromised laptops.

Sixth, write the rollback signal first. Examples that stay inside the documented model include a new attack type from that source in the detail view, a surge that rate limiting is already meant to throttle, or the calendar date on the ticket. If nobody can say what would reverse the choice, I do not approve it.

Seventh, stop at the docs. The overview points people to a community FAQ channel for questions, and the configuration pages are the place to re-check controls. I do not add compose flags, API calls, or menu paths that these sources do not contain. Guessing a whitelist screen would publish an unsupported integration.

Substitutes that are not a whitelist

Changing the public DNS record so one partner can reach the origin is not a per-IP exception. The setup guide tells you to resolve the domain to the SafeLine server so the proxy can receive traffic, clean it, and forward it. Moving that record drops the reverse proxy for every visitor.

Raising or disabling rate limits until the noise stops is also the wrong control. Rate limiting, as documented, throttles floods, brute force, surges, and similar abuse. It does not certify that the source is safe, and silencing it removes a signal you may need when you read the attack list.

Handing out the initial console password so the requester can fix it themselves confuses account administration with traffic policy. The deploy guide prints that administrator account for the operator who installed the product. It is not an allowlist mechanism.

What I put in the ticket

I keep six lines:

  • Observed source, and whether it is dedicated or shared.
  • Application domain, listen port, and upstream, matching the add-application dialog.
  • Attack-list time and what the detail view reported.
  • The real ask: fix the client, tune inspection, adjust a documented throttle, or wait until an exception control is actually documented.
  • Owner, start, end, and the removal check.
  • Residual risk: which documented attack classes would matter if this source were inspected less.

If the detail view shows a single malformed probe, I send the client owner back to fix the request. If the address is a shared egress that also reaches an authenticated app, I refuse a source exception. If the pages in front of me still do not describe an allowlist object, I leave the proxy in path and track the event. That is slower than a mythical whitelist button. It matches the product as published.

Do the official pages show how to whitelist an IP?

No. They document the reverse-proxy role, named capabilities such as a Web Access Control List and IP-based rate limiting, the application fields, and the attack list. They do not document whitelist fields, commands, or a console path. I will not fill that gap with invented steps.

Is IP-based rate limiting the same as an allowlist?

No. The product overview describes rate limiting as throttling traffic that exceeds defined limits, including denial-of-service patterns, brute-force attempts, traffic surges, and other abuse. A limit can still apply to a noisy client. It does not mark that client as trusted.

Should I point DNS around the proxy for one address?

Not on the public record. Protection, as documented, depends on resolving the domain to the SafeLine server so traffic is received and cleaned before the upstream. A public DNS change removes that path for every client, which is the opposite of a narrow exception.

What belongs in an exception request?

The observed address, whether it is shared, the application domain, port, and upstream, the attack-list detail, an owner, and an expiry. Without the detail view, you cannot tell a false positive from a real exploit attempt that happened to come from a familiar network.

What if a newer build adds an allowlist control?

Read that version's docs before using it. Confirm whether the match is per application, how removal works, and what inspection remains. Shared egress, missing event detail, and no rollback are still reasons to say no, even if a control appears later.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)