Your SlideShare is downloading. ×
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
HAESUN061.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

HAESUN061.ppt

349

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
349
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Applying a Multi-level Security Mechanism to a Network Address Translation Scheduler Arthur McDonald Computer Science Department East Stroudsburg University
  • 2. Outline
    • Introduction
    • Multi-Level Security Basics
    • Linux Virtual Servers
    • Proposed Algorithm
    • Implementation and Experiments
    • Results and Conclusions
  • 3. Introduction
    • Recent Security Threats
    • Need to protect data on distributed systems
    • Linux Virtual Servers
    • Load Scheduling
    • Multi-Level Security
  • 4. Multi-Level Security
    • Information with different sensitivities to be stored on same system
    • Information is processed with users having different security classes
      • Prevents users from accessing info for which they are not cleared
    • Example on Next slide
  • 5. MLS Example
    • Data assigned 4 security classes or levels:
      • Level 1 – CLASSIFIED access
      • Level 2 – SECRET access
      • Level 3 – UNCLASSIFIED access
      • Level 4 – No access
    • Clearances are hierarchical
  • 6. MLS Properties – Access Control
    • Control what users can read, write or execute files
    • System must also make decisions about access control
    • Two types:
      • Discretionary Access Control (DAC)
      • Mandatory Access Control (MAC)
  • 7. Discretionary Access Control
    • Restricts access based on the identity of the user
    • Three basic types of access:
      • Read – User can open and view the data in file/directory
      • Write – User can open and write data to the file/directory
      • Execute – User can execute the file
        • Relevant only to executables
  • 8. Discretionary Access Control
    • Owner makes access decisions
    • Typically three categories:
      • Self: Owner of the data
      • Group: A set of users on the system
      • Public: All users of the system
  • 9. Mandatory Access Control
    • Used in systems with extremely sensitive data
    • All objects (files, directories, etc…) and subjects (users) are assigned a sensitivity level.
    • Subject’s sensitivity level specifies objects it has access to.
  • 10. Mandatory Access Control
    • Two parts to label: Classification and a set of categories
      • Classification is hierarchical
        • DOD uses Top Secret, Secret, Confidential and Unclassified
      • Categories are non-hierarchical – represent areas of information in the system
        • Subject with highest classification level may not mean they are cleared to access all data
  • 11. MLS Properties – Information Flow
    • Three Models:
      • Bell-LaPadula
      • Biba
      • Clark-Wilson
  • 12. Bell-LaPadula Model
    • Linear model
    • User with security level b can READ objects at level a iff a <= b
    • User at level b can write objects at level c iff c >= b
    • Higher access can read from lower level and lower access can write to higher levels
    • Insures data confidentiality
  • 13. Bell LaPadula Model Level b resources Read access only Write access only Read-Write access Level a Level c Level d Level b
  • 14. Biba Model
    • Opposite of Bell-LaPadula
    • Users at level b can write to level a iff a <= b and level b can read from level c iff c >= b
    • Insures data integrity
  • 15. Biba Model Level c Level b resources Write access only Read access only Read-Write access Level a Level d Level b
  • 16. Clark Wilson Model
    • Similar to Biba, with one more constraint
    • Task is separated into duties
    • Ensures integrity rules are not disobeyed
  • 17. Linux Virtual Servers
    • What is an LVS?
    • Why use them?
    • How is it done?
  • 18. Linux Virtual Servers – What?
    • Cluster of computers connected by fast network
    • Cluster “appears” to be a single machine
    • Service requests from incoming clients
      • HTTP, FTP, telnet, etc...
    • Minimum requirements
      • 1 Director machine
      • 2 or more Realservers
  • 19. Linux Virtual Servers – What? Client Realserver 2 Realserver N Director Realserver 1 Internet Network
  • 20. Linux Virtual Servers – Why?
    • Need for fast, reliable servers
    • Three requirements:
      • Incremental Scalability
      • 24x7 Availability
      • Cost-effectiveness
  • 21. Linux Virtual Servers – Why?
    • “Old” way – single machine
      • Need to upgrade when load becomes too much
      • Add faster CPU, more RAM, other hardware…
        • Complex and expensive
      • New machine can also become overloaded
  • 22. Linux Virtual Servers – Why?
    • LVS’ satisfy all the requirements
    • Scalability – Add/Remove machines to cluster easily
    • Availability – Services are backed by multiple machines – One goes down, not a problem
    • Cost effective – No “supercomputer” to upgrade; simply add PCs
  • 23. Linux Virtual Servers – How?
    • Network director and realservers together
      • Typically star topology network
      • Realservers are part of private network
    • Two IPs for director
      • Real IP: IP address for internal network
      • Virtual IP: Address that clients see
    • Services are assigned to the director, along with port number and scheduling algorithm
  • 24. Linux Virtual Servers – How?
    • Director waits for connections
    • Connection received:
      • Call scheduling function to determine what realserver to forward data to
    • Three forwarding methods:
      • Direct Routing
      • IP Tunnelling
      • Network Address Translation
  • 25. Linux Virtual Server – How?
    • Load Scheduling Algorithms
      • Round Robin
      • Weight Round Robin
      • Least Connection
      • Weighted Least Connection
      • Destination/Source Hash Scheduling
  • 26. MLS Load Scheduling
    • Distribute load across realservers based on security levels
    • Security level determined by client’s IP address
    • Three security levels: A, B and No Access
    • Level A forwarded to Realserver 1
    • Level B forwarded to Realserver 2
    • No Access – Data is dropped
  • 27. MLS Load Scheduling
    • Code developed based on LVS schdeuling algorithms
    • Compiled directly into the kernel
      • Can also be compiled as a module
  • 28. MLS Load Scheduling
    • Init, update and finished function
    • Two main functions:
      • ip_vs_mls_schedule
      • ip_vs_mls_get_security_level
  • 29. MLS Load Scheduling
    • Problems:
      • File I/O in Kernel Space
      • Dotted decimal string to unsigned int conversion of IP addresses
  • 30. Implementation
    • Hardware:
      • Four Intel Pentium machines connected by hub
    • Software:
      • Director: Red Hat 7.0
      • Realserver 1: Red hat 7.0 kernel 2.2.16, Apache
      • Realserver 2: Mandrake 7.1, Apache
      • Client: Windows XP, Internet Explorer
  • 31. Implementation
    • Installing LVS
      • Obtain “fresh” kernel from www.kernel.org
      • Patch kernel with the LVS code
      • Configure the kernel using xconfig
      • Compile and install modules
      • Compile kernel
      • Test the new kernel
  • 32. Implementation
    • IPVSADM
      • Administration program for LVS
      • Used to set up service
      • Add realservers to LVS
  • 33. Experiments
    • Attempt to connect to the realserver
      • Test Case 1 – Client IP address set to Level A access
      • Test Case 2 – Client IP address set to Level B access
      • Test Case 3 – Client IP address set to No Access
  • 34. Future Work
    • Improve algorithm for scalability
    • Design an admin tool for easy addition/deletion of client IP address/security levels
  • 35. Conclusions
    • Project is a good initial step in research towards MLS in Linux Virtual Servers
    • More work needs to be done, especially in the current global climate
    • Future looks bright for the LVS project

×