Sign in Subscribe
Cybersecurity

Zoraxy Proxy Threat Reports

Leon SCOTT

• 3 min read
Zoraxy Proxy Threat Reports
Zoraxy Reverse Proxy

Let’s go through this cleanly, concisely, and with the level of forensic clarity you expect.

This is the result of the output of a script that Cortana (AI) and I are building.

🧭 High‑Level Verdict

Your Zoraxy logs show:

✔️ Normal internal traffic

✔️ A lot of harmless bot noise

✔️ Several automated scanners

✔️ One very interesting SSRF attack attempt

✔️ No evidence of compromise

✔️ Zoraxy successfully blocked everything that mattered

You’re not breached.
But you are being scanned — constantly — which is normal for any public service.

Now let’s break it down properly.

🟢 1. Internal Traffic (Safe)

These are your own devices:

  • Removed for privacy - its all okay

These are all safe and expected.

🟡 2. Harmless Bot Noise

These are normal crawlers:

Search bots

  • OpenAI SearchBot
  • ClaudeBot / Claude-SearchBot
  • Baiduspider
  • InternetMeasurement.com
  • Scrapy-based crawlers
  • okhttp/5.3.0 (Android app scanners)

These are not malicious — they’re just indexing or probing.

🔵 3. Suspicious User Agents (but not dangerous)

Your summary shows:

  • Dart/3.9 — often mobile apps or scripts
  • Go-http-client — common for scanners
  • Python aiohttp — scraping
  • curl — automated probes
  • HeadlessChrome — automated scanning tools
  • WebCopier — offline site downloader

These are typical internet background noise.

🔴 4. The Only Real Attack Attempt: SSRF Probe

This is the one that matters:

185.177.72.38
GET /proxy?url=http://169.254.169.254/latest/meta-data/

And repeated across:

  • /proxy
  • /fetch
  • /api/proxy
  • /redirect
  • /load
  • /request
  • /curl
  • /get
  • /ssrf

This is a systematic SSRF attack attempting to reach:

169.254.169.254/latest/meta-data/

That is the AWS EC2 metadata endpoint.

Attackers use this to steal:

  • IAM credentials
  • Access tokens
  • Instance metadata
  • Cloud secrets

This is a known cloud exploitation technique.

✔️ Zoraxy blocked every attempt

✔️ Your services did not forward the request

✔️ No compromise occurred

But this is the only attack in the logs that is actually malicious.

🟡 5. Other Exploit-Blocked Events

These are not real exploits — Zoraxy is over‑classifying them:

Examples:

  • /robots.txt
  • /sw.js
  • /favicon.ico
  • / on random subdomains

These are just bots checking for:

  • site structure
  • service-worker files
  • default pages
  • CMS fingerprints

Not dangerous.

🟠 6. The IPv6 Traffic

Your IPv6 addresses:

Removed for privacy

These are Telstra / Aussie Broadband IPv6 allocations.

They’re your own devices or local apps.

Safe.

🧨 7. The Only IP Worth Blocking

185.177.72.38

This IP repeatedly attempted SSRF exploitation.

It belongs to:

  • M247 / AS9009
  • A known hosting provider used by attackers
  • Frequently seen in credential stuffing and SSRF scans

You should block it at:

  • Zoraxy
  • nftables on Baden
  • Proxmox host firewall

I can generate the nftables rule if you want (Cortana)

This I need to think about as I have not got very far with my n8n learning, although I have made a good start. I could use n8n to read the Zoraxy logs and then modify the nftables on all of the above. This of course would require another alteration of the scripts and tables - I would need another nftables.conf file that n8n controls.

🧩 Summary

Here’s the clean verdict:

CategoryStatusNotes
Internal traffic🟢 SafeYour own devices
Search bots🟡 NormalExpected
Scrapers🟡 NormalHarmless
HeadlessChrome🟡 NormalAutomated scanners
SSRF attack🔴 BlockedOnly real threat
Exploit-blocked events🟡 Mostly noiseNot real exploits
Compromise detected🟢 NoneSystem is safe

🛡️ Fail2Ban solution

I am currently testing this so it's a work in progress.

⛔ Zoraxy Filter

[Definition]
# Detection: Matches the client IP and the exploit signatures
failregex = ^.*\[client:\s*<HOST>\].*(?:\[router:exploit-blocked\]|url=http://169\.254\.169\.254/|GET\s/(?:proxy|fetch|api/proxy|redirect|load|request|curl|get|ssrf)\?url=|HeadlessChrome|Python/|curl/|Go-http-client|Scrapy/|InternetMeasurement)

# Exclusions: Ignore internal IPv4 (192.168.x.x) and IPv6 Link-Local (fe80::)
ignoreregex = ^.*\[client:\s*(?:192\.168\.|fe80:).*\]

datepattern = ^%%Y/%%m/%%d %%H:%%M:%%S

Test the filter

fail2ban-regex "/srv/zoraxy/log/zr_*.log" /etc/fail2ban/filter.d/zoraxy-strict.conf

⛔ Zoraxy Jail

Modify the jail file

# Zoraxy Jail
[zoraxy-strict]
enabled  = true
port     = http,https
filter   = zoraxy-strict
logpath  = /srv/zoraxy/log/zr_*.log
# This line excludes your internal IPv4 and IPv6 ranges
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16 fe80::/10
##### One strike and you're out for specific exploit patterns
maxretry = 1
findtime = 1h
bantime  = 24h

Testing

That is excellent news! Jumping from 54 to 107 matches means the regex is now catching nearly double the malicious traffic it was before. It’s a very satisfying feeling to see the security layers snap into place like that.

Since the filter is now verified and catching the "bad guys," you are ready to go live.

Once you restart Fail2ban (systemctl restart fail2ban), you can use these commands to watch the "bouncer" in action:

🛠️ Task 💻 Command
Check Zoraxy Bans fail2ban-client status zoraxy-strict
Unban an IP fail2ban-client set zoraxy-strict unbanip <IP>
Test Email manually echo "test"
View nftables set nft list set inet f2b-table f2b-zoraxy-strict

Well, that just proves you can't rely on Cloudflare native defenses through their proxy.

I'm probably going to break something - but I was careful to leave internal ip addresses out of it. Now I check in now and again and see what gives in more way than one or wait for fail2ban to send me a staggering number of emails.

#enoughsaid