Archive
Container Lifecycle Management
I wanted to share a big problem that I see developing for many devs, as they begin to adopt containers. In an effort to familiarize us with some fundamentals, I want to compare the difference between virtual machines and containers.
The animation (above) shows a few significant differences that can confuse many developers who are used to virtual machine lifecycles. We can outline the benefits or why you *want* to adopt containers
- On any compute instance, you can run 10x as many applications
- Faster initialization and tear down means better resource management
Now, in the days where you have separate teams, one running infrastructure and another handling application deployment, you learned to rely on one another. The application team would say, ‘works for me’ and cause friction for the infrastructure team. All of that disappears with containers…but…
By adopting containers, teams can overcome those problems by abstracting away the differences of environments, hardware and frameworks. A container that works on a devs laptop, will work anywhere!
What is not made clear to the dev team is, they are now completely responsible for the lifecycle of that container. They must lay down the filesystem and include any libraries needed for their application, that are NOT provided by the host that runs them. This creates several new challenges that they are not familiar with.
The most important part of utilizing containers, that many dev teams fail to understand, is they must update the container image, as often as the base image they choose to use becomes vulnerable. (Containers are made up of layers and the first one is the most important!) Your choice of base image filesystem, will come with some core components that are usually updated, whenever the OS vendor issues patches (which can be daily or even hourly!). When you choose to use a base image, you should consider it like a snapshot, those components develop vulnerabilities that are never fixed in your container image.
One approach that some devs use is live patching the base image (like apt-get or dnf or yum update). Seasoned image developers soon realize that this strategy is just a band-aid when they add another layer (in additional to the first one) and replace some of the components at the cost of increasing the size. Live patching can also add cached components that may/may not fully remove/replace the bad files. Even if you are effective at removing the cached components, you may forget others as you install and compile your application.
The second approach involves layer optimization. Dev teams are failing to reduce the size of the container images which uses more bandwidth, pulling and caching those image layers, which in turn, uses more storage on the nodes that cache them. Memory use is still efficient thanks in part to overlay filesystem optimization but the other resources are clearly wasted.
Dev teams also fail to see the build environment as an opportunity to use more than one. Multipart building strategy involves the use of several sacrificial images to do compilation and transpilation. Choosing to assemble your binaries and copying them to a new clean image helps remove additional vulnerabilities when those intermediate packages are not needed in the final running container image. It also reduces the attack surface and can extend the containers lifecycle.
It takes a very mature team to realize that any application is only as secure as the base image you choose. The really advanced ones ALSO know that keeping your base updated is just as important as keeping ALL your code secure, when dealing with containers.
Run Fedora WSL
Hi fellow WSL folks. I wanted to provide some updates for those of you who still want to run Fedora on your Windows Subsystem install. My aim here is to enable kind/minikube/k3d so you can run kubernetes and to do that, you need to enable systemd.
How do you run your own WSL image you ask? Well if you are a RedHat lover like I am, you can use the current Fedora Cloud image in just a few steps. All you need is the base filesystem to get started. I will demonstrate how I setup my WSL2 image (this presupposes that you have configured your Windows Subsystem already).
First, lets start by downloading your container image. Depending what tools you have, you need to obtain the root filesystem. You may now need to uncompress the files. Either you downloaded a raw fil that was compressed using xz, tar.gz or some other compression tooling. What we want to do is get at the filesystem. Look for the rootfs file. The key is to extract the layer.tar file that consists of the filesystem. I used the Fedora Container Base image from here (https://koji.fedoraproject.org/koji/packageinfo?packageID=26387). Once downloaded, you can extract the tar file and then you can extract the layer (random folder name) to get at the layer.tar file.
Then you can import your Fedora Linux for WSL using this command line example
wsl –import Fedora c:\Tools\WSL\fedora Downloads\layer.tar
wsl.exe (usually in your path)
–import (parameter to import your tarfile)
‘Fedora’ (the name I give it in ‘wsl -l -v’)
‘C:\Tools\WSL’ (the path where I will keep the filesystem)
‘Downloads\…’ (the path where I have my tar file)
If you were successful, you should be able to start your wsl linux using the following command
wsl -d Fedora
(Here I am root and attempt to update the OS using dnf.
dnf update
Fedora 38 – x86_64 2.4 MB/s | 83 MB 00:34
Fedora 38 openh264 (From Cisco) – x86_64 2.7 kB/s | 2.5 kB 00:00
Fedora Modular 38 – x86_64 2.9 MB/s | 2.8 MB 00:00
Fedora 38 – x86_64 – Updates 6.8 MB/s | 24 MB 00:03
Fedora Modular 38 – x86_64 – Updates 1.0 MB/s | 2.1 MB 00:02
Dependencies resolved.
Nothing to do.
Complete!
You must install systemd now to add all of the components
dnf install systemd
The last part included activating systemd in WSL. Add a file called /etc/wsl.conf and add the following
[boot]
systemd=true
That is all of the preparation, now you can restart the OS and you should check to verify if your systemd is working.
systemctl
Zero-Day Exploitation of Atlassian Confluence | Volexity
There is another 0-day for Atlassian, they are having a tough time with RCEs
https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/
Bank had no firewall license, intrusion or phishing protection – guess the rest • The Register
Wow, ‘Security is hard’, but keeping licenses updated? It’s not THAT hard folks…
https://www.theregister.com/2022/04/05/mahesh_bank_no_firewall_attack/
How Modern Log Management Strengthens Enterprises’ Security Posture
If you have decided that you will just ‘log everything’, I suspect you may have already failed in that objective. If you are intrigued, then please read on…
How to Implement Security HTTP Headers to Prevent Vulnerabilities?
Looking for a great guide to understanding the the ‘must have’ collection of headers? Implementation of any/all of these can make the difference between 🙂 & 🙄https://geekflare.com/http-header-implementation/
Howard Hesseman, the hard rocking DJ on ‘WKRP in Cincinnati,’ dies at 81 – CNN
RIP Johnny Fever 🤘
https://www.cnn.com/2022/01/30/entertainment/howard-hesseman-wkrp-cincinnati-dies/index.html
Google Cloud Anthos MultiCloud API and GKE on Azure GA | Google Cloud Blog
It’s here and ready to join your fleet of clusters – check out the newest member of the Anthos capable deployments now on Azure too!
Why exfil your payload via ASCII? A picture is worth…
Malwarebytes has discovered a new type of skimming attack where the booty is sent via an image!
The attackers hides the credit card skimmers in the metadata of icon files and then sends the sensitive info after the attack is successful, to the C2 via an image.
Talk about the need for ‘copy protection’?
As if hiding JavaScript in the copyright tag of the ico file isn’t ingenuous enough, they capture input field data, obfuscate it and place it in a image file to be uploaded so your Siem doesn’t even see it?
They have shared the details in a blog post if you want to learn more.
https://latesthackingnews.com/2020/07/06/attackers-hide-credit-card-skimmers-in-image-files-to-steal-data/
Thinking of rooting your Android…think again
While many of us have been home, wondering if this virus will go away as quickly as it came upon us, Google has been silently preparing for ‘Round 2’ in the phone wars.
SafetyNet is Android’s third party attestation API and if you want to install legit software from the Google Play Store, you already have it.
Getting ready to route out the last of the modified bootloaders, they have now rolled out a hardware backed detection method to ensure application developers can tell if your device is rooted. This allows high risk vendors like your banking app to prevent the application from running to help curb fraud. Read more about it here.
https://www.xda-developers.com/safetynet-hardware-attestation-hide-root-magisk/amp/
Security Analyst - Jeff Soehner CISSP, GXPN,GPYC,GMOB,GCIH 