AIDE 0.15.12+squeeze and config file
 

Hi:

Before I start removing packages from Synaptic Package Mgr. I wanted to post this package because (think) it will be a help to my OS.
This is what Synaptic gave in the description.

AIDE is an intrusion detection system that detects changes to files on the local system. It creates a database from the regular expression rules that it finds from the config file.
This package contains the statically linked binary for "normal" systems. You'll want to tweak the configuration file:
etc/aide/aide.conf
URL: http://sourceforge.net/project/aide

What kinds of questions should I be going through to determine what packages I should install?

And, what packages I should remove?

I have an overwhelming amount of packages that are not installed and even though I read the descriptions sometimes I am unable to distinguish if they are really necessary or not.

The other thing is that if I do install this AIDE for Intrusion Detection what exactly would I add to the config file that is associated with this application?

This http://sourceforge.net is not in my sources.list; is it trustworthy?

"What tasks do I need to perform right now and is the package I choose the best choice for that task?"


Ideally applications you don't use right now.


Unlike distributions that make new Linux users install everything I suggest you install only what you need. You can always install something later on when you actually need it.


That depends on if Debian ships AIDE with an example or /etc/aide.conf. Minimally you'll want to define:
See 'man aide.conf' for details and the aide@cs.tut.fi mailing list and archives.
* Do note that for AIDE to be effective you have to have a necessity for running it and your have to realize it is a passive, post-incident auditing tool. Passive here means it requires you to run it manually or using a cron job (compare with Samhain which runs as a daemon) and post-incident here means it does not prevent anything and can only alert you after the fact. The latter means the emphasis should be on prevention (machine hardening, binary, configuration file and database backup to detached, trusted media, use in conjunction with other auditing methods). Luckily distributions come with loads of documentation and Debian is home to one of the oldest but still relevant ones: the Securing Debian Manual. To gauge if the investment required is worth it ask yourself this simple question: in the event of a (perceived) breach of security, how much is an audit trail worth?


Best install packages from official repo's (though in the case of Debian that's no ironclad guarantee as it doesn't mandate and enforce package signing policies AFAIK). As for external sources, Sourceforge.net is as trustworthy as its security posture and the code they host is as trustworthy as the people who have access to uploading code. In some cases a developer may provide package hashes (which doesn't tell you anything about the integrity of package contents) but in a lot of cases developers just don't care. Not so in the case of AIDE as they offer GPG-signed packages which IMNSHO should be the standard.

unSpawn:

You throughout answered my questions and provided me with what I needed:

ie:)
-aide@cs.tut.fi the mailing list; archives
- the Debian website; Securing Debian Manual
-Information regarding the configuration file
-Emphasis on prevention
And other good instruction and advice that I needed to hear; Thank You

An audit to me is worth more than gold to me. I'm not in favor to vulnerabilities as I'm sure your not either.
Which leads me to what you cautioned me on:

Recently; I learned how to un-pack a package and have a look at what it contains. That is if I am suspicious of course. And in this case since I haven't manually un-packed a package yet; I'm thinking that I should err on the side of caution. I tend to be somewhat skittish at the practice of a new procedure but once well educated I'll proceed.

I acknowledge the "no ironclad guarantee" It is tho my hope that Official repositories are good. I can't imagine a deliberate attempt to corrupt files but if I've learned anything from life; anything is possible-

I will go and learn more about:
I don't know what they stand for; Google should provide me with that-

You have been a good help to me again; Thank you:hattip:

AFAIK- as far as I know...
And IMNSHO- in my not so humble opinion...got it-

Perhaps I expect to much; but IMO they (Debian)should make authoritative order/injunctions over packages.
But; I also don't have government experience.

If your machine is only a client, meaning it does not provide any networked services, and you use common sense then you expose almost nothing for anyone to scan let alone attack. That would minimize the need for system integrity verification and access and usage logging quite a bit.


Ninety nine per cent of the time keeping informed (Debian security mailing list), using what official repo's offer and verifying sigs and hashes will do just fine. Being able to use different verification methods will allay suspicions and establish validity for the other one per cent.

Indeed for now my machine is just a client so I don't have much concern for caution.

However, when I am ready to put my work online to make my living I will have to perform tasks and put emphasis on what I have learned from you today.

I receive notification from Debian Security on a regular bases through e-mail so I feel I've made a good practice with that-

I now am confident and well educated (thanks to you) to open Synaptic Package Manager and start making appropriate choices.

You said: " Being able to use different verification methods will allay suspicions and establish validity for the other 1%"
If there is more than one way to verification I will resuscitate that when I am finished building my online business website.

You are good at what you do unSpawn; the time you have taken to teach me what I needed to learn is appreciated; Thank You

...which makes it the perfect setup to test out stuff without the stress of having to get things right right away. You do make backups don't you?


Sounds interesting. Do let me know when you're starting up the project.


You're welcome. I'ts quite simple though. If you choose to use Linux because it offers you performance and versatility, helps you protect assets and provides services in a continuous, stable and trustworthy way then you are not "using Linux because it's Linux" but you are making an investment. That kind of investment warrants protecting as it represents value in terms of time, effort, money and often a business or brand name. So getting things right before the trouble starts just seems common sense to me.


Compromises have happened to kernel.org (2011), GitHub (2012), Fedora (2008, 2011), Debian (2003, 2006), OpenSSH (2002) Sendmail (2002, 2006), tcpdump (2002), Proftpd (2010), Unreal IRCd (2010), WineHQ (2011). In some cases Security Officers have alerted the public, in others it's been eyeballs trained on the source noticing diffs and in others, like for instance the infamous Ubuntu "Waterfall" screen saver, it's been users questioning odd behaviour that have alerted the public. Some options in no particular order:
- Distribution, repository and package GPG-sig checking (also see sig revocation),
- package hash and package content hash check,
- package (content) (hash) check against packages downloaded from different mirrors,
- package contents diff against official CVS/GIT/whatever else source,
- CVS/GIT/whatever else commit logs (see the kernel.org explanation),
- asking distro / infrastructure SO's, repo maintainers, software developers or fellow users,
- running the package in a sandbox (file system and network access, tracing system calls),
- "odd" system log messages,
* I'm probably forgetting something.

When using official packages you'll enable whatever verification your distributions package management offers and you'll implicitly trust the distro or repo owner to act responsibly. Which options you choose is best dictated by the situation. If you think something is odd then it is your responsibility to check things out (and that includes ignoring sheeple who tell you "not to worry", "think everything is OK" or call something "overly paranoid" w/o backing up their claims with accurate, authoritative, factual information).

Yes, indeed, I do make backups.

And like you said and I'm not just agreeing because you've mentioned it but I have made an investment. A very big investment one I've dedicated myself to for the last 12 years; 3 in which using Linux has greatly improved my skills.

GIMP will be my number one application when I open my new Studio and I'll let you know when I start up the project.

Starting a new business and using Linux to do it is going to be amazing!

You said:;" If you think something is odd then it is your responsibility to check things out (and that includes ignoring sheeple who tell you "not to worry", "think everything is OK" or call something "overly paranoid" w/o backing up their claims with accurate, authoritative, factual information)."

This to me is a Big Red Flag that something is Not Right and all the more reason for me to investigate.

I'll continue my further reading at debian.org/doc/manual/securing-debian-howto/
And see if the library has "Maximum Linux Security" Attackers Guide To Protecting Your Linux Server And Network" ISBN 0672313413 July 1999. I think it's paperback-

I'm not a security expert, but I always install rkhunter right after performing a fresh install and configure it to update the files properties database every time dpkg/apt-get/aptitude/synaptic run. This way I can know if a file has been altered without the package managers' intervention (and it can also scan for known rootkits).

Of course, it alone may not be 100% infallible, but I think it may be used in combination with other tools and the methods suggested above by unSpawn.

This "rkhunter" is new to me. I'll look in Synaptic and see if it's there.

I'll have to learn more about the how to configure applications in order to do as you have.
I'm still going through the learning process.
Thanks

You can install it through Synaptic, and after installing it (and having closed Synaptic), execute (as root):

You will be prompted with some questions. I usually answer "Yes" to all questions, then I execute:

This will update the file properties database. Then anytime you want to scan your system, execute:

BTW, sometimes I have gotten some false positives with rkhunter detecting some rootkit named Xzibit. If I recall correctly, I once had to modify some configuration files and on another install I just purged rkhunter (with aptitude) and reinstalled it again.

Odiseo:

I wrote down your instructions and know what to do now if
Until you told me I was not aware of this application.
Thank You

If you get some warning with rkhunter, you shouldn't automatically assume that it is a false positive. In my case, I supposed it was a false positive because I received this warning in a freshly installed system with little chances of being infected and a web search returned some info suggesting this (link). If in doubt, it's always better to investigate or resort to the forum (LQ has a security subforum).

Regards.

Ok; now I understand; It is not wise to assume and when I have doubt or am suspicious I will investigate.
The last thing I want (I'm sure I speak for many) is a breach in security.

Thank you for helping me; have a good weekend.

Sincerely,
Ztcoracat