Mcafee, Redhat exclusion: best practice

Latest response


could you please tell me if there are exclutions or best practice with using Mcafee


Raphael Dodin.


Hi Raphael,

What you ask is very much opinion based - me personally, I strongly recommend to avoid McAfee and other "so-called" anti-
virus solutions on RHEL. All those are developed for insecure systems like Windows, Linux distributions and especially RHEL
are secure out-of-the-box. If you nevertheless want to install McAfee - be prepared to run into more or less severe issues. :)


Many organizations - especially those that implement "industry" security postures - mandate the use of A/V. :-\

Hi Raphael,

There is an open source solution - ClamAV - you can install, without generating negative impacts to the system. With this
tool you can check if files are infected by virus vulnerabilities on-demand and a daemon for on-access is available as well.

Installation on RHEL 7 :

sudo subscription-manager repos --enable rhel-7-server-extras-rpms
sudo subscription-manager repos --enable rhel-7-server-optional-rpms
sudo rpm -Uvh

sudo yum install clamav clamav-update

Installation on RHEL 8 :

sudo subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
sudo rpm -Uvh

sudo dnf install clamav clamav-update

And in case you want to implement on-access-scanning of e-mails for example, just install the package clamd as well. :)


Should be noted that the most recent Clam A/V on small-memory ELx systems (especially, it seems, 7.7) can be problematic. Basically, unless you add a swap-file to such a system, the systemd-service gets stuck in a start-loop.

Thanks so much for sharing those instructions on installing ClamAV. Those are even better than on the official instructions available here: On that note, that upstream project is welcoming contributions, quoting their note: "where you can contribute to user manual and FAQ.":

I think it would be more valuable for everyone to do that great documenting effort there and making a link here, rather than writing it here :)

FYI, I raised an issue on their github in that regard because I was unable to install ClamAV on RHEL7 following their official instructions. I am flooded with tasks and currently don't have the time to find and improve that installation guide beyond installing the packages (I noticed there is mandatory configuration of clamd to have on-access scanning working).

Anyway, fully appreciate your sharing efforts, I wish I had found your answer earlier, I would have reached the same stage, without wasting a few extra hours on that.

Thank you for this information. However, it would have saved me a lot of my hair, if I found this information in the documentation ( rather than sperad all over the internet.

I am really supporting open-source products over commercial products, however things may run smoother if more energry are put into Github-push-requests (in this case for the documentation) rather this discussion here or other discussions elsewhere (in a general manner, not targeting anyone).

Just see what Mircosoft is doing in terms of installation support: I think technically it will be very much the same as any other Antivirus-software. But they put a lot of effort into "making the life of the admins easier" ... wich is a success factor for them.

Again: I would support ClamAV over Mircosoft. No doubt about it. However, in terms of admin-support and documentation, I have to give the kudos to them. And I would prefer to give it to the OpenSource-Project.

Hi Raphael,

I agree with our friends who gave you good advice. I have been working on Linux systems from the beginning (when kernels had version numbers starting with "0.").

In professional world, I never had to install anti-virus software on Linux servers - no matter what type of industry or business I worked in. Simply, not needed.

Maybe I was lucky :) In so many years in the IT business, I have never personally seen a Linux server attacked by a computer virus either.

My view on best practice: proper management of the servers significantly decrease the risk of virus attack on Linux servers.

Best wishes from massively fire-damaged Australia.

Dusan Baljevic (amateur radio VK2COT)

Hi Dusan,

I completely agree with your view on "best practice" ! Wish you and all the others in Australia the very best ! :)


Hi Dusan,

If a Linux server services Samba shares and people could by accident upload Windows viruses, you are blamed for it. This is the only use case I can think of that would make me install antivirus software on a Linux server.

In this case I would exclude the "McAfee software directories and /boot" to avoid the antivirus software to attack the kernel and to break itself.


Jan Gerrit

Pretty much the exact reasons I was given the first time one of my customers' security people sent out the edicts. Even better was, having replied, "but none of these systems are SMB servers," the security person responded, "but they could turn the system into an SMB server or client and we want to hedge against that". :p

Hi Thomas and the esteemed colleagues,

Exactly! The antivirus software is not really protecting the Linux system – it is protecting the Windows computers from themselves :)

As far as security guidelines are concerned, lot of them are based on "conditional" and vague statements . They also rely on fear factor, where the condition "might" happen sometime.


Dusan Baljevic (amateur radio VK2COT)

Red Hat trick: Did you know RHEL comes with a built in security/vulnerability scanner? Here is the commands for RHEL7 as an example:

  1. Install OpenSCAP : yum install openscap openscap-scanner

  2. Download the OpenSCAP datastream file : wget -c

  3. Run OpenSCAP command to scan : sudo oscap xccdf eval --results results.xml --report report.html com.redhat.rhsa-RHEL7.ds.xml

  4. Review scanner report : firefox report.html

I agree, installing AV on RHEL is a cure much worse than the disease. I won't name any products here, but let's just say I've lost a bit of hair over it, particularly when it comes to AV products working nicely along-side containers.

Unfortunately, the reality is Info Sec departments within large organisations wield a lot of power and cling tightly to their "standards". So, the conversation becomes "Oh you don't want to install AV on the RHEL fleet? Ok, then we'll hire someone more compliant that you". Otherwise read as "you're fired!".

So, some of us don't have a choice. We must find a way to get it working. I, for one, would appreciate more guidance on the topic from RHEL.

BTW, I have AV working pretty well on linux, but it took quite a while to get there.

Hi there, I am also in the process of getting bold myself with trying to install AV tools on RHEL7. Coming from Red Hat and trying to understand your point of view, I have a genuine question: What guidance do you expect from RHEL? There is a page explaining Red Hat view regarding AV tools ( What else could be done? From my point of view, it's more external tools which have an impact on the OS itself (since it appears that the AV tools "hooks themselves" and taint the kernel). It looks more it would be the responsibility of those making those tools to provide guidance. That is not trying to avoid a problem or "throw the hot potato" elsewhere, I have genuine concerns and questions on how we can improve that at RHEL level.

At the moment, I am rather concerned with the quality (or lack of...) on the technical documentation to be useful at operational level. I mean I evaluated several AV tools and none of them are providing clear, easy to follow and working instructions to quickly install and configure the tool and verify it's properly working. Installing something like that (= in that current state) in a well supported and stable OS like RHEL, is cause for concerns for me as a professional. I can translate that by I have the impression of installing something unfinished, occasionally buggy, rather obscure to operate, and which interfere with the rest of my system. That is why I have the impression that the guidance should come at that level, and not at RHEL level.

I'm glad we can discuss about that openly!

Thanks for the insights.

Just gone thru the same as you did.

I'm not english native, I appreciate that you bring it clearly to the point. Maybe a bit staright forward, however, clear to the point.

My two cents regarding the posts above on the documentation for ClamAV is that the folks at ought to maintain the documentation. Don't get me wrong here, it's great for the community here to provide solid feedback/guidance etc on things such as ClamAV, but it's their project. I recognize sometimes those that create a project get busy especially with current events, but in that case, the project ought to have some form of allowable input (maybe a forum) for their own current issues/best practices etc. I realize this sounds like a rant, but the above is just my way to get to finally saying I believe ClamAV ought to provide solid documentation for their own product.

My 2 cents, and nothing against the ClamAV folks either.