He podido abrir mi caja, la cual llevaba unas semanas esperándome, y tras un pequeño esfuerzo, por fin hemos podido hacer el «unboxing».
Se trata de un Appliance OOTBI de Object First, Como bien sabeis, se trata de una solución de almacenamiento S3 inmutable para Veeam, Os dejo aquí un poquito más de información!
Bueno, vamos al lío, os voy poniendo fotos, y explicando un poquito lo que va apareciendo:
Hasta aquí la impresión física y primer encendido,
He de decir que se ve de una calidad excelente, el más alto nivel de Supermicro, Junto con los discos de gran calidad, capacidad y velocidad!
En la próxima, el arranque del SO, integración en Veeam VBR 12.1 y primeros trabajos e impresiones.
Os vuelvo a poner la foto del frontal, el cual, simplemente me parece precioso!! Quedaría fantástico colgado en la pared de mi despacho, a modo de cuadro!
Tras estar de remodelación en el Laboratorio, que se ha convertido en un «borrón y cuenta nueva», estaba echando de menos un servidor DNS, simplemente DNS, para poder hacer pruebas, resolver interno y a la vez usarlo en casa con un poquito de filtrado.
Primera idea, un Windows server, pero era demasiado, y VM siempre corriendo, y la idea es poder apagar el laboratorio (Consumo de luz, y que sino me echan de casa!)
Así que me puse a mirar a mi alrededor, y Boom!!!!
Ahí me dije, si solo quiero un DNS, y que no meta ruido y consuma poco, a ver si podemos echarla a andar….
Muy noble mi Pi, arrancó, ahora, a buscar una SD «grande» para poder hacer algo.
Ahora, solo quedaba bajarse la app para preparar la tarjeta, en mi caso, uso Mac, por tanto usaremos el Raspberry Pi Imager:
Con unos sencillos pasos, llegamos a una ventana final, en la cual , nos indica el password de acceso a la consola web, el cual debemos guardar, ya que luego desaparece, y si queremos volver a acceder, debemos resetearlo. Leer las pantallas, ya que son preguntas muy sencillas, como la consola de administración web, etc. Recalcar que desde el wizard podemos poner IP estática a la raspberri, o dejarla por DHCP, dependerá de vosotros, en mi caso tiene IP estática, ya que más adelante, la usaré como servidor DHCP también!
Accedemos, y se verá la consola así:
Ahora ya solo queda que cambies en tu DHCP el DNS que entrega por la IP de tu Pi-Hole, y estarás en marcha.
Es muy intuitiva y fácil de usar, podemos activar varios proveedores de DNS, como Comodo, OpenDNS, Google, etc. Bloquear dominios listados en adlists, añadir nosotros blacklisted domains, hacer entradas DNS propias, etc…
Recently I added to my home lab, my first Ubuntu Server with a Hardened Repository for Veeam Backup, you can find more info here.
Now, the thing is, I want to be able to get notified if some user logs into the server via ssh, as a extra control, since I disable the SSH service when I dont use it.
Also the idea came, to be able to get notified from other applications via telegram, so wasn’t a crazy idea at the end.
from previous entries, or the internet, you can easily find how to create a Bot, and how to get your ID, so Im not going to dive into that,
So first, once we have created and activated our bot and user ID, lets go a create our Telegram messaging program,
in our home, lets create a file like this:
nano send-over-telegram.sh
#!/bin/bash
GROUP_ID=
BOT_TOKEN=
# this 3 checks (if) are not necessary but should be convenient
if [ "$1" == "-h" ]; then
echo "Usage: `basename $0` \"text message\""
exit 0
fi
if [ -z "$1" ]
then
echo "Add message text as second arguments"
exit 0
fi
if [ "$#" -ne 1 ]; then
echo "You can pass only one argument. For string with spaces put it on quotes"
exit 0
fi
curl -s --data "text=$1" --data "chat_id=$GROUP_ID" 'https://api.telegram.org/bot'$BOT_TOKEN'/sendMessage' > /dev/null
GROUP_ID: Your Group ID from your telegram suscription BOT_TOKEN: your token received when you created your bot.
let`s convert this into a «program» to do so, lets move (or copy) our file into the route /usr/sbin
Everything inside /usr/sbin is owned by root, so lets change the ownership to our file
sudo chown root:root /usr/sbin/send-over-telegram
Finally, we want any user to execute this «program» so lets also modify the permissions for that
sudo chmod 0755 /usr/sbin/send-over-telegram
now we can test it out:
send-over-telegram test
you should get the «test» text message into your Telegram Group!
Now, let’s get notified any time a user logs into our server via SSH, to do so, we are going to create a script, and move it to a specific folder.
nano login-notification.sh
#!/bin/bash
# prepare any message you want
login_ip="$(echo $SSH_CONNECTION | cut -d " " -f 1)"
login_date="$(date +"%e %b %Y, %a %r")"
login_name="$(whoami)"
# For new line I use $'\n' here
message="New login to server"$'\n'"$login_name"$'\n'"$login_ip"$'\n'"$login_dat>
#send it to telegram
send-over-telegram "$message"
As you can see, here we are sending the information to our previously created «command» send-over-telegram
now, lets move (copy) the script where needs to be to trigger the alert:
We are done! Now, lets log off and back on to our Ubuntu Server,
You should get your Telegram Message with the information like this:
Remember!!
After using your SSH access, you should always disable it from the server, to avoid unwanted accesses to your server remotely, and do local changes or enable it just when you need to
En una entrada anterior, veíamos como desplegar el Ubuntu VHL «paquetizado» directamente, ya aplicando todo el Hardening y opciones del script «por defecto» e incluso endureciendo los permisos de usuarios.
Ahora bien, si el caso es, que quieres instalar tu propio Ubuntu Server, y luego aplicar el Hardening, te traigo unos pantallazos con una Instalación estándar más la ejecución del script.
Ya tenemos nuestro Ubuntu Server con el Harden aplicado, y ya podemos seguir los pasos del artículo siguiente para añadir nuestro repo a Veeam B&R V12 y hacerlo inmutable, desde la parte de la adición del repo a VBR V12.
Hola, Hoy por fin me he animado a desplegar y probar el fantástico proyecto de Veeam, el VHR «Veeam Hardened Repository»
Se trata de un despliegue «paquetizado» de un Ubuntu Server, el cual ha sido «endurecido» o «reforzado» con las pautas de seguridad DISA STIG.
Existe la opción de instalar el S.O. por tu cuenta, y después correr el script de Hardened, pero me ha parecido más interesante probar este «paquetizado«
Voy a ir poniendo pantallazos y algunos comentarios, el proceso es muy sencillo. Para las pruebas, lo he desplegado en una maquina virtual, pero este VHR está diseñado para ser desplegado en un servidor físico, no en vm.
Toda la información y descargas las podemos encontrar aquí!
Comenzamos:
Como pre requisito, este deploy buscará en los discos el más pequeño para el S.O. y el más grande para el repositorio, yo en mi caso he desplegado un disco de 20GB y otro de 100Gb y los ha reconocido solo. Recomendado si hacéis el despliegue en servidor, que tenga controladora RAID, un RAID 1 «Pequeño» para el S.O. y un Raid 5 ò 6 para el repositorio.
OJO, continuamos ahora en el Servidor VHR que desplegamos, para terminar el Hardening!!
ara poder hacer troubleshooting, tendremos que reiniciar y lomearnos en el servidor como root desde el modo Standalone desde el arranque del Grub, ya que el root está deshabilitado, y nuestro usuario únicamente tiene permisos de Reboot y Shutdown.
Espero os haya gustado, y os facilite el despliegue de esta fantástica opción, yo lo tengo en mi laboratorio, y como bien dice la documentación, usarlo a vuestro criterio, y no tiene soporte, no habrás tickets en soporte!
Para monitorear los discos en caso de fallo, etc, deberes configurar la ILO, IPMI, DRAC, etc… que tenga vuestro servidor, ya que el S.O. del VHR no mandará notificaciones.
I had a case during this week, and I wanted to share my experience / workaround with y’all.
I wanted to export a backup to an external drive, the VBR was a virtual machine, and no access to the Hypervisor to plug the USB and push it to the vm.
Now you may think, mount it somewhere and share it over the network as a shared folder…
I did, and was not working, some windows stuff that we were not allowed to share any unit, and was driving us crazy!
We did some research, and remembered that there was a way to share / mount remote USB Devices over the Network! now, time to give it a shot!
The idea is very straight forward, a Server machine, where the USB Devices is located at, and a client, to mount the remote resource as “local”.
USB SERVER(Local USB Drive)→NETWORK→USB CLIENT“Remotely mounted USB Drive”
You simply download the Server and client, and execute them in the decided machines, couple of easy configs, and you are good to go, let me show you some screenshots.
Hope you liked this little workaround,
now, planning and thinking in future usages for this great tool.
Just wanted to highlight that I used the “Free” Version, which only allows to mount one USB Device at a time, there is a licensed version, but not used for now. Also wanted to tell you that I have no relationship at all with them, just found it and wanted to share it with all of you.
Hola, Este paso curioso me llegó, dado que un amigo me pidió ayuda con un tema, un servidor, el cual necesita una copia del mismo para hacer una auditoría, solo de las unidades de disco.
Lo primero que me vino a la cabeza fue, restaurar la vm desde un backup, y ya de ahí coger los vmdks pertinentes y hacer lo que sea.
De ahí, otra idea, si es un servidor virtual, restaurar los ficheros de vm, no el contenido, no? Este parece ser el paso más sencillo y adecuado, siendo una vm.
Pero luego, dándole vueltas, caí en la cuenta, y si es físico? cómo podríamos hacerlo? Por qué no mejor coger y pedirle a veeam directamente los vmdks?
Veeam no solo nos «convierte» o «entrega vmdks (vmware), sino también puede ser vhd (Hyper-V o Azure) o vhdx (Hyper-V).
Vamos a verlo con unos sencillos pantallazos, por si a más de uno le puede ser útil:
Hola, en un post anterior vimos la funcionalidad Backup Move en VBR 12, una maravilla.
Ahora bien, me he encontrado con un pequeño error, el cual no me permitía mover los backups de un repo a otro, en concreto, de un repo local a un repo S3 en Wasabi (immutable).
Tal y como podemos leer en el error, se trata de nuestra configuración de la tarea, la cual tiene puesto un Synthetic Full los sábados, y no le ha gustado nada.
Lo cambiamos a Active full, realizamos un Full, y ya nos permitirá hacer el cambio de Repo.
Pequeño detalle a tener en cuenta a la hora de querer hacer nuestros movimientos. Ojo con el espacio disponible, ya que un Active Full ocupa, y según tengamos nuestros recursos disponibles, podemos tener problemas.
Detalle también a tener en cuenta a la hora de crear nuestras tareas en el inicio, si prevemos que haremos este tipo de movimientos, conviene tenerlo preparado.
He tenido la suerte de poder tener un NAS de Terramaster para hacer unas pruebas en mi laboratorio.
En esta entrada, os voy a mostrar unas imágenes de cómo llegó, como es por fuera y por dentro y sus características base, por último, unas fotos de cómo lo tengo ahora mismo, y mis impresiones.
El F4-423 de 4 bahías es adecuado para usuarios que necesitan soluciones de almacenamiento de alto rendimiento. Alto rendimiento significa que los usuarios pueden manejar fácilmente flujos de trabajo de alta carga, mientras múltiples soluciones de respaldo de nivel empresarial garantizan la seguridad de los datos y protegen contra el riesgo de pérdida de datos.
Se trata de una solución de almacenamiento de alto rendimiento que proporciona almacenamiento virtual ampliado y base de datos para usuarios de SMB. Utiliza un procesador Intel Celeron N5095 de cuatro núcleos con 2,0 GHz y frecuencia turbo máxima de 2,9 GHz. Está integrado con una tarjeta gráfica GPU y cifrado de hardware AES-NI. Además, está equipado con dos interfaces de Internet de 2,5 GbE y memoria de doble canal DDR4 de 4 GB (ampliable a 32 GB). Además, esta solución de almacenamiento se instala internamente con 2 ranuras M.2 NVMe, que aceleran el almacenamiento en caché de SSD y duplican la eficiencia de almacenamiento de su RAID.
Vamos a ver una foto de la caja, y de como sale:
Mi primera impresión es muy buena, un producto robusto, limpio y con un acabado sencillo y elegante.
Me ha sorprendido gratamente la conectividad que trae, los USB 3.0, los dos puertos 2.5GB Ethernet y el HDMI, el cual más adelante lo usaremos para ver el sistema y las tripas de este juguete.
Os dejo a continuación una foto inicial del interior, en el cual podremos apreciar en su placa la expansion de discos con 2 M2 NVMEs, y una foto más en detalle de los puertos traseros del mismo.
Con esta capacidad de red, sumado a sus 4 bahías de 3,5 u 2,5, las dos ranuras de expansion M2 NVMe, y su RAM ampliable hasta 2 SODIMM DDR4 de 16GB, lo hacen una unidad muy completa y de fácil crecimiento.
Si te interesa echar un vistazo y adquirir uno, puedes entrar aquí.
Seguiremos haciendo pruebas a esta fantástica unidad, desde su sistema operativo propio TOS, a la instalación de otros sistemas y la integración de la misma en el Home Lab.
En esta ocasión vamos a ver, en sencillos pasos, como configurar una tera de Copy Job de una maquina virtual de nuestro entorno, a otro datastore, bien de un VBR ó de un servidor ESXi que tengamos registrado en nuestro VBR Server.
No lo confundamos con un Backup Copy Job, que es algo totalmente diferente, Esta tarea está enfocada en copiar los archivos de la maquina, no los backups o resultados.
No veo muy implementada o nombrada esta funcionalidad, yo la he empleado para hacer copias de maquinas virtuales, directamente al destino donde las quería tener, con un mecanismo de control, «garantizando» que la copia se había realizado correctamente, o para casos que queremos tener dicha copia, de ultima frontera, dado que el destino es un ESXi y se puede «registrar» la vm rápidamente y encenderla.
Como último detalle, decir que es un Copy, por tanto, no mantiene registro de diferentes ejecuciones, sino que tendremos disponibles los archivos de la última copia OK ejecutada.
Vamos a ver los pantallazos y el ejemplo:
Ahora vemos la otra opción, como destino, un repositorio de Veeam, en este caso, el Local repo de nuestro VBR Server
Como habéis visto, una manera muy efectiva de copiar una vm para luego hacer diferentes cosas con ella, registrarla en un ESXi, tener los archivos en un repositorio o servidor, o para mover una maquina virtual de un host a otro, si no tenemos opción de HA, o de Réplicas, o simplemente mantener una copia de nuestra/s máquinas en un repositorio diferente, sin estar en formato vbr, sino directamente como vm de ESXi en este caso.