You are here

Self Managed Firewall Hole Policy

By default self-managed machines (or self-managed services running on DICE machines) on the Informatics network can only make their services available within the Informatics network. To make services available to the wider University (EdLAN and/or eduroam) or beyond (to the world) self-managed machine owners will need to apply for a firewall hole. Due to the security risk this creates to our network, machines and users in order to have a firewall opened you will need to make a business case. Your business case will need to explain why the research work or project cannot technically be carried out in other ways (without a firewall hole) and outline the software stack that will be running the service. Your business case will need to be particularly strong in the case of services that will expose a login shell of any kind and/or that will require a firewall hole that exposes the service to the world. All business cases must be submitted by making a support request in the usual way and must be formally approved by the Head of Computing before any firewall hole can be opened. Some things to consider when making your business case are listed below, ensuring you address these in your business case will reduce the subsequent dialog and time for your firewall hole to be formally submitted for approval. Please allow at least two weeks for processing of firewall hole requests. All firewall holes are reviewed annually, any problem identified at review, such as software which is out of date, is likely to result in the immediate closure of the hole until the problem is addressed.

Items to Consider in your Business Case

Not exhaustive and in no particular order.

  • Does the service need to be accessible just to the rest of the University or the entire world
  • Why can the service not be accessed only using either the University or School VPN
  • If not DICE OS, what procedures you will use for keeping the underlying OS up-to-date
  • Procedures you will use for keeping the service software stack up-to-date
  • Procedures for checking and managing urgent security updates
  • Who will be the technical contact for the service and/or management of the underlying OS
  • Who is the business owner of the machine and service
  • Wnat is the nature of the service and software frameworks supporting it
  • How is the software being used sourced - e.g. is it supplied with the OS or obtained from a different repository, how actively is it maintained
  • If any of the software has been locally produced, has it been peer reviewed to check for any security vulnerabilities
  • Will the service be run on non-standard ports
  • What access to the machine (if any) does the service provide
  • Who are the users of the service and if they are a known set of users why can they not use the VPN to connect to the service
  • Kinds of authentication and authorisation that will be in place to protect the service
  • Duration of the project - how long will the firewall hole need to be kept open
  • Can the remote connections be additionally restricted by host, domain or IP address (e.g. are they from known external organisations or users with known address range)
  • Outline what you would do in the case of a breach/hack, what kind of data might be exposed, do you have/need a DPIA
  • Will the access be to one machine or many machines, adding a new machine later with the same configuration may not need a new business case but does increase surface attack area
Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic