Siguiente: Parámetros del núcleo
Subir: Solaris
Anterior: sfpDB
Índice General
Antes de hablar de la seguridad del subsistema de red en Solaris quizás sea
necesario introducir el comando `ndd'; esta orden permite tanto consultar
(mediante el símbolo `?') como modificar la configuración de
ciertos drivers del sistema, en concreto los que soportan la pila de
protocolos TCP/IP:
anita:/# ndd -get /dev/tcp tcp_strong_iss
1
anita:/# ndd -set /dev/tcp tcp_strong_iss 2
anita:/# ndd -get /dev/tcp tcp_strong_iss
2
anita:/#
Si quisiéramos comprobar qué parámetros ofrece un determinado driver (por ejemplo /dev/tcp), lo haríamos con la orden siguiente:
anita:/# ndd -get /dev/tcp \?
El uso del carácter `' no es más que un escape del shell para el símbolo `?'. es importante conocer qué parámetros
ofrece cada driver de nuestro sistema antes de planificar una
modificación de sus valores, especialmente en Solaris 8, versión en la que
ha cambiado ligeramente el nombre de alguno de ellos y además se han incluido
algunos nuevos relativos a IPv6 (que no mostramos aquí).
Los primeros parámetros que nos interesará modificar para incrementar
la seguridad de nuestro sistema pueden ser los relacionados con el forwarding, el reenvío de paquetes de cierto tipo que llegan a la
máquina. En primer lugar, es importante evitar que nuestro equipo se convierta
en un enrutador; aunque en algunas versiones de Solaris es suficiente con
crear el fichero /etc/notrouter, lo más recomendable es deshabilitar por
completo el IP Forwarding a nivel del subsistema de red, lo cual se
consigue mediante la siguiente orden:
anita:/# ndd -set /dev/ip ip_forwarding 0
anita:/#
También es importante evitar que en hosts con múltiples tarjetas se
reenvíen tramas entre ellas; con esto conseguimos hacer más difícil
un ataque de IP Spoofing, ya que el sistema conoce en todo momento a
través de que interfaz le llega un paquete, y si lo hace por una que no le
corresponde, la trama se ignora. Para lograr este objetivo podemos modificar el
valor del parámetro ip_strict_dst_multihoming:
anita:/# ndd -set /dev/ip ip_strict_dst_multihoming 1
anita:/#
Los últimos parámetros relacionados con el reenvío de tramas en la
máquina afectan a los broadcasts y a los paquetes source routed
(aquellos que contienen en su interior el camino a seguir, total o
parcialmente, hasta su destino). Por supuesto, no es recomendable el forwarding de broadcasts dirigidos desde una estación fuera de una red
hacia todos los equipos de esa red, algo que una máquina Solaris con el IP Forwarding activado hace por defecto; de la misma forma, no se deben
reenviar tramas que marquen el camino a su destino, ya que en la mayor parte de
redes no existen motivos válidos para la emisión de este tipo de paquetes,
y muchos de ellos son denotativos de actividades sospechosas. Podemos evitar
ambos reenvíos mediante las siguientes órdenes respectivamente:
anita:/# ndd -set /dev/ip ip_forward_directed_broadcasts 0
anita:/# ndd -set /dev/ip ip_forward_src_routed 0
anita:/#
Otros parámetros a tener en cuenta para incrementar nuestro nivel de
seguridad son algunos relativos a ataques contra el protocolo ARP; para
prevenir el ARP Spoofing es recomendable reducir el timeout que
Solaris presenta por defecto y que marca la frecuencia de borrado de las
entradas de la tabla ARP y de la tabla de rutado, fijando ambas en un
minuto. Esto lo conseguimos mediante las órdenes siguientes (en las que
especificamos el tiempo en milisegundos):
anita:/# ndd -get /dev/arp arp_cleanup_interval 60000
anita:/# ndd -get /dev/ip ip_ire_flush_interval 60000
anita:/#
Dentro del protocolo ICMP también existen parámetros del subsistema de
red interesantes para nuestra seguridad; un grupo de ellos son los relacionados
con los diferentes tipos de tramas ICMP que pueden implicar un broadcast: ICMP/SMALL>_ECHO/SMALL>_REQUEST, ICMP/SMALL>_TIMESTAMP e ICMP/SMALL>_ADDRESS/SMALL>_MASK. Todos ellos pueden ser utilizados para causar
negaciones de servicio, por lo que una buena idea en la mayor parte de
situaciones es simplemente ignorarlos; incluso en el segundo caso (ICMP/SMALL>_TIMESTAMP) Solaris ofrece la posibilidad de ignorar las tramas de este
tipo aunque no sean broadcasts, simplemente paquetes dirigidos a un host deterinado, ya que pueden proporcionar información del sistema útil
de cara a un ataque. Para conseguir ignorar todas estas tramas podemos ejecutar
estas órdenes:
anita:/# ndd -get /dev/ip ip_respond_to_echo_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_timestamp_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_address_mask_broadcast 0
anita:/# ndd -get /dev/ip ip_respond_to_timestamp 0
anita:/#
Todavía dentro del protocolo ICMP, otro tipo de mensajes que nos
pueden causar problemas son los ICMP/SMALL>_REDIRECT; es conveniente
deshabilitar tanto su emisión (sólo un router tiene la necesidad
de enviar este tipo de tramas) como su recepción, ya que pueden ser
utilizados para generar rutas falsas en el subsistema de red de una máquina.
Para lograr ambas cosas podemos ejecutar las siguientes órdenes:
anita:/# ndd -get /dev/ip ip_ignore_redirects 1
anita:/# ndd -get /dev/ip ip_send_redirects 0
anita:/#
La generación de los números iniciales de secuencia TCP es otro
parámetro que seguramente nos interesará modificar en un sistema
Solaris; por defecto esta generación se basa en incrementos pseudoaleatorios,
lo que puede facilitar ataques de IP Spoofing contra el sistema. Podemos
aumentar nuestro nivel de seguridad utilizando un esquema de generación más
robusto, basado en [Bel96], simplemente modificando el fichero /etc/default/inetinit para asignarle al parámetro TCP/SMALL>_STRONG/SMALL>_ISS
un valor de 2:
anita:/# cat /etc/default/inetinit
# @(#)inetinit.dfl 1.2 97/05/08
#
# TCP_STRONG_ISS sets the TCP initial sequence number generation parameters.
# Set TCP_STRONG_ISS to be:
# 0 = Old-fashioned sequential initial sequence number generation.
# 1 = Improved sequential generation, with random variance in increment.
# 2 = RFC 1948 sequence number generation, unique-per-connection-ID.
#
TCP_STRONG_ISS=2
anita:/#
Al contrario de lo que sucede con ndd, cuyos cambios se pierden al
reiniciar el sistema y hay que planificar en el arranque si necesitamos hacerlos
permanentes, la modificación del fichero anterior no tendrá efecto hasta
que el sistema vuelva a arrancar; si no queremos detener la máquina, podemos
conseguir lo mismo mediante la orden `ndd' sobre el núcleo en
ejecución:
anita:/# ndd -set /dev/tcp tcp_strong_iss 2
anita:/#
También mediante ndd podemos modificar en Solaris las restricciones
relativas a los puertos reservados (aquellos que sólo el root puede
utilizar, por defecto los que están por debajo del 1024). En primer lugar,
podemos definir el mínimo puerto no reservado, para que las conexiones al
sistema o los procesos de usuario puedan utilizar sólo los que están por
encima de él; si por ejemplo queremos que el rango de puertos reservados
comprenda a todos los que están por debajo del 5000 podemos ejecutar la orden
siguiente:
anita:/# ndd -set /dev/tcp tcp_smallest_nonpriv_port 5000
anita:/#
Además, desde su versión 2.6 Solaris permite marcar puertos individuales
como reservados, tanto UDP como TCP, y también eliminar esta
restricción de puertos que previamente hayamos reservado; por defecto, aparte
de los primeros 1024 puertos, Solaris define como reservados - en TCP y
UDP - los puertos 2049 (nfsd) y 4045 (lockd). En el siguiente
ejemplo se muestra cómo consultar los puertos marcados de esta forma, cómo
añadir un alguno a la lista, y cómo eliminarlo de la misma; aunque el
ejemplo se aplica a TCP, el caso de UDP es completamente análogo
pero sustituyendo el nombre del dispositivo contra el que ejecutamos la orden
(que sería /dev/udp) y la cadena `tcp' del nombre de cada
parámetro por `udp':
anita:/# ndd /dev/tcp tcp_extra_priv_ports
2049
4045
anita:/# ndd -set /dev/tcp tcp_extra_priv_ports_add 5000
anita:/# ndd /dev/tcp tcp_extra_priv_ports
2049
4045
5000
anita:/# ndd -set /dev/tcp tcp_extra_priv_ports_del 5000
anita:/# ndd /dev/tcp tcp_extra_priv_ports
2049
4045
anita:/#
Antes de finalizar este punto es importante insistir en que los cambios
producidos
por `ndd' sólo se mantienen hasta el siguiente reinicio del sistema;
de esta forma, las modificaciones que hemos visto aquí se mantendrán
sólo mientras la máquina no se pare, pero si esto sucede en el arranque
todos los parámetros del subsistema de red tomarán sus valores por defecto.
Por tanto, lo más probable es que nos interese planificar en el inicio del
sistema las modificaciones estudiadas en este punto para que se ejecuten de
forma automática; para conseguirlo, no tenemos más que crear el script correspondiente y ubicarlo en el directorio /etc/rc2.d/ con un
nombre que comience por `S', con lo que hacemos que se ejecute siempre que
la máquina entre en un runlevel 2:
anita:~# cat /etc/init.d/nddconf
#!/sbin/sh
#
# Configuracion segura del subsistema de red de Solaris
#
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_strict_dst_multihoming 1
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -get /dev/arp arp_cleanup_interval 60000
ndd -get /dev/ip ip_ire_flush_interval 60000
ndd -get /dev/ip ip_respond_to_echo_broadcast 0
ndd -get /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -get /dev/ip ip_respond_to_address_mask_broadcast 0
ndd -get /dev/ip ip_respond_to_timestamp 0
ndd -get /dev/ip ip_ignore_redirects 1
ndd -get /dev/ip ip_send_redirects 0
ndd -set /dev/tcp tcp_strong_iss 2
#
anita:~# chmod 744 /etc/init.d/nddconf
anita:~# chown root:sys /etc/init.d/nddconf
anita:~# ln /etc/init.d/nddconf /etc/rc2.d/S70nddconf
anita:~#
Si queremos conocer mejor la configuración de seguridad del subsistema de
red de Solaris una excelente obra que no debería faltar en la mesa
de ningún administrador de sistemas es [NW99]; todo este punto está
basado ampliamente en ella. Incluye, además de explicaciones claras sobre
el porqué del valor de cada parámetro para prevenir posibles ataques, un
shellscript para planificar en el inicio del sistema, muchísimo más
completo que el presentado aquí, y aplicable a varias versiones de Solaris
(incluyendo la 8); en sistemas en los que la seguridad es un factor a tener en
cuenta (>todos?) es casi obligatorio utilizar esta planificación.
Siguiente: Parámetros del núcleo
Subir: Solaris
Anterior: sfpDB
Índice General
2003-08-08