Presentation

Download Report

Transcript Presentation

Presented by Xiaoyu Qin 21637881
Virtualized Access Control
&
Firewall Virtualization
www.infotech.monash.edu.au
Outline
•
•
•
•
•
•
•
•
•
Background
Project Aims & Previous Research
Research Problem
Research Approach & Method
Analysis
Demo Implementation
Design Review
Future Work
Conclusion
www.infotech.monash.edu.au
2
Background – Grid Network & Security
• Application Solutions
– Globus Security Infrastructure
– Security of Open Grid Services Architecture
– Security as Services
– Public Key Infrastructure
• Virtual Organization & Virtual Connectivity
• Gateway Solutions
– Common Solutions
– Grid Firewall & Firewall Traversal
www.infotech.monash.edu.au
3
Background – Understanding Virtualization
• Pooling & Reallocating
– Resource: Pooling
– Infrastructure: Multiplying, Clustering
• Simulation
– Simulators: VMs
– Application Virtualization: Sandbox
– Network: Tunnelling
– Grid: Virtual Organization *
• Firewall Virtualization
– Dynamic Firewall
– Zone Based Virtual Firewall
– Virtual Access Control
www.infotech.monash.edu.au
4
Project Aims & Previous Research –
Security Gateway for Grid
• Grid Security Scenario
– Unpredictable application & users
– Dynamic
– Large quantity of devices
• Security Gateway
– Packet Filtering
– Access Control
– Intrusion Detection/Prevention
www.infotech.monash.edu.au
5
Project Aims & Previous Research –
Firewall Traversal & Firewall Virtualization
• Firewall Proxy Model
• Firewall Control Model
www.infotech.monash.edu.au
6
Research Problem – NAT Problem
• Server IP + Port == A TCP Service
• Source IP + Port != Client User Identity
www.infotech.monash.edu.au
7
Research Approach & Method
• Research Approach
– A grid firewall solution
– Without NAT problem
– Easy to implement & deploy
• Research Method
– Problem Oriented Research
www.infotech.monash.edu.au
8
Analysis – Problem Breaking Down
Grid Security Gateway
Access Control on
Demand
Permit/Filter (Non)Authorized
Communication By ACL
• f: (Communication, ACL) ->
Permit/Filter
Determine (Non)Authorized
Communication By ACL
• g: Communication -> Identity
(*Session Key)
• h: (Identity, ACL) -> Permit/Filter
• f = h(g(Communication), ACL)
www.infotech.monash.edu.au
9
Analysis – Research Questions
• Central Question :
– How do we determine the identity information?
• Q1: What can a firewall determine? How?
– What can a pure network firewall determine?
– Is there any other choice (IPTables) which can do more?
• Q2: How to generate and carry the information which can
be determined?
– Can the program change some existing properties of the
communication? How?
– Can the program add new properties? How?
www.infotech.monash.edu.au
10
Analysis – Research Hypotheses
•
•
•
Capability of Network Firewall
– IP: Source and target IP address
– TCP: Source and target port
– Protocol
Special Capability of IPTables
– Owner: uid, pid, gid...... (IPFW has also ‘out uid’)
Change existing properties of communication
– Packet based:
> Changing Address: Authentication based NAT/PAT
> Changing protocol: Tunnel/Proxy (useless)
– Connection based:
> Extra handshake (hard to implement)
•
Can the program add new properties? How?
– Application specific Tunnel/Proxy
www.infotech.monash.edu.au
11
Analysis – Possible Solution: NAT/PAT
• Cons
– Customize IP assigning mechanism
> Not supported by most of current VPN solutions
> Hard to program
– Check after tunnel created
> Complex control signal
– Delay caused
– Hard to program but possible*
• Pro
– Existing firewall can be used, but extra
component to run the program is still needed.
www.infotech.monash.edu.au
12
Analysis – Possible Solution: Tunnel/Proxy
• Few Firewall Choice: IPTables, IPFW…
• Tunnel Proxy Choice
– Does it create process for each session?
– Can the process owner one-to-one map to the client
identity?
– SSH Port Forwarding
> Pros:
– Commonly used
– Gateway-to-Gateway
– Only tunnel the request (Comparing with VPN)
> Cons: Client command & settings
• Other methods can be examined
www.infotech.monash.edu.au
13
Demo Implementation
•
•
•
•
•
VAC> show
use whitelist
service 0 10.1.1.2:80 TCP //Http AppServer
ACCEPT User xyqin1
Client>ssh -N -f -L 80:10.1.1.2:80 xyqin1@VFW
www.infotech.monash.edu.au
14
Design Review
• NAT Problem
– NAT between the gateways does not harm
• Efficiency Cost
–
–
–
–
Pre-defined tunnel and filtering rules
One time encapsulating
Only tunnel the request
Non-Cipher SSH is a choice & SSH is not the only choice
• Capability & Reliability
– Clustering
– Load Balance
www.infotech.monash.edu.au
15
Future Work
• Virtualization
– Scalable (Zones, Multiple Instances)
– Dynamic Access Control
– Clustering
• Usability
– Client side program
– Remote Administration
• Distributable
– Authentication Server
• Extendable
– Extensions? API?
www.infotech.monash.edu.au
16
Conclusion
• It is possible and necessary to
implement authentication based access
control on grid gateway, which is secure,
extensible and interoperable with grid.
• Pure network filtering firewall is very
weak solution for grid security purpose.
• Grid security needs application level
methods because of virtualization.
www.infotech.monash.edu.au
17
Q&A
www.infotech.monash.edu.au
18