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

 

Oggi mi è capitato di dover aggiungere una nuova CA alle mie root CA. In MAC OS X è molto semplice, basta eseguire il seguente comando:

sudo security add-trusted-cert -d -r trustRoot -k “/Library/Keychains/System.keychain” “/Users/utente/Desktop/root_CA.cer

naturalmente al posto della scritta rossa dovrete mettere il percorso di dove avete salvato la vostra CA nel vostro Mac.

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.