Computer Security CSE 543
Popular in Course
Popular in Computer Science and Engineering
This 0 page Class Notes was uploaded by Libby Kuhlman on Sunday November 1, 2015. The Class Notes belongs to CSE 543 at Pennsylvania State University taught by Staff in Fall. Since its upload, it has received 20 views. For similar materials see /class/233115/cse-543-pennsylvania-state-university in Computer Science and Engineering at Pennsylvania State University.
Reviews for Computer Security
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 11/01/15
CSE 543 Computer Security Fall 2006 Lecture 18 Network Security November 7 2006 URL httpwwwcseIosuedutjaegercse543f06 PENNSTATE Denial of Service o Intentional prevention of access to valued resource 0 CPU memory disk system resources 0 DNS print queues NIS services 0 Web server database media server applications 0 This is an attack on availability delity 0 Note launching DOS attacks is easy 0 Note preventing DOS attacks is hard 0 Mitigation the path most frequently traveled DDOS generalized by Mirkovic 0 Send a stream of packetsrequestswhatever 0 many PINGS HTML requests 0 Send a few malformed packets 0 causing failures or expensive error handling 0 lowrate packet dropping TCP congestion control 0 ping of death 0 Abuse legitimate access 0 Compromise servicehost 0 Use its legitimate access rights to consume the rights for domain eg local network 0 Eg Firstyear graduate student runs a recursive file operation on root of NFS partition CSE543 Computer and Network Security Fall 2006 Professor Jaeger S M U RF Attacks PENNEISQL o This is one of the deadliest and simplest of the DOS attacks called a naturally ampli ed attack 0 Send a large number PING packet networks on the broadcast IP addresses eg 19216827254 0 Set the source packet IP address to be your victim 0 All hosts will reflexiver respond to the ping at your victim 0 and it will be crushed underthe load Broadcast PENNSTATE Canonical common DOS Request Flood 0 Attack request flooding o OvenNhelm some resource with legitimate requests o eg webserver phone system i 0 Note unintentional flood is called a ash crowd l l PENNSTATE DOS Prevention ReverseTuring Tests 0 Turing test measures whether a human can tell the difference between a human or computer Al 0 Reverse Turning tests measures whether a user on the internet is a person a bot whatever o CAPTCHA completely automated public Turing test to tell computers and humans apart 0 contorted image humans can read computers can t 0 image processing pressing SOA making these harder S W m 0 Note often used notjust for DOS prevention but for protecting free services email accounts PENNSTATE DOS Prevention Puzzles 0 Make the solver present evidence of work done 0 If work is proven then process request 0 Note only useful if request processing significantly more work than n 0 Puzzle design 0 Must be hard to solve 0 Easy to Verify o Canonical Example 0 Puzzle given Xbits of output of hr where h is a cryptographic hash function 0 Solution Invert hr 0 Q Assume you are given 108 bits of output for 128bit hash function how hard would it be to solve the puzzle I l PENNSTATE Distributed denial of service 0 DDOS Network oriented attacks aimed at preventing access to network host or service o Saturate the target s network with traffic 0 Consume all network resources eg SYN o Overload a service with requests 0 Use expensive requests eg sign this data 0 Can be extremely costly eg Amazon 0 Result servicehostnetwork is unavailable 0 Frequently distributed via other attack 0 Note IP is often hidden spoofed I l The canonical DDOS attack gt V quot adVersaI39Y zombieS CSE543 Computer and Network Security Fall 2006 Professor Jaeger PENNSTATE Adversary Network zombies Why DDOS o What would motivate someone DDOS Reachabilily n 0 An axe to grind 0 Curiosity script kiddies 0 Blackmail 0 Information warfare gargaessyxaig Timezmu n c Copyrigm 2003 Matrix Nesyslems Inc www mamnmyszems mm 131124 14x10 16m 13m 000 2200 T EST jan249AM 11AM 1PM 3PM 5PM 0 Internet is an open system o Packets not authenticated probably can t be 0 Would not solve the problem just move it firewall 0 Too many endpoints can be remote controlled I l Why is DDOS possible cont o Interdependence services dependent on each other 0 Eg Web depends on TCP and DNS which depends on routing and congestion control 0 Limited resources or rather resource imbalances 0 Many times it takes few resources on the client side to consume lots of resources on the server side 0 Eg SYN packets consume lots of internal resources 0 You tell me as said by Mirkovic et al 0 Intelligence and resources not colocated 0 No accountability 0 Control is distributed I l DDOS and the E2E argument o E2E a simplified version We should design the network such that all the intelligence is at the edges 0 So that the network can be more robust and scalable 0 Many think is the main reason why the Internet works 0 Downside 0 Also no real ability to police the trafficcontent 0 So many security solutions breakthis E2E by cracking open packets eg application level firewalls 0 DDOS is real because ofthis PENNSTATE Q An easy fix 0 How do you solve distributed denial of service Simple DDOS Mitigation PENNSTATE lngressEgress Filtering Helps spoofed sources not much else Better Security Limit availability of zombies not feasible Prevent compromise viruses Quality of Service Guarantees QOS Pre or dynamically allocate bandwidth Eg diffserv RSVP Helps where such things are available Content replication Eg CDS Useful for static content Push back PENN Initially detect the DDOS Use local algorithm lDesque processing Flag the sourcestypeslinks of DDOS traffic Pushback on upstream routers Contact upstream routers using PB protocol Indicate some filtering rules based on observed Repeat as necessary towards sources Eventually all enough sources will be filtered Q What is the limitation here S Tra ceback ma Routers forward packet data to source Include packets and previous hop At low frequency 120000 Targets reconstruct path to source IP unreliable Use perhop data to look at Statistics say that the path will be exposed Enact standard Add filters at routers along the path R1 R2 R3 DDOS Reality None of the protocol oriented solutions have really seen any adoption too many untrusting illinformed mutually suspicious parties must play together well hint human nature solution have many remaining challenges Real Solution Large ISP police there ingressegress points very carefully Watch for DDOS attacks and filter appropriately eg BGP routing tricks blacklisting whitelisting Products in existing that coordinate View from many points in the network to identify upswings in Interestingly this is the same way they deal with worms Lecture 18 Systems and Midterm Review CSE543 Fall 2007 Computer and Network Security Professor Jaeger October 30 2007 CSE543 Computer and Network Security Fall 2007 Professor Jaeger PENNSTATE Understanding Data Lifetime What happens to data in a system Where do secrets go Handled by Hardware systems middleware applications drivers etc How to find leaks and solve them CSE543 Computer and Network Security Fall 2007 Professor Jaeger PENNSTATE Data Lifetime How long memory values reside on a system Allocate a buffer Assign a secret Free the buffer Q What happens to the memory during and after this cycle What happens to freed memory Data may be written elsewhere used for other purposes Q What s the threat model here Key and other secrets protection is paramount Can t Be That Hard Typical solutions Zero the memory on free Pin memory so not written to swap Encrypted file systems Problems Compilers may not comply Zeroing code on free buffers is optimized out Crashes Incorrect features don t really pin memory Hibernation and Migration Write state of system Complex interactions of logging random number generation crash dumps error reporting etc I l Understanding Approach Whole System Simulation TaintBochs extension of lA82 simulator Key Ideas Shadow Memory Backup of all existing memory registers and main memory Propagation Policy If any byte of any input value is tainted then all bytes of the output are tainted Exceptional Cases Tainted lookup tables Add more tainting Constant functions Remove unnecessary tainting Tainted Inputs Device inputs all keyboard or patterns network Application state what data is tainted to the system I l S Analy5is mg Log everything All changes in system state at any point in simulation System states Can generate the state of the system at any time Identify Data Map memory and registers to source variables Program and line number where variable was defined Patch Linux kernel to store this or core dump reading Identify Code Find line number of modifying code Can also enact gdb to use most features from a state Findings Mozilla browser What happens to a userinput password Ends up in Linux tty buffers Linux Random number generator Xserver input queue Linux UNIX domain socket buffers Mozilla strings Everyone in path allocates memory Sometimes for multiple purposes Free d but not zero d Memory is still around until reused May also be copied to other variables Some are easy Heap memory Ensure memory is zero d Stack memory Zero the stack frame Some are harder Stores built from tainted data Random number and others in memory Stores written to other places Swap encrypt it Logs etc Encrypt them What Does This Say About Security Systems Security Involves interactions at multiple levels OS Devices Application Services X Window System Users Function ls Defined By Code What does that instruction do What is its security impact Can programmers express this Or can we figure it out Can it be conveyed into a form that users can work within Not around I l Midterm I I I In class Closed book and closed notes Contents 18 crypto and 28 systems security Crypto Scope is same as miniexam Questions will be closely related but no same or subsumed by miniexam Systems Principles Systems Approaches Some times compare them I l PENNSTATE Security Terminology Adversary Risks Vulnerability Threats Compromise Trust Trust Model Threat Model Cryptography PENNTE Encryption Decryption Symmetric Key Systems DES Onetime pads Public Key Systems RSA DiffieHellman Hash Functions Uses Properties Combinations of these into protocols Threats to crypto systems use I l PENNSTATE Authentication Key distribution NeedhamSchroeder Secret and public key Kerberos Protocol Basics Extensions to NH Kerberos Flaws Public Key Infrastructure Use Limitations PENNSTATE Trusted Computing Hardware for Security Protected Storage Hash Extends Sealed Storage IMA Model Paper What can really be done Issues Trust and DRM Systems Security PM Access Control Fundamentals Protection State Protection System Reference Monitor Access Matrix Policies Secrecy BellLaPadulaM LS Integrity Biba LOMAC ClarkWilson GoalsProperties How represented how achieved ACLs and Capabilities Functions and issues I l PENNSTATE Systems Architectures Protection systems UNIX Windows Features used for protection andor security Secure Systems Sandbox Systems Secure Capability Systems Multics SELinux Domain transitions Programming language vulnerabilities Securitytyped languages Related to HW SELinux and SecurityTyped Languages PENNSTATE Good Luck CSE543 Computer and Network Security Fall 2007 Professor Jaeger Page 17
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'