During a recent audit we were requested to install antivirus software on our DNS servers that are running linux (bind9). The servers were not compromised during the penetration testing but this was one of the recommendations given.

  1. Usually linux antivirus software is installed to scan traffic destined to users, so what's the goal to install antivirus on a dns server?

  2. What is your opinion on the proposal?

  3. Do you actually run antivirus software on your linux servers?

  4. If so, which antivirus software would you recommend or you are currently using?

  • 10
    i only installed antivirus on linux mail servers, for scanning virus in mail attachments, i don't see any sense in install antivirus on dns server.
    – c4f4t0r
    Commented Nov 9, 2014 at 17:24
  • 11
    Yeah, this doesn't make any sense. Ask the company to clarify that recommendation. Commented Nov 9, 2014 at 17:36
  • Just what antivirus software do they want you to install?
    – hookenz
    Commented Nov 10, 2014 at 0:56
  • Tempted to call "Primarily Opinion-Based," because I feel that a legitimate case could be made to the contrary of the popular answers thus far. :)
    – Ryan Ries
    Commented Nov 10, 2014 at 2:55
  • 1
    We found ourselves in this position - not specifically with DNS but Linux servers in general - and although we agree with the argument against, in the end it was just a box-ticking exercise that we got tired of fighting. So we run centrally managed ESET Antivirus on all servers.
    – HTTP500
    Commented Nov 10, 2014 at 16:18

10 Answers 10


One aspect of this is that recommending "anti-virus" to be on everything is a safe bet, for the auditor.

Security audits aren't entirely about actual technical safety. Often they are also about limiting liability in case of a lawsuit.

Let's say your company was hacked and a class action lawsuit was filed against you. Your specific liability can be mitigated based on how well you followed industry standards. Let's say the auditors did not recommend AV on this server, so you don't install it.

Your defense in this is that you followed the recommendations of a respected auditor and pass the buck so to speak. Incidentally, that's the PRIMARY reason we use third party auditors. Note that shifting of liability is often written into the contract you sign with auditors: if you don't follow their recommendations, it's all on you.

Well, attorneys will then investigate the auditor as a possible co-defendant. In our hypothetical situation the fact that they did not recommend AV on a particular server will be seen as not being thorough. That alone would hurt them in the negotiations even if it had absolutely no bearing on the actual attack.

The only fiscally responsible thing for an auditing company to do is to have a standard recommendation for all servers regardless of actual attack surface. In this case, AV on everything. In other words they recommend a sledge hammer even when a scalpel is technically superior due to legal reasoning.

Does it make technical sense? Generally no as it usually increases risk. Does it makes sense to attorneys, a judge or even a jury? Absolutely, they are not technically competent and incapable of understanding the nuances. Which is why you need to comply.

@ewwhite recommended you speak with the auditor about this. I think that's the wrong path. Instead you should speak with your company's attorney to get their opinion on not following these requests.

  • 2
    Behold why we are held back. A /working/ AV is little defense for a Linux server in most cases as it really only defends the case of somebody using it to distribute malware.
    – joshudson
    Commented Nov 11, 2014 at 16:18
  • 7
    If you're on a hardened machine, an AV is probably going be the only software installed on the server that have a built-in backdoor, i.e. autoupdater. Also, if you manage to make all relevant storages read only, the AV will be the only software that requires write access for updating its signature.
    – Lie Ryan
    Commented Nov 12, 2014 at 12:30
  • 1
    I can't agree with the the point of not speaking with auditors. Auditors make mistakes more often than they like to admit. There is nothing wrong with reaching a mutual understanding that the auditor made a mistake -- just make sure the acknowledgement is unambiguous.
    – Andrew B
    Commented Nov 13, 2014 at 7:01
  • 2
    @AndrewB: I don't think I was saying NEVER to speak with the auditors. Rather, a discussion with your legal reps PRIOR to that would be the best way to proceed. The company needs to fully understand the risk of negotiating with the auditors before trying to go that path.
    – NotMe
    Commented Nov 13, 2014 at 14:46

Sometimes auditors are idiots...

This is uncommon request, though. I would counter the auditors recommendation by securing/limiting access to servers, adding an IDS or file-integrity monitoring or bolstering security elsewhere in your environment. Antivirus doesn't have any benefit here.


As noted in the comments below, I was involved in the launch of a very high-profile website here in the US, and was responsible for designing the Linux reference architecture for HIPAA compliance.

When the matter of Antivirus came up for discussion, we did recommend ClamAV and an application firewall to process submissions from end-users, but managed to avoid having AV on all systems by implementing compensating controls (3rd-party IDS, session logging, auditd, remote syslog, two-factor auth to the VPN and servers, AIDE file-integrity monitoring, 3rd-party DB encryption, crazy filesystem structures, etc.). These were deemed acceptable by the auditors, and all was approved.

  • 2
    +1. There are many things where you can spend resources: time, money, and energy that provide return to your company. Maybe one the auditors read about DNS poisoning and thinks this is a cure. The return on this is negligible. Commented Nov 9, 2014 at 17:47
  • All these are already in place: performance monitoring mechanisms, IPS, network firewall and of course iptables on the server. Commented Nov 10, 2014 at 15:02
  • @JohnDimitriou Then you're in excellent shape. The Antivirus recommendation is a bit strange. Ask the auditors to clarify.
    – ewwhite
    Commented Nov 10, 2014 at 15:03
  • 1
    @ChrisLively This came up during the design of a somewhat high profile environment I was working on last year. We ended up with ClamAV on systems where we were accepting user-submitted data. However, we avoided AV on other Linux systems by outlining our compensating controls and coming to an agreement with the auditors.
    – ewwhite
    Commented Nov 11, 2014 at 15:31
  • I'd say as long as you've shown that you've "sufficiently mitigated the risk" and the auditors are actually signing off that they agree, then legal liability is likely satisfied. Of course, I'm sure the contracts, and other laws, surrounding that particular environment might make it a bit unique.
    – NotMe
    Commented Nov 11, 2014 at 22:15

The first thing you need to understand about auditors is they may not know anything about how the technology in scope is used in the real world.

There are a lot of DNS security vulnerabilities and issues that should be addressed in an audit. They will never get to the real issues if they are distracted by bright shiny objects like "antivirus on a DNS server" checkbox.


Typical modern anti-virus software does more accurately attempt to find malware and is not only limited to viruses. Depending on the actual implementation of a server (dedicated box for a dedicated service, container on a shared box, additional service on "the only server"), it's probably not a bad idea to have something like ClamAV or LMD (Linux Malware Detect) installed and perform some extra scan every night or so.

When asked in an audit, please do pick the exact requirement and take a look into the accompanying information. Why: too many auditors don't read the full requirement, are not aware of the context and guidance information.

As an example, PCIDSS does state "deploy anti-virus software on all systems commonly affected by malicous software" as a requirement.

The insightful PCIDSS guidance column specifically states mainframes, mid-range computers and similar systems may currently not be commonly targeted or affected by malware, but one should monitor the current actual threat level, be aware of vendor security updates and implement measures to address new security vulnerabilities (not limited to malware).

So after pointing at the list of around 50 Linux viruses from http://en.wikipedia.org/wiki/Linux_malware in comparison to the millions of known viruses for other operating systems, it's easy to argument a Linux server not to be commonly affected. The "most basic set of rules" from https://wiki.ubuntu.com/BasicSecurity are also an interesting pointer for most Windows-focussed auditors.

And your apticron-alerts on pending security updates and running integrity checkers like AIDE or Samhain may more accurately address the actual risks than a standard virus scanner. This may also convince your auditor of not introducing the risk of installing an otherwise unneeded software (which provides a limited benefit, may impose a security risk or simply break).

If that doesn't help: installing clamav as a daily cronjob doesn't hurt that much like other softwares.


DNS servers have become popular with PCI auditors this year.

The important thing to recognize is that while DNS servers do not handle sensitive data, they support your environments which do. As such, auditors are starting to flag these devices as "PCI supporting", similar to NTP servers. Auditors typically apply a different set of requirements to PCI supporting environments than they do the PCI environments themselves.

I would speak to the auditors and ask them to clarify the difference in their requirements between PCI and PCI supporting, just to make sure that this requirement didn't accidentally sneak in. We did need to make sure that our DNS servers met hardening guidelines similar to the PCI environments, but anti-virus was not one of the requirements we faced.


This could've been a knee-jerk reaction to the shellshock bash vuln, it was suggested online that bind could be affected.

EDIT: Not sure it was ever proven or confirmed.

  • 11
    Which, oddly, anti-virus software would be of no help for.
    – Bert
    Commented Nov 9, 2014 at 18:48
  • @Bert can't antivirus detect vulnerable bash?
    – Basilevs
    Commented Nov 10, 2014 at 13:00
  • shellshock was already patched and servers successfully passed the tests Commented Nov 10, 2014 at 15:03
  • Hey... I'm not saying it's going to help, I'm just saying it's probably what they had considered to be helpful.
    – D Whyte
    Commented Nov 10, 2014 at 18:37

If your DNS servers fall into PCI DSS scope, you may be forced to run AV on them (even though it's downright silly in most cases). We use ClamAV.


If this is for SOX compliance, they're telling you to install antivirus, most likely, because somewhere you have a policy that says all servers must have antivirus installed. And this one doesn't.

Either write an exception to the policy for this server, or install AV.


There are two main kinds of DNS servers: authoritative and recursive. An authoritative DNS server tells the world what IP addresses should be used for each hostname within a domain. Lately it's become possible to associate other data with a name, such as e-mail filtering policies (SPF) and cryptographic certificates (DANE). A resolver, or recursive DNS server, looks up information associated with domain names, using the root servers (.) to find registry servers (.com), using those to find domains' authoritative servers (serverfault.com), and finally using those to find hostnames (serverfault.com, meta.serverfault.com, etc.).

I can't see how "antivirus" would be fitting for an authoritative server. But practical "antivirus" for a resolver would involve blocking the lookup of domains associated with the distribution or the command and control of malware. Google dns block malware or dns sinkhole brought a few results that might help you protect your network by protecting its resolvers. This is not the same sort of antivirus that you'd run on a client/desktop machine, but proposing it to the party responsible for the "antivirus" requirement might produce a reply that helps you understand the nature of the "antivirus" requirement better.

Related questions on other Stack Exchange sites:

  • How is what you're describing an anti-virus? It sounds like a cross between an anti-spam filter and a firewall. To me, that's like saying iptables is anti-virus software.
    – Patrick M
    Commented Nov 11, 2014 at 17:01

Better to run Tripwire or AIDE

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .