[2026.3] Source IP no longer logged for rejected/malformed HTTP requests — breaks fail2ban setups Topic is solved

[sylvainsjc]

Hello,

Since upgrading to Domoticz V2026.3-stable, I no longer see the line `Error: Error parsing http request address: <IP>` in the log, even when deliberately sending malformed requests that do produce a `400 Bad Request` on the client side.

Even with Debug "Authentication" enabled, failed attempts do show up, but never with the source IP address.

This breaks fail2ban setups based on that message (probably quite a few people, given the number of existing tutorials on the forum). Would it be possible to reintroduce a log trace with the IP for requests rejected by the new hardened parser in 2026.3?

Thanks!

Config: Domoticz V2026.3-stable, Raspberry Pi 5.

[Ragdag]

Make sure you have setup the settings correct, they changed Reverse Proxy support and added host headers selection

2026-09-09 13_25_13-Domoticz - Setup — Mozilla Firefox.png (24.03 KiB) Viewed 643 times

If they are still set to none and your Reverse Proxy is in the Trusted list (What is needed to work with host headers), you have no authentication enforced at all!
I would prefer if the Reverse Proxy IP was a separate entry from the Trusted LAN range as that would be less prone to issues and accidental wide open setups

[Filip]

Make sure you have setup the settings correct, they changed Reverse Proxy support and added host headers selection
2026-09-09 13_25_13-Domoticz - Setup — Mozilla Firefox.png

If they are still set to none and your Reverse Proxy is in the Trusted list (What is needed to work with host headers), you have no authentication enforced at all!
I would prefer if the Reverse Proxy IP was a separate entry from the Trusted LAN range as that would be less prone to issues and accidental wide open setups

I would like to make the link with viewtopic.php?t=45198&sid=64cc4fc2b82a8 ... 35eb86afb9. I created a new one as I am not sure the root cause would be the same...

I see the settings for the trusted network, however in my case, I only have the "Networks" and not the "Reverse proxy header" in my settings page. I cleared cache and even tried in an incognito window...

Screenshot from 2026-09-09 19-52-35.png (23.56 KiB) Viewed 605 times

using version 2026.3 (docker)

Screenshot from 2026-09-09 19-55-36.png (61.62 KiB) Viewed 605 times

[sylvainsjc]

in my case I don't use reverse proxy

[gizmocuz]

Since 2026.3 a malformed or oversized request is no longer logged as an error. Anyone could fill the log by sending junk, so it is now a debug line ("<ip> -> rejected malformed or oversized request"), and only when the WebServer debug category is enabled.

Failed logins are still logged as an error with the source IP:

Code: Select all

Error: Failed login attempt from <ip> for user '<name>' !

so a fail2ban filter on that line keeps working. If you used the old "Error parsing http request address" line to ban scanners, please switch the filter to the failed login line.

[sylvainsjc]

Here is my technical solution implemented to restore the Fail2ban protection:
• Nginx Reverse Proxy (Port 80): Handles external traffic and generates an exploitable log file (/var/log/nginx/access.log).
• Domoticz Configuration: Enabled trust for the X-Forwarded-For header sent by Nginx.
• Optimized Fail2ban: Monitors HTTP codes 401, 403, 400, and 444 within Nginx logs.
• Banning Action: Uses the native nftables-multiport action with a clean reject (reject with tcp reset) to instantly drop connections.

[lost]

Since 2026.3 a malformed or oversized request is no longer logged as an error. Anyone could fill the log by sending junk...

The log would only fill on setups not using fail2ban and alikes. Tell me if I'm wrong, but knowing someone was "shaking the coconut tree" (aka "fuzzing the webUI server") with malformed requests was IMO useful as this did prevent unlimited attempts until one may succeed.

Must say this was my #1 cause for a ban in my former upgrade fail2ban logs, that are now almost empty (so I searched for the reason) even if such crafted requests must IMO still occur at heavy pace. Problem is I now can't prevent them as easily as before

Did upgrade to last stable 2026.4 on friday from a 2025.1, also noticed messages about tls handshakes misses I don't remember to have seen before upgrade, but not much:

Code: Select all

2026-11-01 06:22:52.771  Status: ::ffff:95.214.53.196 -> TLS handshake not completed within 10 seconds, dropping connection
2026-11-01 06:23:02.842  Status: ::ffff:95.214.53.196 -> TLS handshake not completed within 10 seconds, dropping connection

[gizmocuz]

Thanks for the feedback, good point: with only a debug line, scanners were no longer visible in the log. In the next beta both lines are logged again with the IP, but at most once per IP per minute (repeats go to the debug log), so fail2ban can ban every scanner while a single client can no longer fill the log:

Code: Select all

2026-11-01 08:54:07.392  Status: 1.2.3.4 -> rejected malformed or oversized request, replying 400
2026-11-01 08:54:18.397  Status: 1.2.3.4 -> TLS handshake not completed within 10 seconds, dropping connection

A fail2ban filter for both lines:

Code: Select all

failregex = ^.*Status: (?:::ffff:)?<HOST> -> (?:rejected malformed or oversized request|TLS handshake not completed)

Because an IP shows up at most once a minute, use a low maxretry with a longer findtime, for example maxretry = 2 and findtime = 600.
@sylvainsjc: banning on the nginx access log, as you do now, works fine too.

[lost]

Thanks for the change, indeed best to rate-limit for those who don't limit attempts by other means! I'll update when new beta will be available.