Utiliza cortafuegos para que incluso si instalan servicios estos no sean accesibles al resto del mundo.
Observa regularmente la tabla de procesos, puertos abiertos, software instalado, etc. en busca de cambios.
Ten una política de seguridad escrita que los usuarios puedan entender, y fortalécela.
Borra todo tipo de objetos peligrosos (compiladores, etc), a menos que sean necesarios en un sistema.
Restringe el acceso físico a los servidores.
Política del menor privilegio, así pueden estropearse menos cosas.
¡HAZ COPIAS DE SEGURIDAD!
Comprueba con regularidad los servidores en busca de cambios (puertos, software, etc), para esto son estupendas las herramientas automatizadas.
Los cambios de software deberían estar cuidadosamente planeados/probados, pues pueden implicar efectos inversos. Recuerda: seguridad en profundidad.
2.Seguridad Física y de Arranque 2.1.Acceso Físico ¿Quien puede acceder a nuestro sistema y que puede hacerle?. Personal de limpieza, el chico de los recados un usuario malintencionado, etc.
Teniendo esto en cuenta tiene sentido bloquear los servidores en una habitación segura (o incluso en un armario).
También es una buena idea situar a los servidores en una superficie elevada, para evitar daños en el caso de inundaciones (ya sea por un agujero en el techo o lo que sea).
2.2.La Bios La BIOS del ordenador controla la forma en que el ordenador arranca y otro tipo de cosas.
Las BIOS viejas tiene fama de tener claves universales, asegúrate de que tu bios es reciente y que no contiene semejante puerta trasera.
La bios se puede utilizar para bloquear la secuencia de arranque de un equipo, limitándola a C: únicamente, por ejemplo, al primer disco duro, lo cual es una buena idea.
Deberías utilizar la bios para eliminar la disquetera (el servidor típico no va a necesitar utilizarla), y puede evitar que los usuarios copien datos de la máquina a disquetes.
También puedes eliminar los puertos serie en las máquinas de los usuarios, de tal forma que puedan instalar módems.
Lo mismo sirve para el puerto paralelo, permitiendo a los usuarios imprimir obviando la red, o dándoles la oportunidad de instalar una grabadora de CDROM o un disco duro externo, lo cual puede disminuir la seguridad en buena medida.
Esto es un añadido a la política del menor privilegio, y puede disminuir considerablemente los riesgos, al igual que facilitar la administración de la red.
2.3.LILO Una vez que el ordenador ha decidido arrancar de C:, LILO (o cualquier otro gestor de arranque que utilices) despega.
La mayoría de los gestores de arranque permiten algún tipo de flexibilidad en el modo en que se arranca el sistema, especialmente LILO, pero también es una espada de dos filos.
Puedes pasarle argumentos a LILO a la hora de arrancar, siendo el argumento más dañino "imagename single", lo cual arranca Linux en modo de único usuario, y por defecto, la mayoría de las distribuciones te vuelcan a un prompt de root en un shell de comandos sin preguntar contraseñas u otro tipo de mecanismos de seguridad.
Hay varias tecnicas para minimizar este riesgo: delay=x
esto controla la cantidad de tiempo (en décimas de segundo) que LILO espera a que el usuario introduzca datos antes de arrancar la opción por defecto.
Prompt
fuerza al usuario a introducir algo, LILO no arrancará el sistema automáticamente. Si le añades una opción de cuenta atrás, el sistema continuará arrancando después de que haya terminado la cuenta atrás.
Restricted
pide una contraseña si se pasan opciones de tiempo de arranque (tales como "linux single").
3. Sistema de Ficheros 3.1.Ficheros del Sistema /etc/passwd
El fichero de contraseñas es sin discusión el fichero más crítico en Linux. Contiene el mapa de nombres de usuarios, identificaciones de usuarios y la ID del grupo primario al que pertenece esa persona. También puede contener el fichero real, aunque es más probable (y mucho más seguro) que utilice contraseñas con shadow para mantener las contraseñas en /etc/shadow. Este fichero TIENE que ser legible por todo el mundo, o si no comandos tan simples como ls dejarían de funcionar correctamente. El formato es:
nombreusuario:contraseña_cifrada:UID:GID:campo_GECOS:direct_personal:login_shell
Las contraseñas se guardan utilizando un hash de un sólo sentido. Las contraseñas no pueden obtenerse a partir de la forma cifrada, sin embargo, se puede tratar de encontrar una contraseña utilizando fuerza bruta para pasar por el hash cadenas de texto y compararlas, una vez que encuentres una que coincide, sabes que has conseguido la contraseña.
/etc/shadow
El fichero de shadow alberga pares de nombres de usuario y contraseñas, así como información contable, como la fecha de expiración, y otros campos especiales. Este fichero debería protegerse a toda costa, y sólo el root debería tener acceso de lectura a él.
/etc/groups
El fichero de grupos contiene toda la información de pertenencia a grupos, y opcionalmente elementos como la contraseña del grupo (generalmente almacenado en gshadow en los sistemas actuales), este fichero debe ser legible por el mundo para que el sistema funcione correctamente. El formato es:
nombregrupo:contraseña_cifrada:GID:miembro1,miembro2,miembro3
Un grupo puede no contener miembros (p. ej., no está usado), sólo un miembro o múltiples miembros, y la contraseña es opcional (y no se suele usar).
/etc/gshadow
Similar al fichero shadow de contraseñas, este fichero contiene los grupos, contraseñas y miembros. De nuevo, este fichero debería ser protegido a toda costa, y sólo el usuario root debería tener permiso de lectura al mismo.
/etc/login.defs
Este fichero (/etc/login.defs) te permite definir algunos valores por defecto para diferentes programas como useradd y expiración de contraseñas.
/etc/shells
El fichero de shells contiene una lista de shells válidos, si el shell por defecto de un usuario no aparece listado aquí, quizás no pueda hacer login interactivamente.
/etc/securetty
Este fichero contiene una lista de tty’s desde los que el root puede hacer un login. Los tty’s de la consola suelen ir de /dev/tty1 a /dev/tty6. Los puertos serie son /dev/ttyS0 y superiores por lo general. Generalmente, sólo se debería permitir conectar al root desde /dev/tty1, y es aconsejable desabilitar la cuenta de root, sin embargo antes de hacer esto, por favor, instala sudo o un programa que permita al root acceder a comandos.
3.2.Seguridad de Ficheros Una casa sólida necesita cimientos sólidos, si no se derrumbará. En el caso de Linux, esto es el sistema de ficheros ext2 (EXTendido, versión 2). Algo así como el standard UNIX de toda la vida. Soporta permisos de ficheros (lectura, escritura, ejecución, sticky bit, suid, guid, etc.), propiedad de ficheros (usuario, grupo, otros), y otro tipo de standards.
Las utilidades básicas para interactuar con ficheros son: "ls", "chown", "chmod" y "find". Otras incluyen ln (para creación de enlaces), stat (muestra información de un fichero) y muchas más. En cuanto a la creación y mantenimiento de sistemas de ficheros por sí mismos, tenemos "fdisk" (el viejo fdisk), "mkfs" (MaKe FileSystem, que formatea particiones), y "fsck" (FileSystem ChecK, que suele arreglar problemas).
¿Qué es lo que estamos tratando de evitar que haga la gente hostil?. Se puede comprometer con facilidad un sistema Linux si se consigue acceso a ciertos ficheros, por ejemplo la capacidad para leer un fichero de claves sin shadow da como resultado la posibilidad de ejecutar contraseñas cifradas contra crack, encontrando con facilidad las contraseñas débiles. De otra forma, si un atacante puede escribir en el fichero de contraseñas, el o ella puede irrumpir en el sistema, o conseguir cualquier nivel de acceso que quiera. ¿Cómo se pueden prevenir?
Configurando el sistema de ficheros correctamente cuando se instale. Dos directorios habituales a los que los usuarios tienen acceso son /tmp y /home, dividir esto en particiones separadas también evita que los usuarios llenen cualquier sistema de ficheros crítico (un / lleno es algo bastante malo). Un /home lleno podría dar como resultado la incapacidad de que los usuarios pudieran hacer un login (por eso el directorio del root está en /root). Poner /tmp y /home en particiones separadas es algo así como obligatorio si los usuarios tienen acceso al servidor, poner /etc, /var, y /usr en particiones separadas también es una muy buena idea.
Las herramientas principales para conseguir información sobre ficheros y sistemas de ficheros son relativamente simples y fáciles de usar:
"df" (muestra el uso del disco)
"du" (saca un listado de todo lo que hay en el directorio actual y por debajo de él a lo que tengas acceso)
ls (similar al comando "dir" del DOS), "ls" sólo saca nombres de ficheros/directorios, "ls –l" muestra información como los permisos de los ficheros, el tamaño, etc.,
"stat", que símplemente da información de las estadísticas vitales de un fichero(s) dado, y es muy útil para ver si un fichero está en uso, etc.
Para manipular ficheros y carpetas, están las herramientas generales como cp, mv, rm (CoPy, MoVe y ReMove, copiar, mover y eliminar), al igual que herramientas para manipular la información de seguridad.
chown es responsable de cambiar la propiedad del usuario y grupo de un determinado fichero.
chmod (CHange MODe, cambio de modo) cambia los atributos de un fichero, siendo los básicos lectura, escritura y ejecución.
find encuentra ficheros (en esencia, lista ficheros), y también se puede utilizar con filtros basados en permisos/propiedad
Borrado seguro de ficheros
Algo que muchos de nosotros olvidamos es que cuando se borra un fichero, en realidad no se ha ido, hay posibilidades de que pueda ser recuperado. El truco consiste en desordenar los datos, alterando los bits magnéticos (alias los 1’s y 0’s) para que una vez hubiera terminado, no quedasen trazas del original (es decir, bits magnéticos cargados de la misma forma que estaban originariamente). Se han escrito dos programas (ambos llamados wipe) a tal efecto.
wipe ([email protected])
wipe borra datos con seguridad, sobreescribiendo el fichero múltiples veces con varios patrones de bits. Se puede utilizar wipe en ficheros o en dispositivos.
wipe ([email protected])
Este también borra datos de forma segura, sobreescribiéndolos múltiples veces, sin embargo este no soporta el borrado de dispositivos.
4. Autentificación 4.1.PAM "Pluggable Authentication Modules" para Linux, es una suite de librerías compartidas que permiten al administrador local del sistema escoger cómo autentifican a los usuarios las aplicaciones.
¿Qué significa en realidad? Por ejemplo, tomemos "login", cuando un usuario se conecta, un programa responde la llamada e inicia "login", y luego pide el típico nombre de usuario, seguido de la contraseña, lo cual se compara con el fichero /etc/passwd. Todo esto está bien, hasta que tienes una fenomenal tarjeta de autentificación nueva y quieres utilizarla. Bueno, pues tendrás que recompilar login de modo que soporten el sistema nuevo. Como te puedes imaginar, esto lleva bastante trabajo y está sujeto a errores.
PAM introduce una capa de middleware entre la aplicación y el mecanismo real de autentificación. Una vez que el programa está PAMificado, podrá ser utilizado por el programa cualquier método de autentificación que soporte PAM. Además de esto, PAM puede manejar cuentas y datos de sesiones, lo cual no suelen hacer bien los mecanismos habituales de autentificación.
4.2.Seguridad de contraseñas Para que la autentificación de usuario funcione correctamente se necesitan (como mínimo) algún tipo de fichero(s) con UID a mapas de nombres de usuarios, GID a mapas de nombres de grupos, contraseñas para todos los usuarios y demás información variada.
El problema es que todo el mundo necesita acceso al fichero de contraseñas, cada vez que se hace un ls, se verifica el fichero de contraseñas, de modo que ¿cómo se consigue almacenar todas las contraseñas con seguridad y a la vez mantenerlas legibles por el mundo?
Durante muchos años, la solución ha sido bastante simple y efectiva, simplemente, haz un hash de las contraseñas y guarda el hash, cuando un usuario necesite autentificar, toma la contraseña que introduce, pásala por el hash y si coincide, evidentemente se trataba de la misma contraseña. El problema que tiene esto es que la potencia computacional ha crecido enormemente, y ahora se puede coger una copia del fichero de contraseñas e intentar abrirlo mediante fuerza bruta en una cantidad de tiempo razonable.
Para resolver esto hay varias solucione s:
Utiliza un algoritmo de hashing "mejor", como MD5.
Almacena las contraseñas en alguna otra parte.
Linux ha implementado la segunda desde hace tiempo, se llama contraseñas con shadow. En el fichero de contraseñas, se reemplaza la contraseña por una ‘x’, lo cual le indica al sistema que verifique tu contraseña contra el fichero shadow.
Para implementar contraseñas con shadow hay que hacer dos cosas. La primera es relativamente simple, cambiar el fichero de contraseñas, pero la segunda puede ser un calvario. Hay que asegurarse que todos tus programas tienen soporte para contraseñas con shadow, lo cual puede ser bastante penoso en algunos casos.
Debido a la confianza de Red Hat en PAM para la autentificación, para implementar un esquema nuevo de autentificación todo lo que se necesita es añadir un módulo PAM que lo entienda y editar el fichero de configuración para cualquier programa (digamos el login) permitiéndole que use ese módulo para hacer la autentificación.
4.3.Almacenamiento de contraseñas. Esto es algo que la mayoría de la gente no suele tener en cuenta. ¿Cómo se pueden almacenar las contraseñas de forma segura? El método más obvio es memorizarlas, pero suele tener sus inconvenientes, si se administran 30 sitios diferentes, por lo general se tendrán 30 contraseñas diferentes, y una buena contraseña tiene más de 8 caracteres de longitud, y por lo general no es la cosa más fácil de recordar.
Esto conduce a que mucha gente utilice la misma contraseña en diferentes sistemas. Una de las formas más sencillas es escribir las contraseñas. Por lo general, esto suele ser muy malo. Una mejor opción es almacenar las contraseñas en un formato cifrado, generalmente de forma electrónica en tu ordenador o en el palm pilot, de forma sólo hay que recordar una contraseña para desbloquear el resto.
5. Acceso Remoto 5.1.Introduccion No se pueden empezar a segurar servicios hasta que no se sepa qué se está ejecutando. Para este tipo de tareas, ps y netstat no tienen precio; ps dice qué se está ejecutando (httpd, inetd, etc) y netstat te dirá cuál es el estado de los puertos.
Salida de PS
El programa ps nos muestra el estado de procesos. Las opciones más comúnmente utilizadas son "ps -xau", que muestra algo así como toda la información que siempre quisiste saber.
Lo que viene a continuación es una salida típica de una máquina (utilizando "ps -xau").
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 320 0.0 0.6 760 380 ? S Feb 12 0:00 portmap …
Salida de Netstat
netstat informa acerca de casi cualquier cosa que se pueda imaginar relacionada con la red. Es especialmente buena para sacar listados de conexiones y sockets activos. Al usar netstat se puede encontrar qué interfaces están activas en qué puertos.
Lo que viene a continuación es la salida típica de un servidor, con netstat –an.
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 24.108.11.200:80 205.253.183.122:3661 ESTABLISHED
udp 0 0 127.0.0.1:1031 0.0.0.0:*
raw 0 0 0.0.0.0:1 0.0.0.0:*
…
Salida de lsof
lsof es un práctico programa cuya idea es similar a la de ps, excepto en que muestra qué ficheros/etc están abiertos, lo cual puede incluir sockets de red. Desafortunadamente, el lsof medio saca bastante información, de modo que será necesario utilizar grep o redireccionarlo mediante less ("lsof | less") para hacerlo más cómodo de leer.
squid 9726 root 4u inet 78774 TCP localhost:2074->localhost:2073 (ESTABLISHED)
squid 9726 root 5u inet 78777 TCP localhost:2076->localhost:2075 (ESTABLISHED)
squid 9726 root 6u inet 78780 TCP localhost:2078->localhost:2077 (ESTABLISHED)
squid 9726 root 7w CHR 1,3 6205 /dev/null
…
Ficheros básicos de configuración de red
Hay varios ficheros de configuración importantes, que controlan qué servicios ejecuta Linux y cómo lo hacen. Los lugares de localizacion mas habituales son:
Fichero de configuración del servidor Inetd:
/etc/inetd.conf
Ficheros de inicio de varios tipos:
/etc/rc.d/*
/etc/*
Lo mejor que se puede hacer es imaginarse qué servicios se quiere ejecutar, y deshabilitar/borrar el resto.
inetd.conf
inetd.conf es el responsable de iniciar los servicios, generalmente aquellos que no necesitan ejecutarse de continuo, o que están basados en sesiones (como telnet o ftpd).
Ello es debido a que la sobrecarga que supondría ejecutar un servicio constantemente sería mayor que el costo de inicio ocasional cuando el usuario quisiera utilizarlo.
Para algunos servicios (como DNS) que sirven a muchas conexiones rápidas, la sobrecarga de arrancar servicios cada pocos segundos sería mayor que tenerlo constantemente ejecutándose.
Se aconseja desabilitar tantos servicios de inetd.conf como sea posible, por lo general los que se suelen usar son ftp, pop e imap. Se debería reemplazar telnet y los servicios r por el SSH y servicios como systat/netstat y finger proporcionan demasiada información. El acceso a programas arrancados por inetd se puede controlar con facilidad mediante eluso de TCP_WRAPPERS.
TCP_WRAPPERS
Usar TCP_WRAPPERS hace que el asegurar servidores contra intrusiones externas sea bastante más simple y menos doloroso de lo que te imaginas. TCP_WRAPPERS se controla desde dos ficheros:
/etc/hosts.allow
/etc/hosts.deny
Primero se comprueba hosts.allow, y las reglas se comprueban desde la primera a la última. Si encuentra una regla que te permita específicamente entrar te deja conectarte al servicio.
Si no puede encontrar ninguna regla que te corresponda en hosts.allow, entonces va a comprobar hosts.deny en busca de una regla que te deniegue la entrada. De nuevo comprueba las reglas de hosts.deny desde la primera a la última, y la primera regla que encuentre que te deniega acceso.
Si tampoco puede encontrar una regla denegándote la entrada, entonces por defecto te deja entrar. Si eres tan paranoico como yo, la última regla (o la única regla si se va a utilizar una política por defecto no optimista en cuanto a seguridad) debería ser:
ALL: 0.0.0.0/0.0.0.0
lo que significa que todos los servicios, todos los lugares, de modo que cualquier servicio al que no se le permita específicamente acceder, queda bloqueado (recuerda que por defecto es permitir). Quizás también preferirías simplemente denegar el acceso por defecto a, digamos, telnet, y dejar el ftp abierto al mundo. Habría que hacer lo siguiente:
en hosts.allow:
in.telnetd: 10.0.0.0/255.255.255.0 # permitir acceso desde la red interna de 10.0.0.*
in.ftpd: 0.0.0.0/0.0.0.0 # permitir acceso desde cualquier parte del mundo
en hosts.deny:
in.telnetd: 0.0.0.0/0.0.0.0 # denegar acceso a telnetd desde cualquier parte
/etc/services
El fichero de servicios es una lista de números de puertos, el protocolo y el nombre correspondiente. El formato es:
nombre-de-servicio puerto/protocolo alias
# comentario opcional
Por ejemplo, este fichero se utiliza cuando se ejecuta ‘netstat -a’, y por supuesto no se utiliza cuando se ejecuta ‘netstat -an’:
time 37/udp timserver
rlp 39/udp resource # localización de recursos
name 42/udp nameserver
whois 43/tcp nicname # generalmente al sri-nic
domain 53/tcp
domain 53/udp
5.2.Herramientas Telnet
Telnet es con mucho la herramienta remota más vieja y conocida. Telnet es increíblemente inseguro, las contraseñas y los nombres de usuarios, al igual que los datos de las sesiones vuelan en texto simple.
SSL Telnet
SSL Telnet es telnet con el añadido de cifrado SSL, lo cual lo hace bastante más seguro.
SSH
Soporta diferentes tipos de autentificación (contraseña, basada en rhosts, llaves RSA), permite redireccionar puertos, y se puede configurar fácilmente a qué usuarios se les permite usarlo.
LSH
LSH es una implementación gratuita del protocolo SSH.
REXEC
REXEC es una de las utilidades UNIX más antiguas, te permite ejecutar comandos en un sistema remoto, aunque tiene el serio fallo de no tener un modelo de seguridad real. La seguridad se consigue mediante el uso de ficheros ‘rhosts’, que especifican qué hosts/etc. pueden ejecutar comandos, lo cual está sujeto a spoofing y otro tipo de exploits.
Slush
Slush está basado en OpenSSL, está completamente basado en software de código abierto, dejando pocas posibilidades a que pueda tener puertas traseras/etc. En último caso, podría reemplazar al SSH por algo mejor.
NSH
NSH es un producto comercial con todos sus detalles. Tiene soporte para cifrado, de modo que es relativamente seguro de usar.
Fsh
Fsh significa "Ejecución rápida de comandos remotos", y el concepto es similar al de rsh/rcp. Evita el costo de estar creando continuamente sesiones cifradas, habilitando un túnel cifrado utilizando ssh o lsh, y ejecutando todos los comandos sobre él.
secsh
secsh (Shell Seguro) aporta otra capa más de seguridad de login, una vez que has hecho log vía ssh o telnet SSL te pide otra contraseña, si introduces una errónea, secsh mata el intento de login.
5.3.Telnet Telnet permite hacer login interactivo en una máquina remota, lanzar comandos y ver sus resultados. Es uno de los protocolos más inseguros. La mejor solución para asegurar el telnet es deshabilitarlo y utilizar telnet con SSL o el ssh.
Los problemas con telnet incluyen:
Autentificación en texto claro, nombre de usuario y contraseña.
Texto en claro de todos los comandos.
Ataques de adivinación de contraseñas.
La mejor solución es desactivar el telnet y utilizar ssh. Si es necesario utilizar telnet, sugeriría encarecidamente filtrarlo mediante un cortafuegos, tener reglas para permitir a los hosts/redes acceso a puerto 23, y después tener una regla general denegando acceso al puerto 23, al igual que utilizar TCP_WRAPPERS
Un ejemplo de reglas del cortafuegos:
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 23
ipfwadm –I –a accept –P tcp –S un.host.fiable –d 0.0.0.0/0 23
ipchains –A input –p all –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 23
Un ejemplo de lo mismo utilizando TCP_WRAPPERS:
En /etc/hosts.allow
in.telnetd: 10.0.0.0/255.0.0.0, un.host.fiable
Y en /etc/hosts.deny
in.telnetd: ALL
Existen varias alternativas cifradas al telnet, como ya se mencionó más arriba, ssh, SSLeay Telnet y otras utilidades de terceros, a mi personalmente me parece que la "mejor" alternativa si te vas a tomar la molestia de cambiar el telnet por algo mejor es utilizar ssh.
Para asegurar las cuentas de los usuarios con respecto a telnet, se pueden hacer varias cosas:
La primera sería no permitir al root hacer login vía telnet, lo cual se controla mediante el /etc/securetty y por defecto en la mayoría de las distribuciones el root tiene restringido el acceso a la consola.
Para que un usuario haga login con éxito, su shell tiene que ser válido (lo cual viene determinado por la lista de shells de /etc/shells), de modo que configurar cuentas de usuario a las que se les permita hacer login es simplemente cuestión de configurar su shell a alguno de los listados en /etc/shells.
5.4. SSH SSH es un protocolo seguro y un conjunto de herramientas para reemplazar otras más comunes (inseguras). Fue diseñado desde el principio para ofrecer un máximo de seguridad y permitir el acceso remoto a servidores de forma segura. SSH se puede utilizar para asegurar cualquier tráfico basado en red, configurándolo como un pipe.
No existen tantos problemas con el SSH per se como existen con telnet, todo el tráfico de la sesión va cifrado y el intercambio de llaves se hace de forma relativamente segura. SSH se suele ejecutar como un demonio, y se puede cerrar utilizando el fichero sshd_config. También se puede ejecutar sshd desde inetd, y de tal forma utilizar TCP_WRAPPERS.
Las reglas del cortafuegos para ssh son bastante parecidas a telnet. Por supuesto que está TCP_WRAPPERS, el problema con TCP_WRAPPERS es que un atacante se conecta al puerto, pero no consigue un demonio, SIN EMBARGO sabe que hay algo en ese puerto, mientras que mediante el cortafuegos, ni siquiera se consigue conexión con el puerto.
5.5. Cifrado de servicios Prácticamente todo el tráfico de red viaja sin cifrar y puede ser leído con facilidad por un atacante. Si alguien revienta una máquina del lado de Internet e instala un sniffer de contraseñas, la red entera puede verse comprometida en cuestión de horas.
Existen o se están desarrollando varios mecanismos para cifrar el tráfico de red, en diferentes niveles de la pila de red.
Algunos esquemas sólo cifran los datos que se envían (como el correo cifrado con PGP), algunos cifran la sesión (SSL), y algunos cifran la carga de datos de los paquetes (IPSec y otros VPN’s). A la larga, la mejor solución será el IPSec, puesto que no requiere modificar las aplicaciones, y proporciona un nivel de seguridad entre ordenadores bastante elevado.
6. Links Guia de Seguridad del Administrador de Linux puedes encontrarla en español en el Proyecto Lucas http://lucas.linux.org.mx/htmls/manuales.html (gsal-19991128)
Security Portal (El portal de la Seguridad) http://www.securityportal.com/
Hispalinux (Asociación de usuarios Españoles de Linux) http://www.hispalinux.es/
Linux.org http://www.linux.org/
Linux.com http://www.linux.com/
| Página siguiente |