QRadar CE – Under the Hood

IBM is bringing free QRadar to a wider audience with Community Edition. Community Edition is a fully-featured version of QRadar that is low memory, low EPS, and includes perpetual license.

If you have read my previous article, you should have a working QRadar CE appliance.

Which is a nice start - but If you want to actually try your newly installed appliance in a real environment - even if you just testing it - the default install will probably not suit your needs. So You most likely have to reinstall the whole thing again, to get what you really need.

However to be able to decide what you really need, you should have a look to se what you just got with the default install.

Disk Partitions

The default install will result something like this:

Filesystem                          Size  Used Avail Use% Mounted on
/dev/mapper/centos_qradar--ce-root   50G   18G   33G  35% /
devtmpfs                            3.0G     0  3.0G   0% /dev
tmpfs                               3.0G   12K  3.0G   1% /dev/shm
tmpfs                               3.0G   13M  3.0G   1% /run
tmpfs                               3.0G     0  3.0G   0% /sys/fs/cgroup
/dev/sda1                          1014M  164M  851M  17% /boot
/dev/mapper/centos_qradar--ce-home  144G   33M  144G   1% /home
tmpfs                               602M     0  602M   0% /run/user/0

What you can see here?

  • The total disk usage is not even exceeding 20Gb.

While the minimal requirements say 130Gb. In practice the installation will fail if you assign less than 80Gb for your root disk!

  • Most of the stuff using space from the root partition.

This sounds fishy, so let's check it:

# du -hs /* 
0	/bin
131M	/boot
12K	/dev
38M	/etc
160K	/home
0	/lib
0	/lib64
0	/media
0	/mnt
7.7G	/opt
0	/proc
212K	/root
13M	/run
0	/sbin
0	/srv
8.7G	/store
25M	/storetmp
0	/sys
180M	/tmp
1.4M	/transient
277M	/usr
276M	/var

This clearly show you that the default CentOS install in not suitable for QRadar at all. You will need to redesign this part, as most ot the stuff lives in /opt/, and all of the further data will go under /store/ directory. As these are hard-coded locations, better not poke them. Adapt your setup instead:

The obvious solution would be to assign a separate virtual disk to /store/. The size should be planned according to your needs, but thanks to the virtualization technology, You can increase the virtual disk size on demand.

However, the install script will silently fail if it's found a /store directory. So you can fix this issue by moving the files to a separate disk after a successfull install. As this should be done in recovery mode, you probably better off with a big single disk.

  • Most of your space assigned to /home.

In a multi user environment, this may sound right. However QRadar is an appliance where no real user files will reside. So this is totally wrong.

You do not need separate partition for /home.

  • LVM is used insted of standard partitions.

While LVM is a good and practical thing if we using it on a real hardware. But it is completely useless inside a VM, as You can use your virtualisation features instead.

Use separate virtual (thin) disks instead of LVM partitions.

Running Processes

As the output of ps auxf will break my blog template design, or at least it would be unreadable, so I just link it as a separate file. Check it to see what you should get just after the install process.

Note that this beast is always doing something, so the process list may wary. But the main processes are:

  • docker containers

As all of the QRadar apps are running inside a docker container.

  • PostgreSQL

Where the main offense database lives.

  • Apache HTTPD

For the HTTP based console access.

  • Apache Tomcat

As a java web application server

  • Java based things

As most of the stuff inside is java based

  • NGINX

As a reverse proxy for the docker based apps

As you can see, this appliance is a really complex set of services, with a javacript based GUI: the QRadar Console. It may seems over complicated, however in case a real life enterprise solution, most of these services can be offloaded to a different machine for the scalability. This is reflected by the output of: netstat -tulpn too.

This also means that this appliance is very fragile, as all of these services are exposed to the network you attached to. You should place it to a separated and secured network segment, and only allow the really needed traffic. Even if the appliance is working with cyber threats, it is not meant to defend itself against any kind of attack scenario.

Packetfilter

The packetfilter (iptables) rules, used by the appliance is confirming my statement above. Here you can see filter table, the corresponding NAT table, and the default set of IPV6 rules.

Network Interfaces

The interface list (ifconfig output) looks something like this:

appProxy: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.4.1  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 02:42:70:d2:9c:e6  txqueuelen 0  (Ethernet)
        RX packets 1558  bytes 541988 (529.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1664  bytes 665068 (649.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.2.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 2001:db8:1::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::42:3dff:fe0a:7f5c  prefixlen 64  scopeid 0x20<link>
        ether 02:42:3d:0a:7f:5c  txqueuelen 0  (Ethernet)
        RX packets 8  bytes 544 (544.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 670 (670.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dockerApps: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.3.1  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 02:42:85:cc:c8:f7  txqueuelen 0  (Ethernet)
        RX packets 110  bytes 183385 (179.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 82  bytes 12229 (11.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dockerInfra: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.5.1  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 02:42:63:14:07:a0  txqueuelen 0  (Ethernet)
        RX packets 1698  bytes 421457 (411.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2094  bytes 632371 (617.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.21.218  netmask 255.255.255.0  broadcast 192.168.21.255
        ether 00:0c:29:f3:e7:3f  txqueuelen 1000  (Ethernet)
        RX packets 11296  bytes 10511747 (10.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7295  bytes 3680005 (3.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 228626  bytes 178746776 (170.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 228626  bytes 178746776 (170.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Note that the 192.168.21.218 is the IP address of the QRadar appliance assigned by me. The other IP's are QRadar specific, and you have very limited possibilities to change those.


After a successful installation, your CentOS turned into a QRadar appliance! From this point, you should manage it accordingly!


As all the official documentation said, this version is not for production. You have no real support if doing so. However you can try in your real environment, you can feed it with real logs and events, and you can learn how to use it.