These are my notes on how to set up a system securely, in a way that would prevent attackers from being capable of performing an “evil maid attack”.
You have a Linux server that you want to protect against data theft and other backdoors. The attacker can get physical access to your hardware, for example by having access to the server room that houses your rack.
Your attacker is funded, but not super well funded. This will not protect you against intelligence agencies.
The attacker can buy a new server that looks just like the one you have. You will not be able to tell the difference from physical inspection.
You want to know that it’s safe to log in to your server after a suspicious power outage or reboot.
This solution assumes that once the system is booted and you log in, you have access to the secret data. In other words, this is not a protection for gaming consoles or kiosks.
First of all, full disk encryption using dm-crypt. Obviously. (other FDE also acceptable, of course)
Walking up to the server and typing the passphrase every reboot is not only tedious Continue reading
These are my notes on how to set up a system securely, in a way that would prevent attackers from being capable of performing an “evil maid attack”.
You have a Linux server that you want to protect against data theft and other backdoors. The attacker can get physical access to your hardware, for example by having access to the server room that houses your rack.
Your attacker is funded, but not super well funded. This will not protect you against intelligence agencies.
The attacker can buy a new server that looks just like the one you have. You will not be able to tell the difference from physical inspection.
You want to know that it’s safe to log in to your server after a suspicious power outage or reboot.
This solution assumes that once the system is booted and you log in, you have access to the secret data. In other words, this is not a protection for gaming consoles or kiosks.
First of all, full disk encryption using dm-crypt. Obviously. (other FDE also acceptable, of course)
Walking up to the server and typing the passphrase every reboot is not only tedious Continue reading
Earlier today many BGPmon users received one or more alerts informing them that their autonomous system (AS) started to announce a more-specific prefix. BGPmon classified many of these alerts as possible BGP man-in-the-middle (MITM) attacks. Here is an example alert:
====================================================================
Possible BGP MITM attack (Code: 21)
====================================================================
Your prefix: 23.20.0.0/15:
Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix
Update time: 2015-03-26 11:27 (UTC)
Detected by #peers: 24
Detected prefix: 23.21.112.0/20
Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US)
Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE)
ASpath: 4608 24130 7545 6939 40633 18978 3257 14618
The alert shows the user was monitoring 23.20.0.0/15, normally announced by Amazon, Inc. (AS14618). In this case however, the detected prefix was the more specific 23.21.112.0/20. The netblock owners would have verified their BGP announcements and quickly recognized they did not originate this more-specific prefix. Further analysis pointed to the suspicion that a bad actor was impersonating Amazon. BGPmon algorithms alerted to this as well, and–within moments of the initial change–marked these events as a possible BGP MITM attack.
One reason for this classification is the way BGPmon understands and interprets AS Continue reading
In my last post, I showed you how I automated my Kubernetes lab build out by using Salt. This took the build time and cut it by more than 70% (Im guessing here but you get the point). In addition, I’ve been making all of my changes for the cluster in Salt rather than applying them directly to the host. Not only does this give me better documentation, it allows me to apply changes across multiple nodes very quickly. You might be wondering why I chose Salt since I’ve blogged about Chef in the past. The answer isn’t cut and dry, but Salt just made sense to me. On top of that, there is VERY good documentation out there about all of the state and state functions so it’s pretty easily consumable. As I walk through the process I used to create the lab build scripts, I hope you’ll start to catch onto some of the reasons that made me decide to learn Salt.
Let’s start by taking a look at me GitHub repo…
While there’s a lot here, the pieces we really want to talk about are the files that end Continue reading