Download Incident Response and Honeypots

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Distributed firewall wikipedia , lookup

Access control wikipedia , lookup

Cyber-security regulation wikipedia , lookup

Cyberwarfare wikipedia , lookup

Address space layout randomization wikipedia , lookup

Unix security wikipedia , lookup

Security-focused operating system wikipedia , lookup

Malware wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Computer and network surveillance wikipedia , lookup

Cross-site scripting wikipedia , lookup

Wireless security wikipedia , lookup

Cyberattack wikipedia , lookup

Social engineering (security) wikipedia , lookup

Computer security wikipedia , lookup

Mobile security wikipedia , lookup

Cybercrime countermeasures wikipedia , lookup

Transcript
CIT 480: Securing Computer
Systems
Incident Response and
Honeypots
Incident Response
What is an Incident?
Phases of Incident Response
1.
2.
3.
4.
5.
6.
7.
8.
Preparation
Identification
Containment
Damage Assessment
Preserve Evidence
Eradication
Recovery
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, network connections, NIDS alerts.
• Noticing unauthorized system changes.
• Notification from another entity
–
–
–
–
Customer
Partner
Law enforcement
Victim of attack launched from your IP range
• Strange activities on system:
– crashes, random reboots, slow performance.
Incident Response
Restoring system to satisfy site security policy
Phases:
1.
2.
3.
4.
5.
6.
7.
8.
Preparation for attack (before attack detected)
Identification of attack
Containment of attack (confinement)
Damage assessment
Preserve evidence (if necessary)
Eradication of attack (stop attack)
Recovery from attack (restore system to secure state)
Follow-up to attack (analysis and other actions)
Preparation
1. 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 Goals
1.
2.
3.
4.
5.
6.
Identify what happened.
Contain intrusion to prevent further damage.
Recover systems and data.
Prevent future intrusions of same kind.
Investigate and/or prosecute intrusion.
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
Containment
Limit 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
– Passive IDS tools like Bro and p0f work this way.
– 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.
Deception
Deception can be used to
– Slow down attackers
– Guide attackers to desired targets
– Track attacker activity
Helping defense discover + learn about attacks.
Honeypots
Honeypot: a system designed solely for intruders to
attack in order to accomplish one or more of the
following goals. Also known as a honeynet.
1. Detect intrusions with very few false positives, since
legitimate users have no reason to access honeypot.
2. Monitor attacker activities to determine targeted
assets, origin, motivation, capabilities, etc.
3. Waste intruder time attacking honeypot, so that
defender has time to respond to incident.
Low Interaction Honeypots
honeyd: responds to probes on a set of unused IP
addresses via shell scripts that can return banners for
simple scans like nmap –sV.
nepenthes: emulates vulnerable Windows services
to collect exploits and malware.
Dionaea: scriptable honeypot designed to be able to
emulate wide variety of vulnerable services to collect
exploits and malware.
Fakenet: simulates DNS, HTTP, HTTPS to
dynamically analyze malware. Returns reasonable
responses to malware requests.
Medium Interaction Honeypots
MI-honeypots usually emulate single service or
application with some degree of depth.
Examples:
–
–
–
–
Glastopf is a web application honeypot.
Honeypot-camera emulates a webcam.
Honeyprint appears to be a network printer.
Kippo is an ssh honeypot designed to log brute force
attacks and attacker shell commands.
High Interaction Honeypots
Client Honeypots
Honeymonkey
– Strider Microsoft Research project.
– Network of VMs running IE crawling the web
in search of malicious sites that attempt to
exploit browsers and distribute malware.
– Multiple versions of Windows and IE used.
Thug
– Low interaction client honeypot.
– Emulates multiple browsers and OSes.
Honeytokens
A honeytoken is data that is designed solely for
attackers to abuse. Any access to the data is an
indication of unauthorized use.
– Attempts to download honeytoken files or database
records can be identified by NIDS.
– Medical record systems will sometimes create fake
records for celebrities and politicians.
– Mailing lists may contain email addresses published
nowhere else that point to accounts that accept mail and
record sender information.
– Maps contain fake streets, towns, or islands to identify
when competitors copy the map.
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.
Preserve Evidence
In-depth live system investigation.
Construct a bit-level copy of entire hard
disk or partition for forensic examination.
Create image in single-user mode if possible:
md5sum /dev/hda
dd if=/dev/hda conv=noerror,sync |
ssh desthost “cat >disk.img”
desthost> md5sum disk.img
Eradication
1.
2.
3.
4.
Do nothing.
Kill attacker’s processes and/or accounts.
Block attacker’s network access to system.
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-Up
1. 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.
Counterattacking
Use 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.
– Active Defense Harbinger Distribution Linux.
Consequences
1. 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 DoS, 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 Points
1.
2.
3.
4.
5.
6.
Incident response procedure.
Prepare for an incident before one occurs.
Don’t trust the affected system in any way.
Contain, then prepare detailed response.
Legal issues of counterattacks.
Use honeypots to deceive attackers
1. Goals: intrusion detection, monitoring, slow
2. Interaction levels: low, medium, high
3. Honeyclients and honeytokens
References
1.
2.
3.
4.
5.
6.
7.
Matt Bishop, Introduction to Computer Security, Addison-Wesley,
2005.
N. Brownlee and E. Guttman, , “RFC 2350 - Expectations for Computer
Security Incident Response,” http://www.faqs.org/rfcs/rfc2350.html,
1998.
CERT, “Computer Security Incident Response Team (CSIRT) FAQ,”
http://www.cert.org/csirts/csirt_faq.html
William Cheswick, Steven Bellovin, Steven, and Avriel Rubin,
Firewalls and Internet Security, 2nd edition, Addison-Wesley, 2003.
Fraser (ed.), “RFC 2196 - Site Security Handbook,”
http://www.faqs.org/rfcs/rfc2196.html, 1997.
Garfinkel, Simson, Spafford, Gene, and Schartz, Alan, Practical UNIX
and Internet Security, 3rd edition, O’Reilly & Associates, 2003.
Kevin Mandia, Chris Prosise, and Matt Pepe, Incident Response &
Computer Forensics, 2nd edition, McGraw-Hill, 2003.
Released under CC BY-SA 3.0
 This presentation is released under the Creative Commons
Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license
 You are free:
 to Share — to copy and redistribute the material in any medium
 to Adapt— to remix, build, and transform upon the material
 to use part or all of this presentation in your own classes
 Under the following conditions:
 Attribution — You must attribute the work to James Walden, but
cannot do so in a way that suggests that he endorses you or your
use of these materials.
 Share Alike — If you remix, transform, or build upon this material,
you must distribute the resulting work under this or a similar open
license.
 Details and full text of the license can be found at
https://creativecommons.org/licenses/by-nc-sa/3.0/