When using Zabbix on a Centos8/RHEL8 machine the following error occurred whil trying to monitor an HTTPS-website via the build in web scenarieos:
(35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
The error itself also shows up when trying to use curl to connect to the website:
$ curl -D - https://<some-legacy-website-> -k
curl: (35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
That error occurs if the server uses an older cipher-suite that’s considered unsafe by the default crypto policy used in Centos8/RHEL8.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
To work around that problem, the legacy cipher suites must be enabled by:
# update-crypto-policies --set LEGACY
Although a restart is recommended after issuing the command, for me it also worked without the need of issuing a reboot.
Commands to query the auditlog for Zabbix relevant queries and create/import a compiled policy file within Zabbix
Could be adapted to generate policies for any other system.
The suggestion is to set SELinux to permissive (setenforce=0) execute the action and afterwards create the policy based on the logged events. If the policy does not work on the first try after re-enabeling SELinux again it it could happen that a call was blocked (which is also logged within the auditlog) that was not blocked with SELinux in permissive mode. Therefore it could help creating a new human readable policy (.te-file) and checking the first version vs. the second version + merging them.
filename=zabbix-server
cat /var/log/audit/audit.log | grep zabbix | audit2allow -m $filename >> $filename.te
checkmodule -M -m -o $filename.mod $filename.te
semodule_package -o $filename.pp -m $filename.mod
semodule -i $filename.pp
#restorecon -R -v /run/zabbix/zabbix_server_alerter.sock #suggested by the policygenerator
Just two littel scripts that come handy if you want to download all the CVE info in JSON format for offline use.
#!/bin/bash
urls=$(curl https://nvd.nist.gov/vuln/data-feeds#JSON_FEED | grep 'https://' | grep -i json.gz | sed 's/.*href=//g' | cut -d\' -f2)
mkdir -p ./nistNvdJson
cd nistNvdJson
for l in $urls;
do
wget $l
done
gunzip *
Donwload NIST NVD CVEs in JSON
#!/bin/bash
loopVar=1
dataDir="rhelCveData"
mkdir $dataDir -p
echo "getting data:"
T="$(date +%s)"
while [[ $loopVar -ne 0 ]];
do
echo -n "-$loopVar- "
data=$(curl -s https://access.redhat.com/labs/securitydataapi/cve.json?page=$loopVar)
if [[ "$data" == "[]" ]]; then
loopVar=0
else
toFile=$toFile${data:1:-1}", "
let loopVar=loopVar+1
fi
done
T="$(($(date +%s)-T))"
echo "[${toFile::-2}]" >> "$dataDir/rhelCve.json"
sed -i 's/^\[\]$//g' "$dataDir/rhelCve.json"
printf "Got data in: %02dd:%02dh:%02dm:%02ds\n" "$((T/86400))" "$((T/3600%24))" "$((T/60%60))" "$((T%60))"
Get CVE infos for RHEL
Additional information:
If you query the NIST NVD Data and search for RHEL CPEs you won’t get a lot of hits as only a smal percentage of the CVEs that affect Red Hat software has the correct CPE attached. However – NIST NVD is nice to have because in the Red Hat CVEs only the total CVSS score is listed but no detailed vulnerability metrics are included.
Because Nessus seems to dislike Oracle ApEx we needed to remove it from the database. Oracles manual regrading the removal is pretty straight forward (https://docs.oracle.com/database/121/HTMIG/trouble.htm#HTMIG270), but I wanted to do it in a single none intreactive line which makes it easier to do de removal automated.
so – here it is:
echo quit | sqlplus -S "sys/sys as sysdba" @$ORACLE_HOME/apex/apxremov.sql
/* just another personal tech blog */
