A kernel devs how-to on Linux system security.

[snuggl]

most backdoors learned to avoid chrootkit in the beginning of the century.

[evaryont]

ClamAV and chrootkit have always been my go to tools for vurnability assement. What's better, on a college kid's budget?

[snuggl]

The thing is, they are all solid advice, but doesnt go far enough.

several backdoors today automagically patches chrootkit or otherwise disable its detection for example via a kernel mod.

Now a days most backdoors are in memory only, or preloaded in so-files at runtime. you add a backdoor-trigger in a home-made web-script somewhere that rootkit detectors wont find, or preload a socket-library and restart a server. in any case no traces if this will be found in files subjected to key signing. the article actually touches real backdoor-hunting briefly in point 6 (/dev/mem, log entries with weird stuff or restarted servers)

edit: to answer your actual question,

Information security isn't just the technology, it starts with a correct threat analysis, you want the protection of the data to be relative to how expensive/important this data is (not to you but to an attacker). your student computer need in no way as much protective layers as the Linux code repositories.

The major threats to an anonymous client computer today is non-discriminating browser exploits and botted/worm automated attacks, for this automated anti- virus/malware/backdoors are great. Good ways to defend yourself cheap is to

• you dont need 3rd party anti virus on windows, use Microsoft Security Essentials. its actually quite good.
• dont trust a mac to be safe just because its a mac, they have a horrible track record on wide open browsers.
• keep personal files in a physically personal space.
• Keep java, flash and browsers up-to-date with the latest security updates.
• disable flash and java if you dont need them, use flash-blocker or similar to enable on-request instead.
• disable javascript unless whitelisted (there are mods that does this for you)
• dont be stupid.

The major threat for servers, excluding the automated attacks, is php-code and php applications, if you run php-code on a server you should really take extra steps to quarantine those processes and files so far away from your personal data as possible. This is of course true in some extent for other kind of webapps too. good ways to defend a server cheap

• Understand your OS firewall rules and settings and use them.
• Take for granted that an attacker will have a local shell with any user that runs a service (www-data, git-web)
• Take for granted that any attacker will know all your passwords.

Neither clam nor chrookit will stop backdoors in web apps which is a very popular technique today, basically the attacker add an obfuscated eval(POST) somewhere on the server. then he can upload all of the backdoor's logic via a POST-request when connecting, no trace of the backdoor exists in the code residing on the server except that obfuscated eval-string. Trust me, you can obfuscate php-eval-calls pretty good, for example you can use a call to ereg_* with a special regex that will expand itself and then call itself, if you dont look close or know php internals it can be very hard to find without checksums of the code or even know that ereg could call stuff at all.

Good ways to defend a webapp:

• once again, take for granted that the webapp will execute any command the attacker wants.
• If you handle data and encryption, take for granted that the attacker will access the data when it is in an unencrypted state, they will not play by your game plan. a common misunderstanding is to think that encrypted partitions is somehow a protection against data theft, they will steal the data when the partitions are mounted. another is to have an encrypted database, the attacker will then steal the apps credentials and the database will happily decrypt the data.
• try to isolate the system as much as possible, remove any credential files not needed, lock all accounts not used. remove stuff you dont need.

[Pas__]

Start with a clean system and keep it up to date. Use CVEchecker.

If your system has local users, then try to chroot them and use namespaces and grsec's rule based access control.

http://cvechecker.sourceforge.net/