msgbartop
Cordobés por tierra, hidalgo por mar, hidalgo por el diablo
msgbarbottom

05 nov 20 Configuración de un módem 3G/4G/HSDPA en Armbian mediante una SIM de Pepephone

Estoy trabajando en un proyecto IoT que implica el que un dispositivo ARM (en mi caso, una Orange Pi Zero) sea capaz de tener conectividad a Internet en un entorno aislado, sin WiFi o conexión cableada. Para ello, la mejor manera que he encontrado es dotar al mismo de una conexión 3G/4G mediante una tarjeta SIM de un operador de telefonía. En mi caso, Pepephone. A diferencia de otros dispositivos que disponen de un lector de tarjetas SIM, la Orange Pi Zero no dispone del mismo, para lo cual es preciso hacer uso de un módem USB. He utilizado un modelo genérico, un HSDPA 3G que se puede encontrar por unos pocos euros en Aliexpress. Estos dispositivos vienen de casa con los drivers necesarios para hacerlos funcionar en diversas versiones de Windows, pero no cuentan con soporte oficial para Linux. Sin embargo, no es complicado hacerlos funcionar. A continuación detallo los pasos para ello.

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

En primer lugar, estoy haciendo uso de una Orange Pi Zero con sistema operativo Armbian. En el momento en que escribo esto la versión publicada, y que estoy utilizando, es la 20.08.1, versión de kernel 5.8.5. Sobre esta versión del sistema operativo, para hacer funcionar el módem USB, hay que instalar dos aplicaciones:

  • USB_ModeSwitch: Permite que el sistema operativo reconozca el módem USB como tal, y no como un dispositivo de almacenamiento génerico por USB. El mismo se puede instalar en el caso de Debian en general, y Armbian en particular, desde los repositorios oficiales.
  • Wvdial: Utilidad para realizar la conexión a Internet mediante módem, que levanta una interfaz de red ppp (Diox, ni años que no creaba interfaces de red de este tipo). Tiene la ventaja de que se configura y ejecuta completamente desde línea de comandos, por lo que no es necesario entorno gráfico.

USB_ModeSwitch

La configuración de USB_ModeSwitch no tiene misterio. Dado que la aplicación está recogida en los repositorios oficiales de Debian, basta con instalar los dos paquetes correspondientes (usb-modeswitch y usb-modeswitch-data) utilizando apt. En función del dispositivo del que hagas uso, con esto debería bastar para que tu módem USB sea reconocido, pero a veces las cosas se complican un poco. Como en mi caso. :mrgreen: El dispositivo que yo uso se identifica a sí mismo inicialmente como un dispositivo de almacenamiento masivo. Al hacer un lsusb aparece identificado de la siguiente manera: Bus 003 Device 011: ID 05c6:1000 Qualcomm, Inc. Mass Storage Device. Es necesario trastear un poco para que se muestre en el sistema como un módem USB. Para ello:

  • Asegurarse de tener instalada la tarjeta SIM. Sin ella, el dispositivo nunca se mostrará como un módem.
  • Comprobar que el dispositivo pasa a identificarse como un módem con el comando /usr/sbin/usb_modeswitch -W -v 05c6 -p 1000 -K. Si pasa a identificarse con algo similar a esto, Bus 003 Device 002: ID 05c6:6000 Qualcomm, Inc. Siemens SG75, vas por buen camino.
  • Alcanzado este punto, se puede automatizar este cambio mediante la creación de un fichero con nombre 05c6:1000 en el directorio /etc/usb_modeswitch.d. El fichero debe contener lo siguiente:

    TargetVendor=0x05c6
    TargetProduct=0x6000
    StandardEject=1

Con esta configuración, Armbian pasará a configurar de manera correcta el módem, y estará listo para ser utilizado por la aplicación de marcado.

Wvdial

Ya con el módem USB correctamente reconocido por el sistema, es necesario configurar una aplicación de marcado, que permita levantar una interfaz de red en el sistema. En mi caso, he optado por utilizar wvdial. Los pasos para configurarla son los siguientes:

  • Instalar wvdial: wvdial se encuentra en los repositorios oficiales, por lo que se puede instalar con un simple apt install wvdial.
  • Tras instalarla, utilizaremos la aplicación wvdialconf, que tratará de reconocer y configurar de manera automática el módem USB. Si hemos seguido correctamente los pasos anteriores de USB_ModeSwitch, no tendríamos que tener problema alguno. Tras la finalización de la aplicación, ésta nos habrá generado el fichero de configuración /etc/wvdial.conf, con los parámetros genéricos de conexión del módem. La configuración que se genera por defecto para el HSDPA es la siguiente:

    [Dialer Defaults]
    Init1 = ATZ
    Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    Modem Type = Analog Modem
    Phone =
    ISDN = 0
    Password = "password"
    New PPPD = yes
    Username = "username"
    Modem = /dev/ttyUSB0
    Baud = 9600

  • Es necesario adaptar estos parámetros a tu operador para poder establecer la conexión. En mi caso, estoy utilizando Pepephone. Tras algunas pruebas, di con una configuración que funciona correctamente:

    [Dialer Defaults]
    Init1 = ATE1
    Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    Modem Type = Analog Modem
    Phone = *99#
    ISDN = 0
    Password = "pepephone"
    New PPPD = yes
    Username = "pepephone"
    Modem = /dev/ttyUSB0
    Baud = 9600

    Dial Command = ATDT
    Stupid Mode = 1
    Auto Reconnect = on
    Init3 = AT+CFUN=1
    Init4 = AT+CGATT=1
    Init5 = AT+CGDCONT=1,"IP","internet","",0,0

  • Por último, una vez guardado el fichero, se puede lanzar la conexión tan sólo ejecutando el comando wvdial

…y con esto quedará levantada la conexión ppp0, como la siguiente:

ppp0: flags=4305 mtu 1500
inet 10.118.75.xx netmask 255.255.255.255 destination 10.64.64.xx
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 125 bytes 9030 (8.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 122 bytes 9001 (8.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Como punto de configuración adicional, es conveniente automatizar la creación de la interfaz. Aunque idealmente podría hacerse con la siguiente configuración en /etc/network/interfaces:

auto ppp0
iface ppp0 inet wvdial

…pero he observado que no funciona demasiado bien tras un reinicio. Sospecho que es porque se intenta configurar la interfaz ppp0 cuando USB_ModeSwitch aún no ha completado la transición de dispositivo de almacenamiento masivo a módem USB. En mi caso, y para no complicarme, he optado por prescindir de la configuración anterior, y en su lugar he añadido el comando wvdial al fichero /etc/rc.local, resolviendo de esta manera el problema. No es tan elegante, pero funciona.

Editado

Un pequeño complemento: dado que por sí sola no se añade la ruta por defecto para que el tráfico de red salga por el módem USB, se puede añadir de manera automática mediante un script. Basta con crear un script ejecutable bajo la ruta /etc/ppp/ip-up.d/ con un contenido como este:

#!/bin/sh
ip route add default dev ppp0
exit 0

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

Etiquetas: , , , , , , , , ,

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 (2 votes 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: , , ,