Unit 10 Rh253 v2

UNIT 10
Securing Services
J. lvarez M.
Instituto Profesional DUOC UC
Semestre 1 - 2011
Objetivos
Analizar la actividad de servicios
Implementar polticas de seguridad:
Dentro de los servicios
Con TCP Wrappers
Con xinetd
Agenda
Inspeccionar servicios de red locales
Configurar TCP Wrappers
Securizar servicios administrados por xinetd
System V startup control
Un host es configurado para proveer un rango
limitado de servicios. Todos los otros servicios
deberan ser deshabilitados por razones de
seguridad.
Ser necesario entonces determinar que
servicios estn corriendo desde scripts System
V o xinetd.
chkconfig --list provee una lista de TODOS los
servicios que son iniciados va System V o
xinetd.
Sin embargo, NO puede ser usado para
obtener una lista de los servicios que
actualmente se estn ejecutando.
[root@localhost ~]# chkconfig --list
[root@localhost ~]# chkconfig --list portmap
Para deshabilitar un servicio, se debe utilizar
chkconfig <service-name> off.
[root@localhost ~]# chkconfig portmap off
Tener en cuenta que chkconfig solo mantiene
el listado de los servicios System V linkeados
en /etc/rc.d/rcX.d y en la configuracin de
xinetd.
chkconfig no inicia o detiene, o controla la
conducta de otros servicios.
chkconfig no trabaja con los servicios iniciados
va rc.local o inittab.
Securizacin de Servicios
Muchos demonios proveen su propio conjunto
de mecanismos de seguridad.
Estos mecanismos son usualmente mucho
ms avanzados que la simple funcionalidad
que provee TCP Wrappers.
Por otro lado es mucho ms simple utilizar
una localizacin central para las polticas de
seguridad de los servicios.
La librera libwrap.so, ms comnmente referida
como TCP Wrappers, provee listas de control de
acceso basado en hosts para varios servicios de
red.
La librera, ejecutables, y documentacin son
distribuidas en tcp_wrappers<versin>.rpm.
Cuando un cliente se conecta a un servicio TCP
Wrapped, las listas de control de acceso
/etc/hosts.allow y /etc/hosts.deny son
examinadas, en ese orden.
El servidor entonces deber elegir entre
aceptar o rechazar la conexin, dependiendo
de la configuracin de la lista de control.
Las polticas pueden ser especificadas para
servicios individuales y/o mltiples servicios, y
son usualmente configuradas en trminos de
las direcciones IP clientes.
TODOS los procesos controlados por xinetd
automticamente utilizan la librera libwrap.so.
Muchos servicios RHEL son compilados y
linkeados dinmicamente con libwrap.so.
Se puede utilizar el comando ldd para desplegar
una lista de libreras dinmicamente linkeadas a
un programa particular. Por ejemplo:
[root@localhost ~]# ldd /usr/bin/talk
TCP Wrappers
TCP Wrappers es una herramienta simple que
sirve para monitorear y controlar el trfico
que llega por la red.
TCP Wrappers ha sido utilizada exitosamente
en la proteccin de sistemas y la deteccin de
actividades ilcitas.
TCP Wrappers
El cdigo original para TCP Wrappers fue
escrito por Wietze Zwuitze Venema de la
Universidad Tecnolgica de Eindhoven, Pases
Bajos, entre los aos 1990 y 1995, y desde el 1
de junio de 2001, el programa es lanzado bajo
su propia licencia tipo BSD.
TCP Wrappers funciona en base a una librera
llamada libwrap, que es la que implementa la
funcionalidad en s.
TCP Wrappers
Un Wrapper es un programa para controlar el
acceso a un segundo programa. El Wrapper
literalmente cubre la identidad del segundo
programa, obteniendo con esto un ms alto
nivel de seguridad.
TCP Wrappers
Los Wrappers son ampliamente utilizados, y han
llegado a formar parte de las herramientas de
seguridad por las siguientes razones:
Debido a que la seguridad lgica est
concentrada en un solo programa, los
Wrappers son fciles y simples de validar.
Debido a que el programa protegido se
mantiene como una entidad separada, ste
puede ser actualizado sin necesidad de
cambiar el Wrapper.
TCP Wrappers
Debido a que los Wrappers llaman al
programa protegido mediante la llamada al
sistema estndar exec(), se puede usar un
solo Wrapper para controlar el acceso a
diversos programas que se necesiten
proteger.
TCP Wrappers y xinetd
Los TCP Wrappers proporcionan control de
acceso a una gran variedad de servicios.
La mayora de los servicios modernos de
redes, tales como SSH, Telnet y FTP, hacen
uso de TCP Wrappers, que montan guardia
entre las peticiones entrantes y el servicio
solicitado.
Los beneficios ofrecidos por TCP Wrappers
son mejorados cuando se usan en conjunto
con xinetd, un super servicio que proporciona
acceso adicional, conexin enlace, redireccin
y control de la utilizacin de recursos.
Configuracin de TCP Wrappers
La configuracin es almacenada en dos
archivos: permisos en /etc/hosts.allow y
denegaciones en /etc/hosts.deny.
Primero es examinado /etc/hosts.allow. Si el
acceso NO es explcitamente permitido, es
examinado entonces /etc/hosts.deny. Si el
acceso NO es explcitamente denegado, la
conexin, por omisin, es permitida.
Cambios en los archivos de acceso son
inmediatamente efectivas para todas las
nuevas conexiones.
/etc/hosts.allow y /etc/hosts.deny tienen dos
o ms campos separados por :.
daemon_list: client_list [:options]
El primer campo especifica una lista separada por
, de nombres de ejecutables (NO nombres de
servicios), posiblemente con las wildcards ALL y
EXCEPT.
El segundo campo contiene una lista de
especificaciones de clientes, usando direcciones
IP, hostnames, dominios, subredes, o pares de
direcciones de red/mscara. Nuevamente, las
palabras clave ALL y EXCEPT son reconocidas.
Un ejemplo de configuracin del archivo
/etc/hosts.allow se muestra a continuacin:
#hosts.allow
ALL: redhat.com .redhat.com
in.ftpd: ALL
Esta configuracin permite todas las
conexiones desde mquinas redhat.com y
*.redhat.com. Tambin permite los
requerimientos de ftp desde todas las
mquinas.
1. Especificacin de nombres de demonios:
Las aplicaciones pasan nombres de sus
ejecutables.
Mltiples servicios pueden ser
especificados.
El uso del wildcard ALL permite especificar
TODOS los servicios.
Existen limitaciones para ciertos demonios.
Por ejemplo:
in.telnetd: 192.168.0.1
sshd, gdm: 192.168.0.1
Si el hosts tiene ms de una interfaz de red
es posible implementar diferentes polticas
para ellas, usando la sintaxis:
daemon@host: client_list
Por ejemplo:
in.telnetd@192.168.0.254: 192.168.0.
in.telnetd@192.168.1.254: 192.168.1.
2. Especificaciones para el cliente:
Especificaciones de hosts
Por direccin IP
Direcciones IP parciales o completas
Los componentes de ms a la derecha
son tratados como cero si son omitidos
Ejemplo: 192.168.1. (TODOS los hosts
dentro de la red clase C 192.168.1.0)
Por direccin de red/mscara
Especificar la direccin de red completa
mas la mscara de red.
La mscara de red debe ser en formato
largo
Ejemplo: 182.168.0.0/255.255.255.0
Por host name
Realiza un reverse lookup cada vez que
un cliente se conecta
NO siempre es soportado
Ejemplo: .example.com (TODOS los hosts
en el dominio example.com)
Por nombre de red
Nombres de red de /etc/networks o NIS
No trabaja junto con los usernames
Ejemplo: @mynetwork
Wildcards
ALL - Hace corresponder todo, siempre
coincide
LOCAL - TODOS los hosts sin un punto en su
nombre
UNKNOWN - TODOS los hosts o usuarios
que sean desconocidos
KNOWN - TODOS los hosts o usuarios que
pueden ser determinados o sean conocidos
PARANOID - coincide con TODOS los
hosts cuyo nombre no se corresponda
con la direccin.
Operador EXCEPT
El operador EXCEPT puede ser usado en
las listas de demonios y clientes para
excluir algunos hosts de las
coincidencias.
3. Especificacin de opciones
La versin de TCP Wrappers incluida con
RHEL soporta las opciones extendidas
documentadas en hosts_options de la
pgina del manual en lnea man.
Una de las opciones ms comnmente
utilizadas es spawn, que permite cerrar la
conexin y ejecutar un programa externo
cuando la regla coincide.
Las opciones utilizan el caracter % para los
reemplazos o expansiones. Reemplazos
comunes son:
%c Suministra informacin variada sobre el
cliente, como nombre de usuario y el de la
mquina o el nombre del usuario y la
direccin IP (user@host).
%s Suministra informacin variada del
servidor como el proceso demonio y la
mquina o la direccin IP del servidor
(server@host).
%h Suministra el nombre de host del
cliente (direccin IP si el nombre no est
disponible).
%a Suministra la direccin IP del cliente.
%A Suministra la direccin IP del servidor.
%p - PID del servidor
El ejemplo siguiente usa una expansin en
conjunto con el comando spawn para identificar
el host cliente en un archivo de registro
personalizado.
Cuando se intentan conexiones al demonio de
SSH (sshd) desde un host en el dominio
example.com, se ejecuta el comando echo para
registrar el intento, incluyendo el nombre del
host cliente (usando la expansin %h), a un
archivo especial:
De forma similar, las expansiones se pueden
utilizar para personalizar mensajes de vuelta al
cliente. En el ejemplo siguiente, los clientes
intentando accesar servicios FTP desde el
dominio example.com son informados que se
les ha prohibido acceder al servidor:
Las expansiones % que son soportadas se
encuentran documentadas en la pgina del
manual en lnea man host-access(5).
Considere el siguiente ejemplo para la
mquina 192.168.0.254 sobre una red clase C:
# /etc/hosts.allow
vsftpd: 192.168.0.
in.telnetd, portmap: 192.168.0.8
#/etc/hosts.deny
ALL: .cracker.org EXCEPT trusted.cracker.org
vsftpd, portmap: ALL
pop3d: 192.168.0. EXCEPT 192.168.0.4
En esta configuracin:
Solo las estaciones sobre la red local
pueden acceder por FTP a la mquina.
Solo la estacin 8 podra montar un
directorio NFS desde la mquina.
A TODOS los hosts en cracker.org, excepto
trusted.cracked.org, se les niega el acceso a
algn servicio TCP Wrapped.
Solo el hosts 192.168.0.4 est habilitado para
usar pop desde la red local.
Un ejemplo ms realista:
#/etc/hosts.allow
vsftpd: 192.168.0.
in.telnetd, sshd: .example.com 192.168.2.5
#/etc /hosts.deny
ALL: ALL
El ejemplo anterior deniega el acceso a todos
los servicios para cada uno, excepto aquellos
para los cuales es explcitamente permitido.
En este caso el acceso por FTP es permitido
para todos los hosts en la subred 192.168.0.0
mientras que los accesos TELNET y SSH para
todos en el dominio example.com as como al
hosts 192.168.2.5.
Securizacin de servicios xinetd
xinetd provee su propio conjunto de funciones de
control de acceso:
Basadas en hosts
Basadas en tiempo
Primero se chequea TCP Wrappers, si el acceso es
garantizado , las directivas de seguridad de xinetd
son evaluadas. Si xinetd acepta la conexin,
entonces el servicio requerido es llamado y la
seguridad especifica asociada al servicio es
evaluada.
Control de acceso xinetd
El control de acceso xinetd es implementado con
las dos siguientes directivas: only_from y
no_access.
La sintaxis es la siguiente:
Permitir con only_from=host_pattern
Denegar con no_access=host_pattern
Por ejemplo:
only_from=192.168.0.0/24
no_access=192.168.0.1
Si ambas directivas se especifican para un
servicio, la que mejor calza con la direccin
del host remoto es autoritaria.
Dado que algunos casos, la que mejor calza
puede ser ambigua, es una buena idea usar
solo una de estas directivas cuando sea
posible.
Por ejemplo:
service telnet
{
only_from = 192.168.0.0/24
no_access = 192.168.0.1
}
Esto bloquear el acceso al servicio TELNET
para todos excepto los hosts de la red
192.168.0.0/24, y de aquellos, al host
192.168.0.1 le ser denegado el acceso.
Los patrones de hosts para xinetd pueden ser:
direcciones IP numricas, por nombre de red,
por nombre de hosts y pares de direcciones
IP/mscara.
En xinetd es posible restringir el acceso a los
servicios en ciertas horas, mediante la
directiva access_times.
access_times permite especificar el intervalo
de tiempo en el que un determinado servicio
puede ser usado.
El rango de tiempo debe especificarse en
formato de 24 horas, HH:MM-HH:MM.
Por ejemplo:
service telnet
{
access_times = 08:00-16:00
server = /usr/sbin/in.telnetd
}
La directiva per_source limita el nmero de
conexiones simultneas por direccin IP, y
puede ser usada en /etc/xinetd.conf y los
archivos de configuracin especficos al
servicio en /etc/xinetd.d/. Por ejemplo:
per_source=2
Este nmero no puede exceder el nmero
total de instancias, especificada en instances.
Por ejemplo:
service telnet
{
wait = no
instances = 60
per_source = 5
server = /usr/sbin/in.telnetd
}
Recordar que los archivos de configuracin de
servicios xinetd se encuentran en el directorio
/etc/xinetd.d/.
El archivo de configuracin de xinetd es
/etc/xinetd.conf.
Por ltimo, las configuraciones en
/etc/xinetd.conf tienen precedencia sobre las
de los servicios en /etc/xinetd.d/.
A diferencia de los TCP wrappers, los cambios
al control de acceso slo tendrn efecto si se
reinicia el servicio xinetd:
[root@localhost ~]# service xinetd restart

Unit 10 Rh253 v2

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Unit 10 Rh253 v2

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIT 10

Anda mungkin juga menyukai