KTRAQ IDS Release for Linux | Security Audit
Ktraq IDS is my latest security invention, and I feel it is the cleanest solution to date, for absolving systemcall hijacking.
Ktraq is by far, the most reliable and efficient way to detect, and disable kernel rootkits in Linux. As mentioned in the detailed
introduction and example presented here: http://www.bitlackeys.com/projects/ktraq
ktraq is still in an early faze of development, but is nonetheless perfectly sufficient to seize and disable any kernel rootkit, whether it be installed as an invisible LKM, or just manipulates the system call table by accessing memory through /dev/kmem. Although detecting and removing the kernel rootkit is the ultimate goal, it is still desirable to see exactly what files, and processes the kernel rootkit was hiding, and though now visible, may still be affecting the system in a less dramatic way. I have developed a procedure in which, as the developer of ktraq, I feel is a unique and auspicious method of performing a transparent security audit on the kernel, the processes, and the filesystem; using ktraq as the primary tool. I have decided that for a time I will offer my services, for a price of course, and companies within the greater seattle area, if interested may contact me with questions, or to schedule a time for an audit (sometime during the weekend, as I do have a day job). Please contact me by email here ryan@bitlackeys.com
The following is the definition of a Kernel rootkit from wikipedia:
Kernel level rootkits add additional code and/or replace portions of an operating system, including both the kernel and associated device drivers. Most operating systems don't enforce any security distinctions between the kernel and device drivers. As such, many
kernel mode rootkits are developed as device drivers or loadable modules, such as Loadable Kernel Modules in Linux or device drivers in Microsoft Windows. This class of rootkit is perceived as dangerous simply because of the unrestricted security access the code has obtained, regardless of the features the rootkit may employ. Any code operating at the kernel level may have serious impacts on entire system stability if mistakes are present in the code. The first and original rootkits did not operate at the kernel level, but were simple replacements of standard programs at the user level. Although traditionally security advances were made first on Unix systems, the first kernel rootkit was developed for Windows NT 4.0 and released in the mid-1990's by Greg Hoglund.
Kernel rootkits can be especially dangerous because they can be difficult to detect. The reason they can be difficult to detect is
because they operate at the same level as the operating system, thus they can modify or subvert any request made by software on the running system. In a situation such as this, the system itself cannot be trusted. An accepted proper response in such a case is to perform system analysis offline using a second 'trusted' system and mounting the hard drive of the infected system as a resource.
Ryan O'Neill
