Automatic container updates with watchtower
Connect 1Password's CLI and app in i3 with lxpolkit
Use GNOME Keyring with Sway
Basic authentication with Traefik on kubernetes
Encrypted gitops secrets with flux and age
Secure Tailscale networks with firewalld
Forwarding ports with firewalld
Inspecting OpenShift cgroups from inside the pod
Running Ansible in OpenShift with arbitrary UIDs
Running Home Assistant in a Docker container with a Z-Wave USB stick
Disable autoplay for videos in Firefox 65
Use a secret as an environment variable in OpenShift deployments
Changes in RHEL 7 Security Technical Implementation Guide Version 1, Release 3
Apply the STIG to even more operating systems with ansible-hardening
Old role, new name: ansible-hardening
Enable AppArmor on a Debian Jessie cloud image
RHEL 7 STIG v1 updates for openstack-ansible-security
Takeaways from Bruce Schneier’s talk: “Security and Privacy in a Hyper-connected World”
Bruce Schneier is one of my favorite speakers when it comes to the topic of all things security. His talk from IBM Interconnect 2017, “Security and Privacy in a Hyper-connected World”1, covered a wide range of security concerns.
There were plenty of great quotes from the talk (scroll to the end for those) and I will summarize the main takeaways in this post.
People, process, and technology #
Bruce hits this topic a lot and for good reason: a weak link in any of the three could lead to a breach and a loss of data. He talked about the concept of security as a product and a process. Security is part of every product we consume. Whether it’s the safety of the food that makes it into our homes or the new internet-connected thermostat on the wall, security is part of the product.
The companies that sell these products have a wide variety of strategies for managing security issues. Vulnerabilities in an internet-connected teapot are not worth much since there isn’t a lot of value there. It’s probably safe to assume that a teapot will have many more vulnerabilities than your average Apple or Android mobile device. Vulnerabilities in those devices are extremely valuable because the data we carry on those devices is valuable.
Certainty vs. uncertainty #
The talk moved into incident response and how to be successful when the worst happens. Automation only works when there’s a high degree of certainty in the situation. If there are variables that can be plugged into an algorithm and a result comes out the other end, automation is fantastic.
Bruce recommended using orchestration when tackling uncertain situations, such as security incident responses. Orchestration involves people following processes and using technology where it makes sense.
He talked about going through TSA checkpoints where metal detectors and x-ray scanners essentially run the show. Humans are around when these pieces of technology detect a problem. If you put a weapon into your carry on, the x-ray scanner will notify a human and that human can take an appropriate response to escalate the problem. If a regular passenger has a firearm in a carry-on bag, the police should be alerted. If an Air Marshal has one, then the situation is handled entirely differently - by a human.
One other aspect he noted was around the uncertainty surrounding our data. Our control over our data, and our control over the systems that hold our data, is decreasing. Bruce remarked that he has more control over what his laptop does than his thermostat.
OODA loop #
Bruce raised awareness around the OODA loop and its value when dealing with security incidents. Savvy readers will remember that the OODA loop was the crux of my “Be an inspiration, not an impostor” talk about impostor syndrome.
His point was that the OODA loop is a great way to structure a response during a stressful situation. When the orchestration works well, the defenders can complete an OODA loop faster than their adversaries can. When it works really well, the defenders can find ways to disrupt the adversaries’ OODA loops and thwart the attack.
What I’m looking forward to at IBM Interconnect 2017
Display auditd messages with journalctl
augenrules fails with “rule exists” when loading rules into auditd
Talk Recap: Holistic Security for OpenStack Clouds
HTTP/2 for the blog and icanhazip.com
Join me on Thursday to talk about OpenStack LBaaS and security hardening
New SELinux shirts are available
Automated security hardening with Ansible: May updates
Troubleshooting OpenStack network connectivity
Preventing Ubuntu 16.04 from starting daemons when a package is installed
802.1x with NetworkManager using nmcli
Talk Recap: Automated security hardening with OpenStack-Ansible
OpenStack Summit in Austin is almost here!
Enable IPv6 privacy in NetworkManager
Automated Let’s Encrypt DNS challenges with Rackspace Cloud DNS
Enabling kwallet after accidentally disabling it
Talking to college students about information security
systemd-networkd and macvlan interfaces
What I learned while securing Ubuntu
Time Warner Road Runner, Linux, and large IPv6 subnets
Chronicles of SELinux: Dealing with web content in unusual directories
Build a network router and firewall with Fedora 22 and systemd-networkd
Research Paper: Securing Linux Containers
Automated testing for Ansible CIS playbook on RHEL/CentOS 6
Improving LXC template security
Time for a new GPG key
Upatre and icanhazip
Adventures with GRE and IPSec on Mikrotik routers
You have a problem and icanhazip.com isn’t one of them
Woot! Eight years of my blog
The spring of 2015 marks eight years of this blog! I’ve learned plenty of tough lessons along the way and I’ve made some changes recently that might be handy for other people. After watching Sasha Laundy’s video from her awesome talk at Pycon 20151, I’m even more energized to share what I’ve learned with other people. (Seriously: Go watch that video or review the slides whether you work in IT or not. It’s worth your time.)
Let’s start from the beginning.
Run virsh and access libvirt as a regular user
Libvirt is a handy way to manage containers and virtual machines on various systems. On most distributions, you can only access the libvirt daemon via the root user by default. I’d rather use a regular non-root user to access libvirt and limit that access via groups.