msgbartop
Ph´nglui mglw´nafh Cthulhu R´lyeh wgah´nagl fhtagn
msgbarbottom

31 jul 20 Acceso a través de OpenVPN a equipos de la red local del servidor VPN

La configuración por defecto de OpenVPN permite acceder sólo al equipo servidor de VPN cuando estableces la conexión desde el cliente. Sin embargo, es posible extender el acceso al resto de equipos de la red local de dicho servidor, en caso de necesitar acceso a otras máquinas. La receta es la siguiente:

  • Configurar el servidor para que advierta al cliente de las rutas a las que puede acceder: Para que el cliente sepa que se puede conectar a más redes además de al propio servidor de VPN es preciso advertirle de ello. Se puede hacer fácilmente añadiendo la directiva “push” en el fichero de configuración del servidor. Para permitir acceso a una red de tipo 192.168.0.0/24, bastaría con lo siguiente: push “route 192.168.0.0 255.255.255.0″, y reiniciar el servicio.
  • Permitir que nuestro servidor haga forwarding de paquetes: Se habrá de modificar el fichero /etc/sysctl.conf, y quitar el comentario de la línea # net.ipv4.ip_forward=1. Posteriormente habrá que reiniciar el servicio con sudo sysctl -p.
  • Activar el enmascaramiento de paquetes en nuestro servidor: Este último paso va en función de nuestra arquitectura. Si nuestro servidor de OpenVPN no es la puerta de enlace por defecto de nuestra red, dado que las peticiones de los clientes OpenVPN llegarán al servidor de destino con una IP del tipo 10.8.0.x (o como sea que lo tengamos configurado en nuestro servidor OpenVPN), a la hora de responder a dichas peticiones, enviarán las respuestas a la puerta de enlace por defecto, con lo que se perderán las respuestas, ya que la puerta de enlace por defecto no tendrá constancia de la emisión de las mismas (enrutado asimétrico), y éstas no llegarán al cliente OpenVPN (este problema no se daría con el servidor OpenVPN actuando como puerta de enlace, ya que tendría constancia de los paquetes, y podría enrutarlos adecuadamente). Para evitar el problema, es posible activar el enmascaramiento de paquetes. Bastaría con añadir la siguiente regla a nuestro iptables: iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE… siempre que la interfaz de la red sea la eth0, y que nuestra red de clientes OpenVPN sea la 10.8.0.0/24 (si no, hay que modificar estos valores según correspondan). Para hacer que la configuración sea persistente, recomiendo usar el servicio iptables-persistent, existente en Debian y otras distribuciones.

Referencias:

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , ,

06 jul 19 Hacking lab sobre Modbus TCP. Elementos configurados

Esta entrada es la parte 2 de 4 de la serie Hacking Lab Modbus TCP

En el artículo anterior se hacía referencia al objeto del hacking lab y se daba una visión general de la arquitectura implementada. En este artículo se va a entrar en un mayor detalle de los elementos que forman parte de dicha arquitectura: HMI, PLC, actuador TCP y plataforma de ataque.

HMI de control de luces LED
El HMI de control simula un sistema SCADA. Está implementado mediante Node-Red, sistema software que permite la programación basada en flujos para desarrollar sistemas para Internet de las Cosas. A fin de poder realizar la implementación del sistema de control industrial, se ha hecho uso de las siguientes librerías:

  • Modbus,que permite implementar un sistema de comunicación basado en Modbus TCP y Modbus Serie.
  • Dashboard, que permite crear cuadros de mandos y aplicaciones web para interactuar con los flujos de control.

El sistema desarrollado consta de dos partes:

  • El cuadro de mandos es una simple botonera que permite encender la iluminación LED rojo, verde y azul mediante interruptores individuales. Estos interruptores, al actuar sobre ellos, envían una señal MODBUS TCP al PLC simulado, para cambiar el estado de la bobina que corresponda a cada color, y muestra el resultado final del mismo en pantalla.
  • Captura de la interfaz de control

    Captura de la interfaz de control

  • La lógica de interacción del HMI con el PLC se ha desarrollado para leer cada 500 ms el estado de las 3 bobinas del PLC, y desplegar en la botonera el estado de las mismas. Si el usuario cambia uno de los interruptores, el sistema envía al PLC mediante MODBUS sobre TCP una orden para escribir un cambio de estado en la bobina correspondiente. El flujo de control corresponde al siguiente diagrama:
  • Flujo de control HMI-PLC

    Flujo de control HMI-PLC

PLC de control de luces
El PLC que actúa como Master MODBUS se ha desarrollado igualmente haciendo uso de Node-Red con la librería MODBUS. En este caso se ha implementado la funcionalidad de Master Modbus, escuchando en el puerto 1502/TCP (frente al habitual 502/TCP por razones de permisos) de la Raspberry Pi que despliega los servicios de Node-Red.

PLC simulado con Raspberry Pi

PLC simulado con Raspberry Pi

El flujo Node-Red definido es el siguiente:

Flujo Modbus TCP del PLC simulado

Flujo Modbus TCP del PLC simulado

Este flujo realiza dos funciones: la primera es levantar el servidor Master MODBUS, que escucha en la IP 192.168.0.39 por el puerto 1502/TCP. La segunda inyecta los valores por defecto en las 3 bobinas (posiciones de memoria 1 a 3) que se han definido para almacenar los valores de la iluminación LED RGB. En este caso, las tres bobinas se inicializan a cero (FALSE lógico).

Actuador TCP
El actuador TCP se ha implementado como un esclavo Modbus que consulta al PLC el estado de las tres bobinas que controlan el estado de los LED RGB. En función de la lectura realizada del valor de dichas bobinas, enciende o apaga la iluminación LED. Al ser tres las bobinas implementadas, la iluminación puede tomar un máximo de 8 valores combinados (considerando “apagado” como uno de los estados posibles).
La implementación del actuador se ha realizado mediante un dispositivo NodeMCU, que permite su programación mediante el IDE Arduino, con capacidades de conectarse a una red WiFi. Se ha hecho uso de la librería Modbus-Arduino para la implementación del cliente.

Actuador desarrollado con NodeMCU

Actuador desarrollado con NodeMCU

Actuador con iluminación en azul

Actuador con iluminación en azul


Actuador con iluminación en rojo

Actuador con iluminación en rojo

Kali Linux
Para simular la intrusión de un atacante externo se ha hecho uso de una Raspberry Pi con la distribución Kali Linux instalada. Kali Linux es una distribución de Linux especialmente pensada para servir de herramienta para realizar tests de intrusión en el ámbito del hacking ético y auditorías de seguridad de sistems de información.

Se ha realizado el siguiente flujo de ataque:

  1. Reconocimiento: Mediante ingeniería social (fuera del laboratorio) se ha determinado la existencia de un sistema de iluminación LED basado en Modbus.
  2. Escaneo: Una vez conseguido un equipo en la red, se ha procedido a un escaneo de la red en busca del dispositivos que escuchen en el puerto Modbus(habitualmente 502/TCP, pero para este caso se ha hecho uso de 1502/TCP) con ZenMap, cliente gráfico para NMAP.
  3. Ganar acceso: Una vez identificado el equipo Master Modbus, se ha realizado un proceso de escucha mediante modbus-cli, una herramienta desarrollada en Ruby disponible para Kali, que permite escanear y escribir sobre sistemas MODBUS. En una primera fase se ha escuchado hasta determinar las bobinas que controlan el sistema de iluminación, y en una segunda fase, se han realizado cambios sobre la misma.
  4. Para el laboratorio no se han realizado el resto de fases del hacking (mantener acceso ni borrar huellas).

En el siguiente artículo se detallarán los resultados obtenidos en el laboratorio.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , ,

08 jun 13 Copia de seguridad y compresión de tarjetas SD en Linux

Hoy traigo un mini-tutorial de cómo hacer imágenes comprimidas de memorias externas (SD, USB…) en Linux.
Para crear las imágenes:

dd if=/dev/sdX | gzip -9 > /ruta/a/backup.img.gz

…siendo sdX el dispositivo a clonar.

Para restaurar las imágenes:

gzip -dc ruta/a/backup.img.gz | dd of=/dev/sdX

…siendo iguamente sdX donde restaurar la imagen.

Pero si queremos ser creativos, podemos hacer esto mismo, enviado las imágenes a un tercer servidor:

dd bs=1M if=/dev/sdX | ssh user@host ‘gzip -9 > /ruta_remota/a/backup.img.gz’

…algo sumamente útil si, por ejemplo, estamos haciendo diabluras con una Raspberry Pi y contamos -obviamente- con poco espacio en el sistema local.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , ,

13 oct 09 Monitorizar el uso de memoria en linux en tiempo real

Algunas veces es necesario realizar monitorizaciones en tiempo real del uso de memoria en linux, y nuestro viejo amigo top se queda algo escaso. En realidad, la mejor manera de ver el uso de memoria en un sistema linux es leer el fichero /proc/meminfo. Lo malo es que esto sólo nos proporciona una imagen estática del sistema. Para solucionar este inconveniente, podemos hacer uso del comando watch. Este programa nos lanza el comando que le indiquemos de manera periódica. Por ello, si ejecutamos la siguiente línea de comandos:

$ watch -d 'cat /proc/meminfo'

…podremos ver cada dos segundos los cambios en el fichero /proc/meminfo, con las diferencias producidas remarcadas (opción “-d”). Gracias a Strato_cuervo por darme la pista.

He encontrado también una entrada muy interesante de cómo crear gráficas de uso de memoria en linux: Gráficos del uso de memoria en Linux A esta entrada ya le dedicaremos más tiempo otro día.

Por cierto, agradecería recomendaciones de manera eficientes de medir el uso de recursos en linux… con lo que pueda venir en una instalación por defecto en una máquina convencional. Nunca se sabe cuándo tienes que monitorizar una máquina instalada en el año del poncio…

VN:F [1.9.20_1166]
Rating: 10.0/10 (3 votes cast)

Etiquetas: , , ,

15 jun 09 Streaming de webcam para monitorización remota

Una de las grandes ventajas de los sistemas linux es su flexibilidad: permiten desde realizar instalaciones estándar de escritorio hasta realizar instalaciones de grandes servidores de procesos de datos. Hoy voy a hablar de una posibilidad que permiten: realizar un sistema de monitorización remota mediante webcam. Esta aplicación respondería al siguiente esquema:

  • Una estación remota, con un sistema linux básico con una instalación en modo consola, y una webcam añadida. Idealmente este equipo debería ser de pequeño formato, como un Pico-ITX, pero cualquier equipo sería válido. Con una instalación básica de consola sería más que suficiente.
  • Un equipo de escritorio, dedicado a la monitorización. Este equipo, en desde el que se va a realizar el control de la estación remota, requeriría disponer de un entorno gráfico, a discreción del usuario

El sistema operativo, obviamente, tendría que ser linux. Cualquier distribución valdría, pero por mis preferencias personales he de recomendar Debian, una magnífica distribución con la flexibilidad suficiente como para permitir una sencilla instalación de estos dos entornos tan diferentes.

La piedra angular de esta instalación es el programa netcat, la navaja suiza de los administradores de sistemas. Esta herramienta tiene como principal característica es su capacidad para abrir puertos TCP/IP y redireccionar flujos de datos del sistema operativo por ellos. También tiene una función trascendental los túneles SSH, que permiten enlazar puertos en una máquina remota (a la que se realiza la conexión SSH) con otra máquina que esté en la red local del sistema cliente (esto también incluye, obviamente, la propia máquina cliente).

Otra suposición de la que partimos es que el cliente y el servidor NO se encuentran en la misma red local, sino que se encuentran en redes separadas, ya sea porque hay algún elemento como un cortafuegos interpuesto, o bien porque se encuentran enlazadas por una red WAN. En cualquier caso, algo impide impide que se pueda acceder a cualquier puerto entre el cliente y el servidor, estando limitado a accesos por puertos bien conocidos, como SSH.

En primer lugar, habría que configurar el sistema operativo del servidor para que reconozca la webcam. Esta tarea queda fuera de este mini-tutorial, por lo que me remito a internet para realizar esta labor. Sin embargo, en un sistema linux reciente, tendría que ser más que suficiente con instalar Video For Linux 2, ya que los módulos necesarios suelen venir por defecto en el kernel. Esto debería provocar que la webcam, al ser conectada al servidor, haga aparecer el dispositivo /dev/video0 (o algo por el estilo).

Una vez hecho esto, la idea en el servidor es la siguiente: recoger el flujo de datos de la webcam a través del dispositivo correspondiente (/dev/video0,o el que corresponda), y mediante netcat, abrir un puerto (por ejemplo, el 2000) y dirigir el flujo de datos anterior a este puerto, que estará preparado para recibir conexiones. Esto se haría mediante el siguiente comando:

$ cat /dev/video0 | nc -l -p 2000

Por otro lado, en el cliente, habría que realizar la siguiente operación: realizar un túnel SSH al servidor, de tal manera que se enlace el puerto que hemos abierto en el servidor (en este caso, el 2000) con un puerto en la máquina cliente (en este caso, el 270001). A continuación, con netcat se recoge el flujo de datos del puerto 27001; por último, mediante un pipe, se recoge la salida del comando anterior (que sería mostrada por la salida estándar) hacia un programa de visualización de vídeo adecuado, como mplayer o xine. La sucesión de comandos sería la siguiente:

ssh -f -L 27001:127.0.0.1:2000 usuario@servidor sleep 10; nc 127.0.0.1 27001 | xine -

Un cutre-esquema de lo expuesto anteriormente sería el siguiente:

Diagrama de la instalación

Diagrama de la instalación

Con toda esta película conseguiríamos visualizar desde el equipo cliente la webcam del servidor.

Una pequeña variación de lo anterior permite, por otro lado, hacer streaming de ficheros de vídeo (o audio). Con el siguiente comando abriríamos el puerto local 2000 para accesos desde un servidor remoto, que leerían del fichero video.avi:

nc -l -p 2000 < video.avi

Por la parte del cliente seguiríamos usando el comando anterior.

Existen algunos corolarios a este mini-tutorial. Uno de ellos consistiría en lograr que el acceso al servidor sea sin contraseña, basándonos en el uso de certificados de usuario. Pero eso ya quedará para otro día.

VN:F [1.9.20_1166]
Rating: 5.0/10 (1 vote cast)

Etiquetas: , , , , , ,