lunes, noviembre 30, 2015

vim: registros y macros (I)

vim utiliza una serie de registros internos para manejar el texto que se está editando. Si consultamos la ayuda con :help registers veremos que hay nueve tipos distintos. En esta entrada me voy a centrar en los llamados registros con nombre, aquellos que se identifican con una letra del alfabeto (de la a a la z). Éstos sólo los usa vim cuando se referencia a los mismos de manera específica.

Hay varios comando que se le puede especifar el registro destino donde queremos que se almacene los resultados del mismo. Por ejemplo, si se quiere copiar las 4 primeras líneas de un fichero al registro a:

:1,4y a

Puede verse el contenido del registro a con los datos copiados con:

:register a

Si se quisiera insertar el contenido del registro a al final del fichero se podría hacer de la siguiente manera:

:$pu a

Esta no deja de ser una manera de usar el conjunto de registros con nombre de vim como una especie de block de notas donde podemos poner texto e ir pegando según nos convenga. Una propiedad interesante que tienen los registros es que su contenido puede ser interpretado como una secuencia de pulsaciones que son órdenes de vim, es decir, los registros se utilizan para definir macros.

Por ejemplo, supongamos que queremos usar el registro a de tal manera que cuando se ejecute la macro vim automáticamente realice los siguientes pasos:

  • Vaya a una nueva línea
  • Pase a modo de inserción
  • Inserte un texto.
  • Situe el cursor en una determinada posición en el texto insertado.

Para grabar una macro usamos la orden ql, introducimos las órdenes de vim que nos interese y cuando terminamos pulsamos q. Para ejecutar una macro se utiliza @l. En ambos casos l es el nombre del registro que queremos usar. Cuando vim está grabando una macro de esta manera, aparecerá la palabra recording en la línea de comando. Un ejemplo de una macro grabada esa manera es el siguiente:

$a^M<p style="text-indent: 30px;">^M^M</p>^[

El comando anterior sólo lo utilizo para que se vea lo que podemos hacer con vim en una macro. No está preparado para poder copiarse directamente a nuestro $HOME/.vimrc, ya que tiene caracteres de control que no están correctamente en el texto.

Lo interesante es poder mapea estas macros a secuencias de teclas, de tal manera que las mismas se ejecuten de manera automática al pulsarlas. Por ejemplo, si quiero que la macro anterior, grabada en el registro a se ejecute al pulsar F1, sólo en el modo normal del editor:

:nmap <F1> @a

La limitación más importante que tiene el mecanismo de registros es que son globales a vim, no están personalizados por cada buffer de texto que estemos editando, con lo cual las macros que hayamos grabado, serán iguales para todo vim. Esto, sin embargo, puede tener cierta solución usando los eventos de BufRead / BufEnter, para ir definiendo las macros de acuerdo a nuestros intereses en ciertos buffers de texto.

Referencias

viernes, noviembre 27, 2015

osquery(II): Configurar osqueryd

En el primera entrada sobre osquery estuve probando las posibilidades de osquery para obtener información del sistema desde la línea de comandos con osqueryi. Pero la fortaleza de una herramienta de este tipo es poder definir aquellas consultas que queramos y que el programa las vaya ejecutando cada cierto tiempo, almacenando el resultado de las mismas o los cambios que se han producido en las partes del sistema que estamos monitorizando.

El programa que se encarga de ejecutar las consultas programadas en osqueryd. Éste lee su fichero de configuración en el cual se definen las diferentes opciones, las consultas que ejecutará para obtener la información del sistema, los ficheros y directorios que monitorizará para detectar cambios y las opciones de salida. Por defecto, esta información la almacenará en una base de datos RocksDB y en un fichero de texto donde cada una de sus líneas es un objeto JSON con los datos o la modificación de los mismos. La primera vez que se ejecuta una consulta determinada almacenará todos los resultados en la base de datos RocksDB. A partir de entonces, solamente almacenará los cambios respecto a la última vez que se ejecutó la consulta.

Por defecto, el fichero de configuración en el caso de la instalación de OS X está en /var/osquery/osquery.conf o en los directorios /var/osquery/osquery.conf.d/*.conf. En caso de que esté en una ruta distinta puede pasarse el parámetro --config-path ruta especificando la ruta donde está dicho fichero. El formato del fichero de configuración es JSON. En casa una de las claves principales, se configura las opciones, las consultas que se quieren realizar, la comprobación de integridad de ficheros y los packs, que son conjuntos de consultas que permiten tener información del sistema que estamos monitorizando.

{
  "options": {
    ...
  },
  "schedule": {
    ...
  },
  "file_paths": {
    ...
  },
  "packs": {
    ...
  }
}

Bajo la clave options se definen varios parámetros de configuración de osqueryd. Todos estos parámetros de configuración tienen valores por defecto, por lo que en principio no sería necesario definirlos. Pero si estamos haciendo un despliegue en multitud de nodos usando alguna herramienta como Ansible o Puppet se querrá establecer algunos paramétros de configuración por defecto.

En la configuración por defecto, osqueryd leerá las consultas a realizar del fichero de los ficheros de configuración y almacenará los resultados de las mismas en un fichero en texto plano en el disco duro. Cada línea de dicho fichero es un objecto JSON. Una funcionalidad interesante que tiene osqueryd es que se puede crear un fichero de configuración mínima que utilice una conexión protegida por TLS para que baje la configuración y envié los resultados de las consultas que se hagan en el sistema a un punto central donde puedan consolidarse y analizarse. En los ejemplos que voy a utilizar en esta entrada toda la configuración y el registro se hará sobre el sistema de ficheros.

Un ejemplo de las opciones que se pueden configurar es el siguiente

{
  "options": {
    "host_identifier": "baldurgate",
    "schedule_splay_percent": 10,
    "config_plugin": "filesystem",
    "logger_plugin": "filesystem",
    "logger_path": "/var/osquery/logs"
  }
}

Configuramos algunas de las opciones que no nos interesa por defecto de osqueryd. El nombre del host (host_identifier), un tiempo que se añade a cada query para evitar lanzar varias a la vez en el mismo instante (schedule_splay_percent), el sistema que se va a usar para almacenar los registros (logger_plugin) y la ruta donde se van a almacenar, puesto que el logger_plugin es filesystem.

Pero la parte importante son las consultas que se quieren realizar sobre el sistema para que nos de la información que necesitamos monitorizar. La configuración normal hace que se ejecute la consulta la primera vez y luego sólo se almacene las diferencias de las mismas respecto a la ejecución anterior. Estas diferencias también son escritas a través del plugin de registro que se haya seleccionado. En la web del proyecto pueden verse las diferentes tablas que pueden consultarse. Cada clave que haya dentro de la sección schelude debe ser única, definiendo la consulta y cual debe ser la periodicidad con la cual se debe de ejecutar.

{
  "schedule": {
    "macosx_alf" :{
      "query": "SELECT * from alf",
      "interval": 60
    },
    "macosx_alf_excpetions": :{
      "query": "SELECt * from alf_exceptions",
      "interval": 60
    },
    "macosx_alf_explicit_auths": :{
      "query": "SELECT * from alf_explicit_auths",
      "interval": 60
    },
  }
}

Estas tres consultas obtienen información del sistema cada sesenta segundos. Es importante cuando se definen las consultas en osquery comprobar cual es el rendimiento que tienen la máquina, ya que podría ocurrir que se gastara demasiados recursos en las mismas, teniendo que modificar tanto la programación como el número de consultas para no ahogar la máquina.

El comportamiento por defecto del osqueryd es mandar al plugin de registro tanto las filas de la consulta que se han añadido como las que se han quitado. Sin embargo, hay consultas en las cuales dicho comportamiento no tiene sentido. Por ejemplo, consultas que devuelvan resultados relacionados con el tiempo o contadores de rendimiento. Puesto que osquery mandará la línea añadida y quitará la que no existe, se puede usar la clave removed a false para que esa información no se almacene. Por ejemplo

Por otro lado, si se quiere los datos en un punto determinado de tiempo de una consulta se puede hacer con snapshot a true, en vez de registrar las diferencias. Por ejemplo, la siguente consulta almacenaría la información de cada punto de montaje de manera periódica (mismo ejemplo que está en la documentación de osquery)

  "schedule": {
    "mounts": {
      "query": "select * from mounts",
      "interval": 3600,
      "snapshot": true
    }
  }

Una de las funcionalidades más interesantes incluidas en osquery es la posibilidad de actual como un host IDS, analizando los directorios y ficheros que se programen para avisar en caso de que exista algún cambio. Por ejemplo, si se desea monitorizar posibles cambios en todos los directorios bajo /etc se podría usar una configuración como la siguiente:

  "schedule": {
    "query": "select * from file_events;",
    "removed": false,
    "interval": 300
  },
  "file_paths": {
    "etc": [
      "/etc/%%"
    ]
  }

Los posibles eventos que se generen debido a las modificaciones que se produzcan en los ficheros y directorios especificados en file_paths se almacenarán en la tabla file_events, la cual se podrá consultar para ver las modificaciones que se han ido produciendo.

Por último hablar de los packs que no son más que conjuntos de consultas definidas para realizar una determinada labor (por ejemplo obtener una foto de la máquina en un momento dado o para gestión de vulnerabilidades). La instalación de OS X por defecto tiene cuatro packs que se instalan en /var/osquery/packs. Un ejemplo de como configurar uno de ellos es el siguiente:

  "packs": {
    "vuln_management": "/var/osquery/packs/vuln-management.conf"
  }

Esto es un primer vistazo a las posibilidades que tiene osquery para utilizarlo como herramienta de inventariado, monitorización y conformidas en máquinas Linux y OS X. Hay más opciones de las que no he hablado, como la posibilidad de usar reglas yara para detectar malware, la posibilidad de usar herramientas remotas para configurar osquery o centralizar los registros de los eventos que vaya creando el sistema.

miércoles, noviembre 25, 2015

Activar el menú depuración de las App Store de OS X

La App Store que utiliza las últimas versiones de OS X es una aplicación desarrollada con tecnologías HTML y Javascript que se ejecuta en un contenedor WebKit. A veces, puede ser necesario activar la depuración de la misma depurar errores que puedan estar ocurriendo. Para ello simplemente introducimos la siguiente línea en una shell:

defaults write com.apple.appstore ShowDebugMenu -bool true

Volvemos a reiniciar la aplicación de la App Store y tendremos el menú depuración:

Las opciones más interesante son Show Download Folder que nos abrirá una ventana del Finde en el directorio por defecto donde se descargan las aplicaciones, Clear Cookies que borrará las cookies que el sistema pudiese tener almacenadas y Reset Application que nos reseteará la aplicación.

sábado, noviembre 07, 2015

HyperScan: Librería de expresiones regulares de alto rendimiento de Intel

En la pasada Conferencia de Usuarios de Suricata,celebrada a principios de esta semana en Barcelona,Intel ha presentado HyperScan, una librería de expresiones regulares especializada en machear gran cantidad de las mismas contra bloques o flujos de datos a alta velocidad. Este librería comenzó como un producto de fuentes cerradas en el año 2008 hasta su publicación por Intel este año.

Los antivirus y sistemas de deteción de instrusiones de red (NIDS) suelen estar diseñados para usar un conjunto de reglas que usan expresiones regulares para intentar detectar patrones de datos que puedan ser una amenaza.

Las librería compila las expresiones regulares - que siguen el formato de expresiones regulares de la librería pcre - en una base de datos. El resultado de esta compilación depende del modo en que se vaya a usar las expresiones regulares - ya sea para buscar en un bloque o en un flujo de datos - y del procesador que se vaya a usar para realizar la operación de macheo, intentando usar todas las características que tenga cada CPU - como instrucciones SIMD - .La librería no usa backtraking con lo cual su consumo de recursos es reducido y apropiado para su uso en sistemas embebidos.

Ayer le pregunté a uno de los autores de Suricata sobre las pruebas que Intel había hecho con un Suricata modificado para usar dicha librería, ya que los datos de rendimiento del Suricata normal era un orden de magnitud menor que el Suricata que usaba HyperScan. Las pruebas las ha hecho Intel usando el conjunto de reglas http de emerging threads.

El código fuente de la librería está disponible en github bajo una licencia de tipo BSD.