LinuxQuestions.org - Should i worry?

By the way how would i know if i got hacked?
To determine chances of getting your box being subverted depends for instance on:
1. what (publicly accessable) services you run and how they are secured (and access to them),
2. what (way) users are allowed (limit(ed|less)) access to the system,
3. what access rights users have to system commands and resources.
The generic best way to remove possibilities for system compromise is to work and think along the lines of the ancient security mantra: "that which is not explicitly allowed is forbidden". For details on securing and hardening, please see the LQ FAQ: Security references.

To know what the "best" ways to check for system compromise are and how to prevent them or determine status, you should know a system can be controlled by a cracker. The worst case scenario will reroute system calls to for instance filter out and hide processes. This can be done for instance by loading a Linux Kernel Module (LKM, see for instance the Adore-ng LKM), changing the running kernel's memory (see for instance the Suck-IT rootkit or Google for Silvio Cesare's docs) or preloading a library (ld.so rootkit).
The generic best way to address these issues is to:
1. take away capabilities to load modules and change memory structures (in the case of LKM's: kernel recompile or lcap, rest: kernel patch: 2.2.x: Open Wall, 2.4.x: Grsecurity, LIDS, 2.6.x Grsecurity or LSM?), and
2. deny users access to resources (files, devices, processes) they do not explicitly need, and
3. make system binaries, config files, authentication databases immutable (or partition mounted readonly when not using ext2/ext3fs) and make access logs append-only.

The generic best way to detect system tampering is to:
1. install and regularly run a filesystem integrity scanner (Aide, Samhain, tripwire) right after you installed the OS, and before it was connected to a network. Save a copy of the binary, databases (,system configs and package manager databases) on readonly media (or secured signature server) for later use. If unsure, reboot the box loading a kernel from a trusted source like your distributions bootable cdrom, Knoppix, Trinux, tomsrtbt before checking.
This solution beats running Chkrootkit or Rootkit Hunter, because the result should show *any* changed file on the system and not just in the statically coded locations like those two apps use.
2. verbose and make use of system logging, process the logs and regularly check the reports.
The essence is that whatever exploiting takes place most likely will be noisy, and so logging about everything gives you a better view on what's happening. Verbose logging should not be seen as a nuisance: you can't detect problems if you don't log 'em. Run a logwatcher/analyser to regularly supply you with logs. Please check out Grsecurity, logging options else maybe try the procmon LKM.
Here's an example of Grsecurity doing exec logging (in a chroot, syslog date cut away):

Code:

exec of /chroot/hammettk/bin/ls within chroot by process (bash:22741) UID(1001) EUID(1001), parent (bash:8391) UID(1001) EUID(1001)

exec of /chroot/hammettk/usr/bin/du within chroot by process (bash:23616) UID(1001) EUID(1001), parent (bash:13778) UID(1001) EUID(1001)

exec of /chroot/hammettk/usr/bin/df within chroot by process (bash:16468) UID(1001) EUID(1001), parent (bash:13778) UID(1001) EUID(1001)

Here's an example of Procmon doing exec logging (date cut away):

Code:

1001:22741:/bin/ls --color

1001:23616:/usr/bin/du

1001:16468:/usr/bin/df -h

3. In the case you suspect a LKM to be loaded you have two options:
- passive: check your ksyms log if your have recent modutils package (both examples: adore):

Code:

 __insmod_adore_O/var/tmp/ka/adore.o_M3FDDF647_V132117 [adore]

 __insmod_adore_S.text_L4944 [adore]

Note logging can easily be avoided if the cracker supplies her own insmod binary, kills, reroutes or denies logging or scrubs the logs.
- active: you could try running kern_check. If the result shows something like:

Code:

WARNING: (kernel) 0xe1b9d220 != 0xc01dc990 (map)  [sys_open]

WARNING: (kernel) 0xe1b9d1a8 != 0xc01dbf40 (map)  [sys_chdir]

WARNING: (kernel) 0xe1b9d094 != 0xc01ed590 (map)  [sys_getdents]

WARNING: (kernel) 0xe1b9d2a4 != 0xc01c38f0 (map)  [sys_getgid]

it's time to investigate. Note: not with kernels that deny reading /dev/kmem.
4. Run Chkrootkit.

This is not all, but at least you've got an basic idea I hope...