Archivo categoría GNU/Linux

VMware: ¿Cómo añadir un disco duro a una máquina virtual Linux sin reiniciar?

 

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.

, , ,

No hay Comentarios

Repositorios online en GNU/Debian

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í.

, ,

No hay Comentarios

Cómo añadir repositorios públicos a Oracle Enterprise Linux

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í.

, , , ,

1 Comentario

Cómo verificar la integridad de datos con Tripwire

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:

  1. Instalación del software.
  2. Creación de la clave del site y la local.
  3. Creación e implementación del fichero de configuración y de la política.
  4. 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:

Sección del sistemas de ficheros de Tripware

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.

 

Descripción de Rules Names

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:

  1. No lo hayamos modificado nosotros.
  2. No hayamos autorizado su modificación.
  3. 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.

  1. 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.
  2. 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------).
  3. 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------).
  4. 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.

, , ,

No hay Comentarios

Centralizar los logs vía Web

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í.

 

 

, , ,

1 Comentario

Getlibs – Cómo resolver dependencias de 32 bits en una GNU/Debian de 64 bits

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.

getlibs-all

 

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.

 

 

, , ,

No hay Comentarios

Cómo ver las fechas y horas en los logs de Squid

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.

, ,

No hay Comentarios

Cómo intercambiar las llaves entre servicios SSH

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.

 

 

No hay Comentarios

Cómo enviar correos desde la línea de comandos en Perl – II

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.

, , , ,

No hay Comentarios

Cómo enviar correos desde la línea de comandos en Perl – I

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.

, , , ,

No hay Comentarios