David Bohm

Hay dos frases que definen mi manera de pensar:
Realmente no hemos prestado mucha atención al pensamiento como un proceso; hemos participado en pensamientos, pero sólo hemos prestado atención al contenido, no al proceso.
La capacidad de percibir o pensar de manera diferente es más importante que el conocimiento adquirido.
Ambas son de David Bohm.

domingo, 31 de mayo de 2020

Logs en Linux, archivos para dar y tomar

El mundo de los logs en Linux se hace complicado cuando hay que analizar un comportamiento en el servidor, uno de sus servicios o una aplicación concreta. Por ello vamos intentar resumir los ficheros mas importantes, comúnes o útiles, aunque es un tarea complicada.

Veamos, tradicionalmente se han clasificado en categorias como:
   - Logs de sistema
   - Logs de eventos
   - Logs de servicios
   - Logs de aplicaciones

Eso está muy bien y aparece en todos los sitios, pero la realidad es que si vamos a la configuración de rsyslog o syslog-ng por ejemplo, podremos ver un listado extenso de archivos a los que hace referencia:

   /var/log/auth.log - Logs de autenticación.
   /var/log/syslog.log - Logs de sistema
   /var/log/crond.log - Logs de los trabajaos de cron
   /var/log/daemon.log - Logs de servicios en segundo plano
   /var/log/kernel.log - Logs del kernel
   /var/log/lpr.log - Logs de impresión
   /var/log/user.log - Logs de usuario
   /var/log/maillog - Logs relacionados con el servidor de correo
   /var/log/messages - Logs generales de sistema

Si indagamos por internet, podremos obtener un puñado mas de archivos de logs:


   /var/log/httpd/ - Logs de apache
   /var/log/lighttpd/ - Logs de Lighttpd
   /var/log/boot.log - Logs de arranque de sistema
   /var/log/kern.log - Logs de kernel
   /var/log/mysqld.log o /var/log/mysql.log - Logs de MySQL
   /var/log/secure o /var/log/auth.log - Logs de autenticación
   /var/log/utmp or /var/log/wtmp
   /var/log/yum.log Logs de yum
   /var/log/qmail/ - Logs de qmail

Se que es una locura, pero si además incluyes aplicacions la lista puede ser infinita. Si tuviesemos que centrarnos en unos cuantos creo que sería bueno seleccionar los logs mas críticos y relevantes si un día tenemos un problema. Se que no vamos a descubrir nada nuevo, pero veamos esta lista tan habitual:


/var/log/boot.log --- Almacena la informacion relacionada con el arranque y los mensajes que se registran en dicho proceso. Aqui obtendremos información sobre apagados incorrectos, reinicios no planeados o fallos de arranque en general.

/var/log/auth.log o /var/log/secure --- El primer fichero es típico de distribuciones basadas en debian y el segundo en distribuciones basadas en red hat. Contiene todos los eventos relacionados con la autenticación y la autorización de usuarios. Permite revisar intentos fallidos de acceso, fuerza bruta, etcétera. Almacena todo lo relacionado con la seguridad, uso de sudo, inicios de sesión ssh y todos los eventos de autenticación de usuario. Informará sobre intentos de acceso no autorizados o fallidos, además de los inicios de sesión que se han realizado con éxito. También /var/log/faillog o /var/log/btmp contendrán intentos fallidos de acceso. El registro de inicio de sesión y su fin se mantienen en /var/log/wtmp. A este respecto es muy útil /var/log/lastlog que mantiene el último inicio de sesión de cada usuario.

/var/log/messages o /var/log/syslog --- Contiene registros de la actividad general del sistema, almacena mensajes informativos y no críticos. Puede mostrar errores de arranque no relacionados con el kernel y servicios relacionados con las aplicaciones. Suele ser el primer archivo que revisaremos si algo va mal.

/var/log/dmesg --- Almacena mensajes del nucleso relacionados con hardware, dispositivos y sus controladores. Contendrá la detección de los dispositivos, errores de hardware y otros mensajes genéricos.

/var/log/kernel.log o /var/log/kern.log --- Es un archivo importantísimo, contiene todo lo que registra el núcleo. Nos puede ayudar si tenemos un núcleo personalizado, o nuestro servidor presenta problemas de hardware, conectividad, etcétera.


/var/log/cron --- Registra todo lo que tenga que ver con las tareas programadas en cron. Cada vez que se ejecute una tarea programada cron registrará la información relevante, ejecuciones correctas, errores, etcétera.

/var/log/daemon.log --- Registra eventos relevantes de los demonios que estén en ejecución en segundo plano.

/var/log/yum.log --- Almacenará toda la información relevante cuando se instale un nuevo paquete si hemos usado yum. Registra la instalación de componentes del sistema y los paquetes de los repositorios. Es habitual que si un software no se ha instalado correctamente acudamos a este archivo log.

/var/log/maillog o /var/log/mail.log --- Registrará todo lo relacionado con el servicio de correo y de cualquier aplicación que tenga que ver con dicho servicio. Se podrá rastrear los envios y recepciones de correos electrónicos, investigar sobre problemas de entrega de correos, averiguar origen de un correo, spam, etcétera.

/var/log/httpd --- Almacena los registros del servidor apache si lo tenemos instalado. Normalmente se almacena en dos archivos diferentes: error_log y acces_log. En el primero se registrarán los errores relacionados con el servidor, su servicio y el sistema. En el segundo archivo se almacenarán todas las peticiones de acceso recibidas a través de protocolo http. Registrará dirección IP y el ID de los clientes que realizan peticiones de conexión al servidor tanto exitosas como infructuosas.

/var/log/mysqld.log o /var/log/mysql.log --- Almacena los registros del servidor mysql si lo tenemos instalado. El primer archivo es típico de distribuciones basadas en Red Hat y el segundo para las basadas en Debian. Es el archivo de registro con todos los mensajes de depuración, fallo y éxito relacionados con mysql. Se puede registrar desde problemas al iniciar, ejecutar o detener el demonio de mysql, hasta información sobre bloqueos de consultas, consultas de ejecución lenta, etcétera.

En otras entradas trataremos formas de centralizar la información y de poder hacer un análisis mas general o rápido de los logs, por lo menos en un primer paso que nos evite empezar a revisar archivo tras archivo. Podríamos ver desde un logwatch que nos ayuda a obtener un informe un poco mas "humano" de forma puntual o programada, hasta un servidor de logs Nagios o un graylog, con el que podremos centralizar, recopilar y monitorizar, para establecer alertas que nos notifiquen si hay un comportamiento anómalo en nuestros servidores.

SaluDOS

jueves, 14 de mayo de 2020

Powershell en Linux... tal cual suena y funciona.

Si, como lo oyes, estoy trasteando con powershell en linux, estoy ya tan acostumbrado al scripting con powershell en entornos Windows que me he lanzado al vacio.

Veamos como instalarlo. Vamos a la página de Microsoft para descargarlo aquí. En concreto vamos a instalar la versión 6 sobre elementary OS, luego vemos como sería en otras distribuciones.

Vamos a la opción de Linux y después tendremos que elegir la versión concreta, en este caso si miramos en consola lanzando el comando:

   # uname -a

Podremos obtener en la salida que es la versión: 18.04.1-Ubuntu

Así que vamos a esa versión concreta. Como puedes ver hay mas versiones y distribuciones diferentes.

Tomamos la primera opción, copiamos el contenido y lo ejecutamos en consola, sería este:

   # Download the Microsoft repository GPG keys
   wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb

   # Register the Microsoft repository GPG keys
   sudo dpkg -i packages-microsoft-prod.deb

   # Update the list of products
   sudo apt-get update

   # Enable the "universe" repositories
   sudo add-apt-repository universe

   # Install PowerShell
   sudo apt-get install -y powershell

Lo que va detrás del simbolo # serán solo comentarios, por lo que solo se ejecutarán las líneas de comandos.

En el caso de un CentOS 7, por coger otro ejemplo en plan servidor, solo tendríamos que seguir los pasos de la web de Microsoft, serían:

   # Register the Microsoft RedHat repository
   curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

   # Install PowerShell
   sudo yum install -y powershell

En cualquier caso, para lanzar la consola de powershell:

   # Start PowerShell
   pwsh

Si además tenemos VSCode instalado, quedaría integrada la terminal de powershell sobre el editor de código, una vez instalado powershell, solo tenemos que reiniciar VSCode, al ir a la extensión de Powershell veremos que ya nos abre el terminal integrado.

Prueba a lanzar un get-date y verás que funciona, a partir de ahí depende de tu imaginación...

SaluDOS

sábado, 9 de mayo de 2020

Montando un directorio compartido por NFS

Ultimamente un NAS comercial permite crear un directorio compartido de una forma sencilla. Al agregar una conexión NFS solo tienes que introducir la IP del equipo desde donde quieres conectarte y los permisos que le concedes. Obviamente no es lo mas seguro pero veamoslo por el lado sencillo, solo los comandos a ejecutar para conectar desde un linux a ese directorio.

Supongamos un entorno de laboratorio con los siguientes elementos:

   - NAS, tiene una ip: 192.168.100.252
   - Equipo, tiene una ip: 192.168.100.20, además hemos hecho una reserva en el DHCP para que siempre tenga esa dirección, otra opción es configurar en manual la red del equipo.
   - Directorio compartido: Creamos un directorio llamado Drive, le agregamos conexión NFS para que se pueda conectar la IP del equipo y establecemos permisos de escritura.
   - Al compartir, el NAS nos informará de la ruta que tiene el directorio compartido, supongamos que es: /volume1/Drive

Para conectarnos por NFS, necesitaremos instalar:

En Arch: Documentación oficial aquí.
   # pacman -S nfs-tools

En ElementaryOS:
   # apt install nfs-common
En CentOS:

   # yum install nfs-tools

Una vez que tenemos las utilidades NFS, podemos crear el directorio donde montaremos esa conexión remota:

   # mkdir /mnt/Drive

Tenemos dos opciones, empecemos por la primera, montar a mano el directorio, se puede especificar algún parametro mas pero ya no suele ser necesario:

   # mount 192.168.100.252:/volume1/Drive /mnt/Drive

Si queremos desmontar:

   # umount /mnt/Drive

Lo normal es que tengamos la unidad permanentemente mapeada y simplifiquemos el montaje/desmontaje si nos hiciese falta ejecutarlo, para ello tenemos que editar el fichero fstab y agregar una linea:

   # vim /etc/fstab

   192.168.100.252:/volume1/Drive /mnt/Drive nfs defaults 0 0

Recarga fstab, o bien reiniciando o mejor ejecutando:

   # mount -a

Tras este comando, se ha leido fstab y el punto de montaje se ha efectuado, podremos dirigirnos a /mnt/Drive y operar en el NAS sin necesidad de montarlo manualmente.

Ahora, si hiciese falta, podríamos montar el directorio así:

   # mount /mnt/Drive

O así:

   # mount 192.168.100.252:/volume1/Drive

Por ejemplo podríamos simplificar este último comando si añadimos un nombre en nuestro equipo para la IP, para ello editamos el fichero hosts y añadimos una línea:

   # vim /etc/hosts

   192.168.100.252      NAS01

Con esto, ya podemos hacer referencia al nombre y no a la IP, en todo lo que hemos ejecutado o configurado hasta ahora. Podriamos personalizar el nombre a nuestro antojo, independientemente del nombre que tenga realmente el dispositivo NAS.

En fstab especificariamos:

   NAS01:/volume1/Drive /mnt/Drive nfs defaults 0 0

Recargariamos fstab:

   # mount -a

Seguiriamos pudiendo montar directamente así:

   # mount /mnt/Drive

O así:

   # mount NAS01:/volume1/Drive

SaluDOS

jueves, 7 de mayo de 2020

¿Qué antivirus elegir?

Cuando quieres instalar un antivirus, tanto en tu casa como en los sistemas o empresa que administras, el tema está complicado.

Por un lado no es lo mismo un PC, un smartphone o un servidor, y por otro lado no todos los antivirus tienen soporte para todas las plataformas como Windows, Linux, Android o MacOS.

Si utilizas google o cualquier otro buscador, creo que mas que ayudar empeora a la hora de elegir, ya que la búsqueda tiene condicionantes y sobre todo influye la publicidad o el dinero que haya puesto una u otra empresa de antivirus por detrás.

Además está esa premisa de que lo barato sale caro y muchas veces es difícil saber si un antivirus en su versión gratuita nos va proteger o no.

AV-TEST es un instituto de investigación independiente en temas de seguridad. Aunque es un instituto alemán y no tengo cercanía sobre si nos podemos o no fiar de lo que dicen, cuando he querido comparar me ha ayudado bastante sus análisis. Tiene una trayectoria muy larga y sus rankings y análisis son muy conocidos.

Colaboran con otras instituciones y realizan bastantes estudios, contando con laboratorios de prueba bastante variados. Además diferencian el objetivos de sus análisis contando con pruebas para:

   - Usuarios privados, enlace aquí.
   - Empresas aquí.
   - Elementos IoT aquí.
   - Productos de seguridad en general aquí.

Incluso incluyen artículos y noticias que tratan de ayudar en temas de seguridad, por ejemplo esta noticia que hoy por hoy ayuda bastante sobre el teletrabajo: Trabajar en casa de forma segura o esta sobre las actualizaciones de software: Actualizaciones para mas seguridad.

Muy recomendable ver su atlas aquí. Es una plataforma inteligente que analiza amenazas, como correos electrónicos maliciosos, spam, malware, URLs sospechosas o peligrosas, etcétera. Cuenta con diferentes categorías y datos generales interesantes de conocer.

SaluDOS

lunes, 4 de mayo de 2020

osquery, la navaja suiza del sysadmin

La aplicación osquery es una de esas herramientas open source que cuando eres administrador de sistemas y la descubres, realmente te quedas sin palabras.

Digamos que es una herramienta que va a estar vigilando tu equipo, o los equipos de toda la red que administras o los servidores que tienes que sufrir. El escalado es muy potente, hasta llegar a miles y miles de activos en tu infraestructura.

Se puede instalar en tu propio equipo o en un servidor para controlar que es lo que está pasando en él, independientemente de la plataforma que tengas, está soportado para Windows, Mac OS y Linux. En su página web oficial hay gran cantidad de información, y la documentación es bastante extensa y la puedes consultar aquí.

Si nos centramos en una máquina linux, está soportado sobre bastantes tipos de distribuciones, por ejemplo para instalar en...

Arch y familia:
   # pacman -S osquery

ElementaryOS y familia debian:
   # apt-get install osquery

CentOS y familia Red Hat:
   # yum install osquery

Si lo queremos instalar en un equipo o servidor Windows, podemos ver el proceso aquí y también en la web de chocolatey aquí.

Vale, y que vigila, pues me atrevería a decir de forma atrevida que practicamente todo. Digamos que transforma tu sistema operativo en una base de datos en donde las tablas SQL representan conceptos abstractos como procesos en ejecución, módulos de kernel cargados, plugins de navegador, conexiones de red abiertas, eventos de hardware, etcétera.

Se ejecuta en modo demonio/servicio y se encarga de ir agregando los resultados de las consultas que realiza el programa sobre la máquina como registros de un motor SQLite.

Y ¿como consultamos los parámetros de nuestra maquina en este recolector de información?, pues con simples comandos SQL a través de su consola.

Una vez instalado podríamos arrancar el demonio y activarlo para futuros reinicios:

   # systemctl start osqueryd
   # systemctl enable osqueryd

Para lanzar la consola, ejecutariamos:

   # osqueryi

Y entramos en un shell propio, un CLI, sobre el que podemos lanzar las consultas de forma interactiva. Además es totalmente agnostico de plataforma, por lo que las consultas son genéricas y creo que es ahí donde reside su potencia cuando administras infraestructuras mixtas, tiene una buena adaptabilidad a los diferentes sistemas operativos.

Pongamos algunos ejemplos de comandos y esas consultas para entender como podríamos aprovecharnos de este software, comencemos sacando la ayuda:

   osquery> .help

Si queremos ver las tablas generadas:

   osquery> .tables

Si queremos podemos utilizar pragma table_info, nativo de SQLite, para conocer la información de una tabla concreta con los campos que contiene para poder construir sentencias SQL apropiadas, por ejemplo:

   osquery> pragma table_info('system_info');

Hay que tener en cuenta que dependiendo de la plataforma, habrá bastantes tablas comunes pero se generarán otras tablas especificas para el sistema operativo que está corriendo.

Ejemplos sencillos, genéricos y que se describen por si solos podrian ser:

   osquery> select * from uptime;
   osquery> select * from system_info;
   osquery> select * from os_version;
   osquery> select * from time;
   osquery> select * from crontab;
   osquery> select * from processes;
   osquery> select * from users;
   osquery> select * from kernel_modules;
   osquery> select * from etc_hosts;
   osquery> select * from interface_addresses;
   osquery> select * from routes;
   osquery> select * from process_open_files;
   osquery> select * from syslog_events;

Y ahora veamos ejemplos mas elaborados, algunos extraidos de esta web, para comprender la potencia de este punto único de encuentro para muchas preguntas que nos podemos hacer sobre un equipo, servidor o infraestructura completa.

Para saber cual es el hostname del equipo:

   osquery> select hostname from system_info;

Si por ejemplo queremos obtener información del procesador del sistema, podríamos lanzar algo así:

   osquery> select cpu_type, cpu_brand from system_info;

Si queremos saber como está el almacenamiento local en el punto de montaje raiz:

   osquery> select path, type, round((blocks_available * blocks_size *10e-10),2) as gigs_free from mounts where path='/';

Si queremos conocer los puertos que están a la escucha:

   osquery> select * from listening_ports;

Si queremos encontrar los procesos que están corriendo sobre el puerto 80:

   osquery> select pid from listening ports where port = 80;

Al tratarse de meras consultas SQL, podríamos llegar a generar joins de varias tablas por lo que la información se vuelve mas completa, por ejemplo al hilo de los dos comandos anteriores podemos unir procesos y puertos que están escuchando:

    osquery> select p.pid, p.name, p.state,p.uid, lp.port from processes p join listening_ports lp on p.pid = lp.pid and lp.port=80;
Y si nos vamos a un ejemplo mas trabajado, podríamos por ejemplo querer saber cuales es el top 10 de los procesos que están consumiendo mas CPU:

    osquery> select pid, uid, name, round(((user_time + system_time) / (cpu_time.tsb - cpu_time.itsb)) * 100, 2) as percentage from processes, (select (sum(user) + sum(nice) + sum(system) + sum(idle) * 1.0) as tsb, sum(coalesce(idle, 0)) + sum(coalesce(iowait, 0)) as itsb from cpu_time ) as cpu_time order by user_time+system_time desc limit 10;
Y podriamos hacer lo mismo con el top 10 de los procesos que ocupan mas memoria:

    osquery> select pid, name, round((total_size * '10e-7'), 2) as used from processes order by total_size desc limit 10;

Este ejemplo también es muy interesante, saber quien está logueado en nuestro sistema:

   osquery> select * from loggued_in_users;

Si queremos conocer cuales han sido los últimos inicios de sesión, no solo los actuales:

   osquery> select * from last;

Si queremos salir de la consola:

   osquery> .exit

Y por último, me parece interesante saber donde se encuentran los ficheros mas relevantes de osquery, tanto para distribuciones de la familia de centOS como de debian, estas serían las rutas por defecto:

   - Configuración: /etc/osquery/osquery.conf
   - Logs: /var/log/osquery
   - Binarios: /usr/bin
   - Packs: /usr/share/osquery/packs

Si te estás preguntando que son los packs, digamos que son conjuntos de consultas a modo de reglas para buscar información interesante o mas concreta.

En el caso de Windows todo debería de ir a la ruta: C:\Program Files\osquery

   - Configuración: C:\Program Files\osquery\osquery.conf
   - Logs: C:\Program Files\osquery\log
   - Binarios: C:\Program Files\osquery
   - Packs: C:\Program Files\osquery\packs

Una herramienta que si vemos su potencial instalado y ejecutado en local, imagínate si la despliegas en red y centralizas la información obtenida... Brutal!!!

SaluDOS

BlackArch, todas sus herramientas de seguridad al alcance de la mano

BlackArch es una distribución específica para temas de seguridad, hacking, pentesting, forense, etcétera. Se puede utilizar para investigar y montar laboratorios y realmente es una alternativa bastante buena a Kali Linux si eres mas de filosofía Arch.

Se puede descargar la imagen .iso desde su página web oficial aquí. Lo normal suele ser generar una máquina virtual o instalarlo en un pendrive para lanzarlo en modo liveCD. Una vez que lo estás ejecutando, siempre puedes instalarlo siguiendo estos dos simples pasos:

Primero instalamos el paquete con los scripts de instalación:

   # pacman -S blackarch-install-scripts
 
Una vez instalado este paquete, podrás seguir las instrucciones tras ejecutar:

   # blackarch-install
Antes de efectuar la instalación de Arch es interesante echar un vistazo a la web sobre blackarch-install aquí


En este mismo apartado de descargas de su página web, te explican como puedes llegar a instalarte las herramientas en tu propio equipo, si tienes una distribución basada en Arch linux. Veamos estos sencillos pasos, ya que es muy interesante si te dedicas a la seguridad informática, la descarga puede ser total, por categorías o por herramienta y esto da mucho juego.

Si quieres consultar las herramientas que ofrece, puedes consultarlo en el apartado Tools de su web oficial aquí.

Para empezar vamos a descargar el script strap.sh:


   # curl -O https://blackarch.org/strap.sh

Comprueba siempre el SHA1 para verificar que es el orginal y nada te ha inyectado otro script, la salida de este comando tendrá que coincidir con el SHA1 que nos muestran en la web:

   # sha1sum strap.sh

   Actualmente el valor es: 9c15f5d3d6f3f8ad63a6927ba78ed54f1a52176


Establecemos que se pueda ejecutar el script:

   # chmod +x strap.sh

Y lo ejecutamos:

   # ./strap.sh

En estos momentos ya tendremos configurados los repositorios de BlackArch, como habremos visto en mitad de la salida del script:

   [+] you can change the default mirror under /etc/pacman.d/blackarch-mirrorlist

Este dato es importante si tenemos que llegar a ajustar algo de los repositorios en algún momento. A partir de aqui ya podremos instalar las aplicaciones de BlackArch, veamos algunos ejemplos:

Si lo que queremos es obtener un listado de todas las herramientas disponibles podriamos ejecutar:

   # pacman -Sgg | grep blackarch | cut -d' ' -f2 | sort -u

Si las contamos concatenando con el comando wc veremos que hay, en estos momentos, 2563 herramientas. Ahí queda eso.

   # pacman -Sgg | grep blackarch | cut -d' ' -f2 | sort -u | wc -l


Si buscamos un programa concreto, por ejemplo bettercap, podríamos hacer:

   # pacman -Sgg | grep blackarch | cut -d' ' -f2 | sort -u | grep bettercap

Si buscamos el programa directamente, veremos que nos lo ofrecen los repositorios Community de Arch y también los de BlackArch:

   # pacman -Ss bettercap

Para instalar la herramienta que ofrecen los repositorios de BlackArch tendriamos que ejecutar especificando el repositorio:

   # pacman -S blackarch/bettercap

Si lo que queremos es instalar todas las herramientas, algo que creo que es una locura por la cantidad de ellas:

   # pacman -S blackarch

Podemos consultar las categorias existentes, normalmente cuando vamos a investigar o a hacer un pentesting es razonable buscar una categoría concreta:

   # pacman -Sg | grep blackarch

Y podriamos instalar una categoria concreta así:


   # pacman -S blackarch-<category>

Por ejemplo, para temas de IDS, podríamos instalar la categoría correspondiente:

   # pacman -S blackarch-ids

Y si antes quisieramos ver que contiene, podriamos consultar ese grupo concreto:

   # pacman -Sg blackarch-ids

Veriamos que actualmente contiene:

   blackarch-ids sagan
   blackarch-ids snort
   blackarch-ids suricata
   blackarch-ids suricata-verify

Algunas categorías no tienen mucha cosa, pero te invito a que pruebes con esta, veras que la lista de herramientas es extensa:

   # pacman -Sg blackarch-wireless

Como indican en la documentación oficial, a veces es necesario sobreescribir algunos paquetes o dependencias, por ello si obtenemos "failed to commit transaction" deberemos usar --needed y --overwrite como en el siguiente ejemplo:

    # sudo pacman -Syyu --needed blackarch --overwrite='*'

Si quieres profundizar en blackarch además de su página web oficial, te recomiendo su repositorio oficial en github aquí.

SaluDOS