Introducción a la seguridad en Sistemas Operativos Unix

Introducción

Por otra parte además Unix suele ser un sistema abierto en el que podriamos sufrir intrusiones no deseadas desde el exterior. También hay que tener en cuenta que una red es básicamente insegura y todos los datos que viajan por ella son susceptibles de ser interceptados por personas ajenas, datos correo, transacciones podrían ser interceptadas por otros. 

El hecho de estar en una red que cada día crece hace que el número de posibles atacantes crezca constantemente, las tecnicas de intrusión son también cada vez más sofisticadas o simplemente aparecen nuevos metodos de de ataque que hace que un administrador tenga que mantener su sistema y sus metodos de comunicación lo más protegido posible, ya sea con actualizaciones, parches u otras tecnicas defensivas. 

¿Que es seguridad?

Nos centramos en tres aspectos:

• La confidencialidad nos dice que los objetos de un sistema has de ser accedidos solo por elementos autorizados para ello. 
• La integridad que los objetos solo pueden ser modificados por autorizados. 
• La disponibilidad que dichos elementos deben poder ser accesibles por los autorizados, contrario a negacion de servicio.

• Interrupcion de nuestro sistema, si este se piede que da inutil o no disponible. 
• Interceptacion, es si un elemento no autorizado, consigue un acceso a un determinado objeto del sistema.
• Modificacion, si ademas de conseguir el acceso se consigue modificar el objeto.
• Destruccion, es la modificacion de un objeto que queda inutilizado.
• Fabricacion, si se trata de una modificacion destinada a conseguir un objeto similar al atacado de forma que sea dificil distinguir entre el original y el fabricado.

¿De que nos protegemos?

• Personas como son el mismo usuario, o curiosos o crackers o piratas.
•  Amenazas logicas, como software incorrecto, puertas traseras, bombas logicas, canales cubiertos o ocultos, gusanos, caballos de Troya, conejos o bacterias, virus, applets hostiles.
• Catastrofes naturales o artificiales. 

¿Como protegernos?

• Prevencion, utilizando mecanismos de seguridad como son autenticacion e identificacion (que veremos luego), control de acceso, separacion por niveles a proteger y seguridad en las comunicaciones.
• Deteccion, como pueden ser programas de auditoria.
• Recuperacion, como puede ser por medio de copias de seguridad.

Ajustes básico de seguridad

• Un usuario no debe ejecutar programas suid si no esasolutamente necesario. Para evitarlo en la medida de lo posible podemos establecer en las particiones correpondientes los parametros nosuid a la hora de montarlos También es buena idea añadir nodev y noexec. 
• Establecer na mascar de creación de ficheros lo más restrictiva posible. Esto se hace e n el profile del sistema con el comando umask. 
• Establecer limites de recursos de sistema a los usuarios con las herramientas que sea necesario, PAM, para reestringir número de procesos uso de memoria, tamaño de cores... Para el control de estos parametros existen multitud de herramientas. 
• Control de los logs del sistema, sobretodo en lo que a usuarios se refiere: /var/log/wtmp y /var/run/utmp donde aparecen los registro de conexion y actividad de los usuarios. 
• Establecer atributos especiales a determinados archivos como /etc/passwd y /etc/shadow. Debemos prevenir su modificación o creación de enlaces.... para ello usaremos los sticky bits y comandos del tipo chattr. 
• Control de los porgramas SUID y SGID ya que son las dianas de muchos ataques. Se debe controlar cuales son, que hacer y controlar su posible modificación connpro ejemplo una función de hash o aplicaciones como tripwire. Sería util: 

 

for fich in `find / -type f \( -perm -04000 -o -perm -02000 \)` do  if ! grep $fich /var/suid  then  echo "$fich es un nuevo fichero con SUID"  fi  done  echo "Actualiza la base de datos si es necesario"

• Control de los ficheros con permiso de escritura global ya que estos son un almacen sin limite para crackers. 
• Existencia de posibles ficheros que no son propiedad de nungún usuario y no pertenecen a ningún grupo. Puede ser la firma de una posible intrusión. 
• Control de los ficheros rhost ya que elos permiten el acceso de redes remotas a nuestra red. 

Seguridad fisica

El nivel de seguridad física que necesita en su sistema depende de su situación concreta. Un usuario doméstico no necesita preocuparse demasiado por la protección física, salvo proteger su máquina de un niño o algo así. En una oficina puede ser diferente. 

Linux proporciona los niveles exigibles de seguridad física para un sistema operativo: 

• Un arranque seguro.
• Posibilidad de bloquear las terminales.
• Las capacidades de un sistema multiusuario real.

Seguridad en el arranque

LILO (Linux Loader) es el encargado de cargar el sistema operativo en memoria y pasarle información para su inicio. A su vez, se le puede pasar parámetros a LILO para modificar su comportamiento. 

Por ejemplo, si alguien en el indicador de LILO añade init single, el sistema se inicia en modo monousuario y proporciona una shell de root sin contraseña. Si en su entorno de trabajo cree necesario evitar que alguien pueda iniciar el sistema de esta forma, debería utilizar el parámetro restricted en el fichero de configuración de LILO (habitualmente /etc/lilo.conf). Este parámetro le permite iniciar normalmente el sistema, salvo en el caso de que se hayan incluido argumentos en la llamada a LILO, que solicita una clave. Esto proporciona un nivel de seguridad razonable: permite iniciar el sistema, pero no manipular el arranque. Si tiene mayores necesidades de seguridad puede incluir la opción password . De esta forma necesitará una clave para iniciar el sistema. En estas condiciones, sólo podrá iniciar el sistema quien conozca la clave. 

Bloqueo de la consola

Si te aleja de su máquina de vez en cuando, estaría bien poder bloquear su consola para que nadie pueda manipularla o mirar su trabajo. Dos programas que hacen esto son xlock y vlock . 

xlock bloquea la pantalla cuando nos encontramos en modo gráfico. Está incluido en la mayoría de las distribuciones Linux que soportan X. En general puede ejecutar xlock desde cualquier xterm de su consola y bloqueará la pantalla de forma que necesitará su clave para desbloquearla.

vlock es un simple programa que le permite cerrar alguna o todas las consolas virtuales de su máquina Linux. Puede bloquear sólo aquélla en la que está trabajando o todas. Si sólo cierra una, las otras se pueden abrir y utilizar la consola, pero no se podrá usar su vty hasta que no la desbloquee. 

El Sistema de archivos de Unix

Sistemas de ficheros

Desde el punto de vista del usuario, el aspecto mas importante de un sistema de archivos es la estructura que refleja el sistema de archivos, que constituye un archivo, como los archivos se nombran y se protegen, que operaciones estan permitidas sobre los archivos,etc.

Las reglas exactas para nombrar archivos son nombre de hasta 255 caracteres, diferenciando mayusculas y minusculas, es "case-sensitive".

Unix utiliza el concepto de particion raiz y monta los sistemas de archivos sobre esta particion. Esto significa que todas as unidades utilizan una estructura comun. Asi no existiran varias unidades y una estructura de directorios por unidad, sino que existira una unica estructura de directorios y sobre ella se acomodaran las distintas unidades, inclusive las que se comparten en redes.

Las rutas (PATH) se utilizan para referirse a determinados directorios o archivos dentro del sistema de archivos. Por ejemplo: /usr/src/linux que seria una ruta absoluta, una ruta relativa dependera del directorio donde nos encontramos, si estamos en el directorio /usr/src no podemos referir a linux como ./linux.

Nos podemos encontrar hard links o soft links. Los "hard links" (links "duros") son links directos al inodo del archivo y nos permiten tener mas de un archivo apuntando al mismo inodo. Son hard links el "." y el "..". Un link simbolico tiene su propio numero de inodo pero apunta a otro archivo, incluso a un archivo que no exista. 

Permisos en Unix

Es conveniente tener claros los permisos que se pueden asignar a un fichero o directorio. Puede que algunas aplicaciones no funcionen bien si algún fichero no tiene el permiso o el propietario correctos, bien por falta de permisos o bien por exceso. Algunas aplicaciones son un poco quisquillosas en este aspecto. Por ejemplo, fetchmail es un programa que podemos usar para recoger el correo de un servidor pop. Este programa se configura en el fichero .fetchmailrc, donde tendremos que indicar la clave que usamos en el servidor; pues bien, si este fichero tiene permiso de lectura para otro usuario que no sea el propietario, fetchmail no funcionará. 

Otras aplicaciones, como por ejemplo inn (un servidor de noticias de Internet) tampoco funcionará si el propietario de sus ficheros es otro usuario distinto a news. Todo esto está perfectamente documentado en cada uno de los programas, por lo que es conveniente leer la documentación que aporta y las páginas del manual. 

Permisos de ficheros y directorios

En general, cualquier sistema UNIX divide el control de acceso a ficheros y directorios en tres elementos: propietario, grupo y otros. Tanto el propietario como el grupo són únicos para cada fichero o directorio. Eso sí, a un grupo pueden pertenecer múltiples usuarios. Otros hace referencia a los usuarios que ni son el propietario ni pertenecen al grupo. Todas estas características se almacenan en el sistema de ficheros, en particular en un i-nodo, que es un elemento que describe las características de un fichero en disco (salvo su nombre), si deseamos saber el numero 'i-node' de un archivo en concreto podemos emplear el comando 'ls -i archivo'. 

Una rápida explicación de los permisos Unix:

Permisos: Bits individuales que definen el acceso a un fichero o directorio. Los permisos para directorio tienen un sentido diferente a los permisos para ficheros.

• Lectura (r): 

Fichero: Poder acceder a los contenidos de un fichero 
Directorio: Poder leer un directorio, ver qué ficheros contiene 
 
• Escritura (w): 

Fichero: Poder modificar o añadir contenido a un fichero 
Directorio: Poder borrar o mover ficheros en un directorio
 
• Ejecución(x): 

Fichero: Poder ejecutar un programa binario o guion de shell 
Directorio: Poder entrar en un directorio 

• usuario (u): El propietario del fichero. 
• grupo (g): El grupo al que pertenece el fichero.
• otros (o): El resto de los usuarios del sistema. 

 

Para establecer nuestros permisos en el sistema UNIX:

Forma abosluta:

Claramente observamos que numero octal corresponde a cada caracteristica de un archivo o directorio en un sistema UNIX. Pasemos pues a poner en uso todo lo aprendido hasta ahora. Como dijimos antes el comando utilizado por los S.O UNIX para establecer permisos recibe el nombre de chmod. A la hora de dar permisos en forma absoluta hemos de seguir la siguiente Sintaxis: 'chmod XYZ archivo'. X representa al due¤o del archivo, Y al grupo y Z al resto de usuarios, mientras que 'archivo' es el nombre del archivo a especificar los permisos. Siempre que queramos atribuir mas de un permiso los numeros octales se sumaran. Observar los siguientes ejemplos para un mayor entendimiento: 
 

Forma relativa:

Observa los siguientes cuadros: 
 

Siempre que queramos atribuir permisos a un archivo/directorio en forma relativa seguiremos por orden los 3 cuadros expuestos anteriormente. Por lo tanto primero se indicara a la persona o personas que queremos atribuir dichos permisos, seguiremos estableciendo la agregacion o eliminacion de ciertos permisos y finalmente indicaremos estos mismos permisos. Fijate en el siguiente ejemplo: 

Si te has fijado en las Figuras anteriores, no te deberia costar demasiado entender los permisos que atribuye la orden anterior. Primeramente como hemos dicho, indicamos al usuario/usuarios, en este caso esta la letra 'a' que significa que estableceremos permisos al due¤o, grupo y demas usuarios. El siguiente simbolo que le sigue, indicara si queremos agregar o eliminar permisos del archivo en cuestion, en este caso el simbolo '+' indica que queremos agregar permisos al fichero. Finalmente indicaremos los permisos a agregar. En este caso indicamos 'r' (lectura) para todos los usuarios 'a'. Espero que haya quedado claro lo anterior, mediante este ejemplo. Sin embargo quiza el simbolo '=' no lo acabemos de entender. Bien simplemente a diferencia de los caracters '+' y '-', el simbolo '=' lo que hace es agregar permisos al usuario/usuarios en cuestion, pero eliminando antes los que tenia establecidos. Ejemplo: 

Y simplemente lo que haria seria quitar los permisos establecidos en el grupo (si hay alguno), y daria permisos de lectura 'r' y escritura 'w' al grupo del creador de dicho archivo. 

Si por el contrario queremos establecer varios permisos a las diferentes categorias que comprenden los sistemas UNIX podemos utilizar las comas. Ejemplo: 

Que simplemente esta sentencia eliminaria ambos permisos, de escritura y lectura tanto para el grupo, como para el resto de usuarios o general. Durante gran parte de este texto, nos hemos referido tanto a directorios como a archivos de forma indistintiva. Pero como bien sabemos, un directorio con caracteristicas de ejecucion, no quiere decir que se pueda ejecutar, entre otras cosas, porque los directorios no se crearon con ese fin. A continuacion se muestra un cuadro con las multiples cualidades que puede tener un directorio, y que podemos hacer con funcion de estas. 
 

Como habreis podido deducir, las opciones anteriores se pueden convinar si deseamos dar multiples cualidades a un directorio. A continuacion podras ver unas aclaraciones tanto de archivos como de directorios que no habiamos comentado literalmente hasta ahora.

• Las unicas personas que pueden cambiar el permiso de los archivos o directorios ubicado en una maquina UNIX son: el propietario del archivo o directorio, el root o superusuario del sistema, y el due¤o del directorio en el cual contiene dicho fichero o directorio. 
• Siempre que un usuario tenga propiedad de lectura (como minimo) sobre cualquier archivo, y este no sea el propietario, si copia dicho fichero, la duplicacion de este archivo pasara a ser propiedad de el. 
• Cuando hablamos sobre permisos de escritura de archivos, nos referimos a la posiblidad que tenemos de insertar o eliminar texto dentro de ese fichero, mientras que cuando nos referimos a estos ultimos permisos para directorios, tenemos la posiblidad de crear nuevos archivos o directorios ubicados dentro del directorio en el cual tenemos estos permisos. 
• A la hora de eliminar un archivo o un directorio, no importa los permisos que tengan, ni quien sea su propietario, mientras tengamos permisos de escritura sobre el directorio que se encuentra dicho fichero o directorio podremos borrarlo.

• Otros bits: 

• Sticky bit: 


El sticky bit tiene su significado propio cuando se aplica a directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios. 

drwxrwxrwt 24 root root 8192 Jun 24 14:40 tmp

• Attributo SUID: (Para Ficheros) 


Este bit describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso (no el usuario que lo lanza). Por ejemplo /usr/bin/passwd es un ejecutable propiedad de root y con el bit SUID activo. ¿Por qué? Este programa lo puede usar cualquier usuario para modificar su clave de acceso, que se almacena en 

-rw-r--r-- 1 root root 1265 Jun 22 17:35 /etc/passwd 

pero según los permisos que observamos en este fichero, sólo root puede escribir y modificar en él. Entonces sería imposible que un usuario pudiera cambiar su clave si no puede modificar este fichero. La solución para este problema consiste en activar el bit SUID para este fichero: 

-r-s--x--x 1 root root 10704 Apr 14 23:21 /usr/bin/passwd 

de forma que cuando se ejecute, el proceso generado por él es un proceso propiedad de root con todos los privilegios que ello acarrea. ¿Piensa que esto puede ser un riesgo para la seguridad? Efectivamente lo podría ser si no mantenemos un mínimo de atención, ya que en este tipo de programas se pueden producir desbordamientos de búfer que comprometan su sistema. Recuerde siempre lo siguiente: 

No asignar el bit SUID salvo cuando sea estrictamente necesario. 
Comprobar que cualquier programa con est bit activo no tiene ningún desbordamiento de buffer (conocido).
No asignarlo jamás si el programa permite salir a la shell. 
 

• Atributo SGID: (Para ficheros) 


Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto. 
 

• Atributo SGID: (Para directorios) 


Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio. A continuación se describen los significados de los permisos de acceso individuales para un fichero. Normalmente un fichero tendrá una combinación de los siguientes permisos:
 

-r-------- Permite acceso de lectura al propietario --w------- Permite modificar o borrar el fichero al propietario ---x------ Permite ejecutar este programa al propietario, (los guiones de shell también requieren permisos de lectura al propietario) ---s------ Se ejecutará con usuario efectivo ID = propietario -------s-- Se ejecutará con usuario efectivo ID = grupo -rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap) ---t------ No tiene efecto. (antes sticky bit)

A continuación se describen los significados de los permisos de acceso individuales para un directorio. Normalmente un directorio tendrá una combinación de los siguientes permisos: 
 

dr-------- Permite listar el contenido pero no se pueden leer los atributos. d--x------ Permite entrar en el directorio y usar en las rutas de ejecución completas. dr-x------ Permite leer los atributos del fichero por el propietario. d-wx------ Permite crear/borra ficheros. d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp d---s--s-- No tiene efecto

Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca deje un fichero del sistema con permiso de escritura para un grupo o para otros. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deberían tener permiso de lectura por root, y los directorios de /etc no deberían ser accesibles, al menos por otros . 
 

• SUID Shell Scripts 


Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razón el núcleo no los acepta. Sin importar lo seguro que piense que es su script de shell, puede ser utilizado para que un cracker pueda obtener acceso a una shell de root. 
 
 

• Listas de control de acceso: ACLs


Las listas de control de acceso proveen de un nivel adicional de seguridad a los ficheros extendiendo el clasico esquema de permisos de Unix. Las ACLs van a permitir asignar permisos a usuarios o grupos concretos, se pueden otorgar ciertos permisos a dos usuarios sobre unos ficheros sin necesidad de incluirlos en el mismo grupo.

Se hace con el comando getfacl. Lo interesante de cara a la proteccion de ficheros es extender los permisos clasicos del archivo, modificando su lista asociada. Esto se hace con setfacl.

Ficheros del sistema

 
• /etc/passwd


El fichero de contraseñas es sin discusión el fichero más crítico en Unix (y en la mayoría de otros Unix). 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 campo GECOS puede contener datos tales como el nombre real, el número de teléfono y otro tipo de cosas parecidas en cuanto al usuario, su directorio personal, que es el directorio en que se coloca al usuario por defecto si hace un login interactivo, y el shell de login tiene que ser un shell interactivo (como bash, o un programa de menús), y estar listado en /etc/shells para que el usuario pueda hacer login. 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 (el hash utilizado por defecto es crypt, las distribuciones más nuevas soportan MD5, que es significativamente más robusto). 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. Esto no suele ser un problema por sí mismo, el problema surge cuando los usuarios escogen claves que son fácilmente adivinables. Las encuestas más recientes han demostrado que el 25% de las contraseñas se pueden romper en menos de una hora, y lo que es peor es que el 4% de los usuarios utilizan su propio nombre como contraseña. Los campos en blanco en el campo de la contraseña se quedan vacíos, así que se vería "::", lo cual es algo crítico para los cuatro primeros campos (nombre, contraseña, uid y gid).
 

• /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. Tiende a variar ligeramente entre distribuciones e incluso entre versiones, pero suele estar bien comentado y tiende a contener los valores por defecto.
 

• /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. Mira la sección sobre Telnetd para más información.
 

• /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 (pongamos que quieres hacer login como root desde módem) son /dev/ttyS0 y superiores por lo general. Si quieres permitirle al root hacer login vía red (una muy mala idea, utiliza sudo) entonces añade /dev/ttyp1 y superiores (si hay 30 usuarios conectados y el root intenta conectar, el root aparecerá como procedente de /dev/ttyp31). 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.
 

Introducción a la seguridad en red

Si además comprendemos los mecanismos que se siguen en las conexiones en red, y mantenemos actualizados nuestros programas, podemos tener un nivel de seguridad y una funcionalidad aceptables. Tampoco tienen las mismas necesidades de seguridad un equipo doméstico, con conexiones esporádicas a Internet, que un servidor conectado permanentemente y que actúe como pasarela entre una intranet e Internet. 

Para describir las pautas de actuación seguras iremos examinando cómo actúan las conexiones y cómo podemos protegerlas. 

• inetd 


Para atender las solicitudes de conexión que llegan a nuestro equipo existe un demonio llamado inetd que está a la escucha de todos los intentos de conexión que se realicen a su máquina. Cuando le llega una solicitud de conexión irá dirigida a un puerto (número de servicio, quizás sea más claro que puerto), por ejemplo, el 80 sería una solicitud al servidor de páginas web, 23 para telnet, 25 para smtp, etc. Los servicios de red que presta su máquina están descritos en /etc/inetd.conf (y en /etc/services los números de puertos). Por ejemplo, en /etc/inetd.conf podemos encontrar las siguientes líneas: 
 

(...)  pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d # imap stream tcp nowait root /usr/sbin/tcpd imapd  (...)

Esto quiere decir que, cuando llegue una solicitud de conexión al puerto 110 (pop3) se ejecutará el programa /usr/sbin/tcpd ipop3d . Sin embargo, el servicio imap está deshabilitado (está comentado con un # delante), por lo que el sistema no le responde. 
 

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 (como telnet) sería mayor que el costo de inicio ocasional (o que arrancar in.telnetd) 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. De igual forma ocurre con servicios como DNS y el correo, donde el tiempo es crítico, sin embargo unos pocos segundos de retraso en empezar una sesión de ftp no le hacen daño a nadie. La página del manual de inetd.conf cubre los básicos ("man inetd.conf"). El servicio en sí se llama inetd y se ejecuta al arrancar, de modo que se le puede parar/arrancar/recargar manipulando el proceso inetd. Cada vez que se hagan cambios a inetd.con, hay que reiniciar inetd para hacer efectivos los cambios, killall -1 inetd lo reiniciará correctamente. Como de costumbre, las lineas del inetd.conf se pueden comentar con un # (lo cual es una forma muy simple y efectiva de deshabilitar servicios como rexec). 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 el uso de TCP_WRAPPERS. 
 

• TCP Wrapper 


El siguiente paso es /usr/sbin/tcpd, que es el tcp_wrapper: un servicio que verifica el origen de las conexiones con su base de datos /etc/hosts.allow (equipos autorizados) y /etc/hosts.deny (equipos a los que se les deniega la conexión). tcpd anota todos los intentos de conexión que le llegan en /var/log/secure para que tenga la posibilidad de saber quién intenta conectarse a su máquina y si lo consigue. Si tcpd autoriza la conexión, ejecuta ipop3d que es el programa que realmente atiende la conexión, ante el cual se tiene que validar el usuario mediante una clave. Observe que ya llevamos tres niveles de seguridad: prestar un servicio, autorizar un conexión y validar un usuario. 

Un consejo que es conveniente seguir: No tenga abiertos los servicios que no necesita; esto supone asumir un riesgo a cambio de nada. Tampoco limite la funcionalidad del sistema, si tiene que usar un servicio, hágalo sabiendo lo que hace. 

También hay que asegurarse de que el programa ipop3d no tenga ninguna vulnerablidad, es decir, que esté actualizado. Existen numerosos medios para estar al día de las vulnerabilidades que aparecen. Una buena lista de correo o una revista electrónica tal vez sean la forma más rápida de conocer los incidentes, las causas y las soluciones. Posiblemente la mejor lista de correo para el mundo Unix sea Bugtraq (busque en forums). 

Pero esto no es todo, además puede filtrar las conexiones que le lleguen desde el exterior para que ni siquiera alcancen a los tcp_wrappers . Por ejemplo, en el caso de conexiones a Internet por módem:

ipchains -A input -j DENY -s 0/0 -d $4/32  23 -p tcp -i ppp0 -l

poniendo la anterior línea en el fichero /etc/ppp/ip-up (y ipchains -F input en ip-down) estaríamos añadiendo (-A) un filtro de entrada (input), que deniega ( -j DENY) desde cualquier sitio de internet (-s 0/0) dirigidas a nuestro equipo (-d $4/32) al puerto telnet (23) por tcp (-p tcp) que lleguen desde internet (en este caso -i ppp0 ) y que además las anote en el registro de incidencias (-l ) ($4 es la dirección IP que obtenemos dinámicamente). 

El mecanismo de filtrado de conexiones se realiza en el núcleo del sistema operativo y si ha sido compilado con estas opciones. Normalmente lo está. Este filtrado se realiza a nivel de red y transporte: cuando llega un paquete por un interfaz de red se analiza siguiendo los filtros de entrada. Este paquete puede ser aceptado, denegado o rechazado, en este último caso se avisa al remitente. Si los filtros de entrada aceptan el paquete, pasa al sistema si era su destino final o pasa por los filtros de reenvío o enmascaramiento, donde se vuelve a repetir una de las acciones. Por último, los paquetes que proceden del propio sistema o los que han sido aceptados por los filtros de reenvío o enmascaramiento pasan al filtro de salida. En cualesquiera de estos filtros se puede indicar que lo anote en el registro de incidencias.
 

• Auditoria del sistema. Registro y conocimiento de incidencias 


A parte de todo esto, puede conocer las incidencias que ocurren durante el funcionamiento del sistema. Por un lado conviene familiarizarse con los procesos que se ejecutan habitualmente en una máquina. Es una buena costumbre ejecutar periódicamente ps axu. Cualquier cosa extraña debiéramos aclararla. Puede matar cualquier proceso con la orden kill -9 pid (o killall -9 nombre_proceso). Pero en caso de ataque activo, lo mejor es desconectar de la red inmediatamente, si es posible, claro está.

Después tenemos los registros de incidencias (las ubicaciones pueden ser diferentes dependiendo del sistema, pero no radicalmente distintas) de /var/log . 

Trabajando en modo texto se puede hacer en una consola virtual (como root)
 

tail -f /var/log/messages tail -f /var/log/secure  Y muchos mas que no trataremos aqui.

y de esta forma podemos ir viendo las incidencias del sistema. Conviene también familiarizarse con las anotaciones que aparecen habitualmente para diferenciarlas de las que puedan presentar un problema. 

En modo gráfico hay un programa llamado ktail que le muestra las incidencias de una forma similar a la anterior.
 

• Comunicaciones seguras


Por último, nos interesará mantener unas comunicaciones seguras para garantizar la privacidad e integridad de la información. Actualmente existen las herramientas necesarias para cada necesidad.

Podemos usar cifrados simétricos como pgp y gpg para documentos, correo electrónico y comunicaciones sobre canales inseguros

Podemos crear canales de comunicación seguros de distinto tipo: 
 

• SSH (Secure Shell), stelnet: SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y mantener una conexión cifrada. Con esto evitamos, entre otras cosas, que las claves circulen por la red sin cifrar.

 
• Cryptographic IP Encapsulation (CIPE): CIPE cifra los datos a nivel de red. El viaje de los paquetes entre hosts se hace cifrado. A diferencia de SSH que cifra los datos por conexión, lo hace a nivel de socket. Así un conexión lógica entre programas que se ejecutan en hosts diferentes está cifrada. CIPE se puede usar en tunnelling para crear una Red Virtual Privada. El cifrado a bajo nivel tiene la ventaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningún cambio en el software de aplicación.

 
• SSL: o Secure Sockets Layer, fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator como un protocolo para dotar de seguridad a las sesiones de navegación a través de Internet. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su madurez, superando los problemas de seguridad y las limitaciones de sus predecesores. En su estado actual proporciona los siguientes servicios:

 
• Cifrado de datos: la información transferida, aunque caiga en manos de un atacante, será indescifrable, garantizando así la confidencialidad.
• Autenticación de servidores: el usuario puede asegurarse de la identidad del servidor al que se conecta y al que posiblemente envíe información personal confidencial.

 
• Integridad de mensajes: se impide que modificaciones intencionadas o accidentales en la información mientras viaja por Internet pasen inadvertidas.

 
• Opcionalmente, autenticación de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si puede acceder a ciertas áreas protegidas.

 
• Consejo:


Limite las acciones que realice como root al mínimo imprescindible, y sobre todo no ejecute programas desconocidos. Por ejemplo, en un juego (el quake) que distribuía una revista había un programa llamado runme que enviaba por mail las características de la máquina a una dirección de correo. En este caso se trataba de un troyano inofensivo, pero ofrece una idea de lo que puede hacer un programa ejecutado sin saberse lo que hace.

Unix también tiene la posibilidad de proporcionar acceso transparente a Internet a una red local mediante IP masquerade. En este caso, si usamos direcciones de red privadas, nos aseguramos que los equipos de la red interna no son accesibles desde Internet si no es a través del equipo Unix.

También podemos instalar un servidor proxy con caché, que a la vez que actúa de filtro de conexiones a nivel de aplicación, puede acelerar el acceso a servicios desde la red local.
 

Introducción a la seguridad del root

Tampoco hay que alarmarse. Piense que en un sistema operativo monousuario cualquiera podría darle formato al disco duro y perder toda la información almacenada o borrar cuaquier fichero necesario para el funcionamiento del sistema. En un sistema estilo Unix, como Unix, esto sólo lo podría hacer el usuario root. 

Hábitos seguros

Una primera norma que siempre debería tener presente es usar la cuenta de root sólo para realizar tareas concretas y breves y el resto hacerlo como usuario normal. Es una costumbre muy peligrosa usar todo el tiempo la cuenta de root. Al principio, a los usuarios de Unix les gusta sentir todo el poder de la cuenta de root, les molesta que su propio sistema les deniegue el permiso para hacer algo, pero van cambiando de opinión poco a poco, conforme se van familiarizando con el sistema o cuando han realizado un destrozo de esos que nos hacen proferir insultos contra nosotros mismos acompañados de un desesperado puñetazo en la mesa (o en el teclado). Piense que cuando el sistema le deniega alguna operación es porque puede conllevar algún riesgo. El sistema le avisa para que piense dos veces lo que está haciendo.

En los casos de tareas que necesiten privilegios de administrador para realizar una operación concreta, podemos usar la orden «su» (Super Usuario) o también « sudo». De esta forma podremos acceder a los privilegios de root sólo cuando nos interese.

Consejos:

 
• Asegúrese de que en los borrados de ficheros por parte del root se pide confirmación. Esto lo puede hacer poniendo «alias rm="rm -i"». Esto es lo habitual para el root . Si en alguna ocasión tiene que borrar muchos ficheros y no quiere confirmar cada uno de ellos, puede usar la opción «-f» para no pedir confirmación, deshacer el alias con «alias rm=rm» o bien usando la orden «yes» , poniendo «yes|rm ficheros» para ir confirmando automáticamente cada una de las preguntas de la orden.

 
• Procure prever los resultados de una orden, sobre todo si usa comodines, intentándolo antes una forma no irreversible. Por ejemplo, si quiere borrar todos los ficheros terminados en «~» ejecute primero «ls -la *~» y una vez que haya verificado a qué va a afectar la orden, ejecute «rm *~».

 
• Vigile la variable de entorno «PATH». Limite la búsqueda automática de ejecutables a las ubicaciones estándar del sistema. De forma particular evite incluir el directorio actual, es decir «.», en esta búsqueda. Bastaría incluir un ejecutable llamado «ls» en un directorio para que puedas ejecutar un código desconocido con privilegios de root, y cuando se dé cuenta de lo que ha hecho sea demasiado tarde.


Además, no tenga directorios con permiso de escritura en su ruta de búsquedas, ya que esto puede permitir a un posible atacante modificar o poner nuevos binarios que se puedan ejecutar como root la próxima vez que ejecute una determinada orden.
 

• No utilice las herramientas rlogin/rsh/rexec como root. Pueden ser objeto de diversos tipos de ataques y es peligroso ejecutarlas como root. Nunca cree un fichero .rhosts para root. 

Evite que la clave del root circule por la red sin cifrar. Si tiene la necesidad de ofrecer servicios de shell o ejecución remotas sobre un canal inseguro utilice «ssh» en lugar de «telnet» u otra herramienta que no cifre los datos de las conexiones. Los servicios remotos como «rlogin», «rsh» y «rexec», como dijimos antes, no suelen ser seguros si se utilizan canales no seguros. Es mejor deshabilitarlos. 
 
• Limite las ubicaciones desde donde alguien se puede conectar como root al sistema. En el fichero /etc/securetty puede especificar la lista de terminales desde las cuales se puede conectar el root. Las teminales predeterminadas para conectarse como root sólo incluyen las consolas virtuales (vtys). Si tuviera que conectarse como root desde una ubicación distinta a la consola, hágalo como usuario normal primero y luego utilice «su» para acceder a los privilegios de root. De esta forma un posible atacante tendría que conocer el nombre de un usuario del sistema, conocer su clave y también conocer la clave del root. Esto pone más dificultades para obtener privilegios remotos en su sistema. 

 
• Evite siempre dar la clave de root, no lo haga bajo ningún concepto por mucha confianza que tenga con esa persona. Si tiene que otorgar privilegios a algún usuario para realizar alguna tarea de administración, como montar un CD u otro dispositivo similar, utilice « sudo» para permitirlo con la propia clave del usuario. Así puede decidir qué usuario tiene acceso a una determinada orden. 

 
• No modifique los permisos de un fichero o directorio si no sabe realmente qué está haciendo. Los valores que trae la instalación de las distintas distribuciones suelen ser adecuados. 

 
• Jamás, insistimos, jamás se conecte a un servicio IRC como usuario root.

 
• Hay herramientas como sudo que permiten a ciertos usuarios utilizar comandos privilegiados sin necesidad de ser root, como montar o desmontar dispositivos. Además registra las actividades que se realizan, lo que ayuda a determinar qué hace realmente este usuario.

Prevenir pérdidas de información

Si los datos tienen un tamaño inferior a 650Mb, puede ser una buena opción grabarlos en un CD, bien permanente (ya que es más difícil de falsificar con posterioridad, y si están almacenados de forma adecuada pueden durar mucho tiempo) o regrabable. Las cintas y otros medios sobre los que se puede escribir deberían protegerse tan pronto como se completa la copia y se verifica para evitar la falsificación. Tenga cuidado y almacene su copia de seguridad en un sitio seguro. Una buena copia de seguridad le asegura que tiene un buen punto desde el que restaurar su sistema.

Hay que insistir en la seguridad de las copias de seguridad. Si las copias de seguridad no están almacenadas en un sitio seguro, puede que el posible intruso no tenga necesidad de idear métodos sofisticados para obtenerla, si le basta con copiar o sustraer un CD. 

Características de las copias de seguridad

Secuencia de Copias

Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta para cada Viernes y una cinta para para los Viernes impares. Se realiza una copia incremental cada día, y una copia completa en la cinta adecuada de cada Viernes. Si hace algún cambio importante o añade datos importantes a su sistema también sería adecuado efectuar una copia.

Tar y Gzip

para crear un tarball de tus ficheros favoritos (por lo general /etc, /var/spool/mail, /var/log , /home y cualquier otros datos de usuarios/sistema), seguido de un:

para comprimirlo lo máximo posible (por supuesto que el espacio de disco duro es más barato que la promesa de un político, pero comprimirlo lo hace más fácil de transportar). Quizás preferirías utilizar bzip, que es bastante mejor que gzip comprimiendo texto, pero es algo más lento. Por lo general después hago una copia del archivo en un servidor remoto, ya sea mediante ftp o enviándolo por correo como un attachment si no es grande (p. ej, la copia de seguridad de un cortafuegos suele ser de alrededor de 100kb de ficheros de configuración). 

Almacenamiento seguro

• La orden crypt:


Esta orden te solicita una clave para cifrar el contenido del fichero que quieres cifrar, no lo utilices para cifrar informacion confidencial es poco seguro.

• La orden PGP:


El sw PGP, desarrollado por Phil Zimmermann, es conocido como sistema de firma digital para correo electronico. Tambien permite el cifrado de archivos de forma convencional mediante criptografia simetrica.

• TCFS:


La principal diferencia con otros es que mientras que estos operan a nivel de aplicacion, TCFS lo hace a nivel de nucleo, consiguiendo mayor transparencia y seguridad. Obviamente esto tiene un grave inconveniente: TCFS solo funciona en sistemas Unix.

• Otros:


CFS, SFS,etc.

Programas seguros, inseguros y nocivos

• Errores en los programas


Los bugs a la hora de programar codigo de aplicaciones o del nucleo de Unix constituyen una de las amenazas a la seguridad que mas quebraderos de cabeza proporciona.

• Buffer overflows.


Uno de los errores mas comunes es el stack smashing o desbordamiento de pila, tambien conocido como buffer overflow.

• Condiciones de carrera.


Cuando dos o mas procesos leen o escriben en un area compartida, y le resultado final depende de los instantes de ejecucion de cada uno.

Ejemplos de ataques

El simple hecho de inundar de datos una red es una táctica pasada de moda pero efectiva, que empeora por el hecho de que la mayoría de las redes tienen configuraciones de cortafuegos defectuosas. Haciendo un ping a la dirección de red de una red remota (por ejemplo un PSI de cablemódem) se pueden recibir varios cientos de pings de respuesta por cada paquete que se envíe. Si se falsea la dirección IP y se etiquetan los paquetes salientes como provenientes de una red de alguien que te disguste, se puede hacer que la mala configuración de una red sea la que haga el trabajo sucio y sature a la víctima.

Envenenamiento de caché DNS

Puesto que muchos servicios confían en el buen funcionamiento del DNS, supone una parte de la red interesante para atacar. Alterar la información de los servidores DNS es más sencillo de lo que debería ser, y si se consigue, se pueden introducir datos falsos. Por ejemplo, si le convenciera a tu servidor de nombres que updates.Redhat.com en realidad apuntase a updates.losmalos.com, probablemente conseguiría engañarte para que te bajases e instalases mi software. Por supuesto que esto lo niega el hecho de que Red Hat firma sus paquetes con PGP, pero ¿verificas las firmas? De igual forma, si utilizas una herramienta automatizada, como autorpm, puede ocurrirte sin intervención del usuario, los paquetes comprometidos se descargan y se instalan, y todo lo que tengo que hacer es echarle un vistazo al log de ftp y después explotar los sitios que han hecho download de los paquetes. Si me las apañase para convencer a tu servidor de correo que otraempresa.com es en realidad uno de mis servidores, no sólo podría recibir el correo que le envías a otraempresa.com, sino que podría leer el correo, y quizás volverlo a reenviar con pequeñas modificaciones (como añadirle un 0 de más al precio de tu oferta).
 

Deteccion de intrusos

• Examinaremos todos los ficheros de log, ya sean creados por syslog o por tu firewall o router.
• Buscaremos los ficheros con los bits setid y setgid activados (sobre todo los de root). Los intrusos suelen dejar copias de programas como /bin/sh o /bin/time con el bit "setuid" activado para permitirles acceso a root mas tarde. Puedes usar la orden:
find / -user root -perm -4000 -print
find / -group kmem -perm -2000 -print
• Comprueba los binarios del sistema, para ver que no han sido alterados. Por ejemplo los referenciados en /etc/inetd.conf como son login, su, telnet, ifconfig, du, etc. Compara las versiones de tus sistemas con copias de seguridad, de la instalacion original, los backups pueden contener caballos de Troya.
• Comprueba que en tu sistema no existan programas no autorizados de monitorizacion de red, como un sniffer.
• Examina todos los ficheros que son ejecutados por cron y at. 
• Tambien puedes comprobar el /etc/inetd.conf para que no haya servicios no autorizados. Busca entradas como /bin/sh o /bin/csh.
• Como no, examina el /etc/passwd a fondo.
• Mira tambien que no existan entradas no autorizadas en los ficheros de configuracion de red y del sistema. Busca con entradas con '+' y nombres de hosts externos no apropiados en el fichero /etc/hosts.equiv, /etc/hosts.lpd y en los .rhosts. Y comprueba que no hay ninguno nuevo creado.
• Busca ficheros raros u ocultos. 
find / -name ".." -print -xdev
find / -name ".*" -print -xdev | cat -v 

Como intentaran entrar en tu maquina

Los puertos mas importantes son:

• ftp (21)
• telnet (23)
• sendmail (25)
• finger (79)
• http (80)
• pop (110)
• imap (143)

telnet maquina.com 21

nos dice la version del ftp de la maquina.

Tambien se puede hacer un escaneo de los puertos a la maquina.

El puerto del finger(79) se usa para conseguir informacion de los usuarios de la maquina. Si el puerto esta abierto y no tiene un firewall entonces te podras conectar pero no es lo usual. Una vez dentro puedes pedir informacion de los usuarios e incluso hacerte pasar por ellos en los mails, para sacar informacion.

Si se hace un telnet al puerto smtp, y luego haces un vrfy a veces te da el nombre del usuario.

Conseguir una cuenta es mas chungo, la forma mas facil es ingenieria social, que consiste en engañar a alguien para que te de su pass o informacion util. No hay que fiarse de nadie.

De ahi pasaran a coger tu /etc/passwd y /etc/shadow y ya estan dentro de tu maquina con unos retoques a los fichero passwd y shadow....

Linux es Open Source

Continuaraaaaaaa