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.
As I’m currently working for IBM, please read my disclaimer.