Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
User Journal

Journal Henry V .009's Journal: Security suggestions

Security suggestions gleaned from the comments in this article:

  • recompile the kernel without suport for loadable modules
  • not having dev tools installed on your servers (quite often source root kits require them)
  • keeping copies of /bin and /usr/bin on some ro media (either a CD or on a seperate server mounted ro), and checking them ageinst you're working copies regularly.
  • running chkrootkit :-)
  • -Mount / ro. You need to set up seperate space for /tmp and /var (not to mention /home) but this will defeat 99% of the automated root kits, of course,
  • if the attacker gets in personnally, all bets are off...
  • Its fairly easy to put a module in Linux using /proc/kmem even if modules are disabled.
  • Run the services chrooted
  • Run pound in front of your web server / web services
  • Use a file integrity checker
  • if you're running BSD, set kern.securelevel to 1 or 2 [to prevent loading new modules]
  • Phrack guide to loading modules sneakily
  • ... tripwire ...

    Oh, and don't forget to mention that you should run tripwire from a known-secure system (a Knoppix CD, for instance) at least once in a while. Indeed, if your system is infested by a good rootkit, it could itself so well that it would play back a phony, made to look innocent contents of any files that it had infected.

    Same goes for lsmod, ps and other tools (it is however very rare that a rootkit is so thorough as to hide itself from all tools. Most often an rpm -q --verify -a finds the nasties). But if you're really paranoid, run your tripwire and rpm --verify from an external system, not from within the one you want to examine.


  • Shameless plug: I've written a script that should be able to help find any rootkits that are listening on tcp/udp on windows. Heres the link
  • RootkitRevealer is your friend.
  • I recently cleaned a machine infected with a rootkit that was NOT detected with Rootkit Revealer. The virus loaded itself via the HKLM/Soft/MS/Windows/Run key, as usual, but it didn't show on regedit nor elsewhere, and the Rootkit Revealer did not detect the "missing" key. The only way to see and remove it was to boot with a WinPE CD.
  • Oh, here's a useful tip for people.. there is a cheaper alternative to WinPE.. BartPE [], it requires Windows XP to build the bootable cd but in terms of usefulness it's a nice little life saver. Can also be extended with Ultimate Boot CD (UBCD) [].
  • re you sure it wasn't just hidden by the buffer issue thats known to exist in regedit.exe? zipzappromos does this, as well as a number of others. No rootkit, just an exploit in an OS flaw
  • Strider Ghostbuster, [], a Microsoft developed technique for detecting all persistant and stealthy rootkits .
  • And that's why you apply a few simple security measures, such as denying LocalSystem access to CMD.EXE and other powerful utilities via NTFS permissions. You can do this to bring LocalSystem down to a level lower than Administrator, and virtually nothing breaks if you do it with a little bit of forethought. Yes, it takes a little bit of work to do the initial planning, but once it's done you script it and bingo. And there are plenty of examples on websites of sample lockdowns plus the scripts (using XCACLS.EXE, typically). Take those examples and customize them to your environment as needed -- you've saved yourself a whole load of the initial work.

    You can open up these permissions on a system-by-system basis if really necessary, or even better just set applications that support it to use named service accounts. Cuts out a huge number of vulnerabilities.

    You can secure a Windows system, and it's really pretty easy to do a lot of these things. You just have to know a bit of what you're doing and be prepared to put in the work. That's the biggest flaw in most MS administration shops: people who shouldn't be admins get lulled into a false sense of security because there's a pretty GUI and they don't understand what's going on behind the scenes.


  • There's an easy answer: restrict what root can do []. Other things that generally will help include:

    Use a "default deny" policy for *everything*

    Use secure OSes (OpenBSD is probably a good choice if you can't or don't want to use SElinux)

    Keep up with patches

    Ensure that evidence can't (easily) be tampered with (for example, use a remote, dedicated host for syslogging)

    Monitor your logs efficiently; in particular, employ a filter that allows you to suppress messages that are just noise (security-wise, that is) but that shows every log line it does not recognise (there are also filters which will try to do the reverse, but that means you'll risk overlooking important messages)

    Use hardware protection when available (for example, some (?) SCSI disks can be write-protected with a jumper setting - turn it on for the disks you have your /boot and / partitions on; if yours can't, boot from CD)

    Try to actively detect anomalies (for example, use Snort, tripwire and similar tools)

    Perform penetration tests yourself

    Be paranoid - none of your systems should trust any of the other just because they *your* systems

    That's some general advice I can think of right now. None of it is specific to rootkits, of course, but if you do things right, then you most likely won't ever get bitten by something bad - and if you still do, you'll at least be able to keep the damage to a minimum and also find out afterwards just what led to the compromise in the first place.

Programmers used to batch environments may find it hard to live without giant listings; we would find it hard to use them. -- D.M. Ritchie