11 dic 2010

Reporte MBSA (Microsoft Baseline Security Analyzer) con Microsoft Visio 2007

Microsoft Baseline Security Analyzer, como dije en mi entrada anterior , nos da como producto final un reporte tipo auditoria, de la seguridad de uno o varios equipos (microsoft) en nuestra red. Si bien los reportes son muy entendibles, lo son mas aun cuando podemos juntar varios de ellos y representarlos junto a su topologia de red. Para ello microsoft provee a Visio 2007 de un conector (gratuito) que permite cargar los reportes MBSA dentro de los diagramas visio, MUY MUY CHETO, ademas de una mejor interpretación logramos centralizar todos los reportes.
Como especifica en la seccion "Download Requirements", la pc que utilizaremos necesita Visio 2007 Profesional y MBSA 2.1. Con MBSA 2.2 el instalador del conector da una advertencia y sale de la instalación. Así mismo los reportes generador por MBSA 2.2 (XML) son interpretados sin problemas por MBSA 2.1 y el conector. A la hora de dibujar la topologia de red hay que tener en cuenta que a cada uno de lo servidores se les debe colocarle su IP o netbios-name para que cuando se importe el reporte sepa a cual equipo quedar atachado.
Luego de la instalación de los requisitos y desarrollo del diagrama, importamos el reporte generado previamente, archivo con extension *.mbsa:

Repetida la operación la cantidad de veces que sea necesaria, activamos el menú para que se muestre el reporte cada vez que seleccionamos un equipo en el diagrama.

De esta forma es como mi ambiente virtual de pruebas queda diagramado, documentado y listo para ser usado en otra ocasión con una nueva lista de actualizaciones (wsusscn2.cab)

Este conector también permite realizar lo anterior de forma inversa, es decir, mediante un diagrama realizar los análisis MBSA, solo especificando las IP o netbios-names de los equipos en el grafo. Personalmente no simpatizo con este método, ya que habría que proporcionarle a un servidor los requerimientos del conector o poner una lapto que si los cumpla, en la misma red de los servidores introduciendo riesgos innecesarios, mas aun cuando la infraestructura es critica.

7 dic 2010

Chequeo Offline de actualizaciones y configuraciones de seguridad con Microsoft Baseline Security Analyzer (MBSA)

Existen situaciones donde nos toca trabajar en ambientes sin conexión al exterior, por razones de seguridad. Cuando los entornos son Windows, quizás nos sintamos un poco mas inseguros que de costumbre y tengamos la necesidad de tener nuestros equipo sumamente actualizados y medir de alguna forma el estado de la seguridad de cada uno de ellos.
¿Pero como lo podemos lograr, sin tener conexión a los servidores de microsft ?
Bueno, Micrsoft provee gratuitamente (aunque usted no lo crea) de una herramienta de tipo auditoria de seguridad que nos indicara las actualizaciones, hotfix y parches faltantes. Errores comunes en configuraciones de seguridad de servicios (como IIS y MSSQL), cuentas de usuarios, passwords, etc. Suena bastante bien no?, estoy hablando de MBSA (Microsoft Baseline Security Analyzer) esta tool nos puede brindar un buen panorama en lineas generales de como estamos.
Microsoft la define de la siguiente manera:
"Microsoft Baseline Security Analyzer (MBSA) is an easy-to-use tool designed for the IT professional that helps small- and medium-sized businesses determine their security state in accordance with Microsoft security recommendations and offers specific remediation guidance. Improve your security management process by using MBSA to detect common security misconfigurations and missing security updates on your computer systems."
Aunque todo lo que brilla no es oro, si queremos que MBSA revise las actualizaciones, necesitara los servicios de Windows Update (WU) para indicarnos los security updates que faltan, en este punto la herramienta nos permite tomar tres acciones:
a) Conectar el equipo a Internet (No es mi caso, por lo que lo descarto).
b) Utilizar los servicios de WSUS de nuestra red local o Intranet.
c) Utilizar el catalogo de actualizaciones wsusscn2.cab para offline scans.

Si bien WSUS es una alternativa para manejar las actualizaciones dentro de la Intranet (solo debemos habilitar el puertos 80 en los firewalls de la DMZ) los pro y contras aun debo analizarlos. Lo que si me resulto totalmente seguro es poder realizar los analisis de MBSA de forma offline, totalmente desconectados de la Internet y Intranet.

Para hacer esto desde las FAQ's de MBSA en la pregunta:
Q: MBSA uses files that it downloads from the Internet, but the computer I want to use to scan my network doesn't have Internet access. How can I use MBSA in an offline and secure environment?
Decargamos wsusscn2.cab, muauth.cab, wuredist.cab y el Windows Update Agent (WUA) standalone instaler. Los *.cab debemos colocarlos en la carpeta "C:\Documents and Settings\\Local Settings\Application Data\Microsoft\MBSA\Cache" si estamos en Windows 2008 Server veran que este path no existe por lo que deben crear este otro: "C:\Users\Administrator\AppData\Local\Microsoft\MBSA\Cache". Como decian por ahí, este path se crear la primera vez que MBSA se conecta a Internet.
Instalamos el WUA y el MBSA 2.2 (que lo bajamos desde aqu ) luego ejecutamos el MBSA, su uso es intuitivo, por lo que no me explayare al respecto.




Lo único a tener en cuenta en el chequeo de los security updates es que se debe seleccionar "Scan using offline catalog only"


Esta es la salida después de aplicar MBSA a una de mis maquinas virtuales de testing.

29 nov 2010

Herramientas de Firma Digital (PKI) para Linux !!!

En la provincia de San Luis, Argentina, se ha desarrollado una infraestructura de clave publica (PKI) que empieza a cubrir distintos aspectos en la administración publica provincial. La misma adopta la ley Nacional N° 25.506 de Firma digital.

Como es habitual voy a usar mi desktop linux para interactuar con todo ello. A la hora de utilizar firma digital debemos instalar toda la cadena de certificados desde la autoridad de aplicación hasta la política que vamos a utilizar, en este paso nos podemos topar con algunos inconvenientes, como que los certificados son X.509 v3 codificados en DER (.cer) y aplicaciones como firefox, como una gran variedad de otras, utilizan codificación Base64  (.pem).
Para solucionar esto  podemos utilizar openssl, como lo indica es sus FAQs The Most Common OpenSSL Commands:


Convert a DER file (.crt .cer .der) to PEM

openssl x509 -inform der -in certificate.cer -out certificate.pem


Luego importamos este nuevo certificado en firefox desde Menu Edicion -> Preferencias -> Tab Avanzado -> Cifrado ->Ver Certificados -> Tab Autoriadades -> Importar.


Una forma fácil de hacer el paso anterior, es bajarse el plugin (complemento) de firefox KeyManager, nos permite entre otras cosas: generar certificados autofirmados, administrar dispositivos, firmar, administrar lista CRL, acceso directo desde el navegador a la lista de certificados.


Otra situación que se puede llegar a presentar es que queramos firmar nuestro correo con cuentas de mails que no sean de la organización, como por ejemplo gmail. Para ello firefox posee un plugin (complemeto) llamado Gmail S/MIME que nos permitirá firmar y encriptar datos con nuestra clave privada. Al hacer esto, la persona que reciba el correo sera advertida de que la firma es valida pero que no concuerda con la cuenta de correo que asociada a el certificado, algo que es obvio si el certificado tiene como uso firma de correos.

18 oct 2010

SQUID Cache Manager + Lighttpd + FreeBSD

Debido a algunos errores de descriptores que aparecieron en el cache.log de SQUID, decidí no solo buscar el porque del error, sino también una manera de ver en tiempo real el funcionamiento de la cache. Ahí fue que recordé que había hablado en un post anterior del CacheMgr de Squid.

Por lo que me puse a configurarlo, pero usando Lihttpd en vez de Apache. Aquí van los pasos que realice:

Enable CacheManager Instalar Lighttpd – Configurar CGI – Activar Squid CacheMgr

1.1 Install lighttpd
1.1.1 cd /usr/ports/www/lighttpd
1.1.2 make install – not clean necesitaremos scripts desde los sources
1.2 Config lighttpd.conf
1.2.1 server.document-root = "/usr/local/www/data"
1.2.2 Create document-root dir
1.2.2.1 mkdir -p /usr/local/www/data
1.2.2.2 chown -R www:www /usr/local/www/data – Change owner
1.2.3 server.port = 8180
1.3 Create files that no exist
1.3.1 Create file server.errorlog = "/var/log/lighttpd.error.log"
1.3.1.1 touch /var/log/lighttpd.error.log
1.3.1.2 chown www:www /var/log/lighttpd.error.log
1.3.2 Create file accesslog.filename = "/var/log/lighttpd.access.log"
1.3.2.1 touch /var/log/lighttpd.access.log
1.3.2.2 chown www:www /var/log/lighttpd.access.log
1.4 Config lighttpd.conf for CGI support
1.4.1 Enabled lighttpd modules
1.4.1.1 server.modules = ( "mod_alias", "mod_access","mod_cgi","mod_accesslog" )
1.4.2 Add .cgi extension to exclude static content
1.4.2.1 static-file.exclude-extensions = ( ".php", ".pl", ".fcgi", ".cgi" )
1.4.3 Add alias to a cgi-bin dir
1.4.3.1 alias.url += ( "/cgi-bin" => "/usr/local/www/data/cgi-bin" )
$HTTP["url"] =~ "^/cgi-bin" { cgi.assign = ( "" => "" )
dir-listing.activate = "enable" }
1.4.4 Test file sintax
1.4.4.1 lighttpd -t -f /usr/local/etc/lighttpd.conf
1.5 Create boot script
1.5.1 Copy and Set vars for lighttpd.conf
1.5.1.1 cp /usr/ports/www/lighttpd/files/lighttpd.sh.in /etc/rc.d/lighttpd
1.5.1.2 chmod ug+x /etc/rc.d/lighttpd
1.5.1.3 Set : ${lighttpd_enable="YES"}
1.5.1.4 Set: : ${lighttpd_conf="/usr/local/etc/lighttpd.conf"}
1.5.1.5 Set : command=/usr/local/sbin/lighttpd
1.5.2 Enabled lighttpd in boot time
1.5.2.1 vi /etc/rc.conf add lighttpd_enable="YES"
1.6 Conf SQUID for Cachemgr.cgi
1.6.1 Check SQUID options
1.6.1.1 acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl webserver src 192.168.1.0/255.255.255.0
http_access allow manager localhost
http_access allow manager webserver
cache_mgr smith@localdomain (user for login into cachemgr)
cachemgr_passwd tu_password all (pass for login into cachemgr)
1.7 Conf /usr/local/etc/squid/cachemgr.conf
The access configuration file defining which Squid servers may be
managed via this cachemgr.cgi program.

1.7.1 Add squid.conf http_port into cachemgr.conf
1.8 Restart squid and lighttpd
1.8.1 /etc/rc.d/lighttpd restart; /etc/rc.d/squid restart

Luego se debería acceder desde el browser a la dirección del cache http://ip-cache:port_lighttpd/cgi-bin/cachemgr.cgi


 Luego con los datos subministrados anteriormente al squid.conf deberiamos logearnos.


References:

http://www.systmbx.com/lighttpd/configure-cgi-for-perl-programs-in-lighttpd-mod-cgi
 http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ModCGI
 http://redmine.lighttpd.net/wiki/1/Docs:ModCGI
 http://wiki.squid-cache.org/SquidFaq/CacheManager#How_do_you_set_it_up.3F
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-starting-services.html
 http://www.linuxparatodos.net/portal/staticpages/index.php?page=19-5-como-squid-cachemgr
 http://www.autosprint.es/opensuse/sec.squid.cachemgr.html

14 oct 2010

SQUID +FreeBSD+Interception Caching

En mi entrada anterior hable de SQUID y los Tips a tener en cuenta para su configuración, hoy dejo los pasos que he realizado para la instalación del mismo sobre FreeBSD.

Interception Caching Configurar SQUID como Interception Caching o Proxy Transparente
   1.1 Instalar SQUID (make install)
     1.1.1 cd /usr/ports/www/squid
     1.1.2 make install – not clean, necesitaremos algunos scripts de los sources
   1.2 Config as Interception Cache
     1.2.1 Set – http_port IP:3128 transparente – in squid.conf
   1.3 Running SQUID
     1.3.1 Check acl access for localnet in squid.conf, for testing
       1.3.1.1 acl localnet 192.168.X.X/24
       1.3.1.2 http_access allow localnet
     1.3.2 /usr/local/sbin/squid -k parse – check syntax of squid.conf
     1.3.3 /usr/local/sbin/squid -Ncd1 – test squid, look output
     1.3.4 /usr/local/sbin/squid – running SQUID
     1.3.5 cp /usr/ports/www/squid/file/squid.in /etc/rc.d/squid - script for boot time
       1.3.5.1 Get execution permissions - chmod ug+x /etc/rc.d/squid
       1.3.5.2 Set var in /etc/rc.d/squid, Replace %%PREFIX%% for /usr/local
       1.3.5.3 Set var in /etc/rc.d/squid, Replace %%SQUID_UID%% for squid
     1.3.6 vi /etc/rc.conf add squid_enabled=”YES”
     1.3.7 /etc/rc.d/squid restart

Lo único que queda, es configurar el navegador a la dirección ip y puerto del proxy. Navegar, obvio que debemos estar en el rango ip de localnet, y verificar el funcionamiento del proxy en access.log y cache.log

#> tail -f /var/squid/logs/cache.log

Starting Squid Cache version 2.7.STABLE9 for i386-portbld-freebsd8.0...
Process ID 94872
With 11095 file descriptors available
Using kqueue for the IO loop
Performing DNS Tests...
Successful DNS name lookup tests...
DNS Socket created at 0.0.0.0, port 19005, FD 6
Adding nameserver X.X.X.X from /etc/resolv.conf
logfileOpen: opening log /var/squid/logs/access.log
Unlinkd pipe opened on FD 11
Swap maxSize 102400 + 8192 KB, estimated 8507 objects
Target number of buckets: 425
Using 8192 Store buckets
Max Mem size: 8192 KB
Max Swap size: 102400 KB
logfileOpen: opening log /var/squid/logs/store.log
Rebuilding storage in /var/squid/cache (DIRTY)
Using Least Load store dir selection
Set Current Directory to /var/squid/cache
Loaded Icons.
Accepting proxy HTTP connections at 0.0.0.0, port 3128, FD 12.
Accepting ICP messages at 0.0.0.0, port 3130, FD 13.
Accepting SNMP messages on port 3401, FD 14.
WCCP Disabled.
Ready to serve requests.

REFERENCES:

FreeBSD Starting Services
How To Install SQUID

26 sept 2010

Linux - Clock - Time - TimeZone (Parte I)

En el año 2009 en Argentina, tuvimos durante un periodo corto, hasta tres horarios distintos en todo el país, algo no habitual y problemático ya que la localización de los sistemas operativos (DST) no estaban preparados para ello. Existen circunstancia en las que determinadas aplicaciones y BD no pueden sufrir cambios inesperados en sus relojes, ya que puede ser catastrófico y hasta implicar acciones legales. En este post voy explicar, sin entrar en demasiados detalles, como linux administra sus relojes.

Linux distingue dos tipos de relojes, el de la BIOS o RTC (hwclock) y el del sistema, mantenido por el kernel de linux (sysclock) . El hardware clock es utilizado para salvaguardar el time (fecha/hora)  cuando el sistema se reinicia o apaga. Al iniciar, el sistema toma la fecha/hora desde la BIOS y la setea en el sistema (sysclock) con hwclock --systz. Cuando el sistema está siendo reiniciado o apagado, la secuencia es la inversa, sysclock setea al RTC con hwclock --systohc. Como se puede observar /sbin/hwclock es utilizado para copiar el time entre estos dos relojes. En algunas implementaciones de Linux, el hardware clock se actualiza cada 11min desde el sysclock. Pero eso no es todo, existen pequeñas desviaciones o errores de exactitud entre ambos relojes, estos porcentajes de desviación son almacenados en el archivo /etc/adjtime y corregidos por la función adjtimex(). La cual puede producir una aceleración o retraso (dependiendo si el factor delta es positivo o negativo) en la frecuencia del hardware clock, para producir la corrección (esto me hace acordar a un post de hace tiempo),  no es una corrección inmediata sino gradual que se produce con el tiempo por el cambio de frecuencia. Cuando se llama a hwclock --syshc este ajuste (/etc/adjtime) es tomado en consideración.

Bien ahora, alguien se habrá preguntado, ¿ por que cornos hay una distinción al setar el hwclock en UTC o localtime y por que suele venir por default a UTC=true?
Al principio estaba convencido que era para complicarnos la vida y tomar esa desición de dejar UTC=true ó cambiar a UTC=false, perooo no no.
La idea es simple, ahora que la entiendo, no generar variaciones bruscas al RTC al producirse los cambios de horarios entre las estaciones del año en los distintos países del mundo. Si dejamos UTC=true el hwclock tendra siempre el mismo time como si fuese el Meridiano de Greenwich y el sysclock al iniciar el sistema tomara el hwclock al cual le +/- el time zone de /etc/localtime lo que dará nuestra hora local. Sin importar la estación del año, la ahora del hardware clock es siempre la misma, evitando que se produzcan cambios que puedan afectar el clock-surce del hardware.

Glosario:
RTC = Real Time Clock ~= CMOS clock ~= Hardware Cloc
DST= Daylight Savings Time (Horario de Verano)

Referencias:
Linux, Clocks, and Time
How Linux Keeps Track of Time
Time, Date, and Time Zones for Red Hat Linux
Gentoo Linux Localization Guide


20 sept 2010

Sistema de Backup con rsync

Hoy me encuentro con la necesidad de poseer un sistema de backups ágil y dinámico para los sites que tengo hosteados. Ya había leído y escuchado de rsync, aunque nuca visto su potencial. Y debo decir que es magnifico, permite realizar backups de directorios completos manteniendo sus atributos, backups incrementales de los datos que "solo han sido modificados" (discerniendo los  archivos que han sido modificados y los suprimidos) .... EPETACULARRR !!!
Basta de vueltas aca va mi sencillo script:



#!/bin/bash
#Develepr By: Alejandro Andino =)
#set -x
export PATH=$PATH:/usr/bin:/usr/local/bin:/bin
# Directorio que se quiere backapear
from="/home/usr/"
# Donde se va a guardar el backup. Este es un site remoto mount.cifs
to="/home/usr/Storage"
# Patrones que no se copiaran desde el source
exclude=$HOME/rsync_pattern.txt
# Nombre del dir que contendra los cambios incrementales
incremental_dir=`date +%d-%m-%Y_%H%M`
# Opciones rsync
rsync_option="--force --ignore-errors --delete --delete-excluded --exclude-from=${exclude} --backup --backup-dir=${to}/${incremental_dir} -av"

/usr/bin/rsync $rsync_option $from $to

#NOTA:
#       1) Se realiza una copia completa del directorio en $to
#       2) Se crea el directorio incremental $to/$incremental (vacio la primera vez)
#               Lugar donde se almacenaran los archivos modificados y eliminados.
#       3) Si se crea un nuevo archivo/dir esta aparece por primera vez dentro del dir
#               de backup principal (main), no en el incremental.

Agregamos en /etc/rc.local el recurso remoto donde se almacena los backups de modo que cada vez que se inicie el equipo este el mismo disponible.

mount.cifs //StorageHost/DirBackup /home/usr/Storage/ -o user=usrDomain,domain=xxx,password=xxxx,rw,uid=usrOwnerFiles

Y bualá... un sistema de backup a nuestra medida, solo queda programarlo en el crontab.

11 ago 2010

SQUID como Proxy Transparente

Siguiendo con las FAQ's de SQUID, esta vez voy a cubrir las notas para transformar a squid en un proxy transparente o un Interception Cache en mi laboratorio.

1 Conceptos de Interception Caching 
  Interception Caching, es el proceso por el cual las conexiones HTTP proveniente de clientes remotos son redireccionadas a un servidor de cache, sin conocimiento o configuraciones explicitas.
Hay buenas razones por las que se puede esperar usar esta técnica:
  • No es necesario configurar a los clientes. Esta es la razón mas popular para investigar esta opción.
  • Puedes implementar mejor y mas seguras estrategias para mantener el acceso de los clientes en caso de que la infraestructura de chache quede fuera de servicio.
También hay desventajas de esta estrategia
  • La intercepción HTTP rompe el estándar TCP/IP por que el user-agents piensan que están hablando directamente con el servidor.
  • Requiere IPV4 con NAT.
  • Esto causa que el path MUT (PMTU) falle, haciendo posiblemente algunos sites inaccesibles. Esto no es usualmente un problema si las clientes clientes están conectadas via Ethernet o DSL PPPo, donde el MTU de todos los enlaces entre los clientes y la cache es 1500 o mas. 
  • EL Proxy authentication no trabaja, y la autenticación basada en IP falla conceptualmente por que los usuarios son todos vistos como provenientes desde la ip propia del proxy.
  • Interception Caches solamente soporta el protocolo HTTP, ni Gopher, SSL, ni FTP. No puedes configurar reglas de redirección al servidor proxy para otros protocolos que no sean HTTP ya que este no conocera como tratar con esto.
  • Interception Cache es incompatible con IP filtering, diseñado para prevenir la suplantación de direcciones ( address spoofing).
2 Requerimientos y métodos para el Interception Cache
  • Es necesario un buen entendiemiento de los que estas haciendo antes de comenzar. Esto involucra entendimiento de las capas TCP (TCP layers) de que esta sucediendo en las conexiones.
  • Muy probablemente necesitaras un dispositivo de red el cual pueda redireccionar el trafico a tu cache.
  • Si estas usando routers y switches Cisco en tu red puedes estar interesado en investigar el uso de WCCP.
3 Pasos involucrados en la configuración del Interception Caching
  • Construir un Squid con las opciones correctas en ./configure para soportar la redireccion y el manejo de clientes de forma correcta.
  • Rutear el trafico desde el puerto 80 al puerto de tu Squid es configurado para aceptar las conexiones.
  • Desencapsular el trafico que los dispositivos de red envían al Squid (solamente si tu estas usando GRE o WCCP para interceptar el trafico).
  • Configurar los dispositivos de red para redireccionar el trafico del puerto 80.
Los dos primeros pasos son requeridos y los dos últimos pueden no ser requeridos dependiendo de como intentas rutear el trafico HTTP a tu cache.
Es critico leer todos los comentarios en el archivo squid.conf y en este documento antes de comenzar. Lograr que el Interception Caching trabaje con Squid no es trivial y requiere de muchos subsistemas (servicios) de la red y de Squid sean configurados correctamente, sino encontraras que esto trabaja y tus usuarios no serán capaz de navegar del todo. Tú DEBES probar la configuración en un ambiente no productivo antes habilitar esta característica a los usuarios.

3.1 Compilar una version de Squid la cual acepte conexiones desde otras direcciones
  Primeramente necesitamos preparar Squid con las opciones correctas en ./configure y luego configurar squid.conf para soportar Intercepting Caching.

3.1.1 Elegir las opciones correctas para pasarle a ./configure
  Todas las versiones soportadas de Squid corrientemente disponibles soportan Interception Caching, sin embargo para que esto trabaje correctamente tu sistema operativo y red, también necesitan ser configurados. Para algunos sistemas operativos, necesitas tener configurado y construir una versión de Squid que pueda reconocer las conexiones hijacked y dicernir la direccion de destino.
  • Para Linux configurar Squid con la opción: --enable-linux-netfilter
  • Para sistemas basados en BSD configuar Squid con la opcion: --enable-ipfw-transparent.
  • Si estas usando OpenBSD's PF configurar Squid con --enable-pf-transparent
Hacer un "make clean" si previamente has configurado Squid sin estas opciones o las confguraciones pueden no presentarse.
Squid2.6+ y Squid3.0+ soportan WCCPv1 y WCCPv2 por defecto.

3.1.2 Configurar SQUID para aceptar y procesar las conexiones redirigidas del puerto 80
  Tienes que cambiar las configuraciones de Squid para reconocer las conexiones hijacked y identificar las direcciones de destino.
Un numero de métodos de intercepción y sus especificas configuraciones es detallada en ConfigExamples/Intercept.
3.2 Recibiendo el trafico sobre el verdadero puerto de Squid
  Tienes que configurar el host cache para aceptar los paquetes redirigidos (cuaqluier dirección IP en el puerto 80) y entregarlos a la aplicación cache . Esto se hace con IP filtering/forwarding.
  • Sobre Linux 2.4 y posteriores esto es llamado iptables
  • Sobre FreeBSD es llamdo ipfw.
  • Otros sistemas BSD pueden usar ip filter, ipnat o pf.
Sobre la mayoría de los sistemas, esto puede requerir reconstruir el kernel o agregar un nuevo modulo.
    3.2.1 Inteception Caching, redirección de paquetes para Solaris, SunOS, y sistemas BSD
      No es necesario usar IP Filter sobre FreeBSD, en vez de ello utilizar ipfw.


    Navegando un poquito el anterior link (ConfigExamples/Intercept) he localizado las configuraciones especificas para que FreeBSD  intercepte los paquetes para Squid 


    Interceptando trafico con IPFW en FreeBSD
      Compilar e instalar SQUID con las opción ./configure --enable-ipfw-transparent.
    Configurar Squid para saber que la IP esta siendo interceptada
    • http_port 3129 transparent
    Configuración de rc.firewall.local
    +-------------------------------------------------------------------+
    | IPFW=/sbin/ipfw |
    | ${IPFW} -f flush | 
    | ${IPFW} add 60000 permit ip from any to any | 
    | ${IPFW} add 100 fwd SQUIDIP,3128 tcp from any to any 80 recv IFACE|
    +-------------------------------------------------------------------+
    Para probar si esto funciona usar la herraminta nc (netcat). Parar squid y como root tipear nc -l 3129
    Luego inciar squid y intentar navegar en una pagina.
    Se deberia ver una salida similar a esta:
    +------------------------------------------------------+
    |#nc -l 3129
    |GET /mail/?ui=pb HTTP/1.1 |
    |User-Agent: Mozilla/5.0 (compatible; GNotify 1.0.25.0)|
    |Host: mail.google.com |
    |Connection: Keep-Alive |
    |Cache-Control: no-cache |
    +------------------------------------------------------+

    Desde aquí en adelante, configurar el browser sin proxy, y deberías ver la cache llenarse y mayor velocidad de navegación.

    Volviendo al HowTo de Proxy Transparente

    3.3 Enviando los paquetes desde los usuarios finales a tu cache server


      Hay varias maneras de hacer esto. Primero, si tu proxy ya esta en la ruta de los paquetes (la ruta entre los usuarios del proxy y internet) no tienes que preocuparte por estos pasos, Interception Caching ya debería estar trabajando. Si la cache no esta en la ruta natural de las conexiones, entonces tienes que desviar los paquetes de su ruta normal a tu host cache usando routers o switches.

    Las subsiguientes configuraciones tratan los métodos de redirección del trafico HTTP al servidor SQUID. Solo es de mi interes la configuración de los Switches Foundry, por lo que obviare los demás apartados.


    3.3.2 Redirección de paquetes con Switches Foundry L4
      Primero, configurar Squid como Interception Caching.
    Luego, configurar el Foundry L4 para redireccionar el trafico a el/los Squid/s. Por defecto Foundry redirecciona al puerto 80 del Squid box. Esto puede ser cambiado a un puerto diferente si es necesario.
    Adicionalmente el switch hace un "health check" del puerto (80) para asegurarse que el Squid esta respondiendo. Si Squid no responde, el switch por defecto envia el trafico directamente (a internet) en vez de redirigirlo a Squid. Cuando el Squid vuelve a estar activo comienza la redireccion nuevamente.
    Este ejemplo asume que tienes dos Squid cache:
    +----------------------------+

    |squid1.foo.com  192.168.1.10|
    |squid2.foo.com  192.168.1.11|
    +--------------------------------------------+
    El servidor SQUID debe estar conectado al switch. Solamente la interface donde esta conectado el router es importante. Donde se conecte el cache SQUID no es importante.
    Este ejemplo supone que el router esta conectado en la interface 17 del switch. 
    • Ingrese en modo configuación: telnet@ServerIron#conf t
    • Configure cada SQUID en el Fundry
      • telnet@ServerIron(config)# server cache-name squid1 192.168.1.10
      • telnet@ServerIron(config)# server cache-name squid2 192.168.1.11
    • Agregar los Squids a un cache-group
      • telnet@ServerIron(config)#server cache-group 1
      • telnet@ServerIron(config-tc-1)#cache-name squid1
      • telnet@ServerIron(config-tc-1)#cache-name squid2
    • Crear una politica para caching http sobre un puerto local
      • telnet@ServerIron(config)# ip policy 1 cache tcp http local
    • Activar la politica sobre el puerto conectado a tu router
      • telnet@ServerIron(config)#int e 17
      • telnet@ServerIron(config-if-17)# ip-policy 1
    Ya que todo el trafico saliente a internet  pasa por la interface 17 (el router) y la interface 17 tiene la politica de caching aplicada, el trafico HTTP va a ser interceptado y redireccionado a las caches que tengamos configuradas.
    El puerto por default para la redirección puede ser cambiado. El algoritmo usado para el balanceo de carga puede ser cambiado (Least Used, Round Robin,etc). Puertos pueden ser exentos del caching si es necesario. Listas de acceso (ACL) pueden ser aplicadas para que solamente ciertas direcciones IP sean redireccionadas,etc.


    3.4 WCCP - Web Cache Cordinator Protocol
      En este momento no voy a trabajar con este protocolo, pero es importante saber que SQUID soporta WCCPv1 y WCCPv2.


    3.5 TProxy Interception
      TProxy es una nueva característica de SQUID 2.6 la cual mejora el estándar de Interception Caching, ocultando la presencia de tú cache. Normalmente con Interception Caching el servidor remoto ve a la ingeniería de cache como la fuente de todas las peticiones HTTP. TProxy mejora este paso ocultando la ingieneria de cache haciendo que el cliente final sea visto como la fuente de las peticiones (aunque realmente no lo sea).
    Esta nueva característica es interesante tenerla presente o saber de su existencia. Del Troubleshooting de este how to solo voy a tomar:


    8.4 "Connection reset by peer" and Cisco policy routing
      Fyodor ha rastreado la causa de un inusual mensaje "connection reset by peer" cuando usas políticas de ruteo Cisco para hijack peticiones  HTTP. 
    Cuando el link de red entre el router y la cache cae (goes down) por un instante, los paquetes que están supuestamente para ser redireccionados son enviados a la ruta por defecto. Si esto sucede, un TCP ACK puede ser enviado desde el host cliente al servidor de origen en vez de ser enviado a la cache. El servidor de origen, recibe un paquete inesperado ACK y envía de vuelta un TCP RESET al cliente, lo cual aborta el requerimiento del cliente.
    Para trabajar sobre este problema, puedes instalar una ruta estática a la interface "null0"  para la dirección de la cache con una métrica alta (baja precedencia) tal como 250.
    Entonces, cuando el link cae (goes down), los paquetes desde el cliente serán dropeados en vez de ser enviados a la ruta por defecto.
    Por ejemplo, si la IP 1.2.3.4 es la dirección del SQUID cache, puedes agregar:
    • ip route 1.2.3.4 255.255.255.255 Null0 250
    Esto parece causar el correcto comportamiento.


    Glosario


    PMUT = Path MTU es la técnica para determinar el tamaño de la maxima unidad de transmisión (MTU)  on the network path entre dos IP's hosts, usualmente con el objetivo de evitar la fragmentación IP.
    OpenBSD PF= Open BSD Packet Filter.
    Helpers= Squid puede extenderse usando varios conjuntos de coprocesses (helpers) que manejan aspectos específicos, de los requerimientos o de las respuestas.

    4 ago 2010

    Comenzando con SQUID - El WEB Proxy Cache

    Voy a tomar desde las FAQ's de Squid, lo que a mi entender resulta interesante  tener en cuenta, a la hora de diseñar y configurar un web proxy-cache (Squid).

    ¿ Cual es el tamaño del sistema que necesito para ejecutar Squid ?
      No hay reglas rígidas y rápidas. El recurso más importante  para Squid es la memoria física, colocar la mayor cantidad de memoria que se pueda.
    Los procesadores no necesitan ser ultra rápidos, es recomendable comprar aquellos que sean económicos en el tiempo.
    El disco de sistema sera el mayor cuello de botella, por lo tanto, discos rápidos son importantes para altos volumenes de cache. La performance de los discos SCSI generalmente es mejor que la de los discos ATA. Los discos SATA tienen una performance intermedia entre los discos SCSI y ATA. El disco de sistema y el disco de logfile pueden ser IDE, sin perder performance.
    La relación memory-to-disk puede ser importante. Recomendamos 32 MB de RAM por cada GB de espacio de disco que se planea usar para cache.



    ¿ Es correcto usar discos separados para Squid ?
      Si, ejecutar squid sobre discos separados a los cual se ejecuta es sistema operativo es muchas veces una muy buena idea.
    En general, el tiempo de búsqueda es lo que se espera optimizar o mas precisamente, la cantidad total de búsquedas que el sistema puede mantener. Por esta razón, es mejor tener la cache_dir sobre discos pequeños separados, que sobre un gran disco (especialmente con SCSI).
    Si el sistema es muy exigido en E/S, desearas tener el sistema operativo y los directorios de log en discos separados.


    ¿ Que "cache_dir" size debo utilizar ?
      En este capitulo suponemos que se esta dedicando una porción entera del disco para el cache_dir de squid, como es a menudo.
    En términos generales, configurar el tamaño del cache_dir igual que el tamaño de la partición, no suele ser una elección acertada. Primero por que Squid no es muy tolerante a ejecutarse fuera del espacio de disco. Sobre el tamaño limite del cache_size, squid usara un poco de espacio extra para el swap.state y algo mas de espacio temporal como área de trabajo, por ejemplo cuando re construye el swap.state.  Así que en cualquier caso asegurarse de dejar espacio extra para esto, o la cache entrara en un ciclo infinito de crash-rebuild.
    La segunda razón es la fragmentación, los sistemas de archivos (filesystems) por si mismos pueden hacer mucho para evitar la fragmentación, y para ser efectivo necesitan espacio para optimizar la ubicación de los archivos. Si el disco esta lleno, la optimización es muy difícil y cuando el disco esta 100% lleno la optimización es imposible. Ten tú disco fragmentado y este sera seguramente tu peor cuello de botella.


    ¿ Como puedo ver estadísticas de squid a nivel de sistema ?
      Las distribuciones de squid incluyen una utilidad llamada cachemgr.cgi, la cual puede ser usada para ver las estadísticas de squid con un browser.


    ¿ Por que no puedo ejecutar Squid como Root ?
      Ni lo voy a traducir, es obvio.


    ¿ Puedes decirme una manera de Upgrade Squid con un tiempo mínimo de Downtime ?
      Esta es una técnica que fue descrita por Radu Greab.
    Iniciar un segundo servidor (instancia)  Squid sobre un puerto HTTP sin uso (supongamos el 4128). Esta instancia de Squid probablemente no necesite una disco cache grande. Cuando esta segunda instancia (server) ha finalizado de recargar el almacenamiento de disco, cambiar el valor de http_port en squid.conf de ambas instancias. Configurar la instancia original para usar el puerto 5128 y la segunda para usar el puerto 3128. Después, ejecutar "squid -k reconfigure" para ambos Squids. Los nuevos requerimientos irán al segundo Squid ahora sobre el puerto 3128 y el primer Squid terminara de manejar sus actuales requerimientos. Después de unos minutos, es seguro el shutdown del primer squid y upgrade este. Posteriormente simplemente repite los pasos en orden inverso.

    La instalación de Squid es sencilla, y esta bien documentada en las faq's de squid, aunque hay que tener en mente las facilities o helpers que se utilizaran, por ejemplo snmp.
    En mi laboratorio estoy usando un FreeBSD 8.0, recompile el kernel para que estuviera 100% acorde al hardware y a la utilidad que le voy a dar. Instale Squid 2.7.9 desde los ports (compilando), esta versión tengo entendido que al día de la fecha es la mas estable y parcheada de todas.



    24 may 2010

    ISO 27001 Auditor Líder con Certificación Internacional IRCA

    Tal cual lo dice el titulo, el viernes 21/05/2010 he logrado la certificación ISO 27001 Auditor Líder, por medio de I-Prot, estoy muy feliz :-) .
    Ha sido una experiencia sumamente gratificante para mi, mas allá del estrés por ser tan intensivo y el examen final, agradezco al instructor Mario Ureña Cuate. Que con total desinterés compartió con todos nosotros sus vivencias y basta experiencias en esto que es la auditoria.
    Un fuerte abrazo a mis compañeros, especialmente a Carlos, mi compañero de equipo.


    Ahí va la foteli (obvio que no va etiquetada ni nada que se le parezca)




    Hasta la próxima.

    3 feb 2010

    Creación automática de sitios Webs, con Apache2 y Vsftp

    Este post va dedicado, en contra del trabajo rutinario y/e aburrido. Estos últimos meses, he observado que existe gente que no le molesta hacer las cosas de forma repetitiva dia a dia, en particular es algo que me desespera ya que no solo se vuelve una tortura sino que también nos hace perder nuestro valioso tiempo.
    Y que cosa mas aburrida que la creación de sitios en Apache y su correspondiente acceso via FTP. Desconozco la existencia de alguna herramienta que nos permita hacer esto de forma automatizada, por lo que decidí hacer la mia.

    Como pre requisito es necesaria la instalación de los paquetes apache2, libapache2-mod-php5, vsftpd,db4. La configuación de los mismo no esta al alcance de este post.


    #!/bin/bash
    #+-----------------------------------------+
    #| Developer by Alejandro Andino.  |
    #+-----------------------------------------+

    echo -n "Ingrese el nombre del sitio web, sin dominio,www ó http : "

    read user_site

    echo -n "Ingrese el nombre del dominio: "

    read domain

    password=`cat /dev/urandom | tr -dc A-Z-a-z-0-9-_ | head -c10`

    ftp="/etc/vsftpd"

    user_ftp=`echo "ftp_"$user_site`

    apache="/etc/apache2"

    sites=$apache"/sites-available"

    sudo chmod o+rxw $ftp/users_db

    echo $user_ftp >> $ftp/users_db

    echo $password >> $ftp/users_db

    if [ $? -ne 0 ]; then
    echo "Problemas de acceso a  $ftp/users_db !!!"
    exit
    fi

    sudo chmod o-wx $ftp/users_db

    parametros="s/\(local_root=\/var\/www\)\/.*/\1\/$user_site/g"

    if [ -f $ftp/virtual-users.db ]; then
    sudo rm $ftp/virtual-users.db
    sudo db4.4_load -T -t hash -f $ftp/users_db /etc/vsftpd/virtual-users.db
    else
    sudo db4.4_load -T -t hash -f $ftp/users_db /etc/vsftpd/virtual-users.db
    fi

    if [ -f $ftp/users/virtual1 ]; then
    sudo cp -f $ftp/users/virtual1 $ftp/users/$user_ftp
    sudo chmod o+rw $ftp/users/$user_ftp
    cat $ftp/users/virtual1 | sed -e ${parametros} > $ftp/users/$user_ftp
    sudo chmod o-r $ftp/users/$user_ftp
    else
    echo "No existe el template de acceso ftp !!!"
    exit
    fi

    #cat $ftp/users/$user_ftp

    if [ ! -f $ftp/users/$user_ftp ]; then
    echo "ERROR al crear usuario FTP !!!"
    exit
    fi

    ################################################"

    sudo mkdir -p /var/www/$user_site

    sudo chown -R www-data:www-data /var/www/$user_site

    if [ -f $sites/default00 ]; then
    sudo cp $sites/default00 $sites/$user_site
    sudo chmod o+rw $sites/default00
    sed -e "s/^.*NameVirtualHost.*//g" $sites/default00 | \
    sed -e 's/ServerAdmin.*/ServerAdmin aandino\@localhost/g' | \
    sed -e "s/DocumentRoot.*/DocumentRoot \/var\/www\/`echo ${user_site}`\//g" | \
    sed -e "s/ServerName.*/ServerName www\.`echo ${user_site}`\.`echo ${domain}`/g" | \
    sed -e "s/ServerAlias.*/ServerAlias \*`echo ${user_site}`\.`echo ${domain}`/g" | \
    sed -e "s///g" > $sites/$user_site
    sudo chmod o-rw $sites/$user_site
    else
    echo "Verifique su instalacion de Apache2 !!!"
    exit
    fi

    sudo a2ensite $user_site

    if [ $? ]; then
    sudo /etc/init.d/apache2 reload
    else
    echo " Un Error ha ocurrido al cargar el Site !!!"
    exit
    fi

    sudo chmod o-rxw $ftp/users_db

    echo "Operacion terminada con exito !!!"
    echo ""
    echo "###################################"
    echo ""
    echo "Usuario FTP: "$user_ftp
    echo ""
    echo "Password FTP: "$password

    Este scripts nos dara como salida la creación del sitio web que le especifique os y su correspondiente acceso via FTP.

    11 ene 2010

    Problemas de sincronización entre varios procesadores - Linux SMP & VmWare Timekeeping

    Este ultimo tiempo, me he encontrado "repentinamente" con problemas en un servidor virtualizado,  despúes de 250 días de actividad interrumpida el host invitado (guest) como se le suele llamar en la gerga de la virtualizacion entra en un estado inconsistente, se congela (hang) y es imposible accederlo remotamente e inutil hacerlo por la consola. Son varios los errores que he detectado en los logs tales como:

    •  ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
    •  ifconfig[2844]: segfault at xxxxx error 4
    • Dec 21 13:55:05 hosting2-front02 kernel: Clocksource tsc unstable (delta = 4688700040 ns)
    • kernel: checking TSC synchronization [CPU#0 -> CPU#1]: passed.                              kernel: checking TSC synchronization [CPU#0 -> CPU#2]: passed.                                                  kernel: checking TSC synchronization [CPU#0 -> CPU#3]:                                                                kernel: Measured 6 cycles TSC warp between CPUs, turning off TSC clock.                                                       kernel: Marking TSC unstable due to: check_tsc_sync_source failed.                                                                                                         kernel: Brought up 4 CPUs
    • Haciendo vmstat o top: Floating point exception.
    • Al hacer df -h                                                                                                 overflow              1.0M  4.0K 1020K   1% /tmp
    He googleado por semanas, tratando de atar cabos, y de encontrar el por que de este comportamiento aleatorio e inesperado. En la busqueda encontre indicios de DDoS (Denegación de servicio) mediante syn flooding, algo que corregi por medio de mod-evasive,iptables e tunning TCP en el kernel de Linux.
    A pesar de haber hecho los ajustes necesarios, el comportamiento se sigue repitiendo, el sistema operativo se congela una vez al día, durante la madrugada donde las cargas son menores. Mi ambiente  de producción es el siguiente:
    • Linux 2.6.24-19-virtual #1 SMP Thu Aug 21 00:52:59 UTC 2008 i686 GNU/Linux
    • Ubuntu JeOS Server 8.04.3 LTS 
    • Servidor de aplicaciones web Apache 2.2.8 Server.
    • Cuatro procesadores Intel(R) Xeon(R) CPU X5450  @ 3.00GHz
    • 3805 Mb de RAM.
    En uno de los mensajes anteriores del kernel.log, ya me estaba dando la pauta que algo extraño sucedia con la sincronizacion de los procesadores  y su clocksource
    • kernel: Marking TSC unstable due to: check_tsc_sync_source failed.
    Al investigar al respecto, descubro que existe problemas de sincronizacion entre el host de virtualizacion (ESX 3.5 en mi caso) y los huespedes (Linux guest), existen salto de reloj o desincronización entre ambos, el clock real de las interrupciones y la BIOS virtual proporcionada al sistema invitado. En los kernel 2.6.X la correcciones se basan en algoritmos mejorados que pueden producir saltos hacia delante o hacia a tras en el Linux guest, lo que proboca descontinuidad en le sistema huesped. Estas versiones de kernels introducen la temporización y metodos de correccion mediante la API ACPI del kernel, el clocksource. Estas correcciones son las que provocan que nuestro servidor proporcione inexactitud a nuestras aplicaciones y hanging del servidor.
    Como solucionarlo, esta documentado por vmeware aqui por lo que no voy a perder tiempo en explicarlo. En las recomendaciones de este documento esta la utilización del servicio NTP, lo cual en mi caso fue necesario para poder solucionar el problema, ya que al pasarle al kernel el clocksource=acpi_pm, no fue suficiente. Aclaro que la comunicación NTP es bidireccional en el puerto UDP 123, es decir nuestros firewalls deben dejar entrar y salir estos puertos para que la sincronización tenga efecto. Los comando NTP lo trate en un entrada anterior.

    "La formulación de un problema, es más importante que su solución."
     EINSTEIN, Albert                


    Referencias: