Please note: This documentation is for OSG 1.2. While we still provide critical security updates for OSG Software 1.2, we recommend you use OSG Software 3 for any new or updated installations. We are considering May 31, 2013 as possible OSG 1.2 End of Life (EOL).

ReleaseDocumentation
ComputeElementFirewalls
Reviewed Passed
by SuchandraThapa
Test Passed
by SuchandraThapa
Released
by HorstSeverini

OSG Services and Firewalls

About this Document

hand This document is for System Administrators. A brief description of services provided by a Compute Element and Storage Element will be given, followed by recommendations how to adjust the firewall for their correct operation. OSG Client installations only have to worry about the GLOBUS_TCP_PORT_RANGE and GLOBUS_TCP_SOURCE_RANGE.

Introduction

Network traffic may be blocked by a firewall for inbound and outbound traffic in dependence on host- and domain names, IP addresses, port numbers and protocols. In this document we distinguish between two types of firewalls:

  1. network firewalls administrated centrally and typically outside of your administrative domain
  2. host-based firewalls within your administrative domain

The protocol and port requirements for a Compute Element and Storage Element are listed below. Please provide them to the administrator of a network firewall potentially blocking network traffic to your host. Next, follow the instructions to adjust the firewall settings on your host-based firewall.

Requirements

  1. be familiar with your institute's network policy and firewall configuration
  2. root access is required to configure a host-based firewall using iptables

Compute Element Services and Firewall Requirements

Service Name Protocol Port Number Inbound Outbound Comment
GRAM tcp 2119 choice-yes    
GRAM callback tcp GLOBUS_TCP_PORT_RANGE choice-yes   contiguous range of ports (8*number of job slots)
GRAM callback tcp GLOBUS_TCP_SOURCE_RANGE   choice-yes contiguous range of ports
GRAM-WS tcp 9443 choice-yes choice-yes  
GridFTP tcp 2811 choice-yes   service GridFTP on the CE
Monalisa udp 9000 choice-yes   for ABping, see $VDT_LOCATION/MonaLisa/Service/VDTFarm/ml.properties

Storage Element Services and Firewall Requirements

Service Name Protocol Port Number Inbound Outbound Comment
GridFTP tcp 2811 choice-yes    
GRAM callback tcp GLOBUS_TCP_PORT_RANGE choice-yes   contiguous range of ports
GRAM callback tcp GLOBUS_TCP_SOURCE_RANGE   choice-yes contiguous range of ports
Storage Resource Manager tcp 8080 choice-yes    
Storage Resource Manager tcp 8443 choice-yes    

Other Optional Services and Firewall Requirements

You may need to open the following required inbound ports for listed optional services.

Service Name Protocol Port Number Inbound Outbound Comment
MDS tcp 2135 choice-yes   obsolete
GIIS tcp 2136 choice-yes   obsolete
GSISSH tcp 22 or 2222 choice-yes    
MyProxy tcp 7512 choice-yes    
GUMS tcp 8443 choice-yes    
VOMS tcp 15001+ choice-yes   range of ports, increment by 1 for each VO supported
RLS tcp 39281 choice-yes    
Squid tcp 3128 choice-yes    

Host-based Firewall Configuration

The default firewall configuration for RedHat's iptables defines a stateful packet filter; no ports that are not explicitly opened by iptables will be open. This includes high numbered ports that are often used by grid services.

If your preference is to leave as much of the stateful packet filtering in place but enable just those grid services you want to deploy, then you can use the following instructions. On RHEL or similar systems the firewall is configured using the /etc/sysconfig/iptables file:

# GLOBUS_TCP_PORT_RANGE
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport <begin port>:<end port> -j ACCEPT
# Monalisa, grabs 3 ports from the following range
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 9000:9010 -j ACCEPT
-A RH-Firewall-1-INPUT  -m state --state NEW -p udp -m udp --dport 9000 -j ACCEPT
# GRAM
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 2119 -j ACCEPT
# Gridftp
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 2811 -j ACCEPT
# Optional Services
# RLS Server
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 39281 -j ACCEPT
# MyProxy
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 7512 -j ACCEPT
# GSISSH/SSH
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT
# MDS
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 2135 -j ACCEPT
# GIIS
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 2136 -j ACCEPT
# GUMS/VOMS
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 8443 -j ACCEPT
# WebServices
-A RH-Firewall-1-INPUT  -m state --state NEW -p tcp -m tcp --dport 9443 -j ACCEPT

HELP NOTE
Please open the range of Globus Ports according to your Compute Element configuration. Also, if you are using a Scientific Linux variant (SL, SLF, or SLC), then you may have to change RH-Firewall-1-INPUT above to INPUT. Just model the rules after the ones already existing in your iptables file.

Finally restart the firewall as the root user for changes to take effect:

[root@ce /opt/osg-1.2.32]$ /etc/rc.d/init.d/iptables restart
  Flushing firewall rules:                                   [  OK  ]
  Setting chains to policy ACCEPT: filter                    [  OK  ]
  Unloading iptables modules:                                [  OK  ]
  Applying iptables firewall rules:                          [  OK  ]

[root@ce /opt/osg-1.2.32]$ /etc/rc.d/init.d/xinetd reload
  Reloading configuration:                                   [  OK  ] 

Stateful Firewalls

A Stateful Firewall keeps track of the state of network connections. If a TCP connection is closed unexpectedly a stateful firewall will not know that it has been closed. In this case the operating system may allow programs to reuse the port number, but the firewall will not.

To avoid using the same ports too quickly, and hopefully avoid the situation where a stateful firewall will not allow a port to be reused. The Globus Toolkit keeps a record of TCP ports using two files which are defined by two environment variables.

The two variables are defined in /opt/osg-1.2.32/vdt/etc/vdt-local-setup.sh for the Bourne Shell:

# This file is sourced by setup.sh.  Use it for any custom setup for this site.
# This file will be preserved across VDT installations if OLD_VDT_LOCATION is set.

# Set GLOBUS_TCP_PORT_RANGE to define communication ports for inbound connections.
export GLOBUS_TCP_PORT_RANGE=<begin port>,<end port>

# Set GLOBUS_TCP_SOURCE_RANGE to define communication ports for outbound connections.
export GLOBUS_TCP_SOURCE_RANGE=<begin port>,<end port>

# Set GLOBUS_TCP_PORT_RANGE_STATE_FILE to the location where Globus should record
# TCP port usage for outbound connections in case of a stateful firewall.
export GLOBUS_TCP_PORT_RANGE_STATE_FILE=<location on file system>

# Set GLOBUS_TCP_SOURCE_RANGE_STATE_FILE to the location where Globus should record
# TCP port usage for inbound connections in case of a stateful firewall.
export GLOBUS_TCP_SOURCE_RANGE_STATE_FILE=<location on file system>

and for the TC Shell in /opt/osg-1.2.32/vdt/etc/vdt-local-setup.csh :

# This file is sourced by setup.sh.  Use it for any custom setup for this site.
# This file will be preserved across VDT installations if OLD_VDT_LOCATION is set.

# Set GLOBUS_TCP_PORT_RANGE to define communication ports for inbound connections.
setenv GLOBUS_TCP_PORT_RANGE <begin port>,<end port>

# Set GLOBUS_TCP_SOURCE_RANGE to define communication ports for outbound connections.
setenv GLOBUS_TCP_SOURCE_RANGE <begin port>,<end port>

# Set GLOBUS_TCP_PORT_RANGE_STATE_FILE to the location where Globus should record
# TCP port usage for outbound connections in case of a stateful firewall.
setenv GLOBUS_TCP_PORT_RANGE_STATE_FILE <location on file system>

# Set GLOBUS_TCP_SOURCE_RANGE_STATE_FILE to the location where Globus should record
# TCP port usage for inbound connections in case of a stateful firewall.
setenv GLOBUS_TCP_SOURCE_RANGE_STATE_FILE <location on file system>

Additional Steps for Scientific Linux

Scientific Linux uses /etc/hosts.deny to block all connections requests. Please add following lines to /etc/hosts.allow to open access to GridFTP and GRAM:

  /opt/osg-1.2.32/vdt/services/vdt-run-gsiftp.sh : ALL
  /opt/osg-1.2.32/vdt/services/vdt-run-globus-gatekeeper.sh : ALL

Testing and Monitoring

Use telnet to check whether the ports required are accessible on your Compute Element or Storage Element by trying to connect to the respective TCP port from the outside:

[user@ce /opt/osg-1.2.32]$ telnet <the FQDN of the CE or SE> <port number to check>

The port is accessible if you get a response. Otherwise telnet will hang or report a no route to host error.

If you configured iptables to log events, you should be able to see blocked events by inspecting /var/log/messages.

References

  1. Globus Firewall Settings
  2. Condor Firewall Settings
  3. Wikipedia Article on Firewalls
  4. Wikipedia Article on IPTables
  5. Wikipedia Article on Stateful Firewalls

Comments

Topic revision: r55 - 15 Feb 2012 - 21:00:06 - KyleGross
Hello, TWikiGuest
Register

Introduction

Installation and Update Tools

Clients

Compute Element

Storage Element

Other Site Services

VO Management

Software and Caches

Central OSG Services

Additional Information

Community
linkedin-favicon_v3.icoLinkedIn
FaceBook_32x32.png Facebook
campfire-logo.jpgChat
 
TWIKI.NET

TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..