Get notified on unwanted network changes with OCI Cloud Guard

Oracle introduced Cloud Guard some time ago to OCI, in this post I’ll take a brief look what Cloud Guard is and how you can get notified on unwanted changes in your tenancy.

As an example, I have a public VCN which is required for my project. I might have several admins managing the VCN and since it’s not an ideal world, there might be some changes happening which don’t follow the guidelines which have been set by the security.

What I want to happen, if somebody opens port 7001 in my VCN’s Security List I would get notification via Cloud Guard, Events and Notifications.

About Cloud Guard

In short, Cloud Guard is service in OCI which helps you maintain and monitor your defined security principles. Together with Security Zones it gives you lots of different options for additional security, however in this post I won’t go into Security Zones though.

Basic blocks for Cloud Guard are:

• Targets – defines the scope what is being monitored
• Detectors – Defines what is being monitored via recipes (Oracle Managed or Custom)
• Problems – Coming from detector recipes, these are potential security issues
• Responders – This is an action which will solve the problem

By default you would be using Oracle Managed detectors but I’m creating a custom detector recipe, disabling all other rules but only leaving rule which creates a problem if somebody opens unwanted port (in this example port 7001).

Currently custom recipes can only be cloned from default ones, you can’t add your own rules there, but can disable or enable the ones you want. If Oracle would add new rule in the managed recipe, this would be automatically added to your custom rule as well!

Recipes can be related to activity or configuration, such as changing security list port to terminating database instance.

Setting up Cloud Guard

We will have very basic setup here:

• Compartment cloud-guard which will be our monitored target
• Cloned Detector recipes: OCI Configuration Custom Detector Recipe & OCI Activity Custom Detector Recipe
• Cloned Responder recipe: OCI Custom Responder Recipe
• Target: vcn-cloud-guard

Cloning recipes is very straightforward, clicking “Clone” and giving the new recipe a name. After that you can just enable and disable the rules you want inside the recipe.

Here, I’ve disabled all the other rules but enabling rule on Security List restricted ports. Note I could also change ports list, risk level and labels.

There are some options you can set via conditionals if you don’t want whole compartment to be monitored, for example monitor only specific VCN.

For the Responder Recipe I’ve similarly cloned it but only enabled Cloud Event activity. This way once Cloud Guard detects a problem, it will raise event which we can utilize with Events and Notifications.

Configuring Events

I’ve created Notification which I’ve subscribed with my own email. In addition I’ve created cg-event which has a rule for Cloud Guard Detector – Problems when it matches compartmentId of cloud-guard.

Getting the alert

I’m disguised as an admin who manages networks in cloud-guard compartment and decide to open up port 7001 which should kick off a problem and also send an email notifications out.

After a while I see a problem appearing for my compartment, problem what I see with problems (hah!) is that you don’t know when system is running detectors. Here I waited hour or two until it appeared which makes testing recipes quite difficult.

Checking up my emails I see one which came through my subscriptions:

{
  "eventType" : "com.oraclecloud.cloudguard.problemdetected",
  "cloudEventsVersion" : "0.1",
  "eventTypeVersion" : "2.0",
  "source" : "CloudGuardResponderEngine",
  "eventTime" : "2021-03-14T20:16:11Z",
  "contentType" : "application/json",
  "data" : {
    "compartmentId" : "ocid1.compartment.oc1..aaaaaaaa2omey2x7xoxrq7cdwak3o6uh7wkjkeezmnhqb3zpggwmjuysvixq",
    "compartmentName" : "cloud-guard",
    "resourceName" : "VCN Security list allows traffic to restricted port",
    "resourceId" : "ocid1.cloudguardproblem.oc1.ca-toronto-1.amaaaaaa76xb3s2quea6embvtfh4kbvp7prjekj2ls72z2szimc2enn2dgfq",
    "additionalDetails" : {
      "tenantId" : "ocid1.tenancy.oc1..aaaaaaaa3ldkbl46td4dggysaxdc5mhvfjrgp2xln2hwm2ldrattnbg6f6pa",
      "riskLevel" : "CRITICAL",
      "status" : "OPEN",
      "problemType" : "CONFIG_CHANGE",
      "resourceName" : "Default Security List for vcn-cg",
      "resourceId" : "ocid1.securitylist.oc1.ca-toronto-1.aaaaaaaa765ij24eii4tqvpslazup424yop7m7srvjf46rilhwj3kepibi5q",
      "resourceType" : "VCN",
      "targetId" : "ocid1.cloudguardtarget.oc1.ca-toronto-1.amaaaaaa76xb3syaqyojer25zcb5xhnwamgufzybp5cghxomtf6xoxlk2y3q",
      "labels" : "Network",
      "firstDetected" : "2021-03-14T20:16:03.552Z",
      "lastDetected" : "2021-03-14T20:16:03.552Z",
      "region" : "ca-toronto-1",
      "problemDescription" : "Security lists provide stateful and stateless firewall capability to control network access to your instances. A security list is configured at the subnet level and enforced at the instance level. You can apply multiple security lists to a subnet where a network packet is allowed if it matches any rule in the security lists.",
      "problemRecommendation" : "Ensure that your security lists do not allow the 0.0.0.0/0 IP address range to control access to your instances. While VCNs would require a public facing IP address and an internet facing gateway with an open security list, defense in depth dictates that security lists be limited to known resources. It should be noted that a NAT instance can also provide internet access."
    }
  },
  "eventID" : "c99f9e74-eb16-4ca5-8a57-559f840c377b",
  "extensions" : {
    "compartmentId" : "ocid1.compartment.oc1..aaaaaaaa2omey2x7xoxrq7cdwak3o6uh7wkjkeezmnhqb3zpggwmjuysvixq"
  }
}

Summary

Once you go through Cloud Guard basics it’s quite simple to setup and configure the alerts you need with current limitations. However I’m hoping the custom recipes become more flexible in the future and not 1:1 mapped to the original ones.

Also during testing the biggest gripe is, when are the rules being validated? Is it every second, every hour or what? It’s very hard to figure out when should I see a problem if it doesn’t appear right away.

All in all, you should definitely consider using Cloud Guard for your implementations. You might not need anything fancy but as not everyone is always aware of their actions it gives you easy way to track what’s happening inside your tenancy.

Just leave the default tenancy level setup if you don’t have time to configure and check every now and then what’s happening there. It’s a free service after all!