Ban IP
Request Enforcement
OpenAlgo checks active IP bans before Flask processes a request. A banned address receives HTTP 403. Ban state is stored in logs.db and cached briefly; manual and automatic changes invalidate the affected cache entry.
Open Logs > Security or visit /logs/security after signing in.
Stored Trackers
ip_bans
Temporary or permanent bans, reason, count, creator, and expiry
error_404_tracker
Per-IP 404 count and up to 50 distinct attempted paths in a 24-hour window
invalid_api_key_tracker
Per-IP invalid-key count and up to 20 key hashes in a 24-hour window
Raw API keys are not stored by the invalid-key tracker.
Automatic Ban Defaults
Automatic banning is off by default. The persisted settings start at:
404 threshold
100 per 24 hours
404 ban duration
0 hours (permanent)
Invalid-key threshold
100 per 24 hours
Invalid-key ban duration
0 hours (permanent)
Repeat-offender limit
2 bans
A zero-hour duration means permanent. When automatic banning is enabled, localhost addresses are excluded. Reaching the repeat-offender limit makes the next active ban permanent; durations are not automatically doubled.
Dashboard Actions
The authenticated dashboard can:
ban one validated IPv4 or IPv6 address;
unban an address;
resolve a host observed in recent traffic and ban matching addresses;
clear an address's 404 tracker;
inspect invalid-key and 404 activity;
update thresholds, durations, repeat limits, and the automatic-ban switch;
review login activity and active application sessions.
Use a specific, factual ban reason. Host banning resolves addresses from recent stored traffic; it is not a permanent domain firewall rule and DNS can change.
Client IP Resolution
With TRUST_PROXY_HEADERS=False (the default), OpenAlgo uses the immediate peer address. With the setting enabled, it can accept CF-Connecting-IP, True-Client-IP, X-Real-IP, the first X-Forwarded-For value, and X-Client-IP in priority order.
Only enable forwarded headers when a controlled reverse proxy is the only network path to the application. Otherwise a client can spoof the address used for tracking and bans.
What IP Bans Do Not Provide
There is no current CIDR allowlist or trusted-IP bypass feature.
Application bans do not replace a host firewall, cloud security group, VPN, WAF, or reverse-proxy policy.
A ban does not revoke a compromised broker token, API key, session, or MCP token. Revoke those credentials separately.
IP bans are not a substitute for rate limits or denial-of-service protection upstream.
Incident Workflow
Confirm the address and attempted paths in Security and Traffic views.
Apply a manual ban when immediate containment is justified.
Regenerate exposed API keys and reconnect or revoke broker access as required.
Revoke application sessions or MCP token families when those credentials may be affected.
Preserve relevant logs before retention purges them.
Adjust automatic thresholds only after checking for legitimate traffic patterns.
Last updated