Team LiB
Previous Section Next Section

Module Objectives

In this module we will be looking at hacking Linux systems. Linux is fast emerging as an affordable yet available operating system. As the popularity is growing so is the attention of players with malicious intent to break in to the systems. Therefore we intent to discuss various aspects dealing with hacking the Linux systems in this module. BY the completion of this module, you will be familiar with the following aspects:

Linux is an operating system that can be downloaded free and "belongs" to an entire community of developers, not one corporate entity. With more and more people looking for an alternative to Windows, Linux has recently grown in popularity and is quickly becoming a favorite among major corporations and curious desktop users. Not only does it give users a choice of operating systems, it also proves itself valuable with its power, flexibility, and reliability.

Linux supports most of the major protocols, and quite a few of the minor ones. Support for Internet, Novell, Windows, and Appletalk networking have been part of the Linux kernel for some time now. With support for Simple Network Management Protocol and other services (such as Domain Name Service), Linux is also well suited to serving large networks. Since Linux was developed by a team of programmers over the Internet, its networking features were given high priority. Linux is capable of acting as client and/or server to any of the popular operating systems in use today, and is quite capable of being used to run Internet Service Providers.

Linux is an implementation of the UNIX design philosophy, which means that it is a multi-user system. This has numerous advantages, even for a system where only one or two people will be using it. Security, which is necessary for protection of sensitive information, is built into Linux at selectable levels. More importantly, the system is designed to multi-task. Whether one user is running several programs or several users are running one program, Linux is capable of managing the traffic.

Another huge advantage of an open system is a large number of software authors and beta testers. This makes the software testing and refinement process faster and better. Because there is not a lot of commercial software for Linux, most software written for Linux is written because the authors want to do it and there need be no compromise of quality.

Linux is "Free" in two senses. In one sense, the Linux consumer is free to modify the system and do anything he or she wishes with it. In another sense, acquiring Linux does not necessarily require any cash outlay at all.

There are two very popular methods for acquiring and distributing Linux: FTP and CD-ROM. Most of the major Linux distributions (Red Hat, Debian, Slackware, Caldera) are available for free download from several popular sites. Though time consuming, it does not cost anything beyond connection charges.

Linux is one of the more stable operating systems available today. This is due in large part to the fact that Linux was written by programmers who were writing for other programmers and not for the corporate system. There are currently two mature program packaging standards in the Linux world - SuSE and Mandrake. Debian and Red Hat each have their own packaging systems; both will check dependencies, both can upgrade an entire running system without a reboot. This makes it easy to upgrade parts or all of a system, as well as add new software, or remove unwanted software.

The fact that Linux is an open source operating system means that there are efforts going on continuously to improve the system. Therefore if a user is downloading a file (which is bound to happen more often than not) to add functionality to his system, he will have to compile the file on his system. The following is a brief look into how this process takes place. It helps to remember, that most Linux programs are beta at best and there can and will contain errors or bugs. However, the percentage of programs that compile without problems has increased significantly recently.


Usually the download is some sort of tarball on the user's disk. The first step towards compilation is to uncompress it and untar it to a directory. By convention, most users untar programs to the directory: /usr/src. This helps in maintaining version history and cleaning up after. The Linux tar program can uncompress and untar a file at the same time if the file is compressed using gzip. That means the user needs to just cd to the /usr/src directory and type:

  tar -xzvf / {path to file}/{filename.tar.gz} [Enter]

and it will uncompress and untar. A quick explanation of the flags:

For compiling, the user issues the "make" command. In order for "make" to start compiling, it must have a file named: Makefile.

There are three common ways to start the compile: simple, Imake, and configure.

Simple compile: If there is a file called Makefile - no Imake or configure files, this method is used to compile the file. This method of compiling has the most problems because nothing is configured to the computer.

make [Enter]
make install [Enter]

and if all goes well, the program can be run.

Imake: This is an older way to compile. If on listing the directory there is an Imake file and no Makefile, this method is used.

xmkmf [Enter]
make [Enter]
make install [Enter]

Configure: this method of compiling if there is a file named configure in the directory. This is the easiest way to compile and probably has the highest chance of compiling correctly. Essentially it checks the entire system for every possible library and support file to ensure that the file can compile the program, and then creates the Makefiles with the correct information. To compile, type:

./configure [Enter]
make [Enter]
make install [Enter]

The most common cause of not compiling is missing files. Almost all programs rely on support programs/files/libraries. If they are missing, the program cannot compile. The wrong version will kill just as much as not having it at all. The next most common problem is missing include files. Sometimes having multiple versions of the same library can cause problems as each version could put its header files in different places.


Scanning is the art of finding machines on a network and testing them to see what ports are listening. Scanning networks and hosts is the first method a cracker will use before launching an attack.


Two interesting tools on Linux are Fping and Nmap. Fping sends multiple ICMP request packets simultaneously and processes the reply as they occur. This makes ping sweeps faster. Fping can be fed with an ip address or can be given a list of ip address on a file.

Scanning helps one to know what services are running on a machine. This will show the open ports on which services are listening for connections. Once the targets are identified, an intruder is able to scan for listening ports.

Port scanning is the process of connecting to TCP and UDP ports on the target system to determine what services are running or in a listening state. Identifying listening ports is essential to determine the type of operating system and application in use on the system.

Types of port scanning:

  1. TCP connect scan: This type of scan connects to the target port and completes a full three-way handshake (SYN, SYN/ACK and ACK).

  2. TCP SYN scan: This is also called half-open scanning because it does not complete the three-way handshake, rather a SYN packet is sent and upon receiving a SYN/ACK packet it is determined that the target machines port is in a listening state and if an RST/ACK packet is received , it indicates that the port is not listening.

  3. TCP FIN scan: This technique sends a FIN packet to the target port and based on RFC 793 the target system should send back an RST for all closed ports.

  4. TCP Xmas Tree scan: This technique sends a FIN, URG and PUSH packet to the target port and based on RFC 793 the target system should send back an RST for all closed ports.

  5. TCP Null scan: This technique turns off all flags and based on RFC 793, the target system should send back an RST for all closed ports.

  6. TCP ACK scan: This technique is used to map out firewall rule sets. It can help determine if the firewall is a simple packet filter allowing only established connections or a stateful firewall performing advance packet filtering.

  7. TCP Windows scan: This type of scan can detect both filtered and non-filtered ports on some systems due to anomaly in the way TCP windows size is reported.

  8. TCP RPC scan: This technique is specific to UNIX systems and is used to detect and identify Remote Procedure Call (RPC) ports and their associated program and version number.

  9. UDP scan: This technique sends a UDP packet to the target port. If the target ports responds with an "ICMP port unreachable" message, the port is closed, if not then the port is open. This is a slow process since UDP is a connectionless protocol; the accuracy of this technique is dependent on many factors related to utilization of network and system resources.


Nmap is covered under the GNU General Public License (GPL) and can be downloaded free of charge from It comes as tarred source as well as RPM format. The usage syntax of Nmap is fairly simple. Options to nmap on the command-line are different types of scans that are specified with the -s flag. A ping scan, for example, is "-sP". Options are then specified, followed by the hosts or networks to be targeted. Nmap's functionality is greatly increased when run as root.

Nmap is flexible in specifying targets. The user can scan one host or scan entire networks by pointing Nmap to the network address with a "/mask" appended to it. Targeting "victim/24" will target the Class C network, whereas "victim/16" will target the Class B. Nmap also allows the user to specify networks with wild cards, as in 192.168.7.*, which is the same as, or,4,5-16 to scan the selected hosts on that subnet.

Users are able to sweep entire networks looking for targets with Nmap. This is usually done with a ping scan by using the "-sP" flag. A TCP "ping" will send an ACK to each machine on a target network. Machines that are alive on the network will respond with a TCP RST. To use the TCP "ping" option with a ping scan, the "-PT" flag is included to specific port on the target network.

Nmap has been covered in detail in module three and readers are advised to refer to that to learn more about the OS fingerprinting and other scan options.

The 'Nessus' Project was started in early 1998, and first released in April 1998. The "Nessus" Project provides to the internet community a free, powerful, up-to-date and easy to use remote security scanner. Nessus allows the user to audit remotely a given network and determine whether attackers may break into it, or misuse it in some way.


Nessus Security Scanner's architecture is a little different from the other scanners as it uses a client/server model. This allows a central server to do all the scanning while results are monitored and reviewed on distributed administrative clients. The scanning engine is Unix-based, while the administrative consoles can be run under Windows or Unix X Windows. Nessus Security Scanner supports command-line interaction as well. Not only is Nessus Security Scanner open source, but the architecture for creating vulnerability checks is quite open as well.

There is also a multi-platform client written in Java. All communication between client and server is encrypted. The current Nessus database contains signatures for, and is therefore able to detect hundreds of vulnerabilities in UNIX, Windows, and commonly-used web CGI scripts; additionally, the Nessus database detects DDoS zombies and Trojans. To scan hosts for vulnerabilities, install client and server, create a new server user, and connect. Problem reports generated by Nessus are easy to read and are exportable to other software.

Unlike many other security scanners, Nessus does not take anything for granted. That is, it will not consider that a given service is running on a fixed port. It will also not determine if security vulnerability is present by just regarding the version number of the remote service, but will really try to exploit it. Plugins are the core of Nessus because they contain a set of scripts to check vulnerabilities in a network, e.g., backdoors, DoS, wide-open ports, etc. These scripts are written in the language called NASL (Nessus Attack Scripting Language) and can be found in /usr/local/lib/nessus/plugin. The user can also develop their own scripts.


Cheops (KEE-ops) is a Network management tool for mapping and monitoring the network. It has host/network discovery functionality as well as OS detection of hosts.

Cheops is an Open Source Network User Interface. It is designed to be the network equivalent of a Swiss-army knife, unifying your network utilities. Cheops does for the network what a file manager does for the file system.

Cheops can optionally determine the OS of hosts on the network, selecting appropriate icons for them. Cheops can show the routes taken to access areas of the network. This feature is designed for larger networks, with routers, subnets, etc. This mapping not only makes hierarchy clearer, but can show unusual routing issues.

Cheops includes a generalized TCP port scanner to see what ports on the network are in use. It can be used to retrieve version information for certain services, to be sure any given host is up-to-date with the latest revision of its services.

Cheops includes a simple integrated SNMP browser, including write capability, using the UCD SNMP library. Cheops also supports a plug-in interface, which includes support for SNMP plug-ins, similar in concept to those of HP Openview.

Cheops can monitor critical servers, and immediately notify the concerned person through its event log, standard e-mail, and soon via paging, when things go wrong. The network administrator can know exactly which system is up or down, and just when problems occur. Right clicking on a host quickly shows a list of common services it supports, and rapid, easy access to them.


PortSentry is part of the Abacus Project suite of tools. The Abacus Project is an initiative to release low-maintenance, generic, and reliable host based intrusion detection software to the Internet community. More information can be obtained from

PortSentry has a number of options to detect port scans, when it finds one it can react in the following ways:

PortSentry has four "stealth" scan detection modes. Method one uses a pre-defined list of ports to watch over. If someone pokes at them it activates. The second method is what I call "inverse" port binding. Where every port under a range is watched *except* for those that the system has bound for network daemons when the PortSentry starts or ones that you have manually excluded. This is a very sensitive way for looking for port probes, but also the most prone to false alarms.

scanlogd is a TCP port scan detection tool, originally designed to illustrate various attacks an IDS developer has to deal with. Scanlogd detects port scans and writes one line per scan via the syslog (3) mechanism. If a source address sends multiple packets to different ports in a short time, the event will be logged. The format of the messages is:

Saddr [: sport] to daddr [and others,] ports port [, port...], flags [, TOS TOS] [, TTL TTL] @HH:MM:SS

The fields in square brackets are optional; sport, TOS, and TTL will only be displayed if they were constant during the scan. The flags field represents TCP control bits seen in packets coming to the system from the address of the scan. It is a combination of eight characters, with each corresponding to one of the six defined and two reserved TCP control bits. Control bits that were always set are encoded with an uppercase letter, and a lowercase letter is used if the bit was always clear. A question mark is used to indicate bits that changed from packet to packet.

Scanlogd needs a way to obtain raw IP packets that either come to the system scanlogd is running on, or travel across a network segment that is directly connected to the system. Current versions of scanlogd can be built with support for one of several packet capture interfaces. As of version 2.0, scanlogd is aware of the raw socket interface on Linux, libnids, and libpcap. The use of libpcap alone is discouraged.


Xcrack (

Xcrack is a simple dictionary based password cracking tool. It will find any passwords that match words in the dictionary file the user provide. It does not generate permutation combination of the words provided in the dictionary to arrive at the right password. For this reason, it is a comparatively faster tool, though efficacy might be less.


John the Ripper is a password cracker, available for many flavors of UNIX (11 are officially supported, not counting different architectures), DOS, Win32, BeOS, and OpenVMS. Its primary purpose is to detect weak passwords. Besides several crypt password hash types most commonly found on various UNIX flavors, supported out of the box are Kerberos AFS and Windows NT/2000/XP LM hashes, plus several more with contributed patches.

John the Ripper is a part of Owl, Debian GNU/Linux, SuSE, very recent versions of Mandrake Linux, and EnGarde Linux. It is in the ports/packages collections of FreeBSD, NetBSD, and OpenBSD.


SARA (Security Auditor's Research Assistant), a derivative of the Security Administrator Tool for Analyzing Networks (SATAN), remotely probes systems via the network and stores its findings in a database. The results can be viewed with any Level 2 HTML browser that supports the http protocol.

When no primary_target(s) are specified on the command line, SARA starts up in interactive mode and takes commands from the HTML user interface.

When primary_target(s) are specified on the command line, SARA collects data from the named hosts, and, possibly, from hosts that it discovers while probing a primary host. A primary target can be a host name, a host address, or a network number. In the latter case, SARA collects data from each host in the named network.

SARA can generate reports of hosts by type, service, and vulnerability by trust relationship. In addition, it offers tutorials that explain the nature of vulnerabilities and how they can be eliminated.

By default, the behavior of SARA is controlled by a configuration file (config/ The defaults can be overruled via command-line options or via buttons etc. in the HTML user interface.


Sniffit runs on LINUX, SunOS, Solaris, FreeBSD and IRIX. The main reason to use sniffit vs. other packet sniffers is the way that is captures the data transferred within sessions. This could be useful, for example, when capturing text-based protocols like HTTP, FTP, and SMTP.

Sniffit can be run either on the command line with optional plug-ins and filters or in interactive mode, which is the preferred mode. The interactive mode of Sniffit allows monitoring connections in real-time.

Sniffers can only be run by root. Sniffers can only log packets that 'travel' on their Ethernet cable. Working with '-d' or '-a' give raw packets, they are still packed in IP, when logging to files, only send data is logged, the packets are 'unwrapped'.


hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface expands the functionality of a common "ping" program (used to test hosts that are online), but hping isn't only able to send ICMP echo requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel with custom-crafted TCP, ICMP and other Internet protocol packets. Crafting packets will allow an attacker to probe firewall rule-sets and find entry points into the targeted system or network. HPing will run on any Linux distro, as well as Net/Free/OpenBSD systems, and lastly it will run on Solaris as well. It is used to test both hosts and firewalls. hping2 can handle fragmentation, arbitrary packets body and size and can be used in order to transfer files encapsulated under supported protocols. Using hping2 the user can:

  • Test firewall rules

  • Advanced port scanning

  • Test net performance using different protocols,

  • Packet size, TOS (type of service) and fragmentation.

  • Path MTU discovery

  • Transferring files between even really fascist firewall rules.

  • Traceroute-like under different protocols.

  • Firewalk-like usage.

  • Remote OS fingerprinting.

  • TCP/IP stack auditing.


Many systems have statistical weaknesses in the methods that are used to generate TCP/IP initial sequence numbers, possibly allowing an attacker to hijack or close TCP/IP sessions. Using a combination of sniffing and spoofing techniques, session hijacking tools allow an attacker to steal a valid, established login session. Examples of such sessions are Telnet and FTP sessions. With a successful session hijacking attempt, the victim's login session vanishes and he usually attributes it to network problems and logs in again.

If attackers know the TCP/IP initial sequence number and the amount of traffic that has been sent, they may be able to close the TCP/IP session, hijack it, or inject arbitrary data. In this type of attack, it is not necessary for the attacker to know the next sequence number. They can send a flood of packets that contain likely sequence numbers so that the one packet containing the correct number will be accepted. If the set of possible sequence numbers is small enough, it becomes practical for an attacker to send packets set with all possible sequence numbers. The larger the available bandwidth of a system, the larger the set of packets can be.

To protect against these types of attacks, many operating systems use pseudo-random number generators to choose the TCP/IP initial sequence number for the TCP/IP session. However, many of these pseudo-random number generators are statistically weak and make sequence number-based attacks not just possible, but practical.

Host-Based Session Hijacking requires the attacker to have root on either source/destination machines. On a Linux system, the attacker uses a tool to interact with local terminal devices/ttys that are used in telnet sessions. If the attacker has root, he will then be able to read all session data from the target's tty and places key strokes into the tty. This is rarely used, as it requires the attacker to obtain root access on either machines.

This session-hijacking technique uses a sniffing technique on a segment of the network carrying traffic passing from the source to the destination to monitor the packets and the TCP sequence numbers. When the attacker decides to hijack a session, the attacker inserts traffic into the network with the source IP of the actual source instead of his own IP, placing the correct TCP sequence numbers on the packets.

This prompts the destination machine to think that the traffic came from legitimate source and follows the commands. And the attacker has hijacked the session. Note: Use of strong authentication cannot protect against successful Session hijackings; whereas encrypting the conversation offers some protection.

Session hijacking has been described in detail in the earlier modules. While the essence is the same, we will explore the various tools available to an attacker to do this in a Linux environment. Readers are advised to refresh the contextual information from the previous modules.


A sniffer is a program/device that eavesdrops on network traffic and grabs information traveling over the network. Sniffers are basically data interception programs. A sniffer is usually passive, it only collects data. Hence, it becomes extremely difficult to detect sniffers. When installed on a computer, a sniffer will generate some small amount of traffic, though, and is therefore detectable. The best way to secure against sniffing is to use encryption. According to Pavel Krauz, the main goal of the HUNT project is to develop tools for exploiting well-known weaknesses in the TCP/IP protocol suite.

Hunt is considered by security professionals to be one of the best session hijacking tools available as it is well written and has a comprehensive feature set. Hunt does not have the graphical interface of similar tools such as IPWatcher and T-sight, but the text based user interface is fairly easy to use and has the benefit of enabling Hunt to be used over a telnet session.

Hunt was developed by Pavel Krauz. Hunt's hijacking capabilities are primarily aimed at telnet and rlogin traffic and enable an attacker to view active sessions on an Ethernet LAN and then select one of them to hijack. Hunt is a program for intruding into a connection, watching it and resetting it. Note that hunt is operating on Ethernet and is best used for connections which can be watched through it. However, it is possible to do something even for hosts on another segment or hosts that are on switched ports.

ARP spoofing with Hunt

ARP enables systems to map IP addresses to the machine's physical addresses. ARP maps IP addresses to MAC addresses for systems connected to Ethernet LANs. Consider an illustrative scenario where Alice wants to send data to Bob.

Normally, if the ARP program on Alice finds a mapping for Bob's IP address in the ARP cache, it will allow Alice to address the data with Bob's MAC address and send it to him. Otherwise, the ARP program on Alice will send out an ARP request to all machines on the Ethernet segment. When Bob answers, Alice will send her data to Bob and will store Bob's MAC address in her ARP cache.

Sometimes it is possible for a machine to send out an ARP reply without an explicit ARP request. Usually, most systems accept this forged answer and update their ARP cache to accommodate it. This weakness allows ARP spoofing to take place.

We revisit rootkits here basing our discussion on Linux rootkits. Conventionally, UNIX and Linux have been known to have rootkits built, as the intruder is aware of the code. Here we will focus on rootkits that use the LKM or Loadable Kernel Module.

A brief review: Rootkits appeared in the early 90's, and one of the first advisories came out in Feb 1994. This advisory from CERT-CC addressed "Ongoing Network Monitoring Attacks" CA-1994-01 revised on September 19, 1997. Rootkits have increased in popularity since then and are getting increasingly difficult to detect. The most common rootkits are used for SunOS and Linux operating systems. Rootkits contain several different programs. A typical rootkit will include an Ethernet Sniffer, which is designed to sniff out passwords. Rootkits can also include Trojan programs used as backdoors such as inetd or login. Support programs such as ps, netstat, rshd, and ls to hide the attacker directories or processes. Finally, log cleaners, such as zap, zap2, or z2, are used to remove login entries from the wtmp, utmp, and lastlog files. Some rootkits also enable services such as telnet, shell, and finger. The rootkit may also include scripts that will clean up other files in the /var/log and var/adm directories. Using the modified programs of ls, ps, and df installed on the box, the intruder can "hide" his/her files and programs from the legitimate system administrator.

The intruder next uses programs within the rootkit to clean up the extensive log files generated from the initial vulnerability exploitation. The intruder then uses the installed backdoor program for future access to the compromised system in order to retrieve sniffer logs or launch another attack. If a rootkit is properly installed and the log-files are cleaned correctly, a normal system administrator is unaware that the intrusion has even occurred until another site contacts him or the disks fill because of the sniffer logs.

The most severe threat to system security that can be caused by a rootkit comes from those that deploy LKM (Loadable Kernel Module) trojans. Loadable Kernel Modules are a mechanism for adding functionality to an operating-system kernel without requiring a kernel recompilation. Even if an infected system is rebooted, the LKM process will reload the Trojan during boot-up just like any other kernel module. Loadable Kernel Modules are used by many operating systems including Linux, Solaris, and FreeBSD.

The LKM rootkits facilitate the subversion of system binaries. Knark, Adore, and Rtkit are just a few of many LKM rootkits available today. As they run as part of the kernel, these rootkits are less detectable than conventional ones.

Let us see how a typical backdoor can be installed by an intruder.

The goal of backdoor is to give access to the hacker despite measures by the compromised system's administrator, with least amount of time and visibility. The backdoor that gives local user root access can be: set uid programs, trojaned system programs, cron job backdoor.

Set uid programs. The attacker may plant some set uid shell program in the file system, which when executed will grant the root to the attacker.

Trojaned system programs. The attacker can alter some system programs, such as "login" that will give him root access.

Cron job backdoor. The attacker may add or modify the jobs of the cron while his program is running so that he can get root access.

The backdoor that gives remote user root access can be: ".rhost" file ssh authorized keys, bind shell, trojaned service.

After the intruder plants and runs the backdoor, his attention turns to hiding his files and processes. However, these can be easily detected by the system administrator - especially if the system is running tripwire.

Let us see how a LKM rootkit helps achieve the attacker's needs.

In the case of LKM trojaned rootkits, the attacker can put LKM in /tmp or /var/tmp, the directory that the system administrator cannot monitor. Moreover, he can effectively hide files, processes, and network connections. Since he can modify the kernel structures, he can replace the original system calls with his own version.


Linux Rootkit IV (lrk4) is written by Lord Somer and was released in November 1998. Other examples of Linux rootkits are lrk, lnrk, lrk2, and lrk3. Most versions include normal rootkit components such as sniffers (linsniffer or sniffit) log editors/erasers (z2, uted, lled), and Trojan horse/backdoor replacement programs to allow remote access, user access to gain root privileges, hide files, process, and connections.

Linux Rootkit IV is a very easy rootkit to use, and install. Installation of lrk4 included nothing more that executing the 'make install'. To install a shadow kit you execute the 'make shadow install'. Lrk4 will only work on Linux 2.X kernels. It is a package with sources to several trojaned system commands. When compiled and installed, they give the user running the command a root shell or some other useful functionality, like hiding certain processes, files, sockets etc. Some of special functionalities are initiated by given a secret password (default password in the package is 'satori') when the program asks for any specific thing, such as new shell, login name, password or whatever is specific to the command.

The user will need root-privileges to install most of those commands, since he will have to replace existing system files and usually set 'suid'-parameter for it. Therefore the attacker has to either root-compromise the victim computer or the local administrator has to accidentally install them. The rootkit comes with following utility programs and trojaned system commands: bindshell, chfn, chsh, crontab, du, find, fix, ifconfig, inetd, killall, linsniffer, login, ls, netstat, passwd, pidof, ps, rshd, sniffchk, syslogd, tcpd, top, wted, z2

Below is a short description of the utilities within lrk4.

  1. - Modified programs that hide the intruder:

    • ls, find, du - these programs will not count or display the intruder files the data file is ROOTKIT_FILES_FILE, defaults to /dev/ptyr. NOTE: all files can be listed with the 'ls-/' if SHOWFLAG is enables. Will hide any files/directories with the names, ptyr, hack.dir, and W4r3z.

    • ps, top, pidof - these programs will not display the intruders processes

    • netstat -- will not display traffic from or to specified IP addresses, user-ids, or ports

    • killall - will not kill the intruders hidden processes

    • ifconfig - will not display the PROMISC flag when sniffer is running

    • crontab - will hide the crackers entries - the hidden crontab entry is in the /dev/hda02 by default

    • tcpd - will not log connections listed in the configuration file

    • syslogd -- will not log connections listed in the configuration file

  2. - Trojaned programs with backdoors:

    • chfn - new full name enter password will drop rootshell

    • chsh - new shell enter password will drop rootshell

    • passwd - rootshell if is entered as current password

    • login - will allow the cracker to log in under any username with the rootkit password (satori)-also if root is refused username (rewt) will work and will disable the history logging

  3. - Trojaned network daemons:

    • inetd - rootshell listening on port 5002. the rootkit password most be entered in as the first line (satori)

    • rshd - the username is the rootkit password, a root shell is bound to the port [ rsh (hostname) -l (rootkit password) ]

  4. - Utilities:

    • FIX - replaces and fixes timestamp/checksum information on files

    • linsniffer - a packet sniffer

    • sniffchk - checks to make sure the sniffer alive

    • wted - wtmp/utmp editor

    • z2 - erases entries in the wtmp/utmp/lastlog entries for a username -will only null the entry

    • bindshell - binds a rootshell to a port (31337) by default

The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on the Security-enhanced Linux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.

Attack Methods 

The typical Rootkit attack proceeds as follows: The intruders use a stolen or easily guessed password to log in to a host. They then gain unauthorized root access by exploiting known vulnerabilities in rdist, sendmail, /bin/mail, loadmodule, rpc.ypupdated, lpr, or passwd. The intruders ftp Rootkit to the host, unpack, compile, and install it; then they collect more username/password pairs and attack more hosts.

Unless the intruder did a poor job of removing traces of his or her visit from the log files, attacks can be hard to detect. Most system administrators don't know their site has been invaded until they are contacted by someone at another site or their disks begin filling up due to the sniffer's logs. Some of the countermeasures apart from encryption are:

chkrootkit is a tool to locally check for signs of a rootkit. It contains:

Tripwire is a system integrity check tool that does not just look for "attack signatures". Tripwire first creates a database that monitors the binary signature, size, expected change of size, etc. Tripwire includes four cryptographic checksums of the content of each file that Tripwire uses to create the original database. When the software performs a system check, it will compare the system with the baseline of original database. If a modification has occurred Tripwire will alert the System Manager Station by a violation alert and the System Administrator by an email, the violation alert will show what files/directories were modified, added, or deleted.

Bastille Linux is a series of scripts which tighten up security on stock Linux systems, by changing permissions and disabling features. Taken to extreme, this will also prevent legitimate work and is more suitable for hardening a dedicated loghost or fileserver than a development system.

LIDS - Linux Intrusion Detection System - is a series of kernel patches that enable module and mountpoint locking. LIDS are available from

dtk or "Deception Toolkit" is a kit of fake daemons and services designed to waste an intruder's time. dtk is available from

Rkdet is a daemon intended to catch someone installing a rootkit or running a packet sniffer. It is designed to run continually with a small footprint under an innocuous name. When triggered, it sends email, appends to a logfile, and disables networking or halts the system.

Secure Linux project: The NSA has a Secure Linux project which includes mandatory access control architecture. The Security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. When confined in this way, the ability of these user programs and system daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example) is reduced or eliminated. This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).

The following rootkits, worms and LKMs are currently detected:

01. lrks, lrk3, lrk4, lrk5, lrk6 (and variants);

02. Solaris rootkit;

03. FreeBSD rootkit;

04. torn (and variants);

05. Ambient's Rootkit (ARK);

06. Ramen Worm;

07. rh[67]-shaper;

08. RSHA;

09. Romanian rootkit;

10. RK17;

11. Lion Worm;

12. Adore Worm;

13. LPD Worm;

14. kenny-rk;

15. Adore LKM;

16. ShitC Worm;

17. Omega Worm;

18. Wormkit Worm;

19. Maniac-RK;

20. dsc-rootkit;

21. Ducoci rootkit;

22. x.c Worm;

23. RST.b trojan;

24. duarawkz;

25. knark LKM;

26. Monkit;

27. Hidrootkit;

28. Bobkit;

29. Pizdakit;

30. torn v8.0;

31. Showtee;

32. Optickit;

33. T.R.K;

34. MithRa's Rootkit;

35. George;

36. SucKIT;

37. Scalper;

38. Slapper A, B, C and D;

39. OpenBSD rk v1;

40. Illogic rootkit;

41. SK rootkit.

42. sebek LKM;

43. Romanian rootkit;

44. LOC rootkit;

45. shv4 rootkit;

46. Aquatica rootkit;

47. ZK rootkit;

48. 55808.A Worm;

49. TC2 Worm;

50. Volc rootkit;

51. Gold2 rootkit;

52. Anonoying rootkit;


Linux IP firewall chaining software is a program that uses the kernel IP packet filtering capability. A packet filter looks at the header of a packet and decides the fate of the entire packet. It can decide to DENY the packet (discard the packet as if it had never received it), ACCEPT (let the packet pass through), or REJECT (like deny, but notify the source of the packet).

ipchains is a rewrite of the well-known ipfwadm, which was a rewrite of BSD's ipfw, and was used to build firewalls in 2.0.x kernels. There are many reasons for this rewrite but perhaps the most important is ipfwadm couldn't allow protocols other than TCP, UDP or ICMP and it didn't handle fragments.


# ipchains -A input -j DENY -p all -l -s -i etho -d

This rule prevents packets that have addresses beginning with 127. from entering the machine. The reason for this is that any IP address starting with 127. is a loopback address, and only used internally. That means that any packet coming into the ppp or ethernet device matching this rule is spoofed.

In the above example, input refers to the chain. There are three built-in chains: input, output and forward. The input chain refers to packets that are coming into the machine. These packets can be coming from a variety of sources. The output chain refers to packets that are leaving the machine. Again, these packets can be leaving through any interface which connects the computer to any network. The forward chain refers to packets that are received that are not destined for the machine. These packets are being routed through the machine. Note that each packet that passes through the forward chain also passes through both the input and output chains.

To simplify aspects of datagram processing in the kernel firewalling code and produce a filtering framework that was both much cleaner and much more flexible, Paul Russell made a new framework called netfilter.

The iptables utility is used to configure netfilter filtering rules. Its syntax borrows heavily from the ipchains command, but differs in one very significant respect: it is extensible. What this means is that its functionality can be extended without recompiling it. It manages this trick by using shared libraries.

The iptables command is used to configure both IP filtering and Network Address Translation. To facilitate this, there are two tables of rules called filter and nat. The filter table is assumed if you do not specify the -t option to override it. Five built-in chains are also provided. The INPUT and FORWARD chains are available for the filter table, the PREROUTING and POSTROUTING chains are available for the nat table, and the OUTPUT chain is available for both tables.

All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. This implies that iptables does all recalculation of states within the PREROUTING chain. If an initial packet is sent in a stream, the state gets set to NEW within the OUTPUT chain, and when the system receives a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED. If the first packet is not originated by the local machine, the NEW state is set within the PREROUTING chain. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

Syntax: iptables [-t table] command [match] [target/jump]

In IPTables, there are four types of ICMP that can be categorized as NEW or ESTABLISHED:

The requests in each case are classified as NEW and reply as ESTABLISHED.

Other types of ICMP are not request-reply based and can only be related to other connections.



  • Physical Security

    • It is ideal to restrict physical access the computer system so that unauthorized people don't get to misuse the system.

  • Password Security

    • Assign hard to guess passwords which are long enough.

    • Ensure procedural discipline so that passwords are kept private

    • Ensure that system does not accept null password or other defaults

  • Network Security

    • Ensure all default network accesses are denied

      $ cat: ALL: ALL" >> /etc/hosts.deny

    • Ensure that only essential services are running. Stop unused services like sendmail, NFS etc

      $ chkconfig --list

      $ chkconfig --del sendmail

      $ chkconfig --del nfslock

      $ chkconfig --del rpc

    • Verify system logs at regular intervals to check for suspicious activity - (System logs in /var/log/secure)

  • Patch the Linux system and keep it up to date

    • Check for bug fixes at the vendor site

    • Update packages as and when available at the Update site of the vendor.

Team LiB
Previous Section Next Section