Hace ya algún tiempo realicé una presentación de cómo funciona el proceso de arranque de un PC con sistema operativo GNU/Linux. Si alguna vez te has preguntado cómo sucede esto y te interesa destripar el proceso, esta presentación es para ti 😉 en el archivo FromPowerOn2Shell encontrarás las respuestas.
Disfrútalo
Este script lo desarrollé para un cliente y permite recoger eventos de una o varias máquinas corriendo Microsoft Windows. Se ha probado con Microsoft Windows Server 2003 pero posiblemente funcione bien en otras versiones. A continuación inserto la documentación creada para el cliente, que explica en detalle el funcionamiento.
Descarga el script Remote-Events_log-retriever
Un cliente me pidió que le crease unas máquinas GNU/Linux con varios programas para la monitorización y el análisis del tráfico de red. La idea era repartir varias máquinas por distintos puntos de su extensa red y vigilar durante un tiempo ese segmento.
El cliente tan solo quería varias máquinas con GNU/Linux y algunos programas instalados, que se administrasen remotamente por SSH y enviaran a un servidor splunk central las alertas de Snort. Pero a mí me pareció una ocasión ideal para explotar la flexibilidad de GNU/Linux y las cosas chulas que se pueden hacer de una forma sencilla, así que me planteé los siguientes puntos que debería cubrir la solución:
Para cubrir estos requisitos hay que:
Esto en la práctica implica transformar un GNU/Linux en una caja «tonta» que muestre un menú con las distintas acciones que se le permite realizar al usuario al arrancar la máquina, es decir en el TTy1. Además decidí mostrar el log de Snort en el TTy2.
A continuación muestro la documentación entregada al cliente en la que se explica con detalle la arquitectura. La documentación incluye, en el Anexo, un script que automatiza el proceso de configuración una vez instalado GNU/Linux.
Estos son los pasos a seguir para integrar un servidor RedHat a un AD de Microsoft y poder iniciar sesión con usuarios de AD en RedHat.
Excepto los pasos de instalación de paquetes, el resto de pasos deben servir para el resto de distribuciones de GNU/Linux y para los Unix en general.
Esta es una guía que he desarrollado para un cliente, por lo tanto hay aspectos que se adaptan a sus necesidades (como el cortafuegos). Pero ha grandes rasgos puede ser utilizada en cualquier ámbito.
A la hora de instalar, configurar y administrar un servidor, se debe:
El script bastiona-linux pretende facilitar el proceso de aplicación de los requisitos corporativos de bastionado, a la vez que crea una plataforma flexible para la incorporación de nuevas medidas que puedan surgir en el futuro así como para eliminar o modificar las ya existentes.
El script se puede ejecutar de dos maneras:
1- Mediante la asignación de permisos de ejecución
chmod +x bastiona-REL.sh
./ bastiona-REL.sh
2- Invocando una nueva instancia de bash con el script como argumento
bash bastiona-REL.sh
Es posible indicar como argumento de ejecución las opciones:
Esta es una guía que he desarrollado para un cliente, por lo tanto hay aspectos que se adaptan a sus necesidades (como iptables). Pero ha grandes rasgos puede ser utilizada en cualquier ámbito. También he desarrollado un script modular que automatiza todo el proceso, para más información ir a este post: Script modular para el bastionado de GNU/Linux
A la hora de instalar, configurar y administrar un servidor, se debe:
Last weeks I was using openvas at work, and at reporting time, it stops to work dumping the error
sql_x: sqlite3_step failed: database disk image is malformed
To the log file «/var/log/openvas/openvasmd.log» I was very concerned because there was all the data needed to write the report of 2 weeks of work and it was not possible to go to the customer’s and launch the tests again. Fortunately openvas is working with a sqlite db so these are the steps I’d follow to recover this annoying situation, as sudo run:
cd /var/lib/openvas/mgr
cp tasks.db tasks.db.back
sqlite3 tasks.db
sqlite> pragma integrity_check;
*** in database main ***
Page 46364 is never used
rowid 433 missing from index results_by_type
rowid 446 missing from index results_by_type
rowid 626 missing from index results_by_type
rowid 640 missing from index results_by_type
….….
wrong # of entries in index report_results_by_result
wrong # of entries in index report_results_by_report
So there is a problem in the database, lets follow the sqlite db recovering procedure, that is dumping to sql file an create a new db
sqlite> .output tasks.sql
sqlite> .dump
sqlite> .exit
rm tasks.db
sqlite3 -init tasks.sql tasks2.db
— Loading resources from tasks.sql
SQLite version 3.7.7 2011-06-23 19:49:22
Enter «.help» for instructions
Enter SQL statements terminated with a «;»
sqlite> .exit
And now start openvas as usual 😉
Here you have a bash script that scan a device and allow the selection of items to be added to a template in a wizard way, it support extension by modules in two ways, to manage some special OIDs (like NIC ones) and by defining output modules (that builds the final result, at the moment a zabbix template)
The zabbix template module can build multi or single graph items.
Just download, untar the file, cd make_template and run:
bash make_template.sh -i -a IP_ADDRESS SNMP OPTIONS
and follow the wizard.
The script generate an OID file that is used by template_modules to make the final template
send me bugs (sure they ll be there) improvements you do or whatever related to the script
Download it now
enjoy it 😉
Hasta hace poco no sabía muy bien de que iba esto del U-boot, pero al intentar actualizar mi apad M70003 he tenido que entender su funcionamiento. U-boot es un gestor de arranque universal para Linux pero… ¿Es universal y solo para Linux? sí, es universal en cuanto al hardware, está diseñado para utilizarse en dispositivos enbebidos y soporta una gran cantidad. Su estructura es sencilla, se basa en archivos de imágen binarios cuya carga y ejecución se controla mediante variables de entorno y comandos, estos comandos pueden agruparse en scripts convertidos a archivos imágen de U-boot.
Bien lo primero que hay que entender es que los archivos imágen que usa U-boot no son iguales, es decir que existe más de un tipo de imágenes, de hecho las imágenes no son más que archivos con una cabecera añadida mediante el comando mkimage de U-boot, estos archivos pueden ser un kernel o un archivo de texto simple, la cabecera contiene información sobre: magic number para reconocer que es una imágen de U-boot, el tipo de archivo que contiene la imágen, a que plataforma va destinado, fecha de creación, nombre, direcciones de carga, compresión… y un hash del archivo que incluye para comprobar que no se ha modificado la imágen, por lo tanto cada modifición de un archivo conlleva la creación de una imágen nueva para cuadrar el hash.
Un proceso de inicio básico de U-boot es así:
Veamos más detalles sobre estos pasos:
1-La carga de U-boot
Los sistemas embebidos suelen funcionar sin un chip BIOS para abaratar costes de producción y porque realmente no es necesario ya que sus funciones son muy concretas y limitadas, por lo tanto hay que realizar las funciones básicas de otro modo, esta es la función de U-boot. Esta imágen tiene que tener capacidad para comunicarse con los distintos dispositivos del sistema embebido, ya que será la encargada de iniciar la pantalla, gestionar la memória, reproducir alertas sonoras y cualquier otra función que se quiera realizar al iniciar el sistema como mover archivos o conectarse a la red para usar BOOTP. U-boot soporta unos cuantos sistemas de archivos*1: de chip (Flash, MTD, ROM) de memória (tmpfs) y de disco (ramdisk, jffs2, cramfs, ext2…).
Una vez cargado U-boot y según los parámetros que se le hayan pasado se obtendrá una consola o este iniciará la carga del sistema embebido.
2-Establecimiento de las variable de entorno U-boot
U-boot admite una serie de comandos*2 que sirven para multiples propósitos: gestión de dispositivos, extraer información sobre el sistema, mover archivos, control de ejecución… y de variables de entorno*3 que establecen parámetros utilizados por los comandos: resolución de la pantalla, dispositivos a iniciar, tema…
La ejecución de estos comandos se puede automatizar mediante scripts, para ello hay que crear un archivo de texto, introducir los comandos que queramos y crear el archivo imágen que ejecutará U-boot, para crear la imágen hay que instalar el programa mkimage (suele estar disponible en los repositorios de las distribuciones GNU/Linux) y ejecutar:
mkimage -A arm -T script -n scriprinicio -d ruta_al_archivo.txt ruta_de_destino
A excepción del parámetro -T que indica el tipo de imágen que se va a crear, en este caso script, el resto de parámetro puede variar (-A: arquitectura destino, -n nombre) además hay otros parámetros, para obtener un listado ejecutar
mkimage
Para obtener información sobre una imágen ya creada hay que ejecutar
mkimage -l ruta_de_la_imagen
En el caso de tener una imágen de tipo script y querer modificarla, es muy sencillo, tan solo hay que copiarla, abrirla con un editor de texto cualquiera y eliminar la primera linea, teniendo en cuenta que al final puede haber un comando valido que hay que mantener, osea buscamos al final de la primera linea y si hay carácteres ascii comprensibles no los borramos.
3-Carga de la imágen Linux
Una vez ejecutados los comandos: inicializados los dispositivos, cargado los archivos… sel carga el núcleo de Linux pasandole como argumentos los establecidos por la variable bootargs
Para crear la imágen de Linux con las cabeceras necesarias para U-boot, hay que configurar un kernel y compilarlo con compilación cruzada para la arquitectura destino, esto requiere tener las utilidades necesarias para compilación cruzada, no voy a explicar como realizar estos pasos porque queda fuera del ámbito del post, tan solo indicar que teniendo mkimage en el PATH del sistema en lugar de especificar bzImage u otros hay que compilar con el parámetro uImage, el comando sería algo así
make ARCH=arm CROSS_COMPILE=ruta_a_las_toolchain- modules uImage
Referencias
1-Sistemas de archivo soportados por U-boot