1 / 35

Applying a Multi-level Security Mechanism to a Network Address Translation Scheduler

Applying a Multi-level Security Mechanism to a Network Address Translation Scheduler. Arthur McDonald Computer Science Department East Stroudsburg University. Outline. Introduction Multi-Level Security Basics Linux Virtual Servers Proposed Algorithm Implementation and Experiments

lew
Download Presentation

Applying a Multi-level Security Mechanism to a Network Address Translation Scheduler

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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. Level d Level c Write access only Read-Write access Level b Level b resources Read access only Level a Bell LaPadula Model

  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. Level d Level c Read access only Read-Write access Level b Level b resources Write access only Level a Biba Model

  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. Client Internet Director Network Realserver 1 Realserver 2 Realserver N Linux Virtual Servers – What?

  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

More Related