Firewall hole procedures

As described in Using the network from outwith the School, our network perimeter is protected by a firewall: in general, all traffic which originates from within our network is permitted, whilst everything originating from outside is blocked. Exemptions to allow incoming traffic from outside are made as necessary, and can be arranged for any user's machine (whether DICE, self-managed, or Windows managed desktop) on request but this needs to be closely managed and monitored for potential security risks. The sections below describe the procedures that User Support have in place for dealing with firewall hole requests, how we perform an annual firewall hole review and how we deal with vulnerabilities identified via the regular scans that we run.

Requests for firewall holes

  • We ensure that an RT ticket is raised to keep an accurate record.
    • Either done by end-user or, if the end-user has emailed us directly, we create an RT ticket on their behalf.
  • Support will make an initial assessment of the request.
    • We will identify the exact purpose of the request if this is not clear from the initial request
    • We will ask the user if any restrictions can be applied e.g. restrict only to EdLAN.
    • We will pass the ticket to RAT for final approval.
    • If approved, support will add the appropriate entries in the machine(s) profile, including the ipfilter.RT resource and add an entry to ipfilter.h where appropriate.
    • We will respond in the RT ticket to advise the user of our scanning procedures (see below under the Firewall Hole Review Procedure).

Annual Firewall Hole Review Procedure

Self Managed Machines and Self Managed Services running on DICE Machines

  • Generate a list of all machine profiles containing ipfilter.h

  • ssh lcfg-master
  • cd /var/rfedata/lcfg/profiles/
  • grep ipfilter.h * > /tmp/firewall_review

  • Check each lcfg profile on the list for open firewall holes. Each open hole will look something like this:

#include <dice/options/ipfilter.h>

!ipfilter.export                    mADD(ssh)

!ipfilter.RT                        mADD(56703)

  • This list can then be compared against the daily "iptables runScripts output" email to identify any machines which acquire firewall holes through other headers. (The email doesn't show the RT number which is an important check).

  • Contact the machine's manager through the RT ticket to verify why they still need the open firewall hole and if so:
    • If the firewall hole is not restricted, check whether it can be, for example, restricted to EdLan
    • If the firewall hole opens a range of ports, check whether this range can be restricted.
    • Relay the following back to the user:
      • We run regular scans to identify vulnerabilities with web applications, unpatched software and configuration weaknesses, all which can pose a significant threat to network security.
      • As a minimum, security updates must be applied.
      • We will contact users when a scan identifies any vulnerabilities and provide them with details including appropriate fixes.
      • Managers of machines must respond in a timely manner when any vulnerability has been identified- usually 2 weeks - as a result of the regular scans that we run. Failure to do so may result in the firewall holes being blocked and the machine taken off the network.
      • If the manager of a self-managed machine changes or the owner of a self-managed service on a DICE machine changes, we must be informed.
      • If the firewall hole relates to resources served via named URL(s):
      • Confirm which URLs are to be hosted.
      • We must be told of additional URLs.

Further notes here: http://computing.help.inf.ed.ac.uk/self-managed-policy

  • If the answer is negative, remove the firewall hole.
  • If there is no response, wait 1 month then comment out the firewall hole rather than removing it.
  • The onus is then on the user to contact support to have the firewall hole re-instated if required. It will remain closed until such contact is made.
  • If the firewall hole can be restricted, the appropriate change to the profile/ipfilter.h should be made.

Note that User Managed Services running on DICE machines are predominantly setup for the user by the Research and Teaching Unit. However, irrespective of Unit, the following procedure must be followed for any firewall holes associated with a user managed service:

  • Every firewall hole must have a corresponding RT ticket set. This ticket must document the owner of the service.

DICE Services

It is the responsibility of the Unit managing a service to regularly review the need and scope for each firewall hole associated with the service. How this is handled is down to each individual unit. However, each firewall hole's LCFG entry must always have an associated comment including at least the responsible Unit or CO (in case of test holes for example), although this need not refer to an RT ticket.

-- RichardBell - 25 Aug 2014

Topic revision: r11 - 21 Jan 2016 - 16:16:34 - AlisonDownie
 
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.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies