These are my raw notes from talks held on Thursday at LCA2014. May contain errors, mis-heard quotes. Also completely un-reviewed or spell checked:
- Interesting security events in 2013:
- UEFI was deployed in production
- Snowden revelations
- Governments involved in sophisticated hacking on domestic populations
- Who are we concerned about
- NSA - complete set of capabilities are unknown, assume the worst.
- Our hosting / service providers
- Opportunistic attackers
- NSA are able to perform attacks undetectable from th eoperating system
- Leaks describe model-specific exploits
- Plausible that vendors are not actively involved
- Passive involvement is likely
- Who would benefit from a generic exploit?
- Intelligence agaencies are probably not our biggest concern
- Most security breaches are political or profit driven
- How can we protect our users?
- Boot verification is an absolute requirement, despite being a vector for freedom infringements
- Operating systems are too big to be perfect
- Persistent infections make recovery impractical
- Users will choose to keep an infected machine rather than have it repaired
- Must be able to replace vendor components
- Especially firmware
- UEFI secure boot still allows users to replace keys
- No guarentees to replace firmware
- Some vendors allow OS replacement
- No way to replace keys or firmware
- Choice between freedom and no security or security and no freedom
- Chromebooks are no better
- Apple are the worst, cant replace OS, keys or firmware
- How much can you trust your system:
- OS backdoors? (not neccessary)
- Firmware backdoors?
- Jetway have not had their leak audited
- Should be a project people engage in
- There are obivous vulnerabilities in the code
- Lower level hacks?
- AMT, CPU microcode
- Attack vector on modern devices is low due to move to cloud services
- If you give your data to someone else, you're trusting them to not steal, share or lose it.
- Spectrum of trust from software you run through to where you store your data.
- Cloud security is poorly understood
- Balance of probability suggests hypervisors have security vulnerabilities
- SELinux / Apparmor allows you to run a VM in an isolated context
- Introspection os bare metal is difficult
- Introspection of VMs is trivial
Security for 2014
- Be more aggressive about securing every layer
- In a way that doesn't compromise freedom
- Ask cloud vendors hard questions
- Customers too
- Don't by into exchanging freedom for security or vice versa
Without verified boot you are insecure. With verified boot you may be insecure.
Rapid OpenStack Deployment for Novices and Experts Alike by Florian Haas
Rough overview of OpenStack Architecture
- OpenStack is the largest community driven cloud architecture
- Keystone is the central identity/location service
- Nova is the compute service that interacts with hypervisors (most of them)
- Glance is the VM image service
- Horizon is the OpenStack dashboard
- All unified API's are RESTful JSON
- Node roles are atomic, composable classes of nodes
- Infrastructure Node runs a database and a message queue (MySQL + RabbitMQ).
- Authentication Node Runs the OpenStack Identifty Service (Keystone) providing authentication
- API Node procides ReSTful endpoints to Openstack services
- Controller node provides scheduling and registraion services internal to OpenStack
- Network Node provides network connectivity within the cloud (Neutron).
- Compute Node(s) hosts and runs VMs (Nova).
- Block Storage Node provides storage (Glance).
- Dashboard Node provides unified user interface (Horizon).
- Metering Node to collect metering data from a unified event stream (Ceilometer).
- Orchestration node runs and orachestration service (Heat).
- Using one node (alice) running all the node services except:
- bob will run computes
- Charlie will be the network node (this would normally have pone interface that is public)
- Puppet node running... a puppet master.
- Stackforge is a collection of puppet modules for OpenStack (and other things).
- KickStack - OpenStack deployment with puppet made easy
Test the puppet architecture:
$ puppet agent --test
Set classes via puppet dashboard to define the node's roles
$ puppet agent --runinterval 10
- Packstack is RedHat's tool and is RDO specific, based on StackForge. Good for all Centos / RHEL OpenStack infrastructure. Not granular enough.
- Crowbar is a DELL project's deployment platform and is used by SuSE (along with Chef)
- Juju is Canonical's deployment tool using a yaml file generated from "charms".
- TripleO/Tusker (OpenStack on OpenStack). Uses Openstack scheduling and deployment for deploying hardware via PXE and IPMI - manage hardware like a VM.
- Foreman "puppet on steroids"
- Presentation tools is reveal.js, shell in a box in an iframe
Horizon: * A good understanding of the architecture is required to effectively troubleshoot * Start in the nova-api logs for an error * Check the scheduler logs * Has it found a suitable host? * available hosts may be out of memory * Not responded * nova list or nova show can you which hypervizor has been selected to run it up * Look at the logs for nova compute on that host.
Should find a clear error in 99% of cases...
Writing your first web app using Python and Flask by Danielle Madeley
- Flask is a lightweight python web framework
- Flask will gracefully finish requests
Debian on AWS by James Bromberger
- AWS is a collection of remote computing services
- Compute, storage etc
- Certification available
- Customers can chose software / operating systems
How is Debian using AWS:
- Distributed Debian packagr compilation on EC2
- Funded by grany
- Helped find bugs in packages
- Helped find bugs in compilers
- Spot Instances allow you to name your own price for EC2, and you get the resources what you pay for - dynamic resource allocation based on market prices
- 12 complete archive rebuilds
- Accelerating ftp.debian.org
- Speed up access for all regions
- Use this in sources.list (or use http.debian.net)
- 24 hours caching for Debian-CD
- Cached in 51 locations
Who's using it?
- DD's mostly
- Looking for people to do stats analysis
- snapshot.debian.org - 18TB of Debian packages 55K of files, 1 Postgres database - every package, ever.
- All files are on S3 with automatic aging to Glacier
- $200/month - donated by AWS
Official Debian images on EC2
- AWS now has officual EC2 AMIs for debian generated by DDs.
- Generation script is on GitHub
- In AWS Marketplace ($0)
- Shared from Debian AWS Account directly
- Available in all regions (including GovCloud)
Creating the Officail AMIs
- Uses build-debian-cloud
- Uses http.debian.net in apt sources
- resizes root file system if larger than default (8G)
- Cloud-init is installed in the Debian AMI
- ssh as admin using your keys
- No remote access - can be changed after log in.
- In the AWS marketplace for discoverability
- 5% growth in usage every week.
Why Debian on AWS?
- First place many people will discover Debian
- Existing users now use at scale.
- Providing a trusted operating system
- AWS are hiring