QRadar: SSH to host fails with error "No ECDSA host key is known for and you have requested strict checking"

Troubleshooting

Problem

SSH and any application that uses SSH to establish connections such as SCP and RSYNC fail to connect to an unmanaged QRadar® appliance. This issue affects procedures such as copying QRadar® SFS files to patch a host to match the Console's version before adding the appliance to the deployment.

 

Symptom

The SSH connection attempt fails with the error:
 

# ssh <Remote Host IP>
ERROR: No ECDSA host key is known for <Remote Host IP> and you have requested strict checking.
ERROR: Host key verification failed.

Cause

When "strict checking" is enforced, the SSH connections to a host require the host's public host key to previously exist in the /root/.ssh/known_hosts file.

 
On older versions, the missing key entry generated a warning. The administrator could choose Y to proceed with the connection or abort it.

Environment

QRadar® 7.4.2 and later.

Resolving The Problem

1. Log in to the host originating the SSH connection.
2. SSH to the remote host disabling the strict checking. This will add the entry in the /root/.ssh/known_hosts file.
   Note: This command is a one-time disabling of the strict check to allow for changes to the known_hosts file. Future attempts will use strict checking.
    

   # ssh <Remote Host IP> -o StrictHostKeyChecking=no
   Warning: Permanently added '<Remove Host IP>  (ECDSA) to the list of known hosts.
   root@<Remove Host IP> 's password:

3. SSH to the remote host and the connection is established.
    

   # ssh <Remote Host IP>

Reference:

https://www.ibm.com/support/pages/qradar-ssh-host-fails-error-no-ecdsa-host-key-known-and-you-have-requested-strict-checking

QRadar: log source management legacy url

If you cannot access Log Source Management App. You can try to use legacy url:

https://10.10.2.10/console/do/core/genericsearchlist?appName=eventviewer&pageId=SensorDeviceList

How to filter QRadar peaks and solve performance issues

Step 1:

Get peak date time information from logs

cat qradar.log |grep SourceMonitor |grep ecs-ec-ingress |sed -r 's#^(.+?)::.+ Peak in the last 60s: (.+?)\. Max Seen.+#\1 \2#'

 

Step 2:

Go to QRadar UI and query that time period and group by EventID or SourceIP for detecting root cause of the problem.

Step 3: 

If the traffic which causes the peaks is abnormal, if it is possible try to drop unnecessary traffic at the log source level by solving the root cause of the problem.

QRadar: How to export all referencedata

 /opt/qradar/bin/contentManagement.pl -a export -c referencedata -i all -e

Get IP count stats for syslog traffic

 tcpdump -nns0 -i any -c 100000 dst port 514 |awk '{print $3}' |cut -d. -f1-4 |sort -V |uniq -c |sort -n

QRadar: snmpwalk: Failure in sendto (Operation not permitted)

[root@console snmp]# snmpwalk -Os -c public -v 2c 127.0.0.1:8001 iso.3.6.1.2.1.1.1
snmpwalk: Failure in sendto (Operation not permitted)



I solved it by changing port number to 8002 and with additional iptables rules.

# Default iptables rules block 8001 traffic.

[root@console ~]# grep -HR 8001 /etc/* 2>/dev/null |grep REJECT
/etc/sysconfig/iptables:-A INPUT -p tcp --dport 8001 -j REJECT
/etc/sysconfig/iptables:-A INPUT -p udp --dport 8001 -j REJECT
/etc/sysconfig/iptables:-A OUTPUT -p tcp --dport 8001 -j REJECT
/etc/sysconfig/iptables:-A OUTPUT -p udp --dport 8001 -j REJECT

# solution

[root@console ~]# iptables -I INPUT -p udp -m udp --dport 8002 -j ACCEPT
[root@console ~]# iptables -I OUTPUT -p udp -m udp --sport 8001 -j ACCEPT

[root@console ~]# iptables-save

QRadar: extract test steps of a specific offense rule

 /opt/qradar/support/extractRules.py -o QRadarRules.tsv 

# psql -t -A -U qradar -c "SELECT rule_data FROM custom_rule WHERE id=100311" | xmllint --xpath "//rule/testDefinitions/test/text" - | perl -MHTML::Entities -pe 'decode_entities($_);' |sed -e 's/<[^>]*>//g'

QRadar: Ariel query for getting related usernames in an offense

 AQL query:

SELECT username FROM events  WHERE INOFFENSE(ID) GROUP BY username

QRadar: Ariel query for getting related remote IPs in an offense

AQL query for getting remote ip addresses which is related with specific offense:

select distinct destinationip from events where INOFFENSE(633) TIMES OFFENSE_TIME(633) AND eventdirection IN ('L2R', 'R2R') 

QRadar: Could not retrieve "manifest_list_512": 500 Can't connect to 127.0.0.1:443 Could not download manifest list.

While installing autoupdate package on an offline environment, I got this error message:

Could not retrieve "manifest_list_512": 500 Can't connect to 127.0.0.1:443 Could not download manifest list.

For solution I set the hostname as QRadar dns name and I test connection with:

[root@qradar autoupdates]# /opt/qradar/bin/UpdateConfs.pl -testConnect 1 0

command.

IBM QRadar: Internal CA signed certificate configuration

Web browsers give visual cues, such as a lock icon or a green bar, to make sure visitors know when their connection is secured. HTTPS also protects against phishing attacks. A phishing email is an email sent by a criminal who tries to impersonate your website.

Using a signed certificate and a dns entry for QRadar provides an extra security layer between end user and QRadar Web Console interface. 

The video content covers these topics:
- Create certificate private key with openssl 
- Create certificate sign request (csr) 
- Sign certificate with Certification Authority on Windows Server 2012 R2 
- Push ca certificate with Active Directory Group Policy on Windows Server 2012 R2 
- Create DNS entry on DNS Server on Windows Server 2012 R2 
- Import ca certificate on Mozilla Firefox 



Reference doc:
https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_adm_ssl.html

payload box

This payload database is very useful for analyzing and discovering new attack techniques. And also you can use these payloads on your SIEM environment for playing with correlation rules.




https://github.com/payloadbox

QRadar community edition: Invalid configuration for device '8':

Workaround:

To work around this issue, remove the vmw:value="-1" from the OVF descriptor:
Download the exported OVF template from content library.
Edit the OVF descriptor and makethe following changes:
<vmw:Config ovf:required="false" vmw:value="-1" vmw:key="graphicsMemorySizeInKB"/>

to

<vmw:Config ovf:required="false" vmw:key="graphicsMemorySizeInKB"/>

Upload the OVF template back to content library.

https://kb.vmware.com/s/article/2152046