UrBackup, optimiza tus copias de seguridad

Después de algunos días viendo diferentes opciones para realizar las copias de seguridad dependiendo del entorno, he topado con una solución que viene como anillo al dedo para la mayoría de casos, sean en entorno domestico o profesional, para VPS Linux o para un PC Windows: URBACKUP.

¿Que es UrBackup?

UrBackup es un servicio que se ejecuta sobre Windows o Linux, y que permite administrar diferentes copias de seguridad en equipos que tengan instalado su cliente, independientemente del sistema operativo que utilicen. Además, esta disponible como paquete, como distribución (Linux+UrBackup) o como plugin para OpenMediaVault, la que yo he utilizado.

OMV, un par de discos y un RAID

Para almacenar las copias de seguridad de diferentes maquinas, instalé un OpenMediaVault en un PC bastante antiguo, y con un hardware, la verdad, bastante flojo.
Una CPU Core2Duo E6400, 1GB de RAM, un disco de sistema de 250GB y un par para las copias, también de 250GB. De media, con un uso muy básico y sin pantalla ni periféricos, consumiendo 60W/h. No esta mal.

Instalé OMV en el disco principal, y hice un RAID1 con los dos de 250GB. Además, programé copias diarias de los backups del RAID al disco de sistema, para tenerlo todo duplicado.
Al principio, tan solo utilizaba las carpetas creadas en el RAID para copias los datos a través de SSHFS, con BackupNinja tal y como explico en este post -> Backups remotos con BackupNinja y SSHFS.

Pero al descubrir UrBackup como una alternativa a VeamBackup, y ver que era compatible con OMV, me lancé sin dudarlo.

Instalación del servidor UrBackup

La instalación del servidor de UrBackup es sencilla, un ejecutable en Windows Server y desde los repositorios en Ubuntu o Debian:

Una vez instalado, la configuración es bastante intuitiva. Si vamos a realizar copias a través de Internet, debemos abrir el puerto para la copia (por defecto: 55413) y si queremos administrarlo por web (no lo recomiendo, por defecto puerto: 55414). Tenemos que abrir los puertos one to one, que el puerto externo o el interno siempre sea el mismo, ya que sino la configuración del servidor se machacará en el cliente.

Instalación del cliente UrBackup

Instalaremos los clientes en cada ordenador o servidor al que queramos realizar copias de seguridad.
Para Windows tan sencillo como un ejecutable, pero en Linux hay que compilarlo. Nada complicado:

Instalamos las dependencias que necesita UrBackup :

apt install build-essential “g++” libwxgtk3.0-dev “libcrypto++-dev” libz-dev

Atención: si no vamos a utilizar el entorno gráfico porque es un server, no hace falta que instalemos el paquete libwgtk3.0-dev, que además es muy pesado. A la hora de compilar también será diferente, seguir leyendo.

Descargamos el codigo fuente y lo extraemos:

wget https://hndl.urbackup.org/Client/2.2.6/urbackup-client-2.2.6.tar.gz
tar xzf urbackup-client-2.2.6.tar.gz

Y hacemos el build y la instalación:

cd urbackup-client-2.2.6
./configure

Cuidado, si no queremos el entorno gráfico, haremos el configure así:

./configure –enable-headless

Y seguimos:

make -j4
sudo make install

Comprobaremos que corra correctamente:

sudo urbackupclientbackend -v info

Añadimos el cliente UrBackup al inicio del sistema:

sudo chmod +x /etc/rc.local
nano /etc/rc.local

Y añadimos antes del exit 0:

/usr/local/sbin/urbackupclientbackend -d

Configuración del cliente

Una vez lo tenemos funcionando, vamos a conectarlo con el servidor.
Si estas en la misma red local, bastará con realizar un descubrimiento desde el panel web del servidor.
En el caso de que este en Internet, tienes que habilitar la opción en el servidor, tal que así:

Ahora, en el pagina principal (Estado) del servidor, añade un nuevo cliente. Selecciona Internet y escribe el nombre de maquina, es muy importante que sea correcto o no funcionará. Si no estas seguro, ejecuta

hostname
.

Una vez añadido, te aparecerá una pantalla con instrucciones para la instalación, pero si ya lo has hecho de la manera anterior, es parecido.

Ahora vamos a Ajustes, selecciona el Cliente, si solo tienes uno es Ajustes de cliente, y a la opción Internet.
Copia la clave que aparece como: Clave de copia por Internet. En el siguiente paso la pondremos en el campo CLAVE_COPIA.

Ahora volvemos al cliente, y crearemos el fichero de configuración:

nano /usr/local/var/urbackup/data/settings.cfg

Y añadiremos las siguientes lineas, modificandolas con los datos del servidor:

internet_server=Nombre_SERVER
internet_server_port=55415
internet_authkey=CLAVE_COPIA
internet_mode_enabled=true

Una vez hecho esto, ejecutaremos el siguiente comando, que se conectará con el servidor, y descargará toda la configuración sobre las copias, etc:

urbackupclientbackend -i -v debug

Ahora, solo nos quedará configurar en el panel web del servidor, los archivos por defecto a copiar, los archivos o carpetas a excluir, etc.
Automáticamente programará las copias cada ciertas horas de manera incremental, y también los backup de imagen del sistema, que nos permitirá restaurarlo de forma completa en caso de fallo.

Espero que te haya servido, y si es así: compártelo!

 

Backups remotos con BackupNinja y SSHFS

Una vez tenemos nuestro servidor instalado y seguro, no nos podemos olvidar de realizar copias de seguridad cada cierto tiempo, y si es posible realizarlas remotamente para evitar desastres, mucho mejor.

Por ejemplo, si tienes un servidor dedicado o un VPS, tiene poco o ningún sentido hacer dumps de las bases de datos y dejarlas en el mismo servidor. Así que una forma sencilla de realizar backups remotamente es a través de SSH (cifrado, seguro y rápido). Puedes montar un servidor de copias de seguridad local en tu casa o trabajo, ya que a través de una linea de fibra se realizarán rápidamente si no tienes mucho volumen de datos. Vamos a ello!

Claves SSH

Lo primero, lo que ahora es nuestro servidor web, sera el cliente SSH que se conectará al servidor de copias de seguridad. Así que generaremos unas claves para poder conectarnos sin contraseña.

ssh-keygen -b 4096 -t rsa -C “$(whoami)@$(hostname)-$(date -I)”

Y copiamos la clave al servidor de copias

scp – ~/.ssh/id_rsa.pub USUARIO@HOST:/home/USUARIO/.ssh/

Ahora, en el servidor de copias, añadiremos la clave al authorized_keys

cat /home/USUARIO/.ssh/id_rsa.pub > /home/USUARIO/.ssh/authorized_keys

Ahora probaremos que la conexión funcione sin pedirnos la clave:

ssh USUARIO@HOST

Si es correcto, ya podemos instalar el software para montar el directorio y realizar las copias.

Instalación y configuración

sudo apt-get install backupninja sshfs

Una vez instalado podemos crear con BackupNinja los tipos de copia que necesitemos, para ello usaremos el comando ninjahelper

ninjahelper

Y abrira la CGI, donde podemos escoger si queremos copias de MySQL, PostgreSQL o de archivos en TAR o RDIFF.

Una vez creemos las tareas, las podemos encontrar en /etc/backup.d/, por ejemplo 10.tar y 20.mysql.

Las mismas tareas de backupninja se pueden programar para que se guarden en un Ahora haremos un pequeño script que montara el directorio SSH y empezará la copia:

nano .sshfsbackup
#!/bin/bash

sshfs USUARIO@HOST:/carpeta_server /mnt/backup

backupninja –run /etc/backup.d/20.mysql

backupninja –run /etc/backup.d/10.tar

fusermount -u -z /mnt/backup/[terminal]

Y le damos permisos de ejecución:

[terminal]sudo chmod +x sshfsbackup.sh

Si no quieres utilizar BackupNinja, también puedes programar los dumps de la base de datos y la copia de los archivos desde la misma consola, este sería un ejemplo del programa:

#!/bin/bash

HOY=$(date +%Y-%m-%d)

sshfs USUARIO@HOST:/carpeta_server /mnt/backup

mysqldump -u root  –all-databases > /mnt/backup/sqldump/alldb_$HOY.sql

tar -cvf /mnt/backup/tar/backup_$HOY.tar /directorio_a_copiar

fusermount -u -z /mnt/backup/

Ahora lo añadimos al Cron para que se ejecute cada dia a las 2 de la madrugada. Asi que editamos el crontab, y añadimos esto:

crontab -e
0 2 * * * sh /root/backups/sshfsbackup.sh

Para que no se acumulen carpetas y archivos de copias en el servidor de backups, también creamos un pequeño script para que vaya eliminando las antiguos. Yo por ejemplo, guardo las copias de los ultimos 10 dias:

nano /home/usuario/purgar.sh

Y añadimos el siguiente codigo, substituyendo las carpetas con las vuestras:

#!/bin/bash

find /carpetabackup/tar/* -mtime +10 -exec rm {} \;
find /carpetabackup/sqldump/* -mtime +10 -exec rm {} \;

Y listo, copias completas programadas remotamente. ¡Espero que os haya servidor!

Protege tu servidor Linux desde cero

Si tienes un servidor Linux público, ya sea un VPS o un servidor dedicado, lo primero que tienes que hacer nada más comprarlo e instalarlo, es securizarlo.
De esta manera te evitaras sorpresas y ataques que son muy frecuentes, y descansaras un poco más tranquilo por las noches.

Para empezar, recomiendo totalmente utilizar un Firewall para tan solo escuchar a través de los puertos que necesitemos, y lo podemos hacer muy fácilmente con IPTABLES.

Sigue esta guía para hacerlo fácilmente -> Protege tu servidor con CSF y IPTables

 

 

Fail2Ban

Bloquea cualquier acceso no deseado

 

Lo primero, instalar Fail2Ban. Es el software principal para evitar accesos no deseados y ataques en tu servidor. Si tienes un Debian/Ubuntu, como siempre, solo tienes que ejecutar este comando:

sudo apt-get install fail2ban

Una vez instalado, yo recomiendo endurecer un poco la configuración para que los baneos se hagan más pronto y duren más.
Para ello editaremos el fichero /etc/fail2ban/jail.conf

sudo nano /etc/fail2ban/jail.conf

Una vez dentro, cambiaremos el valor de maxretry a las veces se pueda fallar al poner la contraseña, por defecto 6, yo lo suelo poner en 3.
Después tenemos el tiempo de baneo, que esta en 600 segundos, y yo, sin dudarlo, le añado un 0: 6000 segundos.

bantime = 6000
maxretry = 3

Si queremos añadir una IP a la whitelist, para que no se banee aunque se fallen más de 2 veces (una IP local, o si tienes una IP estática en casa o el trabajo) lo añadiremos en la linea ignoreip, separado por espacios:

ignoreip = 127.0.0.1/8 192.168.1.1./24 80.80.80.80

Ahora, si quieres ver un log de las IP’s que se van baneando, ejecuta este comando:

sudo tail -f /var/log/fail2ban.log

 

 

Acceso SSH

Deshabilita el acceso a root y cambia el puerto

Es totalmente recomendable, y casi obligado, quitar el acceso por SSH con el usuario root, ya que la mayoría de robots de fuerza bruta es el primer usuario que prueban, y que si aciertan, les daria permisos de superuser. Así que, creamos un usuario nuevo para las conexiones por SSH, por ejemplo pepito.

adduser pepito

Le asignamos una contraseña segura y le damos permiso para ejecutar sudo y elevar permisos. Para ello, editamos el fichero sudoers:

nano /etc/sudoers

Y añadimos la siguiente linea:

pepito ALL=(ALL:ALL) ALL

Guardamos, y ahora vamos a deshabilitar el usuario root por SSH, para ello, editamos el fichero de configuración del mismo:

nano /etc/ssh/sshd_config

Y cambiamos la siguiente linea de yes a no:

PermitRootLogin no

Ahora, añade al archivo el usuario pepito para que puedas acceder por SSH:

AllowUsers pepito

Y si puedes, cambia el puerto para acceder, ya que el 22 es el por defecto, y casi todos los bots intentan atacar a ese puerto, así que escoge otro (en el ejemplo, el 2222):

Port 2222

Recuerda permitir el puerto que hayas puesto en el Firewall, antes de reiniciar el servicio y te deje fuera.

 

 

Mod Security

Detecta ataques en tu servidor web

Para proteger tu servidor web frente a ataques contra tus sitios e inyecciones de SQL, la mejor opción es el modulo Mod Security para Apache.
Para instalarlo, es tan sencillo como ejecutar en tu terminal:

apt-get install libapache2-modsecurity

O dependiendo de la versión de Apache que tengas, la versión 2:

apt-get install libapache2-mod-security2

Una vez instalado, usaremos la configuración por defecto, que ya viene en un archivo que debemos renombrar:

mv /etc/modsecurity/modsecurity.conf{-recommended,}

Y reiniciamos el servicio:

service apache2 reload

Ya encontraremos el fichero de log en el sistema:

ls -l /var/log/apache2/modsec_audit.log

Ahora modificaremos las opciones del archivo de configuración, ya que por defecto el modulo no bloquea nada, solo detecta. Para ello abriremos el archivo:

nano /etc/modsecurity/modsecurity.conf

Y buscaremos la siguiente opcion:

SecRuleEngine DetectionOnly

Y la dejaremos en On:

SecRuleEngine On

Otra directiva para modificar es SecResponseBodyAccess. Esto configura si los “response bodies” se almacenan en búfer. Esto solo es necesario si se requiere detección y protección contra fugas de datos. Por lo tanto, dejarlo activado utilizará más recursos y también aumentará el tamaño del archivo de log. Así que buscaremos esta opción:

SecResponseBodyAccess On

Y la dejaremos así:

SecResponseBodyAccess Off

También podemos modificar el limite de tamaño para el post en el servidor web, cambiando los valores de estas opciones:

SecRequestBodyLimit

SecRequestBodyNoFilesLimit

Para hacerte la vida más fácil, hay muchas reglas que ya están instaladas junto con mod_security. Se llaman CRS (Core Rule Set) y se encuentran este directorio:

ls -l / usr / share / modsecurity-crs /
total 40
drwxr-xr-x 2 root root 4096 Oct 20 09:45 activated_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 base_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 experimental_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 lua
-rw-r – r– 1 root root 13544 2 jul 2012 modsecurity_crs_10_setup.conf
drwxr-xr-x 2 root root 4096 Oct 20 09:45 optional_rules
drwxr-xr-x 3 root root 4096 oct. 20 09:45 util

La documentación está disponible en

ls -l / usr / share / doc / modsecurity-crs /
total 40
-rw-r – r– 1 root root 469 jul 2 2012 changelog.Debian.gz
-rw-r – r– 1 root root 12387 18 de jun. de 2012 changelog.gz
-rw-r – r– 1 root root 1297 jul 2 2012 copyright
drwxr-xr-x 3 root root 4096 Oct 20 09:45 ejemplos
-rw-r – r– 1 root root 1138 Mar 16 2012 README.Debian
-rw-r – r– 1 root root 6495 Mar 16 2012 README.gz

Para cargar estas reglas, debemos decirle a Apache que busque en estos directorios. Edite el archivo modsecurity.conf.

nano /etc/apache2/mods-enabled/modsecurity.conf

Agrega las siguientes directivas dentro de <IfModule security2_module> </ IfModule>:

include “/usr/share/modsecurity-crs/*.conf”
include “/usr/share/modsecurity-crs/activated_rules/*.conf”

El directorio activated_rules es similar al directorio de mods habilitado de Apache. Las reglas están disponibles en directorios:

/ usr / share / modsecurity-crs / base_rules
/ usr / share / modsecurity-crs / optional_rules
/ usr / share / modsecurity-crs / experimental_rules

Los enlaces simbólicos se deben crear dentro del directorio activated_rules para activarlos. Vamos a activar las reglas de inyección de SQL.

cd / usr / share / modsecurity-crs / activated_rules /
ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf.

Apache tiene que volver a cargarse para que las reglas se activen:

service apache2 reload

Espero que os haya servido como punto de partida para proteger un servidor Linux.

Las fuente para la configuración de ModSecurity es esta -> https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu

 

 

Protege tu servidor con CSF y IPTables

Queda claro que cuando contratas un servidor, un VPS, o pones una maquina visible en Internet, es totalmente necesario protegerla frente ataques y accesos no deseados.
Para ello, es imprescindible un Firewall. GNU/Linux utiliza el famoso software IPTABLES, también muy usado en otros dispositivos como routers, dada su eficacia y simplicidad.
Pero para un usuario o administrador que lleva mil temas en la cabeza, no es fácil recordad la sintaxis de Iptables, así que existen herramientas que nos facilitan mucho la vida. Yo, por ejemplo, uso CSF.

Es un software muy simple que recoge toda la configuración en algunos archivos, y luego crea las reglas con Iptables en nuestro equipo de manera automática, incluso pudiendo habilitar una interfaz gráfica, pese a que no os lo recomiendo.

Instalación

Para utilizarlo, lo primero es descargar la ultima versión de su sitio web, y para ello usamos wget:

wget https://download.configserver.com/csf.tgz

Ahora lo descomprimimos:

tar -xzf csf.tgz

Entramos en la carpeta que acaba de crear, y ejecutamos la instalación:

sh csf/install.sh

Al acabar, debería mostraros el siguiente mensaje:

Installation Completed

Podemos comprobarlo con el siguiente comando:

perl /usr/local/csf/bin/csftest.pl

Y deberiais tener este resultado:

RESULT: csf should function on this server

Si es así, ya tenemos CSF correctamente instalado.

Configuración

Lo primero que recomiendo hacer antes de hacer modificaciones y arrancar el firewall, es agregar tu IP a la Whitelist, por si te equivocas en bloquear algún puerto, no te deje fuera.
Para ello, solo tenemos que agregar las IP’s que queramos, una por linea, en el archivo /etc/csf/csf.allow

nano /etc/csf/csf.allow

Ahora, podemos ir al archivo de configuración y modificar lo que necesitemos para adaptarlo a nuestro servidor.

nano /etc/csf/csf.conf

Aquí veremos muchos parámetros, pero lo más relevante, son los puertos y el modo testing.

La primera opción que vemos es TESTING = “1”. Si lo dejamos así, pese que arranquemos el servidor, no se aplicaran los cambios. Debemos ponerlo a 0 cuando tengamos toda la configuración hecha.
Para testear la configuración, puedes usar la opción TESTING_INTERVAL = “”, para probar la configuración tantos minutos como le indiquemos, antes de deshacerla.

Ahora veremos las opciones por defecto para permitir puertos tanto en TCP o en UDP. En el archivo se incluyen de esta manera, que podemos modificar fácilmente añadiendo o quitando los puertos:

TCP_IN = “20,21,22,25,53,80,110,143,443,465,587,993,995”
TCP_OUT = “20,21,22,25,53,80,110,113,443”
UDP_IN = “20,21,53”
UDP_OUT = “20,21,53,113,123”

Una vez hayamos modificado todos los parámetros, podemos arrancar o reiniciar el servicio con este comando:

csf -r

Os recomiendo miraros muy bien toda la configuración, ya que tiene muchas posibilidades.

Ahora, podéis comprobar que los puertos están abiertos o cerrados tal y como habéis configurado con nmap (recuerda hacerlo desde una IP que no tengas en la whitelist).

sudo nmap -sT -O  IP_DE_TU_SERVIDOR

¡Espero que os haya servido!

Configura un servidor de correo Postfix en Sentora/Zpanel desde cero

Con este post pretendía explicar como configurar un servidor de email con Postfix, Dovecot y SpamAssassin desde cero, con un panel de control Sentora o ZPanel,
pero dado la extensión de cada una de las configuraciones, he decidido dejarlo como una guia donde indico las fuentes que yo he utilizado y me han sido más utiles a la hora de realizar esta configuración.

Configurando Sentora / ZPanel

Una vez añadimos un dominio nuevo a zpanel o Sentora, tenemos que crear las zonas:
Nos vamos al apartado de Manage DNS, seleccionamos el dominio, y apretamos el botón de Create zone DNS.
Aunque nuestro servidor no se utilice como servidor de DNS, es necesario tener creadas las zonas para que resuelva correctamente.
Lo siguiente es modificar los registros DNS, sea en la pagina donde has registrado el dominio utilizando sus propios DNS, o en tu ZPanel si has indicado que es tu servidor de DNS.
Modificamos los registros DNS del dominio:

Registro A -> IP_SERVIDOR
Registro MX -> @/IP_SERVIDOR
Registros SPF: v=spf1 a mx -all

Ya podemos crear los buzones de correo que necesitemos desde el Zpanel o Sentora.

Podemos modificar las Cuotas por defecto de espacio del buzón en Admin > Module admin > Mail Config, en la opción Max Mailbox Size.

En el caso de que queramos ampliar la cuota de correo de un usuario ya creado, lo tenemos que hacer desde la base de datos MySQL, en las tablas de Postfix.

Ahora, vamos a configurar DKIM para verificar que el origen de los emails es correcto.

¿Qué és DKIM? El sistema DKIM (DomainKeys Identified Mail) es una evolución del sistema DomainKeys desarrollado inicialmente por Yahoo como un mecanismo para que un mail pueda ser validado por un destinatario comprobando de forma inequívoca que el origen del mismo es realmente el que aparece en las cabeceras del email

Para crear DKIM recomiendo seguir el siguiente tutorial en Español: -> https://www.comalis.com/ayuda/como-configurar-dkim-en-una-maquina-con-postfix

Ahora crearemos los registros DMARC en el servidor DNS. Como ya hemos creado el SPF y DKIM, será mñas sencillo.

¿Qué és DMARC? El estándar DMARC (Autenticación de mensajes, informes y conformidad basada en dominios) es el último gran avance en autenticación de correos electrónicos. … Un mensaje no será validado por DMARC si falla tanto (1) SPF o la alineación SPF como (2) DKIM o la alineación DKIM

Para crear los registros DMARC que insertaremos en el servidor de DNS, utilizaremos la siguiente herramienta de MXTOOLBOX -> https://mxtoolbox.com/DMARCRecordGenerator.aspx?

Cifrando las conexiones

Ahora, crearemos los certificados para que podamos conectarnos con el servidor de email de manera segura y cifrada.
Para ello, primero, debermos crear los certificados para el servidor de correo si no lo hemos hecho todavia. Se crean igual que para una pagina web utilizando LetsEncrypt. Sigue este tutorial -> SSL con LetsEncript
Luego, lo añadiremos en el archivo main.cf de la configuración de Postfix. Comenta las siguientes opciones sobre SMTP y TLS, y añade este fragmento de código apuntando a los certificados recién creados con LetsEncrypt:


smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache
smtpd_tls_cert_file = /etc/letsencrypt/live/tu_dominio/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/tu_dominio/privkey.pem

También añadiremos los certificados en el archivo de configuración de Dovecot: /etc/dovecot/dovecot.conf, quedando así:


ssl = yes
ssl_cert = </etc/letsencrypt/live/tu_dominio/fullchain.pem
ssl_key = </etc/letsencrypt/live/tu_dominio/privkey.pem

Aquí tenemos una guía completa para configurar Postfix con LetsEncrypt -> https://www.upcloud.com/support/secure-postfix-using-lets-encrypt/
De esta manera, al enviar un email ya no aparecerá el candado rojo en GMail, por ejemplo.

SpamAssassin

Para proteger nuestros buzones de miles de correo de SPAM, tenemos que configurar SpamAssassin para que filtre y mande a la carpeta de Junk esos correos tan molestos.
Así que vamos a instalarlo y configurarlo:

apt-get install spamassassin spamc

Una vez instalado, creamos el grupo y el usuario (sin acceso a la shell):

groupadd spamd

useradd -g spamd -s /bin/false -d /var/log/spamassassin spamd

Creamos el directorio y cambiamos los permisos

mkdir /var/log/spamassassin
chown spamd:spamd /var/log/spamassassin

Y ahora editamos la configuración:

nano /etc/default/spamassassin

Cambiando los siguientes valores:

ENABLED=0 por ENABLED=1
CRON=0 por CRON=1
Buscamos OPTIONS y cambiamos la linea por lo siguiente:
OPTIONS=”–create-prefs –max-children 2 –username spamd \ -H ${SAHOME} -s ${SAHOME}spamd.log”

Ahora ejecutamos este comando para crear una variable con el directorio de SpamAssassin:

SAHOME=”/var/log/spamassassin/”

E iniciamos el servicio:

service spamassassin start

Ahora abrimos la configuración de Postfix:

nano /etc/postfix/master.cf

Buscamos las siguientes lineas:

smtp inet n – – – – smtpd

Y añadimos lo siguiente al final:

-o content_filter=spamassassin” after smtpd

Quedando así:

smtp inet n – – – – smtpd-o content_filter=spamassassin” after smtpd

Y en el final del archivo también añadimos la siguiente linea, que define los usuarios que utiliza y que ejecutables:

spamassassin unix – n n – – pipe user=vmail:mail argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Reiniciamos postfix:

service postfix restart

Ahora volvemos a editar las reglas de SpamAssassin:

nano /etc/spamassassin/local.cf

Y cambiamos el siguiente valor, que define la puntuación necesaria para que un mensaje sea marcado como SPAM:

 required_score 5.0 a required_score 3.0

Y activamos el auto-aprendizaje cambiando estos valores:

use_bayes de 0 a 1
bayes_auto_learn de 0 a 1

Reiniciamos el servicio, y a funcionar:

service spamassassin restart

Fuente -> http://forums.sentora.org/showthread.php?tid=22

CUIDADO, en Sentora, los archivos de configuración de Dovecot están apuntando a otro lado (lo que es el filtraje, global.filter etc, solo hay que cambiar en enlace simbólico)

Para testear que funciona bien el filtraje de SPAM, puedes enviar un email con el siguiente mensaje, que dará la puntuación máxima:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

¡Espero que os haya servido!

HTTPS en Prestashop 1.7

En las ultimas semanas he montado un par de Prestashops 1.7, y a la hora de lanzarla, me he encontrado con varios problemas para activar HTTPS a pesar de tener los certificados bien configurados con Lets Encrypt.

Desde el panel, no podía activar el SSL, ya que al realizar la comprobación, me devolvía a la pagina sin activar el botón:

Modificar tabla en MySQL

Para poder activarlo, hemos de ir a la base de datos MySQL y modificar una tabla:
La tabla se llama ps_configuration, y el campo a modificar: PS_SSL_ENABLED , que hay que darle el valor 1 (por defecto 0).

Al hacerlo, ya aparece el botón activado en el panel.

De todas maneras, la pagina no carga correctamente con HTTPS, y las imágenes y estilos CSS no se aplican a la versión segura.
Después, si activamos el botón Activar SSL en todas las paginas, nos encontramos que la pagina entra en un bucle y el navegador nos muestra el siguiente error

ERR_TOO_MANY_REDIRECTS

Modificar .htaccess

Para solucionar este problema, es añadir al archivo .htaccess del hosting (el de la raiz de la pagina) la siguiente opción en la primera linea del fichero:

SetEnv HTTPS On

Una vez guardado, veremos como la pagina ya carga correctamente con el protocolo HTTPS, y si no tenemos ninguna imagen o elemento que se muestre o sirva por HTTP, podremos ver las letras “Es seguro” con el candado en la barra de navegación.

Si te ha servido… ¡Comparte!

 

Quitar anuncios de Spotify en Linux

Os traigo un sencillo truco para eliminar totalmente los anuncios de Spotify en Linux ( y en Windows también funciona ).
Tan solo tenemos que añadir unas direcciones en nuestro archivo /etc/hosts, para cuando el navegador o el cliente de Spotify intente conectarse, le de un timeout, y continúe con la reproducción de la siguiente canción. Muy útil y rápido. También incluye algunas direcciones de otro tipo de publicidad como de Google (partner.googleadservices.com), así que mejor que mejor.

Editamos el fichero con permisos de superusuario:

sudo nano /etc/hosts

Y añadimos las siguientes lineas:
##BLOCKING ADS

0.0.0.0 adclick.g.doublecklick.net

0.0.0.0 adeventtracker.spotify.com

0.0.0.0 ads-fa.spotify.com

0.0.0.0 analytics.spotify.com

0.0.0.0 audio2.spotify.com

0.0.0.0 b.scorecardresearch.com

0.0.0.0 bounceexchange.com

0.0.0.0 bs.serving-sys.com

0.0.0.0 content.bitsontherun.com

0.0.0.0 core.insightexpressai.com

0.0.0.0 crashdump.spotify.com

0.0.0.0 d2gi7ultltnc2u.cloudfront.net

0.0.0.0 d3rt1990lpmkn.cloudfront.net

0.0.0.0 desktop.spotify.com

0.0.0.0 doubleclick.net

0.0.0.0 ds.serving-sys.com

0.0.0.0 googleadservices.com

0.0.0.0 googleads.g.doubleclick.net

0.0.0.0 gtssl2-ocsp.geotrust.com

0.0.0.0 js.moatads.com

0.0.0.0 log.spotify.com

0.0.0.0 media-match.com

0.0.0.0 omaze.com

0.0.0.0 open.spotify.com

0.0.0.0 pagead46.l.doubleclick.net

0.0.0.0 pagead2.googlesyndication.com

0.0.0.0 partner.googleadservices.com

0.0.0.0 pubads.g.doubleclick.net

0.0.0.0 redirector.gvt1.com

0.0.0.0 s0.2mdn.net

0.0.0.0 securepubads.g.doubleclick.net

0.0.0.0 spclient.wg.spotify.com

0.0.0.0 tpc.googlesyndication.com

0.0.0.0 v.jwpcdn.com

0.0.0.0 video-ad-stats.googlesyndication.com

0.0.0.0 weblb-wg.gslb.spotify.com

0.0.0.0 www.googleadservices.com

0.0.0.0 www.googletagservices.com

0.0.0.0 www.omaze.com


Y listo!

Para Windows, seria añadir las mismas lineas en el fichero \WINDOWS\system32\drivers\etc\hosts.

 

Alternativas seguras a las apps y servicios habituales

Después de las ultimas noticias sobre las filtraciones de datos de carácter privado por Facebook y otras compañias, mucha gente ha puesto el grito en el cielo sobre la privacidad de sus datos. Aunque es cierto que ahora parece que la sociedad esta tomando más consciencia de que publica, y donde, muchas veces aceptamos sin más que nuestros datos vayan a ser revendidos o cedidos a otras empresas para su propio beneficio.
Hoy os traigo algunas alternativas a los programas y aplicaciones convencionales que utilizamos cada día, pero que nos aseguran que nuestros datos no van a ser vendidos.
Empezar con estas aplicaciones es un buen comienzo a no dejar tanto rastro digital y no dar nuestros datos a terceros.

 

GMail – ProtonMail

ProtonMail es un servicio de correo electrónico cifrado, creado en 2013 en el centro de investigación CERN. Garantiza la privacidad de tus datos y de tus correos electronicos.
Es una muy buena alternativa a GMail. Cuenta con aplicación en Play Store para Android, y su interfaz web es muy limpia y sencilla. La unica pega, que no ofrece tanto espacio de almacenamiento como Google.
Os recomiendo que lo probeis, junto con la aplicación ProtonVPN para navegar de forma segura.

Puedes registrate en la web de ProtonMail y descargar la aplicación en Play Store.

 

WhatsApp – Telegram

Después del escándalo por la petición de Rusia a Telegram de todas las claves para descifrar los mensajes de sus usuarios, y la negativa de la compañia a poner en riesgo la privacidad de los datos de sus usuarios, todavía tenemos más confianza en esta aplicación de mensajería instantánea. Además cuenta con cliente para ordenador (incluido Linux). Lo dificil: convencer a tus amigos y familiares de que también hagan el cambio…

Descarga Telegram desde Play Store o desde su pagina web oficial.

 

Buscador Google – DuckDuckGo

DuckDuckGo es un motor de búsqueda establecido en Valley Forge, Pensilvania, Estados Unidos. Este motor utiliza la información de sitios de origen público con el objetivo de aumentar los resultados tradicionales y mejorar la relevancia. Prometen que no guardan ninguna información sobre nosotros ni nuestras busquedas, ni se utilizan para mostrar publicidad personalizada. Una de las mejores alternativas al buscador de Google, y posiblemente la mejor si hablamos de privacidad.

Para usarlo, simplemente dirígete a su web, y para acostumbrarte, ponla como pagina de inicio!
También cuenta con un navegador para Android, que puedes descargar desde el Play Store.

 

Google Chrome – Mozilla Firefox / Tor

Con Firefox Focus podemos bloquear trackers o herramientas de seguimiento como cookies, que sirven a redes sociales y anunciantes a conocer tus patrones de navegación.
Además, si utilizamos Tor para ordenador (incluye una versión de Firefox) , también podemos evitar que los proveedores de internet sepan desde dónde accedes, qué consultas en la red y acceder a páginas bloqueadas en tu país.

Descarga Firefox Focus desde Play Store para Android.
Para ordenador, puedes descargar Tor desde aquí.

Espero que te haya gustado, ¡comparte!

Navega seguro desde tu Android

Esta semana hemos sabido que Opera VPN dejaba de ser gratuito para todos los usuarios. Una de las cosas más valorables es la tranquilidad de navegar tranquilo sabiendo que tus datos se están enviando de manera segura a través de cualquier red, y eso en un Smartphone es doblemente importante, ya que muchos solemos desplazarnos a diferentes lugares donde las redes son publicas, o la que casi cualquiera puede acceder, y por lo tanto, pueden estar comprometidas.

No siempre es fácil tener un servidor VPN en casa o en un servidor propio, además de que también continuaríamos saliendo por nuestra propia dirección IP.

Para mi, la alternativa más fiable y que mejores resultados me da es la aplicación ProtonVPN. De los mismos creadores que ProtonMail, el correo ultra privado creado por el CERN, esta aplicación nos permite conectarnos a una multitud de servidores VPN de manera rápida y sencilla, pudiendo elegir nuestras preferencias: servidor más rápido, más seguro, o más cercano. Otro de los factores que le otorgan fiabilidad es la situación estratégica de la compañía, en Suiza, uno de los países con reglas más estrictas sobre la privacidad de las datos de los usuarios y clientes.

El único requisito es tener una cuenta de ProtonMail, en la que os podéis registrar en su pagina web.

Puedes descargar la aplicación desde Google Play.

 

SSL con LetsEncript

Cuando el protocolo HTTP se actualice a su versión 2, todas los sitios webs deberán tener un certificado SSL valido para que las conexiones sean seguras. Los navegadores bloquearan o mostraran explicitamente como “no seguras” las que no lo tengan, penalizando en su posicionamiento y veracidad. Para poder crear fácil y rápidamente los certificados adecuados en nuestros servidores web Apache podemos utilizar OpenSSL o LetsEncript.

La opción más facil es LetsEncript, sobretodo si no queremos perder demasiado tiempo.
Para ello, en sistemas Debian o Ubuntu 16.04 o posterior, tenemos que tener instalado CertBot, así que utilizaremos el siguiente comando:

sudo apt-get install python-letsencrypt-apache

Una vez instalado podemos empezar a crear certificados con este comando, substituyendo dominio.com por el tuyo:
letsencrypt certonly –standalone -d dominio.com -d www.dominio.com

El parámetro –standalone hace que no se realice la configuración de Apache automaticamente, ya que puede dar problemas, y en realidad es muy sencillo de hacer manualmente. A continuación de la opción -d escribiremos el dominio y subdominios.

Ahora iremos al archivo de configuración del sitio en Apache y buscaremos la etiqueta <virtualhost *:80> y cambiaremos el puerto 80 por el 443.

Si tienes configurado correctamente Apache, tendrás un archivo por cada dominio dentro de /etc/apache2/sites-available.

Pues simplemente añadiremos estas lineas, modificando la ruta del certificado por la que te ha generado tu LetsEncript.

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/midominio.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/midominio.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/midominio.com/chain.pem

Añadiremos la redirección del puerto 80 a 443 (HTTPS/ SSL)


# DOMAIN: midominio.com
# PORT FORWARD FROM 80 TO: 443
<virtualhost *:80>
ServerNamemidominio.com
ServerAlias www.midominio.com
ServerAdmin info@midominio.com
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
</virtualhost>
# END DOMAIN: midominio.com

Una vez modificado el fichero y guardado, reiniciaremos el servicio de Apache, y al llamar a tu dominio, ya deberia cargar automaticamente en https.

 sudo service apache2 restart

Ahora debería aparecer en el navegador el candado y “Es seguro” como en la siguiente imagen:

Si no aparece, es posible que tu pagina web contenga enlaces o imágenes apuntando a tu mismo sitio, pero en http y no https. Revisa los src de las imágenes y debería solucionarse.

¿Te ha parecido útil? ¡Compártelo por favor!