Netflow, controlando el tráfico de red (IV)


Siguiendo un poco con el tema de obtener datos de desde un router cisco, del que explicamos en el post anterior cómo realizar la configuración, podemos habar también de las diferentes formas que tiene estos router's de agregación de los datos.


Tipos de agregación:
cisco(config)> ip flow-aggregation cache ?
  as                       AS aggregation
  as-tos                   AS-TOS aggregation
  bgp-nexthop-tos          BGP nexthop TOS aggregation
  destination-prefix       Destination Prefix aggregation
  destination-prefix-tos   Destination Prefix TOS aggregation
  prefix                   Prefix aggregation
  prefix-port              Prefix-port aggregation
  prefix-tos               Prefix-TOS aggregation
  protocol-port            Protocol and port aggregation
  protocol-port-tos        Protocol, port and TOS aggregation
  source-prefix            Source Prefix aggregation
  source-prefix-tos        Source Prefix TOS aggregation
Por lo tanto, para hacer uso de las mismas, únicamente hay que indicar qué tipo de agregación se desea, activarla y los datos se enviarán de dicha forma con el tiempo marcado.
Un ejemplo de agregación simple, sería,
cisco(config)> ip flow-aggregation cache as
cisco(config-flow-cache)> cache entries 2046
cisco(config-flow-cache)> cache timeout inactive 200
cisco(config-flow-cache)> cache timeout active 45
cisco(config-flow-cache)> export destination 192.168.0.35 9995
cisco(config-flow-cache)> enabled

En otro ejemplo, tenemos la agregación en función del protocolo que se esté empleando en los paquetes de red. Los datos de netflow así serán enviados cada 45 segundos al servidor agrupados por el protocolo de red.
cisco(config)> ip flow-aggregation cache protocol-port
cisco(config-flow-cache)> cache entries 2046
cisco(config-flow-cache)> cache timeout inactive 200
cisco(config-flow-cache)> cache timeout active 45
cisco(config-flow-cache)> export destination 192.168.0.35 9995
cisco(config-flow-cache)> enabled
En el próximo post sobre netflow ya tocará ver cómo montar bajo GNU/Linux un pequeño servicio que recoja los datos generados por los equipos para poder posteriormente procesarlos y obtener estadísticas de red de interés.

Temas:
Leer más

MySQL report to syslog


Desde la versión 5.1.20 de MySQL, éste es capaz de reportar todos sus log de forma automática a syslog, el sistema de logging de GNU/Linux. Para habilitar esta facility, simplemente hay que añadir una nueva línea al fichero de configuración (/etc/my.cfg), en la sección mysqld_safe. Tras esto, todos los eventos que reporte el motor de base de datos irán directamente a syslog y será allí donde los haya que tratar.


[mysqld_safe]
syslog
Otra forma de hacerlo, es indicárselo en línea de comandos, con las siguientes opciones, tal como se indica en la página de referencia de la sección mysqld-safe.
  • --syslog
    Envía los mensajes de MySQL a syslog en vez de usar el fichero propio de servidor.
  • --syslog-tag=tag
    Añade un "tag" o etiqueta especial a los mensajes enviados a syslog, para poder así diferenciarlos y tratarlos mejor.
    Por ejemplo, añadiendo el tag MySQL, sería más simple luego buscar eventos en los ficheros syslog.





Leer más

Netflow, controlando el tráfico de red (III)

En este nuevo post, vamos a ver cómo realizar lo mismo que en el anterior, pero esta vez con un router cisco, que nos permitirá muchas más opciones y métodos para el tratamiento de datos netflow.
Como siempre... nos conectamos al equipo en cuestión por la conexión que esté habilitada, recomendable ssh, y entramos en modo configuración.
Realizamos los siguientes pasos:
  1. Zona horaria
    Para manejar los datos de netflow, el router debe estar en hora para así tener unos datos fiables. Para conseguirlo, en este caso aprovecharemos las facilidades de NTP.
    cisco> configure terminal
    Enter configuration commands, one per line. End with CNTL/Z.
    cisco(config)> ntp update-calendar
    cisco(config)> set ntp client enable
    cisco(config)> ntp server 10.10.100.1
    
  2. Hora del sistema
    Ahora comprobamos que la hora del sistema es válida, para ello,
    cisco> show ntp status
    cisco> show clock
    
  3. Configurar netflow
    Entramos nuevamente en modo configuración del router y observamos los parámetros que tiene para el tipo "ip flow-?". Todos estos parámetros nos permiten realizar una configuración muy óptima y ajustada de netflow y de cómo queremos que trabaje.
    cisco> config
    Configuring from terminal, memory, or network [terminal]? 
    Enter configuration commands, one per line.  End with CNTL/Z.
    cisco(config)> ip flow-?
    flow-aggregation  flow-cache        flow-capture
    flow-export       flow-top-talkers  flow-egress
    
     Configuramos por lo tanto el router para que exporte vía UDP todos los paquetes a nuestro servidor cliente netflow, que se encargará de recolectarlos para posteriormente poder procesarlos. Para ello,
    cisco(config)> ip flow-export destination 192.168.1.35 9995 udp
    cisco(config)> ip flow-export version 9
    cisco(config)> ip flow-cache entries 65536
    
  4. Comprobar configuración
    cisco> show ip cache flow
    cisco> show ip flow export
    
     Y del lado del cliente, observamos que sí hay tráfico UDP en el puerto indicado.
    shell> tcpdump -i eth0 port 9995
    19:38:36.565951 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
    19:38:36.565964 IP 10.0.0.5.9995 > colector.9995: UDP, length 224
    19:38:36.678899 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
    19:38:36.947127 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
    19:38:37.080699 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
    19:38:37.152456 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
    


Temas:
Leer más

apt-get cheat sheet

Si en un post anterior hemos dejado una pequeña chuleta de las utilidades básicas y algo más avanzadas que se pueden hacer con rpm, Debian no iba a ser menos, así que os dejo aquí una pequeña chuleta con las opciones más habituales que se suelen usar con apt-get.





  • Instalar un nuevo paquete
    shell> apt-get install package
    
  • Desinstalar un paquete
    shell> apt-get remove package
    
  • Desinstalar un paquete y purgar todos sus ficheros
    shell> apt-get remove --purge package
    
  • Actualizar listado de paquetes disponibles
    shell> apt-get update
    
  • Actualizar sistema
    shell> apt-get upgrade
    
  • Actualizar un único paquete (más dependencias)
    shell> apt-get upgrade package
    
  • Actualizar versión de distribución, o actualización con cambios en paquetes
    shell> apt-get dist-upgrade
    
  • Limpiar paquetes que ya no se usan
    shell> apt-get autoremove
    
  • Limpiar paquetes que ya no se usan y purgar ficheros
    shell> apt-get autoremove --purge
    
  • Descargar las sources de un paquete
    shell> apt-get source package
    
  • Limpiar repositorio local (libera espacio en disco)
    shell> apt-get clean
    
  • Descarga únicamente el paquete, pero lo no instala
    shell> apt-get install --download-only package
    
  • Asume como "yes" a todas las preguntas que se hagan en la instalación
    shell> apt-get install --yes package
    
  • Instala un paquete sin actualizar paquetes ya instalados
    shell> apt-get install --no-upgrade package
  • Forzar la instalación de un paquete o su reconfiguración
    shell> apt-get install -f
    
  • Forzar la configuración de una actualización
    shell> apt-get upgrade -f
    
  • Instalar dependencias de compilación de un paquete
    shell> apt-get build-dep package
    
  • Reinstalar un paquete previamente instalado
    shell> apt-get install --reinstall package
    
  • Simular la ejecución sin afectar al sistema
    shell> apt-get -s install package
    shell> apt-get -s upgrade
    
Leer más

iwatch, monitorizando filesystem local

Aunque existen herramientas para monitorización en red mucho mejores, como es el caso de zabbix, del que ya hemos hablado en este blog varias veces, y que también permite controlar en tiempo real los cambios en ficheros o carpetas alertando de ello, en este caso vamos a ver una pequeña utilidad para equipos aislados. Si trabajamos o controlamos una red muy amplia es buena idea centralizar la monitorización, sin embargo si lo único que nos interesa es tener controlado un equipo, iwatch, es el software que necesitamos.
iwatch es un monitor que está chequeando y avisa, en tiempo real, de cambios en ficheros o directorios. Permite controlar cambios en los atributos, cambios en el contenido, apertura, movimiento, creación de ficheros, etc. Con todo esto envía un correo a la cuenta configurada, que puede ser distinta por recurso y también puede restaurar el contenido original. A bajo nivel, iwatch es un pequeño script escrito en perl que monitoriza los ficheros indicados y actúa según lo establecido.
Para usarlo, primero lo instalamos.
shell> apt-get install iwatch
Una vez instalado, tenemos que indicarle que se ejecute. Hay dos formas de ejecución. En modo daemon o en modo comando, que no devuelve la shell. Nos interesa dejarlo como daemon, por lo tanto, permitimos que arranque como tal.
shell> vi /etc/default/iwatch
## iwatch configuration file

# START_DAEMON:
#   should iwatch start the iwatch daemon during boot?
START_DAEMON=true

# CONFIG_FILE:
#   configuration file for iwatch daemon
#
CONFIG_FILE=/etc/iwatch/iwatch.xml
Ahora sólo queda indicar lo que deseemos monitorizar y qué hacer cuando se detecte algún cambio. El fichero a editar es /etc/iwatch/iwatch.xml. Un pequeño fichero xml muy sencillo de entender y editar. Se especifica el recurso, el mail destino de las alertas y las carpetas o ficheros a controlar.
shell> vi /etc/iwatch/iwatch.xml 
<config>
  <guard email="root@localhost" name="IWatch"/>
  <watchlist>
    <title>Operating System</title>
    <contactpoint email="root@localhost" name="Administrator"/>
    <path type="single" syslog="on">/bin</path>
    <path type="single" syslog="on">/sbin</path>
    <path type="single">/etc</path>
    <path type="recursive">/lib</path>
    <path type="exception">/lib/modules</path>
  </watchlist>
</config>
Sólo queda arrancarlo y cuando se detecte algún cambio, enviará un mail con la advertencia, según la configuración.
shell> /etc/init.d/iwatch start
Un ejemplo de email de alerta recibido se muestra a continuación,
subject: [iWatch] desktop_1: /etc/resolv.conf is changed
[14/Mar/2012 15:12:39]
IN_CLOSE_WRITE /etc/resolv.conf
* /etc/resolv.conf is closed
Leer más

Control de seguridad en crontab

Este pequeño truco realmente puede ser muy útil para sistemas compartidos en el que es necesario dejar como usuario una tarea en cron. Por defecto, dicha tarea si requiere de una contraseña, en crontab se la hay que especificar para que al lanzarse el comando, éste se pueda ejecutar.
Esto por defecto ya llevan un riesgo de seguridad, ya que si alguien lee el fichero, podrá observar la contraseña especificada, escrita en texto plano, tal como se muestra a continuación.
shell> cat /etc/crontab
# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
15 0 * * sun root mysql -u root -pYOUR_SECRET_PASSWD -e "CALL ..."
Esto ya de por sí, es un riesgo importante, y la forma de solucionarlo es realmente muy sencilla y se debería de incluir como código de buenas prácticas. Una forma muy sencilla sería esta,
shell> cat /etc/crontab
# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
15 0 * * sun root mysql -u root -p`cat $HOME/.my.pass` -e "CALL ..."
En la que la contraseña está escrita en un fichero oculto en la home del usuario que ejecuta el comando y que por defecto sólo tendrá acceso de lectura para él. Es una forma muy simple de proteger la contraseña, pero efectiva para el caso que se propone. Para descubrirla habría que hacer cuando menos una escalada de privilegios en el sistema, lo cual es más complicado que simplemente listar /etc/crontab.

A mayores de esto, algunas aplicaciones UNIX todavía no tiene compilado setproctitle como sistema de llamadas, por lo que si realizamos un ps axu, se podrá ver la línea ejecutada con la contraseña en texto plano. Es muy importante para evitar esto, que las aplicaciones sean compiladas con setproctitle. Actualmente en las principales distribuciones de GNU/Linux cron sí está compilado así, por lo que la contraseña se muestras como XXXXXX.
shell> ps aux
root     80 0.0 0.0 752 20 pts/1 S  13:21 0:00 sh
root     81 0.0 0.0 824 84 pts/1 S+ 13:21 0:00 bash
root     85 0.0 0.0 824 44 pts/1 S+ 13:21 0:00 mysql -u root -pXXXXXX -e...
javier  394 0.0 0.0 820 28 pts/2 Ss 13:54 0:00 bash
javier  402 0.0 0.0 088 80 pts/2 R+ 13:54 0:00 ps aux
...
Leer más

Howto install puppet on CentOS


CentOS por defecto no tiene en sus repositorios una versión de puppet. ¡Increíble pero cierto! Por lo tanto, para poder usar puppet en CentOS o Red Hat, tendremos que instalarlo nosotros mismos desde cero.
En este post vamos a describir cómo poder hacerlo de forma sencilla y con paquetes ya compilados, en este caso por Puppet Labs. Los creadores de puppet ofrecen un repositorio con la última versión de puppet disponible para CentOS. Para agregar dicho repositorio, únicamente habrá que crear un nuevo fichero de tipo repositorio bajo /etc/yum.repos.d/ con la siguiente información.

shell> vi /etc/yum.repos.d/puppet.repo
[puppetlabs]
  name=Puppet Labs Packages
  baseurl=http://yum.puppetlabs.com/el/6/products/x86_64/
  enabled=1
  gpgcheck=0

[puppetlabs2]
  name=Puppet Labs Packages Deps
  baseurl=http://yum.puppetlabs.com/el/6/dependencies/x86_64/
  enabled=1
  gpgcheck=0
Tras ésto, ya están disponibles para la instalación los paquetes puppet de cliente y servidor. Sólo hay que proceder a su instalación con yum. En el servidor sería así,
shell> yum install puppet-server
Para el cliente,
shell> yum install puppet
A partir de aquí, el resto del funcionamiento será el típico de puppet, tanto para el servidor como el cliente.

Si este artículo te ha interesado, quizás te puedan interesar también:
Leer más

Averiguando fallos en Joomla!

Recientemente descubrí un programa escrito en perl, llamado joomlascan, y que sirve precisamente para lo que os estáis imaginando, escanear páginas web que usen este famoso CMS en busca de vulnerabilidades que faciliten su posterior explotación.
El modo de realizar el escaneo no es demasiado complejo, intenta buscar la versión del núcleo y una vez la tenga, mira el listado de vulnerabilidades conocidas que hay. Luego también presenta la opción de detección de componentes de terceros y de posibles vulnerabilidades que afecten a estos.
Como ya mencioné, es un script en perl, que se puede descargar desde aquí.
shell> joomlascan.pl

    o               |                          
    .,---.,---.,-.-.|    ,---.   ,---.,---.,---.,---.
    ||   ||   || | ||    ,---|---`---.|    ,---||   |
    |`---'`---'` ' '`---'`---^   `---'`---'`---^`   '
`---'

Usage:  joomlascan.pl -u  [options]

  == Options ==
     -p            = proxy:port
     -a            = Admin folder (default '/administration')
     -v            = Check version
     -c            = Check components
     -f            = Check firewall
     -co           = Check bugs in core (require -v)
     -cm           = Check bugs in components (require -c)
     -all          = Check all (default)
     -ot           = Output to text file
     -oh           = Output to html file
     -update       = Search for updates
     -force-update = Force to download updates
     -about        = About joomlascan
     -version      = Print version info
     -h, -help     = This help

  == Examples ==
     To scan running joomla version and components:
       $ joomlascan.pl -u www.host.com -v -c

     To scan version and core bugs:
       $ joomlascan.pl -u www.host.com -v -co
Y a continuación un ejemplo del script en funcionamiento.
shell> joomlascan.pl -u www.host.com -v -c
                                                     
    o               |                                
    .,---.,---.,-.-.|    ,---.   ,---.,---.,---.,---.
    ||   ||   || | ||    ,---|---`---.|    ,---||   |
    |`---'`---'` ' '`---'`---^   `---'`---'`---^`   '
`---'                                                

Running on Apache/2.2.14 (Ubuntu)

Components:
   com_content

Joomla! version [1.5.15.Stable]
Así hemos descubierto la versión de Joomla que se está ejecutando en una web conocida ;-). Si ahora nos interesa ver los fallos de seguridad que hay en el core, lo ejecutamos con la opción -co.
shell> joomlascan.pl -u www.host.com -v -co
                                                     
    o               |                                
    .,---.,---.,-.-.|    ,---.   ,---.,---.,---.,---.
    ||   ||   || | ||    ,---|---`---.|    ,---||   |
    |`---'`---'` ' '`---'`---^   `---'`---'`---^`   '
`---'                                                

Running on Apache/2.2.14 (Ubuntu)

Joomla! version [1.5.15.Stable]

Possible vulnerabilities in core:
================================
Possible vulnerability: Administration Pages Multiple HTML Injection Vulnerabilities
Versions affected: Joomla! [1.5.0-1.5.19]
Detail: Joomla! is prone to multiple HTML-injection vulnerabilities because the application fails to sufficiently sanitize user-supplied data.Successful exploits will allow attacker-supplied HTML and script code to run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user. Other attacks are also possible.
More info: http://www.securityfocus.com/bid/41822

Possible vulnerability: HTML Injection and SQL Injection Vulnerabilities
Versions affected: Joomla! [1.5.0-1.5.18]
Detail: Joomla! is prone to multiple HTML-injection vulnerabilities and an SQL-injection vulnerability because the application fails to sufficiently sanitize user-supplied input.A successful exploit can allow an attacker to steal cookie-based authentication credentials, compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
More info: http://www.securityfocus.com/bid/41743

Possible vulnerability: Multiple Modules 'search' Parameter Cross-Site Scripting Vulnerabilities
Versions affected: Joomla! [1.5.0-1.5.17]
Detail: Joomla! is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may help the attacker steal cookie-based authentication credentials and launch other attacks.
More info: http://www.securityfocus.com/bid/40444

Possible vulnerability: Session Fixation Vulnerability
Versions affected: Joomla! [1.5.0-1.5.15]
Detail: Joomla! is prone to a session-fixation vulnerability.Attackers can exploit this issue to hijack a user's session and gain unauthorized access to the affected application.
More info: http://www.securityfocus.com/bid/39708

Possible vulnerability: Persistant XSS Vulnerability
Versions affected: Joomla! 1.5.15
Detail: Persistant XSS Vulnerability
More info: http://inj3ct0r.com/exploits/11088
Y si queremos observar los posibles bug's que hay en los módulos que tenga instalados, simplemente la opción -cm, aunque para estos componentes no se contempla la versión del mismo instalada, sino únicamente el módulo, por lo que podemos encontrarnos con algún falso positivo.
shell> joomlascan.pl -u www.host.com -c -cm

    o               |                                
    .,---.,---.,-.-.|    ,---.   ,---.,---.,---.,---.
    ||   ||   || | ||    ,---|---`---.|    ,---||   |
    |`---'`---'` ' '`---'`---^   `---'`---'`---^`   '
`---'                                                
 
Searching for components 
 
Running on Apache/2.2.14 (Ubuntu)

Components:
 com_content

Possible vulnerabilities in components:
======================================
Possible vulnerability: TinyBrowser Joomla! Component 'folders.php' Local File Include Vulnerability
Versions affected: Lunarvis TinyBrowser 1.41.6
Detail: The TinyBrowser component for Joomla! is prone to a local file-include vulnerability because it fails to properly sanitize user-supplied input.An attacker can exploit this vulnerability to obtain potentially sensitive information and execute arbitrary local scripts in the context of the webserver process. This may allow the attacker to compromise the application and the computer; other attacks are also possible.
More info: http://www.securityfocus.com/bid/335843

Possible vulnerability: XStandard Component Directory Traversal Vulnerability
Versions affected: Joomla XStandard
Detail: The XStandard component for Joomla! is prone to a directory-traversal vulnerability because it fails to sufficiently sanitize user-supplied input data.Exploiting the issue may allow an attacker to obtain sensitive information that could aid in further attacks.
More info: http://www.securityfocus.com/bid/33143

Possible vulnerability: Component com_content File Upload Vulnerability
Versions affected: com_content
Detail: Joomla Component com_content File Upload Vulnerability
More info: http://inj3ct0r.com/exploits/14165
Lo que luego se puede hacer con cada una de las posibles vulnerabilidades ya es cosa de cada atacante, pero como aplicación de auditoría interna esta herramienta puede resultar muy útil. Como siempre, la forma de estar protegido, tener el sistema lo más actualizado posible.

Más información: blog.pepelux.org.
Leer más

RPM cheat sheet

Encontrar un cheat sheet de rpm por la red es bastante simple, pero normalmente cuando necesito acordarme de una opción concreta me aparecen todas menos la que busco. Para solucionarlo, dejo aquí las que voy usando más habitualmente, así cuando las necesite las encontraré y de paso servirá de ayuda, quizás, a alguien más.

  • Instalar un paquete
    shell> rpm -i package.rpm
    shell> rpm -ivh package.rpm
    
  • Desinstalar un paquete
    shell> rpm -e package
    
  • Actualizar un paquete
    shell> rpm -Uvh package_2.rpm
    
  • Listado de paquetes
    shell> rpm -qa
    
  • Versión de un paquete instalado
    shell> rpm -q package
    
  • Mostrar información de un paquete
    shell> rpm -qi package
    
  • Listado de los ficheros de un paquete
    shell> rpm -ql package
    
  • ¿A qué paquete pertenece este fichero?
    shell> rpm -qf /usr/bin/file
    
  • Verificar un paquete instalado
    shell> rpm --verify package
    
  • Comprobar firma de paquete
    shell> rpm --checksig package
    
  • Testear los cambios que un paquete haría
    shell> rpm -Uvh --test package_2.rpm
    
  • Ficheros de configuración de un paquete
    shell> rpm -qc package
    
  • Servicios que provee un paquete
    shell> rpm -q --provides package
    
  • Mostrar los últimos paquetes instalados
    shell> rpm -qa --last
Leer más

Replicar punto de montaje: bind mount

En algunas ocasiones puede resultar, cuando menos útil, poder tener accesible desde dos paths diferentes un subconjunto de un árbol de directorios. Esto lo podemos lograr mediante lo que se conoce como bind mount.
Desde el comando mount con la opción -o bind podemos realizar este tipo de montaje especial. Por ejemplo, si queremos tener la misma información que está en una partición localizada bajo /var/www y /usr/local/www, se podría hacer así.
shell> mount -o bind /usr/local/www /var/www
Con lo que, una vez montados se podría ver lo mismo en ambos lugares.
# ls /var/www/
extra  site.com index.html
# ls /usr/local/www/
extra  site.com index.html
Para hacerlo automáticamente cuando el sistema se arranque, habrá que incluirlo en /etc/fstab con la siguiente sintaxis.
/var/www   /usr/local/www   none   bind   0   0
Replicando lo que haya en /vaw/www en /usr/local/www.
Leer más

php, ocultar versión


Cuando se consulta un determinado servidor web que ejecuta php, éste envía la versión del servidor así como la versión de php que está ejecutando. Dicha información puede dar a un posible atacante mucha información sobre si el equipo es o no es vulnerable. Aunque la seguridad por ocultación no es buena, sí puede ofrecer un poco de protección, o cuando menos evita dejar "los datos al aire".
Por defecto, ésta es la información que se puede obtener de un servidor al realizarle una consulta.

shell> curl -I http://www.site.com
HTTP/1.1 200 OK
Date: Wed, 14 Mar 2012 15:24:19 GMT
Server: Apache/2.2.16
X-Powered-By: PHP/5.3.3-7+squeeze7
Set-Cookie: SESS62cf6d13abf72b42af7...
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Wed, 14 Mar 2012 19:24:19 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Para evitar que enseñe la versión de php que está a ejecutar (5.3.3-7) sólo hay que cambiar la variable expose_php de on, valor que tiene por defecto a off y recargar apache.
shell> vi /etc/php5/apache2/php.ini
...
expose_php = Off
...
shell> /etc/init.d/apache2 restart
Después de éste pequeño cambio, como se puede observar ya no hay información sobre la versión de php del servidor.
shell> curl -I http://www.site.com
HTTP/1.1 200 OK
Date: Wed, 14 Mar 2012 15:26:41 GMT
Server: Apache/2.2.16
Set-Cookie: SESS62cf6d13abf72b42af7...
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Wed, 14 Mar 2012 19:26:41 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Leer más

Acelerando las consultas DNS

El método de funcionamiento de la red en equipos Linux, al igual que en Windows, es que cada vez que tú pides un nombre, éste se consulta al DNS primario para obtener una IP y luego establecer la conexión. Si sueles navegar por las mismas páginas, cada vez que las vuelves a cargar, hay que realizar una nueva conexión al DNS para obtener un dato que ya lo teníamos hace nada. Para evitar esto, vamos a explicar cómo hacer uso de una caché DNS que acelere dichas consultas, dejándolas en local la mayor parte de las veces.
Para ello, primero instalaremos el software necesario, dnsmasq.
shell> apt-get install dnsmasq
A continuación configuramos de forma muy simple de demonio para que permita almacenar en caché los valores. Para ello editamos el fichero /etc/dnsmasq.conf y agregamos al final las siguientes líneas,
expand-hosts
domain=tudominio.com
cache-size=150
bogus-priv
A continuación, agregamos como DNS primario de nuestro equipo que la IP local, para que todas las consultas se resuelvan localmente. Para ello, editamos el fichero /etc/resolv.conf y agregamos al principio de todo,
nameserver 127.0.0.1
Ahora todas las consultas pasarán por el DNS primario de nuestro equipo y será dnsmasq el encargado de realizar las peticiones. La idea es que la primera vez ésta se lancen a donde corresponda, pero las siguiente ya no, por lo que se acelerarán dichas consultas. Lo vamos a comprobar.
shell> dig www.marca.com 
...
;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:07 2012
;; MSG SIZE  rcvd: 275
Como se puede observar el servidor de consulta es localhost y al realizar la petición, como era la primera vez, tardó 9 msec. Ahora lo volvemos a intentar y vemos lo que pasa.
shell> dig www.marca.com
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:14 2012
;; MSG SIZE  rcvd: 47
El servidor de consulta sigue siendo localhost, pero el tiempo de respuesta ahora es de 0 msec. Como el dominio está en caché, será únicamente la primera vez cuando tarde en realizar la consulta, a partir de ese momento el tiempo de respuesta será cero.
Leer más

Llenado del 'buffer pool' en InnoDB, MySQL

En un post anterior se habló ya de las ventajas de tener pre-cacheados los datos de determinadas consultas en servidores MySQL que no se estén usando (SLAVE's), para que en el momento que entren en funcionamiento, tengan un buen rendimiento.
La posibilidad de hacer esto, estaba disponible en percona desde hace varias versiones y en la última versión de MySQL, la 5.6 también la incorporaron para facilitar el escalado de servidores MySQL.
El funcionamiento de éste, sin embargo es diferente y para usarlo, se podría hacer tal como sigue.
  • Crear un dump del buffer_pool
    mysql> SET innodb_buffer_pool_dump_now=ON;
    
  • Crear un dump del buffer_pool cuando se cierre el servidor
    mysql> SET innodb_buffer_pool_dump_at_shutdown=ON;
    
  • Subir a memoria un dump
    mysql> SET innodb_buffer_pool_load_now=ON;
    
  • Ver el progreso de construcción de un dump
    mysql> SHOW STATUS LIKE 'innodb_buffer_pool_dump_status';
    
  • O de restauración
    mysql> SHOW STATUS LIKE 'innodb_buffer_pool_load_status';
    
  • O cancelarlo
    mysql> SET innodb_buffer_pool_load_abort=ON;
    
Si queremos habilitarlo, al igual que en percona, se puede añadir la siguiente línea al fichero de configuración (/etc/my.cfg).
innodb_buffer_pool_load_at_startup=ON
Leer más

Verificar autenticidad de un certificado

En muchos casos se necesita tener una entidad certificadora para poder crear y verificar certificados a diario. En estos casos, siempre que no sea algo importante lo que se suele hacer es crear a nivel local la CA y con ella realizar las firmas. Cómo crear una entidad certificadora válida a nivel local está ampliamente explicado en Google. El nivel de seguridad que ofrece es el mismo que si se comprasen los certificados, pero el valor de credibilidad de los mismos es mucho menor.
En caso de que hagáis esto alguna vez, os dejo una forma de comprobar que un certificado emitido es correcto para la CA. En caso afirmativo aparecerá un OK.
shell> openssl verify \
       -CAfile cacert.pem \
       -purpose any \
       example_1-cert.pem      
example-cert.pem: OK

shell> openssl> verify \
       -CAfile cacert.pem \
       -purpose any \
       example_2-cert.pem 
example_2-cert.pem: [...] error 20 at 0 depth lookup:unable to get local issuer certificate

Leer más

Mover punto de montaje en caliente

En GNU/Linux un punto de montaje es una carpeta que contiene un sistema de archivos montada en él y sobre el que luego se trabajar. Para comprobar los puntos de montajes, existe el comando mount, al igual que para montar nuevos dispositivos.
Los programas y script's se ejecutan sobre datos de un punto de montaje y mientras un fichero esté en uso, el kernel no permitirá que dicho dispositivo sea desmontado, sin embargo desde ya hace tiempo el comando mount permite mover el sistema de archivos montado en un punto a otro punto diferente en caliente, sin parar los programas que se estén ejecutando.
shell> mount
/dev/sda3 on / type ext3 (rw,errors=remount-ro)
/dev/sda1 on /boot type ext3 (rw)
/dev/sdf1 on /media/disk type vfat (rw,shortname=winnt)
shell> mount --move /media/disk /mnt/pen/
shell> mount
/dev/sda3 on / type ext3 (rw,errors=remount-ro)
/dev/sda1 on /boot type ext3 (rw)
/dev/sdf1 on /mnt/pen type vfat (rw,shortname=winnt)
Leer más

NetFlow, controlando el tráfico de red (II)

En este post vamos a ver cómo podemos configurar un swtich enterasys para que nos envíe a un colector de este tipo de datos, la información que recaba del tráfico de red. Para que esto funcione en el equipo destino tiene que haber algún tipo de software, que veremos más adelante, que sea capaz de comprender y capturar dicha información. También debe de existir comunicación entre el switch en cuestión y el equipo destino.
En nuestro caso, el equipo a configurar es un Matrix N7. Para ellos, nos conectamos como usuario administrador y realizamos los siguientes pasos:
  • Zona horaria
    Es importante que el equipo esté dentro de una zona horaria reconocida y en la misma que el recolector, para evitar que haya desfases horarios.
    Matrix(su)-> set timezone Madrid +1
    Matrix(su)-> show timezone
    Admin Config timezone: 'Madrid', ...
    Oper  Config timezone: 'Madrid', ...
    
  • Hora del sistema
    La hora del switch debe ser la correcta, para que así los eventos tengan sentido y se puedan asociar hechos a fechas concretas.
    Matrix(su)-> set time 02/21/2012 18:54:41
    Matrix(su)-> show time
    TUE FEB 21 18:54:41 2012
    
  • Configurar netflow
    Matrix(su)-> set netflow ?
     cache              Enable collection for a NetFlow cache
     export-destination Sets the destination address of NetFlow collector
     export-interval    Set the active flow timer value
     export-version     Set data export version
     port               Enable NetFlow collection on a port
     template           Set the V9 template values
    
    Matrix(su)-> set netflow cache enable
    Matrix(su)-> set netflow export-destination 192.168.0.35 9995
    Matrix(su)-> set netflow export-interval 5
    Matrix(su)-> set netflow export-version 9
    Matrix(su)-> set netflow port ge.2.1-6 enable
    
    
  • Comprobar configuración
    Matrix(su)-> show netflow config 
    
    Cache Status:                 enabled
    Destination IP:          192.168.0.35
    Destination UDP Port:            9995
    Export Version:                     9
    Export Interval:              5 (min)
    Number of Entries:             458751
    Inactive Timer:              40 (sec)
    Template Refresh-rate:   20 (packets)
    Template Timeout:            30 (min)
    
    Enabled Ports:
    -----------------
    ge.2.1-6
    
    Disabled Ports:
    -----------------
    lag.0.1-48
    ge.1.1-24
    ge.2.7-54
    
    Matrix(su)-> show netflow statistics
    
    Export Statistics:
    ------------------------------------
    Network Packets Sampled:    62386087
    Exported Packets:             303904
    Exported Records:            8686581
    Export Packets Failed:             0
    Export Records Dropped:        61779
    
  • Comprobar funcionamiento en destino
    shell> tcpdump -i eth0 port 9995
    19:38:36.565951 IP 10.0.0.1.9995 > colector.9995: UDP, length 1404
    19:38:36.565964 IP 10.0.0.1.9995 > colector.9995: UDP, length 224
    19:38:36.678899 IP 10.0.0.1.9995 > colector.9995: UDP, length 1404
    19:38:36.947127 IP 10.0.0.1.9995 > colector.9995: UDP, length 1404
    19:38:37.080699 IP 10.0.0.1.9995 > colector.9995: UDP, length 1404
    19:38:37.152456 IP 10.0.0.1.9995 > colector.9995: UDP, length 1404
    


Temas:
Leer más

No IP-spoof en servicio DNS


Este pequeño truco sólo sirve para servidores CentOS o Red Hat y no para equipos Debian, pero es interesante saberlo y tenerlo aplicado, por si alguien en la red intenta realizar un ataque de IP Spoofing.
En CentOS existe un fichero de configuración, /etc/host.conf que contiene por defecto

shell> cat host.conf
 multi on
Si queremos activar que compruebe que haya alguna spoof de IP y en caso de que detección que nos avise, lo dejamos tal que así.
shell> cat host.conf
 multi on
 nospoof on      # Comprueba IP spoofing
 spoofalert on   # Alerta vía syslog
El significado de las nuevas líneas es:
  • nospoof on
    Realiza una resolución inversa para impedir la falsificación de direcciones IP.
  • spoofalert on
    Alerta vía syslog las posibles falsificaciones.
Leer más

yum utils

yum, del que ya hablamos en otras ocasiones aquí, tiene una gran lista de utilidades y plugins que lo hacen muy versátil y funcional. A continuación, vamos a ver algunas de estas para aprovechar y sacarle más partidos a este estupendo gestor de paquetes.
Para comenzar instalamos todas las utilidades de yum, que están dentro del paquete yum-utils. Una vez tengamos el paquete listo para funcionar, ya tendremos en nuestro sistema un nuevo comando, package-cleanup, que permite realizar una buena optimización de los paquetes ya instalados, así como tener un mejor control de lo que se instalar. Por lo tanto, procedamos.
shell> yum install yum-utils
  • Lista paquetes duplicados
    Nos ofrece una lista de paquetes que pueden estar duplicados, pero en diferentes versiones. Estos paquetes generalmente están ocupando espacio y la versión más reciente es la única que se usa, por lo que poder purgarlos es importante.
    shell> package-cleanup --dupes
  • Limpia paquetes duplicados
    Si existen paquetes duplicados, esta es una muy buena forma de eliminarlos todos. Lo hace automáticamente.
    shell> package-cleanup --cleandupes 
    
  • Lista paquetes con dependencias rotas
    Nos ofrece una salida de todos aquellos programas que tienen problemas de dependencias.
    shell> package-cleanup --problems
    
  • Lista paquetes huérfanos
    Saca una salida que contiene todos aquellos paquetes que no están disponibles en ningún repositorio, es decir, aquellos que fueron instalados de forma manual.
    shell> package-cleanup --orphans
    
  • Borra kerneles antiguos
    Elimina los kerneles antiguos del sistema de forma automática.
    shell> package-cleanup --oldkernels
Leer más

LaTeX: problemas con el anexos


En documentación formal u oficial, generalmente hay una parte final del documento, llamada anexo o apéndice sobre la que se coloca una parte del documento que es importante para comprenderlo, pero no esencial en él.
Para realizar esto, LaTeX tiene ya predefinido un tipo de formalismo que permite realizarlo de forma simple y concisa. Únicamente hay que referenciarlo con appendix, cargando previamente el paquete appendix. Una vez incluido, únicamente hay que seguir escribiendo los capítulos como se haría normalmente.
\usepackage{appendix}
% Documento...
\appendix
\chapter{Anexo I: Ejemplo de hoja técnica}
% Contenido del anexo I
\chapter{Anexo II: Hoja de soluciones}
% Contenido del anexo II
Si hacemos esto, ya tendremos creada la hoja de anexos y posteriormente el resto de anexos, sin embargo, usándolo he descubierto un par de fallos, o más que fallos, un par de detalles que podrían ser corregidos al escribir en cualquier idioma diferente del inglés y que quedarían mejor. El primero, el idioma, que me interesa que aparezca Anexos y no Appendices, tal como está por defecto. El segundo, la separación en el índice de contenidos de la parte de anexos respecto del resto del documento.
Para solucionar el problema con el idioma, simplemente habrá que realizar un renewcommand y especificarle el nombre que realmente nos interese. En este caso Anexos. A continuación se da el código necesario para realizarlo.
\renewcommand{\appendixname}{Anexos}
\renewcommand{\appendixtocname}{Anexos}
\renewcommand{\appendixpagename}{Anexos}
Para comprender mejor el otro problema a solucionar mejorar, mejor lo vemos sobre una imagen del resultado. A continuación se muestra un anexo típico de LaTeX por defecto.

Como se puede observar, en el índice del documento, en ningún lugar se nos indica que esto es un Anexo, sino que hay que especificarlo en el propio capítulo. Lo que nos interesa por lo tanto, es tener una hoja introductoria a los anexos, que nos permita saber que a partir de ese punto vendrán los anexos y también que en el propio índice aparezca así reflejado, tal y como se muestra en la siguiente imagen.

Conseguir esto es muy simple y bastará con poner estas líneas después del appendix.
\appendix
\clearpage
\addappheadtotoc
\appendixpage
Leer más

CentOS/Red Hat chkconfig usage

En todos los sistemas GNU/Linux existe lo que se conoce como runlevels, que no son más que las diferentes formas que tiene de arrancar el sistema operativo y según la que se elija se pueden tener unos u otras servicios en ejecución. En sistemas Debian, la forma modificar los servicios que se arrancan y para en cada runlevel es con el comando update-rc.d y en sistemas Red Hat, el comando empleado es chkconfig.
En este post vamos a ver un poco más detallada la forma que tiene de trabajar dicho comando y cómo poder usarlo, para saber los programas que se arrancan en cada nivel y también cómo hacer que se arranque un nuevo servicio en un nivel o se para otro.
Para obtener un listado de los servicios que se arrancan, así como del estado de los mismos en función de los diferentes 7 runlevel's del sistema,
shell> chkconfig --list
atop            0:off  1:off  2:off  3:off  4:off  5:off  6:off
auditd          0:off  1:off  2:on   3:on   4:on   5:on   6:off
bacula-fd       0:off  1:off  2:off  3:off  4:off  5:off  6:off
crond           0:off  1:off  2:on   3:on   4:on   5:on   6:off
ip6tables       0:off  1:off  2:on   3:on   4:on   5:on   6:off
iptables        0:off  1:off  2:on   3:on   4:on   5:on   6:off
lvm2-monitor    0:off  1:on   2:on   3:on   4:on   5:on   6:off
netconsole      0:off  1:off  2:off  3:off  4:off  5:off  6:off
netfs           0:off  1:off  2:off  3:on   4:on   5:on   6:off
network         0:off  1:off  2:on   3:on   4:on   5:on   6:off
ntpd            0:off  1:off  2:off  3:off  4:off  5:off  6:off
ntpdate         0:off  1:off  2:off  3:off  4:off  5:off  6:off
postfix         0:off  1:off  2:on   3:on   4:on   5:on   6:off
puppet          0:off  1:off  2:off  3:off  4:off  5:off  6:off
rdisc           0:off  1:off  2:off  3:off  4:off  5:off  6:off
restorecond     0:off  1:off  2:off  3:off  4:off  5:off  6:off
rsyslog         0:off  1:off  2:on   3:on   4:on   5:on   6:off
saslauthd       0:off  1:off  2:off  3:off  4:off  5:off  6:off
sshd            0:off  1:off  2:on   3:on   4:on   5:on   6:off
sysstat         0:off  1:on   2:on   3:on   4:on   5:on   6:off
udev-post       0:off  1:on   2:on   3:on   4:on   5:on   6:off
zabbix-agent    0:off  1:off  2:off  3:off  4:off  5:off  6:off
La forma que existe de alterar estos servicios en los diferentes niveles por lo tanto, es la siguiente,
shell> chkconfig --level [0123456] service on
shell> chkconfig --level [0123456] service off
shell> chkconfig --add service
shell> chkconfig --del service
Como se puede observar existen 3 formas diferentes de hacerlo, la primera es indicando el/los level para el que se quiere arrancar o parar el servicio y la segunda es dejar que sea el propio chkconfig el que elija los niveles por defecto en los que arrancar un servicio o pararlo.
Por ejemplo, si nos interesa arrancar el servicio puppet en los level 3, 4 y 5, ejecutaremos el siguiente comando,
shell> chkconfig --level 35 puppet on
Sin embargo, si dejamos que sea el propio comando el que elija en qué niveles arrancar por defecto, nos los arrancaría en el 2, 3, 4 y 5 y el comando sería, tal que así,
shell> chkconfig --add puppet
Si ahora volvemos a ejecutar el listado, podremos observar cómo ejecutivamente el servicio puppet ha cambiado y al reiniciar el equipo, éste arrancará por defecto si entramos en alguno de esos runlevel's.
shell> chkconfig --list
atop            0:off  1:off  2:off  3:off  4:off  5:off  6:off
auditd          0:off  1:off  2:on   3:on   4:on   5:on   6:off
bacula-fd       0:off  1:off  2:off  3:off  4:off  5:off  6:off
crond           0:off  1:off  2:on   3:on   4:on   5:on   6:off
ip6tables       0:off  1:off  2:on   3:on   4:on   5:on   6:off
iptables        0:off  1:off  2:on   3:on   4:on   5:on   6:off
lvm2-monitor    0:off  1:on   2:on   3:on   4:on   5:on   6:off
netconsole      0:off  1:off  2:off  3:off  4:off  5:off  6:off
netfs           0:off  1:off  2:off  3:on   4:on   5:on   6:off
network         0:off  1:off  2:on   3:on   4:on   5:on   6:off
ntpd            0:off  1:off  2:off  3:off  4:off  5:off  6:off
ntpdate         0:off  1:off  2:off  3:off  4:off  5:off  6:off
postfix         0:off  1:off  2:on   3:on   4:on   5:on   6:off
puppet          0:off  1:off  2:off  3:on   4:off  5:on   6:off
rdisc           0:off  1:off  2:off  3:off  4:off  5:off  6:off
restorecond     0:off  1:off  2:off  3:off  4:off  5:off  6:off
rsyslog         0:off  1:off  2:on   3:on   4:on   5:on   6:off
saslauthd       0:off  1:off  2:off  3:off  4:off  5:off  6:off
sshd            0:off  1:off  2:on   3:on   4:on   5:on   6:off
sysstat         0:off  1:on   2:on   3:on   4:on   5:on   6:off
udev-post       0:off  1:on   2:on   3:on   4:on   5:on   6:off
zabbix-agent    0:off  1:off  2:off  3:off  4:off  5:off  6:off
Leer más

Netflow, controlando el tráfico de red (I)

NetFlow es un protocolo de red, escrito por Cisco y que sirve para recabar información sobre el tráfico IP que pasa por un equipo. Actualmente este protocolo es un estándar en prácticamente todos los router's modernos y gracias a ellos, podemos controlar el tráfico de cada IP que pasa por él. De la misma forma que Cisco desarrolló su estándar y el resto de fabricantes lo adaptaron a sus dispositivos, en GNU/Linux existe también una implementación de dicho protocolo, tanto para recolección y procesado de los datos, como para captura de los mismos.


NetFlow actualmente está en la versión 9, aunque la más extendida todavía sigue siendo la versión 5 del mismo, que entre otra información, nos ofrece:
  • Interfaz de entrada/salida del tráfico
  • Timestamps del flujo, con tiempos de comiendo y finalización
  • Número de paquetes y bytes del flujo
  • Toda la información de cabecera de capa 3 (IP origen, IP destino, puertos, protocolo, tipo de servicio, etc.)
  • Flags TCP (en caso de comunicación TCP)
  • Información de rutas (en capa 3)
Una vez introducido el concepto de NetFlow y visto así por encima para qué sirve, en próximos post's veremos cómo poder obtener dicha información de los equipos, bien sean router's, bien sean firewall's linux y cómo almacenarla para posteriormente procesarla.


Temas:
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios