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.
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.
runas /user:administrator 'powershell -command Start-Process powershell -verb runas'
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.
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.
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.
If 3rd party software is installed it is quite likely that the autocomplete attribute for password fields is not set to off. Editing such settings directly in the sourceode is possible most of the time, but it’s not the nicest way and you also run into the problem that everything could be gone again after an update of the software.
A nice workaround is to use the substitute module to accomplish that.
Today I got some time to take care of my server so i installed the latest updates checkt the system for attacks and when I checkt my SSL-certificates i found out, that they were just valid till April 2015 … UPS … ok they are not officially signed and i just use them to encrypt sensitive communication with my server but i wanted to fix that issue and some other little issues i found when checking my blog with https://www.ssllabs.com/ssltest/analyze.html?d=blog.fawcs.info.
Because I also had to regenerate the certificates for my other subdomains I wrote a little script to do that for me (and to use it in the future, because I always have to look up the SSL-certificat generation)
So here is the script:
I also updated the security settings in my virtual host configuration files for some settings. The DH-KeyExchange cipher got excluded from the available ciphers because there is a new attack against DH which makes it vulnerable to MITM-attacks.
Extract of settings:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH !EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”
And it’s always a good idea to to use htaccess with extra users or IP-ACLs to secure specific directories. (for example the wp-admin directory 🙂 )
Some other interesting settings to macke apache more secure can be found her: http://www.tecmint.com/apache-security-tips/