Sometimes is necessary to audit the configurations of the QRadar and find the people involved on the changes in the system. Those changes can be verified inside the “events” tab of QRadar (and filtering by the events from the QRadar device). Another quick way to find the audit information about the QRadar is checking it own logs. For example, to check the history of accounts added on the system, there is a quick command that you can execute to check who and when added new account. To get this information just execute the following command :
[root@MY_RADAR]# cat /var/log/audit/audit.log | grep ‘AccountAdded’ | less
You will get log lines such as the example below :
Jun 12 14:34:37 127.0.0.1 X&Y (7638) /console/JSON-RPC/QRadar.saveUser QRadar.saveUser | [Configuration] [UserAccount] [AccountAdded] ID: 24 | Username: ABC | Email: ABC@DEF | Description: | Role ID: 2 | Security Profile ID: 1
By analyzing the log line, we can verify that X&Y added new account ABC with the e-mail address of ABC@DEF at Jun the 12th at 14:43.
By the original QRadar configuration, all the appliances comes with a pre-configured firewall rules in the OS. For testing purposes we can simple deactivate the firewall using the command “service iptables stop” (to stop the firewall) and “service iptables start” (to turn it back). But sometimes we need to update the firewall configuration aiming permanent changes.
In order to change firewall rules on your appliance you need to follow the below steps:
- Connect through SSH to the appliance that you want to make modifications;
- Login using ‘root’ account;
- Edit one of the following files:
- Add your firewall rules in the file, for example:
- -A INPUT -i eth0 -s x.x.x.x -j ACCEPT
- Save the file with the ‘ :wq ‘;
- Run /opt/qradar/bin/iptables_update.pl so your changes take effect;
With those steps your firewall configuration is now changed and will persist even in rebooting cases.
Continuing the post about running commands across the environment, today we’d like to present you another very useful and powerful command. Gathering information about the appliances and servers can be a painful task, but QRadar can provide us with some good scripts to make this task easy and automated. For example, if you execute on your QRadar Console:
[root@MY_RADAR]# /opt/qradar/bin/myver -v
…you’ll get a lot of information about you appliance like :
- Appliance type,
- Core version of the system,
- Patch number,
- Is the QRM enabled,
- Is the appliance you ran this command is a console,
- What’s the IP address,
- What’s the kernel architecture,
- Information about CPU, Operating System and if this is HA host or not.
And here’s the tricky part: to get this information from all your QRadar servers and appliances, you can combine it with the “/opt/qradar/support/all_servers.sh” command, presented in the another post, and gather this valuable information from all your managed hosts. For example, we can run this command across all the servers and input the result in a text file:
[root@MY_RADAR]# /opt/qradar/support/all_servers.sh “/opt/qradar/bin/myver -v” > /root/info.txt
As you can see, with just one line we can gather information of all our servers and generate a raw report of our QRadar environment. Simple, isn’t it?
A pretty common mistake when dealing with QRadar environments is wrongly updating the network configuration directly on the Operational System. As everyone know, the QRadar runs on a customized RedHat distribution, but it doesn’t mean that we could make the changes directly on the OS. To change the network configuration (IP, Hostname, DNS server, Network Mask, etc) we should use the appropriated QRadar script for it, and it is even easier than changing directly on the OS. The following procedure can be done to change the network configuration. Please note that while the configuration is done, the QRadar services will be down and after the configuration a reboot will be necessary. Also note that the procedure should be done in the server terminal, and not through SSH.
Changing the Network Configuration:
- Open the QRadar terminal (It should be DIRECTLY on the server, not through SSH).
- Run the following command:
- Read the terms and press Y and enter to continue
- Wait while the services are stopped
- Proceed with the network configuration and change the necessary configuration
- After clicking in FINISH, the server will be rebooted.
With this procedure, all the QRadar configuration files will be changed with the new network configuration and also the OS will be updated. So with just one script we change all the necessary configuration.
The daily maintenance across a small environments can be an easy job, but when our environment grows to a point where we have several appliances it can be a though job. For example, in case we need to monitor the Disk Space in a environment of just one appliance, we can simple connect through SSH to the QRadar and run a Linux command such as ‘df -h‘, but in a large environment with several appliances this practice would take a lot of time.
In the QRadar distributed environments, the console acts like a central management console to all the another appliances. In our example of monitoring disk, wouldn’t be easier if we could run a command in the main console to get information about all the environment? It’s exactly what the script ‘all_servers.sh‘ does. The script is located at:
To run the command, you can use the following syntax:
[root@MY_RADAR]# ./opt/qradar/support/all_servers.sh ‘COMMAND’
(Where COMMAND is what you want to run in the appliances)
In our example of monitoring the disk size, we could use:
[root@MY_RADAR]# ./opt/qradar/support/all_servers.sh ‘df -h’ > /root/drive_space.txt
And it would write the result of the script on all the servers in the following file: /root/drive_space.txt
The script can be used for several different purposes: Monitoring disk space, Monitoring CPU, Viewing network configurations, checking logs, etc. Can you imagine how it could help in your environment?! Had good ideas of how to integrate it with your monitoring systems?! Let us know in the comments!
— This post was suggested and written by our new collaborator, Tomasz Stankiewicz.