Cifrar un disco duro y compatible multiplataforma con veracrypt

En éste post de hoy veremos como cifrar un disco duro externo y que pueda ser accedido por los sistemas operativos mas comunes, windows, mac y linux. Cada sistema operativo trae consigo su sistema de cifrado de discos (Linux cryptoluks, Windows BitLocker y Mac OS X Filevault) pero son incompatibles entre ellos, para ello es necesario usar algún tipo de programa que haga la misma función y sea compatible para los múltiples sistemas operativos, para ello tenemos veracrypt.

Proxmox migrar máquinas con mountpoints locales

Tengo 2 contenedores LXC que comparten un directorio con ficheros de configuración que está sobre glusterfs y está montado en local a todos los nodos. El otro día al tratar de migrar las máquinas me decía que no podía migrar las máquinas porque algo no le gustaba del mountpoint. Es una puñeta porque si se para el nodo en el que se encuentra el contenedor por algún motivo, el HA fallará por no poder migrar el contenedor a otro nodo.
El otro día traté de añadir el mountpoint local desde la interfaz de proxmox y no daba la opción. Hoy tonteando en los foros de proxmox he encontrado la solución.

En los contenedores, había configurado a mano el mountpoint. Para ello, paramos el contenedor y nos vamos al nodo en el que se encuentra en aquel momento cada uno de los contenedores y editamos el fichero de configuración que se encuentra en /etc/pve/lxc/

root@planet1B:/etc/pve/lxc# vi 106.conf
mp0: /mnt/gluster/gvol1/nginx,mp=/mnt/conf-nginx,shared=1

El secreto para poder migrar los contenedores con el mountpoint, es añadirle “shared=1” y el directorio tiene que estar en todos los nodos.

Aquí una capturilla de pantalla de como queda en proxmox

Upgrade modoboa 1.14 a 1.17 + roundcube webmail

En la de hoy nos encontramos con un servidor de correo instalado con modoboa versión 1.14 que queremos actualizar a una versión mas nueva, en este caso la 1.17. Aprovecharemos también para actualizar la versión de roundcube 1.4 RC1 a la versión 1.4.11.

Como todo tiene sus puñetitas en la informática, nos encontramos con que la migración de modoboa 1.14 a la 1.17 implica cambiar la versión de python2 a python3 y usar el instalador para hacer el upgrade es lio asegurado. Así que vamos a ver como hacer la migración pasito a pasito y de forma humanamente viable! :D

Para alegrarte un poco el día, comentar que es posible hacer tranquilamente la instalación del nuevo entorno con una IP distinta a la definitiva. Es decir, si voy a usar mail.lamardebits.org no es necesario que el entorno que estamos montando tenga la IP que apunta a mail.lamardebits.org. Así que es posible dejarlo todo listo sin tocar el entorno que está en producción. Cuando queramos hacer el cambio, simplemente será apagar la máquina con la versión vieja de modoboa, cambiar la IP en el entorno nuevo y levantarlo!

Así que empezamos y como de costumbre hago la instalación sobre una debian 10 virtualizada con LXC y con el nesting activado. Además le pongo ya el mountpoint sobre el cephfs a /srv/vmail

Una vez arrancada la maquina, lo básico y recomendable, configurar y actualizar el sistema

root@mail:~# dpkg-reconfigure locales && dpkg-reconfigure tzdata && apt update && apt -y upgrade && apt -y 

Instalación iredmail en debian10

Hoy vamos a instalar iredmail en una debian10.

Partimos de un contenedor lxc dentro de nuestra querida infraestructura de proxmox con un template de debian10 y el nesting activado.

Una vez arrancado el contenedor vamos a actualizar el sistema e instalar algunos paquetes necesarios

root@mail:~# dpkg-reconfigure locales && dpkg-reconfigure tzdata && apt update && apt -y upgrade && apt -y dist-upgrade && apt -y install vim net-tools dnsutils gnupg2

Añadimos también los repositorios de sogo que durante la instalación nos peta si previamente no hacemos esto

root@mail:~# echo "deb https://packages.inverse.ca/SOGo/nightly/5/debian buster buster" /etc/apt/sources.list.d/sogo-nightly.list
root@mail:~# gpg --keyserver keyserver.ubuntu.com --recv 19CDA6A9810273C4
root@mail:~# gpg --export --armor 19CDA6A9810273C4 | apt-key add -
root@mail:~# apt update

Para instalar iredmail correctamente, el nombre del host tendrá que ser el correcto, en mi caso mail y dominio summercamp.cat (donde estoy haciendo la instalación para probar el software). En hostname -f debe salir el fqdn correcto del servidor. Evidentemente los dns deben apuntar a la ip del servidor.

root@mail:~# hostname -f
mail.summercamp.cat

Nos descargamos iredmail de su página web. La versión 1.4.0 corresponde a Abril de 2021, así que good ;)

root@mail:~# wget https://github.com/iredmail/iRedMail/archive/1.4.0.tar.gz
root@mail:~# tar xvzf 1.4.0.tar.gz
root@mail:~# cd iRedMail-1.4.0/
root@mail:~/iRedMail-1.4.0# bash iRedMail.sh 
[ INFO ] Checking new version of iRedMail ...
[ INFO ] Installing package(s): ca-certificates apt-transport-https dialog

Nos aparecerán varias pantallas de ncurses que deberemos rellenar de esta forma

Ahora a esperar un rato que descargue y configure todo lo necesario

Una vez terminado nos debería decir esto

Reiniciamos tal como nos pide

root@mail:~/iRedMail-1.4.0# 

ip real con frontal proxy nginx, backend apache y wordpress

Por fin he encontrado la solución! otra de estas tareas pendientes que hacía que una instalación no funcionase como era esperado! en este caso me encuentro con dos frontales de nginx que actúan como proxy http y detrás de ellos está un wordpress sobre apache. Hace un tiempo, hice un post similar a éste, pero detrás estaba otro nginx.

Así que aquí dejo la solución.

Frontal nginx
En este caso tengo 2 ficheros, el de la configuración del dominio y otro con la configuración específica para los wordpress almacenado en el directorio snippets

# vi /etc/nginx/sites-available/lamardebits.org
server {
    listen 80;
    listen [::]:80;

    server_name lamardebits.org
                www.lamardebits.org;
    return 301 https://lamardebits.org$request_uri;

    #root /var/www/html/;
    include snippets/certbot.conf;
}


server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name lamardebits.org;

    include snippets/certbot.conf;

    # Aquí s'inclou el servidor intern i la protecció específica de WP
    include snippets/wordpress10.conf;

    ssl_certificate /etc/letsencrypt/live/lamardebits.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lamardebits.org/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_trusted_certificate /etc/letsencrypt/live/lamardebits.org/chain.pem;
}

Y la configuración específica para los wordpress

# vi /etc/nginx/snippets/wordpress10.conf
include conf.d/external-log.conf;
location / {
    proxy_pass http://172.31.0.145:6081;
    include proxy_params;

    location ~ \.php$ {
        proxy_pass http://172.31.0.145:6081;
        include proxy_params;

        location ~* wp\-login\.php {
            client_max_body_size 40M;
            proxy_pass http://172.31.0.145:6081;
            include proxy_params;
            include snippets/lmdb-protected.conf;
        }
    }

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    fastcgi_read_timeout 300;
    proxy_read_timeout 300;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Forwarded-Host $remote_addr;

    add_header X-Frame-Options SAMEORIGIN;

}

La configuración de proxy de nginx la tengo así

# vi /etc/nginx/conf.d/proxy.conf
proxy_buffer_size         128k;
proxy_buffers           4 256k;
proxy_busy_buffers_size   256k;
client_max_body_size      32M;

proxy_read_timeout 1800;
proxy_connect_timeout 1800;
proxy_send_timeout 1800;
send_timeout 1800;             

Backend apache + wordpress

A …

Grub cambiar nombres interfaz de red ens0 a eth0 wlan0

Pequeño tip para renombrar las interfaces de red a los nombres de toda la vida, eth0, wlan0, etc.

Editar el fichero /etc/default/grub y en GRUB_CMDLINE_LINUX añadir esto

# vi /etc/default/grub
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Cargamos la configuración a grub

# grub-mkconfig -o /boot/grub/grub.cfg

Editamos el fichero de configuración de la red para definir los nuevos nombres de interfaz

# vi /etc/network/interfaces

Y reiniciamos…

Script para comprobar el estado de varios certificados SSL

Hola, hoy os dejo un script que he desarrollado para comprobar el estado de los certificados SSL de varios dominios.

 
#!/bin/bash

############################################
# SCRIPT CREATED BY: Laura Mora i Aubert   #
# SCRIPT DATE: 2021-04-01                  #
# WEBSITE: blackhold.nusepas.com           #
# INFO: Script that checks domain ssl      #
#       certificates                       #
#       tested with openssl 1.1            #
# LICENSE: creative commons (by:sa)        #
############################################

############################################
#             INSTRUCTIONS                 #
############################################
#                                          #
# 1. Create a file on /root/scripts/ with  #
#    the content of this file              #
# 2. Edit $ADMIN_MAIL with your mail       #
# 3. Edit $DOMAINS array with your domains #
# 3. Give permissions and run the script   #
# 4. Put your script on /etc/crontab or    #
#    /etc/cron.d/check_ssl with this line  #
# # check ssl certificates
# 0  7    * * *   root /root/scripts/check_certificates.sh /var/log/ssl_checks/check_certificates-$(date "+\%Y\%m\%d").log && cat /var/log/ssl_checks/check_certificates-$(date "+\%Y\%m\%d").log |mail -s "[Check Certificates] your-server-name" your-admin-email@domain.com 
#                                          #
# That's all folks! have a nice day :)     #
#                                          #
# - Blackhold                              #
#                                          #
############################################

ADMIN_MAIL="your-admin-email"
DOMAINS=(
# control domains
"google.com"
"expired.badssl.com"
"wrong.host.badssl.com"
# my domains
"capa8.net"
"aspertic.org"
"cacavaca.capa8.net"
)

for DOMAIN in "${DOMAINS[@]}"
do
    echo "---------------------------"
    echo "domain ${DOMAIN} is: "

    touch check_ssl.txt
    echo | openssl s_client -servername ${DOMAIN} -connect ${DOMAIN}:443 check_ssl.txt 2/dev/null
    if [ `cat check_ssl.txt |wc -l` != 0 ]
    then
        cat check_ssl.txt | openssl x509 -noout -dates check_ssl.txt
    else	
        echo "Verify return code: -1 (certificate does not exist)" check_ssl.txt
    fi

    # badssl.com
    # ok: Verify return 

Añadir un chivato al ssh cuando alguien hace login

Con tanto ransomware, accesos indebidos a sistemas y demás ataques varios a sistemas, la concienciación de tener los sistemas al día está al día y supongo que algo habréis notado queridos lectores que mi actividad éstas últimas semanas ha sido frenética. Mi objetivo es ponerlos a punto y cada vez mas ir mejorando la seguridad sin que se vea afectada la usabilidad.

Está claro que un sistema conectado a la red es victima de intentos de acceso continuos y sólo nos interesan los que han tenido éxito. Es por esto que hoy os traigo un pequeño “tip” para avisar de los accesos a nuestro sistema, sean legítimos o no.

Hace años tenía implantada esta política de seguridad en mis servidores y me sirvió para paliar un ataque aún mayor. La primera reacción fue echar el malhechor de mis sistemas, al mismo tiempo que cambiaba las contraseñas de todos los servidores (ahí aprendí que tenemos que ir con mucho cuidado con nuestra política de passwords).

Éste post se basa en esta respuesta del foro de ubuntu y un poco a mi friki-artesanía.

Lo primero será crear los dos scripts y los pondremos donde ejecutemos los scripts del sistema

root@frontal1-nginx:~# vi /root/scripts/login-notify-pam.sh
#!/bin/sh

/root/scripts/login-notify-script.sh &
root@frontal1-nginx:~# vi /root/scripts/login-notify-script.sh
#!/bin/sh

sleep 3
# Change these two lines:
sender="noreply-valido@capa8.net"
recepient="cuenta-de-notificaciones@capa8.net"

if [ "$PAM_TYPE" != "close_session" ]; then
    host="`hostname`"
    subject="SSH Login: $PAM_USER from $PAM_RHOST on $host"
    # Message to send, e.g. the current environment variables.
    message="Algú ($PAM_RHOST) ha entrat al sistema $host per SSH!\n\n`ps aux 

Instalación y configuración de Apache Guacamole en Debian 10

Hola, hoy veremos cómo instalar, configurar y usar Apache Guacamole, una herramienta que nos permite conectarnos remotamente por web mediante protocolos cómo SSH, RDP, VNC.

¿Qué es Apache Guacamole?
Apache Guacamole es una herramienta libre y Open-Source que nos permite conectarnos remotamente a un servidor mediante el navegador web sin necesidad de usar un cliente.

Gracias a HTML5, una vez tengamos instalado y configurado Apache Guacamole, tan solo tenemos que conectarnos mediante el navegador web para empezar a trabajar remotamente.

¿Qué es Tomcat?
Apache Guacamole no es una aplicación web autónoma y está compuesta de muchas partes. La aplicación web en realidad está diseñada para ser simple y mínima.

Una de esas partes, y esencial, es Tomcat. Tomcat es una especie de contenedor de ServLets que nos permite ejecutar herramientas desarrolladas con Java Server Page (JSP).

Para poder usar aplicaciones con Tomcat, este las “comprime” en ficheros .war.

¿Qué es un fichero .war?
Un fichero .war es una Aplicación Web que permite a Tomcat acceder a su utilización. El fichero .war en sí no es legible sino que tiene que ser expandido/descomprimido para ser leído.

Instalación de Guacamole-server
Comezamos con la instalación de Apache Guacamole-Server. Primero debemos instalar los paquetes mínimos necesarios, después podrémos elegir qué protocolos usar según nuestras necesidades.

Instalamos los paquetes principales necesarios:

root@guacamole:~# apt install libcairo2-dev libjpeg62-turbo-dev libpng-dev libossp-uuid-dev gcc make tomcat9 tomcat9-admin tomcat9-user

Ahora podemos elegir, según nuestras necesidades, qué paquetes instalar:

Usar Guacenc:

apt install libavcodec-dev libavutil-dev libswscale-dev

Usar el soporte para RDP:

apt 

Cambiar la red de ceph

El sábado hice un taller en vivo sobre proxmox en el que enseñé a configurar tanto ceph como glusterfs.

Aquí el vídeo sólo de la parte de la entrevista:

Instalar proxmox es super fácil, pero preparar bien el entorno ya es otra cosa. Al prepararlo cometí un fallo de diseño al reutilitzar configuración antigua.

Tal como dije, se recomienda destinar una red específicamente para la comunicación de los ceph. Así que vamos a ello.

El contenido de mi fichero de configuración de red es el siguiente

# vi /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.139.39.166/27
        gateway 10.139.39.161
        bridge_ports eth0.10
        bridge_stp off
        bridge_fd 0

auto vmbr1
iface vmbr1 inet static
        address 172.31.0.11
        netmask 255.255.0.0
        bridge_ports eth0.1000
        bridge_stp off
        bridge_fd 0
        post-up echo 1 /proc/sys/net/ipv4/ip_forward

auto vmbr2
iface vmbr2 inet manual
        bridge_ports eth0.1001
        bridge_stp off
        bridge_fd 0


# ceph - glusterfs # dades
iface eth1 inet manual

auto vmbr11
iface vmbr11 inet static
        address 192.168.10.1/24
        bridge-ports eth1
        bridge-stp off
        bridge-fd 0

He cambiado los bridge_ports tanto de vmbr1 como de vmbr2 y añadido el bridge vmbr11 sin vlans y con la red 192.168.10.0/24.

He aplicado la configuración correspondiente a cada nodo del cluster y los he reiniciado.

Una vez iniciados de nuevo y comprobado que lleguen los servidores entre ellos por la red 192.168.10.0/24, he ido al fichero de configuración del ceph (/etc/pve/ceph.conf) y he cambiado el parámetro cluster_network

# vi /etc/pve/ceph.conf
[global]
         auth_client_required = cephx
         auth_cluster_required = cephx
         auth_service_required