Acceso a múltiples servidores de TeamSpeak mediante subdominios sobre la misma IP en Linux usando TSDNS

Escenario

Tenemos un servidor dedicado con dirección pública (1.2.3.4) en el que tenemos ya corriendo un server de ts3 en la dirección 1.2.3.4:9987 (comportamiento por defecto de ts3). A dicho servidor se puede acceder utilizando esa dirección ip:puerto, nuestro nombre de dominio sysfiend.host y sus subdominios *.sysfiend.host. La idea ahora es montar un nuevo server de ts3 en la misma máquina al que se debe poder acceder solo desde priv.sysfiend.host y que correrá en la dirección 1.2.3.4:9988.

El plan

Una vez montado el segundo servidor (utilizando una herramienta como YaTQA), vamos a configurar el servicio TSDNS que nos proporciona TS3 y a crear un nuevo registro SVN en nuestro DNS.

Fire!

Accedemos a la carpeta tsdns:

cd tsdns

Copiamos el fichero tsdns_settings.ini.sample y editamos el nuevo:

cp tsdns_settings.ini.sample tsdns_settings.ini
nano tsdns_settings.ini

Al final de este, añadimos:

priv.sysfiend.host=1.2.3.4:9988
sysfiend.host=1.2.3.4:9987
*.sysfiend.host=NORESPONSE

De esta manera priv.sysfiend.host siempre resolverá en nuestro nuevo server corriendo en el puerto 9988, mientras que sysfiend.host resolverá en el antiguo, corriendo en el puerto 9987. Además, utilizando la línea de *.sysfiend.host=NORESPONSE, evitamos que cualquier subdominio (menos los especificados) resuelvan en algún servidor de TeamSpeak.
Una vez configurado, lanzamos el ejecutable del servicio que se encuentra en esta misma carpeta con el argumento --update para que actualice los datos:

./tsdnsserver --update

Si todo ha ido bien, debería aparecer un texto tal que así:

Scanned tsdns_settings.ini, number of entries ipv4: 2 normal and 1 wildcards; ipv4+6:2 normal and 1 wildcards.

Finalmente, pero no menos importante, añadimos un registro SVN a nuestro servidor DNS para que el servicio TSDNS sea alcanzable desde _tsdns._tcp.sysfiend.host:

ADD NEW RECORD > SRV Record
Service: _tsdns
Protocol: _tcp
Priority: 0
Weight: 1
Port: 41144 (este es el puerto por defecto de tsdns, en caso de tener uno diferente, modificarlo)
Target: sysfiend.host

Done!

Ahora solo nos queda esperar que los servidores DNS se actualicen y ya no tendremos que tocarlos más para estos temas. 

¿Cómo protege WhatsApp las conversaciones?

En este post solo explicaré que mecanismo usa WhatsApp para proteger las conversaciones, no hablaré de los fallos que este tiene ni de los "backdoors" de los que ya se ha hablado mucho (aunque también lo haré en algún momento futuro). Pues bien, con esto aclarado, vamos a ello.

Para proteger las conversaciones, WhatsApp utiliza la encriptación de los mensajes utilizando cifrado asimétrico, impidiendo así que nadie, menos el destinatario, pueda leerlos. Para ello, cada usuario cuenta con una clave privada y 100 claves públicas temporales asociadas a esa única privada.
En la práctica, mandar un mensaje de A a B sería algo como esto:

1. A pide a B su clave pública.
2. A cifra el mensaje con la clave pública de B.
3. A envía el mensaje cifrado a B.
4. B recibe el mensaje cifrado.
5. B utiliza su clave privada para descifrar el mensaje.

Y listo, una vez "desbloqueado" el mensaje, B ya puede gozárselo con información super privilegiada de A mientras que C se limita a seguir dando rienda suelta a su imaginación...

Ser un vago es lo mejor que te puede pasar o la historia de cómo hice el trabajo de varios días en 2 horas

12 Reasons Why Every Linux System Administrator Should be Lazy <- Una buena lectura hablando del tema

Desde bien pequeño ya me decían que era un vago y que nunca hacía nada, y en parte tenían razón... Nunca me gustó hacer más de lo estrictamente necesario en temas que no me interesaban suficiente y siempre he intentado optimizar lo más posible trabajos repetitivos. Por ejemplo, cada vez que había comida familiar, era necesario coger unas cuentas sillas extra del garaje para los invitados y siempre intentaba hacer el menor número de viajes posibles, ya fuera encajando una encima de otra, arrastrándolas o como fuera, pero siempre el menor tiempo perdido posible.
Esta manera de ver las cosas la he ido utilizando siempre y me ha llevado a ser, o eso quiero creer, un vago eficiente.

A la hora de administrar un servidor, una red o incluso algo tan simple como un fichero al que hay que hacer cambios, te encuentras demasiadas veces en situaciones en las que, si tuvieras los conocimientos necesarios no necesitarías más que ejecutar un comando, crear un pequeño script o utilizar alguna aplicación ya existente para ahorrarte, en ocasiones, horas de trabajo. Es por eso que siempre que se me plantea un trabajo grande y repetitivo, en lo primero que pienso es en una manera de automatizarlo, en alguna manera de imponer el conocimiento a la fuerza bruta. A veces resulta que tardas más tiempo buscando una solución del que habrías gastado haciendo lo que sea que tenías que hacer pero, la próxima vez, es algo que ya tienes aprendido.


Pasemos a algo más práctico... ¿por qué debes ser un vago?

Pues bien, si ya has tenido que enfrentarte a administrar algo, sea lo que sea, sabrás de sobra de lo que voy a hablar y, en caso de que no sea así, apunta.
Administrar, ya solo como palabra, mete miedo. Significa tener el control absoluto de algo, ver lo que hace, cuando y por qué, supervisar su correcto funcionamiento, tomar decisiones, hablar con gente y un sin fin de responsabilidades asociadas. Es por esto que debemos ser lo más vagos de toda la oficina. Serán necesarios conocimientos que puede que no tengas en un principio y tiempo dedicado a leer, de todo, logs, artículos, preguntas y respuestas, y necesitarás hackear cada proceso, buscar sus vulnerabilidades y usarlas a tu favor. Aquí va un ejemplo de hackear un proceso, por si no queda claro el concepto:
Mi escenario era simple: tenía delante una página web (example.com) en la que había unos 4.000 emails públicos que me interesaban y no podía usar un email crawler ya existente por x motivo. En mi poder tenía un plugin para Chrome llamado Email Extractor que recolectaba todos los emails existentes en la página actual (un email crawler sin profundidad, básicamente). Lo único que sabía era que en un apartado de la web había una lista con todas las entidades de las que necesitaba obtener los correos y estaba organizado de la siguiente manera:

ID	NOMBRE ENTIDAD	TELÉFONO
ID2	NOMBRE ENTIDAD2	TELÉFONO2
ID3	NOMBRE ENTIDAD3	TELÉFONO3

Siendo cada ID un enlace a una página con un script de redirección, por lo que, clickar en ID hacía lo siguiente:
Click en ID ->
-> example.com/redireccion.php?id=$ID -> 
-> example.com/entidades/nombre_entidad (no necesariamente igual al de la tabla)
Viendo el panorama, la solución más obvia era visitar 4000 páginas diferentes para conseguir esos correos, pero lo mismo no.

Obtener el link de cada una de las páginas era fácil, tan solo había que copiar el ID y utilizarlo luego en la url, pero ¿cómo sacar el email de manera automatizada? "¡Ya está! Uso curl para descargar todas las páginas y hago un grep '@' y ya está" pensé. Ciertamente funcionaba, pero me devolvía, mínimo, 5 emails por página y algunos elementos que no eran para nada emails como "deportist@s", así que no era suficiente. Y entonces fue cuando vino el momento de aprender algo. Pensé que seguramente habría algún tipo de programa que te permitiría extraer contenido de un fichero html dándole, como referencia, su anidación. Por ejemplo, dado un fichero con el contenido:

<div class="foo">

    <div class="bar">

      <p>correo@example.com</p>

    </div>

</div>

... el programa sería capaz de sacar lo que hubiese dentro de <p> solo cuando estuviese dentro del div .bar y .foo respectivamente, y así era, este programa existía, por lo que me lo descargué, leí el manual, hice una prueba y me preparé para ahorrarme el trabajo de varios días de una manera bastante elegante.

Con todo esto aprendido, tan solo quedaba escribir un pequeño script que se descargase cada una de las páginas donde se encontraban los emails y que posteriormente la analizase y me sacase como resultado a un fichero todos y cada uno de esos 4000 correos. Y de esa manera, en unas 2 horas, hice el trabajo de varios días.


Al igual que este ejemplo, hay miles y todos tienen una fácil solución: ser un vago.

No puedo acceder remotamente a mi aplicación | Algunas soluciones comunes

Antes de nada, esto no vale para todos y cada uno de los problemas que se puedan afrontar tras una instalación (supuestamente) exitosa, pero ayuda a en muchos casos.

Escenario:

He instalado x aplicación, la cual tiene un interfaz de administración web, en mi Raspberry Pi.
Puedo acceder por SSH a la Pi y al interfaz web desde ella, pero desde otro equipo en la misma red, no.

Comandos útiles para comprobaciones:

netstat -punta | grep LISTEN #localmente

netstat -punta | grep miaplicacion

nmap -p80 dirección.ip.raspberry #desde el exterior

Troubleshooting:

Puesto que podemos hacer SSH a la Pi, nuestro abanico de posibles problemas se cierra bastante y nos quedamos con problemas de firewall, iptables, selinux o errores de configuración.

Firewall

Por defecto viene deshabilitado en las Pi, así que, a no ser que hayamos configurado nosotros uno, nos olvidamos. En caso de haber instalado uno, comprueba que acepta conexiones desde el exterior o, al menos, la misma red.

Iptables

Solución rápida; borrar nuestra configuración:

iptables -F

Solución menos rápida, comprobar la configuración y hacer los ajustes necesarios, en caso de ver algún error:

iptables -L #Configuración actual

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT #Abrir puerto TCP 80 (ejemplo)

Un poco de ayuda con el tema de Iptables -> https://help.ubuntu.com/community/IptablesHowTo

Selinux (desgraciado...)

En caso de que no esté ya, lo deshabilitamos:

vi /etc/selinux/config #la ruta puede variar un poco dependiendo de vuestro OS

Cambiamos

SELINUX=permissive

por

SELINUX=disabled

sestatus #comprobamos que, en efecto, lo hemos deshabilitado

Errores de configuración

Si has llegado a este punto, es porque todo lo anterior ha fallado y sigues sin poder acceder a tu aplicación. En ese caso, solo nos queda lidiar con los ficheros de configuración de dicha aplicación
(y su manual) para comprobar que no hay ninguna opción que impida aceptar tráfico desde el exterior. Una opción común de este tipo hace referencia a algo como LISTEN, NETWORK o INTERFACES seguido de una dirección de red (en caso de ser 127.0.0.1, habría que cambiarla por la de nuestra red o 0.0.0.0 para aceptar tráfico desde cualquier parte).