Strange DNS attack killing syslog

Discussion in 'Server Operation' started by brainsys, Feb 12, 2026.

  1. brainsys

    brainsys Active Member

    Debian 12 ISPConfig server

    My syslog started growing at a spectacular rate in the past 5 days to a point is was filling the whole server disk. This is caused by millions of these type of entries:
    Code:
    2026-02-12T15:41:55.044210+00:00 v1 named[270743]: client @0x7fce9a3c6498 218.78.140.194#38011 (ofi.com): query (cache) 'ofi.com/ANY/IN' denied (allow-query-cache did not match)
    The IP varies so trying to firewall it out is impossible. ofi.com is a Chinese domain and this is not it's nameserver - hence the 'not match'. It doesn't appear to be impacting the load average but the syslog expanding to fill the disk makes it an effective DDOS.

    I am coping at the moment by running a cronjob every hour filleting syslog of all ofi.com entries. Can any one tell me anything about this type of attack and any other remedial action I could be taking?
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    These hosts are probing you to see if you’re an open resolver and/or trying cache snooping and ANY-query amplification patterns. BIND is blocking them correctly.

    What you could try is to create a file:

    Code:
    /etc/rsyslog.d/ignore-bind-denied.conf
    with this content:

    Code:
    :msg, contains, "allow-query-cache did not match" stop
    and then run:

    Code:
    systemctl restart rsyslog
    This is untested though :)
     
    ahrasis likes this.
  3. brainsys

    brainsys Active Member

    Thanks Till. As if by magic the moment I posted the attack paused. It was expanding syslog by 5GB a day so it would have taken less than 5 days to break this server's spare space.

    If they restart I will test your suggestion and report back.
     
  4. brainsys

    brainsys Active Member

    It did start again . Your suggestion appears tested and working ;-)
    Why millions of attempts from multiple servers is needed to probe for a bind misconfiguration is a mystery. Thank you.
     
  5. Andreas G

    Andreas G New Member

    It is most probably a amplification attack. Request packets are small, but the response to the request can be significantly larger. If the attacker spoofs the requesting IP, they can generate massive traffic to that IP. For example, the answer to the request for ofi.com is over 5000 bytes in size.
     
  6. brainsys

    brainsys Active Member

    Worryingly because I have suppressed the syslog messages won't be stopping the attack continuing. Is there anything I can do to stop the feedback short of disabling BIND? - which is not an option.
     
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    Not really worrying in my opinion, as it's a failed attack. As long as you do not have bandwidth issues and your BIND can handle the load to reject the requests, then they will give up after some time.
     
    ahrasis likes this.
  8. zygotic

    zygotic New Member

    I came across this thread because i'm also seeing DNS amplification attacks using ofi.com. The target of the attacks is the source IPs I/we see in our logs (rather than it targeting ofi.com)

    Solution should be to add something like this to named.conf.options. Doing so stops you being a participant in DNS amplification attacks - in this case where REFUSED responses are sent to the (spoofed) source IPs.

    Code:
         rate-limit {
            responses-per-second 10;
            errors-per-second 5;
            slip 0;
         };
    I'm seeing many thousands of requests from incrementing IPs in at least 2 different /16 networks. Each one will be limited to 5 REFUSED responses. But given there are so many spoofed source IPs i've added fail2ban as well, and then banned the /16s on top of that.
    All the best
     
    ahrasis and Andreas G like this.
  9. mahiro

    mahiro New Member

    Adding onto this, we're also seeing massive amounts of requests for ofi.com against our authorative DNS cluster. We use technitium DNS. I set an aggressive rate limit in hopes they give up eventually.

    DNS testers confirm none of our authoritative boxes are open resolvers, yet they've continued this random sending of a few million requests a day every odd off day for a month now. Will probably just block all of china at our firewalls if this continues
     
    ahrasis and Andreas G like this.
  10. brainsys

    brainsys Active Member

    Still puzzled by this. If it was just a case of finding open resolvers a few tests should suffice. If it was an attempted BSOD then a day's attack should suffice to discover if it's effective (not for us). So just don't understand why it should continue for a week - could still be ongoing but I supprresed the syslog entries so I wouldn't know.
     
  11. mahiro

    mahiro New Member

    I dropped all of china at our firewall, still get a bit from hong kong every so often but I can't figure out why they keep trying, it doesn't work
     
  12. zygotic

    zygotic New Member

    Are you sending REFUSED responses to the requests (until/unless now firewalled off entirely)? Maybe they are part of the point, but from what i've seen they'd be super diffuse over thousands of IPs rather than targeting anyone/anything in particular.

    I assume someone has put together a long list of nameservers that are either open forwarders or can be made to send a high volume of REFUSED responses to a spoofed IP and are using it to either target someone or just be annoying and tie up resources.
     
  13. mahiro

    mahiro New Member

    We do send refused back until it hits a rate limit threshold, at which point it just drops the queries silently. Refused packets are tiny though, even smaller than the lookup itself, so i’m not sure why they would bother. A DDoS at that point would be more effective directly vs using a refused response
     
  14. Andreas G

    Andreas G New Member

    It’s probably not about finding open resolvers. DNS requests use UDP, so they’re “fire-and-forget.” Even with a relatively weak system, it’s easy to launch massive attacks simply by sending packets to thousands of servers. If 99% of the packets are ignored or blocked by a firewall, it doesn’t matter because the attacking system isn’t burdened by them.
     
    zygotic likes this.

Share This Page