Odd errors appearing in the container logs. Possibly a leak being triggered from external source?

[AndyRap]

I happened to sit with the Zoraxy log from my docker service (Unraid) open for a while today and noticed the following errors being reported.

Whilst I could dismiss these as internal errors, the fact that they seem to relate to various paths makes me believe that these are being generated when a certain type of URL is being tested against the server from a nefarious actor.

`[2025-05-06 13:37:03.702687] [uptime-monitor] [system:info] Uptime updated - 1746535023

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/my1.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/admin.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/muse.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/makeasmtp.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/themes.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/admiin.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/xp.php": dial tcp [::1]:46064: connect: connection refused

[2025-05-06 13:42:03.702686] [uptime-monitor] [system:info] Uptime updated - 1746535323

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/index.php?p=": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/wp-protector.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/radio.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/xmrlpc.php?p=": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/x2.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/about.php?p=": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/.info.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/index.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/install.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/about.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/cloud.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/Llj.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/atomlib.php": dial tcp [::1]:46064: connect: connection refused

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/makeasmtp.php?p=": dial tcp [::1]:46064: connect: connection refused

[2025-05-06 13:47:03.702983] [uptime-monitor] [system:info] Uptime updated - 1746535623`

Not sure if this is a bug or expected, but wanted to make sure it was reported in case it hints towards a possible exploit.

Thanks

[tobychui]

It seems like someone is trying to break into your server. By default Zoraxy don't use that port, but since the ACME module will automatically find a spare port to bind into and listen to acme request, I guess that might be the reason why there is such a werid open port number.

I don't think this is a bug but more like a firewall settings issue in your side. Try disable all other posts except the one that is intended for serving contents like 443 and 80. For details reasons, I guess you need to ask the acme module developer @yeungalan

[AndyRap]

Hi Toby,

I appreciate your reply but, ports 80 and 443 are the only ports forwarded from my external, internet facing firewall to Zoraxy, and that's why I was / am concerned that those errors were showing up in my logs and raised it as a possible issue here :)

For clarity, I run Zoraxy in a separate DMZ VLAN which is itself firewalled on my Mikrotik core switch only to allow TCP ports 80, 443 and 8000, with port 8000 only being available from local LAN sources.

I will keep an eye on the logs today and update if the issue persists.

Thanks

[AndyRap]

To add further information, and rather more alarmingly. There are entries in the logs that match the requests logged as errors above, such as:

my1.php
admin.php
muse.php
makeasmtp.php

and they come from IP addresses that are already blacklisted in Zoraxy, as shown in the attached log snippet.

Thanks

zoraxy_log_snippet.txt

[tobychui]

@AndyRap I don't see any problem in the log.

I see the log is printed by [router:blacklist] which means the request has been handled by access list handler.

[AndyRap]

I didn't state that the log snippet listed any errors what-so-ever.

It does however show entries hitting zoraxy for exactly the same random .PHP files being requested within the same time period as the original errors showed up in the Zoraxy container logs.

For example:

Original error:

client: error making http request: Get "http://localhost:46064/.well-known/acme-challenge/makeasmtp.php?p=": dial tcp [::1]:46064: connect: connection refused

Zoraxy log:

[2025-05-06 13:41:47.040523] [router:blacklist] [origin:m231-root.] [client: 52.169.178.249] [useragent: ] GET /wp-includes/SimplePie/Content/makeasmtp.php 403

Are you saying that these two are entirely coincidental, not related at all and therefore there is zero possible issue?

Thanks

[tobychui]

Are you saying that these two are entirely coincidental, not related at all and therefore there is zero possible issue?

Yes, these are two different issues. As I have described / replied above.

1. That log is (supposing) come from the ACME modules. ACME module has its own special routing rule (and access control mechanism) that do not apply to any (http proxy rules) whitelist blacklist setting. I also recommend you reaching out to Alan for more information in the implementation details in the first response.

2. Since you reply saying that blacklist didn't work, but your log state that the request has been blocked, that is why I said the log seems all right in the 2nd response.

I guess someone is scanning both your normal http directory and the acme endpoint for your domain. Zoraxy currently do not have exploit protection mechanism yet. You can add a Cloudflare proxy in the middle if needed.

[AndyRap]

Thank you for your time, and I do appreciate you replying, but please do not quote me as stating something that I have not.

I have not once stated that the blacklisting of that IP did not work, merely that it seems far to coincidental that the same, extremely random 'makeasmtp.php', for this example, request shows up in both the main Zoraxy log, whilst also appearing during the same time period as having managed to trigger the included ACME module.

In my 30+ years working in the IT industry such coincidences rarely, if at all, turn out to be said coincidence.

The only ports that are forwarded from my firewall (OPNSense) to Zoraxy are TCP 80 and TCP 443, as required to obtain proper operation of a reverse proxy with HTTP to HTTPS redirect. I would understand completely if I was an uneducated user who had, rather than selectively opening only the required ports, set for example, the IP address of Zoraxy as a DMZ host and was forwarding all inbound traffic not otherwise redirected to other services, to Zoraxy. This however is not the case, I'd be happy to include a screenshot of my firewall rules should any doubt remain.

How this remote actor is able to trigger a response from the ACME module running as part of the Zoraxy solution is beyond me, my programming knowledge and therefore technical abilities, essentially I do not posses the knowledge to debug your, or anybody elses code.

I wanted to make you aware of a possible problem, and that is why I opened this thread. Hopefully exploit mechanisms can be introduced in the near future which would mitigate such events.

If the issue persists today I will reach out to @yeungalan, though I can pretty much guess what their response would be, something along the lines of "The ACME module is simply responding to a request it has received and therefore not at issue" leaving me, or anyone else who might experience the same type of errors stuck between a rock and a hard place.

Once again I appreciate your time.

Thanks

[tobychui]

To be honest I think the acme module should be rewritten by someone with more professional knowledge in the field. Current implementation is more like a community maintained functions that everyone contribute code they needs and it is kind of a mess (at least from my view as an embedded system engineer, maybe it make sense from web devops view)

Though, it is too much work for me to do so, I guess @yeungalan will probably be too busy to reply to this thread as well.

Anyway, if you find any more patterns or reproduction steps (maybe a script that replay such attack?) , please open a proper bug report.