Oracle Cloud Infrastructure Documentation

Securing Compute

Security Recommendations

Oracle Cloud Infrastructure Compute provides both bare metal and virtual machine (VM) instances, architected and managed in accordance with industry-leading security best practices.

Managing Instances and Credentials

  • To prevent inadvertent or malicious termination of critical instances (for example, production instances), Oracle recommends that you give INSTANCE_DELETE permission to a minimal set of groups. Give DELETE permissions only to tenancy and compartment admins.
  • Instances can be authorized to access Oracle Cloud Infrastructure services (Compute, Block volume, Networking, Load balancing, Object storage), on behalf of an IAM user, by using Oracle Cloud Infrastructure instance principals feature. To use this feature, you create dynamic groups and grant them access to service APIs. Members of dynamic groups are instances that you define based on rules to match instances to the group. A short-lived private key to sign API calls, is delivered through instance metadata service (http://169.254.169.254/opc/v1/identity/cert.pem), and the key is rotated multiple times a day. For more information about accessing services from instances, see Calling Services from an Instance.

Instance Metadata Access Control

  • Instance metadata (http://169.254.169.254) provides predefined instance information (for example, OCID and display name), along with custom fields. Short-lived credentials, such as dynamic group credentials, could be provided through the instance metadata. Oracle recommends that you limit instance metadata access to only privileged users on the instance. For example, iptables can be used to restrict instance metadata access only to privileged users such as root, using the following rule.

    iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP
  • Instances use link local addresses to access instance metadata service (169.254.169.254:80), DNS (169.254.169.254:53), NTP (169.254.169.254:123), kernel updates (169.254.0.3), and iSCSI connections to boot volumes (169.254.0.2:3260, 169.254.2.0/24:3260). Host-based firewalls such as iptables can be used to authorize only root user to access these IPs. Ensure that these OS firewall rules are not altered.

Instance Network Access Controls

  • Harden secure shell (SSH) on all instances. Some SSH security recommendations are shown in the following table. SSH configuration options can be set in the sshd_config file (located at /etc/ssh/sshd_config in Linux). 

    Security Recommendation Configuration sshd_config Comments
    Use public-key logins only PubkeyAuthentication yes Periodically review SSH public keys in ~/.ssh/authorized_keys file
    Disable password logins PasswordAuthentication no Mitigates password brute-force attacks
    Disable root logins PermitRootLogin no Prevents root privileges for remote logins
    Change SSH port to non-standard port Port <port number> This is optional. Ensure that this change does not break applications using port 22 for SSH
  • Secure SSH private keys used to access instances and prevent any inadvertent disclosure. For more information about creating an SSH key pair and configuring an instance with the keys, see Creating a Key Pair.

  • Use VCN security lists as a mechanism to allow instance access from authorized IP addresses. Fail2ban is an application that blacklists IP addresses involved in brute-force login attempts (that is, too many failed attempts to an instance). Fail2ban inspects SSH accesses by default, and can be configured for other protocols. For more information about Fail2ban, see Fail2ban Main Page.
  • In addition to VCN security lists, host-based firewalls (such as iptables and firewalld) can be used to restrict network access to instances, in terms of ports, protocols, and packet types. These firewalls can be used to prevent potential network security attack reconnaissance (for example, port scanning) and intrusion attempts. Custom firewall rules can be configured, saved, and initialized on every instance boot. The following example shows commands for iptables.

    # save iptables rules after configuration 
    sudo iptables-save > /etc/iptables/iptables.rules 
    # restore iptables rules on next reboot 
    sudo /sbin/iptables-restore < /etc/iptables.rules 
    # restart iptables after restore 
    sudo service iptables restart

Instance Entropy

Both bare metal and VM instances provide high-quality and high-throughput entropy source. Instances have hardware random number generator support, whose output is fed into the entropy pools used by the OS to generate random numbers. In Linux instances, /dev/random is non-blocking, and recommended to be used for security applications requiring random numbers. You can use the following commands to check the throughput and quality of random numbers generated by /dev/random, before using its output in applications.

# check sources of entropy 
sudo rngd -v 
# enable rngd, if not already 
sudo systemctl start rngd 
# verify rngd status 
sudo systemctl status rngd 
# verify /dev/random throughput and quality using rngtest 
cat /dev/random | rngtest -c 1000

Host Security Hardening and Patching

  • Establish baseline for security hardening of OS images (Linux, Windows) running on instances. For more information about security hardening of Oracle Linux images, see Tips for Hardening an Oracle Linux Server. The Center for Internet Security Benchmarks provides a comprehensive set of OS security hardening benchmarks for various distributions of Linux and Windows Server.
  • Keep the instance software up-to-date with security patches. Oracle recommends that you periodically apply the latest available software updates to your instances. For Oracle Linux, you can run sudo yum update command. On Oracle Linux, you can get information about available and installed security patches using the yum-security plugin. Commands for yum-security are available below. For Oracle Linux instances launched after February 15, 2017, Ksplice support is available for applying patches without rebooting the instance. For more information about using Ksplice on Oracle Cloud Infrastructureinstances, see Installing and Running Oracle Ksplice.

    # Install yum-security plugin
    yum install yum-plugin-security
    # Get list of security patches without installing them
    yum updateinfo list security all
    # Get list of installed security patches
    yum updateinfo list security all

Instance Security Logging and Monitoring

  • Various security-related events are captured in log files. Oracle recommends that you periodically review these log files for detecting any security issues. In Oracle Linux, the log files are located in /var/log. Some security-relevant log files are listed in the table below. 

    Log File or Directory Description
    /var/log/secure Auth log showing failed and successful logins
    /var/log/audit Auditd logs capturing system calls issued, sudo attempts, user logins, etc. ausearch and aureport are two tools used to query auditd logs
    /var/log/yum.log Lists various packages installed or updated on the instance with yum
    /var/log/cloud-init.log cloud-init can run user-provided scripts as privileged user, during instance boot. For example, SSH keys can be introduced using cloud-init. Oracle recommends that you review the cloud-init logs for any unrecognized commands.
  • Host-based intrusion detection system (IDS) monitors instances for unauthorized accesses. OSSEC and Wazuh (OSSEC fork) are popular open-source IDS that can monitor for unauthorized access, malware, file modifications, and security misconfigurations. In the case of Wazuh, Wazuh server and ELK stack are deployed on an instance, and agents are deployed on other instances in the VCN to send logs to the Wazuh server. The resulting alerts are displayed on a Kibana dashboard. Wazuh IDS was prototyped on instances, and below are instructions for deploying a working Wazuh server on an instance (with ELK version 5.6.3). For more information about installing Wazuh agents and accessing the Kibana dashboard, see the Wazuh documentation.

    #!/bin/sh
                
    echo "installing elasticsearch"
    sudo add-apt-repository ppa:webupd8team/java;
    sudo apt-get update;
    sudo apt-get install oracle-java8-installer;
                
    sudo apt-get install curl apt-transport-https
    curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - ;
    echo "deb https://artifacts.elastic.co/packages/5.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-5.x.list;
    sudo apt-get update;
                
    sudo apt-get install elasticsearch=5.6.3;
                
    sudo systemctl daemon-reload
    sudo systemctl enable elasticsearch.service
    sudo systemctl start elasticsearch.service
                
    curl https://raw.githubusercontent.com/wazuh/wazuh-kibana-app/2.1/server/startup/integration_files/template_file.json | curl -XPUT 'http://localhost:9200/_template/wazuh' -H 'Content-Type: application/json' -d @-
                
    curl https://raw.githubusercontent.com/wazuh/wazuh-kibana-app/2.1/server/startup/integration_files/alert_sample.json | curl -XPUT "http://localhost:9200/wazuh-a
    lerts-"`date +%Y.%m.%d`"/wazuh/sample" -H 'Content-Type: application/json' -d @-
                
    echo "installing logstash"
    sudo apt-get install logstash=1:5.6.3-1;
    sudo curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/2.1/extensions/logstash/01-wazuh.conf;
    sudo curl -so /etc/logstash/wazuh-elastic5-template.json https://raw.githubusercontent.com/wazuh/wazuh/2.1/extensions/elasticsearch/wazuh-elastic5-template.json;
    sudo usermod -a -G ossec logstash;
                
    sudo systemctl daemon-reload;
    sudo systemctl enable logstash.service;
    sudo systemctl start logstash.service;
                
    echo "installing kibana"
    sudo apt-get install kibana=5.6.3;
    sudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-2.1.1_5.6.3.zip;
                
    sudo systemctl daemon-reload;
    sudo systemctl enable kibana.service;
    sudo systemctl start kibana.service;

Security Policy Examples

In all the following examples, the policies are scoped to a tenancy. However, by specifying a compartment name, they can be scoped down to specific compartment in a tenancy.

Restrict Users Ability to Delete Instances

The following example allows the InstanceUsers group to launch instances but not delete them

Allow group InstanceUsers to manage instance-family in tenancy
 where request.permission!='INSTANCE_DELETE' 
Allow group InstanceUsers to use volume-family in tenancy 
Allow group InstanceUsers to use virtual-network-family in tenancy

Restrict Ability to Use Instance Console

For security compliance reasons, some customers do not want to expose instance console to users in their tenancy. The following policy example restricts ability to create or read from consoles.

Allow group InstanceUsers to manage instance-console-connection in tenancy
 where all {request.permission!= INSTANCE_CONSOLE_CONNECTION_READ, 
            request.permission!= INSTANCE_CONSOLE_CONNECTION_CREATE}