Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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?
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.
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).
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.
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'.
Quote:
Originally Posted by RHCE_ran
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.
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.
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.
/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.
Quote:
Originally Posted by jpollard
One additional security issue is auditing tmpfs filesystems is a problem. Evidence of misdeeds is automatically erased.
Both inotify and the audit service are perfectly capable of auditing tmpfs so maybe you mean something else?
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.
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.
/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.
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.
Quote:
Both inotify and the audit service are perfectly capable of auditing tmpfs so maybe you mean something else?
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).
The difference is that such a DoS by filling a filesystem can be controlled by quotas on disk based filesystems.
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.
Quote:
Originally Posted by jpollard
I was thinking of the after the disaster of finding out what happened - the state of the filesystem is gone.
True that.
Quote:
Originally Posted by jpollard
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...
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).
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.
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).
Quote:
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.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.