IBM Support

QRadar: Microsoft Windows Log Sources and Support for SMBv1 and SMBv2 (Updated)

Troubleshooting


Problem

Agentless protocols in QRadar that use Server Message Block version 1 (SMBv1) no longer connect properly due to Microsoft Windows disabling this protocol on all operating systems. This technical note describes a workaround to use an intermediate server.

Symptom

Important

IBM released QRadar protocol RPMs to support both SMBv1 and SMB2 to resolve the connection issues related Microsoft's disabling the SMBv1 connectivity. This release update enhanced the existing SMB protocols for QRadar to allow connections by using the SMBv2 file-sharing protocol. To enable SMBv2, all five protocol RPMs must be installed in a single command. Administrators can update their protocols to the latest version by using the procedure outlined as Option 1: Update QRadar protocols to a version that supports SMBv2.

Cause

Microsoft disabled SMBv1 based protocol on all Windows operating systems due to exploits from the WannaCry or WannaCrypt vulnerabilities. Certain QRadar agentless protocols require SMBv1 to allow Event Collectors or Event Processors to connect to the Windows host to collect data. Administrators having the SMBv1 protocol disabled on a Windows host no longer be able to establish a connection to Windows hosts. This change by Microsoft affects the following protocols in QRadar:
  • Microsoft IIS (agentless, WinCollect is unaffected)
  • Microsoft Exchange
  • SMB Tail Protocol
  • Microsoft DHCP (agentless, WinCollect is unaffected)
  • Oracle Database Listener
 

When log sources that use these protocols go into the error state, it might be due to the SMBv1 protocol being disabled. Malicious exploits are targeting SMBv1 protocol in accordance with Microsoft Security Bulletin MS17-010. This critical SMB Server exploit globally disables the SMBv1 on a number of Windows operating systems. This issue affects Windows hosts that use QRadar Protocols to collect events, instead of using WinCollect agents.

Diagnosing The Problem

If the QRadar log source that uses the IIS, Exchange, DHCP, or SMB Tail protocol is in the error state, administrators can verify whether SMBv1 is enabled or disabled:
  • Windows Vista or 2008 & Windows 7/2008R2
    Verify the following registry key on the Windows host to determine the status of the SMBv1 protocol. A value of 0 is disabled in the protocol and a value of 1 is enabled: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SMB1
  • Windows 8 & Server 2012
    Administrators can use PowerShell to detect whether the SMBv1 enabled or disabled with the following command:  
    if ([bool](Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol)) { Write-Host "SMBv1 is Enabled" } else { write-host "SMBv1 is Disabled" }
  • Windows 10 & Server 2016
    Administrators can verify SMBv1 status by using Powershell with the following command:
    Set-SmbServerConfiguration –AuditSmb1Access $true



Resolving The Problem

Option 1 (Recommended): Update QRadar protocols to a version that supports SMBv2
To enable SMBv2, all five protocol RPMs must be installed in a single command. Administrators who attempt to install the protocol files individually experience installation errors due to rpm dependencies. Administrators must download and install these protocol files by using the included instructions. To reduce the impact to users, administrators must consider scheduling a maintenance window to complete this procedure as services are restarted.
Before you begin, download the following files:
  • PROTOCOL-SmbTailProtocol-<version>.noarch.rpm
  • PROTOCOL-OracleDatabaseListener-<version>.noarch.rpm
  • PROTOCOL-WindowsDHCPProtocol-<version>.noarch.rpm
  • PROTOCOL-WindowsExchangeProtocol-<version>.noarch.rpm
  • PROTOCOL-WindowsIISProtocol-<version>.noarch.rpm
NOTE: These RPM files are not available through QRadar Auto Updates. Administrators must use the provided links and the following procedure to install the updated protocol RPMs to enable SMBv2 support.

WARNING: A Deploy Full Configuration temporarily interrupts event and flow collection while services are restarted on all hosts in the deployment. A web server restart expires the session token, that logs off from all users and interrupt reports in progress. Administrators can advise users to manually start reports that are interrupted by a web server restart.


For 7.2.x Consoles:
  1. Download the updated protocol files for QRadar 7.2.x: Fix Central download link for all five protocol rpms
  2. Using SCP or WinSCP, copy the protocol rpm files to the Console.
  3. Using SSH, log in to the Console as the root user.
  4. To install the five protocol rpms, type: yum install -y PROTOCOL-SmbTailProtocol-7.2-20180410083224.noarch.rpm PROTOCOL-OracleDatabaseListener-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsDHCPProtocol-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsExchangeProtocol-7.2-20171212142247.noarch.rpm PROTOCOL-WindowsIISProtocol-7.2-20171212142247.noarch.rpm
  5. From the Admin tab, select Advanced > Deploy Full Configuration.
  6. From the Admin tab, select Advanced > Web Server Restart.

    Results
    After the protocols RPMs are installed, administrators must edit their log source configurations to enable SMBv2. A new user interface field is added to SMB-based log source configurations to allow administrators to define whether the protocol connects to the event source with SMBv1 or SMBv2.


For 7.3.x & 7.4.x Consoles:
  1. Download the updated protocol files for QRadar 7.3.x or 7.4.x based on the version of QRadar being used in the environment from: IBM Support Fix Central. Download the most recent protocols for:
    PROTOCOL-SmbTailProtocol
    PROTOCOL-OracleDatabaseListener
    PROTOCOL-WindowsDHCPProtocol
    PROTOCOL-WindowsExchangeProtocol
    WindowsIISProtocol
  2. Using SCP or WinSCP, copy the protocol rpm files to the Console.
  3. Using SSH, log in to the Console as the root user.
  4. Change to the directory containing the new protocols.
  5. To install the five protocol rpms, use tab completion to finish the correct names for each of the protocols downloaded: yum install PROTOCOL-WindowsDHCPProtocol- PROTOCOL-WindowsExchangeProtocol- PROTOCOL-WindowsIISProtocol- 
    For example,
    yum install -y PROTOCOL-SmbTailProtocol-7.3-
    20180402125212.noarch.rpm PROTOCOL-OracleDatabaseListener-7.3-
    20171212192242.noarch.rpm PROTOCOL-WindowsDHCPProtocol-7.3-
    20171212192242.noarch.rpm PROTOCOL-WindowsExchangeProtocol-7.3-
    20171212192242.noarch.rpm PROTOCOL-WindowsIISProtocol-7.3-
    20171212192242.noarch.rpm
  6. From the Admin tab, select Advanced > Deploy Full Configuration.
  7. From the Admin tab, select Advanced > Web Server Restart.

    Results
    After the protocols RPMs are installed, administrators must edit their log source configurations to enable SMBv2. A new user interface field is added to SMB-based log source configurations to allow administrators to define whether the protocol connects to the event source with SMBv1 or SMBv2.
 

Option 2: Use an intermediate Linux server
This work around uses a Linux intermediate server to mount the remote shares by using SMBv2 and make them available through an SMBv1 share to QRadar. The intermediate server is locked down to communicate using SMBv1 and accept these connections from QRadar appliances using firewall rules. The purpose of this procedure is to allow SMBv1 between the QRadar appliance and the intermediate server for event collection. Administrators who require SMBv2 per company security policy can use the updated protocols listed in Option 1: Update QRadar protocols to a version that supports SMBv2.

IMPORTANT: The procedures described in this technical note are intended for an intermediate server that is running a Linux distribution. Do not run these procedures to create mount points on the QRadar appliance as it causes event collection issues. This procedure is only intended for a non-QRadar Linux server.
 

For example:

Figure 1: Example configuration using an intermediate server to collect events using QRadar protocols.

Part 1: Configuring an Intermediate Server Share
This process informs administrators how to create an auto mount to configure a Red Hat Enterprise or CentOS intermediate server share. This share can act as a pass-through for protocols affected by SMBv1 being disabled on most Windows hosts. This procedure works for protocols in QRadar 7.2.x and QRadar 7.3.x and customers are not required to upgrade to collect data.
Procedure
  1. Install a Linux distribution on a 3rd party or intermediate server or virtual machine. 
    Note: This cannot be a QRadar appliance or managed host.
  2. Using SSH, log in to the Intermediate Linux server.
  3. To verify that SMB is enabled on the Intermediate Linux server, type: systemctl is-enabled smb 
    For example: root@RHEL7-Server ~]# systemctl is-enabled smb disabled
  4. If Step 3 returns the value disabled, type the following command to enable SMB: systemctl enable smb 
    [root@RHEL7-Server ~]# systemctl enable smb
    Created symlink from /etc/systemd/system/multi-user.target.wants/smb.service to /usr/lib/systemd/system/smb.service.
  5. To start the smb service, type: systemctl start smb
  6. Using vi editor, open /etc/samba/smb.conf and add the following lines: 
    [mnt]
    comment = QRadar SMBTail Share
    path = /mnt/smb
    read only = Yes
  7. Save the file by using the Esc key then typing :wq
  8. Create a User and password for a smbuser smbpasswd -a smbuser 
    Note: The user smbuser is intended as an example. This is the account name and password that QRadar uses to connect to the SMB1 share on the Linux intermediate server.
  9. To create the directory /mnt/smb, type the following command: mkdir /mnt/smb
  10. To restart the smb service, type: systemctl restart smb

    Results
    SMB is now enabled on the intermediate Linux server. The administrator can now configure firewall rules to restrict communications from selected hosts or services.
Part 2: Configuring Firewalls
SMB requires connections to port 445 TCP in the intermediate server. Depending on your Linux distribution, your firewall configuration might be using iptables or firewalld.
Firewalld
For firewalld instances in Linux distributions based off of Red Hat or CentOS (7.x versions only). These commands must not be run on the QRadar appliance, only the intermediate Linux server.
  1. Type the following command to create a zone for your SMB share: 
    firewall-cmd --permanent --zone=public --add-service=samba
  2. Optionally, you can add ports individually: 
    firewall-cmd --permanent --zone=public --add-service=sambax
    firewall-cmd --permanent --add-port=137/tcp
    firewall-cmd --permanent --add-port=138/tcp
    firewall-cmd --permanent --add-port=139/tcp
    firewall-cmd --permanent --add-port=445/tcp
  3. To load the changes in the firewall, type: firewall-cmd --reload 
    Results
    The firewall for Red Hat Enterprise 7 or CentOS 7 is enabled to add SMB communications. If the firewall is not reloaded, as in Step 3, these firewall rules will not be enabled. Only select incoming connections are accepted when a zone is set to public. It is recommended that most users to add SMB ports for the service as it can be disabled easily.
Iptables
For firewalld instances in Linux distributions based off of Red Hat or CentOS (6.x versions only). These commands must not be run on the QRadar appliance, only the intermediate Linux server.
  1. To add firewall rules in iptables, open the following file in any text editor: /etc/sysconfig/iptables
  2. Add the following lines: 
    A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 137 -j ACCEPT
    A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 138 -j ACCEPT
    A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 139 -j ACCEPT
    A INPUT -s x.x.x.x/32 -m state –state NEW -p tcp –dport 445 -j ACCEPT
    Where x.x.x.x is the host sending incoming connections to the Intermediate Linux Server.
  3. Save the file changes.
  4. Reload the updated firewall configuration by using this command: service iptables restart.
Part 3: Sharing Your Event Logs
Windows systems administrators can right-click the target folder containing their IIS, DHCP, Exchange, SQL logs, then select Properties. Click the Sharing tab, which contains the settings to share a folder. Go to the Advanced Sharing and enable the Share this folder check box. Administrators must verify permissions to ensure that the SMB user configured in Part 1 can access the shared folder. If you are using Windows Server 2016, administrators might need to enable the File Server role. Windows Server 2016 includes the Server Manager application that can be used to create and manage file shares that the Linux intermediate server can access. You must apply a user profile to create a share by using Windows Server 2016.
Part 4: Mounting the SMB File Share
To automount the Windows folder on the Intermediate Linux, use the /etc/fstab file. The procedure is intended as a mount location for the Windows logs on the Linux intermediate server. Auto mounting QRadar to poll for the data. Your log source must use the path defined in the mount point.
  1. Copy the /etc/fstab file to back it up 
    cp -p /etc/fstab /etc/fstab.bak
  2. Using vi editor create a credentials file: vi secret.txt 
    Note: The credentials file can be a name of your choice.
  3. Add a username and password in the following format: 
    username=<domain/username_of_host>
    password=<Your_password>
  4. Save the changes by using the Esc key then typing :wq
  5. Change the permissions of the file to read/write for root only: chmod 600 /root/secret.txt
  6. Add the following line to the bottom of the /etc/fstab file:  
    //IP_Address_Windows_Host/Shared_Folder/ /mnt/smb type cifs credentials=/root/secret.txt,_netdev,uid=0,gid=dba, ro,cache=strict,soft,dir_mode=0755 0 0
    Note: The example file path /mnt/smb is only an example and administrators need to mount each default folder that is used by their Windows hosts for the logs.  
     
    Examples of files that need an individual mount point:
    For Microsoft Exchange 2016 SMTP logs, the default directory is c$/Program Files/Microsoft/Exchange Server/V15/TransportRoles/Logs/ProtocolLog/ and the mount point could be /mnt/smtp_exchange2016.
    For Microsoft Exchange 2016 OWA logs, the default directory is c$/inetpub/logs/LogFiles/W3SVC1/ and the mount point could be /mnt/owa_exchange2016.
    For Microsoft Exchange 2016 SMGTRK logs, the default directory is c$/Program Files/Microsoft/Exchange Server/V15/TransportRoles/Logs/MessageTracking/ and the mount point could be /mnt/msgtrk_exchange2016. 
    For Microsoft DHCP logs, the default directory is Windows/system32/dhcp/ and the mount point could be /mnt/dhcp.
    For Microsoft IIS logs, the default error log path is Windows/system32/LogFiles/W3SVC1/ and the mount point could be /mnt/iis_logfiles 
     
    Results 
    The Administrators might need to repeat this procedure for multiple folders. For example, the Microsoft Exchange protocol supports MSGTRK, OWA, and SMTP logs and each folder needs a mount point. Depending on your collection requirements, repeat this procedure for the other SMB mount points. Your log sources require an update to reference the intermediate server IP address and any paths for new mount points you create to the new location of Windows log you want to collect.
  

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.2.8;7.3.1;7.4.0;7.4.1;7.4.2;7.4.3"}]

Document Information

Modified date:
23 February 2023

UID

swg22004891

Page Feedback