We have developmental and production servers running on Red Hat 5.X. My query was that are there any anti-virus available for Red Hat 5.X as I am concerned for the security of the systems.

I hope my question is clear of whether there are any anti-virus’s available for Red Hat 5.

Please revert with the reply to my query.

Regards

There are several available...if you went to Google and put in "antivirus programs for redhat linux", you will see many documents and programs available to you. Did you try that first??? Symantec, Kaspersky, McAfee all make products for Linux. Clamav is an open-source product. Some basic research of your own is the best place to start for any question.

Also, since you're using Red Hat ENTERPRISE Linux, have you contacted Red Hat support? They have documents in their knowledegebase that talk about this, and they can help you with such questions. You are PAYING for RHEL, right?

1 members found this post helpful.

You may as well know that all of the "anti-virus for Linux" products only look for Windows virus problems.

install ClamAV
it should be in the rhn repo for rhel5.10
or
build the source

now it really only will look for Microsoft Windows viruses
and is mainly used for mail servers

or if you are receiving and sharing a LOT of MS windows files

then run

1 members found this post helpful.

Thanks for your answer. We have Red Hat license with L3 support only which means direct technical request to Red Hat cannot be placed.

Is that Red Hat antivirus only detects Windows virus problems?

Requesting a revert on this.

Regards

Thanks for your answer. Is it that Linux anti-virus only look for Windows virus's as there are no virus's for Linux? That may imply that Linux is completely safe and it does not need any anti-virus.

Requesting an update.

Regards

"completely safe" is a misnomer.

There have been worms for linux in the past. What happens though is that the patch is usually provided by the project(s) faster than the malware propagates.

It is always possible for the owner to install malware. It is even possible for users to install malware.

But the base design of Linux provides a good compartmentalization between the system and users that the system itself is quite well protected. It also provides separation between users - but the users CAN defeat that protection by allowing others access to their files.

RH/Fedora and derivatives also provide SELinux, which provides a mandatory access control that cannot be bypassed by users. The best example of its use is in compartmentalizing Apache. A vulnerability in the web server can allow entry... but the apache process, and any penetration, is constrained to access only files granted apache. If /tmp has not been labeled to grant access (and it shouldn't) then no process started by apache (nor apache itself) can access it - even though it has world access. This capability also protects the separation between system and users, and can be used to define separation between users.

The remaining problems of current RH/Fedora/CentOS are design failures - users can still crash the system in one way or another - mostly by exploiting the design failures.

1. /tmp is a tmpfs mount - by default this allows users to fill half of physical memory.
2. /run is a tmpfs mount - AND has user owned and writable directories (credential storage, and others). This also allows the users to fill half of physical memory. (thus deadlocking the system).

#2 has the added problem that when /run is filled, no user can login (not even root) because credentials can't be stored. It also can cause problems for services that can't start due to the inability to be added to the /run (pid files for instance).

This cannot be fixed very well. tmpfs was not intended to be used when mixing user files and system files, especially on servers. /tmp can be mitigated by not using tmpfs for a mount. /run cannot be replaced - the data is supposed to be transitory, and is removed on logout or reboot. Making it a real filesystem would require deleting anything in that filesystem on boot, which would take time (if its a small filesystem it could be erased by a mkfs prior boot).

One additional security issue is auditing tmpfs filesystems is a problem. Evidence of misdeeds is automatically erased.

tmpfs works quite well for what it was designed for - tracking shared memory segment allocations. It also seems to work for cgroups. Neither of these are writable by users (though some possibility exists for the /sys/fs/cgroup...).

And in case you are thinking of quotas, quotas aren't supported by tmpfs. Partly due to the fact that the quota files get deleted when the system is shutdown, so the quota files would have to be reestablished on boot - the rest is that the kernel developers don't want the overhead of quota checking imposed on shared memory segments (it can get relatively slow if you have a lot of users, and it wastes yet more memory).

2 members found this post helpful.

L3 support means you have full access to the Red Hat knowledgebase, which covers anti-virus type questions. Also, please check your use of the word 'revert'.
Again, can you not look this up for yourself?? There have been THOUSANDS of articles written about Linux and anti-virus over the years, which you can easily find. Posting updates after ten minutes or so asking for updates won't get you an answer any faster.

jpollard hit it on the head...there is no such thing as 'completely safe', unless you have your computer disconnected from ANY network, and locked in a bank vault that only you have access to. THEN it's completely safe.

/run as tmpfs is not intrinsic to RHEL, CentOS or Fedora: it was pondered by Debian devs in the previous decade and cross-distribution adaptation started around 2011 AFAIK. The risk of a DoS by filling a tmpfs is a same level risk as filling any file system like /var or any runaway process filling the process table and running (production) servers without tuning, hardening and auditing simply is waiting for disasters to happen.


Both inotify and the audit service are perfectly capable of auditing tmpfs so maybe you mean something else?

If you are concerned about systems security then antivirus is not the first thing to look at. Instead widen your scope, inventory what machines you are responsible for, what their purpose is and assess the security posture of everything. List problems in order of severity, draw up a plan and then go and methodically fix things. Note security is not a one-off (like installing antivirus software) but a continuous cycle of auditing and adjusting.

*Also, looking at your previous threads, do note LQ is a forum. This means you should ask detailed questions, respond in a timely fashion, clarify when needed, in short: interact.

The difference is that such a DoS by filling a filesystem can be controlled by quotas on disk based filesystems. And there are quotas available for the process table as well.


Actually not - inotify has inherent limitations that make it unreliable. It is not designed to monitor entire filesystems.

I was thinking of the after the disaster of finding out what happened - the state of the filesystem is gone.

Audit services are fine --- if you can get logged in; and the logs aren't corrupted, AND you happen to be monitoring exactly the right things...

Whenever I had set up a server, any user accessable filesystem was always mounted with quotas, nosuid/nosgid. And NO user was allowed write access to a filesystem with sensitive data on it (such as /var, and now /run; /var/tmp would be either a link to the mounted tmp, or be a mounted filesystem itself).

And tmpfs has mount options. So not taking care of that before putting a system into production clearly classifies as a typical layer 8 problem.


True that.


Log corruption, nice, but you're opening a can of worms that includes everything that can be corrupted. With local + remote logging one stands some chance. Wrt auditing I find compliance helps wrt focus (else there's LSPP, CAPP and whatnot rule sets to adapt) but otherwise people generally give auditing way too little thought (until after the fact).

The only options that tmpfs has is size. That can help a deadlock, but it doesn't help the DoS of either one. Once /run is full, you can't log in (credentials can't be stored). Neither can services restart or be started (pid files fail - been there done that).

The problem with Fedora/RH/CentOS is that remote logging is no longer really supported, so you have to also add rsyslog to get any...(now in the "yet another service that has to be run" that could fail with systemd).