By Craig Carl
Oracle Bare Metal Cloud Services offers a set of features that makes it especially compelling for NoSQL and Big Data workloads, including:
MongoDB, a leading database program, has recently become a popular target for cyber criminals looking for a high value ransomware target. In the past month alone, thousands of MongoDB servers have fallen victim to ransomware, forcing organizations to either pay the ransom, or risk losing critical data.
According to a recent study by the Ponemon Institute that included a survey of 350 organizations in 11 countries the average cost of a data breach is 3.79 million dollars, that’s strong motivation to build secure infrastructure.
The Castle approach -
I talk to Oracle customers every day about the best ways to build secure infrastructure in the cloud, defense in depth is always an important part of those conversations. Defense in depth, or the Castle approach to IT security is an information assurance concept that stipulates that no breach of any single security control will result in an exploitable vulnerability. This approach requires that you to build redundancy into every level of your IT defenses.
Start with completely private subnets –
On Oracle Bare Metal Cloud Services (BMCS), compute instances are launched into subnets in a Virtual Cloud Network (VCN). Subnets can be created that allow unlimited access to/from the Internet, to allow only certain traffic both inbound and outbound (ingress and egress) or to deny all Internet access, ingress and egress. We call subnets that allow any Internet traffic at all, ingress or egress, ‘public subnets’ and subnets that don’t support any Internet access ‘private subnets’.
Our first layer of defense is to create subnets that don’t have any access to or from the Internet. The BMCS platform provides three different ways to isolate instances from the Internet, we’ll use all three because good defense in depth calls for as much redundancy as possible –
Any one of these methods is, by itself, enough to isolate these instances from the Internet. By using all three we ensure that accidental exposure is unlikely and significantly raises the level of effort for an attacker.
Malicious Administrators -
To protect against a malicious administrator, compromised credentials, or a single administrator making a whole bunch of mistakes we can use the BMCS’s IAM policy language to ensure that no single administrator has permissions to make all the changes required. Once the appropriate policies have been deployed two administrators would have to be involved before these instances could be exposed. BMCS user permissions are highly granular and can be scoped up and down as required.
Secure compute instances –
By default the Linux operating systems that BMCS delivers to customers have their host firewalls enabled and configured to deny all inbound connections except port 22. The host firewall should never be stopped and ports should never be opened to all inbound connections, a source CIDR range should always be specified, that CIDR range should be as small as possible, limited to a VCN subnet or on-premises network.
The SSH service is configured to not support password based authentication, customers provide the public half of a keypair when they launch an instance. Never enable username/password authentication for SSH, keypair or certificate based auth are your only viable options today.
As a best practice customers should build separation of duties in their IT organizations such that administrators who have permissions to manage the BMCS VCN configuration don’t have the ability to SSH into an instance. Once that’s done it would take three administrators to expose MongoDB on these instances to the Internet; two to change the VCN and another to change the host firewalls. This protects against any two malicious administrators or set of compromised credentials.
Using the compute isolation capabilities of BMCS, secure-by-default OSes, and some best practices this MongoDB deployment is off to a secure start.
Securing MongoDB –
While early versions of MongoDB lacked some basic security capabilities more recent versions have improved dramatically. The most recent versions of MongoDB support –
Accessing MongoDB –
A MongoDB that’s completely inaccessible isn’t much good to anybody so we’ll need to find a way for clients to securely access the database.
For enterprises that need access from on-premises networks, BMCS offers VPN and other private connectivity options. These private connection options continue the theme of isolation and privacy and are the best option where business requirements allow. In this case the ingress firewalls on the subnets that host the MongoDB would allow access only to MongoDB specific ports where the source IP is in the RFC1918 CIDR range of the on-premises network(s).
For use cases where Internet facing applications also hosted on BMCS need access to MongoDB we’ll add one or more public subnets to the VCN and configure the Security Lists appropriately, which is conservative. Every subnet has a stateful ingress and egress firewall, we’ll use both to continue the theme of defense in depth.
With these assumptions –
Security Lists deny all by default so we would need to open certain (source|destination)/port pairs –
These rules would need to be duplicated on the host firewalls, defense in depth requires redundancy. You should have noticed at this point that we don’t have any way to connect via SSH to any instance in any of these subnets. Good eye.
Administrative access –
We always need to aggressively protect SSH access to instances, we’ve already agreed to never enable username/password auth, but we can do more.
If you are using VPN you should access port 22 directly from your on-premises network using the dynamic Security List technique described below, you don’t need a bastion host.
If you need SSH access to the infrastructure over the Internet you should use a bastion host with the added layer of protection described below. It’s important that the private half of the keypair used on the MongoDB instances is never on the bastion host. Scott Lowe has written a great primer on bastion hosts and how to configure your SSH client to make using a bastion transparent.
We never want to allow port 22 access from the subnet(s) where our applications live, we want to protect against an attacker gaining access to an application and jumping from there to a MongoDB instance. This means we won’t put our bastion host in the same subnet as the application servers, it will get its own.
Because we’re hosting this infrastructure in the cloud we can easily add a layer of protection that wouldn’t be practical on-premises. This is one of my favorite, only in the cloud security tricks, on-demand SSH access. On BMCS, changes to Security Lists generally take less than 15 seconds to become effective so why not just add a port 22 rule to a Security List only when an administrator needs it and remove the rule when the work is done? Using one of our SDKs or the API directly it’s easy to write a script that will –
Secure, performant, cost effective, scalable, easy to use, and enterprise focused, Oracle Bare Metal Cloud Services is the best place to build infrastructure supporting NoSQL and Big Data workloads.
You can be up and running in the OBMC in less than 2 hours, signup at https://shop.oracle.com/product/BareMetal or contact your Oracle sales team.
Technical questions and feedback on this post are both encouraged, firstname.lastname@example.org.
Join the BMCS community at https://community.oracle.com/community/cloud_computing/bare-metal.
$ sudo ship_it