Security Art Work

(Si te sientes cómodo y representado por este texto, dale toda la difusión que puedas y quieras: reprodúcelo, enlázalo, tradúcelo, compártelo, vótalo… todas esas cosas que puedes hacer con total tranquilidad y libertad gracias, precisamente, al hecho de que tenemos todavía una red neutral. Hagamos posible el seguir teniéndola)

Los ciudadanos y las empresas usuarias de Internet adheridas a este texto MANIFESTAMOS:

La Red Neutral es un concepto claro y definido en el ámbito académico, donde no suscita debate: los ciudadanos y las empresas tienen derecho a que el tráfico de datos recibido o generado no sea manipulado, tergiversado, impedido, desviado, priorizado o retrasado en función del tipo de contenido, del protocolo o aplicación utilizado, del origen o destino de la comunicación ni de cualquier otra consideración ajena a la de su propia voluntad. Ese tráfico se tratará como una comunicación privada y exclusivamente bajo mandato judicial podrá ser espiado, trazado, archivado o analizado en su contenido, como correspondencia privada que es en realidad.

Europa, y España en particular, se encuentran en medio de una crisis económica tan importante que obligará al cambio radical de su modelo productivo, y a un mejor aprovechamiento de la creatividad de sus ciudadanos. La Red Neutral es crucial a la hora de preservar un ecosistema que favorezca la competencia e innovación para la creación de los innumerables productos y servicios que quedan por inventar y descubrir. La capacidad de trabajar en red, de manera colaborativa, y en mercados conectados, afectará a todos los sectores y todas las empresas de nuestro país, lo que convierte a Internet en un factor clave actual y futuro en nuestro desarrollo económico y social, determinando en gran medida el nivel de competitividad del país. De ahí nuestra profunda preocupación por la preservación de la Red Neutral. Por eso instamos con urgencia al Gobierno español a ser proactivo en el contexto europeo y a legislar de manera clara e inequívoca en ese sentido.

El otro día leía detenidamente una noticia que me dejó pensativo. No porque no estuviese de acuerdo. Ni siquiera porque no fuese algo que pudiese ocurrir. Todo lo contrario. Leía que un juez, haciendo uso de la ley, imponía a un padre de un adolescente una multa en base a la falta de cumplimiento del deber “in vigilando” que se le exige a un padre, como responsable de su hijo menor de edad.

El caso es que al padre en cuestión el juez le impuso una multa de 5.000 euros porque su hijo arremetió en la red social tuenti contra una niña a la que, de hecho, no conocía de nada. Fue un recurso fácil para hacerse el gracioso y a la niña le supuso un trauma del que tardará en recuperarse. Técnicamente es un caso de “ciberbullying” o ciberacoso.

¿Qué debemos hacer los padres con este tipo de comportamientos? ¿Cómo nos podemos enterar de lo que hacen nuestros hijos en las redes sociales? Por una parte es evidente que debemos vigilar el comportamiento de nuestros hijos en la sociedad puesto que somos responsables del mismo y es nuestro deber educarlos, pero, por otra, ¿cómo podemos hacer eso sin saltarnos su derecho a la intimidad o a la privacidad?

Hace poco, en relación a un proyecto de seguridad de menores en el que estamos trabajando, mantuvimos una reunión con un grupo de fiscales que nos insistían en que los menores tienen los mismos derechos que los adultos en este sentido, es decir, no podemos interferir sus comunicaciones sin que ellos lo sepan y por supuesto, no podemos obviar su derecho a la intimidad, así que ¿cómo podemos enterarnos de los riesgos que acechan a nuestros hijos en su uso cotidiano de las nuevas tecnologías? No hablamos de sistemas de control parental, ni de herramientas antivirus, ni antimalware, necesitamos una nueva generación de sistemas de ayuda a los padres o tutores que nos alerten de los riesgos, que nos avisen cuando algo va mal.

[Read more…]

Tradicionalmente, las infraestructuras de red de datos han estado basadas en arquitecturas de tres capas: core, distribución y acceso, siendo esta última la que soporta las conexiones de los sistemas finales. Este tipo de arquitecturas desde un punto de vista únicamente de gestión son relativamente sencillas: el departamento de comunicaciones es quien se encarga del acceso a red (configuración, administración,etc), y el personal de sistemas administra todos los aspectos relativos al sistema final: usuarios, aplicaciones, recursos, etc.

A medida que los sistemas evolucionan, y actualmente con las distintas técnicas de virtualización en auge, esta administración se vuelve más compleja puesto que ya no tenemos un modelo de gestión delimitado; pensemos en un sistema blade con un switch empotrado en el propio chasis, un sistema VMWare usando su vswitch para permitir la conectividad de las máquinas virtuales, o el uso de una arquitectura distribuida usando vd; en cualquiera de los casos, ¿quién administra estos equipos de comunicaciones? Habitualmente, el administrador de red no suele llegar a este nivel, quedando en manos del administrador de sistemas (o de virtualización) la gestión del dispositivo, el cual es posible que no disponga de los mismos conocimientos de red que el personal dedicado.

Recientemente he asistido a un taller de Cisco sobre Unified Computing donde Cisco propone varias soluciones a este problema mediante la tecnología VN-LINK. Esta trata, salvando la distancia, de mapear un puerto de red a cada máquina virtual, de forma que el administrador de red gestiona todos los puertos de la red por igual, usando las mismas herramientas, pudiendo crear perfiles de red (port profile) que más tarde el administrador de virtualización podrá asignar a los sistemas finales. Con este propósito, también han creado la alianza VCE, formada por VMWare, Cisco y EMC (véase la noticia en idg.es).

Para solucionar este problema, Cisco dispone de varias soluciones basadas en el switch de la serie Nexus 1000V (conmutación virtual sobre el hypervisor o sobre la tarjeta física) o Hypervisor bypass, usado en sistemas críticos que requieren gran rendimiento. El sistema Cisco Nexus 1000V es un sistema de conmutación basado en Cisco NX-OS, formado por dos componentes, la supervisora, desde la cual se configuran y gestionan los parámetros de red de las máquinas virtuales, y el software instalado sobre VMWare que se encarga de la propia conmutacion. Este sistema sustituye al conmutador virtual proporcionado por VMWare, mejorando el modelo de gestión ya que podemos administrarlo con las mismas herramientas que el resto de switches de nuestra red, y mejorando la funcionalidad, puesto que disponemos de todas las opciones de configuración de los switches habituales, como pueden ser Private VLan, Port Security, DHCP Snooping, etc,

Para llevar a a cabo esta mejora, Cisco ha lanzado su estrategia UCS (Unified Computing System) agrupando mediante un único sistema, procesamiento, almacenamiento y virtualización. Los sistemas basados en UCS disponen de un sistema completo de servidores distribuidos y chasis (en formato blade o rack), que se interconectan y gestionan desde un único punto de red, permitiéndonos disponer de sistemas llamados Stateless Server, es decir, con posibilidad de separar el propio servidor (sistema operativo y configuración) del hierro sobre el que corre, de forma que podremos crear perfiles de servicio (Service Profile) con los datos de hardware (interfaces de red, interfaces HBA, parametros de BIOS, etc) y llevar el sistema a otro hardware distinto, manteniendo toda la configuración.

Como comentó Rafa en su post de la semana pasada, empresas como CISCO están realizando grandes avances tecnológicos, y aunque no sea tan futurista como la telepresencia en 3D, seguro que la tecnología UCS da mucho que hablar. Desconozco las soluciones similares de otros fabricantes, aunque me costa que Juniper e IBM trabajan en algo similar. ¿Algún lector tiene más información al respecto?

Para acabar la semana, tenemos una entrada de Rafael Rosell, que inicia su andadura como colaborador de este blog.

Rafael es Ingeniero Superior Industrial y Máster por el IESE. Asimismo, actualmente es Director Comercial del Instituto de Biomecánica de Valencia y es especialista en la dirección de equipos de ventas y estrategias comerciales, campo en el que lleva más de 15 años trabajando. Esperamos que la entrada les guste tanto como a nosotros.

Ha llegado a mis manos un artículo muy interesante de El Economista en el que se comentan los grandes avances tecnológicos que empresas como CISCO están obteniendo, y que sin duda puede revolucionar la forma en la que hacemos las cosas o nos relacionamos.

El artilugio en cuestión es digno de aparecer en escenas de “Matrix”: se trata de un sistema de telepresencia en 3D. Traducido al cristiano, esto significa que (una vez dicha tecnología llegue a su fase de comercialización), seremos capaces replicar en 3D con apariencia bastante real una imagen de una persona con el objetivo de, entre otras cosas, participar en reuniones a distancia, reproduciendo una imagen de mí como si en realidad estuviera presente en la citada reunión.

[Read more…]

Para empezar la semana, hoy tenemos una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre ingeniería social governance. Esperamos que les guste.

Hoy me gustaría hablarles de una palabra que todo el mundo tiene últimamente en la boca: el governance. Y es que ésta es una de esas palabras que gustan… como que hace tilín. Desde Marketing hasta los más altos CEO’s, CTO’s, CIO’s, y otros tantos, hablan del governance aquí, allí, hoy y mañana. En estos últimos años he oído la palabra governance en todos los foros donde creía que podía salir y en otros tantos en que nunca me lo hubiera imaginado, y es que es pegadiza y suena bien, y de paso le da a uno esa imagen de cosmopolita que tanto gusta.

¿Que es el governance? Partamos de la base que el governance no es nada si no hay algo que gobernar. Partiendo de esta premisa, podemos aplicar governance a todo, y de hecho se aplica por defecto (ya sea bien o mal, eso es otra historia) a todas las facetas —voy a restringir el campo— de la informática empresarial (sí, empresarial): desde la metodología de desarrollo hasta la seguridad de los puestos de trabajo. Y es que el governance (yo lo entiendo así) es el ‘como se hacen las cosas’, y por eso hay que definirlo bien, ya que sino las cosas se nos irán de madre. ¿Y qué tiene esto que ver con la seguridad? ¿Qué hace el governance compartiendo espacio en este foro a veces técnico, a veces legal pero siempre interesante? Pues señores, el governance y la seguridad deben ir ligados como si fueran parte de la fórmula de la Coca-cola. Pero, ¿por qué la Coca-cola? Pues porque nadie conoce realmente como se fabrica (bueno, espero que alguien sí lo sepa), y porque el governance no es una metodología, no es tangible, no es medible (bueno, existen aproximaciones), pero es necesario conjugarlo bien en todos los puntos para que no nos salga gaseosa marrón.

El governance y la seguridad comienzan desde el momento que se define que es neceasario ‘gobernar’ la situación para que esto no se vaya de madre. Por ejemplo, en desarrollos de arquitecturas SOA (software) se habla de que la seguridad debe estar desde el nacimiento y esto es parte del governance —y mira que se habla de governance cuando alguien menciona SOA… En la gestion de CPD’s (no estoy muy ducho en este tema, francamente) podríamos hablar que el governance debe velar porque los aspectos de seguridad se tengan en cuenta, en la integración de los sistemas (no en un proyecto de integración sino en el uso de ESB, EAI o simples hubs made-in-house) el governance debe velar entre otras cosas por que las interfaces sigan estándares y la integración, monitorización, control y deploy sea correcto (disponibilidad de servicios aparte de su desarrollo, finalmente algo de seguridad), en infraestructura de redes podríamos hablar de tener en cuenta la alta disponibilidad de hardware, el caudal de datos, los procedimientos operativos…

En fin, el governance es una pieza fundamental de cómo hacer las cosas, de qué cosas hacer y de quién debe hacerlas. Para mí es como ver una pirámide a vista de pájaro. Es la única manera de ver realmente todas las caras, incluso la no visible, y de esa forma entender de forma clara la estructura. Es por eso que las pirámides deben verse desde el cielo, pero construirse desde la base. Así que si alguno de ustedes pretende cogerle el gusto al governance, no comiencen por alzar la vista mirando al techo (N.d.E. cosa que, se lo digo yo, no sirve de nada más que para acabar mal de las cervicales), evalúen las situaciones desde los mandos intermedios (generalmente mas operativos), definan los objetivos (con ellos) y aprovechen su conocimiento para llevar a cabo las acciones procedimentales/técnicas/organizativas que deben asegurar que se esta gobernando la situación.

Para hoy martes tenemos una entrada de Rafa García, amigo y antiguo colaborador de S2 Grupo que ya ha participado en el blog en alguna ocasión.

Rafa ha dedicado los últimos años de su carrera profesional a la gestión de datacenters, campo en el que posee extensos conocimientos (como demuestra la presente entrada), y es actualmente Director de NIXVAL, un proveedor de servicios de externalización de centros de datos para alojamiento de sistemas de misión crítica, parte del grupo CLEOP. Esperemos que la entrada les guste tanto como a nosotros.

Recientemente, trabajando en una ampliación bastante importante de nuestro centro de datos he podido constatar ya de forma generalizada que el mercado propone parámetros de diseño de salas técnicas con temperatura ambiente de 25º C y control de humedad de humedad relativa al 80%. Este post va de porqué, cómo y hasta dónde pueden realizarse estos cambios en una sala técnica existente —en este caso una de un centro de datos real— ya que con estos nuevos parámetros de diseño los centros de datos han dejado de ser como los conocíamos hasta la fecha.

El aumento de la temperatura de la entrada en aire a los servidores de 21º hasta 25º es un cambio que está operativo desde hace aproximadamente 1 año en una de las salas de nuestro centro de datos, que alberga aproximadamente 130 kW de sistemas. ¿Porqué este aumento? Para ahorrar energía, claro. ¿Y no causa problemas en los sistemas? No. Los equipos actuales soportan temperaturas operativas de hasta 35º garantizadas por el fabricante. Como muestra los parámetros operativos del equipo DELL Poweredge R210, uno de los mas baratos (369 €) y populares servidores:

[Read more…]

Dado que el anterior post del blog tenía como protagonistas gráficos a un par de cerdos, voy a utilizarlos como nexo de unión para lo que quería comentarles (ya saben que me gusta encontrar situaciones -a veces curiosas- que nos permiten ver la necesidad de gestionar la seguridad en múltiples actividades cotidianas).

La norma ISO 28000 como ya hemos visto en posts anteriores introduce la gestión de la seguridad en la cadena logística o de suministro, y basa el sistema de gestión a implantar fundamentalmente en el análisis de riesgos, revisando las amenazas que pueden afectar a:

• El personal.
• La información que da soporte a los procesos de negocio.
• Los bienes o mercancías.
• El medio o los medios de transporte utilizados.
• Las unidades de carga.

Pues bien, voy a comentarles los tres casos que he visto en la prensa digital de hoy.

[Read more…]

Terminamos con éste la serie de artículos sobre la implantación de un IDS en un entorno con una alta tasa de tráfico, donde veremos las soluciones que se han tomado para el problema de los paquetes descartados y la escritura en base de datos.

Según dejamos el tema en el artículo anterior, el problema parece residir en que Snort, hasta que no termina de escribir la alerta en la base de datos, no procesa el siguiente paquete. La escritura en base de datos se realiza mediante una conexión TCP que precisa del handshake y de la escritura del INSERT en la misma; es por esto que constituye un proceso muy lento. Para solucionarlo, vamos a tomar cuatro pequeñas medidas que reducirán considerablemente el tiempo que necesita Snort en generar una alerta:

Escritura en disco local de la alerta y uso del formato unified2. La escritura en local es mucho más rápida que la escritura en red y si utilizamos un formato binario que ocupa muy poco espacio, se tardará mucho menos tiempo en generar la alerta. El formato binario unified2 es una evolución del formato unified introducido en Snort v.2.8. Se trata de un formato extensible formado por una cabecera que define el tipo de registro y su longitud, y que permite guardar en un mismo fichero diversos tipos de eventos como, por ejemplo, alertas IPv6, estadísticas o información de escaneos.

[Read more…]

A estas alturas empieza a ser difícil encontrarse con una organización que no quiera invertir tiempo y esfuerzo en la seguridad. Aunque queda camino por recorrer, poco a poco la madurez en la seguridad está evolucionando desde el “si no falla ni nos han entrado, no pasa nada” al “debemos controlar el riesgo“, de modo que ha habido una migración en los últimos años en cuanto al foco de la seguridad. Ésta ya no se centra sólo en la disponibilidad de los servicios, sino también en la integridad de los mismos; las diferentes normativas que se han elaborado en estos años, como la LOPD o el Esquema Nacional de Seguridad ha ayudado mucho a que la seguridad esté cada vez mas presente en todas las organizaciones. Conceptos como “correlación”, “IPS”, “consola de gestión” o “monitorización” son cada día más conocidos y ya no suenan a jerga especializada.

Sin embargo, a pesar de esta mejora la seguridad sigue siendo vista no como un aspecto que debe envolver todos los demás, según una perspectiva holística, sino como otro elemento más en nuestra infraestructura de red (el firewall, un router, la VPN) o como una auditoría que nos revela fallos que solventamos. Es decir, como un elemento o acción puntual y aislada que nos permite incrementar nuestra seguridad o a veces tan sólo la percepción de seguridad. Existen varios efectos colaterales de esta manera “compartimentada” de abordar la seguridad, que les indico a continuación:

• Los beneficios del proyecto no se trasladan de manera efectiva a la organización, sino que se limitan a aquel departamento que ha promovido la iniciativa. No resulta nada raro que una organización decida abordar una auditoría 27002 pero el resultado efectivo sea la mejora de aquella parte de la seguridad de la que el departamento promotor es responsable, generalmente IT, por una simple cuestión de autoridad y competencias.
• Las implantaciones de nuevos sistemas, productos o elementos se quedan “cojas”, introduciendo incluso nuevos problemas de seguridad; un concentrador VPN es mucho más que un elemento de red que nos permite acceder remotamente a la organización: requiere procedimientos de alta y baja de usuarios, revisión periódica de usuarios, actualizaciones, políticas de utilización acceso remoto (y teletrabajo si es una de sus funciones), etc.
• El propio enfoque de la seguridad, unido a que se trata en muchos casos de iniciativas o proyectos “departamentales” e incluso en ocasiones casi personales, hace que no sea nada raro que el conocimiento y la experiencia que se deriva de estas iniciativas quede “atrapado” en el personal implicado en el proyecto. De este modo, no se incorporan al know-how de la organización, y se limita su utilización en posteriores iniciativas.

Aunque los tres efectos indicados son igualmente perniciosos, me gustaría incidir un poco más en el último. Si las lecciones aprendidas quedan dentro de las “cabezas pensantes” del personal de comunicaciones, el personal de sistemas, o tan sólo el responsable de IT, y no se traducen en documentos y acciones formales o incluso informales, no se tarda mucho en convertirse en departamentos reactivos, incapaces de responder de forma coordinada y sobre todo, anticipada y preventiva. Por utilizar una expresión que seguro que muchos conocen, el resultado es que nos limitamos a apagar fuegos. Claro que más de uno pensará: ¿Cómo demonios me voy a poner a pensar en detectores de humo cuando tengo una habitación llena de fuego? Pues haciendo que los cambios en la manera de trabajar se introduzcan de forma gradual, poco a poco. Es fantasioso pretender que elaborar procedimientos, documentación o introducir algo de necesaria burocracia en el día a día no vaya a afectar a nuestra manera de trabajar, tanto en la carga de trabajo que implica su elaboración e implantación, como en el rechazo que mostramos ante cualquier cambio de rutina, aunque su consecuencia sea positivo.

La cuestión, al final, radica en garantizar que el aprendizaje diario permanezca en la organización y no en la cabeza de esta o aquella persona, ya sea a través de procedimientos formales o informales, que permitan cumplir con la legalidad, retener el conocimiento, y que deben ser aplicables en el día a día de la organización. Esto en ocasiones puede entrar en conflicto con una mala concepción de la “imprescindibilidad” que algunas personas tienen, pero sólo de esta manera seremos capaces de transmitir el conocimiento de las personas a la organización, evitando caer en pequeñas parcelas de conocimiento y de poder, que sólo obstaculizan el normal funcionamiento de la empresa.

(Entrada elaborada en colaboración con Manuel Benet)

Al hilo de una antigua entrada de nuestro compañero Antonio Villalón acerca de Dtrace y Solaris, me propuse encontrar algo parecido para sistemas Linux. Dtrace te permitia recolectar información del sistema a muy bajo nivel para detectar anomalías en su funcionamiento y en algunos casos poder prevenir futuros problemas.

Tras un tiempo de búsqueda, y después de descartar varias opciones que no me parecían todo lo completas que deberían, me encontré con SystemTap, una maravillosa herramienta que nos permite monitorizar la actividad del kernel mediante scripts sin tener que compilar y reiniciar cada vez que se requiera ejecutar una prueba.

Es crítico para un administrador de sistemas tener un control total sobre que ocurre en el sistema y herramientas como SystemTap, que te permiten obtener datos precisos del funcionamiento del sistema son de gran ayuda. También aporta seguridad el hecho de poder tener controlado cualquier evento del sistema, ya no a nivel de aplicación, sino de kernel. Conocer qué procesos están abriendo cierto fichero, el consumo de red de cualquier proceso o la ejecución de X función dentro del kernel por Y proceso nos proporciona una ingente cantidad de información que puede resultar necesaria en caso de una detectar una intrusión.

Por el propósito que tiene, SystemTap no es sencillo. Aunque la base es fácil de comprender, su programación requiere conocimientos avanzados de los diferentes módulos del kernel de Linux, aparte de conocimientos de su propia sintaxis. Por suerte para nosotros, existe abundante documentación, y para facilitarnos la tarea y reducir la barrera de entrada existen ya multitud de scripts de ejemplo que nos permitirán ver su funcionamiento e imaginar las posibilidades que tiene SytemTap.

Su instalación es bastante sencilla. En una distribución Fedora basta con instarlo mediante Yum y luego usar un comando propio para que descargue e instale el paquete kernel-debug correspondiente a nuestra versión actual del kernel:

Como breve introducción, en SystemTap tenemos “events” y “handlers”. La construcción habitual en SystamTap suele ser la siguiente

En lo que respecta a los “events” existen dos tipos, síncronos y asíncronos. Un evento síncrono ocurre cuando cualquier proceso ejecuta una operación en el kernel. Como ejemplos de este tipo de eventos tenemos:

• Entradas a syscalls.
• Operaciones en el VFS (Virtual File System).
• Entradas en funciones del kernel, por ejemplo “sys_open”.
• Entradas en funciones de cierto modulo.
• etc.

Los eventos asíncronos, por contra, son aquellos que no están ligados a ninguna instrucción particular en el código. Consisten principalmente en contadores y temporizadores.

Los “handlers” es la parte del código llamada cuando ocurre un “event”. Este código, una mezcla entre C y AWK, nos permite tratar la información del evento, almacenarla y en general, utilizar cualquier función disponible en cualquier lenguaje moderno (salida por pantalla, uso de vectores, funciones,…). Vamos a ver un ejemplo básico de “probe”, el cual almacenaremos en un fichero denominado probe.stp, y ejecutaremos con la orden stap probe.stp

En este ejemplo, cuando se realice cualquier llamada a la función open() el script escribirá por pantalla el nombre y el PID del proceso que ha ejecutado la llamada.

A partir de aquí, el asunto se puede complicar todo lo que queramos. Se pueden declarar funciones para factorizar el código, variables globales para compartir información entre handlers, timers, etc., y como con cualquier lenguaje nuevo hay que aprender la sintaxis. Por si esto no fuera suficiente, hay que conocer los eventos que podemos registrar en el kernel. Lo más recomendable para no desanimarnos es comenzar probando los scripts de prueba, ver como trabajan, y adaptarlos a nuestras necesidades, leyendo la documentación correspondiente en cada caso. En el wiki del proyecto encontrareis abundante información, y en Fedora, además, podemos instalar el paquete systemtap-testsuite el cual nos copiará en /usr/share/systemtap/testsuite/systemtap.examples/ multitud de ejemplos.

Por último, me gustaría compartir un script que me gustó mucho (está en el paquete de testsuite que hemos mencionado) y que nos permite conocer el consumo de red de cada proceso del sistema en tiempo real. Os invito a que lo reviséis, veáis como se programa un script un poco complejo y las posibilidades de la herramienta. El script tan sólo almacena en cada llamada a las funciones transmit y receive la información en vectores para luego, en función de un timer, mostrarla por pantalla. Aquí esta:

#! /usr/bin/env stap 
global ifxmit, ifrecv 
global ifmerged 

probe netdev.transmit 
{ 
  ifxmit[pid(), dev_name, execname(), uid()] < << length 
}

probe netdev.receive 
{ 
  ifrecv[pid(), dev_name, execname(), uid()] <<< length 
} 

function print_activity() 
{ 
  printf("%5s %5s %-7s %7s %7s %7s %7s %-15s\n", 
          "PID", "UID", "DEV", "XMIT_PK", "RECV_PK", 
          "XMIT_KB", "RECV_KB", "COMMAND") 

  foreach ([pid, dev, exec, uid] in ifrecv) { 
    ifmerged[pid, dev, exec, uid] += @count(ifrecv[pid,dev,exec,uid]); 
  } 

  foreach ([pid, dev, exec, uid] in ifxmit) { 
    ifmerged[pid, dev, exec, uid] += @count(ifxmit[pid,dev,exec,uid]); 
  } 

  foreach ([pid, dev, exec, uid] in ifmerged-) { 
     n_xmit = @count(ifxmit[pid, dev, exec, uid]) 
     n_recv = @count(ifrecv[pid, dev, exec, uid]) 
     printf("%5d %5d %-7s %7d %7d %7d %7d %-15s\n", 
            pid, uid, dev, n_xmit, n_recv, 
            n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0, 
            n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0, 
            exec) 
  } 

  print("\n") 

  delete ifxmit 
  delete ifrecv 
  delete ifmerged 
} 

probe timer.ms(5000), end, error 
{ 
  print_activity() 
}