¶ Forwarding Syslogs from Linux Hosts to QRadar
The following steps are required to forward syslogs from a Linux host to the QRadar appliance for SIEM ingestion.
Note: Some Linux flavours will differ slightly to the instructions provided below. It is expected that the audience will be familiar with their own deployment and the guide below will provide sufficient insight to the configuration requirements to successful configure log forwarding to QRadar. If your Linux Machine is a product appliance of some kind, you may wish to consult the vendor.
The following guide will assume your system is using rsyslog, which may not be the case. Instructions will be similiar and adaptable to syslog forwarder in use on the system (syslogd, ngsyslog)
Basic vi commands (cheat sheet) – The Geek Diary
¶ Configuring the rsyslog file
You will need to edit your rsyslog.conf file so that your Linux host knows where the QRadar appliance is.
- Open a terminal session on the Linux Host you wish to forward logs from.
- We need to edit the remote syslog file that resides in the /etc directory. To do so, type the command below.
vi /etc/rsyslog.conf
The file will open and will look something like this.
- Scroll to the very bottom of the file or go straight there by using the command (shift) g.
- Place the cursor at the end of the last line and hit the “insert” key on the keyboard. Or, you can simply hit the “i” key.
- At the beginning of the newly inserted line, type:
*.* @@IP Address:514 # UDP
or
*.* @IP Address:514 # TCP
where <IP Address> is the IP of your QRadar collector/processor appliance. In the example below we use IP 10.10.10.50 with port 514.
- Save (Escape, :wq) the file then restart the service by typing command:
service rsyslog restart
¶ Configuring auditd
You will need to edit your auditd file to add the required rules.
- Create a backup of the existing auditd rules configuration file by typing the following command:
cp /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.bkp
Note: If you receive permissions errors during this process, you may need to log in as root or elevate your permissions by using sudo if front of the commands.
- Now you will need to edit the audit rules by using the vi text editor.
vi /etc/audit/rules.d/audit.rules
- Use the insert key to enter Insert Mode and move cursor to the end of the file. Copy ALL the content below and paste to where the cursor is. ALL the lines below should now be included in the file.
# Program called
-a exit,always -F arch=b64 -S execve
-a exit,always -F arch=b32 -S execve
#It is possible to specify single commands to reduce the load with -F <path_to_binary> (see auditd documentation)
# Process spawns child
-a exit,always -F arch=b64 -S fork -S vfork -S clone
-a exit,always -F arch=b32 -S fork -S vfork -S clone
# File monitoring for edition and attributes modification
-w /boot -p wa
-w /etc/pam.d -p wa
-w /etc/shadow -p wa
-w /etc/passwd -p wa
-w /etc/rsyslog -p wa
-w /etc/openldap -p wa
-w /etc/sysconfig/syslog -p wa
-w /etc/syslog.conf -p wa
-w /etc/sysconfig/network-scripts -p wa
-w /etc/default/ufw -p wa
-w /etc/sudoers -p wa
-w /etc/sudoers.d/ -p wa
Note: You may wish to tune the above list and correlation rules with files or directories that you wish to monitor.
- Update the audit syslog plugin configuration.
If you are using RHEL v7, open the /etc/audisp/plugins.d/syslog.conf file and verify that the parameters match the following values:
active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_LOCAL6
format = string
If you are using RHEL v8, open the /etc/audit/plugins.d/syslog.conf file and verify that the parameters match the following values:
active = yes
active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_LOCAL6
format = string
- Update the auditd.conf if installed auditd is v2.6 or later.
sudo vi /etc/audit/auditd.conf
Find log_format = RAW and modify the value to match the below
log_format = ENRICHED
For other distributions the process should be similiar.
- Finally, restart the auditd service by typing the following command.
service auditd restart
or as applicable,
systemctl restart auditd
¶ Logging bash history
Edit the global bashrc file, the location may vary between distributions/bash versions.
sudo vi /etc/bashrc
or
sudo vi /etc/bash.bashrc
Append the following the end of the file
export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "[BASH_HIST] [PID=$$]: USR=$(whoami) DIR=$(pwd) CMD=$(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" )"'
¶ Extra applications
Applications running on your server may not use the built in logger and syslog falicities to generate their logs, and therefore will not be forwarded automatically.
For example, Apache and Nginx will often log directly to disk. Similairly applications may use log4j (in the case of java apps) or similiar libaries to log direct to disk by default, in these cases you will need to implenment specific log fowarding profiles in syslod/ngsyslog/rsyslog or make changes in the logger’s configuration (log4j config for example) to forward the relevant logs to QRadar.
Such application logs will likely also need fine tuning within QRadar, so please advise Secure-ISS of any such applications you wish to ingest.
¶ Troubleshooting
If you are experiencing issues with logs being forwarded to Qradar, it is important to check communication is allowed to the Qradar host. This can be acheived through a tool known as nmap which can be used to scan open ports on specified hosts.
Testing UDP (requires root):
sudo nmap -sU -p <port> <host>
Note UDP scanning results can be ambigous due to how the UDP protocol works, however,
open|filteredshould indicate the connection is okay.
Testing TCP:
nmap -p <port> <host>
¶ Examples
❯ sudo nmap -sU -p 514 172.17.10.7
Starting Nmap 7.80 ( https://nmap.org ) at 2025-05-15 10:15 AEST
Nmap scan report for 172.17.10.7
Host is up (0.015s latency).
PORT STATE SERVICE
514/udp open|filtered syslog
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds
❯ nmap -p 514 172.17.10.7
Starting Nmap 7.80 ( https://nmap.org ) at 2025-05-15 10:15 AEST
Nmap scan report for 172.17.10.7
Host is up (0.016s latency).
PORT STATE SERVICE
514/tcp open shell
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
Failing connection issues, check logs are actually being generated on the system:
ls -ltr /var/log
If there’s no recently modified logfiles it is likely the server simply hasn’t produced logs to forward yet.
Service status can be checked with systemctl:
❯ sudo systemctl status rsyslog.service
● rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2025-05-01 11:05:33 AEST; 1 week 6 days ago
TriggeredBy: ● syslog.socket
Docs: man:rsyslogd(8)
man:rsyslog.conf(5)
https://www.rsyslog.com/doc/
Main PID: 816 (rsyslogd)
Tasks: 4 (limit: 18973)
Memory: 8.3M
CPU: 7.428s
CGroup: /system.slice/rsyslog.service
└─816 /usr/sbin/rsyslogd -n -iNONE
❯ sudo systemctl status auditd.service
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2025-05-01 11:05:17 AEST; 2 weeks 0 days ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Main PID: 719 (auditd)
Tasks: 3 (limit: 18973)
Memory: 32.7M
CPU: 11min 23.840s
CGroup: /system.slice/auditd.service
└─719 /sbin/auditd
If systemctl returns anything other than active (running) there is likely any issue with the configuration. It should also provide some error messages that can be used for further troubleshooting should the above troubleshooting fail.
augenrules errors usually indicate an issue with the configured auditd rules list. To troubleshoot, run augenrules --load as root:
❯ sudo augenrules --load
/usr/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 2677491
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2677491
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2677491
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
backlog_wait_time_actual 0
Error sending add rule data request (No such file or directory)
There was an error in line 16 of /etc/audit/audit.rules
As you can see, the error here is on line 16 of audit.rules. Find the respective problematic rule in /etc/audit/audit.rules, then comment the corresponding rule in the rules list configured in /etc/audit/rules.d/. Additional utilities aureport and ausearchcan be used for further troubleshooting of auditd if issues persist.