Securing Compute

Security Recommendations

Oracle Cloud Infrastructure Compute provides both bare metal and virtual machine (VM) instances, architected and managed in accordance with 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 permissions to a minimal set of groups. Give DELETE permissions only to tenancy and compartment administrators.
  • You can use the Oracle Cloud Infrastructure instance principals feature to authorize instances to access Oracle Cloud Infrastructure services (Compute, Block Volume, Networking, Load Balancing, Object Storage) on behalf of an IAM user. To use this feature, create dynamic groups and grant them access to service APIs. Dynamic groups allow you to group Oracle Cloud Infrastructure computer instances as "principal" actors (similar to user groups). You can then create policies to permit instances to make API calls against Oracle Cloud Infrastructure services.

    When you create a dynamic group, rather than adding members explicitly to the group, you instead define a set of matching rules to define the group members. A short-lived private key to sign API calls is delivered through the 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, such as OCID and display name, and custom fields. The instance metadata can also provide short-lived credentials, such as dynamic group credentials. Oracle recommends that you limit instance metadata access to privileged users on the instance. The following example shows how to use iptables to restrict instance metadata access to the root user.

    iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP
  • Instances use link local addresses to access the 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). You can use host-based firewalls, such as iptables, to ensure that only the root user is authorized to access these IPs. Make sure these operating system firewall rules are not altered.

Instance Network Access Controls

  • Harden secure shell (SSH) on all instances. The following table shows some SSH security recommendations. 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 the ~/.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 a non-standard port Port <port number> Optional. Verify that this change does not break applications using port 22 for SSH.
  • Use secure SSH private keys to access instances and to prevent inadvertent disclosures. For more information about creating an SSH key pair and configuring an instance with the keys, see Managing Key Pairs on Linux Instances.

  • To limit instance access to authorized IP addresses, use VCN network security groups or security lists. Fail2ban is an application that blocklists IP addresses involved in brute-force sign-in attempts (that is, too many failed attempts to sign in to an instance). By default, Fail2ban inspects SSH accesses, and you can configure it to inspect other protocols. For more information about Fail2ban, see Fail2ban Main Page.
  • In addition to VCN network security groups and security lists, use host-based firewalls, such as iptables and firewalld, to restrict network access to instances by controlling ports, protocols, and packet types. Use these firewalls to prevent potential network security attack reconnaissance, such as 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 random number generators whose output is fed into the entropy pools used by the operating system to generate random numbers. In Linux instances, /dev/random is non-blocking and should be used for security applications requiring random numbers. You can use the following commands to check the throughput and quality of the random numbers generated by /dev/random before using the 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 a baseline for security hardening of Linux and Windows images 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 operating system security hardening benchmarks for various distributions of Linux and Windows Server.
  • Keep instance software up to date with security patches. Oracle recommends that you periodically apply the latest available software updates to your instances. Oracle Autonomous Linux images are automatically updated with the latest patches. For Oracle Linux images, you can run the sudo yum update command (sudo dnf update on Oracle Linux 8). On Oracle Linux, you can get information about available and installed security patches using the yum-security plugin. The following example provides commands for yum-security. 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 Infrastructure instances, 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 to detect any security issues. In Oracle Linux, the log files are located in /var/log. Some security-relevant log files are listed in the following table.

    Log File or Directory Description
    /var/log/secure Auth log showing failed and successful sign ins.
    /var/log/audit Auditd logs capturing system calls issued, sudo attempts, user sign-ins, and so on. ausearch and aureport are two tools used to query auditd logs.
    /var/log/yum.log Lists packages installed or updated on instances with yum.
    /var/log/cloud-init.log During instance boot, cloud-init can run user-provided scripts as a privileged user. For example, cloud-init can introduce SSH keys. Oracle recommends that you review the cloud-init logs for any unrecognized commands.

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 to 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 the 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}