#328 - Firewall Holes Procedural Automation

Evaluate and implement a very simple mechanism to automate the annual audit and renewal of user requested firewall holes. Currently there is procedural documentation to follow, but it would be better to at least drive some of this automatically. This could be as simple as just setting reminders on the RT tickets associated with the holes that inform the necessary users that a positive step is required to perpetuate the firewall holes. There may be other things we can do cheaply to automate some of the manual procedure.

The current situation

  • There are around 190 profiles with the ipfilter.h header
    • Of these, 90 are either self-managed or DICE machines allocated to users who have requested firewall hole(s). These firewall holes are reviewed by US.
    • The remainder include servers, CO machines, printers. These firewall holes are not reviewed by US.
  • We have a daily email reminder of all firewall holes of the format:

    • 8000 (8000/tcp)
      • abc.inf.ed.ac.uk  :*allocated to*:IF-2.48:*managed by*:sl6_64:RT#1234
      • def.inf.ed.ac.uk  :*noAlloc*:*noLoc*:managed by:*noOs*:RT#4567
      • other.inf.ed.ac.uk  :*allocated to*:IF-2.48:*managed by*:sl6_64:RT#3456
      • blah.inf.ed.ac.uk  :*noAlloc*:*noLoc*:support-team:*noOs*:*noRT*
    • 8000to8005 (8000:8005/tcp)
      • next.inf.ed.ac.uk  noAlloc:JCMB-1305:*managed by*:sl6_64:*noRT*

  • US run and review regular ESISS scans on any self-managed machine with firewall hole(s).


  • Triggers to notify when user-requested firewall hole(s) are due to be reviewed.
    • (Should this extend to all firewall holes ?)
  • Means of recording that the review has taken place.
  • Means of recording that any appropriate action has been taken.
  • Means of ensuring that we have the correct contact details for self-managed machines.

Possible solutions

Whichever solution is chosen, some manual updating of profiles and/or RT tickets will be required but we want to keep this to a minimum..

  • Each request for a firewall hole should have an RT ticket so add a reminder to them.
    • It's simple to add a reminder to an RT ticket but this would be a manual process.
    • Our current RT configuration does not send out an email reminder close to the reminder date but it can easily be configured to do so.
    • Would recommend a new queue in RT for the sole purpose of tracking firewall audits.
    • Would want to edit the 'Reminder' search to only show reminders with a due date in the next week. (Otherwise, whoever is responsible for the 90 US machines would see 90 reminders at once.)
    • (Do we have a never-ending RT ticket for each machine with a firewall hole or create a new one each year and reference the previous year ?)

  • Amend the iptables component and subsequent emails
    • Add a 'review_date' resource to the ipfilter component
    • Create additional email reminders sent on the basis of 'review_date' to prompt US about self-managed firewall hole reviews. Could be expanded for all Units ?

  • Combination of the above
    • On the basis of 'review_date', automatically create an RT ticket in a 'firewall' queue.
    • Subject would show machine name and review date.
    • This would create a new RT ticket each year for each machine.

Points agreed at Development Meeting, 05/08/2015

  • One person should be responsible for ALL holes on a machine even if the machine has a number of firewall holes requested by different people.
    • There will be a few edge cases that will require manual intervention (e.g. demos server).
  • The review should be at machine (rather than firewall hole) level.
  • Should have a dedicated ipfilter queue in RT.
  • ipfilter should pull firewall holes automatically after some grace period beyond the review date with reminder sent to RT (copied to requestor and support).
  • Use an RT scrip and automate putting firewall requests into dedicated queue and setting next reminder dates.
  • Keep one ticket open in dedicated queue per machine.

Thoughts subsequent to Development Meeting

  • Not entirely convinced about keeping a dedicated ticket open per machine. Once the review and any necessary actions have taken place, the ticket should be closed so that it is easier to spot reviews which still require action.
  • The 'annual' ticket will contain reference to the originating RT request(s).

Progress to date

  • An 'iptables' queue has been set up in RT
  • An additional resource - reviewDate - has been added to the ipfilter component (thanks to George).
  • A general tidy up (where possible) of machine allocations!
  • A script, run daily, which extracts ipfilter information to a comma-separated file, including ReviewDate on a Unit basis.
    • The US unit list includes every machine with a firewall hole excluding machines allocated to RAT, Services, Inf and MPU i.e. it includes US managed and all self-managed machines.
    • The breakdown of machines with firewall holes:
      • Support - 87
      • Services - 67
      • RAT - 40
      • Inf - 38
      • MPU - 22
      • Total - 254
  • A script which subsequently runs (on a Unit basis) to create an RT ticket in the ipfilters queue. It includes links to any RT numbers referenced in the machines profile.
  • A script which can email Units any changes made - run daily.

-- AlisonDownie - 29 Jul 2015

Edit | Attach | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r16 - 18 May 2020 - 15:00:29 - 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