Changes between Initial Version and Version 1 of HowTo/ManageCustomImages


Ignore:
Timestamp:
05/13/16 09:28:44 (8 years ago)
Author:
lnevers@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • HowTo/ManageCustomImages

    v1 v1  
     1= Managing Custom Images =
     2
     3Users in GENI have the ability to create image snapshots known as "custom images" this is a feature available to facilitate the running of experiments, but as is usual with any image creation, there are associated administrative task that must take place, such as:
     4 - monitoring security alerts and installing required updates to block security attacks.
     5 - Cleaning up bad, duplicate, or old images on GENI racks. 
     6
     7This page outlines some guidelines on how image maintainers can find when there are new attacks (e.g. Heartbleed) and take appropriate steps. Also covered are maintenance guidelines/procedures for cleaning up obsoleted and bad images.
     8
     9== Security Alert Handling ==
     10
     11GENI Custom Image maintainers should subscribe to appropriate security mailing lists, or get alerts for the Operating Systems used to create the custom images. This function was initially owned by the GPO.  The goal is to have different ways that look for a virus once you know it exists, find a resolution and apply it to the appropriate custom image.
     12
     13=== Security Alerts Sources ===
     14
     15In GENI there are mostly CentOS or Ubuntu image.  Both have mailing security mail lists that maintainers should subscribe to. These lists are very low traffic and fairly easy to digest:
     16
     17 https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
     18
     19 https://lists.centos.org/mailman/listinfo/centos-announce
     20
     21As an example, here are the emails from both Ubuntu and CentOS Security lists regarding the libc vulnerability announced on in February 2016:
     22
     23 https://lists.centos.org/pipermail/centos-announce/2016-February/021668.html
     24
     25 https://lists.ubuntu.com/archives/ubuntu-security-announce/2016-February/003305.html
     26
     27Of note, these emails are only sent '''after''' a fix has been posted. How does one know there is a problem in the first place? If it's a big enough deal, [https://slashdot.org/ slashdot], or other news sites, will cover it.
     28
     29In most cases, the OS vendors release patches the same day as the bug is publicly announced, as they are coordinating amongst themselves and with the upstream developers.  As was the case with this libc bug in February.
     30
     31So how do we confirm we might be effected, if there is no patch immediately available?  There will probably be an article on [https://slashdot.org/ slashdot], or other news outlets.  From there they might link to a vendor's page.
     32
     33Here's an ongoing Vulnerability that you can reference:
     34
     35https://access.redhat.com/security/vulnerabilities/drown 
     36
     37You can click on diagnose and there's a script you can download, to see if you are effected, or maybe some mitigation steps.
     38
     39Once we identify the package, we'll check to see what we have installed and compare it to the effected versions.  Remember there are various factors to consider depending on the bug. Maybe its package specific or perhaps it is OS version specific (CentOS 5 is effected but 6, or Ubuntu 12.04 is affected, but not 14.04). As an example, the libc vulnerability was addressed by different package names. The Ubuntu package is called `libc6`, and the CentOS is called `glibc` and to address the vulerability the following instructions were given:
     40
     41CentOS:
     42
     43 yum info glibc
     44
     45Ubuntu:
     46
     47 dpkg -s lib6
     48
     49
     50
     51