Detecting and stopping botnet attack

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • JJHosting
    Junior Member
    • May 2026
    • 1

    #1

    Detecting and stopping botnet attack

    Over a 5 hour window I had a website hit with the over 49k bot requests from over 46k unique IP addresses. There is a pattern to the referrer and agent string. What's the best method to provide the attack details so Imunify360 could better respond next time? The distribution over so many IPs was a first for me.
  • akots
    Administrator
    • Mar 2023
    • 129

    #2
    Hi,

    For this type of traffic, I would suggest checking several Imunify360-side options, depending on how stable the bot pattern is.

    Since the traffic was highly distributed - many unique IPs with a repeated Referer/User-Agent pattern - regular per-IP DoS limits may not always be enough if each IP sends only a small number of requests. However, it is still worth making sure that Anti-Bot protection and Enhanced DoS Protection are enabled.

    https://cloudlinux.zendesk.com/hc/en...bot-protection



    You can enable Anti-Bot protection from the UI: Imunify360 → Settings → General → Anti-bot protection

    Or via CLI:
    Code:
    imunify360-agent config update '{"WEBSHIELD": {"splash_screen": true}}'
    You can also enable Enhanced DoS Protection:
    Code:
    imunify360-agent config update '{"ENHANCED_DOS":{"enabled":true}}'
    If needed, you can tune the threshold and timeframe, for example:
    Code:
    imunify360-agent config update '{"ENHANCED_DOS":{"timeframe":60}}'
    imunify360-agent config update '{"ENHANCED_DOS":{"default_limit":500}}'
    For web ports, you can also define separate limits:
    Code:
    imunify360-agent config update '{"ENHANCED_DOS": {"port_limits": {"80": 150, "443": 200}}}'
    That said, in your specific case, if the most reliable indicator is the repeated User-Agent or Referer value, the better approach may be to create a custom ModSecurity rule matching that pattern. This can block the requests directly at the WAF level, or it can be connected with Imunify360’s graylisting logic so that repeat offenders are moved to the Grey List / Anti-Bot challenge.

    For example, a custom rule can be registered in Imunify360 with something like:
    Code:
    imunify360-agent config update '{"MOD_SEC_BLOCK_BY_CUSTOM_RULE": {"77999907": {"max_incidents": 3, "check_period": 60}}}'
    The exact rule should be adjusted to your real pattern and environment. If you use this approach, please make sure the custom ModSecurity rule ID is from the allowed custom range, for example, 779999XX, so Imunify360 can process it correctly.

    For a one-off attack with thousands of rotating IPs, blocking individual IPs is usually not very effective. Matching the recurring request pattern - User-Agent, Referer, URI, or a combination of these - is usually more useful. If the traffic is still reaching the origin in large volume, an upstream CDN / DDoS filtering layer may also be needed, because Imunify360-side filtering happens on the server after the traffic has already arrived.

    If these options do not sufficiently reduce the impact, another good next step would be to open a support ticket with the details of this specific traffic pattern. Our Support team can review the actual access logs, Imunify360 events, WAF behaviour, and server configuration to suggest more targeted tuning. If they identify that the pattern could be handled better by Imunify360 detection logic, they can also escalate the case to the Imunify developers for further review and possible improvement.

    So, in case you'd like to proceed with a report, please include the following details in the ticket so our team can review whether the traffic can be better classified by Imunify360/WAF/Anti-Bot mechanisms:

    1. Affected domain(s) and exact time window of the attack, including timezone.
    2. Several raw access log samples showing:
    - source IP
    - requested URL/path
    - HTTP method
    - response code
    - User-Agent
    - Referer
    3. The repeated Referer/User-Agent pattern you noticed.
    4. Any related Imunify360 Incidents entries, WAF rule IDs, or Anti-Bot/Graylist events.
    5. Whether the website is behind a CDN/proxy such as Cloudflare.
    6. An Imunify360 doctor key:
    Code:
    imunify360-agent doctor
    This will allow Support to check the server-side evidence and, if needed, pass the pattern to the Imunify team for further analysis.



    Comment

    Working...