Drivers ATI en GNU/Linux

Mitos sexuales desmentidos II

La masturbación masculina y la ceguera

Otro mito falso que aún se sigue contando, afortunadamente cada vez en menos medidas. ¡Qué ocurrencias!

Historia de Xenix

(Microsoft Xenix). Xenix es un antiguo y obsoleto sistema operativo tipo UNIX desarrollado por Microsoft, que lo adquirió de AT&T. Finalmente sus derechos fueron adquiridos por Santa Cruz Operation y lanzado bajo el nombre de SCO UNIX.

Microsoft compró una licencia de la versión 7 del sistema operativo Unix de la empresa AT&T (el UNIX System V) en 1979, y le puso de nombre Xenix. La empresa anunció el 25 de agosto de 1980 que este sistema estaría disponible para microcomputadoras de 16 bits, pero no tuvo mucho éxito.

Microsoft no vendía Xenix directamente a los usuarios finales, sino que licenciaba como OEM a empresas como Intel, Tandy, Altos y SCO, quienes lo portaban a sus respectivas arquitecturas de computadora. Por ejemplo, Xenix recién estuvo disponible para la arquitectura Intel 8086/8088 cuando la empresa The Santa Cruz Operation (SCO) lo portó así.

El Microsoft Xenix original sólo se ejecutaba en computadoras PDP-11, luego se portó hacia el procesador Zilog Z8001 de 16 bits. En tanto, la empresa Altos lo portó para sus computadoras Intel 8086 a principios de 1982. En tanto Tandy lo portó para sus sistemas basados en el Motorola 68000 con el nombre de TRS-XENIX a principios de 1983; mientras que SCO lo portó a la IBM PC en septiembre de 1983. También hubo una versión para las Apple Lisa basadas en 68000.

En 1985 fue lanzada la versión 2.0 de Xenix, basada en el UNIX System V. La actualización a la versión 2.1.1 agregó soporte para los procesadores Intel 80286. Los siguientes lanzamientos mejoraron la compatibilidad con el System V.

Para 1986, la empresa SCO portó Xenix a los procesadores 386 de 32 bits. La versión 2.3.1 introdujo soporte para procesadores i386, SCSI y TCP/IP.

El sistema Xenix System 5/386 de SCO fue el primer sistema operativo de 32 bits disponible en el mercado para las computadoras de arquitectura x86. SCO renombró Xenix bajo el nombre de SCO UNIX en 1989. Su precio de mercado era de 1200 dólares americanos y venía en una gran caja con 40 disquetes de 5.25 pulgadas. Requería como mínimo de 1 MB de RAM.

Mientras tanto, AT&T y Sun Microsystems fusionaron los sistemas Xenix, BSD, SunOS y System V dando lugar al System V Release 4.

Para finales de los 80, probablemente fue la versión de UNIX más extendida del momento, de acuerdo a la cantidad de máquinas que lo ejecutaban (según The Design and Implementation of the 4.3BSD UNIX Operating System).

Microsoft perdió el interés por desarrollar el sistema Xenix cuando logró un acuerdo con IBM para desarrollar el sistema OS/2; transfirió Xenix a SCO y en el acuerdo se quedó con un 25% de la empresa.

Microsoft siguió utilizando Xenix internamente en estaciones de trabajo Sun y en minicomputadors VAX hasta finales de 1992. Siguió utilizando Xenix 68000 hasta 1993 para el transporte de sus e-mails internos.

La última versión de Xenix fue la 2.3.4 lanzada en 1989.

Que te diviertas!

Knock, knock, knockin’ on server’s ports – Port knocking con ejemplos

¿Qué es el port knocking?

Imagina que en mi servidor tengo activo un servicio privado, al que no quiero que nadie acceda, sólo yo. Por ejemplo, puede ser un sistema de administración remota, monitorización, logs, rescate, o simplemente cosas que no quiero que sean públicas. Y, claro, cuanto más tiempo esté un servicio expuesto a Internet, más probabilidades de ser vulnerado.
Por ejemplo, si tenemos un servidor SSH corriendo, normalmente veremos el puerto 22 abierto, y cualquiera que nos haga un scan de puertos podrá verlo (¿quién va a querer hacerme un scan de puertos?):

nmap servidor.com
Starting Nmap 7.01 ( https://servidor.com ) at 2017-08-01 00:24 CEST
Nmap scan report for totaki.com (123.231.32.132)
Host is up (0.055s latency).
rDNS record for 123.231.32.132: servidor.com
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https

 

Está bien, una de las formas de ocultar un servidor SSH es cambiar el puerto, y entonces un análisis rápido no lo verá. De todas formas es un puerto abierto y, tarde o temprano, esas cosas salen a la luz. Así que si abres tu puerto 753 como servidor SSH, cualquiera se podrá conectar a él y basta hacer un netcat al puerto y ver cómo se presenta:

nc -t servidor_oculto.com 753
SSH-2.0-OpenSSH_6.7p1

 

¡Listo! Sabemos que es un SSH, vamos a atacar, intentando identificarnos como los usuarios típicos: root, admin y demás, ¡Y conocemos la versión! Con lo malo que es eso para mantener un sistema medianamente seguro. Aunque bueno, aquí tienes una guía para endurecer un servidor SSH y hacerlo más seguro. No obstante, también podríamos tener un servicio corriendo que fuera algo más inseguro con una autentificación algo más floja.

Así que vamos a hacer un sistema de cerradura, como los de las cajas fuertes de las películas, en los que tenemos que girar la rueda varias veces siguiendo una combinación hasta que la podemos abrir o como cuando llamamos a la puerta con una combinación de golpes y esperas perfecta para que sepan que somos nosotros. De hecho port knocking lo podemos traducir como golpeo de puertos, es decir, intentaremos conectar con varios puertos y, el firewall de nuestro servidor mágicamente nos reconocerá y nos abrirá el puerto sólo para nosotros y así poder conectarnos.

Entonces, imaginemos que mi combinación es 1111, 3333, 2222 (lo pongo así para que veamos que no es necesario que los números de puerto estén ordenados), para abrir el puerto 22 de SSH necesitaré hacer intentos de conexión a los puertos 1111, 3333 y 2222. Estos puertos están cerrados, por lo que no conectarán, y el servidor parece que pasa de nosotros porque no hace nada, pero, tras los intentos de acceso a dichos puertos, podremos establecer una conexión con el puerto 22.

¿Podemos considerarnos paranoicos con este sistema de seguridad? Puede, y a muchos sysadmins les encanta. Al menos nos proporciona ocultación de los servicios críticos, así como de sus protocolos. Aunque, como todo, tiene sus riesgos.
No estoy inventando nada

Antes de continuar, tengo que decir que esta técnica es muy antigua. En junio de 2003, Martin Krzywinski publicó en Sys Admin Magazine un artículo bautizando de paso a esta técnica con un nombre chulo. Pero claro, eso no quiere decir que no se hubiera hecho antes.

Beneficios de esta técnica
Incluyo algunos puntos (no todos) que vienen en el artículo original de Krzywinski:

• Lo principal es que es un método de autentificación silencioso. Como dije antes, el sistema parece que pasa de ti. Además, los puertos a los que accederemos están previamente cerrados, por lo que con un escaneo de puertos no sabremos los puertos que hay que golpear, y mucho menos el orden.
• Si encima disponemos de un sistema que detecte y bloquee los escaneos de puertos, podríamos evitar que si nuestra clave de golpeo es de tres puertos, pudieran acceder al sistema tras hacer 3 escaneos. Además de que podríamos configurar el tiempo entre golpeos por lo que si tardas mucho en golpear tienes que empezar de nuevo. Aunque algunas implementaciones modernas de esta técnica pueden también evitar que un escaneo cuente como knock (hará knock cuando llegue al puerto deseado pero invalidará el knock cuando pruebe el siguiente puerto).
• No tenemos que cambiar nada en el software servidor que escucha en el puerto que vamos a abrir. Es más, esta configuración es totalmente independiente.
• Elimina entradas en los logs de sistema. ¡Cuántas líneas logea el demonio SSH con intentos de acceso! Con este sistema, la mayoría de intentos de acceso a un servidor SSH no llegarán a afectarnos lo más mínimo. El puerto del servicio está cerrado así que el propio firewall se deshará de todos.

Desventajas e inconvenientes

• No es conveniente proteger puertos como el 80 (http) o el 25 (smtp), porque los clientes no se van a poner a hacer el proceso de knocking cada vez que quieran algo de esos servidores. Esto está pensado para servicios que deben ser privados.
• Si tenemos servicios abiertos al público en el mismo servidor. Alguien podría utilizar un problema, bug, puerta trasera, etc. para entrar en el servidor y podría echar por tierra la seguridad que queremos tener con los servicios privados. Esto no es específicamente de la técnica, es un problema general de todos los sysadmins.
• Tenemos que tener cuidado con los servicios de automatización del firewall. Yo utilizaré iptables, así que si utilizamos UFW o APF, puede que éstos no se lleven bien y tendremos que trabajar un poco más para que todo funcione en sintonía.
• Es algo más que debemos mantener. Tanto si lo hacemos con scripts de iptables como si lo hacemos con un demonio. Como administradores del sistema tendremos que asegurarnos de que el sistema está vivo y no falla. Sólo imagina que si el sistema que controla el port knocking falla, nos quedaremos sin acceso al servicio que hemos ocultado.
• Tenemos una contraseña para abrir el puerto. Podríamos hacer un script que haga el knocking automáticamente, y ese script nos lo querremos llevar con nosotros a cualquier lado. Y ya estamos liberando información privada si lo subimos a un servidor o lo anotamos, etc.
• Si muchos usuarios tienen la clave del knocking e intentan acceder al servidor, la información temporal que tiene que almacenar el firewall puede crecer mucho. No es preocupante si es un gran servidor, pero la memoria se evapora.
• Este método permite la entrada a la IP que haga el juego completo de knocks. Es decir, si estamos haciéndolo a una máquina en Internet y varias personas compartimos conexión cualquiera en nuestra red local podría entrar. Eso también podría ser una ventaja… según se mire.

Ejemplo con iptables
Entonces, lo que queremos es que nuestro servidor tenga el puerto 22 (ssh) cerrado (tomo el 22, pero podría ser cualquier otro). Y cuando intente conectar con los puertos 1111, 3333 y 2222, puertos que están cerrados y los intentos de conexión no harán nada, veremos el puerto 22 abierto para poder conectar por SSH. Así que vamos a definir los diferentes estados por los que pasará mi sistema:

Estado     Descripción
Inicial     Configuración básica del firewall
WAITING     Esperando golpeos. Desde este estado repartimos los paquetes entrantes a los demás estados
KNOCK1     Entra el primer toque
KNOCK2     Entra el segundo toque
KNOCK3     Entra el tercer toque
ACCESSGRANTED     Esperando conexión con el puerto abierto

También vamos a suponer que tenemos un servidor web instalado, por lo que el puerto 80 deberá estar abierto (en la práctica deberíamos también abrir el 443). Si tienes otro firewall o un script de firewall, tal vez esto tengas que solucionarlo ahí.

Crearemos los estados en iptables:

iptables -N WAITING
iptables -N KNOCK1
iptables -N KNOCK2
iptables -N KNOCK3
iptables -N ACCESSGRANTED
 

Esto es lo que vamos a hacer lo siguiente en el servidor.
¿Qué haremos con el tráfico normal del servidor?

Asumo que el servidor SSH ya está instalado y funcionando.
Es decir, vamos a definir las directivas del tráfico que aceptará nuestro servidor (lo que empieza por # se ejecutará como root directamente. Si no somos root, tal vez podríamos usar sudo).

Lo primero que hacemos es aceptar todo el tráfico entrante y saliente (INPUT y OUTPUT, algunos también necesitaréis activar FORWARD), seguidamente con -F limpiamos las reglas de iptables hasta el momento (cuidado si tienes firewalls ya).

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F


La siguiente línea hace que las conexiones ya establecidas sigan su curso. Es decir, tanto las conexiones al servidor web como las conexiones que ya tenemos establecidas en el puerto 22, que no tengan ningún problema para continuar.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

 

Lo siguiente es aceptar todo lo que venga de localhost. Normalmente podemos tener varios servicios en la misma máquina que conectan con ellos mismos, y son todos privados, por lo que éstos no tienen que tener impedimentos.

iptables -A INPUT -i lo -j ACCEPT


Con estas líneas, rechazamos los paquetes ICMP, por ejemplo el PING. Esto no es esencial, pero muchos lo hacen, y desde aquí quiero demostrar que podemos hacer que ciertas conexiones continúen o al contrario, que se detengan.
Como hacemos en la siguiente línea, que es aceptar todo lo que provenga del puerto 80 tcp. Es decir, nuestro servidor web.

iptables -A INPUT -p icmp -j DROP
iptables -A INPUT -p tcp –dport 80 -j ACCEPT

Todas las conexiones que hayan llegado hasta aquí, las vamos a pasar al estado WAITING

iptables -A INPUT -j WAITING

 

Configuramos los estados knockX y AccessGranted
Estos estados “knock” también pueden ser considerados puertas, como si un usuario tuviera que pasarlas todas para ver la libertad. Éstos serán KNOCK1, KNOCK2, KNOCK3. Empezamos por el primer intento. Estamos esperando un knock al puerto tcp 1111, conexión que tenemos que tirar porque ahí no hay servicio y no queremos que el puerto figure como cerrado. Eso sí, vamos a ponerle un flag “PASSED1” para que cuando entre el siguiente paquete sepa que tiene que este paso ya está hecho y entre directamente en KNOCK2.
La primera línea sólo nos sirve para enviar un log (que podemos ver con dmesg. El ejemplo de dmesg está al final del post).
En la tercera línea me encargo de tirar todos los demás paquetes que vengan. Sin flag ni nada, esos no han pasado la prueba.

En este post hablo de poner un flag a la IP, para indicar que se ha pasado la prueba. En realidad, iptables lo que hace es meter una IP en una lista. Al final estamos hablando de lo mismo, pero de forma más eficiente. En lugar de crear un texto que diga PASSED1 asociado a una IP, lo que hacemos es crear una lista llamada PASSED1 y meter ahí la IP, el momento en el que entró el último paquete y alguna información más. Si queremos, podemos ver el contenido de las listas haciendo:


cat /proc/net/xt_recent/PASSED1
src=12.124.229.34 ttl: 51 last_seen: 4306420264 oldest_pkt: 1 4306420264
src=21.123.219.55 ttl: 51 last_seen: 4306420224 oldest_pkt: 1 4306420224


iptables -A KNOCK1 -j LOG --log-level 4 --log-prefix “Knock 1: ”
iptables -A KNOCK1 -p tcp --dport 1111 -m recent --name PASSED1 --set -j DROP
iptables -A KNOCK1 -j DROP
 

Vamos, al KNOCK2, al que entraremos cuando recibamos el segundo knock. Éste será parecido al primero, sólo que antes de nada tendremos que borrar el flag PASSED1. Esto lo hacemos para que cuando un usuario haga mal el golpeo, es decir, después del 1111, golpee el 5555 y luego el 3333 ya no cuente, así si hacen varios escaneos que no bloqueamos el usuario no entrará. Por lo demás, hacemos que cuando se acceda al puerto 3333 pongamos la etiqueta “PASSED2” para que, como antes, cuando llegue un paquete nuevo al estado WAITING, éste sepa que tendrá que ir directamente al estado KNOCK3 porque KNOCK2 ya lo ha pasado y además, el paquete lo tiramos, porque en el puerto 3333 no hay nada. Por lo demás, saltaremos al estado KNOCK1 para ver si la conexión pasa el primer toque.

iptables -A KNOCK2 -m recent --name PASSED1 --remove
iptables -A KNOCK2 -j LOG --log-level 4 --log-prefix “Knock 2: ”
iptables -A KNOCK2 -p tcp --dport 3333 -m recent --name PASSED2 --set -j DROP
iptables -A KNOCK2 -j KNOCK1

 

Este estado sí que es mucho más parecido al anterior y, con esto, ya nos da una pista para que nuestro sistema pueda tener tres, cuatro o cinco knocks. Cuantos más knocks, más difícil será entrar, será un modo más paranoico, y nuestro firewall será más complicado (recordad que esto requerirá un mantenimiento y, si hay muchos usuarios que quieren entrar, todo será más complicado). Lo único que cambian son los números. Es decir, en el estado KNOCK3 entramos porque el flag PASSED2 está activo (es decir, hemos superado el paso2 y por eso estamos en knock3), luego logeamos diciendo que estamos en knock3 y si alguien intenta conectar por el puerto 2222, colocaremos el flag PASSED3. Sencillo, ¿no?

iptables -A KNOCK3 -m recent --name PASSED2 --remove
iptables -A KNOCK3 -j LOG --log-level 4 --log-prefix “Knock 3: ”
iptables -A KNOCK3 -p tcp --dport 2222 -m recent --name PASSED3 --set -j DROP
iptables -A KNOCK3 -j KNOCK1


Y... una vez superados los tres knocks, es decir, la conexión tiene el flag PASSED3, el acceso ya está permitido y ahora aceptaremos las conexiones al puerto 22.

iptables -A ACCESSGRANTED -m recent --name PASSED3 --remove
iptables -A ACCESSGRANTED -j LOG --log-level 4 --log-prefix “Access Granted: ”
iptables -A ACCESSGRANTED -p tcp --dport 22 -j ACCEPT
iptables -A ACCESSGRANTED -j KNOCK1


Colocando cada paquete en su estado
Una vez que tenemos los estados KNOCKX y ACCESSGRANTED configurados, necesitamos que el estado WAITING, que será al estado que saltemos cuando llega un nuevo paquete (y éste ha sido previamente filtrado), reparta los paquetes que lleguen entre los diferentes estados en función de los flags que hemos ido definiendo. Es decir:

Si no tenemos flags, saltamos a KNOCK1, porque tal vez sea una conexión con el puerto 1111, si no lo es, no haremos nada.
Si la IP tiene el flag PASSED1, saltaremos a KNOCK2 y esperaremos el segundo toque.
Si la IP tiene el flag PASSED2, saltaremos a KNOCK3 y esperaremos el tercer toque.
Si la IP tiene el flag PASSED3, saltaremos a ACCESSGRANTED y esperaremos una conexión por el puerto 22.


Además, desde aquí podemos asignar tiempos. Es decir, si la IP tiene el flag PASSED1 y además han pasado menos de 10 segundos desde que entró en la lista, entramos a KNOCK2. Con esto limitamos el tiempo que tiene el usuario para poder completar cada paso y entrar en el sistema.

iptables -A WAITING -m recent --rcheck --seconds 30 --name PASSED3 -j ACCESSGRANTED
iptables -A WAITING -m recent --rcheck --seconds 10 --name PASSED2 -j KNOCK3
iptables -A WAITING -m recent --rcheck --seconds 10 --name PASSED1 -j KNOCK2



Todo el tráfico restante, lo mandamos a KNOCK1
iptables -A WAITING -j KNOCK1


El script completo
A mí me encanta poder copiar y pegar de las webs, al menos para probar las cosas de un tirón. Así que, pongo el script completo aquí.


#!/bin/bash

# Creamos objetivos de iptables
iptables -N WAITING
iptables -N KNOCK1
iptables -N KNOCK2
iptables -N KNOCK3
iptables -N ACCESSGRANTED

# Establecemos una política básica de permisos
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
# Ignoramos ping, bueno, paquetes ICMP en general. Sólo para probar, mejor será que se lo dejemos a nuestro firewall que tendrá mejores reglas para esto.
iptables -A INPUT -p icmp -j DROP
# Aceptamos conexiones por el puerto 80
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# Todos los paquetes que hayan llegado hasta aquí, saltarán a WAITING
iptables -A INPUT -j WAITING

### Estado KNOCK1 - En espera del primer golpe
iptables -A KNOCK1 -j LOG --log-level 4 --log-prefix "Knock 1: "
iptables -A KNOCK1 -p tcp --dport 1111 -m recent --name PASSED1 --set -j DROP
iptables -A KNOCK1 -j DROP

### Estado KNOCK2 - A la caza del segundo golpe
iptables -A KNOCK2 -m recent --name PASSED1 --remove
iptables -A KNOCK2 -j LOG --log-level 4 --log-prefix "Knock 2: "
iptables -A KNOCK2 -p tcp --dport 3333 -m recent --name PASSED2 --set -j DROP
iptables -A KNOCK2 -j KNOCK1

### Estado KNOCK3 - El último paso hacia la libertad
iptables -A KNOCK3 -m recent --name PASSED2 --remove
iptables -A KNOCK3 -j LOG --log-level 4 --log-prefix "Knock 3: "
iptables -A KNOCK3 -p tcp --dport 2222 -m recent --name PASSED3 --set -j DROP
iptables -A KNOCK3 -j KNOCK1

### Estado ACCESSGRANTED - Tenemos acceso al puerto 22
iptables -A ACCESSGRANTED -m recent --name PASSED3 --remove
iptables -A ACCESSGRANTED -j LOG --log-level 4 --log-prefix "Access Granted: "
iptables -A ACCESSGRANTED -p tcp --dport 22 -j ACCEPT
iptables -A ACCESSGRANTED -j KNOCK1

# Ahora establecemos las políticas por las que entramos en cada estado
iptables -A WAITING -m recent --rcheck --seconds 30 --name PASSED3 -j ACCESSGRANTED
iptables -A WAITING -m recent --rcheck --seconds 10 --name PASSED2 -j KNOCK3
iptables -A WAITING -m recent --rcheck --seconds 10 --name PASSED1 -j KNOCK2
iptables -A WAITING -j KNOCK1


Cómo hacer el golpeo de puertos
En el lado del cliente, en nuestro ordenador, sólo tendríamos que intentar acceder a los puertos, con el programa que queramos, incluso con un navegador web si queremos (puede ser muy lento). Eso sí, como los puertos no tienen ningún servicio y cuando intentamos establecer una conexión parece que el servidor nos ignora tendremos que tener muy en cuenta los timeouts. Es decir, tenemos que poner un timeout pequeño, por ejemplo de un segundo o menos. Eso sí, la conexión con el servidor debe ser más o menos buena para que los paquetes lleguen en un tiempo razonable. Así que podríamos intentarlo incluso con curl:


curl -m 1 http://servidor.com:1111
curl: (28) Connection timed out after 1001 milliseconds
curl -m 1 http://servidor.com:3333
curl: (28) Connection timed out after 1001 milliseconds
curl -m 1 http://servidor.com:2222
curl: (28) Connection timed out after 1001 milliseconds
ssh usuario@servidor.com
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)
...

 

Aunque, ya puestos, intentémoslo con netcat, que será más sencillo:

nc -w 1 servidor.com 1111
nc -w 1 servidor.com 3333
nc -w 1 servidor.com 2222
ssh usuario@servidor.com
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)
...

 

Y también con el mismo nmap, desactivando el ping al host:

nmap -Pn --host_timeout 500 --max-retries 0 -p 1111 servidor.com
nmap -Pn --host_timeout 500 --max-retries 0 -p 3333 servidor.com
nmap -Pn --host_timeout 500 --max-retries 0 -p 2222 servidor.com
ssh usuario@servidor.com
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)
...


Por si fuera poco, lo podemos automatizar con un pequeño bucle en una sola línea de nuestro shell favorito:

for port in 1111 3333 2222; do nc -w 1 servidor.com $port; done
ssh usuario@servidor.com
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-83-generic x86_64)
...
 

Utilizando un demonio (knockd)
Aunque existen varios sistemas, uno de los demonios que más me ha convencido, y más utilizado para estas cosas es knockd. El problema de tener un demonio corriendo es que si el demonio se cae estamos perdidos… ¡pero perdidos de verdad! Porque no vamos a poder entrar en nuestro servidor. Hay proveedores, como por ejemplo DigitalOcean que te permiten acceder a través de web a tu servidor sin necesidad de SSH aunque en ocasiones esto debe estar prohibido por exigencia de nuestros clientes o de normativas de seguridad.

De todas formas, el hecho de utilizar un demonio muy conocido y muy antiguo para eso (la primera versión es de 2004) es que está muy probado y podemos considerarlo estable. Además está hecho en C, por lo que la huella en memoria y la CPU utilizada serán ínfimas (que esté hecho en C no tiene nada que ver, podemos hacer programas muy poco eficientes, pero programarlo en python, por ejemplo ralentizaría mucho el sistema en caso de que entren muchas conexiones a la vez); y utiliza la biblioteca pcap, que también es muy robusta y está muy probada.

Cabe comentar que el uso del demonio facilita muchísimo la tarea de implementar el port knocking, ya que es mucho más intuitivo y no hay que andar pensando en los estados de los diferentes paquetes ni preocuparse en exceso por los firewalls. Además, como el resultado final es la ejecución de un comando, es decir, el programa detecta los knocks y en consecuencia ejecuta una orden, podemos personalizar dicha orden para que sea lo más amigable posible con nuestro firewall o script controlador o si, por ejemplo, queremos o necesitamos logear este tipo de actividad, no sólo haciendo caso al propio log de knockd.

Para esta guía he utilizado una Debian, de todas formas en otra distribución no debería ser muy complicado instalarlo y configurarlo (los ficheros de configuración serán iguales).


sudo apt-get install knockd

Lo primero es editar el archivo /etc/default/knockd, en el que debemos poner a 1 START_KNOCKD y en KNOCKD_OPTS definir el interfaz de red sobre el que nos vamos a centrar. En mi caso, eth0. Por lo que el archivo quedaría así:

    ################################################
    #
    # knockd’s default file, for generic sys config
    #
    ################################################

    # control if we start knockd at init or not
    # 1 = start
    # anything else = don’t start
    #
    # PLEASE EDIT /etc/knockd.conf BEFORE ENABLING
    START_KNOCKD=1

    # command line options
    KNOCKD_OPTS=”-i eth0″

 

Seguidamente, editamos /etc/knockd.conf, vamos a hacer algunos cambios en el fichero para hacer las cosas más fáciles:

    [options]
    UseSyslog

    [openSSH]
    sequence = 1111,3333,2222
    seq_timeout = 5
    command = /sbin/iptables -I INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
    tcpflags = syn

    [closeSSH]
    sequence = 3333,2222,1111
    seq_timeout = 5
    command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
    tcpflags = syn
 

Ahora, configuramos iptables, en mi caso, aunque podríamos hacerlo perfectamente desde nuestro firewall o script de firewall siempre y cuando adaptemos bien las reglas. Sería una configuración parecida a la configuración inicial anterior en la que aceptamos los paquetes de las conexiones ya establecidas, aceptamos los paquetes que vienen de localhost y lo que venga del puerto 80, si queremos. Eso sí, en lugar de enviar los paquetes enviados a WAITING, directamente los tiramos (drop).


iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP


En este caso, knockd será el que controle si se están haciendo los knocks y la forma de entrar en el servidor será muy parecida. Eso sí, con esta configuración necesitamos hacer los knocks a los puertos 1111, 3333, 2222 para abrir el puerto 22 y luego 3333, 2222, 1111 para cerrarlo. El puerto se mantendrá abierto hasta que lo cerremos. Por un lado está bien, porque no tendremos que repetir los knocks para abrir otra sesión (por ejemplo si queremos abrir dos sesiones), pero por otro… personalmente soy muy despistado y se me puede olvidar cerrar el puerto.

Knockd por tiempo, como hacíamos con iptables
Como soy muy despistado, con knockd también podemos replicar el comportamiento anterior de iptables, es decir, el puerto se abrirá durante un tiempo y se cerrará automáticamente. Para eso, entraremos en el archivio /etc/knockd.conf y pondremos lo siguiente:

    [options]
    UseSyslog

    [opencloseSSH]
    sequence = 1111, 3333, 2222
    seq_timeout = 15
    tcpflags = syn
    start_command = /usr/sbin/iptables -I INPUT -s %IP% -p tcp –syn –dport 22 -j ACCEPT
    cmd_timeout = 10
    stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp –syn –dport 22 -j ACCEPT
 

De esta manera con nuestra secuencia de puertos de antes se abrirá el puerto 22 por unos segundos y luego se cerrará pasados unos segundos. Y también tenemos un log de todo esto, tanto en el ejemplo anterior como en este podremos ver en el syslog (/var/log/syslog) lo siguiente:

    Aug 3 12:43:06 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 1
    Jul 30 12:43:07 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 2
    Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 3
    Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: OPEN SESAME
    Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: openSSH: running command: /sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp –dport 22 -j ACCEPT

Y listo. Ya tenemos la puerta abierta. Lo bueno de este demonio es que podemos configurar varios locks y los servicios que queramos en cada uno de ellos o incluso… enviar mensajes a los servidores utilizando los knocks, los start_command y stop_command pueden, perfectamente, ser scripts que hagan cualquier cosa y no sólo abrir o cerrar puertos.

Secuencias de knock preconfiguradas
¡El comportamiento más peliculero de knockd! Vamos, contraseñas de knock que van cambiando cada vez que se abren o se cierran las puertas. Imagina que vamos a utilizar varias secuencias para abrir un puerto, así que vamos a crear un fichero /etc/ssh_knock_seq que contenga lo siguiente:

    1111,3333,2222
    1111,2222,3333,
    1234,5678,9101,
    1213,1415,1617

 

Es muy importante el espacio al principio de la línea, ya que knockd escribirá un # en el primer carácter de cada secuencia que vaya utilizando (por eficiencia, es mucho más rápido cambiar un carácter que insertarlo, ya que implica un desplazamiento de todos los contenidos), por lo que perderíamos el primer número si no ponemos un espacio.

Ahora, en /etc/knockd.conf hacemos lo siguiente:

    [options]
    UseSyslog

    [openSSH]
    one_time_sequences = /etc/ssh_knock_seq
    seq_timeout = 5
    command = /sbin/iptables -I INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
    tcpflags = syn


La primera vez que hagamos la secuencia de knocks debemos hacerla a los puertos 1111, 3333 y 2222; la segunda vez a los puertos 1111, 2222 y 3333 y así sucesivamente. Lo bueno es que las secuencias cambian, así que si alguien está sniffando el tráfico de red y vea que estás hacieno knocks a puertos e intente hacer lo mismo después, no le va a servir porque la secuencia ha cambiado. Lo malo es que si hay más de un administrador del sistema que tiene que entrar, es un poco rollo saber por qué combinación vamos.

Complicando un poco los knocks
Este cliente, al funcionar capturando el tráfico de la red, puede ver directamente los paquetes TCP que se envían, y podemos reaccionar ante diferentes flags del paquete: syn, ack, fin, rst… Para no entrar en mucha profundidad, normalmente cuando se inicia una conexión TCP. Un cliente envía SYN al servidor, y el servidor responde SYN-ACK, luego el cliente le responde ACK, cuando alguien corta la comunicación le dice al otro FIN, para reiniciar la conexión se envía RST y, bueno, hay algunos más. El caso es que normalmente cuando hacemos knocks enviamos un SYN, pero, ¿y si hacemos que el servidor requiera knocks con ACK? Es raro, más paranoico y enrevesado, además puede requerir privilegios de administración en los clientes y no sé yo si a muchos firewalls les gustará que les mandes un ACK sin conocer de nada al host con el que hables (el SYN solo es como un saludo). Pero bueno, podemos decirle a knockd en tcpflags que escuche solo a ACK o a FIN y sólo reaccionará ante esos estímulos. Está muy chulo para probar.

Para hacer los knocks, recomiendo la herramienta hping3 que podemos utilizarla así:

hping3 -c 1 -A miservidor.com -p 1111
hping3 -c 1 -A miservidor.com -p 3333
hping3 -c 1 -A miservidor.com -p 2222
 

Y, por supuesto, podemos utilizarla en un script como el de antes.


Envío de knocks con cliente
knockd proporciona un cliente llamado knock (sin la d) con el que podemos enviar los knocks todos seguidos y sin scripts como hacíamos antes:

knock miservidor.com 1111 3333 2222


Anexos
Algunas cosas que no tienen mucho que ver, pero ayudan a comprenderlo todo.

Ejemplo de dmesg
El kernel está todo el rato escribiendo mensajes con lo que sucede. Y el caso de iptables, ya que actúa en el kernel no es menos. Cuando desde iptables enviamos al log un mensaje podremos consultarlo haciendo:

iptables | tail

 

Con tail sacamos las últimas líneas del buffer de mensajes del kernel, porque suele ser muy largo y seguramente algo que sucedió hace mucho tiempo no nos interesa.
De todas formas, las fechas y horas están expresadas en el tiempo transcurrido tras el arranque de la máquina y no es un formato muy agradable porque usa números muy largos. Podemos expresarlo en formato humano con este post o con el argumento -T. Aunque a mí me gusta mucho la salida producida por:

dmesg -HTxL

 

Que escribe los mensajes de manera legible y nos deja hacer búsquedas (como less), el tiempo en formato humano, nos da información sobre el tipo de mensaje y encima lo muestra en colores.

Ejemplo de iptables centrado en interfaz
No voy a extenderme mucho, pero si queremos que una regla de iptables se aplique a los paquetes que viajan por una interfaz de red determinada debemos incluir “-i [interfaz]”. Al final se quedaría algo así:


iptables -A KNOCK1 -i eth0 -p tcp --dport 1111 -m recent --name PASSED1 --set -j DROP
ACCEPT, REJECT y DROP

 

Está claro que ACCEPT directamente acepta el paquete y si va para alguna aplicación, ésta lo recibe y lo procesa. Vamos, el uso normal. Pero cuando especificamos REJECT, estamos rechazando el paquete, y para rechazarlo tenemos que responder algo. DROP, en cambio ignora el paquete, lo tira en saco roto y que se pierda en la inmensidad de la red.
Es como cuando mantienes una conversación con alguien, si aceptas su mensaje haces algo al respecto. Te dicen “Hola” y respondes: “Buenos días, ¿cómo estás?”. Si rechazas los mensajes (reject), te dicen “Hola” y contestas: “¡No hablo contigo!” y pones carita de enfado. Eso implica un esfuerzo, intención de contestar y en general gasto de recursos. Pero si ignoras a alguien, te dirán “Hola” y no contestas, pero tú estás a lo tuyo, lo mismo has movido un poco la oreja o has girado ligeramente la cabeza cuando lo has escuchado, pero tu “amigo” ya puede esperar tu respuesta, que lo hará hasta que se cumpla su timeout.

Basado en: http://totaki.com/poesiabinaria/2017/08/knock-knock-knockin-on-servers-ports-port-knocking-ejemplos/

Amar y Querer

—Te amo —le dijo el Principito.
—Yo también te quiero —respondió la rosa.
—Pero no es lo mismo —respondió él, y luego continuó— Querer es tomar posesión de algo, de alguien. Es buscar en los demás eso que llena las expectativas personales de afecto, de compañía. Querer es hacer nuestro lo que no nos pertenece, es adueñarnos o desear algo para completarnos, porque en algún punto nos reconocemos carentes.

Reflexiòn

Las personas se sienten perturbadas no por las cosas, sino por los puntos de vista que adoptan sobre éstas.
Epíteto, siglo I a. C.

Matambre casero arrollado

Todo un clasico si los hay, porteño como pocos, muy facil de hacer y el acompañante clasico y tradicional de fiestas y picadas. Lleva algo de tiempo prepararlo y cocinarlo, pero realmente vale la pena realizar todo ese trabajo.

Ingredientes:

• Matambre de Novillo 1
• Huevos 1-2
• Huevos duros 4-6
• Zanahorias grandes 2-3
• Morron Rojo 1-2
• Queso rallado 1 pocillo
• Aji Molido 1 cucharada
• Pan Rallado 1 taza (puede ser salvado de avena)
• Oregano 1 cucharada
• Ajo 3-5 dientes
• Verduras para caldo (o un cubito de caldo de verduras)
• Jugo de limon c.n.
• Pimenton dulce (opcional)
• Tomillo (opcional)
• Nueces picadas (opcional)
• Sal y Pimienta c.n.
• Agua c.n.
• Aceite de Oliva c.n.

Estirar el Matambre, y reservando la grasa desgrasarlo,  y ponerlo sobre la mesada con la parte de la grasa hacia arriba y mezclarlo con Oregano, Ajo, Aji Molido, Aceite de Oliva, jugo de Limon, Sal y Pimienta a gusto.

Dejar macerar bien enrollado un dia completo en heladera. Puede ser envuelto en film de cocina.

Mezclar el Huevo, el Queso Rallado, Aji Molido, Oregano, Ajo, Sal y Pimienta a gusto, batiendolos.

Si el Matambre tiene una forma rara, con el cuchillo le damos un poco mas de prolijidad, los pedazos que cortamos van dentro del matambre mismo, como relleno, nada se tira.

Con el huevos batido cubrir la carne, sin llegar a los extremos, distribuyendo las Zanahorias peladas en tiras gruesas y el Morron en tiras finitas, los huevos duros en cuartos y espolvorear con queso rallado mezclado con el Pan Rallado.

Enrollar el matambre bien apretado, empezando por el lado mas angosto.

Coser el matambre con hilo de algodon (el famoso "hilo matambrero", o el humilde piolin si no lo conseguis) y atarlo muy fuerte para que conserve bien la forma.

Envolverlo en un lienzo (o film de cocina si no tenes) y cocinarlo en una cacerola con agua, la grasa reservada, las verduras y sal gruesa, primero con fuego bien fuerte, y cuando rompe el hervor bajamos el fuego, tapamos la cacerola y lo dejamos un minimo dos horas y media, cubriendolo totalmente del caldo siempre. Controlar el nivel y que siempre hierva. Lo ideal es dejarlo cuatro horas, y si lo envolvimos en film de cocina, despues de dos horas podemos pinchar con tenedor para ver como esta y que se desgrase un poco tambien, pinchando los globos que se forman.

Opcional: Envolverlo en papel de ALU con la parte brillante "para dentro", en vez de un lienzo, y cocinarlo en horno, en fuente alta y controlando siempre el nivel del liquido (tipo un dedo acostado), con horno bajo por un minimo de tres o cuatro horas, con cebollas en rodajas y papas cortadas en dos alrededor, ademas de la grasa reservada y las verduras con sal gruesa (Es mi forma preferida, mantiene todos los jugos y queda mucho mejor que solamente hervido).

Dejar enfriar en el propio liquido de coccion, es muy importante esto, minimo una hora.

Escurrir bien el matambre sobre una placa, dejandolo un tiempo y poniendole un peso importante encima, o mejor aun, dentro de una "prensa para matambres". El fin es sacarle los restos de agua y darle una mejor presentacion.

Despues llevar a la heladera, sin la prensa obviamente, envuelto en papel de ALU de cocina, minimo seis horas.

Para servir, quitar los hilos y el lienzo, y cortarlo en rodajas de tipo un centimetro de ancho y maridar con un tinto de generoso cuerpo, compartiendo entre amigos.

Que te diviertas!

Usa La Fuerza...

El primer satélite de comunicación cuántica chino envía datos a la Tierra

El primer satélite de comunicación cuántica que China puso en el espacio hace un año logró enviar con éxito datos a la tierra, sentando las bases para construir una red global de comunicación cuántica, informaron hoy fuentes oficiales.

La agencia oficial de noticias Xinhua explicó que el QUESS, siglas en inglés de "Experimentos con Cuantos a Escala Espacial", ha operado con éxito y que sus resultados han sido publicados en la revista académica Nature.

Los científicos chinos se han convertido en los primeros en realizar la distribución de claves cuánticas hasta la tierra desde un satélite, después de que en agosto del año pasado fuera enviado desde el centro de lanzamiento espacial de Jiuquan, en el desierto de Gobi (noroeste de China), a una altitud de 500 kilómetros.

La comunicación cuántica está basada en cambios de estado de partículas subatómicas como los fotones y en la práctica podría tener dos grandes usos: un sistema de transmisión de datos más rápido que los actuales e imposible de interceptar y, más remoto y complicado, la teleportación.

EEUU, Europa o Japón ya han experimentado con comunicación cuántica en superficie, pero China, que también ha comenzado a desarrollar una red de transmisión de este tipo entre Pekín y Shanghái, es el primero que lleva la investigación al espacio.

El equipo científico chino que desarrolla estos experimentos está dirigido por el físico cuántico Pan Jianwei quien explicó que el satélite envió claves cuánticas a las estaciones terrestres en Xinglong (Hebei, norte de China) y Nanshan (Xinjiang).

La distancia de comunicación entre el satélite y la estación terrestre varía de 645 kilómetros a 1.200 kilómetros y la velocidad de transmisión de la clave cuántica es de hasta 20 órdenes de magnitud más eficiente que la experimentada usando una fibra óptica de la misma longitud.
Diez minutos

Cuando el satélite vuela sobre China proporciona una ventana del experimento de cerca de 10 minutos. Durante ese tiempo, la clave segura de 300 kbit puede ser generada y enviada por el satélite, según explicó Pan.

"Eso, por ejemplo, puede satisfacer la demanda de hacer una llamada telefónica segura absoluta o transmitir una gran cantidad de datos bancarios", agregó.

"La distribución de claves cuánticas basada en los satélites puede vincularse a las redes cuánticas metropolitanas" y servir para "conectar a numerosos usuarios dentro de una ciudad de más de 100 kilómetros", agregó el científico.

Los científicos esperan que las comunicaciones cuánticas cambien fundamentalmente el desarrollo humano en las próximas dos o tres décadas, ya que hay enormes perspectivas para aplicar esta nueva generación de comunicación en campos como la defensa o las finanzas.

Asnos estúpidos - Isaac Asimov

Naron, de la longeva raza rigeliana, era el cuarto de su estirpe que llevaba los anales galácticos. Tenía en su poder el gran libro que contenía la lista de las numerosas razas de todas las galaxias que habían adquirido el don de la inteligencia, y el libro, mucho menor, en el que figuraban las que habían llegado a la madurez y poseían méritos para formar parte de la Federación Galáctica. En el primer libro habían tachado algunos nombres anotados con anterioridad: los de las razas que, por el motivo que fuere, habían fracasado. La mala fortuna, las deficiencias bioquímicas o biofísicas, la falta de adaptación social se cobraban su tributo. Sin embargo, en el libro pequeño nunca se había tenido que tachar ninguno de los nombres anotados.

En aquel momento, Naron, enormemente corpulento e increíblemente anciano, levantó la vista al notar que se acercaba un mensajero.

-Naron -saludó el mensajero-. ¡Gran Señor!
-Bueno, bueno, ¿qué hay? Menos ceremonias.
-Otro grupo de organismos ha llegado a la madurez.
-Estupendo, estupendo. Hoy en día ascienden muy aprisa. Apenas pasa año sin que llegue un grupo nuevo. ¿Quiénes son?

El mensajero dio el número clave de la galaxia y las coordenadas del mundo en cuestión.

-Ah, sí -dijo Naron-, Lo conozco. -Y con buena letra cursiva anotó el dato en el primer libro, trasladando luego el nombre del planeta al segundo. Utilizaba, como de costumbre, el nombre bajo el cual era conocido el planeta por la fracción más numerosa de sus propios habitantes.

Escribió, pues: La Tierra.

-Estas criaturas nuevas -dijo luego- han establecido un récord. Ningún otro grupo ha pasado tan rápidamente de la inteligencia a la madurez. No será una equivocación, espero.
-De ningún modo, señor -respondió el mensajero.
-Han llegado al conocimiento de la energía termonuclear, ¿no es cierto?
-Sí, señor.
-Bien, ése es el requisito -Naron soltó una risita-. Sus naves sondearán pronto el espacio y se pondrán en contacto con la Federación.
-En realidad, señor -dijo el mensajero con renuencia-, los observadores nos comunican que todavía no han penetrado en el espacio.

Naron se quedó atónito.

-¿Ni poco ni mucho? ¿No tienen siquiera una estación espacial?
-Todavía no, señor.
-Pero si poseen la energía termonuclear, ¿dónde realizan las pruebas y las explosiones?
-En su propio planeta, señor.

Naron se irguió en sus seis metros de estatura y tronó:

-¿En su propio planeta?
-Si, señor.

Con gesto pausado, Naron sacó la pluma y tachó con una raya la última anotación en el libro pequeño. Era un hecho sin precedentes; pero es que Naron era muy sabio y capaz de ver lo inevitable, como nadie, en la galaxia.

-¡Asnos estúpidos! -murmuró.

Apaga la tele...

Vichyssoise (Sopa crema de esparragos fria)

Tradicional sopa al estilo "de nuestras abuelas", realizada de la manera clasica, digamos que yo no uso "sal rosa del Himalaya", "Crema de Almendras", "Leche de Arroz", tofu o pelotudeces similares para cocinar, sino lo que podes encontrar en casi cualquier hogar:

Ingredientes:

• 4 Puerros grandes (Ajo Porro)
• 1 Cebolla grande picada
• 50g de Manteca
• 3 Papas grandes peladas (1 Kg aprox)
• Cebolla de verdeo (Ciboulette)
• Perejil C/N
• 1L Caldo de Carne (o Vino blanco seco)
• 300 cc de Crema de Leche
• Aceite de Oliva C/N
• Sal C/N
• Pimienta C/N
• Agua C/N

Preparacion:
Preparar el litro de Caldo de Carne previamente, y no dejar enfriar mucho. Si, eso de los cubitos, con toda la Ciencia que ello conlleva. Yo prefiero usar Vino Blanco para esta receta, pero son gustos...
Calentar en olla mediana la Manteca, agregar el Puerro picado fino (solo la parte blanca), la Cebolla y las Papas en rodajas finitas, o cubos chiquitos. Revolver bien, que no se pegue ni se nos queme. Antes de que comiencen a dorarse, agregar el Caldo de Carne caliente y dejar hervir, tipo, cubriendo todo con un dedo de liquido. Completar con agua de ser necesario. Cocinar 20 minutos (o con fuego muy bajo durante 40 minutos en caso de usar Vino Blanco), y procesar junto con un chorro generoso de Aceite de Oliva hasta obtener una crema pareja y homogenea.
Agregar la Crema de Leche, Sal y Pimienta. Mezclar y dejar enfriar en la heladera, en un bol de vidrio (evitando el metal) tapado con film para evitar "otros gustos", en lo posible varias horas.

Servir bien fria en tazones de consomé, con un poco de Cebolla de verdeo y Perejil fresco espolvoreado encima. Acompañar preferentemente con Tostadas de Pan al Ajo y unas Berenjenas al Escabeche caseras, o una vez ya fria se puede congelar en porciones indivuduales si lo preferimos asi, para poderlo disfrutar en otro momento.
Disfrutar con abundante vino tinto acompañado entre amigos.

Que lo disfrutes!

SystemD es una mala historia de terror

Porque sostengo hace tiempo que SystemD es una reverenda mierda y no quiero adoptarlo en mis servidores GNU/Linux, y siguiendo con mi aclamada serie "SystemD y la puta madre que lo parió a el y al deficiente mental de Lennart Poettering" con sus estrafalarios errores y pelotudeces varias.

systemd da privilegios de root si el nombre de usuario comienza en un dígito

systemd can't handle the process previlege that belongs to user name startswith number, such as 0day #6237

Si un servicio se lanza con un nombre de usuario que comience con un dígito (por ejemplo "0day"), systemd no puede gestionar correctamente los privilegios y lo lanza como root.

Cabe destacar que estos son nombres de usuario válidos según el estándar POSIX.

El comentario de Lenny al respecto: "I don't think there's anything to fix in systemd here".

¿Ven el patrón de comportamiento? Esto es lo que ocurre cuando se mezcla NIH con arrogancia.

Pero lo más grotesco es ésto:

"0day no es un nombre de usuario válido". Por Dios, todas las brechas de seguridad en la historia de la seguridad informática se basan en entradas inválidas. ¿Si el nombre de usuario es invalido le doy acceso root? Por favor, acaso el mundo se está volviendo loco!? Imaginen la alarma de una casa, si la clave es inválida te dejo pasar. O una caja fuerte, si código no es válido entonces te abro la caja. Esta persona demuestra un nivel de ignorancia atroz en cuestiones de seguridad informática y es el responsable principal del desarrollo de la pieza de software más crítica en userland.

remote code execution con una respuesta DNS especialmente armada

USN-3341-1: Systemd vulnerability

Esto no tiene nada de bizarro, es un bug muy grave y con consecuencias catastróficas. Nada más y nada menos que remote code execution, esto es, poder ejecutar código arbitrario en el sistema víctima, la peor de las consecuencias ante una falla de seguridad. Sin contar con que en el menor de los casos puede provocar DoS (denial of service). El bug es provocado por systemd-resolved. ¿Por qué reimplementar dnsmasq? ¿Por qué reimplementar algo que funciona perfectamente desde hace décadas? ¿Por qué reimplementar cualquier cosa de manera tan pobre?

systemd se cuelga al setear una variable de entorno

systemd can be frozen by setting an environment variable and reexecuting after that #6152

Setear una variable de entorno y reejecutar el demonio, hace que se "freeze". ¿De qué forma una variable de entorno aleatoria puede hacer que un proceso no inicie o se congele? Y esto ocurre al tratar de "reiniciar" systemd: systemctl daemon-reexec. Estamos hablando de PID 1. ¿Ven lo que pasa cuando se jode con PID 1?

El cliente DHCP de systemd no es capaz de renovar un lease

[systemd-devel] Renew DHCP lease

Renovar un lease de DHCP debería ser una funcionalidad básica de un cliente DHCP.

Respuesta de Lenny: "This is currently not implemented."

Funcionalidades básicas no implementadas. Claramente se trata de una versión pre-alpha llevada a producción y liberada al público. Y hablando de funcionalidades no implementadas...

networkd no soporta direcciones IPv4 con máscara 31

networkd: support for /31 IPv4 addresses (rfc3021)

Este bug lleva casi un año abierto. Las direcciones IPv4 con máscara 31 (definidas en la RFC3021 de diciembre de 2000) son utilizadas comúnmente en enlaces punto a punto (point-to-point). Con máscara 31, una subred sólo puede contar con 2 direcciones IP. Al suprimir las direcciones de red y broadcast, cada una de las 2 posibles IP se utiliza como la dirección de cada uno de los puntos en el enlace. systemd desconoce esta característica del protocolo IP porque claramente es un "sistema de inicio" para notebooks.

Basado en: https://www.linuxito.com/seguridad/915-nuevos-bugs-bizarros-y-peligrosos-de-systemd

Pruebas

XI Foro de Seguridad Informatica en Carlos Casares

Hasta los crayones te insultan

Etica Hacker vs Hacking Etico

Dos terminos aparentemente contrapuestos, usados e interpretados a gusto personal. En los foros de la ONION han evolucionado y se han convertido en caballos de batalla para unos y otros. Pero ¿que hay realmente detras de ellos?

 Practicamente todos los usuarios de la onion usan el termino Hacking en su acepcion negativa que la ha impuesto la prensa y el cine de masas.

Cuando se da un robo de datos a una oficina estatal o se obtienen las tarjetas de credito de personas inocentes, los criminales hablan de carding o incluso van mas alla y muy orgullosamente se autodefinen como Hackers.

Es curioso comprobar que la mayoria ni siquiera ha visitado la wikipedia para conocer y enterarse un poco sobre los origenes y la definicion socialmente aceptada del propio termino. Si la montaña no va a Mahoma, entonces sera tarea de este ir a visitarla.

"El término hacker tiene diferentes significados. Según el diccionario de los hackers, «es todo individuo que se dedica a programar de forma entusiasta, o sea un experto entusiasta de cualquier tipo», que considera que poner la información al alcance de todos constituye un extraordinario bien. De acuerdo a Eric S. Raymond el motivo principal que tienen estas personas para crear software en su tiempo libre, y después distribuirlos de manera gratuita, es el de ser reconocidos por sus iguales. El término hacker nace en la segunda mitad del siglo XX y su origen está ligado con los clubes y laboratorios del MIT.

En español, se recomienda diferenciar claramente entre hacker y cracker, ya que, si bien ambos son expertos en colarse en sistemas, el segundo lo hace con propósitos ilícitos. Además, el uso del término hacker no se limita a la seguridad informática. También se ha propuesto la posibilidad de usar estos dos términos adaptados al español como háker —se pronuncia como hache aspirada como en el original, no como jota— y cráker."

Y al parecer muchos usuarios utilizan la palabra Haker cuando en realidad quieren decir/pensar/utilizar Craker.

Ahora bien, ¿como pudo darse tal distorsion para que se termine usando "Hacking Etico", cuando en realidad deberian usar el termino "Craking Etico"? Incluso en este ultimo, ya de por si contiene una contradiccion, ¿como puede ser etico practicar el craking?.

Para muchos, los hakers (o mejor dicho crakers) tienen una etica algo "especial", pues supone que entre ellos, debe mostrarse respeto y colaboracion. Esta regla casi siempre termina siendo violada, cuando cualquiera de ellos demuestra ignorancia sobre cualquier cosa, ya que inmediatamente los otros, los "verdaderos hakers", deben saberlo todo y por lo mismo, el interpelado ya no es digno de respeto, sino que es visto como otra potencial victima, la cual debe incluso ser castigada por osar a "creerse otro igual, un haker".

Otro aspecto contradictorio de estos crakers, es la venta de sus conocimientos. Ellos exigen "pagar por conocer las tecnicas de carding o hacking", ya que la experiencia y los conocimientos no se regalan... muy propio de los mafiosos. ¿Y que es lo contradictorio en ello? Muy simple, si el respeto y la colaboracion se da solo entre iguales, ¿como puedo esperar lo mismo si solo soy un candidato a llamarme haker? ¿puedo esperar a que no se me estafe?

Y volviendo a la wikipedia: "De acuerdo a Levy los seis fundamentos del hacker son:

• El acceso a los computadores debe ser ilimitado y total
• Toda información debería ser libre
• Es necesario promover la descentralización y desconfiar de las autoridades
• Los hackers deberían ser juzgados por su labor y no por cosas como su raza, edad o posición social
• Se puede crear arte y belleza en un computador
• Las computadoras pueden cambiar tu vida para mejor

...

De acuerdo a Raymond, la ética social del hacker se basa en tres principios:

• La creencia de que compartir información es bueno
• Que los hackers tienen una responsabilidad ética de compartir la información con la que trabajan
• Que los hackers deberían facilitar el acceso a computadoras cuando sea posible"

Y analizando cada uno de los enunciados, veremos que el sentido dado por los autores se distancia kilometros y mas kilometros de lo que hacen muchos de los supuestos hakers en la onion.

Otros probablemente, tratando de justificar los robos de bases de datos o informacion confidencial de servicios publicos, hablaran de hacktivismo y Leaks, con un solo objetivo: Confundir, mezclar peras con manzanas.

¿Como puede definirse el robo de la base de datos de un registro de identificacion civil como un escape de informacion (Leaks) o una accion hacktivista cuando no cumple los requisitos basicos? No hay objetivos socio-politicos, las victimas no estan realizando actividades que se puedan considerar como dañinas para la sociedad y lo peor aun, el objetivo es puramente comercial.

Ojala mas de alguno tome esto para razonarlo y como una segunda oportunidad.

¿Que es la parapsicologia?

No aprendemos mas