DICE development projects - 5_Completed

User accessible login reports

boss — Fri, 25 Jan 2013 15:46:26 +0000

Project ID:

254

Current stage:

5_Completed

Manager:

squinney

Unit:

mp-unit

What:

Description:

The recent development of a database to store interesting events that have been filtered out from the centrally-stored syslog files means that it is now relatively straightforward to generate reports of logins for our users.

The aim of this project is to produce a mechanism (eg individual email reports, cosign-protected web page) for users to see from which remote machines their account has been accessed - including ssh and weblogin logins.

Deliverables: A working mechanism.

Why:

Customer: All users

Case statement: Recent evidence shows us that compromised accounts are a serious, and not infrequent, threat to the integrity of our computing systems.

When an account has been compromised, an attacker will often log on to systems accessible by that account to check for any local root exploits. If there are no current root exploits on those systems, the attacker will quietly logoff and keep the account details for a future attempt.

Providing a mechanism by which users could see from which external machine their account was accessed would allow users to spot suspicious activity on their account, hopefully before any malicious damage is done.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: Two weeks

Plan:

The simplest approach to providing access to this information for our users is to create a cosign-protected CGI script. This would use SQL to securely query the data stored in the buzzsaw database stored on the central log server.

The intention is to write this script using the python programming language. This provides the opportunity to gain valuable experience with an alternative programming language. This clearly means that the project will take longer but that has been factored into the effort allocation.

The web interface does not need to be complicated but will ideally have facilities to allowing basic paging (e.g. month by month) and sorting of the data (e.g. by date, source host, target host).

Separation of the query code from the presentation by using a templating system is preferable to make it easier to modify the interface in the future.

Along with the web interface we will send an email to each user every month summarising all the logins from the previous month. This means that all users will be encouraged to check their login history regularly.

Effort taken (days):

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport254

Other:

Dependencies:

Risks:

Milestones

Achieved date	Name	Description
2012-11-23	sql	Develop the python code to do the necessary SQL queries against the buzzsaw database.
2012-11-30	cgi	Develop a cosign-protected cgi script which will use the sql query functions to find a list of logins for the user.
2012-12-14	presentation	Develop a web interface using a templating system to present the data to the user in a reasonable format with basic paging and sorting functionality.
2012-12-21	email	Develop a system to send an email to each user every month which summarises their login activity.

Documentation update - infrastructure unit

boss — Fri, 25 Jan 2013 15:46:25 +0000

Project ID:

250

Current stage:

5_Completed

Manager:

gdmr

Unit:

inf-unit

What:

Description: Review and update end-user documentation. Includes porting across any remaining documentation not already on new drupal based site.

Deliverables:

Why:

Customer:

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 2 weeks effort

Plan:

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport250

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Migrate all VMware guests to KVM service

boss — Fri, 25 Jan 2013 15:46:25 +0000

Project ID:

251

Current stage:

5_Completed

Manager:

ascobie

Unit:

mp-unit

Summary:

Migrate all VMware guests to KVM service

What:

Description: Migrate all VMware guests to KVM service. Project created just to track progress (at development meetings).

Deliverables:

Why:

Customer:

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Increasing Energy Savings from DICE Desktops

boss — Fri, 25 Jan 2013 15:46:22 +0000

Project ID:

234

Current stage:

5_Completed

Manager:

Unit:

mp-unit

What:

Description: This project aims to assess and if necessary improve the effectiveness of energy-saving measures on DICE desktops. It builds on project 94 which delivered the LCFG sleep component.

Deliverables: A data feed of statistics showing the sleep rates of DICE desktops; possible improvements in the LCFG sleep component; possible improvements in the energy-saving guidance given to users of DICE desktops

Why:

Customer: The School of Informatics and the University of Edinburgh should benefit from lower energy bills and a lower environmental impact.

Case statement: For some years the DICE desktops in the student labs have used energy-saving sleep software, the LCFG sleep component, which was developed in project 94. More recently the sleep component was also installed on staff and postgrad DICE desktops. We should now follow up on this work by finding out how successful it has been and what might be done to increase the energy savings. The project would start by collecting statistics from
machines to see how much of the time they are asleep - in other words
trying to understand how much of a contribution that sleep might be
making to energy saving. Depending on what the statistics say, some
changes to the LCFG sleep component could be made or users could be informed
about how to get their machines to sleep.

Gathering the statistics should be straightforward as machines running the sleep component currently log when they enter and exit from a sleep state. The statistics could be made available not just for this project but also for other purposes. For instance it may well be useful and interesting to use them to produce periodic graphs of desktop sleep rates, or to calculate monetary savings.

There is at least one obvious change which could be made to the sleep component: it currently lacks a way to find out the idleness of a machine's keyboard and mouse. This means that the sleep component has been conservatively configured to avoid suspending any machine which has an X session in progress. Adding such a capability, and safely sleeping idle machines running a user X session, could be a way to increase machine sleep substantially.

As for explanations for users, we already have some blog posts and a page of guidance for DICE desktop users on machine sleep but this could be expanded and made more detailed if necessary. It could perhaps also be publicised more widely from time to time.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: Estimate of 2 weeks effort, and temporary use of a few DICE desktop machines.

Plan:

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport234

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Windows 7 upgrade

boss — Fri, 25 Jan 2013 15:46:21 +0000

Project ID:

229

Current stage:

5_Completed

Manager:

alisond

Unit:

compexec

What:

Description: All our Managed Desktops need to be upgraded to Windows 7.

Deliverables: Upgrade to all current MDP machines to Windows 7 along with training for CSOs and end-users.

Why:

Customer: All our MDP users

Case statement:

When:

Status:

Timescales: Dependant on IS, ISS and testing of kerberos and openAFS.

Priority: High

Time:

How:

Proposal:

Resources: This will require some Windows 7 and Office 2010 training.

Plan:

Meeting with IS in early January
Install test machine for kerberos and OpenAFS
Purchase software licenses
Liaise with ISS
Resolve Firefox version issue
Resolve printer installation
Arrange training for CSOs
Identify training for end users
Schedule upgrades with end users

Other:

Dependencies:

IS timetable for updates.
CSO training in installation of MDP (Windows 7) and software
Testing of kerberos and openAFS, including Toby's time.
Purchase of appropriate licenses (Windows 7, Office 2010 and Acrobat)

Risks:

Milestones

Proposed date	Achieved date	Name	Description
2012-01-10	2012-01-15	IS Meeting	To meet with Myles Ewen to discuss implementation and setting up of test machine including advice on how to install kerberos and openAFS.
2012-01-11	2012-01-31	Test Machine	Install test machine to allow us to test kerberos and openAFS
2012-02-29	2012-02-15	software	Test kerberos and openAFS
	2012-03-31	CSO training	Training in MDP installation.
	2012-03-31	ISS Meeting	Meet with ISS to discuss scheduling of upgrades. Dependent on solution for AFS/kerberos.
	2012-03-31	Purchases	Purchase all necessary upgrade licenses.
	2012-03-31	User testing	Ask competent end-user to help test. Dependent on AFS/kerberos solution.
2012-01-20	2012-01-20	List of upgrade	Identify complete list of machine upgrades.
	2012-03-15	Timetable	Create timetable of user upgrades
	2012-04-16	Upgrades	Start upgrades
	2012-03-31	firefox	Work out best options for firefox versions for theon/e-financials. Possibly use Google Chrome ?
	2012-04-30	printers	review way printers are installed - could/should they be IS queues?

System Security Enhancements

boss — Fri, 25 Jan 2013 15:46:20 +0000

Project ID:

224

Current stage:

5_Completed

Manager:

squinney

Unit:

mp-unit

What:

Description: This project will enhance the security of our systems in various ways based on the proposals made in the report into the compromise of the SSH servers.

Deliverables: More secure DICE infrastructure.

Why:

Customer: Internal.

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

The expectation is that all of the "main aims" will be completed within the time allotted. If there is spare time then work will be done on the "other possibilities" section of the project.

Resources: 4 weeks effort.

Plan:

Main Aims

System Auditing:
We should enable the Linux audit daemon on all DICE machines with a reasonable set of default rules. This will, for instance, make it possible to trace all modifications to important parts of the filesystem and monitor the execution of setuid root files. For important servers we would also like to have a facility to securely send the audit logs to a remote central server.
Enhance logging and automate the log monitoring:
In particular we need to automatically monitor the syslogs for all DICE systems to spot events, such as kernel panics, which might indicate attempts by a user to leverage a local security hole.
Regularly monitor the file-system:

It is clear that we need to monitor the file-system of our servers for unauthorized changes. In particular we should monitor:
1. All setuid root scripts which are runnable by other users.
2. All files which are not owned by RPMs
3. Important directories such as /etc/.
Some of this can be done using the Linux audit daemon but it would be good to have additional coverage. This can be done with intrusion-detection software such as AIDE (Advanced Intrusion
Detection Environment) which is a file and directory integrity checker.
Regularly sweep for root-kits:

We should regularly run software to check for the evidence of root-kits having been installed, e.g. chkrootkit and rkhunter. In particular, running more than one check would denitely be useful as they function quite differently.
Bootable image for investigations:
Develop a bootable ISO which can be used to carry out investigations on suspect machines. This would be based on our standard installroot image with additional packages, such as chkrootkit and rkhunter, which are useful to have readily available. This could be made available via CD, USB and PXE. There is also a need for a read-only filesystem (in our case delivered via AFS) for running scripts such as chkrootkit which use a number of separate tools which could be subverted if they are coming from the local disk.

Other Possibilities

Use SELinux:

We do not currently use the SELinux framework which would almost certainly have prevented this intrusion occurring. To run it in full "strict" mode might require a great deal of effort to make it work with LCFG. However, it should be possible to get a lot of
the benefits whilst using the lesser "targetted" mode, which is the standard for Redhat systems. It is denitely worth some further investigation.
Shared database for failed logins:

We should investigate whether it is possible to create a database of failed logins which is shared across all DICE machines with external SSH access. This could be used to
automatically block all SSH access for hosts which are attacking our systems.
SSH Honeypot:

We could use an SSH honeypot which has an SSH firewall hole but which cannot actually be accessed by any users due to restrictions in the SSH daemon config and the
access.conf file. The location of this service would not be advertised to our users so it
would only be found by attackers who are port-scanning our network for targets. This
could then feed into a shared database of banned hosts.

Some parts of the work for this project have already been done or just need some extensions. In particular, the audit daemon work is mostly complete but needs rolling out to all machines.

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport224

Other:

Dependencies:

Risks: We get hacked again...

Milestones

Proposed date	Achieved date	Name	Description
	2012-06-16	3. Monitor fs	File-system intrusion monitoring
2012-09-30	2012-06-30	4. Check for ro	Regularly sweep for root-kits
	2012-07-30	6. SELinux	Consider using SELinux
	2012-07-16	5. ISO	Develop a bootable image for investigations.
	2012-08-30	7	Consider using a shared database for failed logins
2012-08-17	2012-05-31	1. Log Checking	Enhance logging and automate log monitoring.
2012-06-18	2012-05-31	0. Auditing	System Auditing

KDC upgrade to 1.9

boss — Fri, 25 Jan 2013 15:46:20 +0000

Project ID:

223

Current stage:

5_Completed

Manager:

gdmr

Unit:

inf-unit

What:

Description: Test kerberos version 1.9.x KDCs. Add any additional configuration hooks required. Upgrade the INF and IFRIEND KDCs.

Deliverables: Version 1.9.x KDCs. Ideally add password strength checks.

Why:

Customer: All

Case statement: There are two drivers for this:

The version of kerberos that comes with SL6 is 1.9.something, so we would have to do this work anyway
We would like to use the additional "pwqual" plugin to enhance our password strength checks

When:

Status:

Timescales: Best to allow three weeks for thorough testing, master-side in particular.

Priority: Required as part of the inf-unit's SL6 upgrade path.

Time:

How:

Proposal:

Resources:

Plan: Slave-side should be reasonably straightforward. Master-side will require a test realm to be set up. Phasing into service should be done cautiously.

Other:

Dependencies: This project doesn't depend on anything else. Lots of things do depend on it.

Risks: We have to make this work if we are to be able to upgrade the KDCs to SL6. OTOH there's no reason to expect that there'll be any real problem. However, BEWARE of breaking AFS, as it still requires single-DES keys.

URL: http://www.dice.inf.ed.ac.uk/units/infrastructure/Projects/168-PWstrengt...

Milestones

Proposed date	Achieved date	Name	Description

Wake-on-LAN

boss — Fri, 25 Jan 2013 15:46:18 +0000

Project ID:

213

Current stage:

5_Completed

Manager:

Unit:

mp-unit

What:

Description: Implement a wake-on-LAN system

Deliverables: A wake-on-LAN system

Why:

Customer: Anyone with a machine which might be put to sleep

Case statement: We've had a few queries now about wake-on-LAN, the implication being that folk would be happier to have their machines sleep if they could have a way to wake them up as needed.

When:

Status: Delivered. The service can be found here.

Timescales: Putting together a cgi-bin script would probably only take a week or so. Testing and ironing out any platform- and machine-specific quirks might take another couple of weeks. There might be another week or so of Support effort to add the necessary entri

Priority: High priority.

Time:

How:

Proposal:

Resources: The system would probably run on the network infrastructure machines, or perhaps the network services machines if that's easier, so no additional kit would be needed.

Plan: The netinf machines are on all the right subnets and already have "all" machines' MAC addresses through the dhcpd resources. The idea would be to provide a cgi-bin script which would look up the MAC address and call some piece of code (externally-sourced or locally-written) to send the magic packet.

To be accessible from outside, there would need to be cosign-protected https access to the cgi-bin. If this conflicted with the need to have simple http access to the netmon pages for DR purposes then the system might be better run on the network services machines than the network infrastructure machines, but that's something to determine at the time.

Alternatively, hook into the central IS-provided system. There are issues with configuration-data transfer and directed broadcasts which make this appear rather more expensive and less flexible than doing it ourselves.

Other:

Dependencies: Given that not all machines sleep/wake properly, there might need to be some kind of (spanning-map based?) configuration by machine type. Since ?most self-managed machines don't currently have a machine-type entry in their profiles, for this to be done reliably could require some Support effort.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

SL6 RAT packages

boss — Fri, 25 Jan 2013 15:46:17 +0000

Project ID:

211

Current stage:

5_Completed

Manager:

roger

Unit:

rat-unit

What:

Description: This project should port the current F13 rat package lists to SL6 whilst trying to identify old and unused packages and updating versions where appropriate.

Deliverables: a full set of software for supporting teaching and research within informatics.

Why:

Customer: The school

Case statement:

When:

Status:

Timescales:

Priority:

Time: A significant amount of effort was expended in gathering requirements, porting, and getting feedback. Hopefully this will be lessened if/when a more formal requirements-gathering framework is in place.

How:

Proposal:

Resources:

Plan: A significant amount of consultation with Course Organisers and Teaching Assistants will be required to determine what software is required and what is redundant. Consultation will be organised in two phases, for Semester 1 and Semester 2. Each phase will involve establishing current and required versions, checking for local (or other) SRPM, and using pkgforge to build each package.

Once built, packages will be added to packages list (lcfg/core/packages/dice/dice_sl6_rat.rpms) and tested - first on testsl6.inf (locatelli), and then rolled out to lab and desktop machines.

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport211

Other:

Dependencies:

Risks: We now have a more accurate list of teaching software requirements (having weeded-out the dead wood), and the equivalent process next year should be quicker. However, if the Software Requirements framework isn't implemented, we will continue to have late requests which cause additional work.

Milestones

Proposed date	Achieved date	Name	Description

Sl6 Dice desktop

boss — Fri, 25 Jan 2013 15:46:17 +0000

Project ID:

210

Current stage:

5_Completed

Manager:

iainr

Unit:

rat-unit

What:

Description: additional work required to bring LCFG SL6(inf) (#131) up to working DICE desktop

Deliverables: components and configuration to bring the sl6 inf release up to DICE standard.

Why:

Customer: The primary customer is the School of Informatics. Other schools may take some of the software/components or modify it fortheir own use.

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 6 weeks base on the sl5->f13 port

Plan:

Other:

Dependencies:

Risks:

URL: https://wiki.inf.ed.ac.uk/DICE/SL6DICEDesktop

Milestones

Proposed date	Achieved date	Name	Description
2011-06-01	2011-06-01	command line	get the base command line config in place
	2011-06-20	X tweaks	Finalise any DICE tweaks of the X system in place
	2011-06-14	tweaked command	tweak the command line environment for SL6
	2011-06-08	X Environment	Configure Base X Environment for use in SL6
	2011-07-01	core env packag	Have all core env packages in place
	2011-07-08	signoff	submit project for signoff