For the last few years, if you wanted to set up a virtual network environment (for testing purposes, or setting up a lab, etc), it was more or less a manual process of installing software like the CSR 1000v from an ISO or OVA. Rinse and repeat. If you were fortunate enough to work at a company with decent virtual machine automation and infrastructure (and had access to it) then you could in theory make this a little easier, but it’s hardly portable. However, this is still much better than it was only a few short years ago, when many vendors simply did not offer a virtual machine version of their routers and firewalls.
The other day I was catching up on some Twitter feed, and I noticed a tweet from John Deatherage that caught my eye:
Updated #vsrx @vagrantup plugin to support DHCP, as well as Vagrant's new(er) insecure pubkey replacement https://t.co/WaMSAoDVIY #netdevops
— John Deatherage (@RouteLastResort) March 25, 2015
I’ve been using Vagrant for about a year, so I’ve got a bit of experience with it, but mostly with server operating systems. Seeing this tweet reference it’s use in the context of spinning up instances of a Continue reading
For the last few years, if you wanted to set up a virtual network environment (for testing purposes, or setting up a lab, etc), it was more or less a manual process of installing software like the CSR 1000v from an ISO or OVA. Rinse and repeat. If you were fortunate enough to work at a company with decent virtual machine automation and infrastructure (and had access to it) then you could in theory make this a little easier, but it’s hardly portable. However, this is still much better than it was only a few short years ago, when many vendors simply did not offer a virtual machine version of their routers and firewalls.
The other day I was catching up on some Twitter feed, and I noticed a tweet from John Deatherage that caught my eye:
Updated #vsrx @vagrantup plugin to support DHCP, as well as Vagrant's new(er) insecure pubkey replacement https://t.co/WaMSAoDVIY #netdevops
— John Deatherage (@RouteLastResort) March 25, 2015
I’ve been using Vagrant for about a year, so I’ve got a bit of experience with it, but mostly with server operating systems. Seeing this tweet reference it’s use in the context of spinning up instances of a Continue reading
VM NIC firewalls have been around for years (they’re also the reason I got my first invitation to the awesome Troopers conference), but it sounds so much better when you call them Microsegmentation (not the one I talked about @ Troopers this year).
Marketing gimmicks aside, VMware NSX includes an interesting in-kernel stateful firewall, and Brad Hedlund was kind enough to explain the intricacies of that feature in Episode 27 of Software Gone Wild
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