Dynamic Firewalls and Service Deployment Models for Grid Environments

1. Dynamic Firewalls and Service Deployment Models for Grid Environments Gian Luca Volpato, Christian Grimm RRZN – Leibniz Universität Hannover Cracow Grid Workshop 2006 (CGW2006) 15th-18thOctober 2006

2. Overview • Dynamic Firewall • General concepts • Dyna-Fire • Cooperative On-Demand Opening (CODO) • Limitations • Globus Toolkit deployment model • Services at the Resource Provider • Use of existing computing infrastructure • Minimal number of connections through the site firewall Gian Luca Volpato | 16-10-2006 | Slide 2

3. Firewall • A Firewall is a piece of hardware and/or software which functions in a network environment to prevent some communications forbidden by the security policy. * • Good: it blocks unwanted and malicious traffic. • Bad: it might be not flexible enough to allow seamless execution of Grid applications. • * Wikipedia Gian Luca Volpato | 16-10-2006 | Slide 3

4. Dynamic Firewall • Goal • Protect a network so that it appears completely inaccessible from external systems but still responds to trusted clients, i.e. allow external connections on-demand. • Current solutions Signaling protocol to add/remove filtering rules: • “Off-path”: communication between applications and firewalls • “In-path”: communication between application peers intercepted by intermediate firewalls Gian Luca Volpato | 16-10-2006 | Slide 4

5. 2 Intranet Client Application Server Application Daemon Library 1 Dyna-Fire &Cooperative On-Demand Opening • One daemon runs on the same host of the firewall to: • monitor all connection requests • add/remove filtering rules in the firewall • A connection is allowed when the client request is successfully authenticated and authorized. • Signaling protocol: • Dyna-Fire==>messages carried by Port Knocking • CODO ==> messages carried over SSL channel Gian Luca Volpato | 16-10-2006 | Slide 5

6. Limitations of dynamic firewalls • No mechanism to discover automatically the firewalls along the path • Signaling before connection establishment? • Static routing table configuration • Dyna-Fire and Port Knocking • CPU overhead for monitoring of connection attempts • Exclusive reservation of some ports • Unidirectional protocol exposed to reply and man-in-the-middle attacks • CODO • Applications (client and server!) must be recompiled/relinked with a special socket library • Authorization policy is coarse-grained and not flexible Gian Luca Volpato | 16-10-2006 | Slide 6

7. GRAM Server Batch System Nodes RFT Server Batch System Master Intranet Local MDS-Index GridFTP Server User Interface Deployment model for Globus Toolkit 4 • Constraints • Use existing batch computing resources • GT4 services must be reachable from the Internet • Goals • Avoid any connection between: • hosts in the Intranet and hosts in the external Internet • Identify, analyze and reduce the connections between: • hosts in the Intranet and GT services in the DMZ DMZ Gian Luca Volpato | 16-10-2006 | Slide 7

8. GRAM Server Batch System Nodes Batch System Master Intranet Batch Sys. Login Node DMZ Batch system • Install Globus GRAM on a host that can submit jobs to the Batch System • Either: • Enable shared file system between this node and the Batch System • Modify GRAM scripts in order to use Batch System functions for file stage-in and file stage-out Gian Luca Volpato | 16-10-2006 | Slide 8

9. Batch System Nodes Batch System Master Intranet GridFTP Server DMZ GridFTP option 1 • GridFTP server and Batch System have a shared file system • Input files are transferred to the local GridFTP server before jobs are submitted to the local GRAM server • Output files are stored in the local GridFTP server Gian Luca Volpato | 16-10-2006 | Slide 9

10. Batch System Nodes Batch System Master Intranet GridFTP Server DMZ GridFTP option 2 • System nodes have direct access to the local GridFTP server • Input files are transferred to the local GridFTP server before jobs are submitted to the local GRAM server • Output files are uploaded to the local GridFTP server Gian Luca Volpato | 16-10-2006 | Slide 10

11. GRAM Server RFT Server Batch System Nodes Batch System Master Intranet Batch Sys. Login Node GridFTP Server Reliable File Transfer • RFT server is installed on the same host where the GRAM server runs • Connections are established: • within the DMZ • between the DMZ and the external Internet DMZ Gian Luca Volpato | 16-10-2006 | Slide 11

12. GRAM Server RFT Server Batch System Nodes Batch System Master Local MDS-Index Intranet Batch Sys. Login Node GridFTP Server DMZ MDS • Deploy one MDS-Index that collects monitoring information from all local GRAM and RFT servers (in future also GridFTP servers) • Connections are established: • within the DMZ • between the DMZ and the external Internet • Batch System Master and GRAM server (Ganglia, Nagios, etc.) Gian Luca Volpato | 16-10-2006 | Slide 12

13. GRAM Server RFT Server Batch System Nodes Batch System Master Local MDS-Index Intranet Batch Sys. Login Node GridFTP Server DMZ User Interface User Interface • The User Interface is used to submit/monitor/manage Grid jobs • Connections are established: • within the DMZ • between the DMZ and the external Internet Gian Luca Volpato | 16-10-2006 | Slide 13

14. GRAM Server RFT Server Batch System Nodes Batch System Master Local MDS-Index Batch Sys. Login Node GridFTP Server Intranet User Interface RFT GRAM Batch System DMZ MDS GridFTP User Interface Shared File System Full model Gian Luca Volpato | 16-10-2006 | Slide 14

15. Summary • Dynamic Firewall • General concepts • Dyna-Fire • Cooperative on Demand Opening (CODO) • Limitations • Globus Toolkit deployment model • GT4 services in DMZ • Use of existing computing infrastructure • Minimal number of connections through the firewall Gian Luca Volpato | 16-10-2006 | Slide 15

16. Thank you! • Questions? Gian Luca Volpato | 16-10-2006 | Slide 16