Indice

1_ Integrantes.

2_ Indice.

3_ Introducción.

4_ Seguridad en UNIX.

5_ Una política de seguridad. Protección de los datos frente a los otros usuarios.

6_  Permisos implícitos para la creación de ficheros.

7_ Cifrado de ficheros. Ids de presentación y contraseñas.

8_ Historial de presentaciones. El superusuario.

9_ El fichero de contraseñas. Un fichero /etc/passwd.

10_ Ingreso y retirada de usuario.

11_ Envejecimiento de contraseña.

12_ Retirada de usuario.

13_ Adición de grupos. El shell restringido.

14_ Protección del sistema y los ficheros de UNIX.

15_ Seguridad física. Redes de área local.

16_ Seguridad uucp. Fichero de permisos de uucp.

17_ Permisos implícitos. Adaptación del fichero Permissions. Control de llamadas de entrada con la línea Logname.

18_ Control de llamadas de salida con la línea Machine. La orden uucheck.

19_ Máquinas remotas desconocidas y sondeos. Ataques al sistema.

20_ Comportamiento del defensor. Detección de un ataque.

21 y 22_ Caballo de Troya, virus y gusanos, Los UNIX seguros.

23_ Conclusión.

24_ Bibliografía

 

 

 Integrantes

1- Alfonso Javier

2- Arce, Benjamin

3- Barrenechea, Ricardo

4- Castro, Maria de los Angeles 

5- Catan, Alejandro

6- Deniz, Isabel

7- Harfuch, Fernando Javier

9- Rosales, Mirna Elisa

10- Sosa Jost, Eliana 

 

 

Introducción

            Unix dispone de muchos modos para que los usuarios accedan al sistema y muchas herramientas para comunicación entre usuarios y máquinas diferentes. Sin embargo en el mundo actual hay razones para que personas no autorizadas irrumpan en el sistema computador (ej. El robo comercial de datos y programas, etc.). Es por esto que hay que equilibrar la facilidad de acceso para los "amigos" con la prevención de acceso a "enemigos".

            El sistema Unix fue originalmente creado para servir a pequeños grupos que compartían la máquina totalmente. No existían rígidas limitaciones al acceso de un usuario, a los ficheros y ordenes, de otros usuarios, incluso ni a los datos más sensibles destinado a mantener en operación el sistema Unix. Cualquier usuario podía fácilmente eliminar o modificar ficheros, o incluso suspender el sistema.

            Lo que se detalla a continuación son algunas de las herramientas y ordenes relacionadas con la seguridad.

            Se pueden adoptar pasos para impedir accesos no autorizados, pero la tendencia natural de un sistema operativo complejo es hacia la disminución de su seguridad por el espacio del tiempo: hay que estar constantemente alerta para detectar agujeros en la seguridad y defender rápidamente el sistema tapando los mismos.

Seguridad en Unix

 

·        Introducción.

·        Una política de seguridad.

·        Permisos implícitos para la creación de ficheros.

·        Protección de los datos frente a los otros usuarios.

·        Cifrado de ficheros.

·        Ids de presentación y contraseñas.

·        Historial de presentaciones.

·        El superusuario.

·        El fichero de contraseñas.

·        Ingreso y retirada de usuario.

·        Envejecimiento de contraseña.

·        Retirada de un usuario.

·        Adición de grupos.

·        El shell restringido.

·        Protección de los sistemas y ficheros de Unix.

·        Seguridad física.

·        Redes de área local.

·        Seguridad uucp.

·        Ficheros de permisos uucp.

·        Permisos implícitos.

·        Adaptación del fichero Permissions.

·        Control de llamadas de entrada con la línea LOGNAME.

·        Control de la línea de salida con la línea MACHINE.

·        La Orden uucheck.

·        Máquinas remotas desconocidas y sondeos.

·        Ataques al sistema.

·        Comportamiento del defensor.

·        Detección de un ataque.

·        Caballos de Troya, virus y gusanos.

 

 

Una Política de seguridad

 

·        Dentro de una máquina o red de máquinas:

      & El administrador o grupo de usuarios en conjunto, debería establecer una política de seguridad para:

          _ Regular la asignación de nuevos ids de usuario,

          _ La cuantía de protección por contraseña requerida dentro del sistema y,

          _ La cantidad de conectividad que la máquina permite a las LANs y el mundo externo.

·        La política de seguridad puede ser relativamente simple si:

        & El sistema esta relativamente aislado y

        & Tiene un pequeño grupo de usuario con la misma comunidad de intereses.

·        La política de seguridad puede ser más restrictiva si:

        & El sistema es grande y

        & tiene varios grupos de usuarios

        & tiene un elevado perfil público, o

        & contiene datos especialmente sensibles o

        & contiene datos especialmente positivos

·        La responsabilidad principal del cumplimiento de las normas de seguridad corresponde a cada usuario individual,

        & Los administradores del sistema pueden desarrollar un procedimiento de auditorías regulares con realimentación a la comunidad de usuario.

        & La regla más importante es conocer el sistema.

·        Si el administrador y los usuarios del sistema utilizan:

        & Las ordenes ps. Who. Is y

        & Otras ordenes de información del sistema.

          _ Se familiarizaran con la actividad normal día a día de la máquina y

          _ Estarán alertas al estado del sistema en todo momento.

·        Las desviaciones de las normas serán rápidamente advertidas.

        & El administrador del sistema podrá tomar acciones para taponar los escapes.

·        Categorías generales de seguridad:

        & Protección de los ficheros y datos privados de un usuario respecto del resto de los usuarios.

        & Protección de los ficheros claves del sistema operativo contra daños accidentales o intencionales.

        & Seguridad física de la máquina.

        & Protección del sistema contra determinados ataques por parte de piratas (hackers).

Protección de los datos frente a los otros usuarios

 

Los ficheros del sistema de ficheros tienen tres niveles de permiso:

·        Los usuarios individuales.

·        Los del grupo al que el usuario pertenece.

·        Los de todos los demás usuarios de la máquina.

En una máquina pequeña donde los usuarios comparten una fuerte comunidad de interés, el administrador del sistema establecerá un único grupo para todos los usuarios, de modo que todos los usuarios puedan compartir ficheros para sus usos propios. En instalaciones mayores donde existen varias comunidades no relacionadas, pueden haber muchos grupos diferentes.

            El fichero tiene tres grupos de permisos para cada uno de los tres niveles de seguridad, es decir, tiene acceso de lectura, escritura y ejecución para el propietario, para el grupo y para todos los usuarios. Cada fichero es propiedad de un id de presentación  y pertenece a un grupo.

            Cuando se crea un nuevo fichero el usuario que lo crea es el propietario del fichero, y su grupo se asigna como un id de grupo.

            Se puede ceder la propiedad del fichero con la orden CHOWN.

            Se puede cambiar el grupo del fichero con la orden CHGRP, pero solo si es propietario del fichero.

 

Permisos Implícitos para la Creación de Ficheros

            El usuario debe preguntarse ¿ Es aceptable que todos los usuarios pertenecientes al grupo tengan acceso a los datos? ¿ Debería alguien más tener permitido la lectura o escritura de los ficheros?, y se debe establecer los permisos para cada fichero que fue creado.

            El sistema Unix proporciona automáticamente al creador de un fichero la propiedad del mismo, y asigna al fichero el grupo de su creador. Se puede declarar una variable del sistema asociada con el id de presentación que establecerá los permisos de un fichero sin acción explícita por parte del usuario. Esta variable del sistema se denomina UMASK (máscara de usuario para creación de fichero), a la cual se accede con su denominación.

            Se puede determinar el valor actual de UMASK ejecutando la orden sin argumento, el resultado son tres dígitos octales que se refieren a los permisos del propietario, el grupo y los otros, de izquierda a derecha. A este número se denomina máscara ya que cada dígito se resta de un permiso implícito global del sistema que todos los nuevos ficheros obtienen.

            Este permiso global es -rw-rw-rw- pero sistemas y programas individuales pueden diferir de este valor. La UMASK del usuario se resta de este valor implícito, no se pueden activar permisos con UMASK que estén normalmente desactivados, pero se pueden desactivar permisos que están normalmente activados.

            Se pueden activar explícitamente los permisos con CHMOD si el usuario tiene la propiedad del fichero.

            Cada dígito octal de la UMASK contiene un bit binario que borra un permiso:

 

·        Borrará el permiso de ejecución.

·        Borrará el permiso de escritura.

·        Borrará el permiso de lectura.

 

            Si un dígito es cero, se utiliza el permiso implícito por ejemplo:

UMASK 000 significa que no se alteran ninguno de los valores implícitos, o sea, crea los ficheros con los permisos implícitos.

UMASK 002 crea fichero sin permiso de escritura para el resto de los usuarios.

UMASK 777 desactiva todos los permisos para todos los usuarios.

            Para declarar UMASK se utiliza la orden UMASK con el código octal como argumento. Si se desea modificar permanentemente la UMASK, hay que colocar la orden UMASK en el fichero, de este modo no se necesita considerar los permisos que se crean para cada fichero.

Cifrado de Ficheros

            Se puede proteger adicionalmente los ficheros cifrándolos. La mayoría de los sistemas UNIX disponen de herramientas para hacerlo de acuerdo con una clave que el usuario proporciona, solo reintroduciendo la clave correcta.

            Editores como ED.VI y EMACS proporcionan la capacidad de crear y editar ficheros cifrados. Se puede permitir al editor que descifre un fichero cuando lo cargue y cifre de nuevo cuando lo escriba al disco.

            Cualquier contraseña es aceptable cuando se cifra un fichero, si se introduce la contraseña correctamente ( la misma ) el fichero será descifrado y aparecerá en el editor. Cuando se escriba el fichero de vuelta durante o después de la sesión de edición será de nuevo cifrado. Se puede utilizar este procedimiento para crear un nuevo fichero o para editar un fichero existente.

            La orden CRYPT lee la entrada estandar y escribe la salida estandar. Si la entrada está cifrada la salida será descifrada.

Desventaja:

            El algoritmo por el cual los ficheros son cifrados en el sistema UNIX es poco conocido y hay programas disponibles que puede reventar el algoritmo descifrado. No es seguro disponer demasiada confianza en los ficheros cifrados, especialmente en un entorno hostil. Los programas transgresores descifrados funcionan analizando las frecuencias de los caracteres en los ficheros cifrados y comparándolos con las frecuencias de caracteres en el texto ingles normal.

            Para vencerlos se puede modificar la secuencia de caracteres del texto normal antes del cifrado con otro filtro tal como PACK o COMPRESS. El fichero comprimido no puede ser analizado por ningún transgresor de CRYPT conocido. Cuando se descifre el fichero hay que recordar desempaquetarlo.

            El esquema de protección de ficheros de más éxito es el que implica escribir el fichero en un disco flexible o cinta magnética, suprimir el fichero de la máquina y poner en un recaudo el medio magnético.

 

Ids de presentación y contraseña

 

            El corazón del esquema de seguridad del sistema UNIX es el id de presentación y la contraseña del usuario individual. Si los atacantes potenciales pueden ser mantenidos completamente fuera del sistema, no podrán causar daños. Desgraciadamente en muchas máquinas la seguridad de la contraseña es tan pobre incluso un infractor sin experiencia puede obtener un SHELL. Es responsabilidad del usuario defender su propia contraseña y cambiarla regularmente.

            Muchos ids de usuario de un sistema pequeño típico no tiene contraseña en absoluto, o sus contraseñas son tan similares al id de presentación que es ineficaz como seguridad. Desgraciadamente, la mayoría de los usuarios  no desean recordar el tipo de contraseña secreta que realmente requiere la seguridad, que con el tiempo las mismas pasan a ser detectables. Todo usuario debería ser forzado a tener una contraseña, la cual debería ser "envejecida" de modo que el usuario estuviese forzado a cambiarla con regularidad. Puesto que la contraseña se almacena en forma cifrada, ni siquiera el administrador del sistema puede determinar cual es.

 El ataque por frecuencias de letras no es posible con una muestra de texto tan breve como una contraseña.

            La herramienta que permite modificar la contraseña es la orden PASSWD. Esta orden solicita la contraseña actual antes de permitir modificarla. Luego requiere que el usuario introduzca la nueva contraseña dos veces antes de que tenga efecto.

            Existen reglas que describen una contraseña aceptable, incluso si estas reglas no son forzadas por el software del sistema proporcionan buenas líneas de guía para crear una contraseña propia.

            Una buena contraseña tiene como poco seis caracteres, de los que al menos uno (preferiblemente dos) es un caracter numérico y otro es no alfabético. Una mezcla de caracteres mayúsculas y minúsculas es buena y cualquier secuencia inusual o no intuitiva de caracteres es también útil. Algunos ejemplos de contraseñas triviales no aceptables son el id de presentación, el nombre del usuario, el nombre de su hijo, su número de habitación o de teléfono, su signo astrológico, su dirección, etc.

 

Historial de presentaciones

 

Algunas versiones SVR4 muestran la última vez que fue utilizado un id de presentación, esto aparece cuando el usuario se presenta ante la máquina, de la siguiente manera:

Login: steve

Password:

Login last: wea occ: 24 15: 11: 02 1990

S

            Esto sirve para alertar al usuario cuando alguien más ha estado utilizando su id de presentación. Si la fecha difiere de la recordada por el usuario de su última sesión su id de presentación esta siendo mal utilizado y debería inmediatamente tomar medidas para cambiar la contraseña. Login mantiene en el directorio propio un fichero de longitud cero denominado lastlogin. La fecha y la hora de la última presentación son las de modificación de este fichero. Este fichero es de propiedad del sistema no del usuario individual, y sus permisos lo hacen dificil de modificar. Ejemplo::

S Is-1 shome/. Lastlogin

------------        1   root     sys                    o oc: 28 15: 11. Lastlogin.

            Esta no es una característica de seguridad energética, pero puede avisar al usuario si su id de presentación ha sido comprometido.

 

 

El Superusuario

 

            El id de presentación root se encuentra disponible en todas las máquinas UNIX para permitir al usuario acceso completo de lectura, escritura y ejecución a todos los ficheros y directorios. Este usuario es conocido como el superusuario. Para conmutar al estado de superusuario sin necesidad de despedirse y presentarse de nuevo como root se utiliza la orden su ( por superusuario ). Ejemplo:

S/soin/su

Password:

=

  

El Fichero de contraseñas

 

            En el fichero de base de datos llamado /etc/passwd se encuentra la información que controla las identificaciones de los usuarios. Ejemplo:

S Is-1/etc/passwd

----------    1 root          526 aor    10 19: 49 / etc/ passwd

            La seguridad del fichero quebraría fácilmente en el caso de que el fichero /etc./ passwd fuera modificable por alguien. Cada usuario tiene una línea en el fichero de contraseñas, y a su vez cada una de ellas consta de varios campos delimitados por " : ", también son necesarios varios ids de presentación estandar globales del sistema, siendo éste el primer campo de la línea y el segundo en un emplazamiento para la contraseña del usuario " x ", el tercero es la representación numérica del id del usuario y el cuarto es la representación del grupo, todo esto para su correcto funcionamiento. Estos campos actúan junto con los permisos del fichero para determinar quien puede acceder a cada fichero del sistema. Hay un quinto campo que es el de comentario y generalmente contiene el nombre y la dirección del usuario. El penúltimo campo contiene un directorio propio del usuario, y el último contiene el nombre de camino completo del shell de presentación del usuario. Si el último campo falta se señala implícitamente a /sbin/sh.

Un Fichero /etc./ Passwd típico

 

            Para el correcto funcionamiento de la máquina son necesarios los ids de presentación los que no pueden suprimirse o modificarse sin provocar daños al sistema. Los ids de presentación, de  usuario y de grupo, el directorio propio y el shell implícito no deberían ser modificados en ninguna presentación que no pertenezca a un usuario real.

            La identificación root que corresponde al superusuario, es el id usuario cero y su directorio es el raíz, debería tener siempre una contraseña de lo contrario se convierte en la peor violación de seguridad en UNIX ya que el usuario tiene acceso completo a todo el sistema. Los siguientes ids de presentación corresponden a otras herramientas administrativas en instalaciones grandes son utilizadas por individuos responsables de la administración de diferentes subsistemas y en una máquina pequeña se pueden desactivar editando la cadena NONE u otra cadena de texto en el fichero de contraseñas en /etc./shadow. Al descifrarse la contraseña a partir de la entrada /etc./shadow, una cadena de texto llano será descifrada en una cadena sin sentido que los usuarios no podrán adivinar al tratar de abrir una sesión.

            Las funciones desactivadas de estos id de presentación las debería efectuar el usuario root.

            Las presentaciones de un sistema pueden diferir dependiendo de la disposición del hardware de la máquina dado que el software adicional suele añadir presentaciones administrativas.

            La presentación nuucp es utilizada por las máquinas remotas para enviar correos, su shell es /usr/lib/uucp/uucico. No se necesita una contraseña para la utilización de nuucp pues no se trata de un shell normal y además el programa uucico es muy seguro.

            Todos los id de presentación excepto nuucp deberían tener contraseñas las que tienen que ser legitimas en clave para los usuarios reales y root.                    

 

Ingreso y retirada de usuario

 

            Aunque es fácil añadir o suprimir usuarios, solo el superusuario puede hacerlo. Las herramientas Useradd, Userdel y Usermod están diseñadas para estos trabajos, y su utilización es preferible a que tener que ingresar manualmente usuarios o utilizar la orden passmgmt obsoleta. Si se cambian ficheros de control de usuarios tales como /etc/passwd, manualmente hay que tener la precaución  de retener los permisos y propiedad originales de los ficheros.

            Cada usuario tiene un id de presentación, un id de usuario numérico, un directorio propio, un shell implícito y una contraseña.

            Al crear un nuevo usuario se debe especificar los valores de todos estos componentes. La orden Useradd permitirá dar ingreso a nuevos usuarios en el sistema, manteniendo valores implícitos, pero es necesario seleccionar los otros cuando se da de alta a un nuevo usuario. La opción -D(por mostrar display) muestra los valores implícitos.

 Ejemplo:

# userad -D

group=other, 1 baserdir =/home skel =/etc/ skel

shell=/soin/sh inactive=0 expire =

#

            Esto muestra los valores implícitos normales asignados a los nuevos usuarios en el caso de no tomar acción específica. Los nuevos usuarios formarán el grupo other con id de grupo (gid) 1. Su directorio propio estará bajo el directorio/home y por omisión obtendrán el shell estandar. Las entradas espire y active se refieren a los parámetros de envejecimiento de la contraseña. Estos valores implícitos están guardados en el directorio /etc/stel. Pueden ser modificados con la opción -D con un argumento en la línea de orden para definir el valor de cada componente implícito. Esto no es recomendable en los sistemas más pequeños.

            Para ingresar un nuevo usuario se especifica el id presentación del usuario tras la orden useradd:

# useradd # jim

            Esto creará la entrada del usuario en /etc/passwd y /etc/shadow utilizando los valores implícitos y también creará un directorio propio para el usuario. Si todo sigue bien useradd regresará, si el id de presentación ya existe useradd se quejará:

# useradd jim

UX: useradd: error: jim is already in use. Choose another.

            Cada id de presentación debe ser único, pero el directorio propio, el id de usuario numérico  y otra información puede estar compartidos entre 2 usuarios, lo que no es una buena idea. La contabilidad del sistema se mejora mucho si cada usuario tiene un entorno individual. La excepción es el id del grupo, que está pensado para ser compartido entre los usuarios.

            Cuando se crea un id de presentación, debería añadirse en comentario que indique el nombre del usuario, su afiliación y otra información relevante. Este comentario aparecerá en la entrada /etc/passwd del usuario, y ayudará a seguir la pista de los usuarios, especialmente en un sistema grande. Para añadir un comentario, utilice la opción -c en la línea de orden de useradd seguido del comentario entrecomillado del siguiente modo:

 

# useradd -c "Jim, 555-1234, Suite 320" jim.

 

            Utilizando argumentos de línea de orden adicionales con useradd se pueden reemplazar los otros valores implícitos también. Se puede seleccionar un id de usuario específico(-d) y un shell (-s), además de otros parámetros asociados con la presentación. Con la opción -e (por expirar) se puede seleccionar una fecha de expiración para la presentación. Esto permite crear una presentación temporal que queda invalidada luego de una fecha especificada.

# useradd -e "12/31/90" -c "Presentación temporal para proyecto yabu" jim

 

Envejecimiento de contraseña

 

            Se crea un id de presentación utilizando useradd, la entrada en /etc/shadow tiene una contraseña bloqueada [locked] , que el nuevo usuario aún no tiene permitido el acceso al sistema. Hay que habilitar la presentación seleccionando algunos parámetros de envejecimiento de contraseña antes de que el usuario pueda utilizar el sistema.

            El software de contraseña permite  que el administrador del sistema prepare un procedimiento de envejecimiento de contraseña  que fuerce a todos los usuarios a cambiar su contraseña con regularidad. Cuando se establece una contraseña, se inicia un reloj, y cuando el intervalo establecido transcurre, la contraseña se descarta y se pide al usuario que elija una nueva. Cuando se crea una nueva contraseña, el superusuario permite el envejecimiento de contraseña utilizando la orden passwd. El procedimiento también borra el estado bloqueado de la contraseña proporcionada al nuevo usuario. Estas características están limitadas al superusuario, y están soportadas por varias opciones en línea de orden passwd.

            Para definir el máximo número de días que una contraseña puede estar activa antes de que deba ser modificada, se utilizará la opción -x junto con un número de días:

# passwd -x 120 jim

            Para definir el número mínimo de días de una contraseña debe estar activa antes de que pueda ser modificada, se utiliza la opción -n:

# passwd -n 7 jim

            Estas opciones regresarán silenciosamente si no hay error. Debe definirse  el intervalo máximo antes de poder declarar el intervalo mínimo, o se puede colocar ambas opciones en la misma línea de orden.

            La orden passwd también informa del estado de la contraseña del usuario con la opción -s (por status):

# passwd -s jim

jim LK 00/00/00 7 120

#

            Lo primero es el id  del usuario, seguido de un status, [lk] significa bloqueado [locket, ps] significa contraseña correctamente protegida [password y np] significa no contraseña [no password]. A continuación viene la fecha en que la contraseña fue modificada la última vez (00/00/00 si la presentación es nueva), seguido de los intervalos mínimos y máximo.

            Después de haber definido los parámetros de envejecimiento de contraseña, se puede suprimir el estado bloqueado con la opción -d (por suprimir [deleter]),:

# passwd -d jim

            La opción -d también puede suprimir la contraseña de un usuario normal. Esta opción debería ser utilizada con extremo cuidado, ya que una presentación sin contraseña es un riesgo de seguridad.

            Nadie puede crear una nueva contraseña para otro usuario, de modo que cuando ingresa un nuevo usuario en el sistema el mejor procedimiento es que el administrador se presente inmediatamente utilizando el nuevo id de presentación y defina una contraseña inicial manualmente. Luego el administrador puede presentarse de nuevo como root y ejecutar

# passwd -f jim

que inmediatamente hace expirar la contraseña recién creada. Cuando el usuario se presente por primera vez, utilizará la contraseña inicial, pero se le pedirá que cambie la contraseña inmediatamente:

login: jim

Password:

Your password has ezpired. Choose a new one

Old password:

            Este mensaje también aparecerá para los usuarios establecidos cuando haya transcurrido el tiempo máximo permitido para sus contraseñas.

            El envejecimiento de contraseñas es útil para el mantenimiento de la seguridad, ya que las contraseñas de los usuarios tienden a adquirir carácter de públicas después de que han sido utilizadas durante un tiempo, y el requerir su cambio con regularidad puede reducir las violaciones de seguridad. El forzar a los usuarios a cambiar su contraseña 2 o 3 veces al año generalmente es suficiente. Una debilidad del envejecimiento de las contraseñas es que los usuarios alternan con frecuencia entre 2 contraseñas favoritas que son puras permutaciones triviales la una de la otra. Por lo que esta práctica debería ser desaconsejada.                                                                                                                                                                                                                                            

Retirada de un usuario

 

            Cuando un usuario ha terminado con el sistema, su administrador debería inmediatamente suprimir el acceso del usuario al sistema, esto puede hacerse de dos modos: en primer lugar se puede bloquear la contraseña, reteniendo el directorio propio y la presentación del usuario. Esto impide al usuario entrar al sistema pero posteriormente puede volver a desbloquearse la presentación sin perder sus datos. Para ello usa la opción ( por bloquear [ lock ] ) de la orden passwd. Ejemplo:

# passwd- t jim

            Se puede retirar completamente al usuario del sistema para ello se usa la orden USERDEL ( por retirar usuario [ user delete ] ). Ejemplo:

# userdel jim

            Esta orden regresará si tiene éxito pero no puede ser usada si el usuario está presente. La orden USERDEL retendrá el directorio propio del usuario de modo que se pueda salvar la información que hay en él si se desea. Para suprimir el usuario y el directorio propio, se debe añadir la opción-r ( por remover ). Ejemplo:

# userdel -r jim

            Se pueden cambiar los parámetros asociados con un usuario, sin eliminarlos y luego restablecerlos con la orden USERMOD.

            Se debe ser cuidadoso en mantener actualizada la supresión de usuarios.

            Cuando el usuario abandona el sistema el administrador del sistema no desactiva inmediatamente su id de presentación, habitualmente esto ocurre en sistemas grandes con cientos de usuarios y presenta un serio riesgo de seguridad, ya que los ex usuarios pueden guardar rencor y provocar serio daño a la máquina. Se debe tener un cuidado extremo en examinar regularmente el fichero de contraseñas y retirar a aquellos usuarios que ya no estén activos.

 

 

Adición de grupos

 

            Cuando se añade un  nuevo usuario a un id de grupo, o se aceptan los valores implícitos no es necesario desarrollar actividades adicionales después de ejecutar las ordenes USERADD y PASSWD.

            Si se desea crear un nuevo grupo para el usuario o se desea que éste aparezca en múltiples grupos se debe editar el fichero /etc/group. Se puede usar la orden ADDGRP ( por añadir a grupo) o DELGRP ( por suprimir de grupo ); y para ver que grupo está en uso /etc/group.

            El fichero es una base de datos que tiene campos delimitados por dos puntos.

            Los usuarios tienen permitido cambiar de grupo usando la orden NEWGRP (por nuevo grupo), el segundo campo contendrá una contraseña cifrada que el usuario debe introducir antes de cambiar de grupo, estos cambios deben estar desactivados.

            El último campo en /etc/group contiene una lista separada por comas de los ids de usuarios que pertenecen a cada grupo. El usuario puede estar en más de un grupo, y tener acceso a ficheros que pertenecen a diferentes grupos. Para redistribuir los usuarios en los grupos se debe editar manualmente el fichero /etc/group, limitando los cambios al último campo. Este fichero debe ser legible por todos pero no modificable ni ejecutable por nadie.

 

El shell restringido

            El shell estandar proporciona facilidades para que el usuario pueda moverse por el sistema de ficheros, ejecutando muchas ordenes, cambiando el phat, etc. Pero en la mayoría de los sistemas UNIX existe un shell adicional llamado rsh ( por shell restringido ) es el mismo programa que el shell normal pero bajo dos nombres en el sistema: actúa de forma diferente dependiendo del nombre que se utiliza para invocarlo. En SVR4 el shell restringido está ubicado en el directorio /usr/lib, hay que tener en cuenta que éste no es el shell remoto utilizado con las LANs que reside en /usr/sbin/rsh. El shell restringido tiene menos capacidad que el shell normal. Se puede declarar /usr/lib/rsh como shell de usuario con la orden:

# userad -s /usr/lib/rsh jim

            El rsh difiere del shell normal en:

1) El usuario no puede utilizar cd para cambiar de directorio, pues está limitado a su propio directorio.

2) El usuario no puede cambiar la variable phat solo puede ejecutar las ordenes residentes en él, preparado por el sistema.

3) El usuario no puede nombrar ordenes o fichero usando un nombre de camino completo. solamente puede acceder al fichero del directorio propio y sus subdirectorios

4) El usuario no puede redirigir la salida.

            Estas restricciones son forzadas luego del profile del usuario. El administrador del sistema preparará un entorno restringido en el profile del usuario incluyendo un phat que apunte a un directorio bien limitado, y luego cambiará la propiedad de profile a root, lo hará legible por todos, pero ejecutable o modificable por ninguno. El usuario con shell restringido estará limitado al directorio propio y a las ordenes permitidas en el phat.

            El programa rsh evita que usuarios inexpertos se extravíen de sus entornos en los sistemas de ficheros, normalmente se adjudica a los usuarios que tienen razones limitadas para presentarse a la máquina.

            No es deseable coartar a los usuarios experimentados con rsh pues interferiría innecesariamente con su trabajo. Rsh no es completamente seguro y cualquier asaltante  experimentado puede fácilmente entrar en el shell normal. No se debe tomar rsh como herramienta de seguridad para asaltantes pero es útil para que el usuario no experimentado no se dañe inadvertidamente a si mismo o al sistema.        

            

Protección del Sistema y los Ficheros de unix

            Incluso los usuarios experimentados pueden dañar al sistema UNIX si tiene demasiado acceso a ficheros claves, tales como /etc/paswd o a datos de uucp. Hay que ser cuidadoso al evitar alguna reducción en la seguridad del sistema como resultado de los cambios normales cuando se instaló el sistema. Normalmente la carga inicial de un sistema UNIX dispone  todo los ficheros y directorios con permisos seguros y correctos, la excepción pueden ser los ids de presentación del sistema en /etc/passwd que no tienen contraseñas por omisión.

            Inebitablemente, con el tiempo, los permisos se hacen gradualmente menos seguros debido a que nadie esta perfectamente atento a la seguridad. Los ficheros pasan a ser más accesibles, las contraseñas desaparecen, las  identificaciones de usuarios inactivos se acumulan, etc.

            Generalmente es buena política volver a cargar regularmente la máquina a partir del software original del sistema lo que se vuelve tedioso para los usuarios y para el administrador del sistema (que ya a adoptado la máquina a sus necesidades), pero cuando se sospechan violaciones de seguridad, es el único modo de garantizar un sistema seguro. Recargar una o dos veces al año es suficiente para la mayoría de las máquinas.

            Cuando se efectúa una recarga hay que asegurarse de que el fichero de contraseñas este actualizado y borrar todas las ordenes y ficheros no utilizados que puedan ocupar lugar en los discos. Un buen procedimiento de copia de seguridad de los datos hace mucho más simple la recarga del sistema.

            Una segunda posibilidad es realizar barridas regulares de la máquina y de su sistema de ficheros, usando un guión automatizado para verificar que los permisos y propiedades de los ficheros sean seguros. Algunos productos de inoculación comerciales funcionan con este principio para detectar las formas de corrección de ficheros. Esta herramienta es dependiente de la instalación especifica, pero un administrador de sistema inteligente puede crear una herramienta útil.

Seguridad Física

            Hay que preocuparse por el acceso directo a la máquina por parte de personas que puedan acercarse a ella en ausencia de usuarios.

            La forma primaria de seguridad para un sistema UNIX “es la seguridad física”. Si se puede impedir el acceso a la máquina, ya sea manteniéndola en una habitación cerrada con llave o no dejando conexiones externas (modems o redes de ares local) se puede garantizar que la seguridad no sea asaltada.

            Un sistema verdaderamente seguro no tiene conexiones de datos externas, excepto los terminales conectados dentro de habitaciones cerradas. Si todos los ids de presentación están correctamente protejidos con contraseñas, no es posible el acceso no autorizado.

            Muchos sistemas UNIX pueden ser accedidos desde un disco flexible o cinta "maestro".

            Muchas máquinas disponen de protección de contraseñas en ROM para retardar los arranques, pero incluso estas no son completamente seguras.

            Un asaltante que sea capaz de llegar a la máquina puede arrancarla y gozar de privilegios completos a partir de una versión del sistema operativo sobre un disco de arranque; por lo tanto hay que tener cuidado de que la propia máquina no sea accesible.

            Otra clase de ataque sobre la seguridad física se origina cuando se carga el software y las aplicaciones. Cualquier disco o paquete de aplicación que se cargue en la máquina puede contener: trampas de seguridad añadidas por su creador o por un enemigo que pudiera haber tenido el software antes de que usted lo haya recibido.

 Una situación típica es que el software se cargue correctamente pero que alguna parte de él contenga una brecha en la seguridad que se activa cuando esa parte del programa se ejecuta. O bien el propio programa produce daño a la máquina o produce alguna modificación en el sistema de modo que un asaltante pueda entrar en él. Estos problemas no ocurren con paquetes comercialmente disponibles, pero cualquier software "sin certificación" debe ser considerado bajo sospecha. El software disponible gratuitamente a partir de boletines electrónicos o el software pirateado que circula de mano en mano es especialmente sospechoso. No se pueden detectar estos problemas hasta que se ha producido el daño, por lo que es aconsejable ser extremadamente cuidadoso al añadir software desconocido a la máquina. En el peor caso, los administradores de sistema consiente de la seguridad exigirán  acceso al código fuente de las aplicaciones examinándolas cuidadosamente en un entorno seguro y luego compilándolas directamente en la máquina destino, lo que generalmente no es posible pero en cualquier caso se puede estar alerta a comportamientos sospechosos por parte de las fuentes del software.

Redes de Area Local

            Las máquinas conectadas por medio de redes de área local (LAN) constituyen un riesgo de seguridad muy peligroso debido a que al introducirse un asaltante en cualquier máquina de la red podrá fácilmente saltar a otras máquinas, por eso es importante que los usuarios de máquinas de una red le den la suficiente importancia a las contraseñas seguras. Dichos usuarios generalmente están asociados en un único proyecto, muchas LANs tienen herramientas como NFS o rlogin que permiten fácilmente compartir ficheros y datos entre máquinas. Esto por supuesto es arriesgado, pero es aceptable si las máquinas individuales se mantienen seguras. A veces es necesario una contraseña adicional antes de volver a acceder a la red, lo que puede hacer más lento las actividades de los usuarios pero proporcionan protección adicional cuando la seguridad es una cuestión importante.

            La mayoría de las LANs permiten grupos de máquinas que pueden compartir fácilmente ficheros o presentaciones remotas. Las máquinas fuera de cualquier grupo particular tienen acceso restringido a dichos grupos  los que hacen que la seguridad de una máquina en la LAN puede estar comprometida sin corromper por ello a la LAN entera. Por ende los grupos pueden aliviar significativamente las molestias de la seguridad. Es aconsejable consultar al administrador de la red para establecer una política en cada LAN.

 

Seguridad uucp

 

            Los subsistemas de comunicaciones de datos son un gran riesgo de seguridad ya que son herramientas expresamente diseñadas para permitir el acceso remoto desde el mundo exterior cuando uucp funciona, se conecta a otra máquina y ejecuta ordenes en ella, leyendo y escribiendo ficheros cuando se solicita. Al contar con una seguridad pobre se arriesga a que un asaltante o intruso, incluso una equivocación sin malicia en el uso de uucp pueda dañar seriamente a la máquina en cambio el software de uucp moderno es muy seguro y fuerte si se toman precauciones de seguridad. La seguridad uucp se degrada con el tiempo, por eso hay que estar vigilantes en la observación de sus herramientas. El principal tema a tener en cuenta en la seguridad asociada con uucp son los permisos de los ficheros. Los ficheros del directorio /usr/lib/uucp deben mantener los permisos que tenían cuando se cargó el software en el sistema. Una buena práctica es listar éstos ficheros con Is-la tan pronto como sean cargados en la máquina y luego verificar su corrección cada vez que se cambie alguna cosa en los directorios  /usr/lib/uucp o /etc/uucp. El sistema uucp está diseñado de manera que una máquina posea jerarquía de directorios públicos donde toda actividad de uucp ocurra normalmente en dicha área pública. Además hay una lista de ordenes que pueden ser ejecutadas por una máquina remota mediante la orden uux.

            La localización del directorio público es /var/spool/uucppublic, y la lista de ordenes disponibles está formada tan solo por la orden de correo rmail. No se pueden recibir correo de máquinas remotas a menos que se permita a otras máquinas ejecutar ésta orden.

Fichero de permisos de uucp

 

            Los permisos de uucp pueden ser personalizados. Los datos de control están guardados en un fichero leído por los programas uucp cuando éstos se ejecutan. En el caso de efectuarse una petición que no es permitida por los datos de control, ésta es rehusada y la conexión uucp se rompe, en cambio si está dentro de la lista aceptable, se sirve. El fichero /etc/uuco/Permissions contiene ésta información, pero solo deberían poder leerlo el superusuario y la presentación nuucp.

            Los permisos pueden ser desde bastante abiertos hasta bastante restrictivos. El valor implícito establecido al cargarse la máquina es bastante limitado. En un fichero ASCH  normal las líneas comienzan con # y son tratadas como comentarios, y las líneas restantes contienen datos. La disposición básica es una serie de líneas que contienen parejas clave = valor, donde las palabras claves describen la capacidad de controlar y donde los valores especifican los permisos permitidos. En el caso de haber más de un valor para una clave, los items deben ir separados con " : ". Cada línea puede controlar un grupo específico de permisos determinando como actúa la máquina cuando llama a otras o como son tratadas las otras máquinas cuando son ellas las que llaman a la propia. Para acomodar el sistema uucp a necesidades concretas se utilizarán varias líneas.

Permisos Implícitos

            Recurrimos a los permisos implícitos por omisión de los "uucp" para obtener buena seguridad por medio de una entrada simple como:

LOGNAME = uucp

            Donde LOGNAME sirve para referirse a los ids de presentación que necesiten los servicios de "uucp" en las máquinas que pueden llamar a la máquina local las que se denominan remotas.

            LOGNAME = nuucp por su parte restringe el acceso remoto al sistema "uucp" al id de presentación "nuucp".

            Con el fichero Permissions se restringe el sistema "uucp" a transferencias del fichero al directorio público y desde el mismo. Solo la orden implícita "rmail" esta permitida.

 

Adaptación del fichero permissions

            Al fichero se puede agregar más líneas para adaptar a ciertas necesidades la seguridad de "uucp".

            En el archivo pueden haber dos clases de líneas: la que empieza con LOGNAME que modifica las acciones del sistema para llamadas que entran, y las que comienzan con MACHINE que modifican las acciones para conexiones con máquinas específicas a las que llama.

            Pueden existir tantas líneas MACHINE  como se necesiten a diferencia de LOGNAME que solo puede haber una.

            Al modificarlas hay que agregar parejas adicionales de clave = valor en la misma línea, en el caso de que ésta fuera demasiado larga puede continuarse con | (diagonal inversa) para escapar el caracter de nueva línea.

 

Control de llamadas de entrada con la línea logname

 

            Cuando una máquina llama a la local se permite que se le envíen los trabajos ubicados en la cola para ella o se fuerza a la máquina local a llamar a la máquina remota antes de enviarle trabajos de salida que estén en la cola destinados a ella, ésta última es más segura ya que una máquina que llame puede mentir a cerca de su "uname" y tomar ficheros no destinados a la misma. Esta mentira es denominada "spoofing" (engaño) en el sistema de "uucp", se  previene que suceda eso con la última opción.

            La palabra clave  SENDFILES= añadida a LOGNAME= sirve para controlar si los trabajos sirven o no para ser enviados cuando la máquina local sea llamada por ejemplo:

LOGNAME = nuucp     SEND FILES = yes  permitirá transferencias Y

LOGNAME = nuucp     SENDFILES = no    impedirá las mismas en todos los casos.

 

            La omisión de SENDFILES = call significa que los ficheros solamente serán enviados a otra máquina cuando sea la máquina local quien la llame y no cuando sea la máquina remota quien llame a la local. Para controlar si la máquina local permite o no a una máquina remota solicitar ficheros del sistema local se puede añadir la palabra clave REQUEST=. Por ejemplo,

 LOGNAME= nuucp   SENDFILES= yes   REQUEST= yes, esto permitirá a la máquina remota captar ficheros de la local haya o no peticiones para envío lo que puede ser muy peligroso, debería especificarse REQUEST= no.

            También es posible especificar que directorios pueden ser utilizados por máquinas remotas al leer o escribir ficheros añadiendo las palabras claves READ= y WRITE= a la entrada de LOGNAME=. El directorio que se especifique designa a una subestructura completa, de modo que cualquier directorio por debajo del designado puede ser escrito o leído. Si se utiliza READ=/ y WRITE=/, se permite la lectura y escritura de todos los directorios de la máquina.  Esto es definitivamente no recomendable. Por omisión se utiliza los valores READ=/var/spool/uucppublic, éste es el directorio público recomendable.

            Cuando haya una llamada de la máquina remota a la local se puede disponer el sistema "uucp" para rehusar la llamada pero preparar la máquina para que llame a la remota. Para forzar este comportamiento de devolución de llamada se utilizará CALLBACK= yes. Por omisión de llamada no es necesario CALLBACK= no.

 

 

Control de llamadas de salida con las líneas machine

 

            Se pueden modificar los permisos para una máquina o lista de máquinas especificadas utilizando la cadena MACHINE= al comienzo de la línea. Cualquier cambio a la lista de órdenes diferente a los valores implícitos va asociado con una máquina específica que debe ser nombrada explícitamente en la entrada MACHINE=. Si se desea que todas las máquinas que llamen tengan los mismos permisos, se puede utilizar la cadena especial OTHER a continuación de MACHINE= para referirse a todas las máquinas, o se pueden designar las máquinas específicas que se deseen. Las palabras clave REQUEST=, SENDFILES=, y WRITE= pueden aparecer en la línea MACHINE=, con el mismo significado que en la línea LOGNAME=.

            Además es posible modificar la lista de órdenes que otra máquina puede ejecutar en la máquina local, bien cuando las máquinas remotas sean llamadas o cuando sean ellas quienes ejecuten peticiones "uux" sobre la máquina local. Para cambiar las órdenes se añade la palabra clave COMMANDS= a la línea MACHINE=, seguido de la lista de órdenes separadas entre sí por dos puntos. Por ejemplo:

MACHINE=OTHER COMMANDS= rmail:news:lp

 

La orden uucheck

            La disposición del fichero Permissions puede ser verificada con la orden /usr/uucp/uucheck, que comprueba la corrección del subsistema uucp, prestando especial atención a los datos de Permissions. La orden uucheck está restringida al superusuario, ya que los permisos de uucp deberían ser mantenidos en secreto.            Para ver una explicación detallada de como están configurados los permisos de uucp, se utiliza la siguiente orden:

#/usr/lib/uucp/uucheck-v

 

la orden uucheck es una  herramienta muy útil que puede reducir sustancialmente la confusión a la hora de establecer los permisos uucp.

 

Máquinas remotas desconocidas y sondeos

 

            Si una llamada de entrada se encuentra que procede de una máquina que el sistema local no tiene registrado en sus ficheros SYSTEMS, la llamada puede ser aceptada como normal, o puede ejecutarse un guión shell por parte del sistema uucp utilizado para registrar llamadas procedentes de máquinas desconocidas, o por precauciones de seguridad similares. Esta capacidad no esta soportada en el fichero Permissions: funciona de forma un poco diferente: si el fichero /usr/lib/uucp/remote.unknown es ejecutable, la llamada de entrada procedente de una máquina remota se da por terminada y se ejecuta la orden remote.unknown: si el fichero no está presente o no ejecutable, la llamada es aceptada en la categoría MACHINE=OTHER. Normalmente la característica remote.unknown está discapacitada ya que es habitual desear recibir correo de las máquinas que pudieran tener conocimiento de la máquina local, pero a las cuales la máquina local puede no conocer. Sin embargo, cuando se sospechan brechas en la seguridad a través del sistema uucp, esta característica puede ser activada haciendo remote.unknown ejecutable.

            Además el sistema uucp puede ser configurado para sondear a otros sistemas. Esto significa que una máquina puede llamar a otro sistema y solicitar los trabajos destinados a ella. Esta característica se utiliza con frecuencia cuando una máquina no puede llamar a la máquina local por alguna razón, pero la máquina local si puede llamarla a ella. Por ejemplo: una máquina puede tener solamente soporte de llamada de entrada.

 

Ataques al sistema

Un ataque malicioso generalmente comienza con piratas que solo desean ampliar sus conocimientos a través de otro, y una clase de asaltante entrará en la máquina, curioseará por el sistema de ficheros, se aburrirá, y saldrá de él sin daños, la otra clase de asaltante sin embargo puede desear robar datos o simplemente dañar al sistema.

La forma de atacar es: el asaltante obtiene el número telefónico o modem (o LAN) a través de una red de otros asaltantes, o incluso por marcar al azar los números telefónicos, luego experimenta hasta que descubre un id de presentación desprotegido y de esta manera acceder a la máquina, entonces puede inspeccionar el fichero de contraseñas y el resto del sistema hasta que encuentra una oportunidad para cambiar su id de presentación por root.

Los ficheros del sistema son alterados, los permisos reordenados, y se añaden órdenes corrompidas al sistema para hacerlo más fácil de quebrar posteriormente, luego las conexiones de red son exploradas para localizar máquinas cercanas que atacar.

Cuando una máquina es asaltada, el asaltante produce daño tan solo por diversión, y finalmente la información de acceso será transferida a otro asaltante y el proceso comenzará de nuevoA cerca de los ataques maliciosos se puede aprender mucho:

En primer lugar la seguridad de las contraseñas es crítica para detener la entrada al principio, en segundo lugar una vez que un asaltante entra en un sistema detectar y prevenir el ataque puede ser extremadamente difícil, en tercer lugar una vez que el sistema ha sido violado es muy probable que el sistema sea atacado de nuevo y los ataques se extenderán a otras máquinas vecinas, en cuarto lugar si se toman acciones inadecuadas contra un ataque el asaltante aprenderá de los cambios efectuados y continuará superándolos.

 

Comportamiento del defensor

 

Generalmente la primera reacción ante la sospecha de un ataque a la máquina propia es negar que haya ocurrido, se puede pensar en buenas razones que explique porqué los permisos de los ficheros han sido alterados o incluso cómo se ha modificado repentinamente el fichero de contraseñas. En realidad uno casi nunca recuerda cual era el aspecto del sistema lo que el asaltante malicioso aprovechará para introducirse más profundamente en la máquina. Cuando se esté seguro de que ha ocurrido un ataque se tratará de negar su importancia, incluso cuando estén activas presentaciones desconocidas, con frecuencia se querrá contactar con los usuarios por mail o write para preguntarles porque están usando la máquina haciendo justamente lo que los asaltantes desean.

Lo siguiente sería anunciar a todos los usuarios que la máquina esta bajo ataque con esto de nuevo se ha advertido a los asaltantes que han sido descubiertos, entonces algunos pasos para mejorar la seguridad serían: cambiar las contraseñas eligiendo otras contraseñas similares a aquellas que los asaltantes puedan haber utilizado. Finalmente tras repetidos ataques se puede tomar la decisión de cancelar totalmente toda la conectividad de la máquina, lo que sirve de entrenamiento al atacante pues con el se ha advertido que se sabe que la máquina esta comprometida y se han efectuado cambios en la seguridad a un ritmo tan lento que los asaltantes pueden adelantarse a las precauciones tomadas. Los asaltantes pueden incluso plantar algún software de tipo Caballo de Troya que atrape las contraseñas cuando alguien se presente ante la máquina. Como última medida se impedirá el uso propio de la máquina.

Lo aconsejable al detectarse un ataque es no cambiar el sistema mientras se plantea la defensa, es también inadecuado un anuncio con news describiendo los cambios que se van a efectuar.

La primera acción abierta debería ser cambiar completamente el sistema: cambiar los números telefónicos de los modems, volver a cargar el software del sistema, cambiar todas las contraseñas e id de presentación y luego restablecer las conexiones uucp con las otras máquinas.

Lo más importante es que en ningún caso debería haber evidencia de que se tiene conciencia de un ataque.

 

Detección de un ataque

 

La detección de un ataque puede ser difícil al ser generalmente la mayoría de los asaltantes más experimentados que los defensores.

Los lugares claves para buscar un ataque son los cambios a los permisos en los ficheros relacionados con la seguridad o /etc/inittab, /etc/profile, los ficheros de datos de cron y los ficheros de control de la facilidad de accesos a servicios. Un cambio en el contenido de cualquiera de estos ficheros es sospechoso, especialmente en /etc/passwd, /etc/uucp/permissions, los ficheros systems de uucp y /etc/profile.

Los ficheros de registro uucp pueden proporcionar información sobre conexiones uucp inusuales con otras máquinas que puedan ser desconocidas. Los usuarios inusuales presentados en la máquina durante horas nocturnas son también sospechosos. El fichero /var/adm/sulog contiene un registro con todos los usos de la orden utilizada con frecuencia por los asaltantes.

Un asaltante experimentado puede evitar ficheros tales como sulog para suprimir sus huellas pero los permisos y la fecha de modificación de los ficheros puede revelar que fueron alterados.

La detección de un ataque puede ser un trabajo para Sherlock Holmes que es un lugar ideal para utilizar una herramienta de monitorización de seguridad.

Caballo de Troya, Virus y Gusanos

 

La forma más desagradable de ataque se produce cuando el saltante modifica la máquina sustituyendo algunas piezas claves del software por copias corruptas que permiten el acceso del mismo. Esto solo ocurre cuando se ha advertido a los asaltantes que fueron detectados y puede ser muy difícil de detectar, para ello se podrían utilizar procedimientos rutinarios de copias de seguridad y así copiar el programa corrupto en un archivo, luego al reconstruir el sistema como defensa, la tendencia será la de restaurar la copia de seguridad en vez de volver a cargar el sistema desde el principio. Generalmente eso solo restaura el programa corrupto y una vez más ayuda al asaltante a entrenarse.

Cuando se sospecha un ataque los datos de copias de seguridad no pueden ser fiables y debe tenerse cuidado al restaurar ese material. Es bueno hacer copias de seguridad sólo de los datos del usuario y no del software del sistema cuando se vuelve a cargar el sistema se debería utilizar el original, el adquirido con la máquina.

Los virus y gusanos trabajan con los mismos objetivos que los piratas pero pueden extender e infectar a otras máquinas sin la acción directa del asaltante.

El virus es un programa que se pega así mismo a una pieza existente de software, mientras que un gusano es un programa autónomo que sobrevive debido a la naturaleza  multitarea del sistema lo que generalmente los activa, es la ejecución de un programa infectado o el montaje de un disco infectado lo que puede  producir daños inmediato pero generalmente el virus espera cierto período de tiempo mientras infecta a más disquettes o a la LAN, luego de alguna fecha determinada se despertará y destruirá el sistema anfitrión. Esas fechas pueden ser extremadamente difíciles de detectar y reparar, la mejor defensa es impedirlas siendo muy precavido con las conexiones a otras máquinas y con el software que cargue.

Los unix Seguros

 

El departamento de defensa estadounidense (DOD) ha realizado una recopilación conocida con el nombre de Orange Boock, del que se definen siete niveles de seguridad organizados en cuatro clases.

Los sistemas de la clase A deben responder a criterios respecto no solo al sistema operativo, sino también a la arquitectura material de la máquina. Se trata de ordenadores diseñados a medida para las necesidades militares.

La clase B1 impone un sistema de protección jerárquico en el que cada objeto se etiqueta, como "no clasificado", "difusión restringida", "confidencial", y "secreto de defensa". Los usuarios pertenecen a categorías que tienen acceso a cierto nivel de confidencialidad.

Las clases B2 (protección estructurada), y B3 (protección por ámbitos de seguridad) son extensiones de la clase B1.

La clase C1 (protección direccional) impone al sistema operativo la protección de los datos de los usuarios (definición de un espacio de usuario), y controlar su acceso (palabra clave).

Clase C2 refuerza el control de acceso a la información: por ejemplo cada usuario tiene un perfil en el sistema. Este debe conservar un rastro de los accesos mediante un sistema auditor: acceso a los ficheros, intentos no autorizados, etc. Además todo rastro residual de un proceso o de un usuario (áreas de memoria, ficheros temporales,...) deben borrarse tras su finalización.

 

 

 

Conclusión

 

            El sistema UNIX es ahora tan bueno como la mayoría de los sistemas operativos. Las versiones de SVR4 han sido certificada en los niveles de seguridad B2 y B3 del departamento de defensa de los Estados Unidos.

Las cuestiones de seguridad son muy complejas, debido a la existencia de los subsistemas.

Todo debe estar correctamente ajustado para lograr una seguridad óptima. Se pueden adoptar pasos para impedir el acceso no autorizado.

Con el paso del tiempo, la tendencia natural de un sistema operativo complejo es la disminución de la seguridad, por ello hay que estar constantemente alerta para detectar agujeros en la seguridad y defender rápidamente el sistema.

UNIX dispone de:

Muchos modos para que los usuarios accedan al sistema, herramientas para la comunicación entre máquinas y usuarios diferentes. Actualmente hay razones para que persona no autorizadas irrumpan en el sistema computador (ej. Robo comercial de datos, etc.)

Lo importante es tratar de equilibrar la facilidad de acceso para los “amigos” y la prevención de acceso para los “enemigos”            

 

 

 

 

 

 

 

BIBLIOGRAFIA

 

El entorno de Programación UNIX. Brian W. Kernighan, Rob Pike

 

Compu Magazine N° 99. Octubre de 1.996

 

Operating Systems. M. Deitel. Segunda Edición,1.990

 

El Sistema Operativo UNIX (XEMIX). José Canosa,1998

 

Administración UNIX. Jean Luc Montagenier, 1996

 

Seguridad en UNIX. Steffen Cofin