Archivo categoría GNU/Linux
VMware: ¿Cómo añadir un disco duro a una máquina virtual Linux sin reiniciar?
Por Ángel Carrasco - GNU/Linux, Virtualización, VMware - 08/11/2012
Más de una vez tenemos que añadir un disco duro "en caliente" a una máquina virtual creada por nuestro hipervisor. En nuestro caso usamos VMware, pero esto es aplicable a otros productos.
El problema que nos surge es, ¿cómo podemos hacerlo sin reiniciar un servidor en producción?
La solución reside en volver a escanear el bus SCSI.
Para ello, primero localizaremos qué host tenemos disponible.
ls /sys/class/scsi_host
Acto seguido, elegiremos el host donde está el disco duro y ejecutaremos:
echo "- - -" > /sys/class/scsi_host/host1/scan
De esta forma, ya tendremos disponible el disco duro sin reiniciar.
Espero que os sea tan útil como a mí me ha sido.
Repositorios online en GNU/Debian
Por Ángel Carrasco - GNU/Linux - 18/09/2012
Al hilo de nuestra entrada "Cómo añadir repositorios públicos a Oracle Enterprise Linux", un lector nos ha realizado una serie de preguntas acerca de los repositorios de GNU/Debian. Debido a su interés general, hemos decidido publicarlas junto con nuestras respuestas.
Lector:¿Cuál podría ser un buen mirror para nuestros servidores?
Autor: La respuesta a esta pregunta no es sencilla porque depende de varios aspectos como son la cercanía geográfica, el tiempo de acceso y la estabilidad. En mi caso, al vivir en el sur de España, un mirror que cumplía estas características era CICA y durante estos años me ha demostrado que funcionan especialmente bien.
Otro aspecto a tener en cuenta es si accedemos a él vía el protocolo http o el protocolo ftp. Aunque no debieran de diferir mucho, el protocolo http suele ir más rápido y da menos problemas para configurar los cortafuegos, etc.
Lector: ¿Cómo se configura la herramienta apt-get para que obtenga los paquetes vía proxy http?
Autor: En el fichero /etc/apt/apt.conf debemos añadir la siguiente línea:
Acquire::http::Proxy "http://ProxyHTTP:Puerto";
Lector: ¿Qué es el fichero source.list y qué contiene?
Autor: Tal como indica el nombre, contiene una lista de fuentes -source.list- donde se proveen paquetes deb para nuestra GNU/Debian y tiene un formato característico que explicamos a continuación:
1. Tipo de paquete: Puede haber dos opciones, deb para binarios y deb-src para fuentes.
2. URL: Para acceder a los paquetes, debemos indicar una url servida bajo protocolo http o ftp.
3. Distribución: Generalmente hay tres distribuciones:
a. Estable (stable). Esta versión siempre será la vigente y está destinada a producción. Se puede substituir la palabra stable por el nombre de la versión actual de GNU/Debian. Por cierto, puede haber variantes para indicar que se tratan de paquetes de la rama estable que han sido aplicados parches de seguridad.
b. En pruebas (testing). Normalmente se trata de versiones de paquetes a medio camino entre la versión estable y la última. Se suele utilizar para probar nuevas características en algún paquete en que estemos interesados o para uso domestico.
c. Inestable (unstable). Está destinada a la experimentación y a conocer qué novedades o cambios puede tener la nueva versión que nos espera en GNU/Debian, por lo tanto, no tiene garantía alguna de funcionar. Como ene l caso de la distribución estable, puede ser substituida la palabra unstable por el nombre de la versión futura de GNU/Debian.
4. Áreas que, en otras palabras, serían grupos determinados de paquetes. Suele haber tres:
a. Main: Paquetes bajo licencia libre y que emplean otros paquetes con licencias de la misma naturaleza.
b. Contrib: Paquetes bajo licencia libre pero que necesitan paquetes que tienen licencias privativas.
c. Non-free: Paquetes que tienen alguna condición onerosa que restringe su uso o distribución.
Lector: ¿Puedes mostrar tu source.list?
Autor: Sin problemas, he aquí:
deb http://ftp.cica.es/debian/ stable main non-free contrib
deb-src http://ftp.cica.es/debian/ stable main non-free contrib
deb http://security.debian.org/ stable/updates main non-free contrib
deb-src http://security.debian.org/ stable/updates main non-free contrib
deb http://ftp.cica.es/debian/ stable-updates main non-free contrib
deb-src http://ftp.cica.es/debian/ stable-updates main non-free contrib
Lector: ¿Dónde puedo incluir otros repositorios como en el caso del software OpenVAS?
Autor: Lo recomendable sería crear el fichero en cuestión en /etc/apt/sources.list.d/ con un fichero que tenga el formato descrito para source.list.
Lector: Si añado los repositorios, ¿cómo puedo acceder a ellos y actualizar mi base de datos de paquetes?
Autor: Debes ejecutar:
# apt-get update
Si el resultado es correcto, entonces tendrás actualizada tu base de datos con todos los paquetes de tus repositorios. Si da fallo en uno de ellos, no podrás contar con sus paquetes y suele ser una situación peliaguda porque pueden ser necesarios para cumplir las dependencias de otros.
Lector: ¿Cómo puedo ir actualizando mi versión GNU/Debian sin problemas?
Autor: Garantías no existen pero si cada cierto tiempo vas ejecutando el comando que te indicaré más adelante, conseguirás dos objetivos. El primero es tener la distribución con todas las actualizaciones de seguridad aplicadas y el segundo es poder tener la última release de GNU/Debian. Esto último facilita y mucho el salto de una versión a otra.
# apt-get dist-upgrade
Espero que las respuestas a estas preguntas, os sean tan útiles como me han sido a mí.
Cómo añadir repositorios públicos a Oracle Enterprise Linux
Por Ángel Carrasco - GNU/Linux - 17/09/2012
Lo que venimos de GNU/Debian, estamos acostumbrados a utilizar los repositorios en Internet para:
1. Instalar paquetes
2. Actualizar paquetes (o la distribución entera)
3. Aplicar las actualizaciones de seguridad, mejoras o algunos patch.
Sin embargo, Oracle Enterprise Linux (OEL) utiliza como medio de instalación de paquetes, por defecto, su DVD de instalación. Lo cual, resulta bastante engorroso cuando queremos actualizar o aplicar las actualizaciones de seguridad, etc. Por tanto, ¿cómo podemos configurar los repositorios online en OEL? y ¿qué alcance tienen?
Permitidnos contestar la segunda pregunta primero. Salvo que se adquiera una licencia y te acojas a Unbreakable Linux Network (ULN), no tendrás acceso a las actualizaciones de seguridad, mejoras y etc. Para configurar repositorios públicos que permitan instalar y actualizar paquetes, explicamos los pasos a continuación.
Configuración de los repositorios públicos
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol6.repo
Inciso: El número que aparece el nombre del fichero indica la versión.
Por último, debemos abrir el fichero public-yum-ol6.repo y modificar el valor de enabled=0 a enabled=1 en todos aquellos que deseemos utilizar.
Con esto ya estaría preparado el sistema para usar los repositorios online.
Instrucciones útiles de YUM
Para comprobar qué repositorios tenemos activos:
# yum repolist
Para instalar un paquete que nos interese:
# yum install paquete
Para buscar un paquete entre los repositorios:
# yum search paquete
Para comprobar si existen actualizaciones:
# yum check-update
Para actualizar los paquetes instalados en nuestro sistema operativo:
# yum update
Espero que os sea tan útil como ha sido para mí.
Cómo verificar la integridad de datos con Tripwire
Por Ángel Carrasco - CHFI, GNU/Linux, Hacking - 14/09/2012
Cada vez más, debemos tener un fuerte control sobre la integridad de nuestros datos, en especial, cuando el servidor tiene acceso a Internet. Para cubrir esta necesidad, en el mundo del software libre hay dos herramientas que se disputan el podio, una es Aide y otra es Tripwire.
Como mi amigo Alejandro García, autor del Blog RM-rf.es, ha escrito un fabuloso artículo sobre Aide. Me voy a centrar en el uso y "disfrute" de Tripwire.
Qué hace realmente Tripwire
Para empezar, daremos unas leves pinceladas al funcionamiento de este programa. Tripwire genera una base de datos encriptada con las propiedades de cada elemento de nuestro sistema de ficheros. Esta base de datos es empleada para comprobar los cambios acaecidos en el sistema de ficheros. Si estas modificaciones han sido realizadas y/o autorizadas por nosotros, la base de datos será actualiza, en caso contrario, habrá que investigar qué ha sucedido.
Teniendo en cuenta lo anterior, lo ideal sería instalarlo en un servidor recién instalado ya que no ha sido comprometido por agentes externos o al menos, tiene muy pocas posibilidades de que sea así. Si el servidor lleva ya cierto tiempo prestando servicios, antes de implementarlo, sería recomendable analizarlo a través de diferentes herramientas.
Instalación de Tripwire
El proceso de instalación de Tripwire, se divide en las siguientes fases:
- Instalación del software.
- Creación de la clave del site y la local.
- Creación e implementación del fichero de configuración y de la política.
- Aplicación de permisos adecuados a los ficheros de configuración y de la política.
Casi todas las distribuciones de GNU/Linux disponen de una versión empaquetada, así que suele ser muy fácil instalar este software. En el caso de GNU/Debian, el primer paso es el siguiente:
# apt-get install tripwire
El resto de pasos son facilitados gracias a los asistentes que despliega.
No os preocupéis, si vuestra distribución no cuenta con estos asistentes o no os apetece usarlos, a continuación explicamos cómo se pueden realizar estas tareas manualmente a través de la herramienta de administración twadmin.
Generación de claves
Las claves son importantísimas y serán solicitadas en todos los procesos que impliquen la modificación de la configuración, de la política y de la base de datos. Os recomendamos que sean diferentes entre sí.
Tenemos que generar dos, una para el site y otra para local que podrán ser almacenadas donde se quiera, por ejemplo, en mi caso será /etc/tripwire. Por convención, a la primera se la llama site.key y a la segunda HOST-local.key, siendo HOST sustituida por el nombre del servidor.
# twadmin -m G -L /etc/tripwire/dummy-local.key -S /etc/tripwire/site.key
Generación de la configuración y la política
Nos va a sorprender la forma que Tripwire tiene para generar la configuración y la política. Para empezar debemos tener siempre presente que se trata de un analizador de la integridad de los datos del sistema y por ese motivo, empieza por su propia configuración y política.
Al margen de la distribución o sistema de paquetes, existen dos ficheros twcfg.txt y twpol.txt que poseen la configuración y la política por defecto respectivamente. Son ficheros de texto plano y por tanto, editables sin esfuerzo alguno. Nosotros los vamos a utilizar de plantilla y a través de twadmin, generaremos unas versiones binarias cifradas y firmadas que Tripwire utilizará para su funcionamiento.
Os recomendamos revisar los ficheros twcfg.txt y twpol.txt para comprobar si cumplen con nuestras necesidades.
El primer fichero que debemos crear es el fichero de configuración y posteriormente, el de política. Creo que también por convención, el fichero de configuración se llama tw.cfg y el de políticas tw.pol, no obstante, si alguien desea otros nombres, deberá modificar las plantillas previamente indicadas.
# twadmin -m F -S /etc/tripwire/site.key -c /etc/tripwire/tw.cfg -Q "ClaveSite" twcfg.txt
A continuación, haremos lo mismo con el fichero de la política tw.pol:
# twadmin -m P -S /etc/tripwire/site.key -c /etc/tripwire/tw.cfg -Q "ClaveSite" twpol.txt
Creación de la base de datos
El tiempo de creación de la base de datos será determinado por el número de elementos de nuestro sistema de ficheros. Debemos tener paciencia si asumimos un sistema complejo como, por ejemplo, un servidor de base de datos.
Para la creación de la base de datos inicial, debemos ejecutar:
# tripwire -m i
En medio del proceso, nos pedirá la clave local para poder escribir en la base de datos de Tripwire.
Comprobación de la integridad de datos
Para testar que Tripware está comprobando la integridad de datos, vamos a hacer una prueba muy simple que consiste en modificar una línea dentro del fichero /etc/hosts. En concreto añadiremos la línea siguiente:
# Esto es una prueba para Tripware.
Ahora vamos a verificar si detecta el cambio en la integridad de los datos.
# tripwire -m c
El informe aparecerá por pantalla y también se guardará una copia en nuestro sistema de ficheros. El informe tiene un nombre normalizado que consiste en [NombreDeHost]-[Año][Mes][Día]-[Hora][Minuto][Segundo].twr lo que facilita la creación de scripts. Por cierto, estos ficheros son binarios y requieren de la herramienta twprint para mostrarse en pantalla, tal como hacemos a continuación:
# twprint -m r -r /var/lib/tripwire/report/dummy-20120913-122534.twr
Como suelen ser informes muy largos, suele ser conveniente utilizar alguna herramienta como more o pg. Existe la posibilidad de generar un informe parcial pero hasta que no estemos muy habituados a la información que se puede obtener, es mejor, obviadlo por el momento.
Volviendo a la prueba que estamos realizando, vamos a analizar el informe donde hay dos secciones que un administrador de sistemas o analista de seguridad ha de fijarse.
La primera hace mención a la sección del sistema de ficheros y este es un ejemplo:
Nos debemos fijar las rules names que les antecede un asterisco ya que esta es la forma que tiene Tripware de informarnos que ha habidos cambios. Ahora bien, la rule name "Devices & Kernel information" no le prestaría mayor atención porque se trata de los directorios que monta el Kernel y que como todos sabemos, están en constante cambio. Sin embargo, las otras dos rules names marcadas por un asterisco sí vamos a estudiarlas con detalle.
Como no, aparece nuestro fichero /etc/hosts que hemos modificado adrede y por sorpresa, muestra el /root/.viminfo. Entonces, vamos a explicar lo que debemos hacer casi de una forma matemática.
Todo fichero modificado es sospechoso siempre que:
- No lo hayamos modificado nosotros.
- No hayamos autorizado su modificación.
- No han sido generados los cambios por el uso de algún software de forma automática.
Para todo los demás casos, hay que tomar medidas y dependiendo del nivel de seguridad (Security Level) más o menos severas o drásticas.
El caso de la modificación de /etc/hosts pertenece al primer caso, lo hicimos nosotros. El caso de /root/.viminfo se debe al tercer caso. No obstante, un buen analista de seguridad (con mode paranoic ON) echaría un vistazo.
Cuando tenemos claro que las modificaciones han sido realizadas o autorizadas por nosotros o se trata del comportamiento normal del software instalado, debemos consolidar estos cambios en la base de datos de Tripwire. Para ello hay dos métodos a seguir, el primero consiste en volver a analizar la integridad de nuestros datos, revisar el informe posterior y si damos nuestra aprobación, insertarlos en la base de datos y el segundo, que consiste en usar un informe ya generado y que hemos aprobado.
Para el caso de querer verificar la integridad de nuestros datos, revisar el informe y posteriormente modificar la base de datos, debemos ejecutar:
# tripwire -m c -I
Para aprovechar un informe ya validado por nosotros, tenemos que teclear:
# tripwire -m u -r fichero.twr
En ambos casos, como se ha de modificar la base de datos, nos solicitará la clave local.
Tarea diaria
Debido a la importancia de comprobar la integridad de nuestros sistemas, recomendamos encarecidamente que se programe una tarea diaria donde se genere el informe con los cambios que haya podido sufrir el sistema.
Para ello, deberemos editar añadir una tarea en el sistema cron de nuestro servidor, por ejemplo:
0 3 * * * /usr/sbin/tripwire -m c
También existe la posibilidad de añadir un script a /etc/cron.daily donde se ejecute esta operación como por ejemplo:
#!/bin/sh /usr/sbin/tripwire -m c
Personalmente prefiero la primera opción ya que podemos configurar el momento que se realiza y así evitamos que se solape a tareas como las copias de seguridad, parcheos u otras modificaciones generales del sistema. Es preferible realizar el análisis en un momento que sepamos que el servidor se encuentra bastante "tranquilo", no es porque cargue la máquina, que realmente no es así, sino para evitar que obtenga unos datos muy parciales.
Aseguramiento de Tripwire
Por último, hay una serie de pautas que debemos seguir para asegurar nuestro sistema Tripwire.
- Hay que eliminar todo fichero de texto con versiones de la configuración o política. Como vulgarmente se dice, hay que evitar dar pistas al enemigo.
- Debemos aplicar a los binarios /usr/sbin/tripwire, /usr/sbin/twadmin, /usr/sbin/twprint y /usr/sbin/siggen los permisos de sistema 0500 (
-r-x------). - De la misma forma, a los directorios de configuración /etc/tripwire y de informes /var/lib/tripwire y a sus contenidos deben tener los permisos de sistema 0700 (
-rwx------). - Por último, se ha de aplicar permisos de sistema 0600 (
-rw-------) a etc/tripwire/tw.cfg y a /etc/tripwire/tw.pol.
Para facilitar, estas son las instrucciones a ejecutar:
# chmod 0600 etc/tripwire/tw.cfg /etc/tripwire/tw.pol # chmod 0500 /usr/sbin/tripwire /usr/sbin/twadmin /usr/sbin/twprint /usr/sbin/siggen # chmod 0700 /etc/tripwire /var/lib/tripwire # chmod -R u=rwX,go-rwx /var/lib/tripwire
Donde X será el permiso de ejecución en caso de fichero y de acceso en caso de directorio.
Para más información
Tripware viene con algunas páginas man que proveen una información sucinta y clara, sin ejemplos…
TRIPWIRE(8) - Manual del programa
TWINTRO(8) - Una introducción al Tripwire
TWADMIN(8) – Manual de la herramienta de administración
TWPRINT(8) – Manual de la herramienta de visionado de informes
TWCONFIG(8) - Información sobre el fichero de configuración
TWPOLICY(8) - Información sobre el fichero de política
Despedida
Os puedo asegurar y ya desde un plano profesional que esta herramienta me ha ayudado muchisimo en mis tareas de administrador y se encuentra en una de las primeras herramientas que instaldo cuando implemento un nuevo servidor.
Espero que os sea tan útil como a mí me lo ha sido.
Centralizar los logs vía Web
Por Ángel Carrasco - CEH, CHFI, Logs - 14/06/2012
Introducción
Uno de los mayores dolores de cabeza de un administrador de sistemas, es la gestión de los logs de sus servidores. Al final, se necesita una herramienta -preferiblemente web- para la gestión de los logs y así poder llevar un seguimiento de los servicios o analizar una incidencia. Por ello, yo utilizo LogAnalyzer de Adiscon y os voy a contar como lo he implementado en un servidor GNU/Debian. Aunque yo haya utilizado este sistema operativo, no excluye a todo aquel sistema operativo que permita la implementación LAMP y del servicio Rsyslog.
Requerimientos
Por ello, antes de empezar debemos comprobar si funcionan correctamente los siguientes servicios:
-
Servidor web con soporte PHP
-
Servidor de bases de datos MySQL
-
Servicio NTP
El servicio NTP no se requiere para poder instalar el software, sin embargo, no debemos perder de vista que si no contamos con una correcta precisión, el análisis de los logs puede ser bastante caótico.
Instalación del servicio Rsyslog
Comprobados los servicios indicados anteriormente, procedemos a instalar el servicio Rsyslog con soporte para bases de datos MySQL y para el protocolo RELP (Reliable Event Logging Protocol:
# apt-get install rsyslog-mysql rsyslog-relp
En el caso concreto de GNU/Debian, nos pedirá la contraseña del administrador del servidor de bases de datos -normalmente el usuario root- y que pongamos dos veces la contraseña para el usuario rsyslog que tendrá todos los permisos en la base de datos syslog, creada en la base de datos para almacenar las salidas del servicio Rsyslog.
Para otras distribuciones, os ruego que leais la documentación pertinente. Generalmente en ella, incluye un fichero SQL para crear las tablas, los usuarios y los permisos que deberá tener la base de datos syslog.
Una vez creada la base de datos syslog, su usuario rsyslog e instalado el servicio Rsyslog, sólo queda configurarlo, cosa que haremos en tres pasos.
Configuración del servicio Rsyslog
El primero paso será aceptar los mensajes syslog por el puerto 514 tanto TCP como UDP, lo cual será necesario para mantener la compatibilidad con la mayoría de los dispositivos de red que emplean o pueden utilizar un servidor centralizado de logs. Por eso, debemos descomentar las siguientes lineas en el /etc/rsyslog.conf.
# provides UDP syslog reception
$ModLoad imudp $UDPServerRun 514 # provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514
El segundo paso será habilitar el soporte para el protocolo RELP. Este protocolo se encarga de transmitir y recibir registros syslog por la red de forma más segura que a través de TCP. Para ello, creamos el fichero /etc/rsyslog.d/relp.conf con la siguiente información:
$ModLoad imrelp $InputRELPServerRun 10514
El tercer paso consiste en asegurar la viabilidad del servidor centralizado de logs creando un sistema de buffering ya que deberá asumir una gran cantidad de datos de syslog a la base de datos. Por ello, lo primero que debemos realizar es crear un directorio donde almacenaremos los ficheros en cola que sean necesarios:
# mkdir -p /var/rsyslog/queue
Posteriormente, debermos añadir la configuración siguiente al fichero /etc/rsyslog.conf.
# Sistema de buffering: $WorkDirectory /var/rsyslog/queue # directorio por defecto de los ficheros encolados $ActionQueueType LinkedList # usar proceso asincrono $ActionQueueFileName dbq ; # establece el nombre de fichero y tambien activa el modo disco $ActionResumeRetryCount -1 ; # reintentos infinitos en caso de fallo de insercion
Llegados aquí, sólo nos falta reiniciar el servicio Rsyslog:
# service rsyslog restart
Instalación del software LogAnalyzer
Ahora tenemos que instalar el software que nos permitirá ver los datos almacenados en la base de datos vía Web. Para ello, bajaremos el software, lo descomprimiremos y lo copiaremos al directorio donde tenemos nuestra página web.
# wget http://download.adiscon.com/loganalyzer/loganalyzer-3.4.3.tar.gz # tar xvzf loganalyzer-3.4.3.tar.gz # cd loganalyzer-3.4.3 # mkdir /var/www/logs # cp -R src/* /var/www/logs/ # cp contrib/* /var/www/logs/ # cd /var/www/logs/ # chmod +x configure.sh secure.sh # ./configure.sh
Para activar la autenticación del software LogAnalyzer, necesitamos crear una base de datos vacía para almacenar los usuarios y sus privilegios. Se puede indicar el nombre que os apetezca pero en mi caso, para la base de datos elegí el nombre Usuarios_LogAnalyzer y el usuario Admin_LA con la contraseña clave.
# mysql -p
mysql> create database Usuarios_LogAnalyzer; mysql> grant all on Usuarios_LogAnalyzer.* to Admin_LA@'localhost' identified by 'clave&';
Configuración del software LogAnalyzer
Para configurar el software, debemos abrir un navegador y escribir la siguiente url: http://IP/logs/install.php
Como el producto está en un perfecto inglés y me imagino que os interesa qué parámetros he empleado para que podamos ponerlo a funcionar ya, os transcribo sólo las opciones que he modificado.
-
Message character limit for the main view = 80 (default)
Lo cambié a 0 para que apareciera el mensaje entero.
- Enable the user database.
La habilité y puse lo siguientes datos:
Server: localhost
Port: 3306
Name: Usuarios_LogAnalyzer
User: root
Pass: (la que tiene)
En el siguiente paso, creará las tablas y datos necesarios.
- Se ha de crear por defecto el usuario administrador del software así que recomiendo que tengáis cuidado con los datos que ponéis ya que es imprescindible para gestionarlo.
- En el paso de la configuración de la base de datos de logs
Name: Es meramente descriptivo. Yo puse Mis Logs de MySQL -ya sé que lo mio no es la imaginación-.
Source Type = MYSQL Native
Select View = Syslog Fields
Table type = MonitorWare
Database Host = localhost
Database Name = Syslog
Database Tablename = SystemEvents
Database User = rsyslog
Database Pass = (La que pusimos anteriormente)
Enable Row Counting = no
Si hemos hecho todo bien, veremos los registros del servidor centralizado de logs.
Configuración de los equipos
Para los servidores Solaris, GNU/Linux y *BSD, hay dos formas de configurar el servicio syslog. Si el servicio syslog instalado permite RELP, se ha de añadir las siguientes líneas al fichero de su configuración:
$ModLoad omrelp *.* : omrelp : IP_Servidor_Centralizado_Logs : 10514 ;RSYSLOG_ForwardFormat;
Nota: El puerto 10514 fue configurado anteriormente, si por lo que sea, coincidiera que está ocupado por otro servicio, puede cambiarse sin problemas.
Si el servicio syslog es el tradicional:
*.* @IP_Servidor_Centralizado_Logs
Por supuesto, cuando acabemos de configurar el servicio, deberá ser reiniciado.
En el caso de los dispositivos de red, sólo debemos indicar donde sea necesario la IP de nuestro servidor centralizado de logs y el puerto 514 tanto TCP como UDP según lo requiera.
Espero que os sea tan útil como ha sido para mí.
Getlibs – Cómo resolver dependencias de 32 bits en una GNU/Debian de 64 bits
Por Ángel Carrasco - GNU/Linux - 16/05/2012
A pesar de que la ya larga existencia de sistemas de 64 bits en GNU/Linux, muchas aplicaciones siguen compiladas a 32 bits. En principio no debería haber muchos problemas pero a veces, identificar e instalar aquellas librerías necesarias para que funcionen correctamente nuestros programas, se puede volver una tortura medieval.
Afortunadamente en sistemas GNU/Debian y GNU/Ubuntu crearon un paquete llamado Getlibs que busca y obtiene las librerías necesarias para ejecutar correctamente cualquier programa de 32 bits compatible con nuestro sistema operativo (en su versión de 32 bits). Hace tiempo que este programa dejó de estar en url como http://frozenfox.freehostia.com/cappy/. Así pues, a continuación dejo un enlace interno para que podáis bajárosla y utilizarla.
El primer paso es instalar el software Getlibs:
# dpkg -i getlibs-all.deb
Una vez ya instalado, podemos decargar todas las librerías necesarias para un programa de la siguiente forma:
# getlibs /usr/local/bin/programa
Espero que os sea útil.
Cómo ver las fechas y horas en los logs de Squid
Por Ángel Carrasco - Conversiones, GNU/Linux, Perl, Redes, Squid - 14/05/2012
Como administrador del servicio proxy Squid, estoy encantado con su funcionamiento. Sin embargo, la gestión de fechas y horas en los ficheros logs suele ser un poco molesto. Sé que se puede cambiar a nivel de configuración pero, a veces, no es posible si queremos guardar la compatibilidad con otras aplicaciones. Para ellos, hay un pequeño truco en perl para convertir de timestamp a un formato leíble por un ser humano:
# perl -pe 's/[\d\.]+/localtime($&)/e' /var/log/squid/access.log
Como podéis observar, también puede ser utilizado en otros servicios que utilicen este tipo de fecha y al ser perl, puede ser usado en casi cualquier *ix sin problemas.
Espero que os sea tan útil como a mí me ha sido.
Cómo intercambiar las llaves entre servicios SSH
Por Ángel Carrasco - Encriptación, GNU/Linux, Redes, SSH - 29/03/2012
Muchas veces debemos automatizar el acceso a un servidor para ejecutar alguna tarea y como toda operación de administración, ha de hacerse sin comprometer la seguridad. Para ello, nuestra idea es poder acceder vía SSH sin necesidad de autenticarse y con la garantía que sólo entra un determinado servidor.
Pongamos por ejemplo, las siguientes máquinas:
- Servidor 1: Destino al que queremos acceder.
- Servidor 2: Origen desde donde queremos acceder al servidor 1.
El primer paso será generar el par de claves en el servidor 1. Hay diferentes herramientas pero yo suelo utilizar ssh-keygen. Posee un gran número de opciones por lo que ruego que se revise su man antes de usar.
Para generar el par de claves de tipo RSA, por ejemplo:
$ ssh-keygen -t rsa
El sistema mostrará lo siguiente:
Enter file in which to save the key (/root/.ssh/id_rsa):
Acepto sin más, ya que me parece correcto este nombre.
Enter passphrase (empty for no passphrase):
Como quiero automatizar la tarea para que no me pida la contraseña, simplemente, lo acepto en blanco.
Enter same passphrase again:
Ídem de lo anterior.
Entonces me generará dos ficheros en $HOME/.ssh:
- id_rsa: Fichero de la clave privada.
- id_rsa.pub: Fichero de la clave pública.
Una vez obtenido el fichero id_rsa.pub, lo transfiero al Servidor 2. De esta forma, podrá acceder al Servidor 1 ya que contiene posee su clave pública y sólo podrá acceder servidor 2.
En el servidor 2, copio el contenido de id_rsa.pub al fichero authorized_keys ubicado en $HOME/.ssh:
$ cat id_rsa.pub >> $HOME/.ssh/authorized_key
De esta forma, ya se puede acceder a servidor 1 con garantías y sin necesidad de teclear la contraseña del usuario en cuestión.
Cómo enviar correos desde la línea de comandos en Perl – II
Por Ángel Carrasco - GNU/Linux - 14/02/2012
Esta entrada es una continuación de la anterior entrada. En vez de escribir nosotros mismos el cuerpo del mensaje, es nuestro programa quien lo carga a través de la entrada estándar.
#!/usr/bin/perl -w
$TO = $ARGV[0];
$SUBJECT = $ARGV[1];
@auxMSG = <STDIN>;
# Extraemos el contenido de la rediccion
$MSG="";
foreach $tmpMSG (@auxMSG) {
$MSG = $MSG . $tmpMSG;
}
# Solo debug
#print "TO: " . $TO . "\n";
#print "SUBJECT: " . $SUBJECT . "\n";
#print "MSG:\n" . $MSG . "\n";
# Enviamos el correo
open (MAIL,"|/usr/lib/sendmail -t");
print MAIL "To: ". $TO . "\n";
print MAIL "From: servidor\@dominio.com\n";
print MAIL "Subject: " . $SUBJECT . "\n\n";
print MAIL $MSG . "\n";
close(MAIL);
exit(1);
Espero que os sea de utilidad.
Cómo enviar correos desde la línea de comandos en Perl – I
Por Ángel Carrasco - GNU/Linux - 14/02/2012
Siempre tenemos algún servicio que necesita poder enviar un correo para avisarnos de alguna incidencia. Lamentablemente en algunos *ix comerciales, tienen la mala costumbre de tener algunos comandos antidiluvianos cuyas interdependencias con servicios modificados por el fabricante, hace que no siempre funcione como queramos.
Como este tipo de cosas no debe detenernos en nuestra labor de administración, os propongo este simple script en Perl que espero os sea útil.
Por cierto, como estoy más que cansado que no se pueda enviar más de una línea, en especial, cuando requerimos más información para realizar un troubleshooting, el script permite enviar diferentes líneas de texto.
#!/usr/bin/perl -w
# Salgo si no me llegan todos los parametros
$num_args = $#ARGV + 1;
if ($num_args != 3) {
print "\nUso: enviar_correo.pl TO SUBJECT MSG.\n";
print "TO: Destinatario o destinatarios unidos por coma.\n";
print "SUBJECT: Asunto del correo electronico entre dobles comillas.\n";
print "MSG: Cuerpo del mensaje entre comillado doble y \\n para los retornos de carro.\n\n";
exit;
}
# Convertimos nuestro retorno de carro en un verdadero retorno de carro
$MSG =~ s/\\n/\n/g;
# Solo debug
#print "TO: " . $TO . "\n";
#print "SUBJECT: " . $SUBJECT . "\n";
#print "MSG:\n" . $MSG . "\n";
# Enviamos el correo
open (MAIL,"|/usr/lib/sendmail -t");
print MAIL "To: ". $TO . "\n";
print MAIL "From: servidor\@dominio.com\n";
print MAIL "Subject: " . $SUBJECT . "\n\n";
print MAIL $MSG . "\n";
close(MAIL);
exit(1);
Esta es una forma de hacerlo, si tienes una mejor, compártela con nosotros y entre todos podemos aprender.



