##(see the SpecSpec for an explanation)

''Please check the status of this specification in Launchpad before editing it.  If it is Approved, contact the Assignee or another knowledgeable person before making changes.''

## Register at https://blueprints.launchpad.net/ubuntu/+specs
 * '''Launchpad entry''': none yet
 * '''Packages affected''': 

== Summary ==
This spec defines the Ubuntu Security Core, an Ubuntu meta-package that configures the Ubuntu installation to provide core security monitoring and defenses for a network.

== Rationale ==
Recent participation at the Second National Collegiate CyberDefense Competition has allowed the gathering of much data.  Prominently, the deployment of competent network security solutions requires large amounts of time-consuming effort.  Firewall, intrusion detection, intrusion prevention, scanning, and patch management services take time to set up and manage, and provide hurdles for new users learning them. We should supply a network monitoring and defense solution with installation and configuration complexity on par with modern Web-based content management systems.

== Use cases ==
There are several.

 * Delta Software, LLC, realizes their network needs some security infrastructure.  They set up a gateway cluster consisting of a cut-through firewall and span (forward all traffic to an IDS monitor); an IDS monitor running Snort; and a management console performing whole network monitoring including system logs, patch levels, and IDS alerts.
 * Keybuk has directly connected his machine to the Internet.  To assure a high level of security, he installs a skeletal Xen manager with a firewall/NAT/IPS Dom-U connected to the Internet; his Desktop Dom-U connected to that as the default gateway; and the Dom-0 controller using GDM Chooser to log into the Desktop.
 * Alice needs to create high-security militarized zones within her company's intranet.  She installs border routers for these networks which use the Ubuntu Security Core to provide intrusion detection, prevention, and monitoring; patch management; network auditing; and tunnel-mode IPSec between these networks.  A router attached directly to the company border router acts as a perimeter firewall and IDS/IPS, as well as a tunnel exit for IPSec to route the decrypted packets past the internal network and out through the Internet or across another tunnel link to another site.


== Scope ==
The initial scope includes several essentials:

 * '''Intrusion Detection Software'''
   * ''[[http://www.snort.org|Snort]]'' - Network analysis and intrusion detection
   * ''samhain'' - File comparison software, like Tripwire
   * ''libsafe'' - Can log to Prelude
 * '''Intrusion Prevention Software'''
   * ''libsafe'' - Anti-exploit library
 * '''Auditing Software'''
   * ''Nessus'' - Security scanner.
   * ''nmap'' - Network service scanner.

Also consider major monitoring systems that overlap:

 * ''[[http://www.prelude-ids.org/|Prelude]]'' - Full log management suite, including Snort IDS logs
   * ''[[http://www.prelude-ids.org/|Prelude-LML]]'' - Prelude log analyzer for system logs like IIS, apache, `/var/log/secure`, etc.
   * ''[[http://www.prelude-ids.org/|Prewikka]]'' - Prelude front-end
   * ''[[http://www.wallinfire.net/files/brouette-doc.html|Brouette]]'' - Prelude event collector you can theme (http://www.gscore.org/blog/index.php/post/2007/03/27/New-brouette-theme)
 * ''[[http://www.ossec.net/|OSSEC-HIDS]]'' - Host Intrusion Detection/log analyzer
   * ''OSSEC-BASE'' - OSSEC can interact with BASE to monitor Snort.
 * ''[[http://www.ossim.net|OSSIM]]'' - Another Prelude/OSSEC type job, brings together a whole bunch of software.
   * ''OSSIM-BASE'' - OSSIM can interact with patched BASE as well.
 * ''BASE'' - Basic Snort monitor console

An administrator should be able to install and use all tools easily.  Consider, Prelude, Prewikka, and OSSEC-BASE, which require manual database population et al; compared to content management systems like Joomla or a Snort monitor program like BASE that walks you through.

Prelude is a standard, recognized by several books (http://books.google.com/books?q=prelude+ids&btnG=Search+Books&as_brr=0) and is the most advanced IDMEF IDS (http://tools.ietf.org/rfc/rfc4765.txt) compliant. It also has commercial support.

OSSEC-HIDS, according to Linuxworld, has also gained [[http://www.linuxworld.com/news/2007/031207-top-5-security.html|acceptance in the enterprise]].

OSSIM has an interesting correlation engine that relates attacks and vulnerability scans to prioritize alerts; and also monitors host behavior to determine probability of compromise.

== Design ==
The system should include the above basic scope elements.  A guided configuration program should allow easy addition of given software and rapid configuration.

No assumptions on other functions of the system should occur; Web applications, for example, should use separate VirtualHost configurations in separate files, included from the main Apache configuration.

== Implementation ==
Implementation should interact with upstream as much as possible.  Either give priority to writing code in such a way as to improve the products rather than tack on hackish configuration scripts; or work with upstream and have them do some of the code as well.  Consider the following:

 * ''Prelude-IDS'' uses [[http://www.prelude-ids.org/IMG/txt/rfc4765.txt|Intrusion Detection Message Exchange Format]].
   * ''Snort'' can act as a ''Prelude-IDS'' sensor, sending IDMEF to `prelude-manager`
   * Other systems should implement an IDMEF service; this would extend OSSIM or OSSEC well.
 * ''Prelude-IDS'', ''OSSEC'', and ''OSSIM'' can take effort to install.  ''BASE'' behaves somewhat nicer.
   * Consider ''drupal'', ''joomla'', ''xoops'', and ''CMS Made Simple'' content management systems
   * Consider as well that these tools want to know where files and a database reside, and how these tools could provide as easy installation and configuration as a CMS
   * Do not implement simple configuration utilities; instead, actually fix the tools themselves and send the patches upstream.
 * Integration could use a boost.
   * Two of these products (''OSSEC'' and ''OSSIM'') integrate with ''BASE''
   * Each of these comes with its own patch to ''BASE''
   * Each also comes with a piece of SQL to modify the MySQL database schema ''BASE'' uses
   * If at all possible, get rid of this crap.  Come up with some way to wave a magic stick around and have each of these integrate directly with ''BASE'' with no modification.  This should involve the ''BASE'' codebase allowing embedding of ''BASE'' for a UI and configuration; and extraction of alerts from ''BASE'' using IDMEF (XML-based) through some PHP script.

=== Code ===

=== Data preservation and migration ===

== Unresolved issues ==
 * Some of the stuff here is hard to set up for new users, even when they understand the concepts.

== BoF agenda and discussion ==
 * Try setting up a system on your network within scope.  ''Prewikka'' will probably stop you; the rest you can do, but I bet it'll take you a good chunk of time. --JohnMoser

=== Root Concepts ===
The root concept of this spec comes from experience at the Second Regional Collegiate CyberDefense Competition.  In this scenario, we were exposed to heavy attack on vulnerable operating systems and services of questionable initial configuration.  During this attack, management continuously injected short-term business tasks such as installing bugzilla, adding users, or configuring SugarCRM and migrating 4000 osCommerce users to it as customers.

Initial plans included utilizing ''snort'' on an `iptables` firewall.  The firewall blocked all non-essential services from the outside as well as non-essential internal communication.  The IDS gathered attack information from internal and external traffic making it through the firewall.

We found that configuring and installing ''snort'' takes a long time.  Building in the IPS module proves difficult; tuning and rewriting rules consumes large amounts of time.  Combined, we can't do it in three 8-hour work days.

Configuring a management console proves extremely difficult.  ''BASE'' does not work without ''snort'' MySQL logs.  ''Prelude-IDS'' would work as a log monitor, if any of us knew how to configure it.  No quick install for ''Prelude-IDS'' seems to exist; although a careful reader can easily digest the instructions, a good hour of reading goes into configuring ''Prelude-IDS''.  High level concepts such as creating an X.509 signed certificate; installing the ''prelude-lml'' sensor; or configuring ''snort'' as a ''Prelude-IDS'' sensor translate to low-level commands and manual configuration.

The `/var/log/secure` log file exposed several attacks; `/var/log/cron` exposed a back door using ''netcat''.  Careful analysis of `/etc/passwd` and `/etc/shadow` exposed two extra root accounts with passwords.  Locating the exact path to the ''cron'' script proved extremely difficult; `/etc/crontab` did not mention `/var/spool/cron.d/`.  A combination of ''prelude-lml'' log auditing and a security baseline analysis tool to list `cron` script, additional root accounts, and the like on a given machine would have helped tremendously.

Based on these results, we can make the following conclusions:

 * Installing an IDS and monitor software need to be easier.
 * Firewall rules depend on the firewall software used.  Generally raw `iptables` works for those competent to write good `iptables` policy; however, a visual interface would help.
 * Firewall - There is no port "http" on my machine.  I don't care that you think I'm blocking all traffic to 10.10.0.0/24 on port rvs-rp-bnd; I have 6 rules that look exactly like that minus the port number, which I can't see in any of them.  It's nice to know, but note it next to the number instead.
   * To get around this, `iptables-save > tmpfile`, edit `tmpfile`, `iptables-restore < tmpfile`.  Much better than vanilla `iptables` commands.
 * '''Log monitoring is essential'''.  It does no good to sniff network traffic in ''snort'' when someone has guessed your root password or installed a secondary root account; ''ssh'' looks like ''ssh''.  ''Prelude-IDS'' sensor ''prelude-lml'' performs a critical system function; `cat` and `grep` do the same, but only if you have 3 orders of magnitude more free time on your hands.  '''Hint:  You don't.'''
 * Separate privileged and non-privileged tasks.  If a monitor and administration package can, say, update Firewall configuration, push Patches, and monitor IDS logs; then make sure monitoring IDS logs has its own clearly isolated section.  If your server sits in an insecure network, ''disable'' all privileged functions ('''Hint:  One-button, and Firewall Config/Push Patches/Add Users type functionality goes away, all stored credentials for those functions gets erased''').  If an attacker compromises your administration machine, they will not have to log in; they will have to inject some code into the administration tool (likely in PHP or Python) to give them admin for free, and with it free use of all your stored passwords whether they know how to get and use the encryption key or not.
 * Baseline and auditing:  Critical.  When you detect a compromise, you need to compare your system with a good state.  If you can list all files that were recently changed, guess what?  You probably now know what to compare!

=== Extra Software ===
Further scope should include more, mostly stuff that no one wrote yet:

 * '''Intrusion Detection Software'''
   *  ''checksecurity'' or ''tiger'' - Analyse the local system for known security issues
   *  ''tripwire'', ''aide'' or ''samhain'' - Detect unauthorise changes in the a system through use of hashes of files
   *  ''libsmashlog'' - Replace `__stack_chk_fail()` (via LD_PRELOAD) to execute analysis regarding what address `RETADDR` indicates and what symbol it came from.  Log the results by acting as a Prelude sensor.
   * ''libfsaudit'' - Audit file system calls.
 * '''Intrusion Prevention Software'''
   * ''Snort'' - The snort-inline module needs to compile as a removable component.  Someone needs to update this so it doesn't need a non-standard, deprecated library and can work with current `iptables` again.  Also it should allow drop rules based on severity levels, rather than the DROP keyword; if a rule has the maximum priority, for example, ''snort'' should allow us to have matching packets dropped without a DROP keyword in the rule.
   * ''libmprotect'' - ''mprotect()'' state enforcer.  Prevents `PROT_WRITE|PROT_EXEC` mappings; optionally blocks `!(prot & PROT_EXEC)` to `prot & PROT_EXEC` transitions.  Modeled after PaX but in a flimsy, tacked-on approach instead.
   * ''libvmfragment'' - `malloc()` and `mmap()` half-randomizer.  Track five `mmap()` segments between 1 and 4096 pages, and five `malloc()` objects of between 256 and 524288 bytes.  Pseudo-randomize their creation and size; when a pseudo-random number falls within a given range, create a new segment of some random size.  If more than 5 such segments exist for that call (`mmap()` or `malloc()`), destroy a random one, condense the list, and place the new one at the front as the newest one.  This will fuzz over the `mmap()` and `malloc()` addresses to a slight degree, with increasing entropy as the program executes (''the entropy comes from time; you don't know how many such calls the program made during a given time interval, even if you know the random seed and PRNG algorithm'').

----
CategorySpec