CIT 380: Securing Computer Systems

CIT 380: Securing Computer Systems Slide #1

CIT 380: Securing Computer Systems

Incident Response


Incident ResponseWhat is an Incident?Phases of Incident Response

1. Preparation2. Identification3. Containment4. Damage Assessment5. Preserve Evidence6. Eradication7. Recovery8. Follow-up


What is an Incident?Violation of security policy:

– Unauthorized access of information– Unauthorized access to machines– Embezzlement– Virus or worm attack– Denial of service attacks– Email spam or harassment


Detecting an Incident• Catching perpetrator in the act

– Unauthorized logins, NIDS alerts.• Noticing unauthorized system changes.• Receiving a message from another site,

saying that your site was used to launch an attack on them.

• Strange activities on system:– crashes, random reboots, slow performance.


Incident ResponseRestoring system to satisfy site security policyPhases:

1. Preparation for attack (before attack detected)2. Identification of attack3. Containment of attack (confinement)4. Damage assessment5. Preserve evidence (if necessary)6. Eradication of attack (stop attack)7. Recovery from attack (restore system to secure state)8. Follow-up to attack (analysis and other actions)


Preparation1. Configure intrusion detection systems.2. Determine your response goals.3. Document incident response procedures.

– Who to contact?– What to do?

4. Organizing a CSIRT– Finding and training personnel.– Hardware/software necessary for

investigation.


Incident Response Goals1. Determine if a security breach occurred.2. Contain intrusion to prevent further damage.3. Recover systems and data.4. Prevent future intrusions of same kind.5. Investigate and/or prosecute intrusion.6. Prevent public knowledge of incident.


Identification• Who/what reported incident.• Date and time of the incident.• Nature of the intrusion.

– What level of unauthorized access was attained?– Is it known to the public?

• Hardware/software involved– How critical are the affected systems?

• Assemble CSIRT– Team membership may vary based on nature of

incident


ContainmentLimit access of attacker to system resources.Containment method depends on criticality of

systems and extent of intrusion.– Monitoring intruder– Reducing intruder’s access– Deception– De-activating the affected account

• Need to kill active processes too– Blocking access to system via firewall– Pulling network/phone cable– Powering down system


Monitoring• Records attacker’s actions; does not interfere with

attack:– Idea is to find out what the attacker is after and/or

methods the attacker is using.• Problem: attacked system is vulnerable throughout

– Attacker can also attack other systems.• Example: type of OS can be derived from settings

of TCP and IP packets of incoming connections– Analyst draws conclusions about source of attack.


Reducing Access• Reduce protection domain of attacker.• Problem: if defenders do not know what

attacker is after, reduced protection domain may contain what the attacker is after.– Stoll created document that attacker d/led.– Download took several hours, during which the

phone call was traced to Germany.


DeceptionHoneypot: system designed for intruders to attack, to waste their time and to allow safe monitoring– ex: The Honeynet Project, honeyd

Deception Tool Kit– Creates false network interface.– Can present any network configuration to attackers.– When probed, can return wide range of vulnerabilities.– Attacker wastes time attacking non-existent systems

while analyst collects and analyzes attacks to determine goals and abilities of attacker.

Experiments show deception is effective response to keep attackers from targeting real systems.


Honeynet ProjectTool development

– Environment simulation: virtual machines.– Data control: firewalling tools to limit attacker

activities to avoid damaging other systems.– Data collection: network and keystroke loggers.– Data analysis: tools to extract relevant data from

tcpdump logs and more.

Research and documentation– Analysis of attacker and honeypot techniques.– Analysis of particular attacks.


Damage Assessment: Data• System date and time when assessment began.• List of users currently logged in.• Time/date stamps for filesystem.• List of processes• List of open network sockets

– Associated applications– Associated systems

• System configuration files.• Log and accounting files.• System date and time when assessment complete.


Data Assessment: ProcedureUse trusted binaries from floppy/CDROM

– Use a trusted shell.– Set PATH to only use floppy/CDROM tools.

System date and time:> dateMon Apr 26 13:33:08 EDT 2004

List of current users> w1:33pm up 30 day(s), 3:34, 3 users, load avg:0.26User tty login@ idle JCPU PCPU whatroot console 9:21am 4:13 -shwald pts/14 15Apr04 3:25 66:24 63:06 -bashroot pts/20 9:21am 4:12 -shnovi pts/6 Sat 4pm 17 52 -bash


Data Assessment: ProcedureFile date/time stamps

ls –alRu / >/mnt/floppy/atimels –alRc / >/mnt/floppy/ctimels –alR / >/mnt/floppy/mtime

Network ports> netstat –anpActive Internet connections (servers and

established)Proto Local Addr Foreign Addr State Programtcp :::22 :::* LISTEN 26327/sshd

tcp 10.17.0.110:22 10.1.0.90:51327 ESTABLISHED 28644/sshd: tcp 127.0.0.1:25 0.0.0.0:* LISTEN 1840/sendmailudp 0.0.0.0:32768 0.0.0.0:* 1456/rpc.statd udp 0.0.0.0:68 0.0.0.0:* 1363/dhclient

udp 0.0.0.0:111 0.0.0.0:* 1436/portmap


Data Assessment: ProcedureRunning Processes> ps auxUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 1 0.0 0.0 1928 520 ? S Apr17 0:04 init [5]

root 1403 0.0 0.0 2128 580 ? S Apr17 0:01 syslogd

-m 0rpc 1436 0.0 0.0 2516 576 ? S Apr17 0:00 portmaprpcuser 1456 0.0 0.0 2916 832 ? S Apr17 0:00

rpc.statdsmmsp 1849 0.0 0.2 7324 2520 ? S Apr17 0:00

sendmail: Queue runner@01:00:00 for /var/spool/clientmqueueroot 1970 0.0 0.0 2992 348 tty3 S Apr17 0:00

/sbin/mingetty tty3root 26327 0.0 0.1 4728 1504 ? S Apr21 0:00

/usr/sbin/sshdwaldenj 28646 0.0 0.2 8548 2560 ? S 11:12 0:00 sshd:

waldenj@pts/7waldenj 28647 0.0 0.1 6800 1500 pts/7 S 11:12 0:00 -bashroot 28767 0.0 0.1 6572 1356 pts/7 S 13:44 0:00 bashroot 28789 0.0 0.0 3624 876 pts/7 R 13:49 0:00 ps aux


Data Assessment: ProcedureCollect system configuration

– Check for sniffers: ifconfig– /etc/passwd, /etc/shadow, /etc/group– Scheduled jobs: cron and at– System init files: /etc/inittab, /etc/rc.d

Collect system log files– Login logs in /etc/utmp, /etc/wtmp– Check /etc/syslog.conf– Log files in /var/adm, /var/log– Process accounting files in /var/acct– Shell history files, e.g., ~/.bash_history


Preserve EvidenceIn-depth live system investigation.Construct a bit-level copy of entire hard disk or partition for forensic examination.– Create image in single-user modemd5sum /dev/hdadd if=/dev/hda conv=noerror,sync | ssh desthost “cat >disk.img”

desthost> md5sum disk.img


Eradication1. Do nothing.2. Kill attacker’s processes and/or accounts.3. Block attacker’s network access to system.4. Patch and repair what you think was changed,

then resume operation.5. Investigate until root cause discovered, then

restore system from backups and patch security holes.

6. Call law enforcement before proceeding further.


Follow-Up1. File reports with law enforcement, vendor, or

regulatory agency.2. File insurance claims if relevant.3. Notify administrators of other affected systems.4. Disciplinary actions against employees for

internal attacks.5. Update security of computer networks/systems.6. Review handling of the incident.7. Update incident handling policy/training.


Follow-UpTracking/Counter-attacking

– IP header marking: traceback at the packet level.– Counterattacking


IP Header MarkingRouter inserts header data indicating path taken.When do you mark it?

Deterministic: always marked.Probabilistic: marked with some probability.

How do you mark it?Internal: marking placed in existing header.Expansive: header expanded to include space for

marking.


CounterattackingUse legal procedures

– Collect chain of evidence so legal authorities can establish attack was real.

– Check with lawyers for this• Rules of evidence very specific and detailed.• If you don’t follow them, expect case to be dropped.

Technical attack– Goal is to damage attacker seriously enough to

stop current attack and deter future attacks.


Consequences1. Counterattack may harm innocent party.

• Attacker may have broken into source of attack or may be impersonating innocent party.

2. Counterattack may have side effects.• If counterattack is flooding, may block legitimate use of

network.3. Counterattack antithetical to shared use of network.

• Counterattack absorbs network resources and makes threats more immediate.

4. Counterattack may be legally actionable.


Example: Counterworm• Counterworm given signature of worm.• Counterworm spreads rapidly, deleting all

occurrences of original worm.– ex: Welchia/Nachi hunts Blaster/MyDoom worms.

• Issues– Can counterworm delete only targeted worm?– What if infected system gathering worms for research?– How do originators of counterworm know it will not

cause problems for any system?• And are they legally liable if it does?


Key Points1. Security incidents come in many forms.2. Prepare for an incident before one occurs.3. Understand your response goals.4. Don’t trust the affected system in any way.5. Contain the problem, then prepare detailed

response.6. Save data offline for later analysis.7. Legal issues of counterattacks.


References1. Matt Bishop, Introduction to Computer Security, Addison-Wesley,

2005.2. N. Brownlee and E. Guttman, , “RFC 2350 - Expectations for

Computer Security Incident Response,” http://www.faqs.org/rfcs/rfc2350.html, 1998.

3. CERT, “Computer Security Incident Response Team (CSIRT) FAQ,” http://www.cert.org/csirts/csirt_faq.html

4. William Cheswick, Steven Bellovin, Steven, and Avriel Rubin, Firewalls and Internet Security, 2nd edition, Addison-Wesley, 2003.

5. Fraser (ed.), “RFC 2196 - Site Security Handbook,” http://www.faqs.org/rfcs/rfc2196.html, 1997.

6. Garfinkel, Simson, Spafford, Gene, and Schartz, Alan, Practical UNIX and Internet Security, 3rd edition, O’Reilly & Associates, 2003.

7. Kevin Mandia, Chris Prosise, and Matt Pepe, Incident Response & Computer Forensics, 2nd edition, McGraw-Hill, 2003.

http://www.faqs.org/rfcs/rfc2350.html

http://www.faqs.org/rfcs/rfc2196.html

CIT 380: Securing Computer Systems

Documents