This is a small, but really useful quality of life feature!
The stars of today’s video are the offspring of Jeff Smith. It was cold, dark and miserable when I recorded the video, and this is one of my favourite clips, so I included it to bring a touch a summer! 🙂
Yesterday evening I went along to the Birmingham Digital & DevOps Meetup for the first time. It followed the usual meetup format of quick intro, talk, break, talk then home.
First up was Elton Stoneman from Docker with “Just What Is A “Service Mesh”, And If I Get One Will It Make Everything OK?” The session started by describing the problems associated with communication between the building blocks of a system, and how a service mesh can alleviate some of them. It then moved on to some service mesh demos using Istio. These included examples of altering the routing of traffic to do canary testing and targeting specific groups etc.
Elton was really honest about the learning curve, issues and overhead associated with this sort of setup. One comment I really liked was when he showed a slide containing the following, saying that often people assume there is a progression from left to right.
Meaning people assume you learn Docker, then you need some form of orchestration so you learn Swarm. From there you naturally progress to Kubernetes and once you understand that, you will inevitably move on to a service mesh using something like Istio. Elton’s point was you don’t *have to* continue on this progression. You can step off at any point once you’ve achieved the functionality you need. I think this is a really important point and I can see it reflected in what I do with Docker. We’ve got some things that stop at just using Docker containers, with no orchestration at all. I work on a project that requires some orchestration, so we use Swarm, which is really easy to use. So far I’ve had no reason to go beyond Swarm, and even considering a service mesh is so far down the line for us. I’m not discounting the relevance of these for everyone, but they don’t make sense for me at this point.
It was a really good session and I learned a lot. You can check out Elton’s blog here.
After the break it was James Relph with “Container Security Fundamentals”. This started of with a basic introduction to containers, using that as an entry point to explain how containers can be problematic from a security perspective, and what you can do to reduce the impact. He covered a lot of stuff, some of which I already do, some I know about and some stuff that was new to me. This is not an exhaustive list.
Don’t automatically trust images from Docker hub. Do your due diligence, even when they are from a reputable source.
Use your own image repository. He mentioned ECR amongst others. This can be used for your own images, but also base images from Docker Hub, which you have verified.
Don’t use “latest”, but use specific tagged versions. Latest gives you all the latest fixes, but all the latest bugs too. You should test and verify before you let images out into your infrastructure.
Multi-stage builds to reduce the size of containers and minimise the attack surface. Basically, copy out what you need and leave the crap behind.
Using sidecar containers to provide specific services, allowing your application images to remain more focused. The sidecar images can be maintained by feature experts to make sure they are as secure as possible.
Scanning images using Clair, amongst other things, to check for dodgy software. One of the audience mentioned Anchore.
Using microVMs like Firecracker to provide additional isolation, whilst retaining the ease of use of containers. I’ve not played with this, but I have tried Kata Containers, which seems to do pretty much the same.
There was a lot in there!
I was a bit nervous going into the event thinking it would all go over my head, and some of it probably did, but it was cool. I got to speak to a few people before the event, during the break and at the end. It seemed like there were quite a mix of people there from beginners in these areas upward, so I didn’t feel out of place.
A few times I found myself thinking, that’s great, but what do I do about my 3rd party applications? I’ve written before (here) about how 3rd party apps screw everything up. 🙂
You know that thing where you buy a new car and suddenly everyone else seems to be driving the same model? That’s how I am with Internet of Things (IoT) these days. Having had my interest peaked at OOW16, I’m suddenly noticing it getting mentioned everywhere, especially related to security. IoT+Security is now in the same position that Cloud+Security was a few years back. You can just hear the cries of “Won’t someone think of the children?”
We’ve spent years trying to encourage people to patch their PCs, servers and applications in an attempt to not be the next big attack vector, then along comes IoT and kind-of forgets all those lessons of the past (see here). This is common for any emerging tech. Let’s get it to work and worry about making it safe later!
The cheapness of IoT devices make them feel throwaway, so it’s a no-brainer to include them in everything. The problem comes when that throwaway tech is put inside something you plan on keeping for a few years, like a fridge, washing machine or internet-enabled underwear. 🙂 If security hasn’t been considered up front, is it going to end up being a problem long term? Either that, or am I going to have to “flash” my internet-enabled underwear on a regular basis to keep them safe? 🙂
I, for one, welcome our small internet-enabled overlords! But only if they come in peace! It will be interesting to see how thing goes…
PS. Cloud image taken at my nephew’s football match yesterday. Saucer from PixaBay. Bluring by SnagIt. Two minutes and I now have better “evidence” than most UFO videos on YouTube. Let’s see how long it takes for this to end up on one of them. 🙂
As followers of the blog will know, I use KeePass for all my work and personal passwords. I’ve come across a number of sites that prevent pasting passwords for “security reasons” and it drives me nuts. Fortunately, most of the them can’t prevent the auto-type feature, so at least that’s something…
This attitude goes beyond websites though. The policy at my current employer is all passwords should be strong and unique, but you are not allowed to use a password manager. Why? Because if someone installs a key-logger on your PC and gets the credentials for the password manager, they will have access to all your passwords. WTF? I think this attitude is moronic. I am not capable of remembering hundreds of unique, strong passwords. Using patterns is predictable, so that is also a fail.
I have seen the way some of my colleagues (past and present) deal with passwords and it is farcical.
One password to rule them all.
Kept in a text/word document on the desktop.
Kept in a text/word document on a network drive.
Kept on a piece of paper in their desk draw, that is never locked.
Freely shared amongst colleagues, so they can “test something using my account”.
For someone to step in and say we can’t use a tool that generates random, strong, completely unpredictable passwords and stores them in an encrypted format makes my blood boil.
Mary Ann Davidson wrote a great piece on her security blog today, which basically talked about focusing on the important vulnerabilities, not necessarily the ones that get the most press. Added to that, the risk associated with a vulnerability may well be different for you compared to everyone else, depending on how your system is used. I agree with what she is saying, but I’m going to take a slightly different angle on the subject.
Over the years I’ve come across lots of different attitudes to database patching from management and DBAs. As more DBAs are now involved in looking after middle tier products like WebLogic, some of those attitudes to patching have moved into that world too. It seems to break down into three camps.
We don’t need no stinkin’ patches. If this is the way you roll you are a dumb-ass!
We only patch stuff that represents a vulnerability for us. This sounds kind-of sensible, but life can get very difficult trying to decide what constitutes a threat, especially when you have to consider all layers of the technology stack.
We always apply all patches. This is logically simple, but you are going to apply a lot more patches, a lot more frequently, which is going to require a lot more testing.
Patching is not just about security.
Support of some products is tied into the patch version. We see this with Oracle products all the time. There are some important deadlines coming up soon! 🙂
The rest of the world is moving on around you. You might be happy with your unpatched product, but things might break because of external factors. If someone turns off SSLv3 on their application server, you aren’t doing HTTPS callouts from your database to it unless you patch up to 188.8.131.52 or later. Your applications will probably get browser compatibility issues on newer browsers and mobile devices unless you keep on top of patching your development frameworks.
Patches like the database PSUs come with extra functionality, including backports of features from newer releases (redaction – 184.108.40.206). They can also bring with them features that make future upgrades easier (transport database – 220.127.116.11 onward).
Choosing not to patch is not really an option these days. Your company has to understand this and allocate the correct amount of resource to getting it done. That might mean more staff resources allocated to patching and subsequent testing (rather than doing “productive” work), outsource the work where you can or moving to cloud services where regular patching is part of the deal.
It includes loads of security features, including the big ones mentioned in the recent attacks:
Changing the name of the “admin” user.
Changing the ID of your renamed admin user.
Changing the table prefix.
Max login attempts lockdown.
Of the 5 blogs I manage, 4 worked straight off with this plugin. Unfortunately, one required a few attempts, so remember to take filesystem and database backups before you start or you may not end up in a happy place.
Over the week since activating the plugin I’ve been quite interested/scared by the results. I’ve been getting several emails a day telling me of user lockdowns due to attempted brute force attacks originating from USA, Russia and the Netherlands.
If you have a self-hosted WordPress installation, you really need to take some basic steps stop yourself becoming a victim. There are a number of security plugins available, which I’m sure work equally well, but I only have experience of this one.
I’ve just bought something over the net using my Barclaycard. As usual, the checkout screen bounces me to a Barclaycard verification screen. As usual it asks me for several letters from my password. As usual my password doesn’t work. As usual I reset the password. Not as usual, the screen then asks me for the 9th letter of my password when I only set an 8 character password. Phone call later my password is reset again. I complete my order. I have to rest my password, but can’t use the one I set previously as it “has been used to recently”.
If I was a thief I really couldn’t be arsed to go through this when I could just mug a granny in the street. I see now how Barclaycard security works. It bores people out of commiting credit card fraud… Sigh…