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.
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
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:
Prelude - Full log management suite, including Snort IDS logs
Prelude-LML - Prelude log analyzer for system logs like IIS, apache, /var/log/secure, etc.
Prewikka - Prelude front-end
Brouette - Prelude event collector you can theme (http://www.gscore.org/blog/index.php/post/2007/03/27/New-brouette-theme)
OSSEC-HIDS - Host Intrusion Detection/log analyzer
OSSEC-BASE - OSSEC can interact with BASE to monitor Snort.
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 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 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).