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.
prelink(8) operates on binaries and libraries. AFAIK, it should never, ever be performing work on /etc/group or /etc/shadow. (There is no reason for it to be.)
Have you added / removed a group, or modified group membership recently? Is it possible some user (i.e. you) has changed his password recently? Those scenarios would account for the HIDS report you're seeing.
Mmm.. My bad.. Not the best examples (Actually looking at them probably the worst) those are the first entries.
Should have thought more about what I was posting.
Changed Files List (Yes users etc added , should have updated AIDE then) Again my bad: Never used AIDE.
This is a new install and has not yet been connected to the network. All the build software has been installed from the DVD.
Given that info, here's where you take a (rather modest) leap of faith, and assume the system is in a "known good" state. From here going forward, you need to have procedures in place to account for any changes your HIDS detects.
To substantially improve the noise-to-signal ratio, I suggest the following:
Prior to planned system changes (user, software, etc.) check your system against the HIDS DB. Account for any detected differences.
Prior to planned system changes (user, software, etc.) check your system against the HIDS DB. Account for any detected differences.
Make the system change.
Update the HIDS DB immediately after.
Thanks...
Given my new experieance and my lack of knowledge this will help.
Unsure if I have a healthy paranoia... But the /home directory is in-tact from an old install. Thus preserving data.
I think I will do fresh install, and go with the updating schema you reccomend.
This time NOT including the old /home partion in the install until I have things up and running and can throughly check out what may be on there.
Sorry no leap of faith for me. But your advice is definatly taken on borad.
Off to read the best way of scanning a potentially infected /home diretory
Unsure if I am having a healthy paranoia.. But should I be rebooting and running and AIDE -init ???
Is it normal for this to happen...
Am I doing something wrong here?
ALSO. Anyone got a link to best way to scan a partion for nasties without connecting to a network BUT having an upto date database for virus / malware / rootkit sigs.
The last two lines are negation examples taken from my own aide.conf. It sounds like your configuration may be too sensitive if it's picking up lastlog.
A couple others things:
RHEL/CentOS rebuilds /etc/aliases.db at boot time (so you're going to need to not monitor aliases.db or get used to the idea of seeing it in reports after a reboot)
Ditto for /etc/blkid/blkid.tab and /etc/blkid/blkid.tab.old. Both may be modified at boot time.
As for binary sizes changing after a reboot..? And /etc/passwd, /etc/shadow, and /etc/group..? That's not right. Are you sure you didn't install some packages between the time you created the AIDE DB and the time you checked against it?
RHEL/CentOS rebuilds /etc/aliases.db at boot time (so you're going to need to not monitor aliases.db or get used to the idea of seeing it in reports after a reboot)
Ditto for /etc/blkid/blkid.tab and /etc/blkid/blkid.tab.old. Both may be modified at boot time.
Thanks...
Strangly I have gone back to working on this pre-production server for home use, been busy studying for exams.
Just doing a Google search on aliases.db which has changed since reboot and found my post.
Yes my config is too sensitive but as you say all those file changes are a bit off....
Past few days I have looked into this and I think I have sorted it. But need to test more.
Down to a combination of 'prelink' and SELinux I think.
Currently I have turned prelink off, and making sure my linux box is SELinux 'Enforcing' for now.
But this did not revert the state of files back for me.
The prelink cronjob has a 'if [ "$PRELINKING" != yes ]; then' section which executes '/usr/sbin/prelink -uav >> /var/log/prelink/prelink.log 2>&1' and you didn't post back any details wrt the "did not revert" part so there's nothing that can be said about that. (Since Aide and prelinking seems a recurring topic and anomie plays a part there as well I'm also linking in this and that thread as people still seem to have problems searching LQ...)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Again my bad: Never used AIDE.
