Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Every log file should be keep when it comes to security. One log file might not have all information you need or you might miss out on side steps been done.
Nother thing security wise is not to download the log files but to have them send to a logging server right away. An intruder will most likely alter the log files so downloads would not show any evidence. If you have the log files on another server you can compare them and see if they differ. If you need to investigate.
Centralized logging is the best route here, with extremely limited access to the logging server.
One great way to do this is with rsyslog. It can take UDP 514 (standard syslog) or TCP 514, which ensures delivery. UDP has no retry mechanism; it's fire and forget. TCP will retransmit if there is an error on the wire.
One file you should always keep an eye on is /var/log/secure as well.
OSSEC is also a great tool to install on your system. It will watch for any suspicious activity and alert administrators when it is detected. I work for a very large telecom and we have this type of alarming in place. We know when a security event occurs even before the security NOC knows and have taken action to prevent further intrusions in the past.
Talking about logs indeed is one thing. Too often I still see people don't alter logrotate defaults, meaning that given an incident a couple of months ago anything of use will already be rotated away and gone. Secondly it still needs emphasizing security is not a one off but (after the initial hardening process) a continuous process of auditing and adjusting. This means for example that installation of a service must be preceded by informing yourself about the (in)security of the software and the ways in which to mitigate risks, and be followed by proper configuration, testing and regular log checks (Logwatch?). Also note that one shouldn't rely on one auditing tool alone. For example the rootkit component of OSSEC HIDS hasn't as a whole been updated much since the product was bought by a large commercial vendor (and if you only want the file integrity checking part you could well use Samhain or even AIDE or tripwire). Finally, as the OP seems to be using Cpanel, he should be especially aware of the pitfalls of using such products.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.