|
Linux es un miembro de la familia UNIX pero es diferente de la mayoría de implementaciones UNIX porque proporciona un gran entorno servidor/estación de trabajo UNIX a un bajo precio, puede ejecutarse en una amplia variedad de plataformas, y no contiene código propietario. En este artículo, daremos una breve introducción a los servicios de red IP, como configurarlos, y como crear una estación de trabajo Linux relativamente segura. Fíjese por favor, en que los ejemplos dados aquí son de la distribución Slackware. La situación de los archivos puede ser diferente en otras distribuciones de Linux.
#!/bin/sh
#
# rc.inet2 This shell script boots up the entire INET system.
# Constants.
NET="/usr/sbin"
IN_SERV="lpd"
LPSPOOL="/var/spool/lpd"
echo -n "Starting daemons:"
# Start the SYSLOGD/Klogd daemons. These must come first.
if [ -f ${NET}/syslogd ]; then
echo -n " syslogd"
${NET}/syslogd & # Backgrounded to avoid an ugly notice from bash-2.0
echo -n " klogd"
${NET}/klogd
fi
...
# Start the INET SuperServer
if [ -f ${NET}/inetd ]; then
echo -n " inetd"
${NET}/inetd
else
echo "no INETD found. INET cancelled!"
exit 1
fi
....
No obstante, la mayoría de servicios se ejecutan a través
del inetd. inetd es un proceso background demonio que se inicia cerca del principio
de la secuencia de boot del Linux. inetd escucha muchos puertos,
y cuando una conexión a un puerto es requerida, inicia el
proceso asociado con ese puerto.
Ejemplos de los servicios que se ejecutan desde inetd son ftp, telnet, finger, pop, imap, y mail/smtp. inetd es como una centralita que recibe las llamadas al número principal de la organización (la dirección IP de la máquina), y conecta el que llama a la extensión que ha pedido( el puerto o el socket).
Hay dos archivos que configuran inetd: /etc/services y /etc/inetd.conf (que puede estar en /etc/inet/inetd.conf). A continuación hay un ejemplo de /etc/inetd.conf
# See "man 8 inetd" for more information. # # <service_name <sock_type<server_path # # The last 3 services ( pop3, imap, uucp) are really only used for # debugging purposes, so we comment them out since they can # otherwise be used for some nasty denial-of-service attacks. # If you need them, uncomment them. # # ftp and telnet are the standard services. # ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # installed the Pine package, you may wish to switch to ipop3d by # commenting out the pop3 line above, and uncommenting the pop3 line below. #pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d # imap2 stream tcp nowait root /usr/sbin/tcpd imapd # # The Internet UUCP service. # # uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l ....
# Start the ROUTEd server.
# if [ -f ${NET}/routed ]; then
# echo -n " routed"
# ${NET}/routed -g -s
# fi
Para configurar los servicios inetd , edite /etc/services and /etc/inetd.conf.El archivo/etc/services asocia los servicios con sus puertos. Lista el nombre del servicio, el número de puerto para el servicio, y el protocolo (upd o tcp). Aquí se muestra la línea para el servicio ftp:
ftp 21/tcp
/etc/inetd.conf contiene parámetros que determinan como se ejecutan los servicios. Aquí se muestra un ejemplo de la línea para el servidor ftp:
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -aPara deshabilitar el programa ftp , coméntelo poniendo una # al principio de cada línea. Para activar el cambio, reinicie inetd. Esto puede hacerse encontrado el identificador del proceso (PID - process-id) de inetd, y luego enviándole la señal de colgar conocida como SIGHUP o simplemente HUP.
{find out the PID}
$ ps -aux | grep inetd
root 479 0.0 0.2 1944 1520 ? S Mar 02 1:18 /usr/sbin/inetd
{ ^ this is the PID}
$ kill -HUP 479
El archivo/etc/services prácticamente solo tendrá que ser editado
cuando se añadan nuevos servicios. Esto puede ser necesario cuando
se instalen utilidades de red.Dese cuenta que usamos tcpd para controlar el acceso al demonio ftp . El programa tcpd es un programa adaptador que puede configurarse para monitorizar las peticiones de telnet, finger, ftp y otros servicios de Internet. Funciona de la siguiente forma: cuando llega una petición de servicio, el demonio inetd ejecuta el tcpd, el cual registra la petición y hace algunas comprobaciones. Cuando todo esta bien, el tcpd ejecuta el programa servidor apropiado y acaba. Para detalles, ver las páginas del manual del tcpd. El control de accesos para el tcpd se configura usando los archivos /etc/hosts.allow y /etc/hosts.deny. El tcpd mira en hosts.allow y luego en hosts.deny. Se para en la primera coincidencia. Por tanto, uno puede permitir a algunas máquinas tener acceso ftp o telnet y denegar el acceso a todo el mundo en hosts.deny. A continuación se muestra un ejemplo de /etc/hosts.allow:
ALL: 10.100.10.0/255.255.255.0
El ALL se refiere a todos los adaptadores de servicios inetd. Esto no incluye a los servicios autónomos. El segundo campo 10.100.10.0/255.255.255.0 significa que todas las máquinas en la subred tienen acceso a todos los servicios. Ahora queremos deshabilitar el acceso a todos los demás. Ponga la siguiente línea en /etc/hosts.deny:
ALL: ALL
La no existencia de los archivos /etc/hosts.* o su existencia vacía, significa que no hay restricciones. Esta es una configuración insegura a no ser que la conexiones legítimas puedan venir de varias redes diversas.
La seguridad física es la primera capa de la seguridad. Los usuarios domésticos probablemente no tienen que preocuparse por esto. No obstante, en un entorno publico, este aspecto de la seguridad es mucho mas preocupante. Recuerde que rebotar el sistema es solo apretar ctl-alt-del si el usuario tiene acceso a la consola. Si el usuario puede rebotar el sistema, es trivial manipular los datos del sistema. Siempre que sea posible limite el acceso a la consola.
La seguridad del sistema es un tópico por si mismo. Trata temas como la restricción de las cuentas de usuario o los privilegios mínimos necesarios. Por ejemplo, ¿los usuarios necesitan realmente un entorno de shell completo o es suficiente con un sistema de menús restringido? La seguridad del sistema también involucra la elección de passwords seguros, difíciles de adivinar; la lectura de los boletines de CERT y la aplicación de los parches cuando sea necesario; y no permitir al root conectarse en cualquier terminal excepto la consola. Esto significa que el archivo /etc/securetty solo tendría que tener una línea:
console
Los administradores de sistemas primero tienen conectarse como ellos mismos, y después ejecutar su. Para un mejor control, este programa registra los nombres de los usuarios que se convierten en root.
La seguridad de la red es la parte más vulnerable del sistema. Las siguientes recomendaciones mejorarán significativamente la seguridad de la red:
Desbordamiento de buffers
En algunos programas, la comprobación de los limites no se hace
debido a la reserva previa de los buffers. Cuando estos buffers se desbordan,
el programa en ejecución (demonio o de usuario) puede manipularse
para que haga varias funciones y operaciones anormales. Generalmente esto
se hace sobrescribiendo la dirección de retorno de una función
en la pila para apuntar a otra dirección, luego se ejecuta una shell
de root o un código que pueda cambiar la protección del programa
para que este pueda adquirir privilegios de root.
99-03: FTP-Desbordamiento de buffers
Proporcionando comandos cuidadosamente diseñados al servidor
ftp, los intrusos pueden forzar al servidor a ejecutar comandos arbitrarios
con un privilegio de root. Cualquier servidor ejecutando al última versión de ProFTPD (1.2.0pre1) o la última de Wuarchive
ftpd (2.4.2-academ[BETA-18]) es vulnerable.
98-12: Desbordamiento de Buffer en algunas implementaciones de servidores
IMAP
El desbordamiento está en el código de la librería de
lal servidor IMAP de la Universidad de Washington que controla la autentificación
SASL a nivel de servidor. Los intrusos remotos pueden ejecutar comandos
arbitrarios bajo los privilegios del proceso ejecutando el servidor IMAP vulnerable. Si el servidor IMAP vulnerable se está ejecutando como
root, los intrusos remotos pueden conseguir acceso a nivel de root.
Vulnerabilidad del desbordamiento de buffer explotable remotamente
En algunos sistemas, el servidor vulnerable NFS esta activado por defecto.
Esta vulnerabilidad puede ser explotado incluso si el servidor NFS no comparte
ningún archivo de sistema. Todas las versiones de Red Hat Linux
no actualizadas, son vulnerables.
La herramienta de escaneado "sscan"
La herramienta sscan realiza pruebas contra los hosts víctimas
para identificar servicios que pueden ser potencialmente vulnerables a
la explotación. A pesar de que sscan por si mismo no intenta aprovechar
estas vulnerabilidades, puede ser configurado para automáticamente ejecutar
scripts maliciosos que si lo hagan. Vigile sus logs para descubrir el escaneado
de puertos.
Ataques de denegación de servicio
Hay un gran incremento en el número y la variedad de los ataques
de denegación de servicios en los últimos años.
Uno bien conocido es el ataque smurf. Básicamente, una gran cantidad
de echos ICMP (ping) es enviado a uno o varios hosts, todos
ellos con una dirección de origen falsa de una víctima. En
una red multi-acceso, puede haber cientos de máquinas replicando
cada paquete. En el escenario más común, los usuarios con
acceso Internet a través de enlace lento lo tendrán difícil para
conseguir acceso frente a poderosas máquinas localizadas en
enlaces muy rápido, instalar las diferentes utilidades usadas para
atacar a otros servidores, y luego lanzar el ataque desde este host.
Para más información sobre este ataque, ver
http://users.quadrunner.com/chuegen/smurf.txt.
Hay muchos sites web y listas de correo acerca de la seguridad en UNIX en general y en Linux en particular. Es importante mantenerse al corriente de las incidencias de seguridad que pasan en Internet; esto puede incluir familiarizarse con las últimas herramientas. Aquí hay algunos enlaces útiles:
Guía de configuración de UNIX
ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
Herramientas de seguridad
ftp://info.cert.org/pub/tech_tips/security_tools
Bugtraq
http://www.mit.edu:8008/menelaus/bt/
Wei-Mei Shyr trabajaba como administrador de sistemas para el Unix Support Group en el departamento de Information Technology Services, en la Universidad de Western Ontario.
Brian Borowski es un administrador de red que
soporta un amplio abanico de equipamiento para el trabajo en red en la
Universidad de Western Ontario.