Monthly Archives: February 2011

Preparando LPIC-1 110.3 Asegurando datos mediante cifrado

Aqui veremos lo mas importante de este topico.

1- Introduccion
2- Utilizando Secure Shell (SSH)
2-1 Comandos
2-2 Instalacion
2-3 Archivos de Configuracion
2-4 Primeras Conexiones
2-5 Teoria Llaves asimetricas
2-6 Creando Llaves asimetricas
2-7 Creando Tuneles
3-0 Teoria GPG
3-1 Uso GPG
3-2 Uso de GPG con Gmail

Introduccion

Vamos a ver un poco como funciona el servicio OpenSSh que viene de los desarroladores de OpenBSD.
Este servicio utiliza lo que se llama cifrado asimetrico (llave publica y privada) con diferentes algoritmos(RSA, DSA,etc) que van a realizar la encriptacion.[2]

Utilizando Secure Shell (SSH)

SSH, tambien conocido como Shell segura es un reemplazo de telnet y otros comandos (rsh,rlogin,rcp ).
Principalmente se usa ssh para poder establecer conexiones remotas encriptadas. Sin embargo se utiliza tambien para copiar archivos,
crear tuneles con diferentes procotolos y puertos.
SSH es un modelo cliente/servidor en donde el demonio sshd es el servidor y ssh y scp son los comandos clientes.
Los clientes se conectan al servidor (sshd) , se establece una sesion encriptada que para eso necesitamos una autentificacion entre ambas partes (intercambio de llaves) y luego nos da el prompt de login.

Comandos

El comando ssh puede ser usado para conectarme remotamente a otros equipos o para conectarme localmente a mi equipo.Podriamos decir que es un uso similar al de rlogin,rsh,telnet.
El comando scp nos va a servir para poder copiar archivos y directorios desde o hacia un servidor remoto, funcionando este como el rcp.
Tambien se puede hacer forwarding con ssh (autentificacion con X y forwarding). Tambien se puede arrancar una X cliente desde una maquina remota y el protocolo X Window System sera encriptado para que sus paquetes viajen por la red.[3]

Instalacion

Aca vamos a consultar si ya lo tenemos instalado.

root@debian:~# dpkg -l |grep -i openssh
ii  openssh-blacklist                  0.4.1                       list of default blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                     1:5.5p1-6                   secure shell (SSH) client, for secure access to remote machines
ii  openssh-server                     1:5.5p1-6                   secure shell (SSH) server, for secure access from remote machines
root@debian:~#

Como ven tenemos instalado todo ya, si lo quisieramos instalar basta con hacer aptitude install NombrePaquete.
No se olviden que para poder hacer que se conecten al equipo necesitan el openssh-server.
Luego de instalar el openssh-server les va a generar las claves.

Archivos de Configuracion

Vamos a ver donde se situan los archivos de configuracion del cliente y del servidor.

Aca tenemos el directorio en gral.
root@debian:~# ls -ld /etc/ssh/
drwxr-xr-x 2 root root 4096 Feb  8 23:59 /etc/ssh/
root@debian:~#

Aca tenemos todos los archivos que contiene:

root@debian:~# ls -l /etc/ssh/
total 152
-rw-r--r-- 1 root root 125749 Dec 26 13:12 moduli
-rw-r--r-- 1 root root   1669 Dec 26 13:12 ssh_config
-rw-r--r-- 1 root root   2453 Feb  8 23:59 sshd_config
-rw------- 1 root root    668 Feb  8 23:59 ssh_host_dsa_key
-rw-r--r-- 1 root root    601 Feb  8 23:59 ssh_host_dsa_key.pub
-rw------- 1 root root   1675 Feb  8 23:59 ssh_host_rsa_key
-rw-r--r-- 1 root root    393 Feb  8 23:59 ssh_host_rsa_key.pub
root@debian:~#

Como ven tienen las llaves que genero con el algoritmo dsa y rsa tanto publicas ocmo privadas.

root@debian:/etc/ssh# file ssh_host_rsa_key
ssh_host_rsa_key: PEM RSA private key
root@debian:/etc/ssh# file ssh_host_rsa_key.pub
ssh_host_rsa_key.pub: ASCII text, with very long lines
root@debian:/etc/ssh#

Luego el archivo de configuracion del cliente es el siguiente :

root@debian:/etc/ssh# ls -l ssh_config
-rw-r--r-- 1 root root 1669 Dec 26 13:12 ssh_config
root@debian:/etc/ssh#

Un archivo tipico ..

root@debian:~# cat /etc/ssh/ssh_config  |grep -v "#"

Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no
root@debian:~#

El archivo de configuracion del servidor es el siguiente:

root@debian:/etc/ssh# ls -l sshd_config
-rw-r--r-- 1 root root 2453 Feb  8 23:59 sshd_config
root@debian:/etc/ssh#

Un archivo tipico :

root@debian:~# cat /etc/ssh/sshd_config  |grep -v "#"

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes

KeyRegenerationInterval 3600
ServerKeyBits 768

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
root@debian:~#

Aca en este archivo vamos a mencionar alguna de las cosas mas importantes como por ejemplo.
Port para especificar el puerto
Protocol la version del ssh
PermitRootLogin para permitir que se loguen como root.
PubkeyAuthentication Permite autentificacion de llaves publicas.
# For this to work you will also need host keys in /etc/ssh_known_hosts
# (for protocol version 2)
HostbasedAuthentication para que los usuarios puedan utilizar las llaves guardas bien conocidas o no.
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication Creo que el comentario de arriba lo dice todo.
X11Forwarding Para poder realizar forwardeo de grafica.

Primeras Conexiones

Cuando nos conectemos por primera vez a un equipo remoto va a pasar lo siguiente.

Equipo Remoto : 192.168.100.136

[rino@oc7287280510 ~]$ uname -a
Linux oc7287280510.ibm.com 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[rino@oc7287280510 ~]$
[rino@oc7287280510 ~]$ ssh -l root 192.168.100.136
The authenticity of host '192.168.100.136 (192.168.100.136)' can't be established.
RSA key fingerprint is 7f:91:5b:59:fb:3e:2d:9a:74:5f:41:7d:4a:36:98:9b.
Are you sure you want to continue connecting (yes/no)? 

Como ven ahi se va a realizar el intercambio de llaves.. Ponemos yes.

Warning: Permanently added '192.168.100.136' (RSA) to the list of known hosts.
root@192.168.100.136's password:
Y como vemos ya tenemos para poner la password
Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 14 15:54:53 2011 from 192.168.100.1
root@debian:~#
root@debian:~# uname -a
Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux
root@debian:~#
Ahora como ven estamos logueado en el equipo remoto.

Ahora volvamos al equipo local.

[rino@oc7287280510 ~]$ pwd && ls -ld .ssh
/home/rino
drwx------. 2 rino rino 4096 Feb 14 18:51 .ssh
[rino@oc7287280510 ~]$

Como ven se creo un directorio que se llama .ssh en el home directory del usuario el cual contiene estos archivos.

[rino@oc7287280510 ~]$ pwd && ls -l .ssh
/home/rino
total 104
-rw-------. 1 rino rino  1002 Aug 25 21:58 authorized_keys
-rw-rw-r--. 1 rino rino    62 Jul 22  2010 config.ssh
-rw-------. 1 rino rino   672 May  2  2010 id_dsa
-rw-r--r--. 1 rino rino   607 May  2  2010 id_dsa.pub
-rw-r--r--  1 rino rino 77941 Feb 14 18:52 known_hosts
-rw-------. 1 rino rino  1743 Jul 22  2010 rino
-rw-r--r--. 1 rino rino   399 Jul 22  2010 rino.pub
[rino@oc7287280510 ~]$

El archivo que nos creo fue el known_hosts que es el que contiene todas las llaves publicas de los servidores remotos que me quiero conectar.
Los demas archivos que figuran son porque en mi caso tengo mis llaves (publicas y privadas) que genere yo para poder conectarme a los equipos remotos sin necesidad de poner ninguna clave.. Eso lo vamos a ver mas adelante.

Si se fijan pueden buscar en el archivo mencionado anteriormente si esta la llave.

[rino@oc7287280510 .ssh]$ cat known_hosts |grep -i "192.168.100.136"
192.168.100.136 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvwJeIutxTZiydnLX+mOGenaYj5g2AKTpztQGFV4pSZxJLe9G0gsnrqZb2Amfe7ibaKqRMCy8OAPJfXJGmOyRVOHvqHnxeDifdXI9u81+qkBQRmuqV+6niqx1BxjWov7LnsiVmEnQDj3rlVe8t3WW5tOujdBTster29ECH0XfaiJdbzEF4xq0wdm0CknGwGha5DkkdWmoXlQh4fXrxsjHyIYSe5MpsIiaFsxp29M7ecxIaGcXct6twS0rABBD/pKrvrg6GMx2CUHaJC3AuoHajlxo7PoaHCv/c1pWZMlKNP4uSon+RH7ficNZ1MXiHsudm6O5gOEZFtTTdLzytxcPj
[rino@oc7287280510 .ssh]$

Si la borran (eso de arriba es toda una linea) , la proxima vez que se conectan a ese equipo le va a pedir devuelta que confirmen el intercambio de llaves.
Para conectarnos a un servidor remoto la sintaxis basica es asi.

ssh -l usuario ip/fqdn
ssh usuario@fqdn
Ejemplo:
ssh -l pepe 192.168.1.1
ssh -l pepe@mipc.com

Teoria llaves asimetricas

Una breve introduccion:

Breve introducción a la criptografía
En general, se pueden utilizar dos métodos de cifrado: simétrica y asimétrica.
El cifrado Simétrico es más rápido pero menos seguro, y el cifrado asimétrico es más lento pero más seguro.
En un medio ambiente con clave simétrica, ambas partes utilizan la misma clave para cifrar y descifrar mensajes.
Con las claves asimétricas, una clave pública y una clave privada se utilizan, y esta es la técnica importante que es utilizada para SSH.
Si las claves asimétricas son utilizadas, cada usuario tiene su propia clave pública / clave privada, y cada equipo necesita un par de ellas. De estas claves, la clave privada debe ser protegida en todo momento: si la clave privada se ve comprometida, la identidad del propietario de la clave privada se pone en peligro.
En resumen, el robo de usuarios de la clave privada es como el robo de identidad de un usuarios. Por lo tanto, una clave privada se almacena normalmente en un lugar muy seguro donde nadie más que su propietario puede acceder a él, por regla general se graba ~./ssh. La clave pública, por el contrario, está disponible a todo el mundo.
La clave Pública / Privada se utiliza generalmente para tres propósitos: encriptación, autenticación y no rechazo.
Para enviar un mensaje cifrado, el remitente cifra el mensaje con la clave pública del receptor que puede descifrar con la clave privada correspondiente. Este escenario requiere que, antes de el envío de un mensaje cifrado, usted tenga la clave pública de la persona que desea enviar el mensaje.
Las otras opciones son para utilizar las claves públicas y privadas para la autenticación o para probar que un mensaje no ha cambiado desde su creación. Este método se conoce como el no repudio. En el ejemplo de la autenticación, la clave privada se utiliza para generar una señal de token codificada. Si este token se puede descifrar con la clave pública de la persona que quiere autentificarse, esto demuestra que realmente está tratando con la persona adecuada, y el acceso puede ser concedido.
Sin embargo, esta técnica requiere que la clave pública sea copiada al host antes de que la autentificacion ocurra.

Utilizando modelo llave Publica/Privada en un ambiente con SSH.

Cuando la autenticación basada en claves se utiliza SSH , debe asegurarse de que, para todos los usuarios que necesitan utilizar esta tecnología, la clave pública está disponible en los equipos que se quieran acceder . Al entrar, el usuario crea una solicitud de autenticación en donde se utiliza la firma de la clave privada del usuario . Esta solicitud de autenticación se corresponde con la clave pública del mismo usuario en el equipo en el que el usuario desea ser autenticado. Si coincide, el usuario tiene permiso de acceso; Si no es así, el acceso de usuario se le niega.
La clave Pública / privada de autenticación está habilitada por defecto en todas las principales distribuciones de Linux.
Los pasos siguientes proporcionan un resumen de lo que sucede cuando un usuario intenta establecer una sesión SSH con un host:

1. Si la autenticación de clave pública está habilitada (por defecto), SSH comprueba el directorio en el directorio home del usuario para comprobar si una clave privada está presente.
2. Si una clave privada se encuentra, SSH crea un paquete con algunos datos en ella (token), cifra el paquete con la clave privada, y lo envía al host. La clave pública se envía también con este paquete.
3. El anfitrión ahora comprueba si un archivo con el nombre authorized_key en el home directory del usuario. Si no es así, el usuario no puede ser autenticado con sus llaves.
Si el archivo no existe y la clave pública es una clave permitida (y también es idéntica a la clave que ha sido seleccionada en el host), el host utiliza esta clave para comprobar la firma.
4. Si la firma se verifica, el usuario tiene acceso. Si la firma no puede ser verificada, el anfitrión le pide al usuario una contraseña en su lugar.

Todo esto suena bastante complicado, pero no lo es realmente. Todo sucede de forma transparente, si ha sido correctamente configurado. Además, lesto representa apenas un retraso significativo al establecer una conexión. Normalmente se requieren no más de un segundo.

Creacion llaves asimetricas

Vamos a realizar los pasos para crear nuestro juego de llaves y lograr que no tengamos que poner ninguna clave al conectarnos en un equipo remoto.[6]

Tenemos nuestro equipo ServidorA que va a ser nuestro equipo de trabajo

[rino@servidorA .ssh]$ hostname
servidorA
[rino@servidorA .ssh]$

Tenemos nuestro equipo ServidorB que va a ser el equipo donde nos vamos a conectar remotamente.

root@servidorB:~# hostname
servidorB
root@servidorB:~#

Paso 1 –> Crear llave publica y privada usando el comando ssh-key-gen en el servidor local

[test@servidorA ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/test/.ssh/id_rsa):
Created directory '/home/test/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/test/.ssh/id_rsa.
Your public key has been saved in /home/test/.ssh/id_rsa.pub.
The key fingerprint is:
9d:45:29:e0:78:47:c3:85:0b:9e:ef:b2:59:26:aa:82 test@servidorA
The key's randomart image is:
+--[ RSA 2048]----+
|        .oooo.   |
|       o..+o.    |
|      ..oo.o.    |
|       .oo.o     |
|        S.o      |
|          .      |
| .      ..o      |
|E .    ..=.      |
|   .... oo       |
+-----------------+
[test@servidorA ~]$

Paso 2 –> Copiar la llave publica en el servidor remoto utilizando ssh-copy-id

[test@servidorA ~]$ ssh-copy-id -i .ssh/id_rsa.pub rino@192.168.100.136
The authenticity of host '192.168.100.136 (192.168.100.136)' can't be established.
RSA key fingerprint is 7f:91:5b:59:fb:3e:2d:9a:74:5f:41:7d:4a:36:98:9b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.136' (RSA) to the list of known hosts.
rino@192.168.100.136's password:
[test@servidorA ~]$

Acuerdense que tienen que tener un usuario en el equipo remoto.
Esto va hacer un append de nuestra llave publica en el archivo remoto .ssh/authorized_key del servidor destino.

Paso 3 —> Autentificarse en el equipo remoto sin poner ningun password.

[test@servidorA ~]$ ssh rino@192.168.100.136
Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 14 19:43:11 2011 from 192.168.100.1
rino@servidorB:~$

Como ven no utilizamos ninguna password.

Ahora vamos a ver como utilizar ssh-add y ssh-agent.
Estos comandos nos van a servir para poder administrar nuestras llaves que se cargan cuando se inicia nuestra sesion. Imaginense que alguien se adueña de nuestras llaves como no la protegimos con una clave cualquiera se puede pasar por nosotros es por eso que necesitamos configurarle una clave.

[test@servidorA ~]$ ssh-keygen -p -t rsa
Enter file in which the key is (/home/test/.ssh/id_rsa):
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
[test@servidorA ~]$

Ahora ya tenemos una clave para nuestras llaves.

[test@servidorA ~]$ ssh rino@192.168.100.136
Enter passphrase for key '/home/test/.ssh/id_rsa':
Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 14 19:57:21 2011 from 192.168.100.1
rino@servidorB:~$

Ahora como ven antes de hacer algo me pide que autentifique con la clave de las llaves.. Ya si alguien quiere usar mis llaves no puede..

La idea es que no tenga que poner siempre esa clave y eso lo vamos a lograr con ssh-add y ssh-agent.

[test@oc7287280510 ~]$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-JtWDS10101/agent.10101; export SSH_AUTH_SOCK;
SSH_AGENT_PID=10102; export SSH_AGENT_PID;
echo Agent pid 10102;
[test@oc7287280510 ~]$

*. Esos comandos que tiro por lineas lo tendriamos que copiar y pegar para que los ejecute la shell, pero seria muy engorroso asi que vamos a realizarlo de la siguiente manera.*
*. Tengan en cuenta que les va a pedir su passphrase.*

Entonces vamos a realizar otros pasos:

[test@oc7287280510 ~]$ eval `ssh-agent`
Agent pid 10194
[test@oc7287280510 ~]$

Aca entra en juego el ssh-ad para que agreguemos nuestra llave en memoria. Nos va a pedir nuestra clave de la llave.

[test@oc7287280510 ~]$ ssh-add
Enter passphrase for /home/test/.ssh/id_rsa:
Identity added: /home/test/.ssh/id_rsa (/home/test/.ssh/id_rsa)
[test@oc7287280510 ~]$

Ahora intentamos loguearnos al servidor remoto.

[test@oc7287280510 ~]$ ssh rino@192.168.100.136
Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 14 20:02:54 2011 from 192.168.100.1
rino@servidorB:~$

Como ven ya nos logueamos sin necesidad de poner ninguna clave. (ni la del usuario ni la de nuestra llave).
Lo unico malo de esto es que no es una buena idea ponerlo en .bashrc o .bash_profile , menos en /etc/profile.. Lo ideal seria en alguno de los scripts de inicio de nuestra sesion grafica para que cuando iniciemos la grafica nos pida que pongamos la password y ya queda nuestra llave cargada [7][8][9] porque sino solo quedaria la llave con la clave cargada unicamente en la shell donde lo ejecutamos en cambio si lo hacemos no bien entramos en nuestra sesion grafica ya queda definida de forma global.

Creando Tuneles

Sintaxis

ssh -R|L port:host:host_port [user@]hostname [command]

Cuando la opción principal es-L, ssh redirige el tráfico desde el puerto local (port) al puerto de la máquina remota(host:host_port)
Cuando un programa se conecta al puerto host local, la conexión se transmite al lado remoto.
Una aplicación muy útil para esto es que transmita los puertos locales al servidor de correo de su empresa para que pueda enviar correo electrónico como si estuviera en la oficina. Todo lo que tienes que hacer es configurar el cliente de correo electrónico para conectar con el puerto correcto en el servidor local. Mas adelante veremos un ejemplo.
Cuando se utiliza-R, ocurre lo contrario. El puerto (port) de la interfaz de host local de la máquina remota se une al equipo local, y las conexiones que le serán enviadas a la máquina local dada por el host: host_port.

Ejemplo
Acceda a login.example.com. Entonces, redireccione las conexiones hacia localhost puerto 2525 al puerto 25 en mail.example.com, que seguramente va a rechazar la retransmisión para usted. La razón es porque la unión con el puerto 2525 tiene que ser creada por root en el puerto 25:
$ ssh-L 2525: mail.example.com: 25 login.example.com
En el sentido de que podemos forwardear estos puertos y otros para crear un tunel cifrado de datos en ambas partes.
Otros ejemplos y teoria [14][15]
La idea es que generemos un tunel (comunicacion) entre dos puntos ya sea de un lado o del otro para poder tener nuestros datos cifrados.
Igualmente recomiendo ver las paginas mencionadas para estar mas a fin con el concepto aca solamente se meniciona la sintaxis.

Veamos un ejemplo mas.

Supongamos que querramos enviar un mail con telnet utilizando un servidor de correo externo en este caso mail.restauradordeleyes.com.ar

[rino@oc7287280510 ~]$ telnet mail.restauradordeleyes.com.ar 25
Trying 38.108.125.71...
Connected to mail.restauradordeleyes.com.ar.
Escape character is '^]'.
220 wiki.itrestauracion.com.ar ESMTP Sendmail 8.13.8/8.13.8; Tue, 15 Feb 2011 21:37:57 +0300
helo mail.restauradordeleyes.com.ar
250 wiki.itrestauracion.com.ar Hello cpe-200-115-224-64.telecentro-reversos.com.ar [200.115.224.64] (may be forged), pleased to meet you
mail from: rino@restauradordeleyes.com.ar
250 2.1.0 rino@restauradordeleyes.com.ar... Sender ok
rcpt to: villadalmine@gmail.com
550 5.7.1 villadalmine@gmail.com... Relaying denied. IP name possibly forged [200.115.224.64]

Como ven nos rechaza porque esta bien configurado no nos permite hacer relay por lo cual necesitamos si o si crear un tunel hacia el mail server.

Entonces antes que nada creamos el tunel.

[rino@oc7287280510 ~]$ ssh -L 2525:localhost:25 root@mail.restauradordeleyes.com.ar
bienvenido a mi sistema %a. Tu IP esta siendo guardada para mayor seguridad
root@mail.restauradordeleyes.com.ar's password:
Last login: Tue Feb 15 21:33:40 2011 from 200.115.224.64
[root@villadalmine ~]#

Como ven lo redireccionamos al puerto 2525 pero si queriamos hacerlo sobre el puerto 25 de nuestra maquina tenemos que tener cuidado que no este corriendo un smtp en ese puerto y lo vamos a tener que abrir como root.

Ahora vamos a ver como si nos deja enviar un mail.

[root@oc7287280510 ~]# telnet localhost 2525
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 wiki.itrestauracion.com.ar ESMTP VersionZZ XXXX; Tue, 15 Feb 2011 21:42:33 +0300
helo mail.restauradordeleyes.com.ar
250 wiki.itrestauracion.com.ar Hello localhost.localdomain [127.0.0.1], pleased to meet you
mail from:rino@restauradordeleyes.com.ar
250 2.1.0 rino@restauradordeleyes.com.ar... Sender ok
rcpt to: villadalmine@gmail.com
250 2.1.5 villadalmine@gmail.com... Recipient ok
data
354 Enter mail, end with "." on a line by itself
HOla este es un mail de prueba
.
250 2.0.0 p1FIgXUA015400 Message accepted for delivery
quit
221 2.0.0 wiki.itrestauracion.com.ar closing connection
Connection closed by foreign host.
[root@oc7287280510 ~]#

Y como ven ahora si nos dejo enviar un mail :).

Ejemplo con tunel reverso.

En el equipo B tenemos corriendo apache con una pagina pero este host esta nateado detras de una red privada como hariamos para mostrarle la pagina a nuestro cliente remoto que tiene linux ??
Facil primero le tenemos que pedir que nos habilite el puerto 22 y que deje corriendo ssh con un usuario que el nos provee asi luego vamos conectarnos a la pc de el para que despues se abra el tunel y el pueda poner en su navegador locahost:8080 y vea la pagina que tenemos en nuestro servidor privado.

Abrimos el tunel del lado del equipo que esta corriendo apache para conectarnos al equipo del cliente.
root@servidorB:~# ssh -R 8080:localhost:80 rino@192.168.1.102
The authenticity of host ‘192.168.1.102 (192.168.1.102)’ can’t be established.
RSA key fingerprint is 3a:c4:01:ea:36:0c:26:91:dc:78:5b:7b:b0:e7:6b:72.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
rino@192.168.1.102’s password:
Last login: Thu Jan 27 17:29:41 2011
[rino@oc7287280510 ~]$

Ahora telefoneamos al cliente y le decimos que pruebe poner en le navegador localhost:8080

El cliente va a tipear en una terminal o en un navegador lo siguiente.

Si es una terminal –> lynx localhost:8080 y esto le va a devolver..

            It works! Usted esta viendo la pagina de mi web privada

   This is the default web page for this server.

   The web server software is running but no content has been added, yet.
Commands: Use arrow keys to move, '?' for help, 'q' to quit, '<-' to go back.
  Arrow keys: Up and Down to move.  Right to follow a link; Left to go back.
 H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list 

Asi entonces abrimos un tunel reverso.. y escapamos al firewal interno porque viaja todo por otro puerto..

Teoria GPG[17]

Historia

GPG inicialmente fue desarrollado por Werner Koch. La versión 1.0.0 fue lanzada el 7 de septiembre de 1999. El ministerio de Economía y Tecnología del Gobierno Alemán financió la documentación y la versión a Microsoft Windows en el año 2000.

Usos de GPG

GPG es estable, calificado como un software para el uso en producción y es comúnmente incluido en los sistemas operativos como FreeBSD, OpenBSD, NetBSD y últimamente con todas las distribuciones GNU/Linux.

Aunque básicamente el programa tiene una interfaz textual, actualmente hay varias aplicaciones gráficas que utilizan recursos de GPG. Por ejemplo, ha sido integrado dentro de Kmail y Evolution, también hay un plugin llamado Enigmail que se integra con Mozilla y Thunderbird que trabajan en Windows, GNU/Linux y otros sistemas operativos. Debido a que los plugins no forman parte del mecanismo de GPG y no están especificados en los estándares OpenPGP, ni sus respectivos desarrolladores están vinculados con los proyectos de plugins, se podría pensar que las ventajas de seguridad de GPG puedan estar comprometidas o incluso perdiendo su efectividad como resultado de esta falta de coordinación y apoyo, pero al ser las herramientas de código abierto o scripts interpretados (como en el caso de los plugins en Thunderbird), se garantiza un funcionamiento fiable con la herramienta GPG.

GPG también puede ser compilado en otras plataformas como Mac OS X y Windows. En Mac OS X hay portada una aplicación libre llamada MacGPG, que ha sido adaptada para usar el ambiente del usuario y sus definiciones de clases nativas. La compilación cruzada no es un ejercicio trivial, por lo menos en parte debido a que las provisiones de seguridad cambian con el sistema operativo y su adaptación a menudo se vuelve difícil, pero los compiladores de alta calidad deben producir ejecutables que interactúen correctamente con otras implementaciones GPG.

Como trabaja GPG

GPG cifra los mensajes usando pares de claves individuales asimétricas generadas por los usuarios. Las claves públicas pueden ser compartidas con otros usuarios de muchas maneras, un ejemplo de ello es depositándolas en los servidores de claves. Siempre deben ser compartidas cuidadosamente para prevenir falsas identidades por la corrupción de las claves públicas. También es posible añadir una firma digital criptográfica a un mensaje, de esta manera la totalidad del mensaje y el remitente pueden ser verificados en caso de que se desconfíe de una correspondencia en particular.

GPG no usa algoritmos de software que están restringidos por patentes, entre estos se encuentra el algoritmo de cifrado IDEA que está presente en PGP casi desde sus inicios. En su lugar usa una serie de algoritmos no patentados como ElGamal, CAST5, Triple DES (3DES), AES y Blowfish. También es posible usar IDEA en GPG descargando un plugin extra, sin embargo este puede requerir una licencia para usuarios de algunos países en donde esté patentada IDEA.

GPG es un software de cifrado híbrido que usa una combinación convencional de criptografía de claves simétricas para la rapidez y criptografía de claves públicas para el fácil compartimiento de claves seguras, típicamente usando recipientes de claves públicas para cifrar una clave de sesión que es usada una vez. Este modo de operación es parte del estándar OpenPGP y ha sido parte del PGP desde su primera versión.

Problemas

El estándar OpenPGP especifica varios métodos de mensajes con firmas digitales. Debido a un error al intentar mejorar la eficiencia de uno de los métodos, se introdujo una vulnerabilidad de seguridad (Nguyen 2004) que afectó a un único método de mensajes firmado digitalmente utilizado en algunas versiones de GPG (desde la 1.0.2 hasta la 1.2.3, con menos de 1.000 claves listadas en los servidores de claves). Dicha vulnerabilidad ha sido corregida a partir de la versión 1.2.4 de GPG. El episodio ilustra la dificultad de realizar implementaciones correctas de algoritmos criptográficos, protocolos e incluso criptosistemas.

GPG es un sistema en línea de comandos. Diferentes implementaciones gráficas están disponibles pero sólo algunas tienen implementadas todas sus características (por ejemplo: borrado de ID, usuarios o firmas). Debido a que todas las instrucciones deben ser pasadas a la línea de comandos, rápidamente llegan a dificultar el uso correcto de aspectos no triviales del programa. El trabajo sobre una versión de librería está en progreso.

Uso GPG

Vamos a ver como usariamos gpg para tener un conocimiento basico sobre el y poder estar listo para rendirlo en LPIC-1.

Generar nuestra llave gpg.

rino@servidorB:~$ gpg --gen-key
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 4
Key expires at Sat 19 Feb 2011 03:05:33 PM EST
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "

Real name: RinoRondan
Email address: rino@restauradordeleyes.com.ar
Comment: This is a Test
You selected this USER-ID:
    "RinoRondan (This is a Test) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.....+++++
.............+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++
..+++++
gpg: /home/rino/.gnupg/trustdb.gpg: trustdb created
gpg: key B32E99FF marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2011-02-19
pub   2048R/B32E99FF 2011-02-15 [expires: 2011-02-19]
      Key fingerprint = DEDF F9DE D3EF F481 5DC6  4829 A2D2 DE78 B32E 99FF
uid                  RinoRondan (This is a Test) 
sub   2048R/56E6C627 2011-02-15 [expires: 2011-02-19]

rino@servidorB:~$

Si llegamos a tener este error -->

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 285 more bytes)

Tenemos que instalarnos la tool rng-tools y editar el archivo /etc/default/rng-tools agregandole el device -->HRNGDEVICE=/dev/urandom.
Para luego restartear el servicio --> /etc/init.d/rng-tools start.

Bueno si todo salio bien van a tener una pantalla similar a la de arriba.

Ahora vamos a ver como listamos nuestra llave creada.

rino@servidorB:~$ gpg --list-keys
/home/rino/.gnupg/pubring.gpg
-----------------------------
pub   2048R/B32E99FF 2011-02-15 [expires: 2011-02-19]
uid                  RinoRondan (This is a Test) 
sub   2048R/56E6C627 2011-02-15 [expires: 2011-02-19]

rino@servidorB:~$ 

Importar una llave publica al gpg keyring.

rino@servidorB:~$ gpg --export --armor rino@restauradordeleyes.com.ar > rinorondan.asc
rino@servidorB:~$ gpg --import rinorondan.asc 
gpg: key B32E99FF: "RinoRondan (This is a Test) " not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
rino@servidorB:~$ 

En este caso la llave publica ya la tengo... pero si tuviera una que me pasaran por mail con el gpg --import file bastaria.

Si quisiera editar una llave ..

rino@servidorB:~$ gpg --edit-key RinoRondan
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/B32E99FF  created: 2011-02-15  expires: 2011-02-19  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/56E6C627  created: 2011-02-15  expires: 2011-02-19  usage: E   
[ultimate] (1). RinoRondan (This is a Test) 

gpg> help
quit        quit this menu
save        save and quit
help        show this help
fpr         show key fingerprint
list        list key and user IDs
uid         select user ID N
key         select subkey N
check       check signatures
sign        sign selected user IDs [* see below for related commands]
lsign       sign selected user IDs locally
tsign       sign selected user IDs with a trust signature
nrsign      sign selected user IDs with a non-revocable signature
adduid      add a user ID
addphoto    add a photo ID
deluid      delete selected user IDs
addkey      add a subkey
addcardkey  add a key to a smartcard
keytocard   move a key to a smartcard
bkuptocard  move a backup key to a smartcard
delkey      delete selected subkeys
addrevoker  add a revocation key
delsig      delete signatures from the selected user IDs
expire      change the expiration date for the key or selected subkeys
primary     flag the selected user ID as primary
toggle      toggle between the secret and public key listings
pref        list preferences (expert)
showpref    list preferences (verbose)
setpref     set preference list for the selected user IDs
keyserver   set the preferred keyserver URL for the selected user IDs
notation    set a notation for the selected user IDs
passwd      change the passphrase
trust       change the ownertrust
revsig      revoke signatures on the selected user IDs
revuid      revoke selected user IDs
revkey      revoke key or selected subkeys
enable      enable key
disable     disable key
showphoto   show selected photo IDs
clean       compact unusable user IDs and remove unusable signatures from key
minimize    compact unusable user IDs and remove all signatures from key

* The `sign' command may be prefixed with an `l' for local signatures (lsign),
  a `t' for trust signatures (tsign), an `nr' for non-revocable signatures
  (nrsign), or any combination thereof (ltsign, tnrsign, etc.).

gpg> 

Cualquier cambio que hagan les va a pedir la clave para esa llave.

Todas las claves tienen un ID -->

pub 2048R/B32E99FF created: 2011-02-15 expires: 2011-02-19 usage: SC

Lo que esta resaltado en negrita es el ID de su clave gpg.

Exportar las llaves :
Ambas:
rino@servidorB:~$ gpg --export -o gpg_backup_file

Solo la privada:
rino@servidorB:~$ gpg --export-secret-key -a "RinoRondan" -o private.key
Les va a mostrar todo el string con la data de la clave privada.

Importar una clave por el ID

rino@servidorB:~/.gnupg$ gpg --recv-keys EF9AAD20
gpg: requesting key EF9AAD20 from hkp server keys.gnupg.net
gpg: key EF9AAD20: public key "G. Matthew Rice " imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2011-02-19
gpg: Total number processed: 1
gpg:               imported: 1
rino@servidorB:~/.gnupg$ 

Ahora firmamos el id que bajamos con la nuestra llave.

rino@servidorB:~/.gnupg$  gpg --edit-key G. Matthew Rice
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  1024D/EF9AAD20  created: 2004-05-14  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  2048g/EC0B7A34  created: 2004-05-14  expires: never       usage: E   
[ unknown] (1). G. Matthew Rice 
[ unknown] (2)  G. Matthew Rice 
[ unknown] (3)  G. Matthew Rice 
[ unknown] (4)  G. Matthew Rice 
[ unknown] (5)  G. Matthew Rice 
[ unknown] (6)  G. Matthew Rice 


Invalid command  (try "help")


Invalid command  (try "help")

gpg> lsign
Really sign all user IDs? (y/N) y

pub  1024D/EF9AAD20  created: 2004-05-14  expires: never       usage: SC  
                     trust: unknown       validity: unknown
 Primary key fingerprint: BD41 69EA 33A4 B657 3A28  2A80 E006 CBF0 EF9A AD20

     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 

Are you sure that you want to sign this key with your
key "RinoRondan (This is a Test) " (B32E99FF)

The signature will be marked as non-exportable.

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "RinoRondan (This is a Test) "
2048-bit RSA key, ID B32E99FF, created 2011-02-15

                  
gpg> tsign
Really sign all user IDs? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y
Your current signature on "G. Matthew Rice "
is a local signature.
Do you want to promote it to a full exportable signature? (y/N) y

pub  1024D/EF9AAD20  created: 2004-05-14  expires: never       usage: SC  
                     trust: unknown       validity: unknown
 Primary key fingerprint: BD41 69EA 33A4 B657 3A28  2A80 E006 CBF0 EF9A AD20

     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 
     G. Matthew Rice 

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I trust marginally
  2 = I trust fully

Your selection? 2

Please enter the depth of this trust signature.
A depth greater than 1 allows the key you are signing to make
trust signatures on your behalf.

Your selection? 1

Please enter a domain to restrict this signature, or enter for none.

Your selection? 1

Are you sure that you want to sign this key with your
key "RinoRondan (This is a Test) " (B32E99FF)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "RinoRondan (This is a Test) "
2048-bit RSA key, ID B32E99FF, created 2011-02-15

                  
gpg> quit
Save changes? (y/N) y

Ahora listamos:

rino@servidorB:~/.gnupg$ gpg --list-keys
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2011-02-19
/home/rino/.gnupg/pubring.gpg
-----------------------------
pub   2048R/B32E99FF 2011-02-15 [expires: 2011-02-19]
uid                  RinoRondan (This is a Test) 
sub   2048R/56E6C627 2011-02-15 [expires: 2011-02-19]

pub   1024D/EF9AAD20 2004-05-14
uid                  G. Matthew Rice 
uid                  G. Matthew Rice 
uid                  G. Matthew Rice 
uid                  G. Matthew Rice 
uid                  G. Matthew Rice 
uid                  G. Matthew Rice 
sub   2048g/EC0B7A34 2004-05-14

rino@servidorB:~/.gnupg$ 

Ahora encriptamos con un archivo nuestro para que solo lo pueda abrir una persona.

rino@servidorB:~/.gnupg$ gpg -e -u "RinoRondan" -r "G. Matthew Rice" rino 
rino@servidorB:~/.gnupg$

Despues cuando Matthew reciba el archivo el lo va a poder desencriptar asi..
gpg -d rino.gpg

Como subir mi ID a un servidor de llaves publicas

gpg --keyserver keys.gnupg.net --recv-key ID

Si quisieramos buscar mas sobre como funciona tendriamos que entender sobre estos archivos:

En el examen de LPI solo nos van a pedir que identifiquemos los archivos que estan en ~/gpg/.

gpg.conf
Nos permite crear los seteos por defectos para GPG, incluyendo nuestro servidor de llaves preferido. En donde este servidor contiene las llaves publicas de los que deseen subirla.

pubring.gpg
Contiene las llaves publicas que importamos.

random_seed
Un archivo de texto que contiene caracteristicas que permitiran a GPG crear numeros aleatorios mas facil y rapidamente.

secring.gpg
Contiene la llave privada que determina nuestra identidad.

trustdb.gpg
La base de datos de confianza, que contiene la información relativa a los valores de la confianza que ha asignado a varias claves públicas. Un usuario puede establecer diferentes niveles de confianza para las claves públicas en su anillo dominante.

Uso de GPG con Gmail

Para poder usar nuestras llaves con gmail vamos a tener que usar el thunderbird y activar el plugin Enigmail o bajarselo con aptitude.
Luego pueden utilizar el wizzar de thunderbird para habilitar la cuenta de gmail y despues configurar su llaves. Acuerdense de antes generar sus llaves con gpg.
Tambien pueden utilizar FreeGPG para firefox en donde van a poder utilizar gpg con gmail.
Aca les dejo un link donde explica --> https://security.ngoinabox.org/es/thunderbird_usarenigmail

Fuente:
http://es.wikipedia.org/wiki/OpenSSH
[2]http://es.wikipedia.org/wiki/Clave_pública
[3]http://ubuntulife.wordpress.com/2007/03/30/exportar-el-display-ejecutar-aplicaciones-x-remotas-en-local/
[4]http://www.gnupg.org/gph/es/manual.html#AEN210
[5]http://codesorcery.net/old/mutt/mutt-gnupg-howto
[6]http://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/
[7]http://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/s2-ssh-configuration-keypairs.html
[8]http://www.ucolick.org/~sla/ssh/agenttips.html
[9]https://wiki.archlinux.org/index.php/Using_SSH_Keys
[10]http://fedoraproject.org/wiki/DocsProject/UsingGpg/CreatingKeys
[11]https://security.ngoinabox.org/es/thunderbird_usarenigmail
[12]http://www.dotdeb.org/2010/07/11/dotdeb-packages-are-now-signed/
[13]http://www.itrestauracion.com.ar/?p=26
[14]http://www.e-ghost.deusto.es/docs/articulo.ssh.html
[15]http://crysol.org/es/node/1317
[16]http://www.rossde.com/PGP/index.html
[17]http://es.wikipedia.org/wiki/GNU_Privacy_Guard
[18]http://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny
[19]http://technologist.pro/systems/encrypt-data-using-gpggnu-privacy-guard

Preparando LPIC-1 110.2 Configurar la seguridad del host

1- Introduccion
2- Inetd
2-1 Instalacion
2-2 Configuracion
2-3 Configuracion con TCP_WRAPPER
2-4 Ejemplo de Configuracion con TCP_WRAPPER
2-5 Tabla de valores de TCP_WRAPPER
2-6 Mas Ejemplos de TCP_WRAPPER
3-0 Xinetd
3-1 Configuracion Xinetd
3-2 Tabla de Valores Xinetd
3-3 Usando ssh con Xinetd
4 Fuentes

Introduccion

Aqui veremos algunas de las cosas mas importates para darle mayor seguridad a nuestro host.
Empezaremos con el demonio Inetd, pero antes vamos a introducirnos con una breve descripcion acerca de lo que es asegurar nuestro host.
Tenemos que dejar en claro que no hay nada que cumpla con una seguridad del 100% en nuestro equipo. Se pueden realizar diversas tecnicas y mejoras para que nuestro equipo no quede expuesto a fallas o ataques pero siempre se va a encontrar problemas. Aca es donde uno tiene que decidir que politicas seguir dependiendo de las necesidades que tengamos.
Para poder empezar a hablar de seguridad en nuestro host debemos saber que hay multiples herramientas y servicios que nos brindaran diversas soluciones dependiendo de nuestras necesidades. Los servicios de redes que corren en nuestros host son inicializados mediante un script donde cada uno de ellos administran sus recursos disponiendo de lo que necesiten. En contraposicion a esto tenemos una forma de centralizar los servicios en un unico demonio que en sus inicios fue llamado inetd y luego Red Hat lanzo la version extendida denominada Xinetd. Estos demonios son llamados “Super Servers” porque engloban una cantidad enorme de servicios que utilizan nuestra red para brindar distintos servicios en donde tenemos un unico demonio en memoria que va ir cargando los demas bajo demanda segun sea la peticion que reciba este servicio. Esto se debe a que años atras cuando la memoria ram era algo tan preciado el tener tantos procesos corriendo para cada servicio hacia que el uso sea demasiado alto y por eso se optaba por agregar los servicios al demonio inetd/xinetd.
El servicio Inetd tiene dos importantes caracteristicas:
* Es un simple proceso que puede escuchar en multiples puertos para sus conexiones entrantes, iniciando el servicio correspondiente de acuerdo al puerto que se le solicite.
* Tambien soporta un sistema de seguridad que nos permite poder aceptar o denegar el acceso a los servicios que esten configurados en donde muchos de ellos por su cuenta no poseen de estas caracteristicas.
Tambien luego salio una mejora que es Xinetd. Este seria el reemplazo de inetd en donde se mejoro notablemente la forma de darle mas control a todo lo referente a la seguridad proporcionando una mejora importante en el logging de nuestros servicios.

Inetd

Aqui desarrollaremos cada parte del demonio inetd.

Instalacion

Antes de empezar a explicar cada parte y como se configura vamos a ver como se instala.

Primero hagamos una consulta para ver si se encuentra instalado.

debian:/etc# dpkg -l |grep -i inetd
ii  openbsd-inetd                     0.20080125-2               The OpenBSD Internet Superserver
ii  update-inetd                      4.31                       inetd configuration file updater
debian:/etc#

El archivo de configuracion se encuentra aqui>

debian:/etc# ls -la inetd.conf
-rw-r--r-- 1 root root 1056 2011-02-06 17:33 inetd.conf
debian:/etc#

Aqui un ejemplo:

debian:/etc# cat /etc/inetd.conf
# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet superserver configuration database
#
#
# Lines starting with "#:LABEL:" or "##" should not
# be changed unless you know what you are doing!
#
# If you want to disable an entry so it isn't touched during
# package updates just comment it out with a single '#' character.
#
# Packages should modify this file by using update-inetd(8)
#
#  

#
#:INTERNAL: Internal services
#discard		stream	tcp	nowait	root	internal
#discard		dgram	udp	wait	root	internal
#daytime		stream	tcp	nowait	root	internal
#time		stream	tcp	nowait	root	internal

#:STANDARD: These are standard services.

#:BSD: Shell, login, exec and talk are BSD protocols.

#:MAIL: Mail, news and uucp services.

#:INFO: Info services

#:BOOT: TFTP service is provided primarily for booting.  Most sites
#       run this only on machines acting as "boot servers."

#:RPC: RPC based services

#:HAM-RADIO: amateur-radio services

#:OTHER: Other services

debian:/etc#

Vamos a instalar el servicio telnet para hacer que inetd lo maneje.
Para eso acuerdense de tener bien actualizada su sources.list (http://debgen.simplylinux.ch)

debian:/etc/apt# aptitude search telnetd
p   inetutils-telnetd                               - telnet server
p   krb5-telnetd                                    - Secure telnet server supporting MIT Kerberos
p   telnetd                                         - The telnet server
p   telnetd-ssl                                     - The telnet server with SSL encryption support
debian:/etc/apt#

vamos a elegir el paquete telnetd.

debian:/etc/apt# aptitude install telnetd
Reading package lists... Done
..
..
Reading task descriptions... Done         

debian:/etc/apt#
debian:/etc/apt# whereis in.telnetd
in: /usr/sbin/in.telnetd
debian:/etc/apt#

Ahora le agregamos la linea al archivo de configuracion
debian:/etc/apt# echo "telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd" >> /etc/inetd.conf
Corroboramos que se halla agregado bien.
debian:/etc/apt# cat /etc/inetd.conf  |grep -i telnet
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
debian:/etc/apt#

Ahora restarteamos el servicio:
debian:/etc/apt# invoke-rc.d openbsd-inetd restart
Restarting internet superserver: inetd.
Corroboramos que este levantado el puerto 23 correspondiente a telnet
debian:/etc/apt# netstat -atnp |grep -i inetd
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      2999/inetd
debian:/etc/apt#

Ahora lo que vamos a hacer es conectarnos des una terminal remota a nuestro equipo por medio de telnet que acabamos de levantar. Ojo que telnet ya para conexiones remotas no es lo mas seguro porque va sin cifrar.

[rino@oc7287280510 ~]$ telnet 192.168.1.100
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
Debian GNU/Linux 5.0
debian login: debian
Password:
Last login: Sun Feb  6 20:19:36 ART 2011 from 192.168.1.102 on pts/1
Linux debian 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debian@debian:~$
Como ven estamos en una terminal remota.
debian:/etc/apt# tty
/dev/pts/0
Ahora si prestan atencion desde esta terminal remota vamos a ver las conexiones establecidas y vean como esta listada nuestra conexion. Tambien van a ver una por ssh.
debian:/etc/apt# netstat -atnp |grep -i established
Active Internet connections (servers and established)
tcp        0     48 192.168.1.100:22        192.168.1.102:36645     ESTABLISHED 2598/0
tcp        0      0 192.168.1.100:23        192.168.1.102:57320     ESTABLISHED 3028/in.telnetd: 19
debian:/etc/apt#
debian:/etc/apt# lsof -i  |grep -i telnet
inetd     2999        root    4u  IPv4   8040       TCP *:telnet (LISTEN)
in.telnet 3028        root    0u  IPv4   8136       TCP 192.168.1.100:telnet->192.168.1.102:57320 (ESTABLISHED)
in.telnet 3028        root    1u  IPv4   8136       TCP 192.168.1.100:telnet->192.168.1.102:57320 (ESTABLISHED)
in.telnet 3028        root    2u  IPv4   8136       TCP 192.168.1.100:telnet->192.168.1.102:57320 (ESTABLISHED)
debian:/etc/apt#

Antes de seguir explicando que es cada cosa, vamos a configurar tambien el servicio ftp para que funcione con inetd.

debian:/etc# aptitude install ftpd
Reading package lists... Done
..
..
Reading task descriptions... Done
debian:/etc#
debian:/etc# whereis in.ftpd
in: /usr/sbin/in.ftpd /usr/sbin/in.telnetd
debian:/etc#
debian:/etc# cat /etc/inetd.conf |grep -i ftp
ftp		stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.ftpd

Ahora vemos quedo todo:
debian:/etc# invoke-rc.d openbsd-inetd restart
Restarting internet superserver: inetd.
debian:/etc# netstat -atnp |grep -i 21
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      3144/inetd
debian:/etc#

Fijense lo siguiente ambos puertos 21 y 23 estan escuchando atraves de inetd y por ende en el mismo proceso.
debian:/etc# netstat -atnp |egrep -i “21|23” |grep -vi established
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3144/inetd
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 3144/inetd
debian:/etc#
3144 es el numero del proceso.

Ahora una muestra de como me conecto al fpt.
[rino@oc7287280510 ~]$ ftp 192.168.1.100
Connected to 192.168.1.100 (192.168.1.100).
220 debian.private FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
Name (192.168.1.100:rino): debian
331 Password required for debian.
Password:
230- Linux debian 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686
230-
230- The programs included with the Debian GNU/Linux system are free software;
230- the exact distribution terms for each program are described in the
230- individual files in /usr/share/doc/*/copyright.
230-
230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
230- permitted by applicable law.
230 User debian logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bye
221 Goodbye.
[rino@oc7287280510 ~]$

Otra forma de probar si anda.

debian:~# /usr/sbin/tcpdmatch -d -i /etc/inetd.conf in.telnetd@192.168.1.100 debian@192.168.1.100
warning: host address 192.168.1.100->name lookup failed
client:   address  192.168.1.100
client:   username debian
server:   address  192.168.1.100
server:   process  in.telnetd
access:   granted
debian:~# /usr/sbin/tcpdmatch -d -i /etc/inetd.conf in.ftpd@192.168.1.100 debian@192.168.1.100
warning: host address 192.168.1.100->name lookup failed
client:   address  192.168.1.100
client:   username debian
server:   address  192.168.1.100
server:   process  in.ftpd
access:   granted
debian:~# 
debian:~# tcpdchk  -i /etc/inetd.conf  -v
Using network configuration file: /etc/inetd.conf

>>> Rule /etc/hosts.allow line 13:
daemons:  ALL
clients:  ALL
access:   granted
debian:~# 

Configuracion

Ahora ya que vimos como instalarlo y probarlo nos queda ver como se configura bien cada entrada en el archivo inetd.conf y luego introducirlos a lo que se llama TCP_WRAPPER.

El archivo de configuracion /etc/inetd.conf centraliza todos los servicios en el pero tambien podriamos encontrar que existe el directorio /etc/inet.d/ y adentro de el estaran los servicios especificos que queremos levantar , teniendo obviamente un archivo global que seria /etc/inetd.conf

En la siguiente tabla vamos a explicar el orden y significado de cada campo del archivo inetd.conf.

Pos. Campo Nombre Descripcion
1 Nombre del Servicio Nombre del Servicio que corresponde al archivo /etc/services. Esto determina en que puerto escuchara
2 Tipo de Socket Puede ser , stream, dgram,raw o seqpacket.Tcp usa dgram y udp stream.
3 Protocolo Puede ser alguno de los siguientes
* tcp,tcp4 = TCP ipv4
* udp,udp4 = UDP ipv4
* tcp6 = TCP ipv6
* udp6 = UDP ipv6
* tcp46 = Ambos TCP (ipv4 y ipv6)
* udp46 = Ambos UDP (ipv4 u ipv6)
4 Opciones de conexion La sintaxis {wait|nowait}[/max-child[/max-connections-per-ip-per-
minute[/max-child-per-ip]]]
* La opcion wait o nowait definoe como inetd maneja las conexiones entrantes. Si esta indicado wait, inetd manejara todas las peticiones a trabes de un solo demonio, en cambio con nowait esto significa que inetd iniciara un nuevo proceso por cada conexion entrante.
* /max chlid indica la cantidad de conexiones que se aceptan al mismo tiempo.
*/max-connections-per-ip-per-minute and /max-child-per-ip son los límites opcionales que se pueden colocar sobre este recurso, para evitar los abusos y ataques de denegación de servicio. En donde se delimita las conexiones por cantidad (tiempo y proceso).
5 Usuario que ejecuta el servicio El servicio sera inicializado con el usuario que le indiquemos.
6 Servidor Ruta de acceso completa para el servicio que inetd debe comenzar.
7 Opciones del Servidor Argumentos de línea de comandos (si los hay) que se debe pasar al servidor.

2-3 Configuracion con TCP_WRAPPER

A esta altura se preguntaran porque estamos usando /usr/bin/tcpd para iniciar el servicio telnet y ftp. Bueno esto se debe a que tcpd inicializa por parametro el servicio que querramos en este caso telnet y ftp y lo hace utlizando tcp_wrapper que a continuacion vamos a ver para que nos sirve.
Utilizamos todos los servicios que queremos que levante inetd con tcpd porque asi podemos aprovechar la ventaja de TCP_WRAPPER.
El demonio tcpd, también conocido como el paquete TCP wrappers, se puede utilizar para limitar las conexiones se pueden hacer a algunos servicios de red. De esta manera usted puede limitar el acceso a los servicios unicamente a los usuarios autorizados. Es fácil de configurar e integrar en un sistema de trabajo. No hay cambios que deban hacerse a los demonios de red, sólo pequeños cambios en el archivo inetd.conf.

Ventajas:
Cuando un usuario intenta obtener acceso cliente para un servicio de red que esta utilizando envoltorios TCP, un pequeño programa envoltorio reporta el nombre del servicio solicitado y la informacion del host cliente. EL programa envoltorio no envia directamente informacion al cliente, una vez satisfechas las directivas de control de acceso, el envoltorio se descarga y libera los recursos que esta utilizando. Los envoltorios TCP proporcionan principalmente dos ventajas frente a otras tecnicas de control de servicios de red:
* El cliente que establece la conexion no advierte que envoltorios TCP esta en uso. Los usuarios legitimos no notan ninguna diferencia y los usuarios que intenten atacar al sistema no reciben informacion que indique por que ha fallado su intento de conexion.
* Los envoltorios TCP operan separados de las aplicaciones a las que protege el programa envoltorio. Esto permite que muchas aplicaciones de servidor compartan un grupo comun de ficheros de configuracion para simplificar su administracion.

Aca podemos listar las librerias que utiliza tcpd.
debian:~# ldd /usr/sbin/tcpd
linux-gate.so.1 => (0xb7748000)
libwrap.so.0 => /lib/libwrap.so.0 (0xb773a000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75df000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb75c5000)
/lib/ld-linux.so.2 (0xb7749000)
debian:~#

La libreria de tcp_wrapper es libwrap.so.0

debian:~# dpkg -l |grep wrapper
ii  libwrap0                          7.6.q-16                   Wietse Venema's TCP wrappers library
ii  tcpd                              7.6.q-16                   Wietse Venema's TCP wrapper utilities
debian:~# 

Para poder utilizar todo esto TCP_WRAPPER utiliza dos archivos.

/etc/host.allow
/etc/host.deny

Ambos archivos de configuración utilizan el mismo formato. Si ninguno de los archivos no existne, es considerado como vacío. Si hay entradas en hosts.allow, pero no hosts.deny,
todo lo que no se autorice de forma expresa se niega. Por el contrario, si hay entradas en
hosts.deny, pero no en hosts.allow, se permiten aquellas conexiones que explícitamente no se han negado. Si existen ambas entradas , el hosts.allow se comprueba en primer lugar, y luego hosts.deny. Así que incluso si una conexión es negada en hosts.deny, puede ser anulada con hosts.allow. La sintaxis de estos archivos es el siguiente

Servicio : lista de host [: commando ]

Los servicios son los que estan listados en /etc/services.

Para listar las aplicaciones que soportan libwrap

debian:/usr/bin# cd /usr/sbin
debian:/usr/sbin# for file in *
> {
> if [ -f $file ]; then
> result=`ldd $file | grep -c libwrap`
> if [ "$result" -gt "0" ]; then
> echo "/usr/sbin/$file is linked to libwrap.so"
> fi
> fi
> }
/usr/sbin/inetd is linked to libwrap.so
/usr/sbin/sshd is linked to libwrap.so
/usr/sbin/tcpd is linked to libwrap.so
/usr/sbin/tcpdchk is linked to libwrap.so
/usr/sbin/tcpdmatch is linked to libwrap.so
/usr/sbin/try-from is linked to libwrap.so
debian:/usr/sbin# 

2-4 Ejemplo de Configuracion con TCP_WRAPPER

Vamos a mostrar algunos ejemplos de como configurar nuestros envoltorios TCP.

Aca lo primero que hacemos es denegar todo.
debian:/var/log# cat /etc/hosts.deny |grep -v \#

ALL: ALL
debian:/var/log# 

Luego aceptamos las conexiones que nos interesan y las demas que utilizen la libreria tcp_wrapper quedaran negadas.
debian:/var/log# cat /etc/hosts.allow |grep -v \#
in.telnetd : 192.168.1.0/255.255.255.0 : spawn (/bin/echo  `date` %c %u>> /var/log/user.log) & 
in.ftpd : 192.168.1.10
sshd: ALL
debian:/var/log#

Aca vemos que cuando intentan acceder al telnet este va a generar una entrada en el archivo user.log en donde nos dira quien fue el que intento conectarse.

debian:/var/log# tail -n 1 /var/log/user.log 
Sun Feb 6 23:39:19 ART 2011 192.168.1.102 unknown
debian:/var/log# 

Para mas informacion todo lo demas queda logueado en /var/log/syslog

FTP:
debian:/var/log# cat syslog |grep -i ftp
Feb 6 20:34:30 debian in.ftpd[3158]: connect from 192.168.1.102 (192.168.1.102)
Feb 6 23:16:42 debian in.ftpd[7918]: refused connect from 192.168.1.102 (192.168.1.102)
debian:/var/log#

debian:/var/log# cat syslog |grep -i telnet| tail -n 5
Feb 6 23:37:51 debian in.telnetd[8078]: error: /etc/hosts.allow, line 13: bad option name: “%u>>”
Feb 6 23:37:51 debian in.telnetd[8078]: refused connect from 192.168.1.102 (192.168.1.102)
Feb 6 23:38:22 debian in.telnetd[8110]: error: /etc/hosts.allow, line 13: bad option name: “%u>>”
Feb 6 23:38:22 debian in.telnetd[8110]: refused connect from 192.168.1.102 (192.168.1.102)
Feb 6 23:39:19 debian in.telnetd[8152]: connect from 192.168.1.102 (192.168.1.102)
debian:/var/log#

debian:/var/log# cat auth.log |grep -i ssh| tail -n 5
Feb 6 23:16:12 debian sshd[7908]: pam_unix(sshd:session): session closed for user root
Feb 6 23:16:16 debian sshd[7915]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.102 user=root
Feb 6 23:16:17 debian sshd[7915]: Failed password for root from 192.168.1.102 port 35700 ssh2
Feb 6 23:16:23 debian sshd[7915]: Failed password for root from 192.168.1.102 port 35700 ssh2
Feb 6 23:16:36 debian sshd[7915]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.102 user=root
debian:/var/log#

Ahora que pasa si quisieramos enviarle un aviso al cliente cuando no pueda conectarse.
Contenido de hosts.allow
ALL : ALL \
: severity auth.info \
: twist /bin/echo “No se permite utilizar %d desde %h.”

debian:/var/log#

Mensaje que recibe el clente:
[rino@oc7287280510 ~]$ ftp 192.168.1.100
Connected to 192.168.1.100 (192.168.1.100).
No se permite utilizar in.ftpd desde 192.168.1.102.
ftp>
A diferencia de spawn twist le envia un mensaje al cliente diciendole porque no se pudo conectar.

Como veran el tema de los logs es muy importante asi que vale la pena dedicarle un tiempo para armar los logs de la manera mas eficiente para que luego podamos sacar estadisticas.

2-5 Tabla de valores de TCP_WRAPPER

Tenemos la siguiente sintaxis:

Lista_demonios : lista_clientes [:spawn comando_shell]

Lista_demonios: Una colecion con uno o mas nombres de procesos o comodines especiales, separada con espacios en blanco.

Lista_clientes: Uno o mas nombres de host, direcciones de host, patrones o comodines, separados por espacios en blanco, para utilizarlos cuando el nombre de un proceso determinado coincide con un servicio solicitado.

Comando_Shell: Un componente opcional que especifica la accion a tomar en caso de que se utilice una regla.

Los patrones son especialmente utiles para especificar grupos de clientes que pueden o no tener acceso a determinado servicio. Si se coloca un caracter (.) al principio de una cadena, se aplica esa regla a todos los hosts que comparten el final de esa cadena. Es decir que .dominio.com afectara a sistema1.dominio.com y sistema2.dominio.com
El carater (.) al final de la cadena tiene el mismo efecto, excepto que va en la direccion contraria. Esto se utiliza principalmente en direcciones IP, pues una regla que se aplique a 192.168.1. afectara a todo el bloque de clase C de direcciones IP. Tambien pueden utilizarse expresiones de mascara de red como patrones para controlar e lacceso de un grupo determinado de direcciones ip. Incluso es posible utlilizar (*) o signos de interrogacion (?) para seleccionar grupos completos de nombrde hosts o direccioens IP,siempre que no los utilice la misma cadena que los otros tipos de patrones.

Pueden Utilizarse los siguientes valores en vez de ip o nombres de equipos.

Metodo Funcion
.domain.org Incluye todos los hosts que estan en el dominio
192.168.1. Incluye todos los equipos dentro de ese rango
Address/Mask Rango de ip con su mascara
ALL Corresponde a todos los clientes de un servicio. Para permitir a un cliente
el acceso a todos los servicios, utilice ALL en la seccion demonios
LOCAL Corresponde a cualquier host cuyo nombre de host y direccion de host sean conocidos, o si el usuario es conocido
UNKNOWN Corresponde a cualquier host cuyo nombre de host o direccion de host sean desconocidos, o si el usuario es desconocido
PARANOID Corresponde a cualquier host cuyo nombre de host no coincida con la direccion de host

Una buena practica es denegar todo en host.allow y luego ahi empezar a darle permiso o denegar algunos en particular.
Para eso podriamos usar la palabra reservada EXCEPT

in.telnetd: 10.0.1.23
in.ftpd: 10.0.1. EXCEPT 10.0.1.11

Ademas de permitir o denegar el acceso a servicios a determinados hosts, tambien presta soporte al usode comandos de shell. Estos comandos shell se utilizan mas comunmente con reglas de denegacion para configurar trampas que suelen activar acciones que registran informacion acerca de intentos de conexion fallidos en un fichero especial o envian un mensaje de correo electronico a un administrador. Tenemos que mencionar otra caracteristica que es el soporte de expansiones. Las expansiones proporcionan al comando informacion acerca de cliente, servidor y proceso involucrados. A continuacion mostramo una lista de expansiones que tienen soporte para esto:

Patron Funcion
%a La direccion IP del cliente
%A LA direccion IP del servidor
%c Proporciona informacion del cliente, como el nombre de usuario y el nombre de host o el nombre de usuario y la direccion IP
%d El nombre de proceso del demonio
%h El nombre del host del cliente ( o la direccion IP, sino esta disponible el nombre del host)
%H El nombre del host del servidor ( o la direccion IP, sino esta disponible el nombre del host)
%n El nombre de host del cliente. Si no esta disponible, se imprime UNKNOWN.
Si el nombre de host y la direccion de host del cliente no coinciden, se imprime PARANOID
%N El nombre de host del cservidor Si no esta disponible, se imprime UNKNOWN.
Si el nombre de host y la direccion de host del servidor no coinciden, se imprime PARANOID
%p El ID del proceso demonio
%s Informacion del servidor, como el proceso demonio y la direccion de host o IP dervidor
%u El nombre de usuario del cliente, si no esta disponible, se imprime unknown.

Mas Ejemplos de TCP_WRAPPER

Aca voy a citar algunos ejemplos de uso..
# Bloquear peticiones posiblemente falsificadas a sendmail:
sendmail : PARANOID : deny

# No permitimos conexiones desde ejemplo.com:
ALL : .ejemplo.com \
: spawn (/bin/echo %a desde %h intento acceder a %d >> \
/var/log/connections.log) \
: deny

# The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo “No se permite utilizar %d desde %h.”

# This line is required for POP3 connections:
qpopper : ALL : allow

ALL : .crackers.com \
: spawn (/bin/echo %a from %h attempted to access %d >> \
/var/log/connections.log) \
: deny

ALL: LOCAL @devels
ALL: .nixcraft.net.in EXCEPT boobytrap.nixcraft.net.in

popd : 192.168.1.200 192.168.1.104
imapd : 192.168.1.0/255.255.255.0
sendmail : 192.168.1.0/255.255.255.0
sshd : 192.168.1.2 172.16.23.12

sshd ,ftpd : ALL
ALL: localhost

in.fingerd: ALL: spawn (/usr/sbin/safe_finger -l @%h | \
/usr/bin/mail -s finger-%d-%h root) &
in.telnetd: ALL: spawn (/usr/sbin/safe_finger -l @%h | \
/usr/bin/mail -s telnet-%d-%h root) &

in.tftpd: .mynet.com EXCEPT .seas.mynet.com
in.fingerd: .mynet.com EXCEPT .seas.mynet.com
in.telnetd: .mynet.com EXCEPT .seas.mynet.com

ALL : 206.182.68.0 : spawn /bin/ ‘date’ %c %d >> /var/log/intruder_alert
vsftpd : ALL : banners /etc/banners/
in.telnetd : ALL : severity emerg
* Completamente cerrado:

#/etc/hosts.allow
* ALL: ALL: deny Cerrado para todos excepto para las conexiones locales:

#/etc/hosts.allow
ALL: 127.0.0.1
* ALL: ALL: deny Conexión local total, red local acceso por telnet y ftp, resto cerrado:

#/etc/hosts.allow
ALL: 127.0.0.1
in.telnetd in.ftpd: LOCAL
* ALL: ALL: deny Sistema cerrado con informe de accesos:

#/etc/hosts.allow
* ALL: ALL: twist ( /usr/bin/echo -e “Intruso %a en puerto %d” ) Sistema abierto a la red local y cerrado al exterior con acciones diferentes en función del tipo de acceso:

#/etc/hosts.allow
ALL: LOCAL: spawn ( echo -e “Acceso autorizado de %a por %d” ) &
ALL: PARANOID: twist ( echo -e “ATACANTE %a por puerto %d, lanzando nukes” ; /usr/local/bin/nukes.sh %a ) &
ALL: UNKNOWN: twist ( echo -e “Posible nuke o scan de %a en %d” ) &
ALL: ALL: twist ( /bin/echo -e “INTRUSO! %a, usando puerto %d” ) &

Usos avanzados de tcp_wrappers, que mas puedo hacer con esto?

* Detectando spoofing: los intentos de spoofing son detectados por tcp_warppers y los clasifica dentro de la categoría de PARANOID, por lo que esta linea en hosts.allow puede ayudarnos bastante a detectarlo:

* ALL: PARANOID: twist ( echo -e “Spoofing en puerto %d \nLa IP %a es falsa” ) Mantener informes de red: redirigir toda la información de salida a un archivo o una consola, nos ayudara a tener informes exhaustivos de los accesos que recibimos, los ataques, los accesos … para hacer esto basta con poner lineas así:

* ALL: ALL: spawn ( echo -e “IP %a en %d” > /var/log/archivo ) Realizar múltiples comandos: a veces es necesario hacer mas de una cosa frente un acceso, la sintaxis es igual que si lo hiciéramos desde bash:

* ALL: ALL: spawn ( echo -e “IP %a en %d” ; wavplay alarma.wav ; nestea %a ) Enviando mensajes al sistema remoto: se puede enviar un mensaje predefinido (banner) al sistema remoto, en este mensaje podemos explicar porque no le damos acceso, que tipo de máquina tnemos, que puede hacer o no …

Para que el sistema remoto vea el banner utilizaremos la linea:
ALL: ALL: banners /directorio_de_banners

Nota: el banner debe llamarse como el demonio que se lanza, es decir si queremos que se vea un mensaje al entrar por telnet, el banner deberá llamarse in.telnetd

Ejemplo: este banner (al que llamaremos in.telnetd) se ve al hacer acceso por telnet
Hola %a, bienvenido a mi sistema. Tu IP esta siendo guardada para mayor seguridad.

Xinetd

Aqui veremos un poco de que se trata Xinetd.
Como mencionamos anteriormente Xinetd es una mejora de inetd dado que nos da la posibilidad de exponenciar la seguirdad que da tcp_wrapper junto con las nuevas directivas que xinetd que funciona al igual que inetd como un super servicio que engloba a otros mas manejando todo en un demonio.
Las ventajas que ofrece aumenta cuando se utiliza la biblioteca libwrap.a junto con xinetd, un superdemonio que proporciona control adicional de acceso,registro,redireccion y uso de recursos. Cuando se accede a cualquiera de los servicios a traves de los numeros de puertos correspondientes en /etc/services, el demonio xinetd gestiona la peticion. Antes de abrir el servicio de red solicitado, xinetd garantiza que la informacion del host cliente cumple las reglas de control de acceso, que el numero de instancias del servicio esta por debajo de un umbral determinado y que cualquier otra regla especificada para ese servicio o para todos los servicios xinetd se cumple. Una vez que se abre el servicio para el cliente que establece la conexion , xinetd vuelve a dormir, esperando peticiones adicionales sobre los servicios que gestiona.

3-1 Configuracion Xinetd

Vamos a instalar xinetd. Seguramente nos va a decir que va a desinstalar inetd.

debian:/var/log# aptitude install xinetd
Reading package lists… Done
Building dependency tree
Reading state information… Done
Reading extended state information
Initializing package states… Done
Reading task descriptions… Done
The following NEW packages will be installed:
xinetd
The following packages will be REMOVED:
openbsd-inetd{a}
0 packages upgraded, 1 newly installed, 1 to remove and 5 not upgraded.
Need to get 136kB of archives. After unpacking 180kB will be used.
Do you want to continue? [Y/n/?]

Le decimos que si y que continue con la instalacion.

Los archivos de configuracion se encuentran :

debian:/var/log# ls -l /etc/xinetd.conf 
-rw-r--r-- 1 root root 289 2008-03-26 14:39 /etc/xinetd.conf
debian:/var/log# ls -l /etc/xinetd.d/
total 20
-rw-r--r-- 1 root root 798 2008-03-26 14:39 chargen
-rw-r--r-- 1 root root 660 2008-03-26 14:39 daytime
-rw-r--r-- 1 root root 549 2008-03-26 14:39 discard
-rw-r--r-- 1 root root 580 2008-03-26 14:39 echo
-rw-r--r-- 1 root root 727 2008-03-26 14:39 time
debian:/var/log# 

Como ven estan separados, tiene un archivo general que es xinetd.conf y luego un directorio xinetd.d en donde ahi adentro va a tener un archivo para cada servicio.

Podriamos tener en nuestro archivo gral unas directivas globales que afectaran a todo los demas servicios o tenerlo vacio donde cada servicio tenga sus directivas.

debian:/var/log# cat /etc/xinetd.conf 
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

}

includedir /etc/xinetd.d
debian:/var/log#

Un ejemplo si quisiera habilitar telnet con xinetd:
debian:/etc/xinetd.d# cat /etc/xinetd.d/telnet
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_type = SYSLOG daemon info
log_on_failure += USERID
no_access = 10.0.1.0/24
log_on_success += PID HOST EXIT
access_times = 00:45-16:15
}
debian:/etc/xinetd.d#
Aca vemos como guarda el log:
syslog:Feb 7 01:42:04 debian xinetd[8889]: START: telnet pid=8895 from=192.168.1.102

Aca otro ejemplo si quisieramos con ftp:
debian:/var/log# cat /etc/xinetd.d/ftp
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
debian:/var/log#

Aca vemos como me guardo el log.

syslog:Feb 7 01:23:02 debian ftpd[8776]: connection from 192.168.1.102
syslog:Feb 7 01:23:16 debian ftpd[8776]: FTP LOGIN FROM 192.168.1.102 as debian

3-2 Tabla valores Xinetd

Vamos a detallar la tabla de valores mas usados que tenemos para poder configurar nuestros servicios:

Campo Descripcion
id Nombre del servicio
flags Los flags mas usados son:
* NORETRY = no intente en caso de que falle
* KEEPALIVE = setea este flag en el socket tcp
* SENSOR = Que no corra este servicio , tan solo que escuche y asi vea quienes se quisieron conectar
* IPV4 = solamente ipv4
* IPV6 = solamente ipv6
disable Valor booleano que determina si el servicio esta apagado o no
socket_type stream,dgram,raw,seqpacket
protocol Tiene que ser un protocolo valido /etc/protocols
wait Se usa para tcp que normalmente esta en no y en udp en si
user El servicio corre como el usuario que especifiquemos
group EL grupo con que va a correr el servicio
instances La cantidad de instancias que puede correr del servicio, por defecto es sin limite
nice El valor de prioridad con que va a correr
Server La ruta completa de donde va a correr el servicio
Server Args Con que parametros va a correr ese servicio
only_from Restriccion desde que ip,host o red se va a poder acceder
no_acces Restriccion desde que ip,host o red no se va a poder acceder
access_time Determina en que horas del dia se va a poder usar, formato es HH:MM – HH:MM
log_type Las opciones son SYSLOG o FILE
log_on_success Cuales son las variables que utiliza para loguear el evento
log_on failure Cuales son las variables que utiliza para loguear el evento
port Cual es el puerto que va escuchar xinetd para ese servicio
bind Cual es la ip que va a estar escuchando para xinetd. Util para cuando tenemos multiples ip
per_source NUmero maximo de conexiones para una ip
max_load Una vez que paso un minuto luego de superar la carga maxima no va a aceptar mas conexiones hasta que baje esta carga.
cps Una vez que supero el valor ej 25 (conexiones permitidas) el servicio queda retirado 30 segundos ej= cps = 25 30

Tambien tenemos ciertas palabras reservadas a usar:

* ATTEMPT : Registra que se ha hecho un intento de conexion fallido. (log_on_failure)
* DURATION: Registra el periodo de tiempo durante el que un sistema remoto ha utilizado un servicio (log_on_success)
* EXIT: Registra el estado salir o la señal de terminacion del servicio. (log_on_success)
* HOST: Registra la direccion ip del hosto remoto . (log_on_failre y log_on_success)
* PID: Registra el ID de proceso del servidor que recibe la peticion. (log_on_success)
* RECORD: Registra informacion acerca del sistema remoto en caso de que el servicio no pueda ser iniciado. SOlo determinados servicios, como login y finger, pueden utilizar esta opcion (log_on_failure)
USERID: Registra el usuario remoto utilizando un metodo definido en la RFC 1413 para todos los servicios flulidos (stream) multiproceso. (log_on_failure y log_on_success).

Se puede utilizar wrapper con xinetd asi que tambien podriamos usar los archivos hosts.deny y hosts.allow ademas de todas las directivas vistas anteriormente.

Tambien algo util que se puede hacer es utilizar la redireccion de puertos:
debian:/var/log# cat /etc/xinetd.d/telnet
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_type = SYSLOG daemon info
log_on_failure += USERID
no_access = 10.0.1.0/24
log_on_success += PID HOST EXIT
access_times = 00:45-16:15
bind = 192.168.1.100
redirect = 192.168.1.121 21
}
debian:/var/log#

Fijense que ahi mandamos todo lo que venga a 192.168.1.100 desde telnet hacia el puerto 21 de otra ip que tiene nuestro equipo y automaticamente nos va a responder el ftp porque ya esta utilizando ese puerto.

rino@oc7287280510 ~]$ telnet 192.168.1.100
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
220 debian.private FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.

El log lo dice todo:

Feb 7 02:28:56 debian xinetd[9463]: START: telnet pid=9472 from=192.168.1.102
Feb 7 02:28:56 debian ftpd[9473]: connection from 192.168.1.121

Creo que no vale la pena dar mas ejemplos pero mirando la tabla se pueden imaginar todo el uso que le pueden dar.

3-3 Usando ssh con Xinetd

FUENTE: http://ubuntuforums.org/printthread.php?t=661061
HOWTO: Run openssh-server sshd from xinetd

Ever wanted to run sshd from xinetd under Ubuntu? Sometimes worked, sometimes not? Here’s the fix!

First the xinetd config file:
Code:
service ssh
{
socket_type = stream
protocol = tcp
wait = no
user = root
# server = /usr/sbin/sshd
server = /usr/local/sbin/sshd_start
server_args = -i
}
Save it as /etc/xinetd.d/ssh

If you directly use sshd you might get the following problem shown in /var/log/auth.log:
Code:
sshd[8771]: fatal: Missing privilege separation directory: /var/run/sshd
So you save the following file as /usr/local/sbin/sshd_start
Code:
#!/bin/sh

if [ ! -d /var/run/sshd ]; then
mkdir /var/run/sshd
chmod 0755 /var/run/sshd
fi

/usr/sbin/sshd $*
and make it executable:

Code:
#sudo chmod u+x /usr/local/sbin/sshd_start
Now simply reload xinetd with

Code:
#sudo /etc/init.d/xinetd restart

4-0 FUENTES

http://www.cyberciti.biz/faq/how-do-i-turn-on-telnet-service-on-for-a-linuxfreebsd-system/
http://www.freebsd.org/doc/es/books/handbook/tcpwrappers.html
http://www.cyberciti.biz/faq/tcp-wrappers-hosts-allow-deny-tutorial/#comments
http://book.opensourceproject.org.cn/distrib/ubuntu/hacking/opensource/final/bbl0040.html
http://uw714doc.sco.com/en/NET_tcpip/filterN.tcp_wrappers.html
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security_Guide/sect-Security_Guide-Server_Security.html
http://www.linux-party.com/TutorialLinux/linux_files/linuxzone/web/linuxzone/tcp_wrappers.htm
http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
http://linuxhelp.blogspot.com/2005/10/using-tcp-wrappers-to-secure-linux.html
http://jamesthornton.com/redhat/linux/7.2/Reference-Guide/s1-tcpwrappers-xinetd.html
http://www.xinetd.org/
http://ubuntuforums.org/printthread.php?t=661061