Sign in Subscribe
Cybersecurity

Zoraxy Reverse Proxy - Forensics

Leon SCOTT

• 6 min read
Zoraxy Reverse Proxy - Forensics
Zoraxy Reverse Proxy

I seriously like this piece of software.

Ran my script again and now it will email me rather than doing all this manually.

Analysis below via Claude (yep, I threw it at the AI).

Zoraxy Reverse Proxy Security Analysis Report

Date: February 4, 2026
System: Zoraxy Reverse Proxy (alex)
Analysis Period: December 2025 - February 2026
Analyst: Security Review

Executive Summary

This forensic analysis identified multiple active security threats against your Zoraxy reverse proxy infrastructure. The most critical findings include:

  • Active bot/scanner attacks from cloud providers attempting exploit enumeration
  • Suspicious automated scraping of application assets from US-based IP addresses
  • Anomalous external access patterns suggesting reconnaissance activity
  • 2,291 blocked exploit attempts successfully mitigated by Zoraxy's protection

Your reverse proxy is performing well in blocking malicious traffic, but several recommendations should be implemented to enhance security posture.

Critical Findings

1. Active Exploit Scanning - HIGH SEVERITY

Multiple Google Cloud IP addresses engaged in systematic exploit scanning:

Primary Attackers:

  • 34.123.170.104 (151 requests) - Google Cloud US
  • 34.122.147.229 (unquantified) - Google Cloud US
  • 34.118.21.126 (73 requests) - Google Cloud US
  • 34.116.214.85 (repeated attempts) - Google Cloud US

Attack Pattern:

  • Repeated attempts to access /sw.js (service worker) with HeadlessChrome
  • Rapid-fire sequential requests (multiple per second)
  • Targeting: nettools.braedach.com and it-tools.braedach.com
  • All requests blocked with 403 status (successful mitigation)

Attack Timeline:

  • Major activity on Feb 1, 2026: 04:20-04:23 UTC and 17:45 UTC
  • Systematic enumeration attempts across both domains
  • HeadlessChrome suggests automated scanning tools

Indicators of Malicious Intent:

  • Headless browser usage (automation)
  • Rapid sequential requests to same endpoint
  • Targeting service workers and application internals
  • Multiple source IPs from same cloud provider

2. Asset Enumeration Campaign - MEDIUM-HIGH SEVERITY

Source: 205.169.39.53 and 205.169.39.57 (DigitalOcean US)

Behavior:

  • Systematic crawling of JavaScript assets on it-tools.braedach.com
  • Methodical enumeration of application components:
    • /workbox-*.js
    • /assets/*.js files (ABAP, Alert, APEX modules)
    • /offline endpoint
  • All blocked with 403 status

Risk Assessment: This is reconnaissance activity mapping your application structure for:

  • Dependency identification
  • Vulnerability discovery in specific library versions
  • Preparation for targeted attacks

3. Suspicious Network Scanning - MEDIUM SEVERITY

Multiple IPs from suspicious networks:

Russian/Eastern European:

  • 45.148.10.99 (1,102 requests)
  • 45.148.10.160 (71 requests)

Netherlands/European Infrastructure:

  • 185.177.72.13 (597 requests)
  • 185.177.72.30 (402 requests)
  • 185.177.72.38 (221 requests)
  • 185.177.72.56 (106 requests)

Analysis:

  • These IP ranges are commonly associated with:
    • VPN exit nodes
    • Proxy services
    • Bot infrastructure
    • Scanning operations
  • Volume suggests automated access rather than legitimate users

4. Chinese Network Activity - MONITORING REQUIRED

Source IPs (China):

  • 58.160.179.21 (1,770 requests)
  • 58.175.3.186 (827 requests)

Observations:

  • Moderate request volume from residential/ISP ranges
  • May be legitimate users OR compromised systems
  • Recommend geolocation analysis of expected user base

Traffic Analysis

Request Volume by Source

Internal Network Traffic (Expected):

  • 192.168.1.x - 22,775 requests (highest internal)
  • 192.168.4.x - 8,586 requests
  • 192.168.4.x - 7,914 requests
  • 192.168.1.x - 6,090 requests

IPv6 Internal:

  • 2001:: - 17,073 requests

External Suspicious:

  • Various international IPs with automated patterns

HTTP Status Code Distribution

Response Codes:
  40,699 - 200 (OK)
  24,869 - 101 (Switching Protocols - WebSocket)
   4,528 - 304 (Not Modified)
   2,788 - 400 (Bad Request)
   2,291 - 403 (Forbidden) ← EXPLOIT BLOCKS
     668 - 204 (No Content)
     657 - 502 (Bad Gateway)
     546 - 521 (Web Server Down)
     285 - 404 (Not Found)
     266 - 401 (Unauthorized)

Key Observations:

  • 2,291 exploit blocks (403) - Zoraxy successfully blocked attacks
  • 657 502 errors - Backend connectivity issues (investigate)
  • 546 521 errors - Web server availability problems
  • 2,788 400 errors - Malformed requests (potential attack attempts)

Anomalies & Concerns

1. AWS US-East Reconnaissance

  • 16.145.76.238 (79 requests)
  • 35.93.135.161 (39 requests)
  • Potential cloud-based scanning infrastructure

2. Backend Reliability Issues

  • 502/521 errors suggest backend services intermittently unreachable
  • Could be exploited during DDoS to amplify service disruption
  • Investigate Proxmox container health

3. Headless Browser Pattern

  • Multiple IPs using HeadlessChrome/125.0.6422.60
  • All from cloud providers (Google Cloud, DigitalOcean)
  • Classic automated security scanner signature

4. International Attack Surface

  • Attacks originating from: US, Russia, Netherlands, China
  • Distributed nature suggests botnet or scanning service
  • No geographic restriction appears to be in place

Security Posture Assessment

Strengths ✓

  1. Exploit blocking is working - 2,291 malicious requests blocked
  2. Logging is comprehensive - Good visibility into attacks
  3. Service worker protection - Prevents JS injection attempts

Weaknesses ⚠

  1. No rate limiting visible - Attackers can send rapid-fire requests
  2. No geographic filtering - Global attack surface exposed
  3. Backend reliability - 502/521 errors create vulnerability
  4. No bot detection - Headless browsers not automatically blocked

Immediate Recommendations

Priority 1 - CRITICAL (Implement Immediately)

  1. Implement Rate Limiting
    • Limit requests per IP: 100/minute for normal endpoints
    • Aggressive limits for /sw.js: 10/minute
    • Block IPs with >20 403s in 5 minutes
  2. Add Bot Detection
    • Block or challenge HeadlessChrome user agents
    • Implement CAPTCHA for suspicious patterns
    • Consider Cloudflare or similar for bot management

Block Known Attack IPs

34.123.170.104 (Google Cloud)
34.122.147.229 (Google Cloud)
34.118.21.126 (Google Cloud)
34.116.214.85 (Google Cloud)
205.169.39.53 (DigitalOcean)
205.169.39.57 (DigitalOcean)
45.148.10.99 (Suspicious Russian range)
185.177.72.0/24 (Netherlands proxy network)

Priority 2 - HIGH (Implement This Week)

  1. Geographic Restrictions
    • Determine legitimate user locations
    • If Australia-only: block non-AU traffic to sensitive endpoints
    • Whitelist specific countries if international access needed
  2. Fix Backend Stability
    • Investigate 502/521 errors (657 + 546 = 1,203 failures)
    • Check Podman container health
    • Implement backend health monitoring
    • Add redundancy if possible
  3. Enhanced Monitoring
    • Set up alerts for:
      • Repeated 502/521 errors
      • New IPs with rapid request patterns
    • Daily security report automation
50 403s from single IP in 10 minutes

Priority 3 - MEDIUM (Implement This Month)

  1. Web Application Firewall (WAF)
    • Consider ModSecurity or similar
    • Create rules for common attack patterns
    • Protect against OWASP Top 10
  2. Honeypot Endpoints
    • Create fake admin pages (/admin, /wp-admin)
    • Auto-ban IPs that access these
    • Gain early warning of scanners
  3. SSL/TLS Hardening
    • Verify strong cipher suites
    • Enable HSTS headers
    • Check certificate validity monitoring
  4. Intrusion Detection System (IDS)
    • Deploy Suricata or Snort on Proxmox host
    • Monitor for attack signatures
    • Correlate with Zoraxy logs

Specific Attack Mitigation

For Google Cloud Scanner Attacks

Firewall Rules:

# Block Google Cloud scanner IPs
iptables -A INPUT -s 34.123.170.104 -j DROP
iptables -A INPUT -s 34.122.147.229 -j DROP
iptables -A INPUT -s 34.118.21.126 -j DROP
iptables -A INPUT -s 34.116.214.85 -j DROP

nftables in use - so these will need to be changed - thinking

Zoraxy Configuration:

  • Add IP blacklist feature if available - yes - available
  • Implement /sw.js specific rate limit (1 req/min per IP)

For DigitalOcean Reconnaissance

Rate Limiting:

205.169.39.0/24: 10 requests/minute to /assets/*
Trigger: 3+ sequential 403s = 24hr ban

For Service Worker Attacks

Best Practices:

  • Implement nonce-based CSP for service workers
  • Add integrity checks (SRI) to all JS assets
  • Consider moving service worker behind authentication
  • Add bot detection specifically for SW endpoints

Long-Term Security Roadmap

Month 1-2

  • Implement all Priority 1 recommendations
  • Document baseline "normal" traffic patterns
  • Create security runbook for incident response

Month 3-4

  • Deploy WAF with custom rules
  • Implement automated threat intelligence feeds
  • Set up security dashboard (Grafana + logs)

Month 6+

  • Regular penetration testing
  • Security awareness for users
  • Review and update firewall rules quarterly
  • Implement zero-trust architecture considerations

Indicators of Compromise (IoCs)

Confirmed Malicious IPs:

34.123.170.104 - Active exploit scanning
34.122.147.229 - Active exploit scanning
34.118.21.126 - Reconnaissance
34.116.214.85 - Exploit attempts
205.169.39.53 - Asset enumeration
205.169.39.57 - Asset enumeration

User Agents to Block:

HeadlessChrome/125.0.6422.60 (automated scanner)
HeadlessChrome/127.0.6533.119 (automated scanner)

Targeted Endpoints:

/sw.js (service worker - high value target)
/assets/*.js (dependency enumeration)
/offline (PWA functionality)
/workbox-*.js (Google Workbox library)

Compliance Considerations

If you handle sensitive data or operate in regulated industries:

  1. Data Breach Notification: Document these attacks for compliance
  2. Log Retention: Maintain logs for 12+ months (regulatory requirement)
  3. Access Controls: Review who has access to proxy configuration
  4. Encryption: Ensure all traffic uses TLS 1.2+
  5. Incident Response Plan: Formalize response procedures

Questions for You

To refine recommendations:

  1. Geographic User Base: Where are legitimate users located?
  2. Public vs Internal: Are these services meant to be internet-facing?
  3. Authentication: Is there authentication in front of these apps?
  4. Data Sensitivity: What type of data do nettools/it-tools handle?
  5. Availability Requirements: What's acceptable downtime for security updates?

Conclusion

Your Zoraxy reverse proxy is actively under attack by:

  • Cloud-based automated scanners (Google Cloud, DigitalOcean)
  • International reconnaissance operations
  • Potential botnet infrastructure

The good news: Your current security is blocking these attacks (2,291 exploit blocks).

The concerning news: The volume and sophistication suggest persistent adversaries who may escalate attacks.

Immediate action required: Implement rate limiting, block known malicious IPs, and add bot detection before attackers identify exploitable vulnerabilities. Fail2ban implementation is a work in progress.

The backend stability issues (502/521 errors) create a secondary vulnerability that could be exploited during DDoS attacks.

Next Steps

  1. Review this report
  2. Prioritize recommendations based on your risk tolerance
  3. Implement Priority 1 items within 24-48 hours
  4. Schedule implementation of Priority 2 items
  5. Set up ongoing monitoring and alerting

Would you like help implementing any of these recommendations?

Report prepared with forensic data from Zoraxy logs covering Dec 2025 - Feb 2026

Like I said lots to learn.

Zoraxy logs are highly detailed, need to get the fail2ban regex definition working and implement via automation. Blanket block all the persistent IP blocks mentioned.

#enoughsaid