Se avete abilitato SELINUX in modalità enforcing e provate ad avviare il demone zabbix-agent potreste ricevere l’errore:

Job for zabbix-agent.service failed because a configured resource limit was exceeded. See “systemctl status zabbix-agent.service” and “journalctl -xe” for details.

Infatti se andiamo a controllare l’audit log

grep zabbix_agent /var/log/audit/audit.log

possiamo vedere che AVC ha impedito l’azione setrlimit a zabbix_agentd

type=AVC msg=audit(1505217991.711:2169): avc: denied { setrlimit } for pid=9247 comm=”zabbix_agentd” scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:system_r:zabbix_agent_t:s0 tclass=process
type=SYSCALL msg=audit(1505217991.711:2169): arch=c000003e syscall=160 success=no exit=-13 a0=4 a1=7fff96165e20 a2=0 a3=8 items=0 ppid=1 pid=9247 auid=4294967295 uid=996 gid=993 euid=996 suid=996 fsuid=996 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm=”zabbix_agentd” exe=”/usr/sbin/zabbix_agentd” subj=system_u:system_r:zabbix_agent_t:s0 key=(null)

Per ovviare a questo problema basta aggiungere una nuova policy con il comando:

grep zabbix_agent /var/log/audit/audit.log | audit2allow -M zabbix_agent

ed attivarla

semodule -i zabbix_agent.pp

 

Scrivo questa guida perchè non ci sono molte informazioni online e potrebbe far comodo.

Per prima cosa occorre fermare il server unifi-video con il comando

service unifi-video stop

Poi occorre creare un certificato in formato pfx.

Se non lo avete, ma possedete i classici server.key, server.crt e ca_intermediate.crt dovrete eseguire il seguente comando:

openssl pkcs12 -export -in server.crt -inkey server.key -certfile ca_intermediate.crt -out /var/lib/unifi-video/server.pfx -name “airvision”

ATTENZIONE ! vi verrà richiesto di mettere una password, inserite ubiquiti

Altrimenti se possedete già un pfx, occorre mettere la password del certificato ubiquiti e trovare l’alias con il comando

keytool -list -keystore server.pfx -storetype pkcs12

verrà un output del genere:

Tipo keystore: PKCS12
Provider keystore: SunJSSE

Il keystore contiene 1 voce

1, 5-mag-2015, PrivateKeyEntry,
Impronta digitale certificato (SHA1): BB:76:85:60:DC:AE:FF:FF:GG:HH:UU:EE:FB:78:74:85:11:FF:FB:15

il nome dell’alias è quello evidenziato in rosso

ora andiamo nella cartella /var/lib/unifi-video e digitiamo

keytool -delete -keystore keystore -storepass ubiquiti -alias airvision

e poi

keytool -importkeystore -srcstoretype pkcs12 -srcalias airvision -srckeystore server.pfx -keystore keystore -destalias airvision

ATTENZIONE ! vi verrà richiesto di mettere una password, inserite ubiquiti
e se possedete un vostro pfx mettete al posto di airvision il nome/numero che avete trovato con il comando keytool -list

se andato tutto a buon fine andiamo ad editare il file /usr/lib/unifi-video/conf/server.xml e cambiamo le righe

keystoreFile=”${app.keystore.file}”
keystorePass=”${app.keystore.pass}”

in

keystoreFile=”/var/lib/unifi-video/keystore”
keystorePass=”ubiquiti”
keyAlias=”airvision”

ora riavviamo il nostro server unifi-video con il comando

service unifi-video start

il gioco è fatto !

Dopo Heartbleed e Shellshock è arrivata una nuova falla: POODLE (Padding Oracle On Downgraded Legaxy Encryption). La vulnerabilità sfrutta l’ormai vecchio protocollo SSLv3 che è sempre usato da moltissimi vecchi browser. Infatti basta lanciare un attacco man-in-the-middle per decifrare i cookie, i quali possono anche contenere informazioni delicate, e adoperare i dati così ottenuti per accedere ai servizi online che ne fanno uso. Sul sito di openssl è riportato un documento che spiega meglio il problema: https://www.openssl.org/~bodo/ssl-poodle.pdf

Ecco un workaround per prevenire l’attacco su Apache in Debian:

aprire il file nano /etc/apache2/sites-available/default-ssl

dopo l’istruzione SSLEngine on inserire

SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGC$
SSLHonorCipherOrder on
SSLCompression off

Ormai i tentativi di intrusioni sono all’ordine del giorno. Per migliorare la sicurezza dei vostri wordpress ecco una mini-how to che spiega come configurare fail2ban in modo che metta in jail gli ip che provano ad effettuare i login ai vari wordpress.

Per prima cosa editiamo il file /etc/fail2ban/jail.conf e aggiungiamo in fondo le seguenti righe:

[codesyntax ]

[apache-wp-login]
enabled = true
port    = http,https
action   = iptables[name=WP, port=http, protocol=tcp]
filter  = apache-wp-login
logpath = /var/www/vhosts/*/logs/access_log  # qui occorre inserire la path dove risiedono i vari access log dei vari domini
maxretry = 3

[/codesyntax]

poi creiamo il file /etc/fail2ban/filter.d/apache-wp-login.conf e al suo interno inseriamo le seguenti righe:

[codesyntax]

# Fail2Ban configuration file
[Definition]
failregex = <HOST>.*] "POST /wp-login.php
ignoreregex =

[/codesyntax]

una volta effettuato riavviamo fail2ban con il comando /etc/init.d/fail2ban restart

ecco fatto ! basta guardare iptables (con il comando iptables -L) per vedere se vengono messi in jail subito degli ip.

Ecco i pacchetti da installare per i tool testuali del setup du Centos e/o Redehat

  • system-config-securitylevel-tui: per confugurare il firewall
  • authconfig: per configurare l’autenticazione
  • system-config-network-tui: per configurare le schede di rete
  • ntsysv: per configurare i servizi di sistema