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:
Voy a describir el funcionamiento y la estructura de una herramienta que creé hace tiempo, pero que creo que puede serle útil a más gente, la herramienta sirve para gestionar los scripts de forma centralizada en entornos de tipo Unix y se llama DCSM de sus siglas en inglés (Distributable Centralized Scripts Manager, Gestor de scripts centralizado y distribuible) esta programada mediante shell scripts y se desarrolló sobre Solaris pero funciona en cualquier Unix, el único requisito es un servidor CVS (era muy complejo instalar subversion en los Solaris 8 😉 ) y crond. A continuación reproduzco el documento que describe esta herramienta.
La situación general, en gran cantidad de redes, a la hora de gestionar los scripts de los servidores, que siempre existen, es crear los scripts específicos para cada servidor, y si es necesario en otro servidor se copia. Este sistema de administración de scripts es muy típico y, aunque evita algo de trabajo, tiene unas claras desventajas, las que intento solucionar son las siguientes:
Estas desventajas se pueden resolver mediante la centralización de la gestión y distribución de los scripts.
Quien no ha compilado un módulo X y al intentar cargarlo se ha encontrado con el desagradable mensaje de que no se puede cargar el módulo por que se ha compilado con una versión de gcc distinta a la utilizada para compilar el kernel. Cada vez que me pasa me encuentro con lo mismo…¿Cómo se que versión de gcc utilizaron para compilar el kernel? y es que es tan sencillo que siempre se me olvida, a ver si al escribirlo aquí se me queda también en la cabeza y si no pues aquí lo tengo… bueno es tan sencillo como ejecutar en un terminal:
shell#: cat /proc/version
¿fácil no?
byte byte 😉