1.Architecture

Course 3: Network Security, Section 1 Pascal Meunier, Ph.D., M.Sc., CISSP May 2004; updated July 30, 2004 Developed thanks to the support of Symantec Corporation, NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise Center Copyright (2004) Purdue Research Foundation. All rights reserved.

Course 3 Learning Plan Architecture Physical and link layer Network layer Transport layer Application layer: DNS, RPC, NFS Application layer: Routing Wireless networks More secure protocols: DNSSEC, IPSEC, IPv6

Learning objectives Understand the logical order of presentation for this course Understand the coverage and focus Understand how networks are organized by layers

Introduction Network architecture is layered Lower layer vulnerabilities are inherited at higher levels Describing exploitable features and vulnerabilities in the scope of each layer makes sense TCP/IP v.4 is dominant design in use Many vulnerabilities can't be prevented without a major transition to a completely new design, or are hard problems Most core vulnerabilities can't really be fixed This is an important design consideration for any application that needs to use networks

Strategies Prevention Disabling features and functionality Disabling exploitation paths Some choice of network application-level protocols Mitigation (limiting consequences and impact) Network configurations (de-militarized zones, etc...) Detection Response Providing guarantees at the application level Migrating to other, safer protocols

Focus on Prevention and Detection Identify features and functionality to be turned off or provided with limited availability Identify exploitation paths and attempt to block them Investigate choice of application-level protocols (e.g., DNS, BGP, etc...) Detect Internal attackers Accountability When all the above was not sufficient Is there another exploitation path? Provide justification for continued or increased blocking

Labs and Tools Survey tools that help identify, block, control and detect Firewalls Filtering proxies Arp integrity tools Intrusion detection tools

Policies Policies define the accepted, normal states of the network Firewall rules encode a subset of the above Detection should ideally cover anything outside policy Low return on detecting blocked incoming attacks Many, expensive, no accountability (but statistics useful) Need to detect violations in the networks you control Should be inspired by The purpose of design decisions at each network layer The risks of the adopted designs We will review the above

What We Won't Cover Detailed firewall configurations See instead "Firewalls and Internet Security: Repelling the Wily Hacker", 2nd Edition, by William Cheswick, Steven M. Bellovin, Aviel D. Rubin. See CERT's Advanced Information Assurance Handbook, http://www.cert.org/archive/pdf/aia-handbook.pdf Exhaustive coverage of all network services and associated risks X11 SNMP etc...

Not Covered (cont.) Monitoring intrusion detection systems and tuning rules Incident response

Learning objectives Know the names and responsibilities of each layer in the TCP/IP model Understand that design limitations and vulnerabilities are inherited upwards

Network Models OSI Model 7 layers Old Applications often have properties of several layers at once Makes classification difficult, confusing TCP/IP Model a.k.a. "DoD" model (Department of Defense) 5 layers Often the two bottom layers are fused, yielding 4 layers Be wary of references to "layer 3" In which model? The 4-layer model makes the discussion of frames and the logical link sublayer more difficult, so we'll use 5 layers

The OSI 7-Layer Model OSI: Open Systems Interconnection ISO standard Layered approach provides: Simplification Abstraction Each layer talks only to the equivalent layer somewhere else Division of responsibilities Standardization and interchangeability of equipment from different makers

The 7 Layers Application Presentation Session Transport Network Data Link Physical

Physical Layer Specifies the physical signals (electrical, optical, etc...) Type Levels Speed Cables if any Range Examples: 10-Base-2 Ethernet coaxial cable specification

Data Link Layer How to transmit data between two stations in the same segment Two components MAC (Media Access Control) Control which station receives which data Which station has permission to transmit MAC addresses uniquely identify stations (in theory) LLC (Logical Link Control) frame synchronization Data unit is called a frame flow control error checking

Network Layer Routing between segments Forwarding Addressing Internetworking Error handling Congestion control Packet sequencing Data units are called "packets"

Transport Layer Reliability retransmissions, etc... Error recovery Flow control

Other Layers Session Handles connections between applications Presentation Handles encoding, encryption, etc... Application

Question How would you classify SSL (Secure Socket Layer) and TLS (Transport Layer Security), given that they: Provide encryption Are often implemented inside applications such as web browsers Provide sessions between hosts and servers Are responsible for data transport?

Answer SSL has been classified at all of those layers by different people: Transport Session Presentation Application

The TCP/IP Model 5 layers: Application (combines presentation and session) Transport Network Data Link Physical We will use this one as it is less ambiguous

Question Where would you classify SSH in the TCP/IP model?

About These Slides You are free to copy, distribute, display, and perform the work; and to make derivative works, under the following conditions. You must give the original author and other contributors credit The work will be used for personal or non-commercial educational uses only, and not for commercial activities and purposes For any reuse or distribution, you must make clear to others the terms of use for this work Derivative works must retain and be subject to the same conditions, and contain a note identifying the new contributor(s) and date of modification For other uses please contact the Purdue Office of Technology Commercialization. Developed thanks to the support of Symantec Corporation

Pascal Meunier [email_address] Contributors: Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera

1.Architecture

More Related Content

Similar to 1.Architecture (20)

More from phanleson (20)

Recently uploaded (20)

1.Architecture

Editor's Notes