Perhaps one of the challenges in learning about Red Hat OpenShift is having a good testing environment to understand the platform well, be able to deploy test applications, and be phesible with both the GUI and the command line. While a minimal cluster starting with OpenShift version 4 requires at least 6 nodes, there is an all-in-one system called Red Hat CodeReady Containers. It includes a minimum cluster of the latest OpenShift 4 version with a series of settings to work on a single virtual machine that we can deploy on our test servers, or even on your own laptop. Although it is a project aimed mainly at software developers, but that serves us perfectly, to learn how to configure and manage this platform.

What other differences exist?

• There is only one node, which acts as “master” and “worker” at a time. You’ll see a lot of “warning” messages, but it’s not a problem.
• Kubernetes Operators are disabled. Also monitoring to save resources.
• Cannot upgrade to new versions of OpenShift. Although this is not a problem because we can download and run the new versions of this virtual machine that Red Hat is publishing regularly.
• It is an environment that must be recreated from time to time. Red Hat recommends doing it once a month, but in our hands-on experience, every two or three days of use, it gets slower and slower and needs to be destroyed and recreated.
• As it runs inside a virtual machine, it may be up to us to make some additional network settings by hand.

What are the HW and SW requirements?

• Latest version of Red Hat or Centos 7.X or 8.X. We prefer Centos as the setup is faster.
• 4 virtual CPUs (vCPUs)
• 8GB RAM
• 35 GB of disk space.

If none of this is a problem for you, you
can download the
image here. Please note that you need a Red Hat developer account (free).

You will see that in addition to selecting the operating system (there is an image for each type of “Hypervisor”), there is also a “secret”, this is still a kind of key-license, which will ask us during the creation of the virtual environment. Don’t download iton, but write down the “pull secret” in a notebook or similar.

If we are deploying the environment on Red Hat Linux, we will need to run these two commands to install and activate the NetworkManager:

$ su -c ‘yum install NetworkManager’

$ su -c ‘sytemctl start NetowrkManager’

We will also add a non-administrator user with sudo permissions, essential for everything to work properly.

$ useradd crc

$ passwd crc

$ vi /etc/sudoers

Allow root to run any commands anywhere

root ALL(ALL) ALL

crc ALL(ALL) ALL

With this user, we’ll download Code Ready Containers and launch the environment configurator.

$ su – crc

$ cd /home/crc/

$wget https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/crc-linux-amd64.tar.xz

$ tar -xvf crc*.xz

$ mv crc-linux-1.xxx-amd64/* /home/crc/bin/

$ crc setup

The latter is a necessary trick for DNS to work properly

$ crc start -n ‘8.8.8’

After a few minutes you should see this message.

To access the cluster, first set up your environment by following ‘crc oc-env’ instructions.

Then you can access it by running ‘oc login -u developer -p developer https://api.crc.testing:6443’.

To login as an admin, run ‘oc login -u kubeadmin -p dpDFV-xamBW-kKAk3-Fi6Lg https://api.crc.testing:6443‘.

You need to set up a number of environment variables with

$ eval $(crc oc-env)

Now you can register as an administrator:

$ oc login -u kubeadmin -p dpDFV-xamBW-kKAk3-Fi6Lg https://api.crc.testing:6443

.. or as a developer:

$ oc login -u developer -p developer https://api.crc.testing:6443

If you don’t have a graphical environment installed on this server, you won’t be able to access the web environment (via crc console),but you can use Firefox on any other system where you have Linux installed.

You need to copy the contents of /etc/hosts from the server where you installed OpenShift at the end of your local /etc/hosts file

Next you’ll need to open a VPN via ssh from a desktop environment like Ubuntu to the server where you deployed OpenShift

$ sudo apt-get install sshuttle

$ sudo sshuttle -r root@remote-server-ip -x remote-server-ip 0.0.0.0/0 -vv

And now, if you open your browser and access https://console-openshift-console. crc.testing you’ll see the GUI

 

If you need to know more, we have hands-on courses from both Docker and kubernetes and OpenShift. Contact us without obligation.

The latest version of IBM QRadar SIEM, The V 7.3.3 is the pre-release release of the expected 7.4 by the end of the first quarter of 2020. It includes improvements in performance, analyst workflow, product security, and essentially user experience. The upgrade is simple, through an IBM-provided script that from the console updates the deployment set.

Here are some elements, which in our opinion make it interesting to update to this version while the long-term 7.4 is released in the coming months.

Support for key and value pairs in the DSM editor.

Until now, when creating a log source manually, we needed to use regular expressions to extract each of the fields. Starting with version 7.3.3 it is possible to use simple delimiters for key – value attributes. This goes a step further than the improvement in event processing in QRadar 7.3.2 CEF and LEEF format, which allowed for the first time to automatically detect new properties. In addition, users with permissions can register that “custom properties” directly from the DSM editor, saving time and facilitating the whole process. Finally, an option has been implemented to export configurations from new log sources from the same editor.

Flow improvements (flows)

This release detects vxLAN information that is present in packets that are sent to QFlow (via Azure vTap, Technocrat
or monitoring card, or NIC) is extracted and added to the QRadar flow logs.

What’s new in Network Insights

Network Insights has improved the module that inspects RDP connections by detecting the type of encryption used and added a module to detect rsh, rexec, and rlogin connections. Another interesting improvement is that from now on all protocols: NFS , POP, SSL, TSL, HTTP, SSH, RDP, etc are detected accompanied by their version, as shown in this table.

What awaits us in version 7.4?

The release of the QRadar 7.4 is planned for the first quarter of 2020 and will include major improvements. This release will be based on Red Hat Enterprise Linux 7.7. It is expected to support Python 3.X and, as a curiosity, it is not clear that it is compatible in Internet Explorer browsers. It is important to note that this is a major update, with changes to the base version of the operating system. This involves additional tasks and additional precautions.

If you serve multiple customers from your SOC and use QRadar, you are in luck. There are plenty of hope that we’ll finally see significant improvements to the graphical interface along with a larger update to the Application Framework that provides full multi-tenancy support. However, the applications will have to be updated to be fully compatible. It is known that the UBA development team is already working on an update that, using these functions, allows to segment user behavior data by customer and domain.

In fact, it will be the companies that provide virtual or remote SOC services in multi-client environments that will benefit the most from the new features of version 7.4. In another post we will talk more about this and how to integrate QRadar into semi-automated incident response environments through different SOAR solutions like Resilient IRP. The future of SOCs will be to continue integrating tools and automating processes,as has been done for years in distributed environments with the implementation of DevOps & SysOpsmethodologies.

If you want to know more about this solution, at Sixe we offer training, consulting and technical support services for IBM QRadar SIEM. We also sell and deploy, migrate and integrate QRadar for all types of environments and customers. Contact us if you need our help :)