The CERN Outer Perimeter Firewall

In order to protect devices connected to the CERN network from the regular attacks initiated from off-site, incoming connections to all CERN devices are blocked in the CERN outer perimeter firewall by default. In addition, client ports 0-1024/TCP and 0-1023/UDP (except 500/UDP) are blocked by default for outging connections. Thus, users can initiate client applications (on so-called higher ports) but not expose server processes.

The firewall hardware is maintained by the CERN/IT network group, while the configuration is maintained by the Computer Security Team.

Requesting Firewall Openings

In the exceptional case that a server needs to be directly exposed to the Internet, there are three ways for requesting firewall openings:

  • Via the Network Connection Request Form: Select "update", scroll down to the part called "Central Firewall Configuration" and click on "Make Firewall Request";
  • Use so-called LANDB sets, where the firewall has static openings for this LANDB set. Each set must be homogeneous and used for production, with one or more servers in its final and secure configuration. Usually, sets are used for redudancy or large, homogeneous services. These sets are either managed by the Computer Security Team or by the service managers themselves. Contact to figure out whether your device is eligible (or not);
  • For Openstack VMs or any puppet managed host, please follow the specific documentation;
  • Make a special request: For special request like e.g. for having IPsec opened, contact

Security Requirements

In any case, the corresponding device needs to meet a number of security requirements:

  • The service must be unique and not be covered by central IT services. For example, consider using the central CERN Webservice instead of setting up your own Web server to host Web sites or Web applications. This will allow you delegating the responsibility for maintaining a secure configuration, timely patching, proper back-ups, intrusion detection, etc. to the IT department;
  • The service must have a justified case of professional need. SSH servers and control system servers will generally not be authorized. Instead, please use the standard means for remotely connecting to CERN;
  • The device must be ready for production and configured according to the relevant Security Baselines. The latter requires that software updates will be applied automatically, that all non-essential network services are disabled;
  • In particular, the system must have proper logging enabled, recording remote actions, their origin and precise time. For example, for web accesses this means logging the time (UTC or GVA timestamp), the source IP address, the full URI and if relevant the logged-in user. Such logs should be pushed into central logging infrastructure, for example through the IT Monitoring service or the Computer Security Team's infrastructure.

Finally, the corresponding device must pass the standard vulnerability scan. Requests for Web services, i.e. HTTP/HTTPS, must also pass a Web application scan. For either, you will be asked to stop the local firewall (e.g. using /sbin/service iptables stop for most Linux systems). After the scan, you will receive a scan report and be asked to fix any potential vulnerabilities and other problems found. Only devices which have successfully passed the scan(s) will be granted the requested opening.

Regular Checks

Automatic tools are regularly checking whether your opening is actually used, i.e. whether

  • there is (still) a service listening on the open port;
  • there has been traffic observed recently contacting that open port.

For homogeneous LANDB sets, it is sufficient that one of its members fulfils the aforementioned criteria (as we assume that this is a homogeneous load-balanced set with fall-back servers).

In case the opening does not seem to be used anymore, notification emails will be sent to the main user and person responsible of the corresponding device or set.