El otro día hablábamos sobre securizar un sistema Linux con iptables y en otro artículo encontrábamos un firewall basado en FreeBSD llamado pfSense. Hoy vamos a ver cómo securizar un sistema Unix (Linux, BSD…) a través de TCP Wrappers,  un buen complemento de iptables. La wikipedia lo define como:

TCP Wrapper (“Envoltorio de TCP”) es un sistema de red ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

Bien, partimos de la base de que tenemos dos ficheros configurables, /etc/hosts.deny y /etc/hosts.allow. En ellos podemos especificar que IPs, hostnames o redes pueden acceder a determinados servicios del sistema. TCP Wrappers suele venir instalado por defecto en la mayoría de sistemas operativos Unix.

La sintaxis básica de estos ficheros es la siguiente:

daemon : dirección : acción
ó
daemon : dirección

Daemon es el demonio/servicio a filtrar, dirección es la dirección, host o subred y acción si denegamos o aceptamos el acceso. Para saber si un servicio puede ser configurado para filtrado vía TCP Wrappers hay que saber si su binario está enlazado con la biblioteca libwrap.a. Para ello:

# ldd /usr/sbin/sshd | grep libwrap.so
	libwrap.so.0 => /lib/libwrap.so.0 (0x001ce000)

Si la salida es NULL el demonio no está compilado con TCP Wrappers y no funcionará. Si devuelve algo como lo anterior sí que lo está. Vamos a ver entonces unos cuantos ejemplos:

Permitir acceso ssh únicamente a unas IPs

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos al resto.

sshd: ALL

Bloquear todo excepto lo declarado en /etc/hosts.allow

/etc/hosts.allow

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos acceso al resto de servicios excepto SSH a las Ips indicadas. La máquina quedará blindada excepto el acceso SSH a las Ips permitidas:

ALL: ALL

Permitir también el uso de sendmail a una subred y unos hosts concretos

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113
sendmail: 10.0.0.0/24 test.com prueba.com

/etc/hosts.deny

ALL: ALL

Permitir todo y bloquear el acceso total a una única IP

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192.168.0.115

Filtrar y ejecutar un comando tras un intento de acceso

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192,168.0.115 \
   : spawn (/bin/echo %a desde %h intento acceder a %d >> \
    /var/log/connections.log) \
   : deny

Aquí ya depende todo si queremos aplicar una política restrictiva desde el principio, bloquear todo y a partir de ahí comenzar a abrir servicios a determinadas Ips, rangos o hosts o si por el contrario queremos dejar todo abierto y cerrar servicios a determinadas Ips,etc.

Si os resulta interesante, disponéis de más información en el handbook de freebsd o en Linux about.com. Esta ha sido una mera introducción a TCP Wrappers

Siguiendo con el tema tratado en el anterior post sobre como encontrar fallos e inconsistencias en los ficheros passwd y shadow vamos a ver como a la hora de editar ciertos ficheros críticos del sistema debemos asegurarnos de hacerlo de forma correcta. Ficheros como /etc/passwd, /etc/group, /etc/shadow o /etc/sudoers pueden editarse ‘al vuelo’ con un editor normal (gedit, vi, vim, nano…) pero corremos el peligro de que mientras lo estamos editando sus datos se hayan actualizado y se pierdan los cambios.

visudo

El comando visudo permite modificar en modo seguro el fichero /etc/sudoers. La diferencia de editarlo con visudo a hacerlo con cualquier otro editor es que visudo bloquea el fichero para evitar ediciones sumultaneas. Otro punto a favor de editar sudoers de esta forma es que en el momento de guardar los cambios realiza un chequeo del fichero en busca de fallos de sintaxis y todo tipo de errores, y en caso de encontrarlos no nos permitirá guardar el fichero y nos indicará el número de línea donde se encuentra el error, permitiendonos editar el ficehro o salir sin guardar.

# visudo

vipw y vigr

Los comandos vipw y vigr permiten editar los ficheros /etc/passwd y /etc/group respectivamente de forma segura. Si quisieramos editar el fichero /etc/shadow y /etc/gshadow deberíamos utilizar el parámetro -s.

Cabe decir que es recomendable evitar la manipulación directa de estos ficheros y que es conveniente usar los comandos correspondientes para gestión de usuarios: crear, eliminar y modificar usuarios de sistema en Unix. Si fuera estrictamente necesario, la modificación de passwd y shadow sería del siguiente modo:

Primero editamos el fichero /etc/passwd:

# vipw
Ha modificado /etc/passwd.
Necesitará modificar /etc/shadow por consistencia.
Use la orden «vipw -s» para hacerlo.

Y posteriormente editamos el fichero shadow y gshadow:

# vipw -s
vipw: /etc/shadow no está cambiado

Si no quisieramos editar el fichero shadow a mano podemos decirle al sistema que lo actualice de forma automática con el comando pwconv:

# pwconv

Y lo mismo cuando editamos grupos con vigr, para evitar la modificación manual de gshadow podemos usar grpconv:

# grpconv

Al igual que con visudo, vigr y vipw bloquean los ficheros para evitar que puedan ser editados a la vez. Para evitar esto se crea un fichero temporal /etc/ptmp y se deshabilita la escritura del mismo.

Os recomiendo revisar las páginas man de los comandos para encontrar información más detallada sobre el funcionamiento y posibilidades de cada uno de ellos.

Me he encontrado con un problema ante el que el origen parecía un fallo en la variable $PATH que se define al hacer login con un usuario en el sistema. La situación era la siguiente: accedemos por ssh y seguidamente hacemos su para autenticarnos como root. El problema viene en que algunos comandos no se encuentran en el PATH por lo que recibimos errores como estos:

[alex@server  ~$] su
Contraseña:
[root@server alex#] echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/alex/bin

[root@server  ~#] tcpdump
bash: tcpdump: command not found
[root@server   ~#] sendmail
bash: sendmail: command not found

Como podéis ver en la secuencia de comandos, el resultado de la variable $PATH está incompleto, faltan /usr/sbin y /sbin. El correcto sería algo así:

[root@server alex#] echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

Probablemente algunos ya hayáis visto donde está el error, y otros no. El fallo es el paso de la autenticación a root, en lugar de su a secas hay que hacerlo con su -<:

$ su -

La aclaración de esto es que el comportamiento por defecto de su es mantener tanto el directorio home del usuario como sus variables de entorno en lugar de adquirir las del nuevo usuario, en este caso root. Así que si queremos adquirir todas las variables de entorno del usuario contra el que hacemos su deberemos especificar el usuario, o en caso de root el guión por lo menos:

$ su - usuario

En los sistemas Unix, cada una de las particiones/sistema de ficheros cuenta con un directorio llamado /lost+found en el cual se almacenan ficheros y directorios (o restos de ellos…) recuperados tras una revisión del sistema de ficheros  a través de la herramienta fsck, todo ello provocado habitualmente por cuelgues del sistema, apagados forzados del equipo, cortes de corriente, etc.

Todos aquellos ficheros y directorios recuperados tras un fsck se almacenan con la siguiente estructura en el directorio /lost+found, el nombre de cada fichero es el número de inodo:

# ls -l /lost+found/
total 1512
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #123805
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #125488
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #135836
-rw-r--r-- 2 root root   2473 2010-03-02 16:03 #137864
-rw-r--r-- 2 root root  18505 2010-03-02 16:03 #137865
-rw-r--r-- 2 root root  56140 2010-03-02 16:03 #137866
-rw-r--r-- 2 root root  25978 2010-03-02 16:03 #137867
-rw-r--r-- 2 root root  16247 2010-03-02 16:03 #137868
-rw-r--r-- 2 root root 138001 2010-03-02 16:03 #137869
-rw-r--r-- 2 root root  63623 2010-03-02 16:03 #137870
-rw-r--r-- 2 root root  34032 2010-03-02 16:03 #137871
-rw-r--r-- 2 root root   2536 2010-03-02 16:03 #137872

Estos ficheros pueden estar corruptos o incompletos, pero podemos tener suerte y encontrar aquello que creíamos perdido tras el fsck:

# cd \#125488/
#125488# ls
images  index.html

Tendremos que revisar uno a uno los ficheros y directorios debido a que el nombre del fichero se ha perdido, en este caso una imagen GIF:

# file \#89952
#89952: GIF image data, version 89a, 169 x 20

Como os podéis imaginar, puede ser una ardua tarea revisar todos los ficheros y directorios e intentar volverlos a poner en su sitio, lo más sensato es recuperar una copia de seguridad y trabajar con ella, reinstalar en caso de ser librerías, binarios… En caso de no disponer de un backup, con los comandos ‘file’ como hemos visto antes o ‘strings’, ‘more’, etc. podemos intentar recuperar algo de información de los ficheros pero puede llegar a ser prácticamente imposible en algunos casos. ¡Suerte!

La variable de entorno TMOUT nos permite definir el tiempo que queremos permitir a un usuario permanecer dentro de la shell o sesión SSH sin hacer nada (estado idle o inactivo). Por defecto no hay límite de tiempo por lo que un usuario podrá permanecer de forma indefinida conectado al sistema independientemente de que la sesión se esté utilizando o no.

Para configurar esta variable, simplemente la añadimos dentro de nuestro perfil de variables/configuraciones de bash ~/.bash_profile o ~/.bashrc. Conviene configurarla como read only para evitar que el propio usuario pueda modificarla:

# Establecemos en 2 minutos (120 segundos) el Timeout para la sesión bash/ssh
TMOUT=120
readonly TMOUT

Refrescamos la shell o entramos y salimos para que sea efectivo:

$ bash

También podemos establecerla a tiempo real mediante export:

$ export TMOUT=120

A partir de ahora, si dejamos la shell abierta durante 2 minutos sin realizar ninguna tarea automáticamente nos desconectará de la sesión:

$ timed out waiting for input: auto-logout

Si hay algo que cualquier administrador de sistemas tiene claro es que es imposible saberlo todo, lo que hay que saber es buscar. Los sistemas *nix cuentan con sistemas de ayuda integrados que nos explican al detalle las funcionalidades de los comandos y servicios, sus ficheros de configuración, directivas, el modo de usarlos, etc.

Páginas man

Las páginas man (manual) nos ofrecen toda esta información detallada, su modo de uso es el siguiente:

$ man COMANDO

Si por ejemplo quisieramos ver la ayuda del comando grep ejecutaríamos lo siguiente:

$ man grep

Una vez dentro, siempre tendremos unas secciones claramente diferenciadas como por ejemplo NAME, SYNOPSIS, DESCRIPTION, etc. Si tenéis conocimientos básicos de vim podréis navegar a través de ellas del mismo modo que en el editor. Para movernos usaremos las teclas de desplazamiento, para buscar ESC + / + cadena a buscar, tecla ‘n’ para movernos entre los resultados, etc.

A la hora de acceder a las páginas man tenemos la posibilidad de acceder directamente a la sección X, si quisieramos acceder a la sección 3 de la página man de grep:

$ man 3 grep

Las secciones para BSD, Unix y Linux son las siguientes:

1. Comandos disponibles
2. Llamadas Unix y C del sistema
3. Rutinas en C para programas en C
4. Nombres de fichero especiales
5. Formatos de fichero y convenciones para ficheros usados por Unix
6. Juegos y salvapantallas
7. Paquetes de procesamiento de palabras
8. Procedimientos y comandos para administradores de sistemas

También podemos buscar en las páginas man a través de palabras clave mediante el parámetro -k seguido de las palabras:

$ man -k regexp
regexp_table (5)     - format of Postfix regular expression tables

Y para ficheros de configuración el parámetro -f:

$ man -f resolv.conf

El comando apropos

Ya hablé hace tiempo de él, entrad aquí para más información: apropos: buscador de comandos en la shell

Comando seguido de –help ó -?

Si a cualquier comando le añadís el parámetro

ó -? recibiréis ayuda por pantalla sobre el mismo. Un ejemplo de la ayuda del comando ps:

$ ps --help
********* simple selection *********  ********* selection by list *********
-A all processes                      -C by command name
-N negate selection                   -G by real group ID (supports names)
-a all w/ tty except session leaders  -U by real user ID (supports names)
-d all except session leaders         -g by session OR by effective group name
-e all processes                      -p by process ID
T  all processes on this terminal     -s processes in the sessions given
a  all w/ tty, including other users  -t by tty
g  OBSOLETE -- DO NOT USE             -u by effective user ID (supports names)
r  only running processes             U  processes for specified users
x  processes w/o controlling ttys     t  by tty
*********** output format **********  *********** long options ***********
-o,o user-defined  -f full            --Group --User --pid --cols --ppid
-j,j job control   s  signal          --group --user --sid --rows --info
-O,O preloaded -o  v  virtual memory  --cumulative --format --deselect
-l,l long          u  user-oriented   --sort --tty --forest --version
-F   extra full    X  registers       --heading --no-heading --context
                    ********* misc options *********
-V,V  show version      L  list format codes  f  ASCII art forest
-m,m,-L,-T,H  threads   S  children in sum    -y change -l format
-M,Z  security data     c  true command name  -c scheduling class
-w,w  wide output       n  numeric WCHAN,UID  -H process hierarchy

El comando whatis

También hablé de él en su día, pinchad aquí: whatis: Descubre para qué sirve un comando

El comando whereis

Comando también tratado en el blog: Whereis, encuentra binarios, sources o páginas de ayuda en Linux / Unix

¡Y si esto no es suficiente para encontrar la información que necesitáis siempre podéis recurrir a Google!

Cuando el nombre de una partición o volúmen es demasiado largo, al mostrarla con el comando df se crea un salto de línea para mantener la estructura de las columnas y tabulaciones:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      447G  6.3G  417G   2% /
/dev/sdb1             996M   39M  906M   5% /tmp
/dev/sda1              99M   24M   70M  26% /boot

Esto puede ser un problema en algunas ocasiones en las que queramos recoger los datos de la salida del comando. Para evitarlo, únicamente tenemos que utilizar el parámetro

y se respetará el nombre y el resto de información en la misma línea:

# df -hP
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  447G  6.3G  417G   2% /
/dev/sdb1             996M   39M  906M   5% /tmp
/dev/sda1              99M   24M   70M  26% /boot

Un truco simple que puede parecer una tontería pero es muy útil en ciertas ocasiones.

Hoy vamos a tratar de comprender las diferencias que existen en Unix / Linux entre los enlaces simbólicos (soft o symbolic links) y los enlaces duros (hard links).

Enlaces simbólicos (soft / symbolic links)

La manera más sencilla de comprender que es un enlace simbólico en Linux es compararlo con el “enlace directo” o “shortcut” en Windows. El fichero o directorio se encuentra en un único punto del disco y los enlaces son un puntero contra él. Cada enlace simbólico tiene su propio número de inodo lo que permite hacer enlaces simbólicos entre distintos sistemas de ficheros.

Para crear enlaces (tanto simbólicos como duros) usamos el comando ln. En este caso vamos a crear un enlace simbólico (parámetro

) del fichero test:

$ ln -s test enlace-a-test

Si listamos ambos veremos que el enlace tiene el carácter

que lo identifica como enlace simbólico:

$ ls -l
lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
-rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Para confirmar que el enlace simbólico tiene un inodo distinto usamos el comando stat:

$ stat test
  File: «test»
  Size: 0         	Blocks: 0          IO Block: 4096   archivo regular vacío
Device: 804h/2052d	Inode: 73793       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:58:53.124142406 +0200
Modify: 2011-04-27 18:58:53.124142406 +0200
Change: 2011-04-27 18:58:53.124142406 +0200

$ stat enlace-a-test
  File: «enlace-a-test» -> «test»
  Size: 4         	Blocks: 0          IO Block: 4096   vínculo simbólico
Device: 804h/2052d	Inode: 77212       Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 18:59:07.812139890 +0200
Modify: 2011-04-27 18:59:06.460112888 +0200
Change: 2011-04-27 18:59:06.460112888 +0200

También lo podemos verificar sacando el inodo en el ls (

):

$ ls -li
77212 lrwxrwxrwx 1 alex alex 4 2011-04-27 18:59 enlace-a-test -> test
73793 -rw-r--r-- 1 alex alex 0 2011-04-27 18:58 test

Hay que tener en cuenta, que en Linux / Unix (al igual que con los accesos directos de Windows), si borramos el fichero o directorio origen, el enlace simbólico permanece pero los datos desaparecen para siempre.
 

Enlaces duros (hard links)

Los enlaces duros lo que hacen es asociar dos o más ficheros compartiendo el mismo inodo. Esto hace que cada enlace duro es una copia exacta del resto de ficheros asociados, tanto de datos como de permisos, propietario, etc. Esto implica también que cuando se realicen cambios en uno de los enlaces o en el fichero este también se realizará en el resto de enlaces.

Los enlaces duros no pueden hacerse contra directorios y tampoco fuera del propio sistema de ficheros.

Vamos a crear un hard link contra el fichero “test” de antes y veremos que efectivamente comparten inodo y que los datos se sincronizan entre ambos:

$ ln test enlace-duro-test
$ ls -li
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rw-r--r-- 2 alex alex 5 2011-04-27 19:09 test

En la primera columna verificamos que tienen el mismo número de inodo y en la tercera se especifica cuando enlaces duros tiene el fichero. Si hacéis cambios en uno de ellos veréis que también se hacen en el resto. Si por ejemplo cambiamos los permisos al fichero test:

$ chmod 0755 test
$ ls -li
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 enlace-duro-test
73793 -rwxr-xr-x 2 alex alex 5 2011-04-27 19:09 test

Y finalmente el stat de cada uno verifica todo lo que comentamos:

$ stat test
  File: «test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

$ stat enlace-duro-test
  File: «enlace-duro-test»
  Size: 5         	Blocks: 8          IO Block: 4096   archivo regular
Device: 804h/2052d	Inode: 73793       Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2011-04-27 19:09:51.528132995 +0200
Modify: 2011-04-27 19:09:53.640114896 +0200
Change: 2011-04-27 19:11:42.516138726 +0200

Diferencias entre soft y hard links

• Los enlaces simbólicos se pueden hacer con ficheros y directorios mientras que los duros solo entre ficheros.
• Los enlaces simbólicos se pueden hacer entre distintos sistemas de ficheros, los duros no.
• Los enlaces duros comparten el número de inodo, los simbólicos no.
• En los enlaces simbólicos si se borra el fichero o directorio original, la información se pierde, en los duros no.
• Los enlaces duros son copias exactas del fichero mientras que los simbólicos son meros punteros o “accesos directos”.

Si se os ocurre alguna diferencia o apunte más no dudéis en comentarlo.