Oracle Linux

OCI Compute Instances – Stop SSH Brute Force Attacks with fail2ban & UseDNS

Every day and night, the SSH login by key into my public accessible Oracle Cloud Infrastructure Linux Compute Instance was permitted for hours. And sometimes, when I had luck, it worked. For me it was not clear when it works and when not. But something has blocked me. The password authentification in the OCI Linux instance is basically disabled, the key is the only way to log in.

After some investigation on the OCI instance, I found a huge amount of login trials in the /var/log/secure file. These brute force attacks were locking me out!

There is a interesting OCI documentation available called Securing Compute with steps how to secure OCI compute cloud instances – and one of this recommendation is: install fail2ban.

https://docs.cloud.oracle.com/iaas/Content/Security/Reference/compute_security.htm

fail2ban

fail2ban is an open source tool which reads several types of logfiles and creates based on rules new entries in the firewall table to block remote connections. I has default filters for ssh, apache postfix and many more. From Wikipedia: 

Fail2Ban is an intrusion prevention software framework that protects computer servers from brute-force attacks.

Link: https://www.fail2ban.org/wiki/index.php/Main_Page

Installation

All steps have to be executed as user root. FYI: I wanted to be informed when a new IP was banned, therefore I have installed sendmail too.

Configuration

For my fail2ban configuration I have created a new file called jail.local and made my settings there.

jail.local

After 2 unsuccesful logins, the source IP will be banned for 86400 seconds. And if a new IP is added to the ban list, I get an email.

/etc/fail2ban/jail.d/00-firewalld.conf

For OL7 where firewalld is used, verify if the command firewallcmd-ipset is set in /etc/fail2ban/jail.d/00-firewalld.conf. If you use iptables, the command can be changed. Please read the documentation how to change the firewall.

Start fail2ban

Verification

Status Check

Status Check with details, there is already one IP listed.

After some minutes, more entries were recognized in the /var/log/secure log file and added.

firewall-cmd

A new rule is automatically added with the match set failban-sshd.

sshd Configuration

After the fail2ban installation, there were other entries left in  /var/log/secure.

After changing the parameter UseDNS to no in /etc/ssdh/sshd_config and a restart, these entries were history.

Summary

Never let a OCI compute cloud running with a public IP without to monitor login attemps! fail2ban is one step to get more security. It is easy to configure and it helps a lot. But you have to do the basic work like software updates, SSH key enabling etc. The Oracle documentation is a good base to start! My next step will be to install and configure WAZUH – I keep you up to date!

Links

https://www.oracle.com/technetwork/articles/servers-storage-admin/tips-harden-oracle-linux-1695888.html

https://fedoraproject.org/wiki/Fail2ban_with_FirewallD

Oracle Cloud Infrastructure Storage Software Appliance – Installation and Configuration

The Oracle Cloud Infrastructure Storage Software Appliance – also known as Oracle Storage Cloud Software Appliance OSCSA – acts as a gateway between classic storage and the Oracle Cloud Infrastructure Object Storage Service. The appliance can be installed on an on-premises Linux system or in an Oracle Compute Cloud machine and runs in a Docker container. It offers a local cache where clients can place their files before the OSCSA moves them into the Storage Service. The communication between a client with a filesystem to the OSCSA works with NFSv4, from the OSCSA to the Object Storage Service, Oracle is using their REST interface. Traffic from the OSCSA to and from the Oracle cloud can be encrypted and compressed.

In this blog post first I will show you how you can install and configure the OSCSA in an on-premises environment. In a second step I configure an on-premises database server which uses the Object Storage Service as Oracle RMAN backup location.

Key Features

  • Compression and Exncryption
  • File Versioning
  • End-to-end Data Integrity with Checksum Verification
  • Support for Data Archival (Oracle Storage Archive Class)
  • Pin files to the appliance cache for faster access

Where to get the OSCSA and more Information

Requirements

  • Two dual-core CPUs (4-core CPUs recommended)
  • Minimum memory requirements (based on the maximum number of files that can be uploaded to the appliance filesystem):
    • 16 GB for filesystems up to 1 million files
    • 32 GB for filesystems up to 5 million files
    • 64 GB for filesystems up to 10 million file
  • Minimum disk size required to install Docker: 10 GB
  • Oracle Linux 7 with UEK Release 4 or later
  • Docker 1.12.6
  • NFS version 4.0

The installation and configuration of the required Oracle Linux components OL7 with UEK4, Docker and NFS is very well described in the „Using Oracle…“ guide. Please take a look in the guide, it’s straight forward. The OSCSA installer does not start when the requirements are not fullfilled. 

My Test Environment

OSCSA breitenbach.martinberger.local Oracle Linux 7.4 100GB Storage
Database Server zuchwil.martinberger.local Oracle Linux 7.4 Oracle RDBMS 12.1.0.2
Traditional Cloud Account cloud.oracle.com Zone EM2 Oracle Cloud Infrastructure Object Storage Classic

Firewall

Port 32771 (Appliance Web Interface) ,  32772 (NFS) and 32773 (REST) have to be opened on the appliance machine. If you don’t want to use these port numbers, you can set them during the installation process. Execute as user root:

File Content

All installation steps are executed as OS user root. The Oracle Storage Cloud Software Appliance Software Release 16.3.1.3 is available on my local machine in folder /stage. The extracted OSCSA file contains a file called OSCSA_GATEWAY_README.txt where you can get more information about the installation and configuration possibilities like proxy etc.

Installation

The installation starts by executing oscsa-install.sh. I have added the parameter -a = advanced so I am able to set ports for NFS, Administrative Web Interface and REST. Oracle recommends for the cache storage a minimal size. I have ignored that for my test environment.

Appliance Start

Now the Oracle Storage Cloud Software Appliance can be started. A server reboot is not problem. The docker image will be started after server startup automatically.

 

Configure a OSCSA FileSystem in the Appliance Web Interface

In this step, the OSCSA will be connected to the Oracle Cloud. At the moment, no <OSCSA FileSystem name> is configured. An OSCSA  filesystem is like a namespace containing a set of data. Now we can log in into the Appliance Web Interface to create our first Object Storage filesystem. URL for the interface is https://<servername>:<port>. The port for the interface was set during the installation process.  

For the connection to the cloud, you need to know your Identity Domain, Username, Password and REST Storage Endpoint URL. The FileSystem name will be reused later for the NFS mount.

Create a FileSystem called OCIClassicStorage01

Enter Domain, Username, Password and REST Storage Endpoint URL. Below this screenshot you can see where you find the URL in your Traditional Cloud Account.

Here you can see the REST URL.

Click on Validate

If the account informations are verified, you are able to enable compression and encryption. I have enable encryption here. Click Save.

The OSCSA storage is now ready to synchronize with the cloud. Click Connect.

Now you can see the the connection between the Oracle Storage Cloud Software Appliance and the Oracle Cloud Infrastructure Object Storage Service is ready.

In the Traditonal Cloud Account in the Storage Classic dashboard is a new object storage filesystem available.

Connect the Database Server to the Oracle Storage Cloud Software Appliance

Let’s connect the database server to the OSCSA to store data in the Object Storage Service. First we check again on the OSCSA server if the service is running.

On the database server a new mountpoint will be created.

We mount the OSCSA with NFS v4 to the local server. This entry can be added later to autofs or whatever you use to automatically mount an NFS filesystem. Permission of the mountpoint is drwxrwxrwx – so everybody can write into it at the moment.

Check.

Execute an Oracle RMAN Backup to the Cloud

A new subdirectory on the NFS mountpoint will be created.

Start Oracle Recovery Manager RMAN database backup.

The backup files are created locally in the specified mountpoint directory.

At the moment where the backup sets are arrived on the mountpoint, the OSCSA begins to encrypt  (this was my selections during filesystem creation) and transfer them into the Oracle Cloud. This is visible in the Appliance Web Interface.

Now the files are uploaded into the Oracle Cloud. This can be verified in the Traditional Cloud Account in the specific filesystem. The files are encrypted and have file names like 10101-v1, 10103-v1 etc.

 

Anything else?

Sure, this was just a basic overview how to configure the on-premises Oracle Storage Cloud Software Appliance. There are many more features like retrieve data, cloud access via command line, preserve filesystem cache, create directory permissions, set user permissons, monitor the appliance, backup the appliance, encryption key handling, use the archive storage and so on which are worth to spend more time for investigation in the future.

Summary

The Oracle Storage Cloud Software Appliance is a nice piece of software which helps you to use the Oracle Cloud Infrastructure Object Storage Service. The appliance is easy to install and configure, local encryption is possible and the documentation is very good. Database Backups and Database Export a perfect candidates for this service. The price is hot, $0.0204 per GB for the first TB, and $0.0201 per GB for the next 49TB.

Thumbs up!

OPatch 13.9 in EM13c – Say Goodbye to Unzip, Copy & Paste

Yesterday I wanted to apply a brand new patch to customer’s Enterprise Manager 13cR2 OMS running on Linux. First I updated the OMSPatcher as described here: How to upgrade the 13.1 Cloud Control OMSPatcher to latest version of OMSPatcher (Doc ID 2135028.1). This update was easy. Download, transfer, unzip and copy the OMSPatcher files to the Enterprise Manager ORACLE_HOME directory.

Then the patch apply results in an error. OMSPatcher is based on OPatch, he needs an update too.

We need a new OPatch Version

This was error message for patch apply with omspatcher when I executed the apply command.

My actual EM13cR2 OPatch version was 13.8.0.0.0.

Get the new Version

In My Oracle Support I found the newest version of OPatch, Download.

opatch_01

Transfer and extract

The next step was to extract and to transfer the package to the target server.And then I was wondering that not like in versions before an OPatch directory was created, now there is a JAR file inside the package. Copy & Paste of an OPatch directory is no more possible anymore.

Installation Routine – README.txt

Let’s take a look in the README.txt – there is an installation manual.

Installation – 1st run – where is my JDK ?

Installation – 2nd run – JRE is not good enough

I tried to use the existing JDK from my Oracle 12.1 installation

Installation – 3rd run – JDK 1.7 rocks

Now I have downloaded and configured JDK 1.7. Another try, and now it works. Here is a short summary of the output. In the background now the Oracle Universal Installer is started.

Thanks to Gokhan Atil – http://www.gokhanatil.com – for the second possibility, you can use the JDK from the OMS too.

Job done

Now the version was ok, the patch could be applied.

Additional Information: If the installer does not find your inventory location (was happened to me on an AIX system), just execute the install command with the parameter -invPtrLoc.

The OMSPatcher can be updated like before, but the other important component in the patch process OPatch has has to be installed. From my point of view this is a step back, I don’t know what was the idea behind to change it. Now you have to be sure, that there is an existing JDK 1.7 available on your system. This means that applying a patch on the express way is not possible anymore, you have to fulfill the prerequisite before you have an actual OPatch. And at the moment, there is no other documentation than the README.txt available, the hint with the inventory parameter came from My Oracle Support after I opened a SR.

Say good-bye to Unzip, Copy & Paste.