Servidor de contraseñas
Objetivo: tener un servidor web donde almacenar de forma segura todas nuestras cuentas online de forma que centralicemos la gestión de las cuentas y podamos consultar los usuarios/password e incluso crear/modificar/eliminar cuentas desde el propio servidor, cliente de escritorio o Android/iOS app.
Requisitos:
- KeepassX o Keepass2
- Apache2
- WebDav
- Keeweb
Dispositivos/Servidores:
- PC/Desktop (cliente1)
- Smartphone (cliente2)
- Servidor Ubuntu (password server)
kdbx: base de datos de contraseñas
Instalación Keepass en un cliente de escritorio:
$ sudo apt update && apt install keepassx
$ keepassx
Base de datos > Nueva base de datos > contraseña > repite_contraseña > Aceptar
En este punto podemos o crear una contraseña fuerte o un archivo de claves. En mi caso he optado por una contraseña fuerte. Prefiero recordar una buena contraseña que andar con un archivo de llave que tendré que tener en el móvil, en el PC, en la nube y al final o lo pierdes o te lo roban, a saber…
Ahora tendremos que crear nuestras cuentas dándole la estructura jerárquica que queramos a nuestras carpetas dentro de la base de datos
Por último guardamos la base de datos como archivo .kdbx (ej: mis_cuentas_online.kdbx)
Servidor
Ya tenemos nuestra base de datos local, ahora vamos a crear un servidor web desde el que poder gestionar este archivo de forma centralizada.
Lo vamos hacer medianamente bien y medianamente seguro, es decir nuestro servidor tendrá conexiones cifradas y usuario/password para poder abrir el archivo de base de datos (además de la clave con la que va encriptada (la creada en el primer paso)).
Certificados
Para crear una PKI visita mi siguiente link donde explico brevemente como crear una PKI: CA + firma de certificados.
Importante:
- Solo necesitáis crear la CA y los certificados de servidor, los de clientes NO harán falta.
- Durante la configuración de OpenSSL se utilizan una serie de FQDN (ej vpn-00a1cc34.nebul4ck.org). Elegir aquel con el que queráis luego acceder a vuestro keeweb (ej my-keeweb.red-casa.com).
- Si no tenéis un servidor de nombres (DNS) en casa, acordaros de configurar el FQDN en el archivo /etc/hosts para traducir el nombre por la IP del servidor Apache
Apache2 + Keeweb + Webdav
Una vez contamos con los certificados necesarios, supongamos que son keeweb.local-network.com.crt, keeweb.local-network.key y que en mi Desktop (Ubuntu 18.04) tengo la siguiente entrada en el archivo /etc/hosts:
192.168.1.223 keeweb.local-network.com keeweb
vamos entonces a instalar, configurar y alojar keeweb en Apache2
Keeweb
Lo primero instalar keeweb en el servidor web:
# cd /var/www/
# mkdir -p keeweb/kdbx
# cd keeweb
# wget https://github.com/keeweb/keeweb/archive/gh-pages.zip
# unzip gh-pages.zip
# mv keeweb-gh-pages/* .
# rmdir keeweb-gh-pages
¿Os acordáis del archivo .kdbx, es decir de la base de datos que creamos con KeepassX? pues será necesario que lo copiéis (por ejemplo con el comando «scp» desde vuestro Desktop/Cliente a este servidor) en el siguiente directorio:
/var/www/keeweb/kdbx
Instalar y Configurar Apache2
# apt install apache2
# cd /etc/apache2
# mkdir cert
# cd cert <-- Copiar en este directorio los certificados generados anteriormente (tanto el .crt como el .key), certificados de servidor
## Creación de los sites HTTP/HTTPS
# cd ../sites-available
# vi 001-keeweb-http.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName keeweb.local-network.com
ServerAlias www.keeweb.local-network.com
DocumentRoot /var/www/keeweb
Redirect "/" "https://keeweb.local-network.com/"
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vi 002-keeweb-https.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName keeweb.local-network.com
ServerAlias www.keeweb.local-network.com
DocumentRoot /var/www/keeweb/
SSLEngine on
SSLCertificateFile "/etc/apache2/cert/keeweb.local-network.com.crt"
SSLCertificateKeyFile "/etc/apache2/cert/keeweb.local-network.com.key"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
<Directory /var/www/keeweb>
Options -Indexes
DirectoryIndex index.html
AllowOverride None
</Directory>
ErrorLog ${APACHE_LOG_DIR}/keeweb-https-error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
</IfModule>
## Configuración Webdav para compartir el archivo kdbx
# cd ../conf-available/
# vi webdav-kdbx.conf
RewriteEngine on
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ blank.html [R=200,L,E=HTTP_ORIGIN:%{HTTP:ORIGIN}]
<Directory "/var/www/keeweb/kdbx">
AuthType "Basic"
AuthName "Password Manager"
AuthBasicProvider file
AuthUserFile "/etc/apache2/.htpasswd-webdav-kdbx"
Require valid-user
DAV On
Options Indexes
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "origin, content-type, cache-control, accept, authorization, if-match, destination, overwrite"
Header always set Access-Control-Expose-Headers "ETag"
Header always set Access-Control-Allow-Methods "GET, HEAD, POST, PUT, OPTIONS, MOVE, DELETE, COPY, LOCK, UNLOCK"
Header always set Access-Control-Allow-Credentials "true"
</Directory>
## Crear usuario de acceso al directorio kdbx
# chmod -R www-data:www-data /var/www/
# cd /etc/apache2
# htpasswd -c .htpasswd-webdav-kdbx kdbxadmin
Enter a New password: ************
## Activar los sites
# a2dissite 000-default.conf
# a2ensite 001-keeweb-http
# a2ensite 002-keeweb-https
# a2enconf webdav-kdbx
## Activar los módulos necesarios
# a2enmod ssl
# a2enmod dav
# a2enmod dav_fs
# a2enmod rewrite
# a2enmod headers
## Reiniciar Apache
# systemctl restart apache2
Abrir la Base de datos
Ahora ya podemos acceder vía web a nuestro keeweb y configurar el acceso Webdav, recordar el fqdn que registramos en nuestro certificado y con el que accederemos al servicio (keeweb.local-network.com) y el usuario y contraseña que hemos creado con el comando htpasswd.
Una vez que accedáis os pedirá la clave maestra de la base de datos, la escribimos y accederemos a las cuentas.
Advance Format Disk: sector 4k
Advance Format Disk
Sector 512 bytes
Hasta el año 2009 las compañías fabricantes de discos duros aplicaban sobre los discos un diseño de sector físico de 512 bytes. Esto significa que a nivel lógico el disco era particionado en pequeños fragmentos llamados bloques lógicos (sector físico) de 512 bytes en los que se almacenaba la información una vez debidamente fragmentada a nivel lógico. Antes, cuando los archivos o información con la que trabajaba el computador eran de menor tamaño, quizás este sistema funcionase eficientemente, el problema llegó cuando los bloques de información que se leían o escribían al disco eran muy superiores a 512 bytes.
Diseño sector 512 bytes
Un sector se divide de la siguiente forma:
- Gap: espacio que separa un sector de otro
- Sync: indica el inicio de sector y la alineación del sector
- Marca de dirección: contiene el estado del sector y sus datos identificativos (número y ubicación)
- Datos: donde residen los datos
- ECC: contiene los códigos de corrección de errores utilizados para reparar y recuperar los datos dañados durante el proceso de lectura y escritura.
Desventajas del sector de 512 bytes
A medida que las densidades de los discos han ido aumentado, la proporción de sectores como porcentaje del almacenamiento total se ha vuelto ínfimo e ineficiente.
Algunas de las principales desventajas del sector de 512 bytes:
- Ineficientes en sistemas que trabajan continuamente con bloques mayores de 512 bytes
- Mayor número de sectores implica mas espacio de disco invertido en ECC
- Mayor probabilidad de error y ejecución de tareas de recuperación de datos
- Disminución de la capacidad de almacenamiento en discos de mayor densidad
Sector 4K o de formato avanzado (Advance Format Disk)
En Diciembre del año 2009 se nombró y aprobó el nombre de «sector de formato avanzado» para los sectores de 4KB.
A partir del año 2011 los fabricantes de discos comenzaron en su mayoría a aplicar este nuevo estándar, aumentando la eficiencia, las capacidades de almacenamiento mediante la reducción del espacio utilizado para ECC, y mejorando la corrección de errores.
El sector 4K combina ocho sectores antiguos de 512 bytes.
El estándar de formato avanzado utiliza el mismo número de bytes por sección Gap, Sync y Marca de dirección, pero aumenta el campo ECC al 100 bytes, algo que mejora considerablemente la eficiencia de tareas de corrección de errores, además de minimizar el riesgo de reproducción.
Impacto en el OS
En muchos de los aspectos a nivel de firmware y software relacionados con el sistema operativo, se sigue asumiendo que los sectores son de 512 bytes. Con el tiempo, tendrá lugar la implementación total de sectores 4k nativos. Mientras tanto, y durante esta transición, los fabricantes de unidades de disco duro implementan los sectores de 4k mediante una técnica denominada emulación de sectores de 512 bytes. Este término alude al proceso de conversión de los sectores físicos de 4 Kb utilizados en el formato avanzado, a los sectores antiguos de 512 bytes que esperan los sistemas informáticos. Esto puede conllevar a consecuencias negativas en el rendimiento, concretamente cuando la escritura de datos no se corresponde sencillamente con los ochos sectores antiguos convertidos, es decir, cuando no existe una perfecta alineación entre el sector 4k y los ocho bloques lógicos de 512 bytes.
Esto se debe a que la unidad de disco duro debe realizar pasos mecánicos adicionales, que se traducen en:
- La lectura de un sector de 4 Kb
- La modificación de contenidos
- Reescritura de los datos
Este proceso se denomina ciclo de lectura-modificación-escritura, y resulta no deseado por su impacto negativo en el rendimiento de la unidad de disco duro.
Prevención contra los ciclos de lectura-modificación-escritura:
- Solicitudes de escritura que están desalineadas debido a la desalineación de la partición lógica con respecto a la física.
- Solicitudes de escritura con un tamaño inferior a 4 Kb.
Logical Block Addressing
El modo en que los sistemas operativos y las unidades de disco duro se comunican la ubicación de los sectores, tiene que ver principalmente con LBA (Logical Block Addressing).
A cada sector de 512 bytes se le asigna un LBA único, desde cero hasta el número necesario según el tamaño del disco. Cuando el OS solicita la escritura de datos, se devuelve una dirección LBA al final de la escritura que con la que se indica la ubicación de los mismos. Al pedir un bloque de 4k, existen ocho posibilidades distintas correspondientes a los ocho bloques de 512 bytes.
Cuando se alinea el LBA con el primer bloque de 512 bytes virtual en el sector físico de 4 Kb, la situación de alineación lógico-física para la emulación de 512 bytes se denomina alineación 0. Las situaciones de alineación 0 funcionan muy bien con los nuevos sectores de 4 Kb en el estándar de formato avanzado. Esto se debe a que una unidad de disco duro puede asignar fácilmente ocho sectores de 512 bytes contiguos en un único sector de 4 Kb.
Cuando se crean particiones en la unidad de disco duro que producen una situación sin alinear, como se muestra en la siguiente figura, el resultado es que se crean ciclos de lectura-modificación-escritura que pueden mermar el rendimiento de la unidad de disco duro.
En el caso de la imagen anterior, se trata de un tipo de alineación 1.
Conclusiones
- Para el firmware, sistema operativo y todas las utilidades, el disco parece tener sectores de 512 bytes, aunque el tamaño de sector físico subyacente es 4.096 bytes
- El uso de sectores físicos más grandes tiene implicaciones directas en el diseño del disco y el rendimiento del sistema
- Cuanto mayor es el tamaño del sector, mas eficientes y potentes algoritmos de corrección de errores puede ser utilizados.
- En teoría redimensionar o contar con sectores de mayor tamaño ofrece mayor fiabilidad y capacidad de almacenamiento
- La mayoría de los sistemas de archivos modernos utilizan estructuras de datos de 4.096 bytes o superior
- En conjunto, las ventajas de una eficiencia de formato mejorada y una corrección de errores más sólida hacen que la transición a los sectores de 4 Kb merezca la pena
En la práctica…
Si cuentas con un disco indebidamente alineado, algo que se puede comprobar con el comando fdisk o parted, quizás te interese el siguiente link
Referencias:
ubuntu 18 dns not working
¿Problemas con los DNS en Ubuntu 18.04 Bionic?
EDITADO: mejor opción es utilizar NETPLAN el nuevo configurador de networking de Debian y derivados. Es fácil usar y configurar. +info
Con la nueva resolución de nombres añadida en la versión 18 de Ubuntu se han dado varios problemas con aplicaciones de terceros como por ejemplo al montar tu propio DNS server (BIND9 o dnsmasc) o con otras herramientas como por ejemplo VPN o Cloud-init para servidores aprovisionados en el cloud..
La cuestión es que ahora el archivo /etc/resolv.conf es administrado de forma nativa por systemd-resolved y no por resolvconf . Se ha intentado dar compatibilidad con «antiguas herramientas Linux» (lo que dicen ellos…) y básicamente la han cagado (por supuesto hasta futuros parches y/o versiones). No voy a entrar en largas explicaciones porque para el que las quiera, puede empezar a leer sobre los modos de funcionamiento de este nuevo demonio (resolved man pages), luego seguir con NetworkManager el cual tiene mucho que decir aquí también, y si aún te quedan ganas puedes ver algunos de los intentos por resolver parte de este problema en:
- https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu/907249#907249
- https://wiki.archlinux.org/index.php/Systemd-resolved#Automatically
- https://stackoverflow.com/questions/51784208/stop-network-manager-from-updating-resolv-conf
- https://unix.stackexchange.com/questions/323459/how-to-make-networkmanager-add-a-dns-server-at-the-top-of-etc-resolv-conf
- https://www.linode.com/community/questions/17081/dns-stops-resolving-on-ubuntu-1804
y un largo etcétera…
Al final lo mejor es meterse en como cada demonio realiza su trabajo y volver a una configuración compatible con el «antes y el ahora».
Básicamente el archivo /etc/resolv.conf es administrado de forma manual (propio de antaño y de sysadmins) o por un demonio externo (systemd-resolved, resolvconf o openresolv) que a la vez este puede tener «dependencias de» por ejemplo NetworkManager. Bien pues para poner fin a nuestros males y que:
- El dhcp de la red modifique el archivo /etc/resolv.conf con los DNS de nuestro ISP/router
- Programas como VPN también puedan gestionar este archivo (recordar, openvpn trabaja con resolvconf y si tenemos configurado el sistema con systemd-resolved, tendremos o DNS de ISP, de VPN o en algunos casos ninguno de los dos :D)
- cloud-init para servidores desplegados en el Cloud
Solución
- Deshabilitar y parar el maldito systemd-resolved (hasta que den solución…):
systemctl disable systemd-resolved
systemctl stop systemd-resolved- Eliminar el archivo /etc/resolv.conf:
rm /etc/resolv.conf- Configurar correctamente NetworkManager:
vi /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
#default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections.
dns=default
#resolvconf: NetworkManager will run resolvconf to update the DNS configuration.
rc-manager=resolvconf
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no- Instalar resolvconf:
apt update && apt install resolvconf- Habilitar e iniciar el demonio:
systemctl enable resolvconf && systemctl start resolvconf- Crear enlace directo a /etc/resolv.conf:
ln -s /run/resolvconf/resolv.conf /etc/resolv.confUna vez reiniciado, al hacer un cat del archivo resolv.conf deberá de aparecer los DNS de vuestro ISP o LAN (antes 127.0.0.53). Cuando instaléis un servicio que necesite nuevos DNS como un cliente VPN este, será capaz de añadir nuevos servidores.
Listo!!
Servidor DNS dnsmasq con CNAMES
Configurar un servidor DNS con dnsmasq es relativamente sencillo pero con frecuencia si no se siguen ciertas pautas, fácilmente va a funcionar de forma errónea y difícilmente te vas a dar cuenta antes de que vengan a darte un toque/aviso de que algo no marcha bien.
Integrar Nagios/Centreon con chat Slack
Si bien existen diferentes formas de recibir las alertas del monitorizador Nagios o Centreon; correo electrónico, mensaje de texto, IRC, etc… en esta entrada veremos como hacer que Slack (uno de los chats libres mas utilizados a nivel empresarial) nos notifique de aquello que ocurre en nuestra infraestructura.
Configurar iSCSI en Linux
En esta entrada continuaremos con iSCSI, concretamente con la instalación y configuración de un cliente iSCSI o servidor de almacenamiento vía TCP/IP (iSCSI).
(más…)
Almacenamiento iSCSI en Linux
Si has llegado hasta aquí es porque estás interesado en conocer los dispositivos SCSI o iSCSI, o bien porque tienes en mente gestionar un servidor de almacenamiento o conectar a el mediante Linux. (más…)
Distributed Shell (DSH): Ejecutar comando Linux en múltiples máquinas
Distributed Shell es un pequeño programa fácilmente instalabe desde los repositorios de nuestra distribución, que nos permitirá ejecutar un comando en varias máquinas de una sola vez.
¿Que es Logical Volume Manager o LVM? – 1/2
Logical Volume Manager o LVM no es mas que una forma de crear y administrar particiones virtuales de disco proporcionada por una función del kernel llamada Device-mapper. Cuando trabajemos con LVM lo estaremos haciendo sobre una capa que nos abstrae de la estructura del disco por lo que no deberemos de preocuparnos por algunos aspectos como (más…)
#4sysadmins 