Hemos seguido descubriendo rincones de España que merecen muchísimo la pena (Gredos, Picos de Europa), por encima de las estupideces de las diecisiete taifas autonómicas que tenemos que soportar.
Espero que este año 2009 sea mejor que el que ha pasado y que haya salud para todos. Me gustaría extenderme más, pero casi es hora de ponerme a cenar. Disfrutar de la noche en compañía de toda vuestra gente.
La configuración de Snort que voy a usar es la siguiente:
ibookdrizzt:~ terron$ id snort
uid=504(snort) gid=504(snort) groups=504(snort)
ibookdrizzt:~ snort$ tar zxvf snortrules-snapshot-2.8.tar.gzEl comando anterior generará un árbol de directorio cuya raíz es /Users/snort donde descomprimirá todos los ficheros de reglas y configuración de Snort.
Ahora hay que editar el fichero snort.conf,cuyo path completo si se ha seguido la configuración anterior será /Users/snort/etc/snort.conf. Este fichero hay que modificarlo de acuerdo con las reglas que se deseen usar, los diferentes módulos de detección que tiene Snort, las variables que definen cuales son las redes a analizar y los módulos encargados de escribir las alertas. Como mi idea de momento es usarlo en una instalación de ossim, he decidido dejar todas las reglas activadas. Con la configuración que quiero implementar las líneas que hay que añadir al fichero snort.conf son las siguientes:
config logdir: /Users/snort/log/La explicación de las líneas anteriores es la siguiente:
output alert_fast: alert.log
output unified2: filename snort.log,limit 64
config set_gid: 504
config set_uid: 504
config snaplen: 1500
ibookdrizzt:/Users/snort root# snort -i en1 -c /Users/snort/etc/snort.conf
En este caso la interfaz que está conectado a Internet es la en13, que recibirá el tráfico y lo analizará, y generará las diferentes alarmas y capturará los paquetes que las causan. Si vemos el directorio de registro:
alert.log
snort.log.1230070130
snort.log.1230071033
Vemos el fichero alert.log que almacena las alarmas en modo texto y los otros dos ficheros son binarios en formato Unified 2. Estos últimos son los que quiero analizar.
Technorati Tags: snort
"The crisis from which we are now suffering is also the outcome of a credit expansion" (1931)
Curiosas, en especial la última: "La crisis que estamos sufriendo es una consecuencia de la expansión de crédito". Los analistas económicos y estudiosos de la materia tendrán que pensar si realmente el crédito puede estar creciendo hasta el infinito con los diferentes mecanismos financieros sin estar respaldado por el correspondiente crédito.
El nuevo formato no tiene cabeceras que identifiquen el fichero (como si ocurre en el formato unified), y que cada fichero no es más que un conjunto de eventos y los paquetes de datos asociados a lo mismos. Todos los DWORD (unit32_t) y WORD (uint16_t) son enteros de 4 y 2 bytes respectivamente big endian ("network byte order"). La estructura de un evento almacenado en el fichero es la siguiente:
| #define | Valor | Estructura |
|---|---|---|
| UNIFIED2_PACKET | 2 | Unified2Packet |
| UNIFIED2_IDS_EVENT | 7 | Unified2Event |
| UNIFIED2_IDS_EVENT_IPV6 | 72 | Unified2Event6 |
| UNIFIED2_IDS_EVENT_MPLS | 99 | Unified2Event_MPLS |
| UNIFIED2_IDS_EVENT_IPV6_MPLS | 100 | Unified2Event6_MPLS |
En caso de estar grabando un paquete de datos (representado por la structura Unified2Packet),tras esta va los datos del paquete.
| Campo | Tipo | Descripción |
|---|---|---|
| sensor_id | DWORD | Identifica el sensor que ha generado el evento. |
| event_id | DWORD | Identificador del evento. |
| event_second | DWORD | Para almacenar una marca temporal de la generación del evento. |
| event_microsecond | DWORD | |
| signature_id | DWORD | Identifica a la regla de Snort que ha generado ele vento. |
| generador_id | DWORD | Identifica el módulo de Snort que generado el eventos. |
| signature_revision | DWORD | Revisión de la regla |
| classification_id | DWORD | Identifica la clase a la que pertenece la alerta generada. Esto se configura en Snort a través de la sentencia config classification |
| priority_id | DWORD | Identifica la prioridad de la regla que ha generado la alerta. |
El resto de los campos de cada estructura son específicos de cada uno de los eventos.
typedef struct _Unified2RecordHeader
{
uint32_t type;
uint32_t length;
} Unified2RecordHeader;
typedef struct _Unified2Event
{
uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t event_microsecond;
uint32_t signature_id;
uint32_t generator_id;
uint32_t signature_revision;
uint32_t classification_id;
uint32_t priority_id;
uint32_t ip_source;
uint32_t ip_destination;
uint16_t sport_itype;
uint16_t dport_icode;
uint8_t protocol;
uint8_t packet_action;
} Unified2Event
typedef struct _Unified2Packet
{
uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t packet_second;
uint32_t packet_microsecond;
uint32_t linktype;
uint32_t packet_length;
uint8_t packet_data[4];
} Unified2Packet
Unified2Event6
typedef struct _Unified2Event6
{
uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t event_microsecond;
uint32_t signature_id;
uint32_t generator_id;
uint32_t signature_revision;
uint32_t classification_id;
uint32_t priority_id;
struct in6_addr ip_source;
struct in6_addr ip_destination;
uint16_t sport_itype;
uint16_t dport_icode;
uint8_t protocol;
uint8_t packet_action;
} Unified2Event6
typedef struct _Unified2Event6
{
uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t event_microsecond;
uint32_t signature_id;
uint32_t generator_id;
uint32_t signature_revision;
uint32_t classification_id;
uint32_t priority_id;
struct in6_addr ip_source;
struct in6_addr ip_destination;
uint16_t sport_itype;
uint16_t dport_icode;
uint8_t protocol;
uint8_t packet_action;
} Unified2Event6
typedef struct _Unified2Event_MPLS { uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t event_microsecond;
uint32_t signature_id;
uint32_t generator_id;
uint32_t signature_revision;
uint32_t classification_id;
uint32_t priority_id;
uint32_t ip_source;
uint32_t ip_destination;
uint16_t sport_itype;
uint16_t dport_icode;
uint8_t protocol;
uint8_t packet_action;
uint32_t mpls_label;
} Unified2Event_MPLS;
typedef struct _Unified2Event6_MPLS
{
uint32_t sensor_id;
uint32_t event_id;
uint32_t event_second;
uint32_t event_microsecond;
uint32_t signature_id;
uint32_t generator_id;
uint32_t signature_revision;
uint32_t classification_id;
uint32_t priority_id;
struct in6_addr ip_source;
struct in6_addr ip_destination;
uint16_t sport_itype;
uint16_t dport_icode;
uint8_t protocol;
uint8_t packet_action;
uint32_t mpls_label;
} Unified2Event6_MPLS
Technorati Tags: snort
En este cuadro de diálogo seleccionamos la interfaz que consideramos pública (en este caso será el Airport) y las interfaces de red que se van a compartir, cosa que se hace en el cuadro de diálogo de abajo. Una vez que se ha activado, pulsamos iniciar y se comienza a compartir las interfaces de red.
Veamos los cambios de configuración que ha realizado la GUI. En primer lugar, las reglas de firewall. Para ello desde una ventana de Terminal, ejecutamos la orden ipfw show.
00010 26221 16201955 divert 8668 ip from any to any via en1 02000 264607 23464758 allow ip from any to any via lo* 02010 0 0 deny ip from 127.0.0.0/8 to any in 02020 0 0 deny ip from any to 127.0.0.0/8 in 02030 0 0 deny ip from 224.0.0.0/3 to any in 02040 0 0 deny tcp from any to 224.0.0.0/3 in 02050 209103 38244907 allow tcp from any to any out 02060 333894 376385236 allow tcp from any to any established 02065 0 0 allow tcp from any to any frag 12190 3 192 deny tcp from any to any 65535 7662 912661 allow ip from any to anyAparte, se habrá ejecutado un proceso, natd que será el encargado de traducir las direcciones. Podemos verlo ejecutando el comando:
ibookdrizzt:~ terron$ ps aux|grep natd root 372 0.0 0.0 27332 580 ?? Ss 12:14AM 0:00.43 /usr/sbin/natd -alias_address 192.168.1.33 -interface en1 ibookdrizzt:~ terron$
Lo que hace la primera regla del firewall, es dirigir todos los paquetes que lleguen a la interfaz en1 - el Airport - hacia el proceso natd, que será el encargado de traducir las direcciones, cambiando la origen con la que tenga la interfaz en1. Como puede verse el NAT se realiza en el momento de salida de los paquetes, tras decidir por cual interfaz va a salir.
La situación en la que quería usar el NAT es la que está representada en el siguiente esquema:
Tenemos un PowerMac G5 conectado a una red wireless cuyo punto de acceso es un router WIFI que me conecta a Internet. La red que se forma es una 192.168.1.0/24 y el Mac tiene asignado la dirección IP 192.168.1.100 (interfaz en1) . A la interfaz ethernet del Mac se crea una red ethernet con dirección IP asignada 192.168.2.1 (interfaz en0). Lo que quiero es que el Mac me haga NAT de las IP de la red 192.168.2.x y me las traduzca a una dirección IP en la red 192.168.1.x, a ser posible la misma que tiene asignada la interfaz wireless. Una implementación de un masquerading clásico.
El NAT se realiza en MacOS X justo antes de que el paquete abandone la interfaz de red. En el esquema anterior, los paquetes salen hacía Internet a través de la interfaz en1. Por tanto, se deberá configurar natd para que intercete los paquetes antes de salir y modifique la dirección origen del paquete y llegado el caso, el puerto origen. Hay que indicarle al kernel que pase los paquetes que coinciden. En nuestro caso, cualquier paquete que tenga dirección origen 192.168.2.0/24 hacia cualquier dirección. Usaremos ipfw para que el kernel nos pase los paquetes a través del mecanismo divert:
ipfw -f flushOjo, en caso de que ya existan reglas en el firewall, comentar que ipfw -f flush borraría todas las existentes. En este caso habría que ver donde insertarlas. Se puede consultar las reglas que ya están instaladas ejecutando la orden ipfw show.
ipfw add divert natd all from 192.168.2.0/24 to any via en1
Ahora habrá que ejecutar natd, el programa que se va a encargar de traducir las direcciones. La dirección IP a la cual se va a traducir recibe el nombre de alias. Este programa cuando se ejecuta, automáticamente pasa a background, con lo cual si se quiere depurar el tráfico de paquetes, se debe ejecutar con la opción -v. Puesto que queremos que se le traduzca todo lo que nos mande la regla de divert configurada anteriormente, teóricamente debería valer con:
/usr/sbin/natd -v -interface en1Sin embargo, veremos que esto no funciona. ¿Por qué?. Porque aunque nos traduzca correctamente la dirección origen de cualquier paquete que salga con la dirección en el rango 192,.168.2.0/24, los que recibe el firewall no sabe que debe enviarlos de nuevo al proceso natd. Esto ocurre por la particular implementación que usa MacOS X y que deriva de FreeBSD, frente a la implementación de Linux toda realizada en el núcleo, y que tiene la correspondiente tabla de estados que permita saber que paquetes están nateados o qué paquetes tienen como origen la propia máquina que hace NAT.
La solución para mi situación es muy sencilla,puesto que tengo dos redes privadas que controlo y puedo usar direcciones en ellas sin problemas: Lo que hago es añadir una IP alias a la interfaz en1 que va a ser la que usen los paquetes nateados. Una regla de nuevo en el ipfw que haga que todo lo que llegue hasta esa IP sea dirigido hacia el natd y ya está. La configuración sería de la siguiente manera:
ifconfig en1 192.168.1.101 alias ipfw -f flush
ipfw add divert natd all from 192.168.2.0/24 to any via en1
ipfw add divert natd all from any to 192.168.1.101 via en1
natd -a 192.168.1.101
El soporte de inspección de protocolos es muy limitado, sólo tiene soporte para FTP e IRC, estando el resto de protocolos que mandan información de direcciones dentro de los mismos no soportados - los famosos módulos de masquerading de Linux -.
Hay dos visiones distintas: La primera es aquella de los que defienden que los modelos son correctos, pero que los datos con los que se han alimentado son erróneos (por ejemplo In Modeling Risk, the Human Factor Was Left Out, en el New York Times. La segunda visión, After the Crash: How Software Models Doomed the Markets, afirma que los modelos están pensados para unas condiciones de contorno concretas, y que cuando estas se alteran, ya no son válidos. En este caso ciertas suposiciones que se hacen para establecer los modelos económicos no serían válidos:
The software models in question estimate the level of financial risk of a portfolio for a set period at a certain confidence level. As Benoit Mandelbrot, the fractal pioneer who is a longtime critic of mainstream financial theory, wrote in Scientific American in 1999, established modeling techniques presume falsely that radically large market shifts are unlikely and that all price changes are statistically independent; today’s fluctuations have nothing to do with tomorrow’s—and one bank’s portfolio is unrelated to the next’s.Esta nota hace referencia a uno de los mayores estudiosos de sistemas caóticos como es Benoit Mandelbrot. Reconozco que me gusta esta idea y entronca con mi visión más liberal de la economía donde agentes privados interaccionan entre sí y no se puede planificar las decisiones que toman.
Ahora, ¿qué pasa cuando se modela un sistema pensando que se cumplen esas restriciones siempre y se alimenta con datos para obtener un resultado determinado?. Pues que el resultado es indefinido puesto que nos hemos saltado las condiciones de contorno para las cuales el modelo fue creado. Sumémoles a esto la capacidad de proceso y velocidad de las redes de comunicaciones actuales y tendremos un sistema que utiliza un modelo para tomar decisiones económicas que está básicamente en un estado desconocido y que dado su interconexión está multiplicando la "basura" generada por un modelo que está actuando fuera de las condiciones de contorno para el que fue concebido. Lo que en informática se llama GIGO, Garbage In, Garbage out, que viene a resumir que un ordenador hace exactamente lo que tú le propones, y que si le metes basura como entrada, los datos que resulten de su proceso serán basura (primera visión) o si el modelo no funciona (segunda visión) seguiremos obteniendo información falsa.
Una de las cosas más interesantes de esta crisis es que está siendo casi televisada, en el sentido que la información fluye por el mundo casi en el mismo momento que se produce, llegando algunos, como Klaus Zimmermann presidente del instituto de estudios económicos DIW, a pedir que se dejen de hacer prediciones y no se publiquen (la referencia al final de esta noticia). Algún día alguien estudiará el efecto multiplicativo que ha tenido la información (o la falta de la misma) en esta crisis económica.
Technorati Tags: crisis,informática,
La primera parte describe los navegadores webs, los estándares y protocolos sobre los que se contruyen y cómo están soportados en cada uno de los diferentes productos existentes.
La segunda parte muestra un resumen de los diferentes mecanismos que implementan los navegadores para proporcionar un entorno segurod de navegación, así como los defectos que se han detectado en los diseños.
La Tercera parte hace referencia a mecanismos de seguridad experimentales y mecanismos que se man tienen por compatibilidad.
Technorati Tags: google,seguridad,navegadores web
Los objetivos de Google es permitir un entorno de ejecución de módulos binarios x86 - aunque podrían portarlo a otras arquitecturas de microprocesador - que permitan aprovechar la potencia disponible en los microprocesadores actuales, que sea portable entre diferentes sistemas operativos y que sea seguro. Para poder interactuar con el resto del navegador existe un puente que comunica javascript con los módulos binarios.
Google crea un entorno aislado ("sandbox") donde se va a ejecutar los diferentes módulos, cada uno de los cuales está en un espacio de direcciones separados y que se comunican entre ellos a través de un mecanismo de procedimientos de llamada remoto (RPC). Se aísla el código que se ejecuta en el sandbox del sistema operativo, ofreciendo sólo una serie de servicios autorizados a llamar desde los ejecutables generados.
De la documentación que llevo leída, en especial de Native Client: A Sandbox for Portable, Untrusted x86 Native Code, la idea que me hago de la arquitectura que quiere implementar Google es la siguiente:
Destacar en este caso el mecanismo de comunicación, denominado IMC e implementado en éste módulo de intercomunicación.
Para tener un entorno seguro se realiza un análisis estático del código que se ha generado: se busca detectar aquellas instrucciones peligrosas para el sistema y se fuerza a que el módulo ejecutable tenga una determinada estructura para evitar código automodificable e instrucciones superpuestas. Además utiliza los mecanismos de segmentación presente en la arquitectura x86 para evitar referencias a memoria fuera de los límites del proceso, y aislar el módulo binario de las librerias que el propio sistema mapea en memoria. La implementación de estos mecanismos de protección es lo que Google llama inner sandbox.
Native Client impone las siguientes restricciones a un módulo binario para que pueda ejecutarse en el entorno:
El módulo tiene una particular disposición en memoria que permite atrapar aquellas referencias a punteros nulos (protege la primera página de la memoria asignada contra lectura y escritura). Los siguientes 60 Kb se utilizan para el código de los servicios de ejecución y el resto del espacio de direcciones se dedica al módulo.Todos los módulos binarios tienen como base la dirección cero y el código comienza a insertarse a partir de los 64 kbytes:
Es interesante ver en acción uno de los mecanismos que tienen los procesadores x86 desde que existe el modo protegido: El uso de la segmentación para limitar el rango de memoria que puede accederse.Acostumbrados a modelos de memoria planos y de 4 GB, Google implementa con ayuda de la segmentación el modelo de memoria (ver nacl_ldt.c para el caso de Linux). Este mecanismo, no se puede usar en procesadores ejecutando código de 64 bits. La estructura que tendría una vez cargado el módulo en memoria sería la siguiente:
Las llamadas al sistema que se realizan desde el módulo binario se compara contra una lista blanca de llamadas permitidas. Esta validación formaría otra capa de protección que Google llam outer sandbox, donde se implementaría los servicios de ejecución. Están en service runtime.
Aparte el entorno de ejecución define un API que da acceso a los servicios que puede necesitar el módulo binario: gestión de memoria, gestión de hilos o primitivas de sincronización.
Technorati Tags: google,native cliente,sandbox
A pesar del tiempo de perros que hacía, pudimos sacar algunas fotos del grupo escultórico:
Volvemos a la N-401 y entramos en el pueblo del Tiemblo. Justo en la rotonda de entrada - donde están unas estatuas que representan a los toros de guisando -, seguimos a la señalización que nos lleva hasta hacía el Castañar del Tiemblo. Al comienzo la carretera está asfaltada, aunque es estrecha, llegamos hasta una zona habilitada como parking. De aquí parte una pista de tierra, por la cual se puede circular con un coche sin problemas, que sube hasta un merendero. De éste merendero parte una senda de montaña que lleva hasta el pozo de nieve, una construcción donde se almacenaba nieve en invierno para posteriormente venderla en verano.
El bosque, con las sendas que parten hacía el pozo de nieve
La ventisca hacía aconsejable darse la vuelta, y bajar de nuevo. Llegado al cruce de la zona de aparcamiento del Castañar nos empezó a caer aguanieve, y decidimos continuar ya hacía el Tiemblo, para comer. Nos fuimos a comer a Casa Mariano, famoso por la abundancia de sus platos. Nos dimos un buen homenaje a base de chuletón y cochinillo.
Después de una agradable sobremesa, decidimos volver a Madrid, pero esta vez lo hicimos a través de El Escorial. Saliendo de El Tiemblo, fuimos hacía San Martín de Valdeiglesias por la N-403. Una vez allí, tomamos la M-501 con dirección a Madrid hasta llegar al cruce con dirección hacía Robledo de Chavela. Ya comienzan a verse las espectaculares antenas de la Madrid Deep Space Communication complexa, parte la red de antenas de espacio profundo de la NASA, desde donde se controlan misiones como las de la Voyager.
Llegamos a Robledo de Chavela, toda la zona estaba nevada. Comenzamos a subir el Puerto de la Cruz Verde. Por la zona de Robledo de Chavela no estaba demasiado nevado, pero al coronar y empezar a bajar hacia El Escorial, la vertiente estaba totalmente nevada. La carretera estaba despejada por las máquinas quitanieves, pero aún así había que ser prudentes. Llegamos al Escorial y ya tomamos la carretera hacía la A-6, y rumbo a Madrid.
Technorati Tags: El Tiemblo,gredos
Technorati Tags: derechos de autor,sgae
En conversaciones con miembros de la Ejecutiva socialista Rubalcaba acostumbra a recordar una anécdota del traspaso de poder con Francisco Álvarez Cascos, cuando éste le anunció que el gobierno del PP se proponía privatizar TVE y Rubalcaba le respondió "ya veréis cuando pasen unos cuantos meses como le cogéis gusto a la caja tonta y se os olvidan esas ideas de la privatización"Para que todo el mundo tenga claro porqué quieren los políticos las diferentes cadenas sufragadas con el bolsillo del contribuyente: simplemente sirven para hacer propaganda de los políticos de los cuales depende su presupuesto. Y para eso, mejor cerradas, que para eso hay ya bastantes cadenas de TV y radios que no depende de los presupuestos generales del estado, y sobre todo, tenemos Internet.
Technorati Tags: televisión
En Objective C se (autorelease pools aparte) crean objetos de esta manera:
MyClass *c = [[Myclass alloc] init];
MyClass *ref;
...
ref=[OtroObjecto myclass];
[ref retain];
...
[c release];
[ref release];
El mecanismo de gestión de memoria en las anteriores versiones de Objetive C estaba basado en una cuenta del número de referencias que tiene hacia el objeto. Cuando se crea el objeto tiene una sola referencia. Si se le manda el mensaje retain la cuenta de referencias aumenta en uno, mientras que si se le manda el mensaje release la cuenta de referencias disminuye en uno. Cuando ésta llega a cero el sistema libera la memoria asignada al objeto. Hasta ahora, toda esta gestión hay que realizarla manualmente teniendo cuidado para evitar que se pierda la cuenta, porque sino tendríamos una pérdida de memoria.
Para facilitar la labor a los programadores Apple ha decidido implementar un recoletor de basura que facilite el trabajo a los programadores y no tengan que llevar la cuenta de referencias de los distintos objetos que se van creando y los que nos devuelve el sistema. Esta librería está escrita en C++ y según la documentación está pensado para usarlo en un entorno de ejecución donde parte de la memoria puede estar manejada por mecanismos distintos de los que ofrece Autozone.
La implementación ejecuta un hilo que va analizando la memoria, viendo la cuenta de referencias que tienen los objetos y construyendo un grafo que representa las relaciones entre los objetos que el programa ha creado. Si hay objetos aislados, significa que no existen referencias a los mismos por parte de otros objetos, y por tanto puede liberarse la memoria que utilizan.
Hay un hilo que está continuamente analizando las regiones de memoria. De esta manera se evita bloquear la ejecución de otros hilos mientras se analiza la memoria buscando objetos que no estén referenciados por otros.
Lo malo, es que no hay documentación que explique porqué está implementado la gestión de memoria de esta manera.
De los comentarios de la entrada en Reddit encontré la referencia a expresión regular necesaria para validar una dirección de correo electrónico RFC 822. Sólo tiene 83 líneas y 6509 caracteres. Y aún así el motor regex de Perl es capaz de comérsela, aunque supera con creces lo que es lógico y mantenible hacer a través de expresiones regulares.
Technorati Tags: regex
Arquitectura
Mapa de memoria
Toros de Guisando
Regex