• InfrastructureReDesign

As we plan to move Infrastructure services to a new Hosting provider its a fair time to re-evaluate the design. Currently these are only ideas, tbd.

Requirements

Deficiencies with current design

1. multiple ssh hops causing latency and configuration pain for a few admins
2. firewall configuration out of control of local admins
3. lack of centralised account management making it a bit labouring to remove/add admins
4. lack of centralised configuration making standard configurations on ssh/web service/logging options difficult to acheive/maintain
5. lack of configuration history on services/machines
6. lack of a clear tested backup that is available to local admins
7. logging checked for abnormal events
8. monitoring of systems for expected statue
9. email standards - defined email address, dkim signing
10. bandwidth accounting /montoring isn't done - needs to be kept in check

Security Requirements

Be guided by SM

1. indications when package updates are required
2. restrictive firewall rules in and out
3. strong authentication for admins to access services)
4. strong identity associated with logins (no shared or root accounts)
5. logging with strong integrity
6. file modification detection

Easy of Maintainence Requirements

1. preference for distribution maintained packages
2. non-distribution packages need some approval process
3. formation of templates for commonly deployed tasks
4. easier integration of application maintainers

Design

Proposed Solutions

There are multiple ways to achieve some of these requirements - lets look at them.

Deficiencies

1. multiple ssh hops:
   1. direct ssh access - security requirement mitigated by: standardised config, monitoring
   2. hopper with more open input firewall rules
   3. Single Packet Authentication / Port knocking
2. firewall config:
   1. locally controlled at VM with alerts on rule changes just to be sure they are authorized/consistant with security requirements
3. account management:
   1. LDAP server with shared /home directory exported across all guest VMs (Samba?)
   2. puppet account management
4. standardization:
   1. puppet to manage config in OS independent manner
5. config history:
   1. puppet supports config history?
   2. RCS on critical files
   3. other VC?
6. backup/restoration:
   1. daily lvm snapshots of running hosts
   2. individual backup daemons on hosts - preferences?
   3. better SQL backups
7. logging:
   1. admins commit rules for their system to categorize log messages
   2. centralised logging for integrity. logs readable by local admins
   3. common alert rules for hits on prohibited firewall rules (outbound)
8. monitoring:
   1. local admins place nagios rules to validate system functionality
   2. common rules for monitoring to check only designed listening services are running
9. email standards:
   1. puppet managed
   2. dedicate local VM for emailout
10. bandwidth accounting /monitoring
    1. iptables accounting by IP
    2. specialised log monitoring / webanalyiser/ mailgraph

Security Requirements

1. package updates
   1. cron-apt or similar
   2. monitoring agent detects this
2. restrictive firewall
   1. rules validated by monitoring
   2. rules occasionally tested
3. strong authentication for admins
   1. ssh key access only
4. strong identity associated with logins (no shared or root accounts)
   1. no root logins, sudo access for root access
5. logging with strong integrity
   1. remote log with log directory exported back to machine readonly
6. file modification detection
   1. lvm snapshots are examined for modified files. Excludes distribution updates and logging/database files

Maintainence Requirements

Design

Host OS

1. ssh access to infrastructure sysadmin managers

Common Services

1. puppet
2. ldap/samba share/ kerberos(?)
3. logging alert rules repository
4. monitoring alert rules repository
5. dns cache
6. emailout

7. CategorySystems