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
The Preparando LPIC-1 110.2 Configurar la seguridad del host by ITRestauracion, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.