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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

You could likely bypass that by manually changing the sysctl setting in /proc. There are better ways to prevent modules from being loaded, including compiling all your modules into the kernel and then disabling dynamic loading of modules. Of course that requires a kernel recompilation and knowing what modules you'll need ahead of time. There are also a number of tools like carbonite that are usefull in defeating obfuscation with lkms.

That being said, suckit isn't an lkm rootkit. It works by writing to /dev/kmem. See the article "Linux on-the-fly kernel patching without LKM" in Phrack issue 58.

Originally posted by shubb Here's the html version of the powerpoint show.

They should stick to doing particle physics

If your system was hacked, I hope that you've done a format and re-installed the system from scratch. Technically you can remove suckit, however you don't know what else has been done to your system and the only way you can trust the system and be sure it's reasonably free of other backdoors, trojans, and viruses is to do a full re-install from trusted media

My question is, what is the effect that this does on the linux box?
The effect is that any and all tools that will *only* look for a path using this /proc entry will not find the binary. If /sbin is in the path they'll find it. Else they could piggy-back their module onto another one. Else they could introduce a custom modutils package.

Is this a recommended thing to do?
No, because of the above. If you take away the CAP_SYS_MODULE capability not even the root account user will be able to load modules. Look for 'lcap' (system-wide) or the GRSecurity kernel patch (more granular control over a cornucopia of things). I don't know if taking away capabilities is in the LSM framework.

Is this something that a hacker can undo once they are in the server?
Only if they're able to elevate their privileges to a point where they can do something useful.

That being said, suckit isn't an lkm rootkit. It works by writing to /dev/kmem.
Again the GRSecurity kernel patch will help by denying writing to /dev/kmem. Note this might break some applications on Desktops though.

do a full re-install from trusted media
I second that, and if you didn't disconnect the box from the 'net I would urge you to do so now. Before you re-install, have a quick look at possible means of entry (services *and* user accounts) and save your authentication databases and logfiles for later perusal. After you've re-installed please make sure you choose different passwords for all accounts and harden the box before you put it back on the 'net. Please check out the LQ FAQ: Security references for that.

Yes, I re-installed the OS onto a new hard drive (kept the old one for data recovery and research into the rootkit.)

Another question. While I was in the box after finding out it was compromised, I saw that my server was talking to an IP address in Austria (I'm guessing the hacker). It was just periodic packets (a couple a second) on a high up port numbers using tcp. It wasnt fast enough to be an ssh or telnet session, maybe just hello packets letting the server know it was still online. My question is, would you recommend trying to contact the ISP to tell them about the hacking of my server? Would they even try to do anything? Do they care that their people are hacking?

My question is, would you recommend trying to contact the ISP to tell them about the hacking of my server? Would they even try to do anything? Do they care that their people are hacking?
As a formality: yes, but don't expect anything. In any case the box could be just an intermediate.