Información blog

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

lunes, 29 de junio de 2015

Bleachbit, el limpiador para Linux

En más de una ocasión hemos echado de menos alguna herramienta de Windows en entornos de Linux, la mayoría de las veces debido a la costumbre que hemos adquirido con el otro sistema. hoy en día existen multitud de herramientas que pueden prácticamente sustituir a sus equivalentes en Windows, pero aún así es cierto que algunas son más populares que otras y que existen ciertas herramientas Open Source que se han hecho mundialmente famosas aún cuando en un principio fueron única y exclusivamente diseñadas para Linuxeros; mientras que otras han caído en el olvido, ya sea porque son consideradas "inferiores" o debido a que no han visto la necesidad de usar estar herramientas en entornos Linux. Un buen ejemplo podría ser el desconocimiento de antivirus para Linux, pero existen también otras herramientas que aún cuando han demostrado ser bien útiles, no han logrado alcanzar la popularidad que deberían. 

Una gran prueba de ello serían por ejemplo los limpiadores del sistema. Un limpiador consisten en una herramienta que agrupa todos los medios necesarios para liberar el disco de información innecesaria que ha ido agrupándose lenta, pero paulatinamente a través del tiempo en el disco; dicha información puede ser desde el historial del navegador a archivos temporales creados por el sistema... Si pensásemos en limpiadores para Windows, la mayoría de nosotros pensaríamos en CCleaner, pues se trata de una herramienta completa y gratuita usada por la mayoría de las personas que se preocupan por mantener limpio el ordenador... ¿Pero y en Linux? Aún cuando hay que reconocer que CCleaner es una excelente herramienta, lamentablemente no ha creado ninguna versión para los Sistemas Linux, privándonos a los usuarios de estos sistemas de poder usar este limpiador... Afortunadamente existen varias alternativas muy interesantes; una de ellas se trata de Bleachbit.

Bleachbit-portada
Bleachbit se trata un limpiador diseñado tanto para Windows como para Linux cuyo único objetivo es agrupar todas las funcionalidades de limpieza de disco dentro de un solo conjunto, con el fin de facilitar la vida al usuario final y asegurar a uno que no se va a dejar ningún fichero sin revisar.

Esta herramienta, a diferencia de la mayoría que he comentado en este blog hasta el momento, se trata de una herramienta de terceros, es decir, que no puede ser instalada a través de los repositorios oficiales. Aún así, el software está diseñado para ser instalado con una enorme facilidad. Para ello es necesario dirigirse primero a la página oficial de la herramienta, al la cual se puede acceder a través de este enlace: http://bleachbit.sourceforge.net/. La herramienta ocupa muy poco espacio y afortunadamente está diseñada para ser instalada en la mayoría de los sistemas operativos, pues posee un listado de paquetes adaptados para una serie de sistemas operativos, entre los cuales se encuentras Debian 6,7 y 8; Ubuntu (desde la 12.04 a la 15.04); Fedora... Yo en mi caso he realizado las pruebas con Ubuntu 14.04 pero no deberíais experimentar problema alguna con cualquier otra distribución...

Tras tener el paquete descargado, habréis observado que se trata un paquete .deb, con lo que habrá que recurrir al comando dpkg para instalarlo... Al ver las dependencias de este paquete vi que dependía de un paquete llamado menu, el cual no viene instalado en el sistema pro defecto y que sin él el paquete bleachbit no puede ser instalado con lo que el procedimiento para instalar este paquete sería:

  1. sudo apt-get install menu
  2. sudo dpkg -i  bleachbit_1.8_all_ubuntu1404.deb

El proceso solamente debería tomar unos minutos, tras lo cual ya deberíamos ser capaces de disfrutar de esta herramienta cuya interfaz, aunque minimalista, es perfectamente funcional. He aquí la pantalla que debería mostrarnos tras su ejecución:

Carpetas

Posee únicamente de dos opciones: Analizar y limpiar. El análisis simplemente se basaría en revisar los ficheros que habría que limpiar y la cantidad de megabytes (o gigabytes) que liberaría tras su limpiado, mientras que la opción de limpiar limpiaría, valga la redundancia, dichos ficheros para liberar nuestro disco de toda aquella "basura" innecesaria. 

Como podéis apreciar no dispone de una gran variedad de opciones, pero ejecuta su tarea con velocidad y eficiencia que es al final lo que uno busca en estas herramientas.

Espero que os resulte útil.

Saludos.

sábado, 27 de junio de 2015

Agregando un disco duro con fdisk en Linux

Fdisk (Fixed Disk Setup Program) es un software instalado por defecto en Linux, cuyo objetivo es la manipulación de discos físicos. Esta manipulación va desde el listado de discos físicos instalados a la configuración de estos y es especialmente útil cuando deseas añadir un nuevo disco duro y no quieres recurrir a herramientas de terceros tales como gparted, aunque ciertamente hay que reconocer que esta última posee de una interfaz gráfica más intuitiva a diferencia del primero que se basa únicamente en la consola. Aún así ese no es motivo para usar esta excelente herramienta, y en mi opinión sería un desperdicio el no darle una oportunidad. Por ello en el post de hoy trataré de explicaros tanto las funcionalidades que posee esta herramienta como el proceso de instalación de un disco duro nuevo dentro de un sistema operativo basado en Linux.

Portada-disco

Para poder aprovechar el disco que acabamos de instalar, pero que todavía no podemos usar, es necesario empezar con el listado de los discos duros instalados junto con sus particiones. Esto puede parecer complejo desde la consola, pero afortunadamente no es así, pues es un comando corto que se puede usar en todo momento. El comando es el siguiente:

  1. fdisk -l

Dependiendo de cuantos discos hayan instalados, la información que os mostrará variará, pero entre toda la información disponible se muestra un fragmento muy interesante con respecto al disco que todavía no está configurado.

Particionado

Este comando puede parecer obvio o inútil, pero es la prueba irrefutable de que el disco está instalado y que el sistema es capaz de detectarlo, asegurándonos que en caso de tener problemas a la hora de agregar el disco, no se debe a problemas de detección. Ahora sería el turno de crear una partición en dicho disco, pues no posee particionado alguno. Para ello habría que recurrir al comando fdisk nombre_del_disco tal que así:

  1. fdisk /dev/sdb

Dicho comando nos permitirá manipular el disco duro a nuestro gusto, otorgándonos una amplia variedad de opciones, opciones que por defecto están ocultas a menos que se pulse la tecla m, tras lo cual se mostraría esta guía:

Opciones-fdisk

Como podéis apreciar, el menú muestra todas las acciones disponibles dentro de esta herramienta, aunque en este caso solamente nos interesan dos: El primero se trata del parámetro n, que es el encargado de crear la partición que necesitamos para nuestro sistema, la cual puede ser primaria o extendida (p y e, respectivamente). En este caso en concreto usaremos una partición primaria, ya que se adapta más a nuestras necesidades, pero esto varía dependiendo de lo que busquemos. Además habrá que especificar el número de partición y el tamaño de ésta. Ambos parámetros son completamente configurables, si bien hay que tener en cuenta que el número de partición siempre oscilará entre 1 y 4, y que el tamaño de la partición puede ser especificado en Kilobytes, Megabytes o Gigabytes mediante las letras K,M y G. Estos parámetros ya poseen unos valores por defecto que son perfectamente válidos para lo que queremos, pues por defecto está diseñado para crear una sola partición (especificada con el número 1) que ocupa todo el disco, tal que así:

Cambios-fdisk

Los cambios han sido realizados, pero no aplicados; para poder aplicar los cambios y así modificar la tabla de particiones del disco duro, es necesario escribir los cambios, para lo cual es necesario recurrir al segundo parámetro que nos interesa, denominado w, encargado de aplicar los cambios en el disco y salir de la utilidad fdisk.

A primera vista puede parecer que ya poseemos el disco en cuestión preparado, pero no es así, pues falta darle formato a la partición que hemos creado en dicho disco para usarla. Existen muchos tipos de particiones, pero la más popular en Linux (y la que vamos a usar) es ext4. La herramienta usada para formatear la partición se denomina mkfs (Make File System) y posee diferentes variantes, dependiendo del formato que deseamos dar a la partición. En este caso deseamos un sistema de ficheros ext4 con lo que el comando sería:

  1. mkfs.ext4 /dev/sdb1

El tiempo necesario para dar formato al disco varía, pero no debería suponer más de un par de minutos. Al concluir el formateo, el disco sería perfectamente operativo. Una forma de darle uso a este nuevo disco podría ser mediante la creación de una carpeta a la que podríamos llamar disco, dentro de la carpeta /usr/src/ y montar la recién creada partición mediante el comando mount:

  1. mount /dev/sdb1 /usr/src/disco/


Montar el nuevo disco durante el arranque

Con lo mencionado hasta ahora el disco sería completamente operativo. El problema radica que ahora mismo el disco tendría que ser montado a mano con el comando mount cada vez que se reinicie, algo que puede resultar engorroso, especialmente si le quieres dar un uso asiduo. La solución pasa por modificar el fichero /etc/fstab, ya mencionado anteriormente para aplicar ACL o cuotas en Linux. Dicho fichero almacena los discos y particiones que se quieren que se arranquen el inicio y para poder agregar nuestra nueva partición, primero necesitamos conocer su UUID, el cual se consigue mediante el comando blkid. El comando no requiere parámetros, y muestra tanto los UUID de cada partición como su sistema de ficheros.

UUID-discos

En este caso únicamente nos interesaría el UUID de /dev/sdb, el cual tendría que ser copiado al fichero /etc/fstab sin las comillas. Además del UUID sería necesario especificar el punto de montaje, el sistema de ficheros y otros parámetros que perfectamente pueden ser copiados de la configuración de /dev/sda1. La línea a añadir en fstab sería muy parecida a la siguiente (cambiar el UUID por el vuestro):

  1. UUID=494f93d3-6e27-415c-9b8e-c72039470f24 /usr/src/disco/       ext4    errors=remount-ro 0     1

Con el cambio aplicado, estaríamos despreocupados de tener que montar manualmente el disco en futuros reinicios.


Eliminar la partición

Aunque este apartado es algo que no está sujeto a las intenciones de esta publicación, considero que ya que nos hemos adentrado en las utilidades de fdisk, sería un desperdicio no mencionar una de las utilidades más usadas después de la creación de particiones: La eliminación de éstas.

El proceso es tan sencillo como volver a escribir:

  1. fdisk /dev/sdb

Dentro del abanico de opciones antes mencionado, está el parámetro d. Únicamente con presionar dicha tecla y escoger el número de partición deseado (en caso de haber solo una borraría automáticamente esa sin preguntar) procederíamos al borrado de la partición. No olvidéis aplicar los cambios con el parámetro w, pues sino los cambios no se aplicarán en el disco.

Eliminar-partición

Espero que os resulte útil.

Saludos.

viernes, 26 de junio de 2015

Términos y condiciones de Google, más claros que nunca

Diez de la noche, una noche como otra cualquiera, uno se acerca a su correo de Gmail para consultar el correo, pues el móvil se ha quedado sin batería y además siempre resulta más cómodo leer los correos desde una pantalla grande, y se topa una vez más con una de las famosas ventanas que se muestran tras loguearse uno, ya sea por revisiones de seguridad u otros motivos... En este caso en particular, el mensaje me resultó curioso, pues no trataba de asuntos de verificaciones ni de seguridad, sino de los términos y condiciones de Google. Para aquellos que se puedan temer algo con respecto a éstos, les diré que no han añadido nada nuevo sino que se han limitado a asegurarse que el usuario entiende y está de acuerdo con lo que se atañe cuando se conecta con una cuenta de Google. 
Como persona curiosa que me considero, eché un vistazo rápido a lo que explicaban, por si habían variado la forma de expresarlo o si habían resaltado algún punto que tal vez pudiese ser considerado como "escandaloso". El resultado de esa pequeña búsqueda fue que efectivamente habían modificado su forma de expresarse, una modificación que en mi opinión ha sido muy de mi agrado, ya que, aunque todos sabemos que Google lo sabe todo sobre nosotros, siempre nos han explicado sus términos y condiciones con enormes párrafos que hastiosos de leer. Esta vez el comunicado de éstas se ha realizado en un formato mucho más simple y esclarecedor; y aunque me sería imposible mostrar todo el contenido, os muestro el fragmento que he considerado como más importante:


Esto sería solo una parte, pero creo que explica con gran claridad la información que toman y el uso que hacen de ésta. Una estructura simple pero que al mismo tiempo te informa de lo esencial... Básicamente indican que toda actividad que se realice desde nuestras cuentas pasará a conocimiento de Google, incluyendo las búsquedas realizadas en youtube.

No veo necesario entrar en el debate ético del uso de nuestros datos o del control que tienen sobre nuestras personas. Lo importante en esto términos es que ahora el usuario final no tiene escusas para pasar por alto los términos o no prestar atención a éstos, ya que esta vez los han explicado de forma clara y concisa.

Ahora bien... ¿Cuantas personas conocéis que se preocupan por estas cosas o que se hayan leído siquiera por encima los términos a los que están sujetos la mayoría de las herramientas gratuitas que usan? La mayoría los contaríamos con una mano y nos sobrarían dedos...

Hay que reconocer que Google ha puesto los medios para que el usuario sea consciente de a lo que se atiene cuando usa sus servicios; ahora es el turno de que el usuario ponga de su parte... ¿Llegará dicho día? Yo espero fervientemente que sea así.

Saludos.

jueves, 25 de junio de 2015

Cambiando la MAC con macchanger

Una MAC (Media Access Control), también conocida como dirección física, es un identificador único asociado a nuestra tarjeta de red; algo parecido a un DNI que identificaría la dirección física del dispositivo. Dicha dirección consta de 6 campos separados por puntos; campos que están compuestos por dos caracteres. La MACs tiene varios usos, pero los más comunes son la asociación de la MAC un dispositivo en concreto para saber si dicha MAC está haciendo algo ilícito; asociación de una MAC a un fabricante en concreto o el establecimiento de una serie de reglas de red en base a dicha MAC.

Aunque alguna vez ha sido mencionado en este blog, es importante saber que los tres primeros campos de la MAC son privados y siempre están asociados a una marca o fabricante en concreto, lo cual puede ser de ayuda cuando por ejemplo tienes una red que supuestamente sólo posee tarjetas de red de elitegroup, y de pronto ves un dispositivo con una mac perteneciente a apple... Una buena página que puede proveernos de información sobre las MACs y los fabricantes es:


Teniendo estos conceptos claros, imaginemos que nos vemos en la situación de que nuestra MAC ha sido filtrada por el cortafuegos ,debido a un error administrativo o a un firewall mal configurado que ha añadido por error nuestra MAC a su "lista negra". Cambiar de equipo o de tarjeta de red no es una opción, con lo que hay que optar por un remedio más rápido y eficiente: El MAC spoofing, también conocido como el suplantación de MAC. Dicha técnica consiste en ocultar la dirección MAC original bajo una MAC diferente (ya sea real o ficticia) con el fin cambiar la "identidad" del ordenador y/o tarjeta de red. 

Existen numerosas herramientas para lograr este objetivo, todo depende del entorno en el que estemos trabajando, pero una de las más famosas es macchanger, un software para Linux que funciona por consola, capaz de cambiar la MAC ya sea de forma automática o manual.

Esta herramienta no está incluida en sistema operativo por defecto, pero está incluida en los repositorios oficiales, con lo que no supone ningún problema para nosotros, pues simplemente habría que escribir:

  1. apt-get install macchanger

Durante el proceso de instalación habrá un momento en el que se nos preguntará si queremos que cada vez que una interfaz de red se active, su MAC sea sustituida automáticamente con una MAC generada de forma automática por la herramienta. Esto es algo completamente a la elección del usuario pero yo recomiendo NO hacerlo para tener un control total.

Con la instalación concluida, ya tendríamos control total sobre nuestras MACs; sólo faltaría tener los conocimientos para manipularlas. La manipulación de una MAC SIEMPRE se debe hacer con la interfaz de red desactivada; lo cual se logra mediante el comando ifdown. Con la interfaz desactivada, se nos presentarían tres posibles acciones:

  • La primera acción es la que habría realizado el software en caso de haber habilitado la sustitución de MAC automática para las interfaces de red. Esta opción simplemente generaría una MAC completamente aleatoria y y el parámetro para realizar dicha acción sería el -r. Así pues, si quisiésemos sustituir la MAC de la interfaz eth0 con una MAC aleatoria, habría que escribir:

  1. macchanger -r eth0

  • La segunda acción posible es un poco menos usada, pero igual de útil que la anterior. Se trata de la sustitución de MAC con una MAC introducida manualmente por nosotros. Esto puede venir bien cuando se quiere poner una dirección física con unas directrices especificas como por ejemplo que sus tres primeros campos tengan una composición específica para que emular que se tiene una interfaz de un fabricante distinto. Además esta opción es muy interesante porque te concede más control que la primera. Para usar esta acción se recurre al parámetro -m, y si nos basásemos en el ejemplo anterior el comando sería:

  1. macchanger -m 00:50:56:DA:AE:WE eth0

  • Por último, pero no menos importante, está la restitución de la dirección física original. Imaginemos que hemos cambiado la MAC y queremos dejarla como estaba originalmente; es decir, restaurar la dirección física original de la interfaz de red. La técnica del MAC spoofing siempre se basa en el enmascaramiento de la dirección real, con lo que simplemente habría que desenmascararla mediante el parámetro -p (permanent)tal que así:

  1. macchanger -p eth0

Estas serían las tres acciones posibles. Para poder disfrutar de los cambios realizados, únicamente habría que activar la interfaz de nuevo mediante el comando ifup.

Saludos.

lunes, 22 de junio de 2015

Habilitar NPAPI en versiones posteriores a Chrome 42

NPAPI (Netscap Plugin Application Programming Interface) ha sido hasta ahora el sistema que posibilitaba el uso de plugins y extensiones en Google Chrome. Cuan grande ha sido mi sorpresa cuando un día, entrando a un sitio que obligaba el uso de Java desde Google Chrome (el cual usa NPAPI) no tenía la posibilidad de activar el plugin cuando anteriormente nunca había tenido problema alguno. Así pues, comencé a investigar un poco y descubrí que el sistema NPAPI ha sido considerado obsoleto por Google, pues según éste ya no es apenas usado por la mayoría de las extensiones, ya que hoy en día se usa PPAPI (Pepper API). Dejando de lado mi opinión personal al respecto, lo importante en referencia a este punto es que esta decisión ha hecho que plugins que hasta hace relativamente poco funcionaban sin problemas, ya no tengan la capacidad de funcionar en chrome... En un principio uno esperaría que los plugins que estén usando ese sistema "obsoleto" sean poco conocidos, pero lamentablemente no es así, pues entre estos se encuentran: Java, Silverlight y Unity.

Esto es un gran problema para los usuarios de Chrome, ya sea para el uso cotidiano o social (varios juegos en facebook usan Unity) o para el uso más profesional como podría ser la conexión a una VPN vía web, web que requiere el uso de java para poder conectarte a dicha VPN. Debido a esto, a uno se le presentarían dos opciones: La primera sería optar por usar otro navegador, como podría ser Firefox; o optar por hallar la forma de habilitar NPAPI en chrome. Afortunadamente, de momento NPAPI está deshabilitado en chrome, pero tiene la capacidad de ser habilitado (de momento) de nuevo, aún su política es deshabilitarlo por defecto. 

Para ello habría que dirigirse al navegador Chrome y escribir la siguiente URL:

chrome://flags/#enable-npapi

Dicha URL nos dirigirá a una ventana con multitud de opciones, pero gracias a que se ha escrito dicha URL seremos llevados a la sección deseada resaltada en amarillo tal y cómo aparece en la siguiente captura donde también os resalto la opción de Habilitar.


Con simplemente pulsar el botón de Habilitar y reiniciar el navegador, ya podríamos navegar con normalidad, olvidándonos de cualquier problema con plugins tales cómo Java. Por desgracia este cambio sólo servirá de manera temporal pues el soporte NPAPI será removido de forma permanente con la versión 45 de Chrome, la cual saldrá el 15 de Septiembre.

Saludos.

domingo, 21 de junio de 2015

SPA, la evolución del port knocking

Recientemente me encontraba leyendo un par de artículos en referencia al port knocking; artículos que en un principio pensaba que no me iban a explicar nada demasiado nuevo ya que hace tiempo que estuve haciendo varias pruebas con él e incluso hablé de él en este blog. Para aquellos que no hayan leído dicho post, se podría explicar a modo de resumen que el port knocking se basa en "tocar" varios puertos en una secuencia correcta para abrir un puerto en concreto temporalmente; cosa muy útil para que el puerto ssh se sólo se pueda abrir bajo dicha secuencia. Dicha protección no es infalible, pues siempre se puede intentar adivinar la secuencia en cuestión (aunque después hayan otras protecciones) pero siempre viene bien añadir una capa extra de seguridad. Dicha protección a evolucionado a un nuevo nivel, en el cual el concepto ha cambiado radicalmente; se trata del SPA o Single Packet Authentication.


Este concepto se basa en un concepto completamente distinto al por knocking. En este caso se trata de enviar un único paquete cifrado con la intención de abrir un puerto en concreto. Esto tiene ventajas con respecto a la seguridad frente al método anterior; lamentablemente el uso de SPA requiere que los equipos cliente y servidor, tengan algunas configuraciones especificas, mientras que en el port knocking toda configuración depende única y exclusivamente del servidor; cosa que es importante tener en cuenta al a hora de escoger uno de los dos métodos de apertura de puertos. Un esquema que podría explicar con precisión el la infraestructura SPA sería éste:


Para usar el método SPA, es necesario contar con una herramienta, que se puede descargar en dos variantes distintas. Se trata de la herramienta fwknop, la cual dependiendo de si lo descargas en un servidor o un cliente, habría que descargar la herramienta fwknop-server o fwknop-client respectivamente. Comencemos con el lado del servidor, pues es el más importante y el más "delicado". Comencemos con la parte del servidor.

Configuración del servidor SPA

Para ello habría que empezar con lo más básico, que se trataría de la descarga del paquete. Afortunadamente, tanto el software para el cliente como para el servidor se encuentran en los repositorios oficiales del sistema operativo, con lo que simplemente habría que hacer:

  1. apt-get install fwknop-server

El proceso de instalación es muy breve, pues al final no se trata de nada más que un servicio que interactua con iptables para brindar acceso por un puerto que inicialmente se encontraba bloqueado. Aún así no basta con instalar el paquete, también es necesario configurarlo, para lo cual sería necesario dirigirse al directorio /etc/fwknop, el cual almacena dos ficheros: access.conf y fwknopd.conf


El primero, access.conf, se basa en la configuración de las políticas de acceso al servidor. Esto hace que sea necesario configurarlo, pues con la configuración por defecto no es suficiente para lograr nuestro objetivo; así pues en el fichero en cuestión hay una serie de parámetros que son realmente importantes:

  • OPEN_PORTS: Este se trata de parámetro más importante de todos, pues es el que se encarga de abrir los puertos que se le indique tras recibir el paquete SPA. A la hora de especificar los puertos que se quieren definir, siempre habría que especificarlo de la siguiente forma: puerto/protocolo.
  • SOURCE: Este parámetro está correctamente configurado por defecto, pues está ya preparado para aceptar el SPA desde cualquier origen, pero perfectamente puede especificarse otro.
  • KEY: Este parámetro varía dependiendo de nuestras necesidades. Puede ser KEY, o puede ser KEY_BASE64 (que permitiría caracteres especiales) o también HMAC_KEY_BASE64, el cual ya incluye opciones de cifrado. En este caso optaremos por un KEY_BASE64, que es más flexible que el parámetro KEY.
  • FW_ACCESS_TIMEOUT: Por último pero no menos importante está el establecimiento del tiempo que va estar abierto el firewall en segundos. En caso de no establecer ningún tiempo, el firewall se quedaría abierto indefinidamente, con lo que no sería una medida segura.
Basándonos en estos tres parámetros, bien podríamos crear un fichero access.conf con el siguiente contenido:

  1. OPEN_PORTS: tcp/22;
  2. SOURCE: ANY;
  3. KEY_BASE64: ivan;
  4. FW_ACCESS_TIMEOUT: 600;

El fichero fwknopd.conf no sería necesario configurarlo pues por defecto ya está cumple con los requisitos para lo que nosotros buscamos. Como habréis podido observar, únicamente está contemplado para abrir el puerto 22 del protocolo tcp, el resto de puertos permanecerían cerrados. Para asegurarnos que nuestro puerto ssh va a estar inaccesible para todo aquel que no posee la información necesaria, un script de iptables con una configuración MUY básica podría ser la siguiente:

  1. #!/bin/bash
  2. iptables -A INPUT -j DROP
  3. iptables -A INPUT -i lo -j ACCEPT
  4. iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Teniendo todo correctamente configurado, simplemente quedaría reiniciar el servicio fwknop mediante el comando /etc/init.d/fwknop-server restart, y ya estaría la parte del servidor preparada.

Configuración del cliente SPA

En este caso la configuración es mucho más sencilla que en el servidor, pero es indispensable tener primero instalado el cliente fwknop. Para ello comenzaríamos instalándolo mediante el comando:

  1. apt-get install fwknop-client

Con el cliente instalado, en este caso no es necesario configurar ningún fichero, sino que sería el turno de enviar el paquete SPA que se encargará de abrir el puerto. Dicho proceso posee la siguiente estructura:

fwknop -A ${protocolo}/${puerto} -D ${ip_destino} -a ${ip_origen}

En mi caso, por ejemplo, el comando sería:

  1. fwknop -A tcp/22 -D 192.168.1.7 -a 192.168.1.8

Al teclear dicho comando, la consola nos preguntará qué contraseña hemos establecido. En este caso se trataría de la password ivan, pero en el vuestro sería otro completamente distinto. Si la contraseña es correcta, el servidor debería abrir el puerto durante los segundos estipulados, quedando únicamente acceder por ssh al servidor. 

Obviamente, aunque este concepto ha sido únicamente aplicado al acceso por ssh, puede ser aplicado a cualquier otro puerto.

Saludos.

jueves, 18 de junio de 2015

Cómo copiar un archivo por red mediante SCP

SCP (Secure Copy) es un protocolo de transferencia de archivos que se realiza a través del protocolo SSH. Esto ofrece como ventaja el hecho de que la transferencia de archivos es cifrada, evitando que la comunicación se vea comprometida, aunque para poder hacer la transferencia es necesario conocer las credenciales de acceso del equipo remoto, pues en caso contrario la transferencia no podrá realizarse. Aún así, este es sin duda el método favorito de la mayoría de las personas que trabajan o han trabajado alguna vez con un entorno basado en Linux. Solamente requiere que ambos equipos tengan SSH instalado y que se tenga acceso a dicho puerto (es decir, que el cortafuegos no nos bloquee o que el puerto no esté cerrado), ya que la herramienta necesaria para realizar la transferencia está instalada por defecto en el sistema.
La transferencia es bidireccional, es decir que puede transferirse un archivo de un equipo remoto a nuestro propio PC sin la necesidad de tener que ejecutar el comando desde el otro equipo, lo cual nos permite actuar con gran libertad, y tiene la gran ventaja de que el comando de transferencia es muy sencillo y rápido de aplicar.

Supongamos que poseemos SSH instalado en ambos equipos y que deseamos realizar una transferencia. Para ello hay que tener muy clara la estructura que poseen estas transferencias:

scp -r ${archivo_a_copiar} ${destino de la copia}

El comando es sencillo, pero lo mejor para entender cómo darle un uso real es mediante la exposición de diversos ejemplos. Cómo veréis estos ejemplos tienen una estructura ligeramente parecida a la estructura de una conexión ssh. En este caso voy a exponer 4 ejemplos, 3 de ellos con una finalidad distinta y otro de ellos de carácter global.

El primer ejemplo es el más común de todos: Se trata de la transferencia de un archivo desde nuestro propio equipo a otro. En este caso en concreto voy a transferir desde mi equipo un fichero denominado fichero.txt a otro equipo con el usuario ivan. Dicho equipo posee la ip 192.168.1.5 y quiero transferir el archivo a su directorio personal, /home/ivan:

  1. scp -r /usr/src/fichero.txt ivan@192.168.1.5:/home/ivan

Podéis apreciar que en el ejemplo, la conexión al equipo remoto sigue la misma estructura que una conexión ssh, es decir que a la hora de referirse a un equipo remoto la estructura siempre sería:

usuario@ip:ubicación

Visto esto sigamos al siguiente ejemplo; En este caso vamos a realizar el mismo procedimiento pero a la inversa, lo cual no requiere nada más que invertir el orden:

  1. scp -r ivan@192.168.1.5:/home/ivan/fichero.txt /usr/src/

Por último, hay otro uso que se le puede dar a SCP. Este uso es algo menos habitual, pero no por ello menos útil. Se trata de la transferencia de archivos entre dos máquinas remotas. Eso significa que siempre y cuando las tres máquinas (las dos remotas y la vuestra) cumplan los requisitos para una comunicación por SSH, no será necesario desplazarse a ninguna de las dos remotas para realizar la transferencia deseada. El comando en cuestión sería:

  1. scp -r ivan@192.168.1.5:/home/ivan/fichero.txt invitado@192.168.1.6:/home/invitado/

Habéis visto en los ejemplos que siempre he incluido las rutas en las que se almacenarán las copias que vamos a realizar, pero no es un requisito; Es posible dejar la ruta de destino en blanco, en cuyo caso el fichero SIEMPRE irá a parar a la carpeta personal del usuario, con lo que basándonos en el ejemplo anterior, un comando igualmente válido sería:

  1. scp -r ivan@192.168.1.5:/home/ivan/fichero.txt invitado@192.168.1.6

Espero que os resulte útil.

Saludos.

miércoles, 17 de junio de 2015

Cómo establecer cuotas de usuario en Debian

En esta ocasión voy a hablaros sobre el establecimiento de cuotas de usuario en un sistema operativo Debian o similar. Cuando un equipo es usado por varios usuarios, uno se puede encontrar con el problema de que algunos individuos llenan el disco duro con una gran multitud de programas, impidiendo que el resto tenga el espacio suficiente para instalar cualquier aplicación... Para evitar estas desigualdades están las cuotas de usuario, las cuales están deshabilitadas por defecto en la mayoría de los sistemas operativos Linux. El motivo es que en Linux se suele instalar lo mínimo y necesario, y luego más allá de lo mínimo suele ser necesario realizar las instalaciones y/o modificaciones necesarias.


Por fortuna el establecimiento de cuotas es relativamente sencillo. Para ello es indispensable modificar el fichero /etc/fstab de forma parecida a cómo hicimos recientemente a la hora de crear ACLs. El establecimiento de cuotas de espacio en el disco, se realiza por particiones; es decir que si por ejemplo tienes varias particiones en un sistema operativo (cómo por ejemplo una partición /home y luego el resto en otra partición) puedes hacer que la cuota se ponga únicamente para home, dejando el resto del sistema de archivos intacto. En este caso estableceremos una cuota para todo el disco, pero recalco que no es necesario; todo depende del particionado que se haya realizado. En este caso, la modificación que hay que realizar en el fichero es algo grande, con lo que lo he recalcado en negrita para que tengáis mayor facilidad para guiaros.

  1. UUID=ab6e3da5-35ff-4c82-89e3-0c70064442c1 /               ext4    errors=remount-ro,usrjquota=aquota.user,grpquota=aquota.group,jqfmt=vfsv0 0       1

Obviamente el UUID es el que yo tengo en el equipo, en vuestro caso sería completamente distinto. El cambio aquí radica en el establecimiento de tres nuevos parámetros: usrjquota, grpquota y jqfmt. Estos parámetros consisten en el la activación de cuotas por usuarios, activación de cuotas por grupos y la especificación del a qué tipo de cuota hay que hacer soporte respectivamente. Los dos primeros valores son estáticos e inamovibles; es decir que son como son, pero en el caso del parámetro jqfmt hay que saber qué tipo de cuota soporta nuestro sistema, pues existen de tres tipos:
  1. vfsold. Lo cual equivale a la versión 1 de cuota.
  2. vfsv0. Lo cual equivale a la versión 2 de cuota (es el más común)
  3. xfs. Este soporte únicamente se usa en sistema de ficheros xfs.
Con el cambio realizado, llegaría el turno de montar de nuevo el disco duro, o reiniciar el sistema. En caso de optar por la primera opción el comando sería:

  1. mount -o remount /dev/sda1

Con el disco duro preparado habría que cargar el módulo necesario para poder realizar las labores de cuota de disco. En este caso el módulo está preparado en el sistema pero sin activar; para solventar ese problema habría que hacer dos cosas: Activar el módulo y obligar al sistema a que cargue el susodicho durante el arranque para evitar activarlo a mano cada vez que se arranque el sistema. Para lograr dicho objetivo habría que teclear estos dos comandos:

  1. modprobe quota_v2
  2. echo quota_v2 >> /etc/modules

El primero se encargaría de realizar la activación manual del módulo, mientras que el segundo ha hecho que éste se cargue automáticamente cada vez que se inicie el sistema. El problema es que aún con todo esto preparado, no tenemos ningún fichero que vaya a almacenar las políticas de cuotas de usuarios y grupos. Si observáis bien la modificación realizada en el fichero fstab, veréis que en los parámetros userjquota y grpquota se han establecido dos valores llamados aquota.user y aquota.group; Ambos se tratan de ficheros que van a almacenar las políticas de cuota de los usuarios y grupos; ficheros que por defecto no existen y es necesario crearlos. Éstos ficheros siempre deben estar ubicados en el directorio principal de la partición (en este caso en /, si por ejemplo estuviésemos haciendo este procedimiento para la partición home se tendrían que crear en la carpeta home). En mi caso en particular debo de crear los ficheros en el directorio / con el usuario root (indispensable) tal que así:

  1. touch /aquota.user
  2. touch /aquota.group
  3. chmod 600 /aquota.user /aquota.group

Cómo podéis apreciar, no solo he creado los ficheros, sino que también me he asegurado que únicamente root posee permisos para manipularlo mediante el comando chmod, evitando que cualquier usuario tenga siquiera permiso para consultar lo que hay en su interior.

Estableciendo las cuotas:

Con todos los preparativos realizados, llegaría el turno de establecer los límites deseados a cada usuario; existen algunas alternativas, pero en este caso voy a optar por la más popular de todas: quotatool. Este software no está instalado en el sistema por defecto, con lo que es necesario descargarlo e instalarlo, aunque al estar incluido en los repositorios oficiales de Debian únicamente habría que escribir:

  1. apt-get install quotatool

Es recomendable instalar el paquete ANTES de realizar los preparativos, pues en caso no haberlo hecho sería necesario reiniciar la herramienta mediante el comando /etc/init.d/quota restart para que el sistema sea capaz de realizar las tareas. En caso de haber instalado el software antes de hacer los preparativos y no haber reiniciado la herramienta, si intentáis establecer una cuota os aparecerá un mensaje como el siguiente:


Además, quotatool no se activa tras su instalación a menos que se lo ordenemos o reiniciemos el sistema. Cómo queremos evitar dicho reinicio escribiremos:

  1. quotacheck -vagum

Supongamos que hemos seguido el procedimiento paso a paso y que nos hemos asegurado de que tenemos todo cargado correctamente; Llegaría el turno de introducir el comando para crear las cuotas; aún así, antes de mostrároslo, es necesario que cuando se establece una cuota de disco, existen dos típos de límites; el límite "blando" y el límite "duro". El límite blando consiste en el límite recomendable por cada usuario; en caso de alcanzar dicho límite el usuario recibiría un aviso de que que está excediendo el límite recomendable para su usuario. El límite duro en cambio es absoluto, y el sistema nunca permitirá al usuario sobrepasar dicho límite. Lo normal al establecer limitaciones, suele ser poner las dos, con el fin de que a partir de cierto límite el usuario quede sobre aviso de que se le esta acabando la tasa de espacio en el disco y/o partición. La estructura que tiene el comando quotatool ya sea para un usuario o un grupo es la siguiente:

quotatool -u ${usuario} -bq ${límite_blando} -l ${límite_duro} ${partición}
quotatool -g ${grupo} -bq ${límite_blando} -l ${límite_duro} ${partición}

La única diferencia entre el escribirlo para un usuario o un grupo radicaría en el parámetro -u (para un usuario) y -g (para un grupo). El límite de espacio se puede establecer en bytes, megabytes, gygabytes o lo que uno desee, siempre que uno respete la sintaxis:


Con esto aclarado, vamos a exponer un pequeño ejemplo en el cual estableceré que el usuario ivan, reciba un aviso de que se le está acabando el espacio que tiene disponible a partir de los 200 megabytes y que tenga un límite de 250 megabytes. Dichas limitaciones se aplicarían a la partición /, con lo que el resultado sería:

  1. quotatool -u ivan -bq 200M -l 250M /

En caso de haber seguido el procedimiento correctamente, no debería mostraros mensaje alguno; en caso de que os muestre algún error, os recomiendo que reiniciéis el servicio quota y que probéis de nuevo. Ahora bien; imaginemos que no ha mostrado mensaje alguno: ¿Cómo podemos saber que efectivamente, el usuario en cuestión tiene la cuota que nosotros hemos definido? Existen dos formas: La primera es tratando de llenar el disco todo lo posible hasta alcanzar la cuota de dicho usuario: la segunda en cambio se trata de un pequeño comando que nos muestra la cuota que hemos asignado al usuario, dicho comando se trata del comando quota, y posee la siguiente estructura, ya sea para el usuario o el grupo:

quota -u ${usuario}  -vs
quota -g ${grupo} -vs

En este caso, vamos a revisar la cuota que hemos aplicado a nuestro usuario (en mi caso ivan), lo cual nos tendría que mostrar algo parecido a lo siguiente:



Espero que os sea útil.

Saludos.

lunes, 15 de junio de 2015

Cómo crear un servidor DHCP en Linux

Hoy vengo a hablaros sobre cómo crear un servidor DHCP en Linux. DHCP (Dynamic Host Configuration Protocol) no es ni más ni menos que un servicio encargado de entregar de forma dinámica direcciones ip a aquellos equipos que estén pidiendo una y cumple una función vital en el día a día de todos los usuarios sin que muchos se den cuenta: Cuando un usuario se conecta a una red wifi, es el DHCP quien se encarga de gestionar la entrega de ip al equipo que se acaba de conectar; al igual que pasa en una red local en la que uno conecta cualquier equipo a esta red y sin tener que hacer nada ya es capaz de salir a Internet. En resumidas cuentas hablaríamos de una ip que ha sido asignada de forma automática por un servidor, evitando así cualquier intervención por parte del usuario final.
Este proceso obviamente consta de dos o más participantes: El servidor DHCP hace las veces de gestor de direcciones ip y posee la capacidad de no sólo entregar direcciones ip; sino que de memorizar a quien ha sido entregada dicha dirección. Obviamente esto no sería posible si los equipos que se conectan a la red no "pidiesen" a gritos una dirección ip con la que poder comunicarse con el resto; ya sea en un equipo Linux o Windows, tienen que estar configurados para ser clientes DHCP para poder pedir una dirección ip; cosa para la que están todos configurados por defecto. El proceso de obtención de ip consta de 4 pasos:
  • DHCP Discovery: Tan pronto cómo un equipo configurado parar ser cliente DHCP se conecta a una red; éste solicita un servidor DHCP que le entregue una ip. Esta petición no va a un servidor DHCP en concreto con lo que en caso de haber más de un servidor DHCP en la misma red, la petición les llegaría a ambos servidores. Es por ello que la existencia de más de un servidor DHCP en la misma VLAN o red resulta peligrosa y/o problemática.
  • DHCP Offer: Una vez el servidor DHCP recibe la petición de ip desde un equipo; le envía un paquete con una serie de parámetros de red, los cuales incluyen la ip, la máscara de red y la MAC del servidor (entre otros).
  • DHCP Request: Si el cliente ha recibido el paquete "offer" exitosamente, éste revisa los parámetros que el servidor le ha enviado y le solicita al servidor la ip que éste le ha ofrecido.
  • DHCP Acknowledge: Por último, si el servidor ha recibido el paquete DHCP Request exitosamente, éste envía un paquete DHCP ACK (abreviación de acknowledge) al cliente; paquete que simplemente consta de una confirmación de recepción del "request". Con dicha verificación realizada, el servidor añade la dirección ip y física del cliente a su lista de clientes y el cliente configura su tarjeta de red con los parámetros de red que se han negociado durante el proceso offer y request.
Una imagen que explicaría este proceso de forma simple sería la siguiente:


Con estos conceptos estaríamos listos para proseguir a la parte de la instalación y configuración del servidor DHCP en un sistema Linux. Para ello, lo primero que habría que hacer es instalar el paquete que nos permitirá que nuestro sistema sea capaz de actuar cómo servidor DHCP; por fortuna solo se trata de un paquete, el cual está incluido en los repositorios oficiales de cualquier sistema operativo, ya esté basado en Debian o en Red Hat. Para instalar el software en cuestión habría que escribir en la consola:

En Debian:

  1. apt-get install isc-dhcp-server

En Red Hat:

  1. yum install dhcp

Una vez instalado el software, solamente faltaría configurarlo. Existen varios tipos de configuraciones; algunos más básicos que otros pero todos igual de funcionales. Aún así, antes de meternos en el reparto de direcciones ip, conviene tener presentes tres parámetros globales muy importantes:
  • Default-lease-time: Es el número de segundos que tiene validez la ip entregada; Dicho número de segundos es asignado al cliente que recibe la ip para que así, en caso de que el cliente no tenga dicho número asignado, posea uno. Una vez pasado dicho tiempo, el cliente tendría que preguntar que realizar el proceso de petición de ip de nuevo con el fin de renovar la validez de ésta. El valor por defecto es 600 segundos.
  • Max-lease-time: Es el número de segundos que tiene validez la ip entregada para el servidor. Pasado dicho tiempo, si el cliente no ha renovado la ip o no la está usando debido a que el equipo está apagado y/o ya no está conectado a la red; la ip del cliente cómo su MAC son borrados de la lista de direcciones almacenada en el servidor. El valor por defecto es de 7200 segundos.
  • Authoritative: Especifica que este servidor DHCP tiene sobre el resto. Esto hace que en teoría, en caso de haber más de un servidor DHCP en la misma red, aquel que tenga el parámetro Authoritative tenga prioridad sobre el otro, pero desafortunadamente no es un parámetro demasiado fiable. En este caso no existen un valor por defecto; se trata de añadir este valor al fichero o no.
Un ejemplo de un DHCP muy simple, pero que bastaría para que los equipos que reciban ip se comuniquen con el resto sería:


Esta configuración es muy básica y no es funcional; pero sirve cómo un DHCP de pruebas. Ahora veremos cómo mejorar esta configuración, pero antes vamos a revisar cada uno de estos parámetros:
  1. Subnet: Este parámetro especificaría el rango de red en el que se trabajaría; esto viene bien a la hora de trabajar con distintas VLANes y simplemente habría que asignar la subred sobre la que se trabaja. En una red local del hogar por ejemplo, la subred sería 192.168.1.0
  2. Netmask: También conocida como mascara de red. Para entender este parámetro hay que tener algunas nociones de redes pero a grandes rasgos, sería el factor que determinaría el rango de equipos con el que sería capaz de comunicarse y entregar ip.
  3. Range: Aquí habría que establecer el rango de red que abarcaría el DHCP. Todo DHCP posee un rango de direcciones que puede otorgar a sus clientes. A mayor el rango, mayor el número de clientes al que puede dar servicio.
  4. Option routers: Esto sería nada menos que la puerta de enlace; Sin ésto, los equipos no tendrían posibilidad de acceder a Internet.
Esto puede parecer funcional, pero no es así. Cualquiera que haya recibido los parámetros de este DHCP podría comunicarse con el exterior, pero de forma muy aparatosa e ineficaz, pues aunque podrían comunicarse con la ip (por ejemplo) 8.8.8.8, que sería la ip del DNS de google, no serían capaces de navegar por Internet con normalidad, pues no tienen la capacidad de resolver nombres. Para lograr solventar dicho inconveniente habría que modificar un poco la configuración anterior para que aquellos que reciban ip no tengan problemas:

El cambio simplemente radica en añadir una línea llamada option domain-name-servers. Dicho parámetro establece uno o varios DNSs, y con ésto ya estarían los clientes listos para navegar por internet. Aún así se puede mejorar la configuración tal para que sea más funcional. Una configuración más habitual y funcional sería ésta:


Cómo podéis ver, se puede especificar el número de segundos que tienen validez las ips entregadas en cada subred de forma personalizada. En caso de asignar un valor específico en esta sección, los valores default-lease-time y max-lease-time establecidos en los parámetros generales no tendrán validez y serán estos los que tendrán prioridad en dicha subred.

Con esto ya tendríamos las nociones generales de cómo crear un DHCP, pero existen algunas opciones muy interesantes que pueden resultar útiles en muchos casos; especialmente dos de ellas: Los fixed-address y los spoofs mediante MAC.

El concepto de fixed-address es muy sencillo. Simplemente se trata de asignar una ip específica a un equipo en concreto; para ello se usa la MAC (Dirección física) de la tarjeta de red del equipo cliente en cuestión y así uno se asegura de que dicho equipo siempre tendrá esa ip. Sería algo parecido que asignarle a dicho equipo una ip estática, con la diferencia de que éste depende del servidor DHCP para obtener la ip. Un pequeño ejemplo de una ip fija o fixed-address sería el siguiente:


El concepto de spoofs de MAC se basa en la distribución de una serie de rangos de ips por grupos de dispositivos. Dichos grupos se distinguen entre sí gracias a las MAC. Eso es debido a que aunque todas las MAC son únicas, siguen un patrón o estándar y concretamente los 3 primeros campos de la MAC (véase que todas las MAC se componen de 6 campos) hacen referencia al fabricante del dispositvo. Con lo que se pueden diseñar spoofs dependiendo del fabricante del dispositivo con el fin de realizar diferentes repartos. Para crear un grupo de dispositivos habría que crear una clase tal que así:

 
Con dicho clase creada, simplemente habría que asociarla con un rango de ips en concreto mediante un concepto llamado pool, obteniendo así la distinción de rangos deseada. Este sería el fichero de configuración final siguiendo todo lo citado anteriormente:

  1. default-lease-time 600;
  2. max-lease-time 7200;
  3. authoritative;
  4. host test{
  5.   hardware ethernet 08:00:27:03:de:fe;
  6.   fixed-address 192.168.1.100;
  7. }
  8. class "grupo" {
  9.   match if substring (hardware, 1, 8) = 08:00:27:;
  10. }
  11. subnet 192.168.1.0 netmask 255.255.255.0 {
  12.   range 192.168.1.2 192.168.1.99;
  13.   option domain-name-servers 8.8.8.8;
  14.   option routers 192.168.1.1;
  15.   default-lease-time infinite;
  16.   max-lease-time infinite;
  17. pool {
  18.         range 192.168.1.101 192.168.1.200;
  19.         allow members of "grupo";
  20. }
  21. }

Con esto ya tendríamos las nociones para crear nuestro propio servidor DHCP.

Espero que os sea útil.

Saludos cordiales.