Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

martes, 22 de diciembre de 2015

Spotify casero con subsonic en raspian

Las herramientas de servicio de música digital se han puesto en auge durante los últimos años, herramientas entre las cuales siempre ha habido un claro ganador: spotify. Obviamente spotify tiene sus limitaciones y si bien no deja de ser una excelente herramienta, siempre cabe la posibilidad de que queramos nuestro propio servicio de música digital para uso propio. Hace relativamente poco mostré como poder stremear contenido multimedia gracias a VLC, pero en este caso, en vez de recurrir a dicha herramienta y a conocimientos de multicast, realizaremos algo más simple y que claramente está orientado hacia únicamente la música. Para ello existe una herramienta gratuita, que si bien tiene una versión premium con más funcionalidades, su funcionamiento básico puede satisfacer las necesidades de la mayoría de los usuarios: Subsonic

Subsonic_logo

Subsonic es una utilidad muy parecida a spotify que puede ser instalada en cualquier equipo o servidor; luego simplemente habría que almacenar la música en dicho dispositivo y podría ser accedida desde cualquier punto que tenga acceso a dicho dispositivo... Al ser algo que va a tener tendencia a estar largo tiempo encendido, es recomendable tener un dispositivo que sepamos que va a estar largo tiempo encendido... En este caso por ejemplo una raspberry pi (no importa que sea la 1 o la 2) puede satisfacer nuestras necesidades sin problemas, pues sus pequeñas dimensiones y su bajo consumo hace que sea muy factible tener un dispositivo de este tipo en casa. Concretamente me he centrado en el sistema operativo raspian, pues es el sistema más usado de todos en estos dispositivos. Aún así, esta utilidad también puede ser instalada en cualquier otro entorno sin problema alguno, siempre y cuando seamos conscientes de que éste tendrá que estar siempre encendido si queremos tener acceso "ilimitado" él.

Su instalación es extremadamente sencilla, pues únicamente requiere de dos cosas:

La primera sería el tener instalado el paquete openjdk-7-jre; pues sin dicho paquete no podríamos siquiera instalar el paquete. Afortunadamente el paquete está incluido en los repositorios oficiales del sistema, con lo que simplemente habría que escribir:

apt-get install openjdk-7-jre

El segundo consistiría en a la descarga del paquete referente a subsonic, aunque en este caso, éste no está incluido en repositorio alguno, con lo que habría que descargar éste desde la página oficial. El software en sí ya está preparado en un paquete únicamente habría que recurrir a dpkg para instalarlo; esto significa que el proceso de instalación del paquete subsonic  se reduce a dos pasos:

  1. wget http://subsonic.org/download/subsonic-5.3.deb
  2. dpkg -i subsonic-5.3.deb

Simple y efectivo... Aún así esto no es suficiente para que podamos disfrutar de nuestro servidor de música, ya que por defecto está configurado para trabajar con root, cosa insegura... Además aunque tenemos el servicio de música preparado, la carpeta con la que éste trabaja por defecto /var/music, no existe por defecto. Con lo que antes de usar la utilidad, es recomendable modificarla y prepararla para que esté todo a punto.

Lo primero y más importante es corregir el problema con root; pues es una grave falla de seguridad y puede causar problemas. Para ello habría que modificar el comportamiento por defecto de la aplicación subsonic; comportamiento que se especificaría en el fichero: /etc/default/subsonic. Allí existe un parámetro llamado SUBSONIC_USER el cual está establecido por defecto como root; dicho valor tendría que ser cambiado para mejorar la seguridad, valor al que le tendríamos que asignar cualquier otro usuario, como por ejemplo ivan dejándolo de la siguiente forma:

SUBSONIC_USER=ivan

Por otro lado, el puerto de escucha por defecto de subsonic es el 4040; cosa problemática ya que los usuarios que NO son root únicamente puede acceder a los puertos inferiores al 1024; con lo que para poder acceder a subsonic tendremos que darle a la carpeta de éste permisos de escritura.

chmod +w -R /usr/share/subsonic/

Por otro lado, habría que crear la carpeta que contendrá los archivos de música; carpeta que subsonic por defecto considera que es /var/music. Además dicha carpeta tiene que pertenecer, obviamente, al mismo usuario que el que hemos asignado en /etc/default/subsonic. Esto lo lograremos mediante estos dos comandos:

  1. mkdir /var/music
  2. chown ivan:ivan /var/music/

Por último, pero no menos importante, habría que reiniciar subsonic, pues ahora mismo sigue estando configurado para funcionar con root, cosa que no cambiará hasta que el servicio se reinicie. Esto es tan sencillo como escribir:

sudo service subsonic restart

Con esto ya tendríamos un servidor de música muy sencillo pero funcional. Si se quisiese acceder a éste desde la red local únicamente habría que escribir en el navegador web la ip _del_servidor:4040; por ejemplo:

192.168.1.5:4040

Mientras que si se desease acceder desde el exterior sería necesario recurrir a un port forwarding en el router; también conocido como redirección de puertos.

Espero que os haya resultado útil.

Saludos.

sábado, 19 de diciembre de 2015

20 comandos para los iniciados en Linux

La terminal de Linux es uno de los elementos más temidos por la mayoría de los usuarios; sin ratón, sin interfaces gráficas, solamente tenemos una pantalla negra en la que hay que introducir comandos para poder desenvolvernos; comandos que a muchos les da respeto e incluso temor. A mí personalmente me encanta la terminal; sus posibilidades, su libertad, su eficiencia... Pero he de admitir que al principio me sentí enormemente intimidado por ésta: ¿Y si "rompo" algo? ¿Por qué tengo que memorizar comandos cuando antes tenía que hacer click? ¿Qué podría pasar si tecleo... ?  ¿Por qué...? Numerosas preguntas que uno se hace debido al temor producido por la consola. Temor causado por el desconocimiento. Este post está dirigido a aquellos que aunque se han iniciado en el mundo de Linux, todavía le tienen miedo a la consola; espero que con este post podáis sentiros un poco más seguros en ésta. Obviamente esta guía no puede abarcar todos los comandos, pero sí que intentaré repasar todos los que en mi opinión son los más importantes.

portada_lista_comandos

  1. man: Primer comando de obligado conocimiento, nos muestra el manual de uso de los comandos que queramos consultar. Por ejemplo se podría hacer un man ls para ver el manual de dicho comando. Es el comando más importante de todos, ya que es la herramienta de aprendizaje más poderosa. Ejemplo: man ls
  2. ls: Muestra un listado del contenido de la carpeta; uno de los comandos más usados en Linux. Ejemploman /home/ivan
  3. pwd: Aunque la terminal siempre muestra la ubicación en la que nos encontramos, a veces es importante asegurarnos; para ello se usa este comando, que dice exactamente en qué carpeta nos encontramos. Es especialmente útil cuando se es novato con la terminal, pues en ocasiones uno se puede sentir desorientado. Ejemplo: pwd
  4. cd: Tan importante como listar el contenido de un directorio, es desplazarnos a otras carpetas; es el comando fundamental que nos ayudará a desplazarnos por los diferentes elementos y carpetas del sistema. Ejemplocd /mnt/
  5. cat: A veces queremos consultar el contenido de un archivo de texto sin tener siquiera la opción a modificarlo. Para lograr dicho objetivo recurriremos al comando cat. Ejemplo: cat texto.txt
  6. nano: Uno de los editores por defecto incluidos en Linux; muchos opinarían que este editor no es tan clásico como vi, ni que tampoco está a la altura, pero en mi opinión que un usuario inexperto comience a editar un fichero con dicha utilidad es una locura. Ejemplo: nano fichero.txt
  7. mkdir: Aunque el movernos por directorios está muy bien, la creación de éstos es muy importante también. Para eso recurriremos al comando mkdir. Ejemplomkdir directorio
  8. cp: Si queremos copiar un archivo de un lado a otro, tendremos que recurrir al comando cp, cuya estrucutra es cp archivo_a_copiar carpeta_destino. Ejemplo: cp copiado.txt /home/
  9. mv: Si queremos mover un archivo de un lado a otro, tendremos que recurrir al comando mv, cuya estrucutra es mv archivo_a_mover carpeta_destino. Ejemplocp fichero_a_mover.txt /home/
  10. rm: No podemos hablar de tratamiento de archivos o carpetas sin mencionar al comando rm (remove), que elimina ficheros y carpetas. Su estructura sería rm fichero_o_carpeta_a_borrar.  Este comando no borra por completo el archivo del disco duro, para ello habría que recurrir a otra herramientas más avanzadas como shredEjemplo: rm archivo.txt
  11. ifconfig: Mucha gente no considera importante este comando, pero en verdad es muy útil cuando deseamos hacer comprobaciones de comunicación con internet, pues este comando nos muestra las ips de nuestro equipo. Este comando puede ir en solitario o puede estar acompañado por el nombre de la interfaz de red, la cual generalmente empezará por eth o wlan. Ejemplo: ifconfig o ifconfig eth0
  12. shutdown -h now: Uno de los comandos que más rápido aprende uno; sirve para apagar el sistema.
  13. reboot: En vez de apagar el sistema, podemos reiniciarlo mediante este comando.
  14. find: Este comando tiene diferentes parámetros, pero todos ellos tienen un objetivo en común: Buscar un archivo dentro del sistema. Hay bastantes usos, pero el más común es find / -name fichero_a_buscar.
  15. df: Es muy importante conocer el espacio en disco que tenemos ocupado para evitar saturarlo. Para ello recurrimos a este comando aunque suele ir acompañado de algún parámetro; generalmente del parámetro -h. Ejemplo: df -h
  16. free: Otro comando realmente útil; especialmente si el equipo tiene poca memoria ram. Nos cuenta cuanta memoria ram total tenemos y cuanta llevamos consumida. Por defecto muestra el resultado en kilobytes, cosa incomoda, pero podemos mostrarla en megabytes o gigabytes mediante los parámetros -m y -g respectivamente. Ejemplo: free -m
  17. useradd: Un sistema operativo sin usuarios no nos es útil, y si bien cuando instalamos el sistema ya añadimos uno, en la gran mayoría de las ocasiones no es suficiente. Para añadir más usuarios recurriremos a esta utilidad. Ejemplo: useradd pepito
  18. userdel: Obviamente también es interesante conocer cómo eliminar los usuarios creados. Lo cual como podéis ver es muy sencillo. Ejemplo: userdel pepito
  19. apt-get install/yum install: Es imposible hacer esta guía pasando por alto estos dos comandos que se han puesto juntos debido a que ambos tienen la misma función; instalar software desde los repositorios oficiales del sistema; la diferencia entre ambos radica en que apt-get install es usado en Debian, Ubuntu y derivados mientras que yum install es usado en Red Hat y derivados... Ejemplo: apt-get install firefox o yum install firefox
  20. chmod +x: Aquí lo ideal sería tener nociones de como funcionan los permisos en Linux, pero como tip general, este comando hace un archivo sea ejecutable. Por ejemplo un script o un programa, a veces no puede ser ejecutado debido a que no se tienen permisos de ejecución; este comando hace posible que el archivo pueda ser ejecutado. Ejemplo: chmod +x archivo
Esta lista es la punta del iceberg; los comandos existentes son mucho más, pero estos pueden servir de referencia para adquirir las bases necesarias para profundizar en esta área; pueden parecer muchos comandos al principio, pero practicando un poco veréis que se aprenden muy fácilmente. 

Espero que el listado os haya resultado útil.

Saludos.

martes, 15 de diciembre de 2015

Primeras impresiones de la beta de Let's encrypt.

Hace unas semanas realicé un post en referencia a un proyecto llamado Let's Encrypt, cuya ambiciosa finalidad es la de proveer de certificados SSL gratis para todos. El proyecto se encontraba en beta cerrada, pero el día 3 de Diciembre, finalmente está disponible para todo el mundo, aunque ellos mismos recalcan que el proyecto se encuentra todavía en fase beta. Aún así no he podido evitar sentir la tentación de probar estos certificados, aunque sea para ver su facilidad de implantación, problemas, limitaciones, etc... 


Hablando el líneas generales se podría decir que el proyecto, aunque bien encaminado, todavía tiene bastante recorrido por recorres. Hace lo que dice, pero requiere de bastantes requisitos para funcionar correctamente, requisitos que personalmente me parece un poco molestos, aunque ellos mismos admiten que están en proceso de mejorarlo y ya advierten que todo esto se encuentra en fase experimental y que pueden haber cosas mejorables, bugs, etc...

El proceso de implantación de los certificados parece a primera vista sencillo, pero a decir verdad necesita bastantes requisitos, y tiene bastantes limitaciones. Las principales que he visto son:
  • Cuando se quiere hacer referencia a la dirección en la que se quiere instalar el certificado; no permite especificar la ip pública ni privada del servidor web. Únicamente admite nombres de dominio. 
  • El nombre de dominio debe de ser accesible desde el exterior; es decir, no puedes asociar un nombre de dominio a un equipo/servidor interno mediante utilidades como bind9 y listo... Este punto es bastante problemático y generalmente la solución suele estar en buscar un DNS dinámico gratuito. En mi caso, para lograrlo he recurrido a noip.com, pero cualquier opción parecida sería válida también.
  • En raspberry pi no funciona la instalación del certificado de momento. He hecho diferentes pruebas, pero en todas parece ser incapaz de instalarlo.
  • Los certificados tienen una validez de 6 meses, tras los cuales habría que volver a generarlos de forma manual, si bien la renovación es bastante sencilla.
A pesar de estos inconvenientes y de los numerosos obstáculos que uno puede encontrarse para instalar un certificado, una vez instalado no parece dar demasiados problemas, si bien habría que esperar cierto tiempo para llegar a una conclusión sólida. Aún así, a pesar de estos inconvenientes, el proyecto sigue teniendo muchos adeptos pues sigue siendo una excelente iniciativa. Además, como ellos mismos dicen, se trata de una versión beta y es normal encontrarse con este tipo de fallos o inconvenientes. 

De todas formas es interesante probar estos certificados y ver hasta que punto nos pueden ser útiles; cierto es que todavía están un poco "verdes", pero probablemente la situación mejore a corto plazo. Hemos de tener en cuenta que lleva muy poco tiempo en activo y es normal encontrarnos con inconvenientes los primeros meses.

En definitiva, se trata de un proyecto con mucho potencial pero que todavía le queda cierto tiempo por madurar; aún así todo apunta a que dará mucho que hablar en el futuro.

Saludos.

domingo, 13 de diciembre de 2015

PPTP y L2TP/IPSec. ¿Qué diferencia hay?

Uno de los aspectos más molestos en el mundo de la informática, ya sea en ámbito de la seguridad o en cualquier otro, es que a veces dan por hecho que el usuario final tiene conocimientos técnicos sobre la herramienta que va a usar, cuando en realidad, en muchas ocasiones, el usuario quiere hacer click en un botón y que éste haga lo que tenga que hacer, sin tener ni idea de lo que éste pueda hacer por debajo mientras que lo haga bien. Dentro de estos conceptos que muchas aplicaciones dan por hecho que el usuario final conoce, se encuentra el procolo de VPN usado... Muchos clientes gráficos de VPN hacen una pregunta muy simple pero al mismo tiempo muy importante que es: ¿Qué protocolo usar? ¿PPTP o L2TP/IPSec? Esta es una pregunta que una persona sin conocimientos técnicos jamás debería de plantearse a la hora de usar una VPN, pero aún así, visto que de momento esa pregunta no desaparecerá a corto plazo, en este post intentaré arrojar algo de luz sobre dicho tema para que, en caso de encontrarnos con dicha incógnita, realizar la elección a sabiendas de el significado de cada protocolo.

pptpvslltp


PPTP

Este protocolo fue diseñado por Microsoft y una serie de colaboradores en 1999, y en su momento supuso un completo cambio en las comunicaciones, pues posibilitaba el intercambio de datos cifrado a través de una VPN mediante TCP. Gracias a la adopción de dicho protocolo, el uso de las VPNs se fue extendiendo a lo largo de los años, siendo consideradas como recursos indispensables para algunas tareas; pues además la mayoría de los proveedores de telefonía (ISP) no bloqueaban este protocolo, suponiendo no solo un recurso útil, sino que además fácil de implementar, pues simplemente hay que seleccionar dicho protocolo y listo...

Obviamente lo fácil generalmente no suele estar relacionado con lo seguro (aunque últimamente se está intentando simplificar bastante) y este caso no es una excepción... La debilidad de este protocolo radica en el cifrado de éste, pues se ha demostrado que es altamente vulnerable y que puede ser quebrado con relativa facilidad...  Un "simple" ataque de man in the middle para situarse entre el equipo que se quiere interceptar y el router junto con el uso de una herramienta para romper el cifrado, como por ejemplo Ethercap o Cain y Abel y se podría obtener la información de aquella comunicación supuestamente privada... Privacidad que obviamente ha sido comprometida. Esta vulnerabilidad de cifrado hace que el protocolo en cuestión sea considerado cómo inseguro, aún cuando hoy en día se sigue usando ¿El motivo? Su facilidad de implantación aún cuando es ampliamente conocida su (in)seguridad.

Se trata de un protocolo que para realizar VPNs sencillas y rápidas de implantar es ídoneo, si bien si se quiere transmitir por ésta contenido relevante es mejor descartarlo de inmediato si no queremos que algunos "curiosos" intercepten la comunicación.

L2TP/IPSec

A raíz de la poca fiabilidad del anterior protocolo se implementó uno nuevo: L2TP, el cual se usa cómo protocolo de creación de redes VPN sobre UDP (a diferencia de su antecesor que lo hacía sobre TCP). La cuestión está que este protocolo de por sí no ofrece ningún cifrado, teniendo que apoyarse sobre IPSec para cifrar la comunicación y establecer canales seguros. Muchas veces se piensa que el protocolo de por sí está cifrado, si bien la verdad es que busca apoyo en el conjunto de protocolos IPSec.

Además del cifrado más seguro ofrecido por IPSec, L2TP garantiza también una mayor seguridad que PPTP, ya que tiene más mecanismos para garantizar la integridad de la información (es decir que no sea manipulada por el camino) y para la garantización de que el origen del que se ha enviado la información es correcto; dificultando la labor a los delincuentes.

Esto tiene como "pega" el hecho de que para usar esta comunicación es necesario crear certificados tanto para el servidor como para cada cliente que se quiere conectar (tal y cómo ocurre por ejemplo en OpenVPN). Esta creación de certificados es algo lenta y "engorrosa" si bien a largo plazo supone muchos beneficios a nivel de seguridad.

Lastima que en la mayoría de las ocasiones esta pega suponga un impedimento en muchos sitios para implementar este protocolo, pues muchos quieren soluciones que se puedan implementar rápidamente y que requieran que el cliente haga click en un botón.

Conclusión

Aunque la implementación de PPTP es muy tentadora debido a su sencillez y su validez para la creación de VPNs que no se usen para comunicaciones "relevantes". la inversión de tiempo y esfuerzo en la creación de una VPN basada en L2TP/IPsec nos puede salvaguardar de muchos imprevistos... Imprevistos que compensan la inversión de tiempo realizada, pues una vez hayan vulnerado la comunicación no hay marcha atrás.

Espero que os haya resultado útil.

Saludos.

jueves, 10 de diciembre de 2015

Cómo esconder los Linux banners de los "curiosos"

Una de las cosas más curiosas que tienen los servicios que funcionan en red es que cuando se trata de acceder a estos, se hace un barrido de puertos con nmap o se hace una interacción de cualquier tipo con un servicio, es que éstos muestran mucha información sobre el servicio en cuestión, e incluso en algunos casos del sistema operativo... Yo a menudo suelo decir que la información es poder, pues no es para menos, ya que por defecto, todos los servicios muestran información que, aunque aparentemente inofensivos, pueden hacer mucho daño. No es lo mismo que una persona sepa que uno tiene un servicio web, que el que sepa que dicho servicio web es un Apache 2.4.10 (por ejemplo) corriendo sobre un sistema Operativo Debian, pues si se sabe qué versión tiene uno y en que sistema está corriendo, se pueden buscar vulnerabilidades de dicha versión y explotarlas. La mejor forma de prevenir ese tipo de cosas es manteniendo el sistema operativo y sus programas actualizados, pero no siempre es así, y además cuanto menos información se comparta con el resto del mundo, mejor. Por ello hoy quiero mostraros un par de consejos para ocultar parte de nuestra información al mundo; consejos que en este caso en concreto estarán relacionados con los banners, que son simplemente recursos que muestran cierta información; por defecto la información del software y/o sistema operativo.

ESCONDER


Al existir hoy en día un enorme número de programas, es imposible englobarlos todos y explicar uno por uno cómo deshabilitar o cambiar cada banner. Además existen algunos programas que no permiten ocultar dicha información o que, si lo hacen, lo hacen de forma limitada... Aún así es muy interesante conocer el concepto y podemos tomar esta información como base para aplicarla a otros servicios que nos interesen; siempre teniendo en cuenta que no todos permiten dicha ocultación. Obviamente más de uno se pude estar preguntado: ¿Cómo podemos saber qué información muestra cada servicio? ¿Cómo sabemos si el servicio muestra demasiada información o no? Esta incógnita se resuelve fácilmente mediante un pequeño comando llamado nmap. En este caso en concreto querríamos usar el comando nmap -sV ${ip_del_equipo}. Por ejemplo realizando un barrido de la ip 192.168.1.7 obtendría este resultado:


Esto solo es una pequeña parte la información que este comando puede mostrar, pues depende de la cantidad de servicios que tengamos instalados; los servicios son muchos y es imposible mencionarlos todos... Aún así, usando como base los servicios que mencionaré a continuación, podemos aplicar estos conceptos para otros servicios que tengamos instalados o que deseemos instalar en el futuro.

Apache2

Los servidores web son unos de los servicios más jugosos y más ansiados, y con razón, pues la caída de éstos suele ser muy perjudicial... El banner mostrado por el servidor web es muy peligroso, ya que no solo dice si es un Apache un Nginx o un ISS (entre otros) sin que además muestra la versión de dicho servidor web. Aunque en este caso me voy a centrar en Apache, este concepto es perfectamente aplicable al resto de servicios, con lo que en caso de tener un servidor web, es muy recomendable ocultar su banner o cambiarlo.

Para este caso en concreto, tenemos la posibilidad de cambiar el banner, que en mi opinión es mucho más útil que ocultarlo, ya que en dicho banner podemos poner lo que nos venga en gana... Desde un nombre gracioso a el nombre y la versión de otro servidor web que obviamente no tenemos instalado... Por ejemplo IIS 7.0 (Internet Information Service) que es tecnología de Microsoft, que es completamente opuesto a nuestro Apache, y hace pensar al atacante que tiene que atacar a un ISS (con ataques específicos para esa tecnología) cuando en verdad estamos corriendo un Apache.

Lo primero que necesitaremos para lograr nuestro objetivo será instalarnos las librerías del módulo de seguridad de apache, mod_security, instalación que se realiza desde los repositorios sin problema alguno:

apt-get install libapache2-modsecurity

Gracias a estas librerías, podemos ahora hacer uso de un módulo llamado security2_module; módulo que incluiremos en el fichero de configuración de apache2 llamado apache2.conf, alojado dentro del directorio /etc/apache2/. Al final del fichero de configuración habría que añadir (para finger ser por ejemplo ISS 7.0)

  1. <IfModule security2_module>
  2. SecRuleEngine on
  3. ServerTokens Full
  4. SecServerSignature "Microsoft-IIS/7.0"
  5. </IfModule>

Simplemente reiniciando apache ya tendríamos nuestro servidor web disfrazado; disfraz que como veis se ha podido aplicar de forma rápida y efectiva.

PHP

Otra gran fuente de información es php. Las últimas versiones están diseñadas para ocultar información sobre este software, pero aún así es conveniente revisar que efectivamente se está haciendo la ocultación, ya que requiere muy poco esfuerzo y nos puede ahorrar muchos problemas. 

La revisión de la visibilidad o no de la información se hace dentro del fichero /etc/php5/apache2/php.ini, y simplemente consiste en revisar el el parámetro expose_php; este debería estar establecido a Off.

expose_php = Off

SSH

Obviamente no podía dejar pasar por alto el ansiadísimo SSH que tantas virtudes tiene y que tanta gente quiere explotar de un modo u otro... Aquí no es posible ocultar la versión de SSH, pero lo que sí que podemos hacer, al menos en Debian, es ocultar el sistema operativo bajo el que está corriendo SSH. Es cierto que no oculta tanta información como a uno le gustaría, pero el hecho de que no conozcan el sistema operativo fortifica bastante el sistema... Para ocultar el banner de Debian, basta con un sencillo comando:

echo 'DebianBanner no' >> /etc/ssh/sshd_config

No es la ocultación absoluta, pero al menos no podrán conocer el sistema operativo gracias a este puerto.

FTP

Un servidor FTP puede ser creado mediante diferentes herramientas, y aunque es imposible ocultar el hecho de que se tiene un servidor ftp, sí que podemos ocultar qué software se está ejecutando. Al igual que en apache, aquí existen varios tipos de servidores ftp, cada uno con sus fortalezas y debilidades. En este caso me centraré en proftpd, pero esto puede ser perfectamente aplicado en cualquier otro servicio.

Para este caso en particular, también valdría con un comando parecido al aplicado con ssh, si bien tanto el parámetro como el fichero de configuración de destino, obviamente, cambian.

ServerIdent off

Obviamente estos son solo algunos de los servicios en los que podemos alterar u ocultar el banner, pero creo que sirven como una buena referencia para el futuro. La mejor prueba  para comprobar que nuestros cambios han sido exitosos, sería la repetición del comando nmap. El comando tarda bastante más en ejecutarse debido a que tiene problemas con proftpd, pero pasado un rato obtendremos un resultado parecido al siguiente:

nmap_limpio


Espero que os haya resultado útil y que os sirva como base para otras aplicaciones.

Saludos.


martes, 8 de diciembre de 2015

Expulsando a los inactivos en Linux

Las sesiones inactivas abiertas pueden resultar tan peligrosas o más que algunas vulnerabilidades o descuidos a la hora de gestionar la seguridad de un entorno... De nada sirve preparar unas medidas de seguridad muy estrictas mediante atributos, permisos o, si somos extremadamente restrictivos, mediante ACL, si luego al irnos a tomar un café o a comer nos dejamos la sesión del equipo abierta. Dicha sesión puede resultar fatal, especialmente en caso de ser la sesión de un usuario con privilegios o root, con lo que es recomendable tratar, en medida de lo posible, evitar dicha situación. Lo ideal en estos casos suele ser simplemente cerrar la sesión de terminal o bloquear el equipo, pero esto requiere del factor humano, factor que, sinceramente, es muy poco fiable. Es por eso que es muy recomendable aplicar medidas que puedan expulsar a los usuarios inactivos, pues suponemos que cuando alguien se encuentra inactivo es debido a que se encuentra fuera de su sitio. Por eso hoy vengo con dos medidas que podemos aplicar en nuestros equipos con mucha facilidad; una para cualquier sesión en general y otra para sesiones ssh.

dormir


Sesiones generales

Esta medida puede ser aplicada para la sesión activa (es decir, la sesión que está ejecutando el usuario en ese momento) o para todas las sesiones de dicho usuario; con lo que esta solución puede ser muy útil también para momentos puntuales en las que queramos cerrar la sesión en caso de inactividad. Para ello haremos uso de las variables de entorno. Para aquellos que no conozcan este concepto, simplemente se trata de información a la que se accede a través del nombre de la variable; un buen ejemplo de una de estas variables sería la variable pwd, que aunque muchos la confunden con un comando, no es así. Esta variable contiene la ruta actual en la que se encuentra una, que puede ser la carpeta home o cualquier otra... Son numerosas las variables de este tipo, variables que podemos consultar en cualquier momento desde la consola escribiendo env.

En este caso no usaremos ninguna de las variables listadas por defecto, sino que asignaremos una que almacenará el número de segundos de inactividad que soportará nuestra sesión. Esta variable se denomina TMOUT y le asignaremos el tiempo de actividad de la siguiente forma desde la consola:

export TMOUT=número_segundos

Teniendo en cuenta que un tiempo de inactividad "razonable", serían 10 minutos, podríamos asignar dicho tiempo a la variable, lo cual equivale a 300 segundos.

export TMOUT=300

Esto está muy bien, pero si lo hacemos de esta forma únicamente sería válido para la sesión actual... Cosa que puede ser realmente conveniente en determinados momentos, pero que en caso de que a uno se le olvidase escribirlo en el momento dado dejaría el equipo a merced de cualquier "curioso" que pase cerca. Es por eso que en caso de querer aplicar el cambio de forma permanente, habría que incluirlo en el fichero .bashrc de cada usuario; fichero que se encuentra dentro de la carpeta /home de cada usuario y en el directorio /root para el usuario root.

Como podeis ver se trata de una solución sencilla que se puede implantar con rapidez.

Sesiones ssh

Mucha gente no quiere tener las limitaciones anteriormente comentadas, y solo quieren que se interrumpan las sesiones ssh tras un determinado tiempo, pues en caso contrario podríamos encontrarnos con sesiones eternas que pueden suponer un grave problema a nivel de seguridad. Aunque la anterior opción también sería válida para las sesiones ssh, si únicamente quisiesemos establecer un tiempo límite para esas conexiones, tendríamos que modificar el archivo de configuración de ssh, es decir sshd_config, alojado /etc/ssh.

Dentro de dicho fichero podremos buscar cuanto queramos, que no encontraremos "pistas" para poner dicha limitación, pues serían líneas extra que habría que añadir a dicho fichero; en concreto dos.

  • ClientAliveInterval: Este pequeño parámetro sirve para que tras una determinada cantidad de segundos mande un mensaje de verificación al cliente que está conectado con el fin de saber si la conexión sigue activa o no. Únicamente se envía el mensaje en caso de estar inactivo; es decir que si por ejemplo se tuviese un intervalo de 300 segundos; únicamente se enviaría el mensaje si se hubiese estado inactivo durante dicho periodo de tiempo.
  • ClientAliveCountMax: Este parámetro es directamente dependiente del anterior. Tras el envío del mensaje de, se espera que el cliente verifique que se encuentra ahí (por ejemplo retomando la actividad). Este parámetro establece un contador de mensajes, si por ejemplo se pusiese dicho valor a tres, si se hubiesen mandado 4 "mensajes" de verificación seguidos la conexión ssh se cerraría. Si por ejemplo se pusiese dicho valor a 0, con el primer mensaje se cerraría la sesión.
A sabiendas de lo que hacen estos dos parámetros añadiríamos estas dos líneas al fichero de configuración.


  1. ClientAliveInterval 300
  2. ClientAliveCountMax 0


Obviamente tras aplicar este cambio, habría que reiniciar el servicio ssh para hacerlo efectivo.

/etc/init.d/ssh restart



Ambos métodos son muy útiles, cada uno con su propósito particular, pero indudablemente realizan su tarea a la perfección; solo quedaría escoger aquel que se adaptase mejor a nuestras necesidades.

Espero que os haya resultado útil.

Saludos.

sábado, 5 de diciembre de 2015

Streaming de peliculas casero con Linux + VLC

¿Alguna vez habéis querido compartir un vídeo con una gran cantidad de personas de vuestra red, pero no deseáis subirlo a Internet ni mandarlo individualmente a cada persona? ¿Simplemente dejar ese vídeo disponible para cualquiera que desee verlo? En el día de hoy vengo a mostraros cómo lograr dicho objetivo de forma muy sencilla gracias a Linux y a la archiconocida herramienta VLC. En este caso en concreto me centraré en usar la consola de Linux, pues aunque también es posible hacerlo desde la interfaz gráfica, el conocer cómo hacerlo desde la consola puede ser realmente útil en entornos en los que se carece de ésta, entornos que necesitan muy pocos recursos para funcionar. Antes de nada, he de decir que para lograr este objetivo transmitirá el vídeo mediante el método de transmisión multicast, con lo que en caso de desconocer este concepto, os recomiendo leeros este post.

streaming_portada

Los requisitos para lograr esto se tratan de simplemente dos:
  • Un sistema basado en Linux; preferiblemente Debian.
  • VLC

El primer requisito es sencillo y requiere de un equipo o máquina virtual con muy pocos recursos, pues no requerirá de entorno gráfico alguno; todo se puede hacer desde la consola sin problemas. El segundo requisito, si bien es muy conocido, nunca viene instalado por defecto en ningún sistema Linux, sea la distribución que sea, pero al ser una herramienta Open Source que goza de una enorme popularidad, está incluida en los repositorios oficiales de la gran mayoría de las distribuciones, con lo que su instalación es tan sencilla como escribir:

sudo apt-get install vlc

Con todos los requisitos cumplidos, hay un pequeño problema y es que aunque VLC es usable, requiere usar una serie de parámetros muy difíciles de recordar, y además es mucho más útil y cómodo tratar VLC como un "demonio" y ejecutarlo cuando nosotros queramos sin tener que memorizar el comando y los parámetros necesarios... Además he aprovechado dicho script para indicar un fichero de configuración en el que indicaremos una serie de comportamientos para VLC. Dicho script se denominaría vlcinit.sh y poseería el siguiente contenido:

  1. #!/bin/bash
  2. PIDFILE=/var/run/streaming.pid
  3. CONF=/etc/vlc/streaming.conf
  4. DAEMON="/usr/bin/vlc"
  5. DAEMON_ARGS="-I telnet --telnet-port 60000 --telnet-password uvelece --vlm-conf=$CONF"
  6. do_start()
  7. {
  8.         start-stop-daemon --verbose --chuid nobody:nogroup --start --pidfile $PIDFILE --background --make-pidfile --exec $DAEMON --$DAEMON_ARGS
  9. }
  10. do_stop()
  11. {
  12.         start-stop-daemon --verbose --stop --pidfile $PIDFILE
  13.         rm -f $PIDFILE
  14. }
  15. case "$1" in
  16.   start)
  17.         do_start
  18.         ;;
  19.   stop)
  20.         do_stop
  21.         ;;
  22.   restart)
  23.         do_stop
  24.         do_start
  25.         ;;
  26.   *)
  27.         echo "El uso correcto es: $0 {start|stop|restart}"
  28.         ;;
  29. esac

Lo más reseñable dentro de este script (aparte de los argumentos de DAEMON_ARGS en los que no profundizaré), sería el archivo de configuración llamado /etc/vlc/streaming.conf. Si exploramos dentro del equipo veremos que no existe dicho directorio vlc, ni mucho menos el fichero streaming.conf... Esto es debido a que este fichero de configuración ha sido inventado con el único propósito de hacernos capaces de "stremear" una película que tengamos almacenada en el equipo.

Es por ello que si queremos que apunte a un fichero real, tendremos que apuntar a éste, para lo cual tendremos que crear tanto la carpeta como el fichero en cuestión, con sus correspondientes permisos de ejecución. Esto se lograría mediante los comandos:

  1. mkdir /etc/vlc/
  2. touch /etc/vlc/streaming.conf
  3. sudo chmod +x /etc/vlc/streaming.conf

Además, dentro de dicha carpeta (/etc/vlc) crearemos un directorio que almacenará la pelicula y/o peliculas que deseemos compartir; como por ejemplo el directorio películas.

mkdir /etc/vlc/peliculas

Dentro de este directorio almacenaremos las peliculas que deseemos; yo por ejemplo, para no incurrir en ningún problema de derechos, he introducido la película Big Buck Bunny, la cual es completamente gratis y se puede distribuir sin problemas. En caso de estar interesados en usar dicha película lo podéis hacer aquí.

Ahora llegaría el turno de preparar el archivo de configuración streaming.conf; este fichero está vacío por defecto, ya que ha sido creado por nosotros, pero usando como plantilla el fichero de configuración para la película Big Buck Bunny, podemos crear un archivo de configuración con tantas películas como deseemos. En este caso en particular, el fichero tendría este contenido:

  1. new channel1 broadcast enabled
  2. setup channel1 input /etc/vlc/peliculas/big_buck_bunny_1080p.avi loop
  3. setup channel1 output #duplicate{dst=std{access=udp,mux=ts,dst=230.40.100.80:1234}}
  4. control channel1 play

A primera vista este párrafo puede parecer ilegible, pero en él únicamente hay tres valores que tendríamos que modificar por cada pelicula a compartir.
  • channel${número canal}: Cada película tendrá un número de canal asociado. Dicho número de canal debe ser único por cada una de éstas y generalmente irá aumentando consecutivamente (1,2...) si bien esto último es opcional. En este caso solo tendremos una película, que será la primera y última, con lo que el canal sería el 1.
  • input ${nombre película a compartir}: En el input deberemos definir cual será la pelicula que emitiremos... Aquí es muy importante establecer de forma precisa la ruta de la película en cuestión para evitar emitir contenidos vacíos.
  • output #duplicate{dst=std{access=udp,mux=ts,dst=${ip_multicast}:1234}}: Aquí es indispensable tener un mínimo conocimiento de lo que se trata una dirección ip multicast y el método de transmisión de ésta; es por ello que al principio he recomendado la lectura del anterior artículo. Esta ip sería la dirección a la que tendríamos que dirigirnos para ver la película, cosa que veremos más adelante. Obviamente la ip multicast tiene que ser única para cada pelicula, pues en caso contrario habría problemas.
Teniendo claros estos conceptos, podemos concluir que, en base al fichero de configuración anterior, tendríamos esta plantilla:

  1. new channel${número_canal} broadcast enabled
  2. setup channel${número_canal} input ${pelicula} loop
  3. setup channel${número_canal} output #duplicate{dst=std{access=udp,mux=ts,dst=${ip_multicast}:1234}}
  4. control channel${número_canal} play

Con el fichero de configuración preparado, seriamos capaces de ejecutar el demonio vlcinit.sh anteriormente creado; demonio que puede ser ejecutado en cualquier momento y con facilidad. Si por ejemplo se encontrase dentro de /etc/init.d, únicamente habría que hacer /etc/init.d/vlcinit.sh start y ya tendríamos el contenido disponible para todo el mundo; ahora bien: ¿Cómo accedemos a dicho contenido? Mediante VLC también claro está.

En este caso, obviamente, los equipos desde los cuales veremos la película deben de tener entorno gráfico, independientemente del sistema operativo que tengan siempre y cuando tengan el software VLC instalado. Simplemente habría que abrir dicho software y dirigirnos a la sección Medio --> Abrir ubicación de red...

Ubicación

Tras clickar en dicha sección, veríamos una pequeña ventana en la que nos preguntarían a que ubicación de red deseamos acceder... ¿Adivinad a qué ubicación deseamos acceder? Efectivamente. A la dirección multicast que hemos especificado anteriormente en streaming.conf. Dirección a la que siempre apuntaríamos mediante la nomenclatura: udp://@${ip_multicast}:1234; es decir que para ver Big Buck Bunny escribiríamos --> udp://@230.40.100.80:1234 tal y como se muestra en la pantalla de a continuación.

MULTICAST

Con únicamente pulsar reproducir, podríamos ver el contenido sin tenerlo almacenado en nuestro equipo... Además dicho contenido podría ser accedido desde diferentes orígenes y diferentes usuarios sin que ninguno de ellos se "molestase" al otro. Cómo nota final, diría que es recomendable compartir pocas películas mediante este método, a menos que tengamos una red preparada para trabajar con multicast, red que jamás estaría preparada para dicho tráfico en un entorno doméstico.

Espero que os haya resultado útil.

Saludos.