El subsistema de red

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.