Bảo mật hệ thống mạng part 54 pdf

Recommended Use Scenario 2 is recommended for use with the team together in a conference room talking through the issues.. Scenario Closeout Allow the team to work through their procedur

Trang 1

Initial Indications

The organization’s Help Desk is getting calls about slow response from the Internet At about the same time, system administrators notice that the Web/FTP server is showing high disk utilization and little free space No alarms have been set off that might indicate the system has been hacked or that the organization might be under some type of denial-of-service attack

What Really Happened

Someone made a mistake on the FTP server configuration This mistake left a writable directory where anonymous FTP users can access it Someone noticed and placed a large amount of illegal copies of software on the system in a hidden directory The sys-tem is now being accessed from around the world and copies of the software are being downloaded

What the Team Will Find

Firewall logs show no attacks or unusual amounts of dropped traffic If complete logging

is enabled on the firewall, it will show a large amount of FTP traffic to the FTP server The logs on the FTP server are showing a lot of requests for files All requests are for files in the ~ftproot/… directory (note that there is a space after the third dot)

If a directory listing is performed before the log file is checked, make sure the admin-istrator requests an ls –a listing to show the file If the adminadmin-istrator tries to look into the file, he must make sure he changes to the correct directory (three dots and a space) Inside the directory, the administrators will find approximately five gigabytes of soft-ware including illegal copies of Windows softsoft-ware

The permissions on the FTP directory structure are wrong as they allow an anony-mous user to write files to the system

Scenario Closeout

Once the directory has been found, allow the scenario to end after the administrators look for how this came about Make sure they perform an ls –l on the directory to show the permissions

Recommended Use

Scenario 2 is recommended for use with the team together in a conference room talking through the issues Provide the initial indications to them and set the stage for the event

As the team tells you what actions they take, give them the results of these actions

SCENARIO 3—FILES MODIFIED BY UNKNOWN PERSON

This scenario can be kicked off by a file integrity checker or by an administrator noticing that files have been changed when they should not have been The issue here is that the change was caused by an employee not following proper procedure, not a hacker

Trang 2

Appendix D: Incident Response Procedure Testing Scenarios 367

The initial alarm can be raised by a file integrity checker that detects a change to binary

files on a server If the organization is not using such a device, the administrator of the

system might notice that certain files have changed when they should not have

In reality, this is not an attack at all but a developer moved new binaries to the system

without following proper change control procedure This meant that the file integrity

checker and the system administrator were not notified of the change

Examination of the system will not find any indications of an attack Logs will show that

the last login (before the administrator) was a developer The logs will not show what

ac-tions the developer performed on the system If the administrator looks in the

devel-oper’s history file (on a Unix system), the actions of the developer can be seen

Allow the team to work through their procedures to determine if there really was an

at-tack against the system If the team identifies the possibility of an unauthorized

configu-ration change, you can end the scenario there If the team gets hung up on the lack of

hacker evidence, you should end the scenario before the team gets too far down the rat

hole of looking for an attacker

Recommended Use

Scenario 3 can be used with the team together in a conference room or you could have

someone make a change to a file on a system This works best if your organization is using

an automatic file integrity checker If you do this around a conference table, provide the

initial indications to the team and set the stage for the event As the team tells you what

actions they take, give them the results of these actions

SCENARIO 4—UNAUTHORIZED SERVICE FOUND

ON A SYSTEM

Organizations should perform regular service and vulnerability scans of their internal

systems This scenario takes advantage of these regular scans by introducing an

unautho-rized service on an internal system There are several ways this scenario can be played

out: the service could be a simple Web server on a high-numbered port, or you could

make the service malicious, such as a Back Orifice server or a distributed

denial-of-service controller

Trang 3

The initial indication of the event is the fact that a service scan identifies a new service running on an internal system

Depending on the variation you choose, the service could be a user who wants to run his own Web server or it could be a malicious program on a system The third alternative is for a system administrator to have installed a new Web-enabled tool on the system

A scan of the system identifies the service running Looking at the processes on the sys-tem may or may not show which process is using the port If the syssys-tem is a Unix syssys-tem and lsof is used, the team will identify the process and can then trace it back to a user

Close out the scenario when the team identifies what the new service is and why it is in place on the system

Variations

The variations below present different options for why the new service was started Other variations can be constructed to make this scenario more appropriate for your environment

Variation A

A user starts a Web server for his own use on the system It is started from his cron file and thus will restart if it is stopped by the administrator It is listening on port 8080

Variation B

Either accidentally or on purpose, a user has loaded a back door program on the system The program could be something like Back Orifice on a Windows system or it could be a distributed denial-of-service tool like Trinoo or TFN2K on a Unix system

Variation C

A system administrator loads a new software tool that is Web-enabled and starts its own Web server on the system

Recommended Use

Scenario 4 is recommended for live systems The port can be opened on the system and found by a security scan or regular administrative checking This is a good scenario for an unannounced test

Trang 4

SCENARIO 5—SYSTEM LOG FILE MISSING

An administrator looking at a system notices a log file is missing This scenario assumes

that log files on Unix systems are rotated on a daily basis so it is very obvious that an

en-tire log file is missing

The administrator of the system was examining the log files on the system and noticed

that the messages file from the previous day was missing All other log files appeared to

be in the right location

The system in question was hacked The attacker came through a buffer overflow in an

RPC program and loaded a sniffer The log file was deleted to cover evidence of the attack

Examination of the system will find a hidden directory under /usr/man/man4 called

.hack The directory contains a sniffer that is started by a cron job under root The sniffer is

running as a process called update

If this is a Solaris system, the team cannot see the sniffer by using ifconfig, they must

load ifstatus first (see Chapter 15 for details on this) Running ps will show update

run-ning out of /usr/man/man4/.hack, which should tip off the team

It will be impossible to identify what vulnerability was used to enter the system

Guesses could be made based upon vulnerabilities on the system, but conclusive proof

was removed with the logs

Close out the scenario when the team finds the sniffer and determines where the file is on

the system You could also allow the team to work through the clean-up procedure

Recommended Use

Scenario 5 is recommended for use with the team together in a conference room talking

through the issues Provide the initial indications to them and set the stage for the event

Alternatively, you could use this as a real scenario but you will have to have a system

on which you can load the sniffer

SCENARIO 6—THE NETWORK IS SLOW

Calls are coming into the Help Desk complaining about slow network response on the

in-ternal network In reality, a system has been configured with the same IP address as one

of the routers

Trang 5

370 Network Security: A Beginner’s Guide

The calls to the Help Desk say it all—the network is running slow There is no obvious sign that a security event has occurred, but the network staff is not sure what the problem is

Someone configured a system with the same IP address as a network router Since all sys-tems on the subnet are using the router as the gateway off the subnet, traffic is very slow The misconfigured system is also responding to all packets to the router’s IP address but not routing traffic

None of the systems on the network will show any signs of an attack However, the net-work is very slow

If a sniffer is placed on the wire it will show the traffic problem The team will have to look specifically for duplicate arp responses to identify the problem Keep in mind that some sniffers will show duplicate IP addresses

Once the problem is identified, the team will have to find the misconfigured system

At this point, only the MAC address of the system will be known

Close out the scenario when the team learns of the duplicate IP address Alternatively, you could continue until the team figures out how to find the misconfigured system

Recommended Use

Scenario 6 is recommended for use with the team together in a conference room talking through the issues (unless you wish to cause problems on your network) Provide the ini-tial indications to them and set the stage for the event As the team tells you what actions they take, give them the results of these actions

SCENARIO 7—INTERNAL ROUTER ATTACK

An internal router comes under a password-guessing attack The attack is picked up by internal systems configured to alarm on multiple failed login attempts

If a mechanism exists to detect failed login attempts on internal routers, the system will pick up the attack and alarm The source of the attack is an internal system

An internal employee is attempting to guess the password on an internal router To do this, he has created a script that guesses various passwords on a continuous basis

Team-Fly®

Trang 6

The source address of the attack is an internal system The system could be a shared

server or a desktop system

On the system, the team finds a script running that is attempting various password

combinations against the router

NOTE: If the system is a shared system, the team will need to identify the correct process Lsof will

be needed if the system is a Unix system

Close out the scenario when the team identifies the script that is being used for the attack

Recommended Use

Scenario 7 is a good scenario for a real-world test The script can be written using perl and

expect Have the script run from a user’s account on an internal system and target one or

more internal routers Make sure that the network administrators will notice the failed

login attempts before running the test

SCENARIO 8—VIRUS ATTACK

Many employees in the organization receive Melissa- or ILOVEYOU-type e-mail viruses

The virus is activated and spreads throughout the organization

Initial indications are very slow e-mail responses and heavy loads on the e-mail servers

Some users may call the Help Desk and ask about problems Later, the number of Help

Desk calls increases as more and more employees see strange e-mails in their inboxes

Several employees received the e-mail and opened the attachments The virus was new

enough to not trigger the anti-virus software on the systems The message was then sent

to every employee in the organization The organization is now fully infected

The team will find the virus script and they can create a script to get rid of the virus or

they can create a manual procedure

This scenario is designed to work the team through a simple but large-scale incident in

the organization Once the team defines their approach to fixing almost all the desktop

systems and removing the e-mail from the e-mail servers, the scenario should end

Trang 7

Recommended Use

Scenario 8 is recommended for use with the team together in a conference room talking through the issues Provide the initial indications to them and set the stage for the event

SCENARIO 9—THE IDS REPORTS AN ATTACK

The organization has deployed a network-based IDS The IDS reports an attack against one of the organization’s systems

The IDS shows an alarm This alarm can be shown on the screen or the notification can be sent to the security team depending on how the organization has the system configured

An attack was launched against a system The system was not vulnerable so the attacker did not gain access to the system

An examination of the system will show that the attack was not successful The IDS cor-rectly reports the attack and the source (external to the organization)

Close out the scenario when the team determines that the attack was not successful

Variation

Launch an attack against the system that is successful Have the team investigate the at-tack and identify the fact that it succeeded and what the atat-tacker did to the system

Recommended Use

Scenario 9 is recommended for use either with the team together in a conference room or

as a real test of the Incident Response Procedure

SCENARIO 10—EXTORTION

A high-level executive of your organization receives a demand for money The demand states that if the money is not paid, the thief will either disclose sensitive information or bring down sensitive systems of the organization

Trang 8

The only indicator that the organization receives is the demand sent to the executive

There are no other indications

In this case, the extortion is a hoax No systems were penetrated

Any systems that are searched will reveal no sign of penetration or signs of a back door

that might allow the intruder to gain access to the systems

This scenario is designed to force the team to create a procedure to examine each system

and to provide a concise recommendation to the senior management of the organization

When the team has defined a course of action, the scenario can end

Variations

According to the latest information from the FBI, this scenario has really occurred at a

number of organizations As such, this scenario may prove to be somewhat realistic The

variations below will put additional pressure on the team Time limits (like that proposed

in Variation A) should not give the team sufficient time to do everything they have to do

Variation A

For added pressure on the team, give the extortion demand a time limit Have the team

work through the exercise with that time limit in mind

Variation B

Get the cooperation of one of the executives of the organization and have him deliver the

news of the demand to the team

Recommended Use

Scenario 10 is recommended for use with the team together in a conference room talking

through the issues Provide the initial indications to them and set the stage for the event

Định dạng
Số trang	9
Dung lượng	88,83 KB