Información blog

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

sábado, 30 de enero de 2016

Preload: Qué es y para qué sirve

En esta ocasión quiero hablaros de uno de los recursos más útiles y usados en el mundo de Linux para mejorar el rendimiento del sistema operativo en general, esta utilidad requiere que pase algo de tiempo para que nosotros notemos alguna diferencia; se trata de la utilidad preload, un paquete de software que monitoriza nuestro sistema y determina qué aplicaciones son las que más usamos, haciendo que éstas se pre-carguen en la memoria RAM para poder usarlas con mayor rapidez. Obviamente el determinar qué es lo más usado requiere que la aplicación lleve instalada un tiempo, con lo que hasta pasados unos días no notaremos ninguna diferencia en el equipo. Esta aplicación es especialmente útil en entornos de escritorio, si bien puede ser perfectamente usada en servidores.

velocimetro

Esta aplicación es un demonio, es decir una aplicación que corre en segundo plano, así que una vez instalada no tendremos que preocuparnos por ella a menos que queramos aplicarle alguna configuración personalizada. Dicho así todo suena fantástico, si bien la preload no está instalado en el sistema... Afortunadamente, la gran mayoría de los repositorios actuales lo incluyen por defecto, así que únicamente tendremos que hacer la instalación desde éstos para tenerlo disponible, lo cual es tan sencillo como escribir en la terminal:

En Debian
apt-get install preload
En Red Hat
yum install preload

En un principio así tendríamos el demonio instalado y operativo, consiguiendo que las aplicaciones más usadas estén pre-cargadas en la RAM. ¿Qué logramos con esto? Qué cuando arranquemos el ordenador, ya tengamos algunos bytes de la memoria RAM cargados en la caché con la información necesaria para cargar dicha aplicación, reduciendo los tiempos de carga en hasta un 50%, pues no tiene que realizar operación alguna para cargar dichos recursos; dicho ahorro en esas tareas conlleva en un gran ahorro de tiempo, cosa especialmente notoria con ciertas aplicaciones "pesadas" tales como libreoffice, que cargan prácticamente al instante gracias a preload. Obviamente existen más aplicaciones en las que se notaría la diferencia; he aquí una pequeña gráfica con algunas comparaciones de antes y después de algunos programas:


Si bien la configuración por defecto de este software es lo suficientemente efectiva como para servirnos en la gran mayoría de los casos, a veces necesitamos un funcionamiento más personalizado; ya sea por que queremos excluir ciertas parte del sistema de dicha monitorización o por que queremos que preload use un máximo de memoria RAM menor al determinado (esto se realiza para evitar que preload use demasiada RAM ). Para personalizar el comportamiento de este demonio, tendremos que recurrir al fichero de configuración /etc/preload.conf.

Este fichero tiene múltiples parámetros configurables que pueden ayudarnos a monitorizar el sistema a nuestro gusto o a ocultar ciertos elementos de dicho "ojo". Los parámetros más importantes serían:

  • cycle: Probablemente el parámetro más importante de todos, especifica cada cuantos segundos hace una revisión del sistema. Pasados esos segundos analiza las aplicaciones que están en marcha y evalua si la información cargada en la caché es la adecuada; tras dicho análisis también evalúa qué información es conveniente tener precargada en la caché. El valor por defecto es 20 (el valor establecido estaría en segundos) y los propios desarrolladores advierten que no es recomendable poner un valor demasiado bajo, ya que estaríamos forzando al sistema a hacer revisiones constantes cada muy poco tiempo y podría sobrecargar el sistema operativo con tantos "ciclos" tan seguidos. Una pequeña curiosidad de este parámetro es que siempre tiene que tener asignado un número par.
  • minsize: Este valor es muy importante también, pues establece el tamaño MÍNIMO que debe de tener un proceso en ejecución. A cuanto más pequeño sea el valor, mayor será el número de procesos que monitorizará (ya que el requisito para que el proceso sea monitorizado será mucho más laxo). El parámetro está establecido en bytes y por defecto tiene un valor de 2000000.
  • autosave: Este parámetro es el encargado de guardar el estado de preload (por si este fuese detenido por cualquier motivo). Al igual que cycle, es recomendable no poner un valor excesivamente bajo, ya que estaríamos haciendo trabajar al equipo con demasiada intensidad. El valor por defecto es de 3600 segundos; es decir de una hora.
  • memtotal,memfree y memcached: Aunque son tres parámetros distintos, su correlación hace que sea más útil explicarlos en conjunto que por separado. La combinación de estos tres valores tienen como objetivo evitar que el equipo consuma demasiada ram; es decir evitar que cachee demasiada memoria y deje el equipo sin memoria para hacer el resto de tareas. Los valores usados son desde -100 a 100 y los valores usados por defecto son: -10, 50 y 0 respectivamente. Esto puede sonarnos raro pero significaría lo siguiente: Usa como máximo el 50% de la memoria ram libre menos un 10% de la memoria total (de ahí el -10) más un 0% de la memoria caché en uso. Estos valores por defecto son de por sí lo suficientemente eficientes para evitar que nos quedemos sin memoria, aunque siempre se puede querer ajustar un poco más.
  • mapprefix: Los directorios especificados en este parámetro serán excluidos de la monitorización de preload, cosa útil cuando queremos que el contenido de la carpeta en cuestión no se pre-cargue en la memoria RAM. En caso de querer especificar más de un directorio, habría que separarlos mediante el caracter ;.
  • exeprefix: Cumple la misma función que mapprefix, con la diferencia de que en este caso se especificarían binarios y no directorios.

Como podéis ver el archivo de configuración es relativamente sencillo de entender y aunque como bien he dicho no es necesario realizar configuración alguna en este para poder disfrutar de esta magnifica utilidad, siempre viene bien conocer lo que la utilidad nos ofrece con el fin de poder personalizarla a nuestro gusto en el futuro.  

Espero que os haya resultado útil.

Saludos.

miércoles, 27 de enero de 2016

Lost+found; qué es y qué hacer con él

Aunque los sistemas basados en Linux son muy robutos y estables, como todo son susceptibles de tener problemas cuando hay apagones, cierres del sistema operativo forzosos etc; dejando bloques y/o archivos corruptos. Ya en su momento vimos qué hacer al respecto con fsck, pero a veces no basta con usar dicha herramienta y empezar a usar el PC con normalidad, sino que es necesario rebanarse un poco los sesos debido a que aún con dicha medida nada parece funcionar. Eso es debido a que algunos de los ficheros que han sido recuperados o arreglados han cambiado su ubicación; concretamente se ubican en un directorio muy particular que no existía hasta que se ejecutó el comando fsck. Se trata del directorio lost+found.

Lost+found

Este directorio, alojado en el directorio raíz (/), guarda todos y cada uno de los ficheros restaurados por la utilidad fsck, si bien lo restaurado sigue una nomenclatura diferente a la habitual... Esto se verá claramente tan pronto como hagamos un listado del contenido del directorio como a continuación.

  1. ls -la /lost+found/
  2. total 368
  3. drwxr-xr-x 3 root root   4096 ene 24 10:32 #103805
  4. drwxr-xr-x 3 root root   4096 ene 24 10:32 #105488
  5. drwxr-xr-x 3 root root   4096 ene 24 10:32 #125836
  6. -rw-r--r-- 2 root root   2473 ene 24 16:03 #127864
  7. -rw-r--r-- 2 root root  18505 ene 24 16:03 #127865
  8. -rw-r--r-- 2 root root  56140 ene 24 16:03 #127866
  9. -rw-r--r-- 2 root root  25978 ene 24 16:03 #127867
  10. -rw-r--r-- 2 root root  16247 ene 24 16:03 #127868
  11. -rw-r--r-- 2 root root 138001 ene 24 17:33 #127869
  12. -rw-r--r-- 2 root root  63623 ene 24 17:33 #127870
  13. -rw-r--r-- 2 root root  34032 ene 24 17:33 #127871
  14. -rw-r--r-- 2 root root   2536 ene 24 17:33 #127872

Si os fijais bien los ficheros mostrados en el listado están compuestos por una # seguido de una serie de números; esos números representan el número de inodo. Un inodo no es nada menos que una estructura de datos que contiene toda la información de un fichero o directorio: estructura, datos, permisos, fecha de creación, etc... Pero entre dichos datos NO se encuentra el nombre. Es por ello que cuando fsck recupera algo, no lo representa con el nombre, sino con el número de inodo, pues es lo que él usa para identificar al archivo. 

En caso de que lo recuperado se trate de un directorio, una de las ventajas que tiene es que si bien el nombre del directorio está representado con su número de inodo, el contenido de éste es mostrado con normalidad, lo cual supone una gran ventaja. En cambio para revisar un archivo no queda otro remedio que jugar con diferentes utilidades para ver qué es o cual es su contenido.  Para ello hay algunos comandos que en mi opinión pueden ser de ayuda. Estos comandos serían:

  • file: Probablemente el más útil de todos; muestra el tipo de fichero del archivo en el que se ha ejecutado el comando, lo que ayuda mucho a acotar nuestra búsqueda. Ejemplo:
file #103805
  • cat: Al conocer el tipo de fichero, si se trata de un documento o de un fichero de configuración, una de las mejores formas para consultar el contenido del fichero sin editarlo sería mediante cat. Ejemplo:
cat #103805
  • exiftool: Una de las mejores formas de conocer un fichero es analizandolo en profundidad ¡y qué mejor para ello que revisar sus metadatos! Exiftool es una herramienta que no está instalada por defecto en el sistema, pero que puede ser instalada mediante apt-get o yum sin problemas. Gracias a esta utilidad podremos revisar y manipular los metadatos a nuestro antojo. Ejemplo:
exiftool #103805

Conociendo exactamente qué es cada inodo, habría que copiar cada uno de éstos a su lugar correspondiente y renombrarlos con sus nombre originales para hacer que todo regrese a la normalidad. Es un proceso que puede resultar tedioso, pero que con las tres herramientas mencionadas puede ser algo más ameno, especialmente cuando podemos estar hablando de decenas o incluso centenares de inodos.

Espero que os haya resultado útil.

Saludos.

domingo, 24 de enero de 2016

Cómo crear un servidor de impresión con CUPS

Hola a todos; hoy quiero explicaros cómo crear un servidor en el que poder centralizar varias impresoras que funcionen por red. Este servidor estaría funcionando en Linux, pero a diferencia de lo que os suelo tener acostumbrados en este blog; en esta ocasión tendrá una muy pequeña parte dependiente de la línea de comandos, lo cual hace que este servicio sea muy fácil de usar; si bien esa facilidad de uso hace que tengamos que tomar ciertas medidas de seguridad con el fin de evitar que gente indeseada haga uso del servicio. La utilidad en cuestión que convertirá nuestro equipo en un servidor de impresión se denomina CUPS; Common Unix Printing System. Utilidad que si bien no está instalada por defecto en ningún sistema operativo, sí que está incluida en la mayoría de los repositorios, evitando que tengamos que acceder a URLs de terceros.

IMPRESORA


La instalación de CUPS es extremadamente sencilla; simplemente hay que instalarlos desde los repositorios mediante el comando:

En Debian:
apt-get install cups
En Red Hat:
yum install cups

Con el software instalado, todavía no estaríamos preparados para usar la herramienta, ya que por defecto tiene todos los accesos cerrados, con el fin de que nosotros preparemos una configuración (en caso de ser posible restrictiva) que permita a unos pocos administrar el servidor de impresión. Todo esto se especifica en un único fichero denominado cupsd.conf, alojado en la carpeta /etc/cups/. Este fichero almacena toda la configuración del servicio cups; incluyendo por supuesto la ip y puerto de escucha y los orígenes desde los cuales puede ser accedido servidor de impresión; parámetros que por defecto están diseñados para que no entre absolutamente nadie más allá del propio servidor. Un ejemplo de parte del contenido que nos encontraríamos sería el siguiente:

  1. Listen localhost:631
  2. Listen /var/run/cups/cups.sock
  3. <Location />
  4.   Order allow,deny
  5. </Location>
  6. <Location /admin>
  7.   Order allow,deny
  8. </Location>..
  9. <Location /admin/conf>
  10.   AuthType Default
  11.   Require user @SYSTEM
  12.   Order allow,deny
  13. </Location>

Aunque esto únicamente es parte de la configuración reúne en esencia todo aquello que nosotros deseamos editar para ser capaces de gestionar correctamente nuestro servidor. Si os fijáis bien en el contenido, veréis que únicamente "escucha" en localhost, pero no solo eso, sino que además nadie es capaz de gestionar la utilidad, pues aunque en cada sección aparece una línea llamada Order, no hay ninguna que especifique allow o deny alguno. Lo única conclusión que podemos sacar de esta configuración es que las configuraciones allow tendrán prioridad sobre las de deny, con lo que podemos poner una línea de deny all y luego otra de allow all, que la línea de allow tendría prioridad.

Teniendo esto claro, habría que saber con exactitud los siguientes datos:

  • En qué ip/puerto queremos que "escuche" el servidor.
  • Desde qué ip/ips queremos que puedan conectarse al servidor.
La ip de escucha vendría a ser la ip del equipo en el que hemos instalado el software, mientras que el puerto es recomendable mantener el establecido por defecto; es decir 631.

Los orígenes desde los que queremos acceder al sofware son un poco más complicados de especificar, pues cada red y rango de ips es un mundo, pero si estuviesemos en un entorno pequeño con un rango de ips desde 192.168.1.0 a 192.168.1.255, una configuración muy básica sería que únicamente los miembros de dicha red pudiesen acceder a dicho software. Recalco que eso sería una configuración muy básica y que este tema es recomendable mirarlo con lupa, y que a poder ser en vez de establecer un rango de ips, nos limitásemos a especificar una única ip, para que solamente un equipo que tengamos controlado sea capaz de acceder.

Siguiendo estas recomendaciones, el fichero de configuración podría quedar de una forma parecida a la siguiente:


  1. Listen localhost:631
  2. Listen 192.168.1.4:631
  3. Listen /var/run/cups/cups.sock
  4. <Location />
  5.   Order allow,deny
  6.   allow 192.168.1.0/255.255.255.0
  7. </Location>
  8. <Location /admin>
  9.   Order allow,deny
  10.   allow 192.168.1.0/255.255.255.0
  11. </Location>
  12. <Location /admin/conf>
  13.   AuthType Default
  14.   Require user @SYSTEM
  15.   Order allow,deny
  16.   allow 192.168.1.0/255.255.255.0
  17. </Location>

Tras realizar el cambio sería obligatorio reiniciar cups para aplicar los cambios; algo tan sencillo como escribir en la terminal:

/etc/init.d/cups restart

No contentos con esto, hay secciones en las que es necesario que un usuario se loguee pues son secciones delicadas relacionadas con configuraciones y/o administraciones. Lamentablemente por defecto ningún usuario puede acceder por defecto a las susodichas, pues para ello tienen que ser miembros del grupo lpadmin. Afortunadamente esto se puede solventar fácilmente haciendo que un usuario existente pertenezca también a dicho grupo (aparte de los que ya pertenecía antes). Esto se logra mediante el comando usermod; comando que tendrá la estructura

usermod -aG lpadmin usuario

Es decir que si deseasemos que el usuario ivan perteneciese al grupo lpadmin tendríamos que escribir:

usermod -aG lpadmin ivan

Si bien este proceso puede parecer un poco tedioso, esto tiene que hacerse una única vez, con lo que en el futuro no sería necesario repetir todo lo realizado hasta ahora. Para poder disfrutar de este servidor tendríamos que escribir la dirección ip del servidor junto con su puerto en el navegador; en este caso sería: 192.168.1.4:631

Gracias a la configuración realizada, podremos gestionar la herramienta sin impedimentos, con lo que pasaríamos a lo más importante: El hecho de añadir una impresora. Para ello habría que dirigirse a la sección Administración  y dentro de ésta habría que clickar el botón Añadir impresora.

Añadir_impresora

Una vez clickado el botón, debido a la delicada naturaleza de esta operación, pasareis a usar automáticamente el protocolo HTTPS, es decir HTTP con SSL; esto es debido a que se quiere dificultar evitar que puedan obtener información sobre dicha tarea mediante ataques de Man in The Middle. Aún así dicho cambio no debería suponeros molestia alguna, ya que ya está todo preparado para que no sea necesario siquiera crear los certificados SSL (son creados automáticamente durante la instalación). El cambio te redirigirá a la misma sección de antes en la que habría que clickar de nuevo el botón Añadir Impresora, momento en el cual nos preguntará por unas credenciales; dichas credenciales tendrían que ser las mismas que las del usuario al que hemos introducido en el grupo lpadmin; por ejemplo en mi caso tendría que poner las credenciales del usuario ivan.

login

Con las credenciales introducidas, pasaríamos a seleccionar la impresora que deseamos agregar. En caso de estar conectada por ethernet/WiFi o conectada físicamente, aparecerá automáticamente en la pantalla; en caso de estar conectadas en cambio por IPP, http o Samba, habría que mirar el manual de la impresora pues cada una tiene su firmware, sus opciones, etc... En este caso en concreto la impresora que voy a añadir está por WiFi con lo que es detectada automáticamente sin problema alguno, con lo que simplemente habría que seleccionarla y listo.



Con dicha selección sería necesario seleccionar el driver que el servidor usará para trabajar con dicha impresroa; no es lo mismo detectar la impresora que ser capaz de usarla a la perfección; aquí lo suyo suele ser buscar el más parecido a nuestro modelo; en caso de no encontrar compatibilidad alguna sería necesario buscar el PostScript PPD del fabricante de la impresora en cuestión; no es algo que suceda demasiado a menudo pero se puede dar el caso...

driver


Por último, con todo lo anterior establecido, habría que simplemente especificar el nombre y la descripción que le daremos a la impresora que vamos a añadir. Este paso es el menos importante de todos pues simplemente se trata de poner un nombre y una descripción lo suficientemente informativa como para distinguir esa impresora en el futuro.

Nombre_impresora

Con la descripción puesta, tendríamos una impresora completamente operativa, con lo que ahora simplemente tendríamos que usarla. El uso de esta impresora se puede hacer tanto desde Windows como desde Linux; es decir que aquí no hay distinción alguna y no por pertenecer a un sistema operativo diferente a Linux nos quedaríamos acceso al servidor de impresión (con todo lo que ello ofrece). Por ejemplo, desde Windows podemos agregar una nueva impresora y seleccionar una impresora compartida... La ruta de cualquier impresora añadida en este servidor sería:

https://ip_servidor:puerto/printers/nombre_impresora

Un ejemplo de esta estructura aplicada a la agregación de una impresora desde Windows sería:


Ahora podríamos hacer uso de esta impresora sin problema alguno; obviamente se le puede sacar mucho más partido a CUPS del que le hemos dado ahora, pero estas serían las bases que uno tendría que seguir para poder disfrutar de las funcionalidades más básicas; a partir de aquí uno tendría que "jugar" y ver cómo poder adaptar esta utilidad a sus necesidades.

Espero que os haya resultado útil.

Saludos.

miércoles, 20 de enero de 2016

Cómo mantener nuestro equipo Linux en hora con NTP

Hoy en día nos hemos acostumbrado a que nuestros ordenadores y móviles cambien de hora automáticamente llegado el momento dado, sin tener que realizar ninguna acción por nuestra parte tal y cómo solemos hacer con nuestros relojes "habituales". Esto no siempre ha sido así, pero hoy en día gracias a que estamos constantemente conectados a la nube (aún cuando muchas veces no somos conscientes de ello) el equipo es capaz de adaptarse a los cambios automáticamente y evitar cualquier desfase horario, pues por defecto no se puede conseguir un reloj con una precisión perfecta, y con el tiempo la hora puede desfasarse unos segundos, minutos e incluso horas... Para lograr esta precisión horaria podemos recurrir al famoso protocolo NTP (Network Time Protocol). Este protocolo consiste en la manutención de la fecha y hora correcta del equipo, gracias a que estos datos son descargados desde una fuente de confianza que posee siempre la hora correcta; dicha fuente se denominaría servidor NTP.

NTP_PORTADA


Para aprovechar esta utilidad en sistemas basados en Linux, sería necesario contar con el paquete NTP instalado, el cual viene instalado por defecto en caso de estar trabajando con entornos de escritorio. De todas formas, siempre es recomendable cerciorarse de que efectivamente el paquete está instalado mediante el uso de apt-get o yum; por ejemplo en Debian sería:

apt-get install ntp

Con el servicio ntp instalado, aún cuando éste ya posee algunas configuraciones por defecto para apuntar a un servidor NTP; este es muy genérico y no se ajusta del todo a nuestras necesidades. Veamos el fichero de configuración perteneciente a esta utilidad... Dicho fichero se denomina ntp.conf, alojado en el directorio /etc. Aunque el fichero en cuestión tiene bastantes líneas existen 4 que nos llaman especialmente la atención, pues son las que determinan la fuente desde la que se obtiene la hora. En este caso las líneas apuntarían a un servidor NTP de Debian.

  1. server 0.debian.pool.ntp.org iburst
  2. server 1.debian.pool.ntp.org iburst
  3. server 2.debian.pool.ntp.org iburst
  4. server 3.debian.pool.ntp.org iburst

Estos servidores tienen la estructura:

server ${número_prioridad}.${url} iburst

Obviamente estas URL deben de ser obtenidas de alguna parte... En algunos casos en concreto se puede especificar la ip de un servidor en vez de un URL, pues puede que haya algún servidor NTP en la red, si bien esto únicamente se puede ver en redes corporativas, o en redes relativamente grandes, con lo que lo más común es que la fuente desde la que obtengamos la hora sea una fuente externa... De las fuentes externas disponibles, las más populares y las consideradas cómo las fuentes "estándar" dentro de este ámbito, se pueden encontrar en la página web: http://www.pool.ntp.org/. Esta página destaca por ofrecer una amplia variedad de servidores distribuidos por zonas y por ofrecer la posibilidad de añadir nuestros servidores cómo servidores NTP de alguna zona en concreto... Además una de las cosas que, personalmente, más me atraen es la posibilidad de apuntar a un servidor NTP de la zona que más nos convenga; es decir que si por ejemplo el equipo se encontrase físicamente en España, podemos apuntar a servidores NTP de dicha zona, obteniendo una fecha y una hora mucho más precisa que si apuntásemos a un servidor NTP genérico. Por ejemplo para apuntar a los servidores NTP de España habría que eliminar las cuatro líneas anteriormente citadas y añadir:

  1. server 0.es.pool.ntp.org
  2. server 3.europe.pool.ntp.org
  3. server 2.europe.pool.ntp.org

Con tan sólo reiniciar el servicio NTP mediante el comando service NTP restart, ya estaríamos apuntando a las nuevas fuentes. Además, para que el reloj de la BIOS también tenga la misma hora que la asignada mediante estos nuevos servidores y evitar cualquier tipo de desfase, escribiremos la hora del sistema dentro del reloj de la BIOS... Esto es tan sencillo como escribir el comando:

hwclock -w

Gracias a estos pequeños pasos obtendríamos un equipo con una gran precisión horaria, tal y como la tenemos en muchos dispositivos en la actualidad, evitando cualquier tipo de intervención manual por nuestra parte en el futuro.

Espero que os haya resultado útil.

Saludos.

viernes, 15 de enero de 2016

main, contrib y non-free en Debian

Hoy quiero explicaros el significado de ciertos conceptos usados en los repositorios Debian y derivados; conceptos que aunque son bien conocidos por muchos, no lo son tanto para otros, y en mi opinión son muy importantes conocer. Se tratan de los conceptos main, contrib y non-free usados en los repositorios de estos sistemas. 

Debian_logo

Estos tres términos se encuentran presentes a la hora de especificar los repositorios que deseamos usar, pues son fundamentales para determinar el tipo de paquetes al que se quiere acceder. Para conocer los repositorios que estamos usando actualmente tendríamos que dirigirnos al fichero /etc/apt/source.list; dicho fichero tendría el listado de fuentes a las que acceder para descargar paquetes y actualizaciones además de los los conceptos que acabo de mencionar. Para tener más claro esto os dejo los repositorios que yo uso en mi caso para Debian 8:

  1. deb http://ftp.es.debian.org/debian/ jessie main non-free
  2. deb-src http://ftp.es.debian.org/debian/ jessie main  non-free
  3. deb http://security.debian.org/ jessie/updates main non-free
  4. deb-src http://security.debian.org/ jessie/updates main non-free
  5. # jessie-updates, previously known as 'volatile'
  6. deb http://ftp.es.debian.org/debian/ jessie-updates main non-free
  7. deb-src http://ftp.es.debian.org/debian/ jessie-updates main non-free

Como podéis ver todos los repositorios tienen una composición parecida; eso es debido a que cada línea tiene la misma estructura, la cual constan en:

Tipo de archivo URL_Repositorio Nombre_Distribución Componentes

Si "desgranásemos" la primera línea por ejemplo, esta quedaría así:

Es la parte de los componentes la que más nos interesa en este momento, pues es la que determina qué tipo de paquete descargarse. Existen exactamente tres componentes, los cuales pueden ser llamados individualmente o todos juntos, dependiendo de nuestras necesidades. Por ejemplo, en los repositorios aquí mostrados solamente se han especificado dos componentes, pero perfectamente podrían haberse puesto todos. Estos tres componentes serían:

  • Main: El componente principal y más usado de todos; incluye a todos los paquetes que son considerados como parte de Debian; es decir que son los paquetes más controlados y seguros que uno se puede descargar para sus sistema operativo. Es muy raro no usar este componente.
  • Contrib: Contiene paquetes complementarios de Debian que se obtienen de fuentes que no pertenecen a Debian; es decir que contiene paquetes complementarios del "exterior.
  • Non-free: Contiene paquetes considerados como "No libres" por Debian.
Como veis, las diferencias entre cada componente son bastante significativas; en caso de seguir la filosofía de libertad ofrecida por el software libre, nunca habría que usar el componente non-free; mientras que si se es muy paranoico y únicamente se confía en los paquetes ofrecidos por Debian, siempre usaríamos únicamente el componente main. En caso de no tener reparos con el sofware descargado, siempre podemos escoger los tres componentes para así poder tener acceso total al amplio catalogo de paquetes disponibles.

Espero que os haya resultado útil.

Saludos.

miércoles, 13 de enero de 2016

TCP Wrappers, la alternativa a iptables

Cada día la gente es más consciente de la necesidad de un sistema seguro, preocupándose más y más de las medidas de seguridad que tienen que tomar... La necesidad más básica de todas es sin duda el uso de un cortafuegos; todo equipo o servidor requiere de un cortafuegos, y más de una vez se ha mencionado en este blog el uso del cortafuegos iptables; un cortafuegos muy útil y completo, cuya única "pega" es su elevada curva de aprendizaje. Es por eso que, si no queremos recurrir a herramientas de terceros, como fail2ban, podemos recurrir a una herramienta parecida a iptables que está instalada por defecto en el sistema denominada TCP Wrappers.

Una de las principales ventajas de TCP Wrappers es que los cambios realizados en éste son realizados permanentemente, mientras que en iptables es necesario almacenar las reglas en un script y de ahí hacer que éste se ejecute en cada arranque; es decir que por defecto los cambios de TCP Wrappers son persistentes, cosa que en iptables no.

TCP_WRAPPERS

La configuración de TCP Wrappers se divide en dos ficheros; uno que establece los HOSTS o fuentes desde las que aceptará las conexiones y otro que establecería los HOSTS a los que negaría la conexión.  Dichos ficheros se llaman hosts.allow y hosts.deny. Ambos ficheros están vacíos pero tienen varias líneas de ejemplo que nos pueden servir como guías para añadir nuestras reglas.

El primero de estos ficheros, y el más importante de los dos es hosts.allow; en caso de estar correctamente configurado es posible omitir el uso de hosts.deny ya que se pueden poner para ÚNICAMENTE se admitan ciertos hosts o para que se excluyan ciertos orígenes. También es importante saber que un host que tenga el acceso permitido en hosts.allow, tendrá acceso aunque se le haya especificado lo contrario en hosts.deny, pues allow tiene prioridad sobre deny.

Aunque cada uno de los ficheros tienen un propósito distinto, con conocer la estructura general a aplicar en cualquiera de éstos bastaría, pues ambos se rigen por las mismas reglas y sintaxis. Toda regla que se aplique en estos ficheros tiene la siguiente estructura:

<servicio/servicios> : cliente/clientes :[opciones]

Cada parte tiene el siguiente significado:

  • Servicios: La primera opción de todas está basada en el servicio o servicios que deseamos controlar. Para referirnos a éste tendremos que llamarlo por su nombre de proceso (por ejemplo sshd o atftpd), con lo que es muy importante tener claros dichos nombres. 
  • Cliente: Aquí lo único que habría que especificar sería la fuente que queremos tener controlada en esta regla. Para hacer referencia a dicha fuente se puede poner una ip en concreto, un rango de ips o un nombre de dominio. Para hacer referencia a un rango de ips podemos hacerlo de dos formas; la primera y la más simple sería dejando un espacio vacío, es decir que si por ejemplo quisiésemos controlar las ips desde 192.168.1.0 a 192.168.1.255, podríamos simplemente decir en la regla que queremos controlar dicho rango así: 192.168.1., pero si quisiésemos ser más precisos, podemos especificar el rango de ip completo junto a la mascara de la siguiente forma: 192.168.1.0/255.255.255.0
  • Opciones: Una acción ocpional o una serie de acciones opcionales; dichas acciones son comandos de shell que pueden permitir o prohibir el acceso o incluso alterar el comportamiento de la conexión.

Para hacer nuestra vida más fácil, podemos recurrir a una serie de nombres, reverenciados también como comodines, que agrupan algunos conceptos; nombres que pueden envolver los servicios, los clientes o ambos. Estos comodines no son nada menos que 5:


  • ALL: Hace referencia a "todo" y puede ser usado tanto para hacer referencia a los servicios como a los clientes. Si se usase ALL con los servicios, se mencionarían a TODOS los servicios, mientras que con los clientes haríamos referencia a todos ellos.
  • LOCAL: Este comodín únicamente puede ser usado con los clientes; comodín que hace referencia a localhost.
  • KNOWN: También puede ser usado únicamente con los clientes y hace referencia a todos los hosts conocidos por el sistema operativo; hosts que serían conocidos porque han sido especificados en el apartado /etc/hosts o porque están presentes en la tabla ARP.
  • UNKNOWN: Es usado en el apartado de clientes y hace exactamente lo contrario que KNOWN, es decir hacer referencia a los hosts desconocidos.
  • PARANOID: Hace referencia a los hosts cuyo "hostname" o nombre no corresponden con su dirección ip; esto viene bien para evitar accesos desde orígenes suplantados.

Con lo visto hasta ahora ya seríamos capaces de crear reglas tanto en el fichero hosts.allow, como en el hosts.deny; por ejemplo podríamos añadir estas reglas en el fichero allow:

Esta regla permitiría el acceso a cualquiera 
ALL: ALL
Si deseásemos permitir que la ip 192.168.1.5 pudiese acceder al servicio sshd; habría que añadir la regla:
sshd: 192.168.1.5
Podemos ser un poco más laxos y decir que en vez de limitarse con la 192.168.1.5; se incluyan a todas las ips dentro del rango 192.168.1.0/255.255.255.0:
sshd: 192.168.1.0/255.255.255.0
Imaginemos que queremos añadir unas acciones extra al comando anterior; acciones que en este caso serían que mostrase un mensaje en pantalla y que además, en vez de permitir el acceso a dicho rango de ips lo denegase:
sshd: 192.168.1.0/255.255.255.0 :spawn /bin/echo "Prohibido el acceso" >/var/log/syslog :deny

Esto es perfectamente aplicable tanto en host.allow como en deny; con la salvedad de que el comportamiento por defecto de host.deny sería bloquear las conexiones que coincidiesen con las reglas añadidas en el fichero en cuestión. 

Además de lo comentado anteriormente, existe un operador especial llamado EXCEPT, que permite crear excepciones específicas para las reglas añadidas. La mejor forma de entender esto sería viendolo aplicado a una regla. Imaginemos que tenemos esta regla añadida al host.allow:

ALL: 192.168.1.0/255.255.255.0 EXCEPT 192.168.1.1

En esta regla diríamos que todas las ips del rango 192.168.1.0-255 serían contempladas por ésta, a excepción de la ip 192.168.1.1; dicha ip estaría excluida de dicho rango. 

También podemos usar el operador EXCEPT para los servicios, tal y como podemos ver a continuación:

ALL EXCEPT atftpd: .testdomain.com

En este caso la regla relacionaría a los clientes provenientes de testdomain.com que se conectasen a a cualquier servicio a excepción de atftpd.

Como podéis ver, TCP Wrappers, si bien no abarca tantas cosas como iptables, puede ser un cortafuegos muy sólido y valioso que puede bloquear cualquier amenaza a la perfección; siempre y cuando se hayan creado las reglas adecuadas para ello.

Espero que os haya resultado útil

Saludos.