IBM Guardium

IBM Guardium

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Monitoring AWS Oracle RDS with Guardium External S-TAP

    Posted Sun August 30, 2020 04:57 AM

    Database Activity Monitoring with Guardium Data Protection is traditionally leveraged with a lightweight software agent installed on the database server at the OS layer. The agent, called S-TAP, is the responsible for collecting traffic that is the basis of Guardium reports, alerts, dashboards.

    But what happens for those systems where we can't or don't want to install the S-TAP? Most typical examples are containerized databases or DBaaS where we don't have the possibility to manage the operating system.

    The answer is External S-TAP – a Guardium component that intercepts traffic for cloud and on-premises databases without the need of installing the agent on the database server. The External S-TAP acts as a proxy that forwards the traffic to the database server but also sends a copy of this traffic to a Guardium collector for traditional analysis, parsing and security policy application.

    External S-TAP software is based on the S-TAP code, but it is packaged in a Docker image. Due to the nature of the component, two or more containers are required in the same External S-TAP deployment in order to assure the availability of the database connection. This is the reason for the presence of a load balancer as well, that is going to balance the traffic to the containers. Two deployment choices exist now:

    • With Kubernetes (Figure 1) – that will take care of issues like load balancing and Docker containers orchestration. Another big advantage of using Kubernetes is the possibility to deploy the External S-TAP directly from the Guardium user interface.
    • Without Kubernetes (Figure 2) – in this case the deployment is managed with scripts for both load balancer and External S-TAP itself.
    Figure 1
    Figure 2


    In this post we are going to use the first approach to describe how to setup an External S-TAP with Amazon Elastic Kubernetes Services for an Oracle RDS.

    Prerequisites

     

    Create an Amazon EKS Cluster

    The EKS Cluster is a set of nodes where we will deploy the External S-TAP docker containers.

    Once completed with all the prerequisites, configure the AWS credentials from the host where AWS CLI is installed and start creating the Kubernetes cluster.

    Run aws configure commands and provide AWS Access Key ID, AWS Secret Access Key for your AWS account. Choose also the default region.

    Figure 3

    The cli commands to create Kubernetes clusters in AWS is eksctl create cluster. Run eksctl create cluster --help for all the possible flags to use with this command.

    Use the following format in order to create a cluster with 2 t3.medium nodes.

    eksctl create cluster \

    --name <your cluster name> \

    --region <aws region> \

    --nodegroup-name <your nodegroup name> \

    --node-type t3.medium \

    --nodes 2 \

    --nodes-min 1 \

    --nodes-max 4

    The cluster creation takes several minutes in order to complete. You can see the status directly from the command line (Figure 4) or from the AWS management console - Cloud Formation tab (Figure 5).

    Figure 4

    Figure 5

    When completed, two new nodes will appear in EC2 tab of the AWS console. Those are the nodes where the External S-TAP will be deployed.

    Run kubectl get svc to verify the cluster creation.

    Run kubectl get nodes to list the cluster nodes.

     

    By default, "eksctl create cluster" will build a dedicated VPC. For our configuration, this means the External S-TAP will be in a different VPC from Guardium Collector and database. Our components will be then using Public IPs for the communication.

    If we don't want to use Public IPs we can use VPC Peering service of AWS or directly create the Kubernetes cluster in the same VPC where the Guardium Collector is deployed (and also the database if applicable).

    In order to use an existing VPC for the Kubernetes cluster, supply private and/or public subnets using --vpc-private-subnets and --vpc-public-subnets flags in eksctl create cluster command.

    eksctl create cluster \

    --name <your cluster name> \

    --region <aws region> \

    --nodegroup-name <your nodegroup name> \

    --node-type t3.medium \

    --nodes 2 \

    --nodes-min 1 \

    --nodes-max 4 \

    --vpc-private-subnets <subnet_id1>, <subnet_id2>, <subnet_id3> \

    --vpc-public-subnets <subnet_id1>, <subnet_id2>, <subnet_id3>

    Run kubectl get svc to verify the cluster creation.

    Run kubectl get nodes to list the cluster nodes.

    Security Groups

    An AWS Security Groups acts as a virtual firewall to control inbound and outbound traffic.

    We need to add new inbound rules in order the allow the communication between our components.

    From External S-TAP to database:

    • an Inbound Rule on the database security group in order to allow traffic from External S-TAP IP address on port 1521 (and port 2484 if SSL is used)
    • add all the IP addresses of all the External S-TAP pods

    From External S-TAP to collector:

    • an Inbound Rule on the collector security group in order to allow traffic from External S-TAP IP address on port 16018
    • add all the IP addresses of all the External S-TAP pods

     

    Regarding both cases above:

    If using public IP addresses, the External S-TAP public IP are listed on the EC2 tab of the AWS console under IPv4 Public IP column. There is one IP for each node.

    If using private IP addresses, after the External S-TAP deployment (next paragraph), on the "External S-TAP instances" page click on the External S-TAP, "Actions", "View Details". An IP address for each of the pods will be displayed.

    Another option is getting the IP address from the command line:

    • run kubectl get pod to get the list of pods with names
    • run kubectl describe pod <pod name> to get the information about a single pod. The private IP address is under the IP

    Deploy External S-TAP from Guardium UI

    One of the big advantages of using Kubernetes is the easy External S-TAP deployment directly from the Guardium GUI (External S-TAP Control window).

    The procedure to add a new External S-TAP is based on 5 different tabs where the Guardium administrator has to provide the requested input:

    • Kubernetes – information about Kubernetes deployment
    • Docker tab – Docker account and Docker image information
    • Database tab – database connection information
    • Guardium tab – Collector IP and how to balance/split traffic to different collectors
    • Advanced tab – is SSL is used for the database connection, some further actions with certificates are needed. This is described in the section "Configuring External S-TAP with SSL" at the end of this post.

    Figure 6

    In the next tables a summary on how/where to gather the requested information.

    Kubernetes Tab

     

    Cloud Provider

    Amazon

    Master URL

    Run kubectl cluster-info.

    Copy and paste the Kubernetes Master URL.

    Token

    Create an EKS-admin account following step 3 of the guide at this link: https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html#w243aac39b9b5b3

    Run kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}') 

    Copy and paste the output token. 

    Deployment Name

    Choose a name for the Kubernetes deployment.

    Namespace

    Choose a namespace.

     

    Docker Tab

     

    Registry Key

    Create an Image Secret using Docker hub user account.

    For example: kubectl create secret docker-registry secret --docker-server=docker.io --docker-username=<your_user> --docker-password=<your_password> --docker-email=<your@email>

    Run kubectl get secret

    Copy and paste the name of the defined secret.

    Location

    store/ibmcorp/guardium_external_s-tap

    Tag

    Provide the tag of the image.

    Current available Docker tags are:

    v11.2.0

    v11.1.0

    v11.0.0

    v10.6.0

     

    Database Tab

     

    Database Type

    Oracle

    Database Port

    1512 (2484 if SSL is used)

    Database Host

    The hostname is on the "Connectivity & Security" tab of the Oracle RDS to monitor.

     

    Guardium Tab

     

    Collector IP

    IP of the collector where the External S-TAP will forward the traffic.

    Depending on which VPC was used for the External S-TAP, this can be the public IP or the private IP.

    Load Balancing

    0 - No Load Balancing (default)

    1 - Split sessions between collectors

    2 - Duplicate traffic to all collectors

    4 - Split sessions between collectors (Multi-threading)


    More info on the External S-TAP window here: https://www.ibm.com/support/knowledgecenter/en/SSMPHH_11.2.0/com.ibm.guardium.doc.stap/proxy/tab_deploy.html

    Once all the information is provided, click apply and the External S-TAP will be created. After some seconds, refresh the page and a new instance will appear on the list.

    Figure 7

    To verify the correct creation of the deployment, run kubectl get deployment.

    To list the pods, run kubectl get pod.

    To see detailed information about one single pod, run kubectl describe pod <pod_name>. This last command will show the configuration setting of the External S-TAP and also the logs if something is not working (for example lack of communication with the database).


    Verify External S-TAP

    When the External S-TAP is successfully deployed, database clients must connect to the load balancer and not to the database server anymore. The load balancer will balance the traffic between the External S-TAP containers that will perform two actions:

    • proxy action forwarding the traffic to the database;
    • S-TAP action capturing the traffic and forwarding it to the Guardium collector.

    The database connection must be modified in order to use the load balancer external IP - run kubectl get svc command to get this information.
    Figure 8
    Modify the connection and connect to the load balancer.

    Verify that the client successfully connects.

    Run some test traffic.
    Figure 9

    Verify that the traffic is reported on the Collector.

    Figure 10

    Figure 10Figure 12

    Configuring External S-TAP with SSL

    When Secure Sockets Layer (SSL) is used for the database connection, additional steps are requested to configure the External S-TAP.

    First of all, we need a certificate signed by a CA.

    Create a certificate signing request (CSR) for each External S-TAP with Guardium CLI account.

    create csr external_stap

    Enter an alias for the certificate (it can be anything).

    Enter the CN for the certificate. If CN match is required for the database, enter the hostname of the database. CN match is not required for Oracle database.

    Provide all the information requested for the CSR.

    When CSR is generated, take note of alias and token. These values will be used for the configuration.

    Also, copy and paste the CSR to a file (for example request.csr) starting at the "-----BEGIN NEW CERTIFICATE REQUEST-----" tag and ending at the "-----END NEW CERTIFICATE REQUEST-----" tag.

    Send the CSR file to a Certificate Authority (CA) of your choice in order to obtain a valid certificate. To import the certificate into the Guardium appliance, it must be in PEM format.

    Figure 13

    When the CSR is signed and the certificate in .pem format is available, store the certificate of the CA first:

    store certificate keystore_external_stap

    Provide the alias and the content of the certificate (starting from "-----BEGIN CERTIFICATE-----" and ending with "----END CERTIFICATE-----").

    Store the signed External-STAP certificate:

    store certificate external_stap

    Insert the alias defined during the CSR creation.

    Insert the content of the signed certificate (starting from "-----BEGIN CERTIFICATE-----" and ending with "----END CERTIFICATE-----").

     

    Once the certificate is successfully imported in the collector, follow the "Deploy External S-TAP from Guardium UI" paragraph to deploy the External S-TAP.

    Only an additional step is required – in the "Advanced" tab insert that is the token generated during the CSR creation. If the token wasn't saved it can be still retrieved running show certificate external_stap from CLI.

    Figure 14

    Verify the correct deployment with the commands already reported above in other paragraphs:

    kubectl get deployment

    kubectl get pod

    kubectl describe pod <pod_name>

    Modify the client database connections in order to connect to the load balancer external IP on the SSL port (2484).

    Verify that the connection is working and the traffic is correctly reported to the Guardium collector.

    Figure 15
    Figure 16

    Conclusions

    DBaaS are becoming more and more popular nowadays, but the "old-fashioned" requirement of monitoring privileged users and reporting on database activities is still there. External S-TAP is a component that provides this capability with a consolidated tool like Guardium Data Protection but maintaining the traditional Guardium architecture. In fact, the same Guardium deployment could be used to monitor activities in a hybrid environment composed by both on-premises and on-cloud databases.

    External S-TAP deployment with Kubernetes is a straightforward task that can be addressed directly from the Guardium UI. This is one of the main differences with the manual Docker deployment.

    Kubernetes will also take care of the containers orchestration and will also manage the load balancer which is the component where the applications/clients will connect to.

     

    External S-TAP vs Native Logging/DAS for DBaaS

    It's important to remark that Guardium is able to monitor some DBaaS with other options like Native Logging (for Oracle) or DAS (Data Activity Streams) services provided by cloud vendor (here a post on how to setup DAS on AWS for Guardium: https://guardiumnotes.wordpress.com/2020/03/).

    The big advantage of External S-TAP is that acts as a traditional S-TAP agent and so it is able to better capture and inspect database traffic. Things like records affected by a SQL statement, extrusion rules, failed logins or SQL exceptions are not captured with Native Logging or DAS.

    External S-TAP provides a complete and mature approach to database activity monitoring. Furthermore, the External S-TAP supports much more DBaaS than the other monitoring mechanisms which are strictly dependent to what cloud and database vendors provide. The IBM Guardium lab have added new databases to the list in the last releases –https://www.ibm.com/support/pages/node/5736879#external_s-tap). Note that the External S-TAP approach is available also for on-premises databases and not only DBaaS.

    Although External S-TAP is much more similar to the Guardium traditional monitoring approach, it is also more invasive than Native Logging or DAS. In fact, a proxy is introduced so that applications and DB clients connections must be re-configured in order to connect to the load balancer.

    With the other options, DAS or Native Logging, no changes to the connections are needed – we just need to enable these features and have Guardium as a consumer of the database activity monitoring information.



    ------------------------------
    Ander Schiavella
    ------------------------------


  • 2.  RE: Monitoring AWS Oracle RDS with Guardium External S-TAP

    Posted Tue September 15, 2020 03:11 PM
    This is very informative Ander.  Thank you!

    ------------------------------
    Carrie Rogers
    ------------------------------

    Original Message