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.
Hi folks! I’m glad of receiving good feedback from you guys! The topic of this post was one recent request from our followers, asking about what the best way to send windows logs to QRadar is. As you can imagine, there’s no best solution, it depends on what kind of environment we have. So to reply this question as simple and short as possible, I created the following table comparing some log collection methods.
To get more information about the Snare Agent, you can check out the vendor website. To get more information about the another two collection methods, you can check out our post about configuring log sources and the official documentation in this another post.
Do you have any question or suggestion? Let us know in the comments!
In this post we are going to explain in a simply way how to change the SSL certificate of QRadar. For the folks that already worked with IBM products know how tricky it were, but with QRadar it is way easier. In less than 10 steps you can import your self-signed or trusted certificated into QRadar.
- Get your self-signed or trusted certificate (remember: you need the public and private key);
- Log into your QRadar console using SSH;
- Transfer the certificate to some folder inside the QRadar, example:
/certificates/qradar_priv_certificate.pfx and /certificates/qradar_public_certificate.cer
- Execute the following command: /opt/qradar/bin/install_ssl_cert.sh -i
- The script will ask you the path to the private certificate file. Just type the path you used on step 3.
- The script can ask you the public certificate, just type the path you used on step 3;
- To confirm the change, type ‘y’ and press enter;
- After the completion, restart the hostcontext service using the command:
service hostcontext restart
- After the restarting the service, open the QRadar using HTTPs using your browser and verify the certificate;
Basically, the QRadar will make all the tricky part and will update the SSL certificate for you.
You can find the official documentation about the SSL certificate change in this link (that basically explain this 10 steps in 10 pages).
We already discussed about how configure log sources, and how configure QRadar to receive the logs. Let’s say that everything is ready, you are in front of the customer, and the logs doesn’t show up, do you know how to troubleshoot it? Here is some quick troubleshooting tips, that can help you in those situations:
- Verify the connectivity between the log source and the QRadar collector:
- You can simply ping from the log source to the collector;
- By default, the IP-Tables from QRadar drop pings, so you will need to stop the iptables process in the QRadar collector. You can do it opening the terminal (or ssh) in the QRadar and using the following command:
services iptables stop ;
- If you cannot even ping the QRadar server from your log source, the issue is the network;
- Don’t forget to restart the IPtables after testing, just use the following command:
services iptables start ;
- Verify the firewalls between the log source and the QRadar:
- The firewalls should allow the ports used to collect. For example, for collecting syslog, the firewalls should allow the port 514/UDP;
- If you have no access to the firewall, a simple way to test the firewall is using the telnet command from the logsource to the QRadar: telnet [IP] [PORT]
Example: telnet 10.1.1.1 514
- If the telnet doesn’t work, some firewall is dropping the packets on the specified port, you should ask for a firewall rule allowing the traffic;
- Verify the flows coming in the QRadar collector:
- You can use the command tcpdump in the QRadar to verify if the packets are being received in the QRadar;
- Syntax: tcpdump -i [INTERFACE] src host [IP-LOGSOURCE] port [PORT]
- Example: tcpdump -i eth0 src host 10.2.2.2 port 514
- If nothing shows up, there is some network issue dropping the packets or the log source is not properly configured;
- Verify the QRadar Logs:
- The QRadar logs are stored in the following folder: /var/log/
- The main log is named qradar.log
- You can simple access and monitor the log using the following command: tail –f /var/log/qradar.log
- You can verify the current EPS using the following command:
tail –f /var/log/qradar.log | grep ‘Events per Second’
I hope this post help you guys to troubleshoot collecting problems on QRadar. If you have any question or suggestion, please leave us a comment!
The QRadar solution offers two types of license by default: High Availability and Disaster Recovery. These licenses can be very useful in medium-large environments making the system more reliable. Both of licenses need to be purchased separately from the base QRadar license, and we know that most of the cases the clients want a solution to reach the compliance levels but with no extra cost. So one possible solution is creating a Cold Backup. You will not find it on the regular IBM documentation, so make sure that you follow carefully the steps of this post, the procedure is easy for people who already have QRadar experience.
Just a quick stop to explain what is a cold backup: Basically is a “clone” from the primary server, and it has the same configuration than the main server but stay always powered off. In case of some failure in the main server the staff should manually power the cold backup on. After restoring the primary server (and before turning it on), the cold backup should be powered off manually. This solution in most of the cases don’t need an extra license, you can use the same than the primary server but should NEVER have the both servers online at same time. Please consult your IBM sales representative before considering the cold backup, the laws can change between countries.
So, here is the high level steps. If you have any question on the steps, please leave a comment. Make sure that you understand all the process before doing it.
- Verify and take note of all the network configuration of the Primary server. You should have: IP, DNS, Gateway, hostname, email server, etc;
- Create an configuration backup of your primary QRadar;
- Turn off the primary QRadar server;
- Install (or re-install) the QRadar in the cold backup server using the network information gathered on the step 1;
- Apply on the cold backup the same license file than the primary server;
- After the finish of the installation, access the web interface of the cold backup, and import the backup generated on the step 2;
- Verify the logs collection and all the imported configuration;
- Turn off the cold backup server;
- Turn on the primary server;
Some considerations about this cold backup solution:
- The primary and cold backup should NEVER be on at same time. Make sure that you power off one server before turning on the other;
- All the transition process is manual, so when you have a failure in the primary you should manually turn the primary off and turn the cold backup on;
- The cold backup server may be not supported by the IBM official support. You should always consider buying a High-Availability or Disaster-Recovery license;
- The log data from the Primary will not be on the cold backup, and the log data in the cold backup will not be in the primary. To synchronize the data between the two servers you can use a external storage or manually import the data;
- Please make sure that you understand the whole process before doing it, we are not responsible for any misconfiguration issue;
- The both servers need to be in the same subnet;
- Remember that every configuration done in the Primary server should be replicated to the cold backup. To do it, just export the configuration from the primary (step 2) and import on the cold backup (step 6);
- Once a month run the updates on the ColdBackup to keep it updated;
- And again: Ensure that the both servers are never online at same time;
And as always, if you have any question or sugestion, let us know in the comments!
When implementing a large QRadar environment we can face several types of log sources across the network. QRadar support more than one hundred type of devices out-of-the-box and can integrate with any another log source using customized parsers. The log source parsers are known in QRadar as Device Support Modules (DSMs).
A personal recommendation to integrate log sources with QRadar is: always use syslog when it is possible. Why? Basically syslog is the standard log protocol for many devices, and QRadar can easily collect, identify and receive logs using this protocol. The syslog typically uses UDP connections, so make the log collection more fast and with almost zero latency. Make sure that all the firewalls of your environment allow traffic to QRadar in the port 514 (default syslog port).
IBM provide a good documentation explaining thorougly how to configure each type of device to send logs to QRadar. You can find the DSM configuration guide in the following link:
Do you have another tips to configure your devices? Share with us!