Log Sources

Using RSyslog to monitor and forward log files to QRadar

Posted on Updated on

Although it is possible to use SSH/SFTP/SCP to collect log files with QRadar, that option may not be the most appropriated for every company. Those collection methods, called pull-collection, requires an extra account in the system (so QRadar can login to collect the log). Moreover, the pull-collection methods collect the logs in an interval (usually, 5 minutes), meaning that logs may take up to 5 minutes to arrive in QRadar.

One alternative for collecting logs stored in files is using the rsyslog service, which is already pre-installed in the majority of the RedHat and CentOS versions. Those services are able to monitor a log file and forward each new log line to QRadar.

The first step is to check which version of rsyslog you have:

$ rsyslogd -version

 

If you have the newer rsyslog versions (7.x or above), then edit the /etc/rsyslog.conf file and add the following lines:

#### Load the file reader module ####
module(load="imfile" PollingInterval="10")

#### Configure to read a file ####
input(type="imfile" File="/var/log/logfile1.log" 
Tag="LogFileName:" 
StateFile="/var/spool/rsyslog/state-LogFileName" 
Severity="info" 
Facility="local3")

#### Forward the logs to QRadar
local3.info @@qradar_ip_address:514

 

If you have the legacy versions (5.x or below), then edit the /etc/rsyslog.conf file and add the following lines:

##### Load file reader module #######
$ModLoad imfile

##### Configure to read a file ########
$InputFileName /var/log/logfile1.log
$InputFileTag LogFileName:
$InputFileStateFile state-LogFileName
$InputFileSeverity info
$InputFileFacility local3
$InputRunFileMonitor  

##### Set the file monitoring for every 10 seconds ######
$InputFilePollInterval 10

##### Forward logs in local3.info to Qradar #######
local3.info                     @@qradar_ip_address:514

 

After the changes being done on the rsyslog.conf file, all you have to to is restart the service:

$ systemctl stop rsyslog
$ systemctl start rsyslog

To check if the service was started without errors, check the status by:

$ systemctl status rsyslog

If everything worked well, your service should be started without any errors.

One very common issue is when the rsyslog is not able to access the log file. This usually happens due to the SELinux service, which blocks access to sensitive files on the machine. To check if that is the case, temporarily disable the SELinux by using the following command:

$ setenforce 0

After that, restart rsyslog and check if the error persist. If it the issue is solved, then all you have to do is adding an exception to your SELinux to allow rsyslog to access the specific log file.

Advertisement

This entry was posted in Administration, Integrations and tagged , , , .

Using Syslog-ng to monitor and forward log files to QRadar

Posted on Updated on

Although it is possible to use SSH/SFTP/SCP to collect log files with QRadar, that option may not be the most appropriated for every company. Those collection methods, called pull-collection, requires an extra account in the system (so QRadar can login to collect the log). Moreover, the pull-collection methods collect the logs in an interval (usually, 5 minutes), meaning that logs may take up to 5 minutes to arrive in QRadar.

One alternative for collecting logs stored in files is using the syslog-ng service, which is already pre-installed in the majority of the newer Linux releases. This service can be used to monitor a specific file (in smaller intervals, such as 10 seconds) and in case of any changes, send the logs to QRadar. The configuration is fairly simple, here are the steps:

  1. Check if the syslog-ng is installed: 
    $ service syslog-ng status

    if not installed, install using:

    $ apt-get install syslog-ng
  2. Edit the syslog-ng configuration file (usually at: /etc/syslog-ng/syslog-ng.conf), inserting the following lines:
    source s_logfile1 {
file("[[[PATH_TO_FILE]]]" follow_freq(10) flags(no-parse));
};

destination d_qradar { 
tcp("[[[QRADAR_COLLECTOR_IP]]]" port(514) template("<$PRI>$DATE $HOST $MESSAGE\n"));
};

log { 
source(s_logfile1); 
destination(d_qradar);
};

    The first line adds a “file monitoring” rule to the specific file. You can update the file monitoring frequency (in seconds) by changing the follow_freq parameter.
    The second line adds a syslog destination, if you already had syslog-ng configured for another log monitoring, this line may not be necessary.
    The third line adds a logging action from the source file to the destination syslog recipient.

  3. Restart the syslog-ng service 
    $ service syslog-ng restart
  4. Done! You can now check on QRadar if logs are coming.
  5. If you need to troubleshoot, you can check the syslog-ng logs by using the following commands: 
    $ syslog-ng
$ service syslog-ng status

 

This entry was posted in Administration, Integrations and tagged , , , .

Monitoring Software-as-a-Service (SaaS) cloud solutions with QRadar

Posted on Updated on

One of the big advantages of having a Software-As-A-Service (SaaS) solution is the fact you don’t need to worry about infrastructure issues, such as patching, network availability, and etc. Also, most of the companies assume that all the security aspects of the solution will be handled by the vendor. Indeed, the vendor is (or should be) responsible for ensuring their system is secure, but it’s important to note that we should still monitor the SaaS solution for hacking attempts, which can be done through QRadar.

Picture this: imagine you have your website on wordpress, you pay wordpress as a service so you don’t need to worry about patching or updates. In theory, the wordpress team also monitors if someone tries to perform an attack against your site (for example, a SQL injection). But let’s say a malicious actor finds out the password of one of your wordpress users and creates a backdoor account for later exploitation. It wouldn’t be flagged by the wordpress security team (since it’s just a new user being created). That’s where QRadar can add value. If you integrate your wordpress with your QRadar solution, you would be able to generate an alert to your system administrator when a user is created or even correlate this event with other events such as pages being modified.

The easiest way to integrate your SaaS with QRadar is through email alerts from your SaaS solution. Let’s take the WordPress example and put it into a step-by-step:

  • Install the WordPress “Security Audit log” plugin
  • Create a mailbox to receive the alerts
  • Create a script that reads your mailbox and saves into a file. For example, you can modify this script to achieve that.
  • Create a custom DSM parser that interprets the file generated by the script above.
  • Create a log source on QRadar that monitors the file created by the script mentioned on step three. Use the custom DSM on this log source.

The implementation may require some time in the first time, but after setting up your first SaaS it will be trivial to set up the second one (since you will already have the mailbox set up and the script that reads the file). The same step by step can be adapted for a number of other SaaS services, such as: Dropbox, Gmail, Office365, Salesforce, AWS Cloudtrail and CloudWatch, etc…

Some of the events that can be interesting for us: New accounts created, change on security settings, login out of business hours, bruteforce attacks, configuration changes, etc.

Monitoring your SaaS solutions will put you one step ahead, ensuring that even applications on the cloud are being monitored and secure. Remember, even the server not being in your datacentre, the data in a SaaS application still yours.

 

This entry was posted in Administration, Integrations, Tunning and tagged , , , , , , .

Windows Desktops Log Collection – Methods Comparison

Posted on Updated on

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.

WindowsLogsComparison

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!

This entry was posted in Administration, Integrations and tagged , , , , , .

Quick Log Collection Troubleshooting

Posted on Updated on

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!

This entry was posted in Installation, Troubleshooting and tagged , , , .