Detección

La mayoría de problemas de seguridad en sistemas de I+D implican accesos no autorizados, bien por usuarios externos a la máquina o bien por usuarios internos que consiguen un privilegio mayor del que tienen asignado. >Cómo detectar estos problemas? Hacer esto puede ser algo muy complicado si el atacante es un pirata con cierta experiencia y no hemos tomado algunas medidas en nuestro sistema antes de que el ataque se produzca. Aquí se presentan unos mecanismos que pueden indicar que alguien ha accedido ilegalmente a nuestro equipo.

• Logs
  Casi cualquier actividad dentro del sistema es susceptible de ser monitorizada en mayor o menor medida. Unix ofrece un estupendo sistema de logs que guarda información en ficheros contenidos generalmente en /var/adm/, /var/log/ o /usr/adm/; esta información varía desde los usuarios que han conectado al sistema últimamente hasta los mensajes de error del núcleo, y puede ser consultada con órdenes como who o last, o con un simple editor de textos.
  Aunque un atacante que consiga privilegios de root en el equipo puede modificar (<o borrar!) estos archivosA.3, los logs son con frecuencia el primer indicador de un acceso no autorizado o de un intento del mismo. Dependiendo de nuestra configuración (/etc/syslog.conf), pero generalmente en los archivos messages o syslog, podemos ver mensajes que pueden indicar un ataque al sistema; a continuación se presentan algunos de ellos:
  • Nov 12 05:35:42 anita in.telnetd[516]: refused connect from bg.microsoft.com
    Este mensaje (conexión rehusada a un servicio) en sistemas con TCP-Wrappers instalado indica que alguien ha intentado conectar a nuestro equipo desde una máquina no autorizada a hacerlo.
  • Nov 7 23:06:22 anita in.telnetd[2557]: connect from localhost
    Alguien ha conectado con éxito a nuestro equipo desde una determinada máquina; no implica que haya accedido con una nombre de usuario y su contraseña, simplemente que ha tenido posibilidad de hacerlo.
  • SU 11/17 03:12 - pts/3 toni-root
    El usuario toni ha intentado conseguir privilegios de administrador mediante la orden su; si lo hubiera conseguido, en lugar de un signo `-' aparecería un `+'. En Solaris, esto se registra en el fichero sulog, aunque en el fichero messages se notifica si el su ha fallado.
• Procesos
  Si un atacante ha conseguido acceso a nuestro equipo, y dependiendo de sus intenciones, es probable que ejecute programas en el sistema que permanecen en la tabla de procesos durante un largo periodo de tiempo; típicos ejemplos son sniffers (programas para capturar tráfico de red) o bouncers (programas para ocultar una dirección en IRC). Debemos desconfiar de procesos que presenten un tiempo de ejecución elevado, especialmente si no es lo habitual en nuestro sistema. Incluso si el nombre del proceso no es nada extraño (obviamente un pirata no va a llamar a su analizador de tráfico sniffer, sino que le dará un nombre que no levante sospechas, como xzip o ltelnet) es muy conveniente que nos preocupemos de comprobar cuál es el programa que se está ejecutando.
  Algo que nos puede ayudar mucho en esta tarea es la herramienta de seguridad lsof, que nos indica los ficheros abiertos por cada proceso de nuestro sistema, ya que programas como los sniffers o los crackers de claves suelen mantener archivos abiertos para almacenar la información generada.
• Sistemas de ficheros
  Otro punto que puede denotar actividades sospechosas en la máquina es su sistema de ficheros:
  Por un lado, hemos de estar atentos al número de archivos setuidados en el sistema: es frecuente que un pirata que ha conseguido privilegios de root guarde archivos con este bit activo para volver a conseguir esos privilegios de una forma más sencilla (por ejemplo, una copia de un shell setuidado como root dará privilegios de administrador a cualquiera que lo ejecute).
  Además, los intrusos suelen crear directorios `difíciles' de localizar, donde poder guardar herramientas de ataque: por ejemplo, si alguien es capaz de crear el directorio /dev/.../, seguramente cuando el administrador haga un listado de /dev/ ni se dará cuenta de la existencia de un directorio con un nombre tan poco común como `...'.
  Otra actividad relacionada con el sistema de ficheros es la sustitución de ciertos programas que puedan delatar una presencia extraña, como ps, who o last, o programas críticos como /bin/login por versiones `troyanizadas' que no muestren nada relacionado con el atacante; por ejemplo, alguien podría sustituir el programa /bin/login por otro que aparentemente se comporte igual, pero que al recibir un nombre de usuario concreto otorgue acceso al sistema sin necesidad de clave. Un ejemplo muy simple de este tipo de troyanos es el siguiente: alguien mueve el archivo /bin/ps a /bin/OLDps y a continuación ejecutaanita:~# cat >/bin/ps #!/bin/sh /bin/OLDps $1|grep -v '^ toni'|grep -v grep|grep -v OLD ^D anita:~# A partir de ahora, cuando alguien teclee ps -ef no verá los procesos del usuario toni. Se puede seguir un mecanismo similarA.4 con programas como w, finger, last, who o ls para conseguir ocultar a un usuario conectado, sus procesos, sus ficheros...
  Otro síntoma que denota la presencia de un problema de seguridad puede ser la modificación de ciertos ficheros importantes del sistema; por ejemplo, un atacante puede modificar /etc/syslog.conf para que no se registren ciertos mensajes en los archivos de log, o /etc/exports para exportar directorios de nuestro equipo. El problema de este estilo más frecuente es la generación de nuevas entradas en el fichero de claves con UID 0 (lo que implica un total privilegio); para detectar este tipo de entradas, se puede utilizar la siguiente orden: anita:~# awk -F: '$3

  "0" {print $1}' /etc/passwd root anita:~# Obviamente, si como salida de la orden anterior obtenemos algún otro nombre de usuario, aparte del root, sería conveniente cancelar la cuenta de ese usuario e investigar por qué aparece con UID 0.
  Detectar este tipo de problemas con el sistema de ficheros de nuestro equipo puede ser una tarea complicada; la solución más rápida pasa por instalar Tripwire, comentado en este mismo punto.

• Directorios de usuarios
  Dentro del sistema de ficheros existen unos directorios especialmente conflictivos: se trata de los $HOME de los usuarios. La conflictividad de estos directorios radica principalmente en que es la zona más importante del sistema de archivos donde los usuarios van a tener permiso de escritura, por lo que su control (por ejemplo, utilizando Tripwire) es a priori más difícil que el de directorios cuyo contenido no cambie tan frecuentemente. Algunos elementos dentro de estos directorios que pueden denotar una intrusión son los siguientes:
  • Hemos de chequear el grupo y propietario de cada archivo para comprobar que no pertenecen a usuarios privilegiados en lugar de a usuarios normales, o a grupos especiales en lugar de a grupos genéricos (users, staff...). Por ejemplo, si el padre de los directorios de usuario es /export/home/, podemos buscar dentro de él ficheros que pertenezcan al administrador con la ordenanita:~# find /export/home/ -user root -type f -print
  • >Hay archivos setuidados o setgidados en los directorios de usuario? No debería, por lo que su existencia es algo bastante sospechoso...
  • La existencia de código fuente, generalmente C, de exploits (programas que aprovechan un fallo de seguridad en el software para utilizarlo en beneficio del atacante) puede ser indicativo de una contraseña robada, o de un usuario intentando conseguir un privilegio mayor en el sistema. >Cómo saber si un código es un exploit o una práctica de un alumno? La respuesta es obvia: leyéndolo. >Y si se trata de ficheros ejecutables en lugar de código fuente? man strings.
• El sistema de red
  Estar atentos al sistema de red de nuestro equipo también nos puede proporcionar indicios de accesos no autorizados o de otro tipo de ataques contra el sistema. Por ejemplo, si utilizamos netstat para comprobar las conexiones activas, y detectamos una entrada similar a anita.telnet luisa.2039 16060 0 10136 0 ESTABLISHED esto indica que desde el host luisa alguien está conectado a nuestro sistema mediante telnet; puede haber accedido o no (si ha tecleado un nombre de usuario y la contraseña correcta), pero el hecho es que la conexión está establecida.
  Otro método muy seguido por los piratas es asegurar la reentrada al sistema en caso de ser descubiertos, por ejemplo instalando un programa que espere conexiones en un cierto puerto y que proporcione un shell sin necesidad de login y password (o con los mismos predeterminados); por ejemplo, si el programa espera peticiones en el puerto 99, el atacante puede acceder al sistema con un simple telnet:luisa:~# telnet anita 99 Trying 192.168.0.3... Connected to anita. Escape character is '^]'. Sun Microsystems Inc. SunOS 5.7 Generic October 1998 anita:~# Podemos detectar los puertos que esperan una conexión en nuestro sistema también con la orden netstat: anita:~# netstat -P tcp -f inet -a|grep LISTEN *.sunrpc *.* 0 0 0 0 LISTEN *.32771 *.* 0 0 0 0 LISTEN *.ftp *.* 0 0 0 0 LISTEN *.telnet *.* 0 0 0 0 LISTEN *.finger *.* 0 0 0 0 LISTEN *.dtspc *.* 0 0 0 0 LISTEN *.lockd *.* 0 0 0 0 LISTEN *.smtp *.* 0 0 0 0 LISTEN *.8888 *.* 0 0 0 0 LISTEN *.32772 *.* 0 0 0 0 LISTEN *.32773 *.* 0 0 0 0 LISTEN *.32774 *.* 0 0 0 0 LISTEN *.printer *.* 0 0 0 0 LISTEN *.listen *.* 0 0 0 0 LISTEN *.6000 *.* 0 0 0 0 LISTEN *.32775 *.* 0 0 0 0 LISTEN anita:~#
• Tripwire
  Quizás una de las formas más efectivas de detectar accesos no autorizados es mediante el programa Tripwire. La idea es sencilla: en un sistema `limpio' (por ejemplo, recién instalado, antes de ser conectado a red) se aplica una función de resumen (message digest) sobre los ficheros importantes del equipo, (por ejemplo, ficheros en /etc/, /bin/ o /sbin/). Los resultados de este proceso se almacenan en un medio que a partir de ese momento será de sólo lectura, como un disco flexible protegido contra escritura o un CD-ROM, y periódicamente volvemos a aplicar el resumen sobre los ficheros de nuestro equipo; si se detecta un cambio (por ejemplo, una variación en el tamaño, un cambio de propietario, la desaparición de un archivo...), Tripwire nos lo va a indicar. Si no lo hemos realizado nosotros, como administradores, es posible (muy posible) que ese fichero haya sido modificado en beneficio propio por un intruso.

Recuperación

>Qué hacer cuando se detecta una intrusión en la máquina? Muchos administradores se hacen esta pregunta cuando se dan cuenta de que su seguridad ha sido quebrada. Por supuesto, en esta situación se pueden hacer muchas cosas, desde ignorar el hecho y dejar que el pirata haga lo que quiera en nuestro sistema (obviamente, esto no es recomendable) hasta intentar localizar al intruso mediante denuncia y orden judicial para tracear la llamada; esto tampoco es habitual, ya que es muy difícil demostrar ante un juez que un atacante ha violado nuestra seguridad, por lo que sólo vamos a perder tiempo y dinero. Lo habitual en entornos universitarios es intentar detectar si el atacante pertenece a la comunidad universitaria (en cuyo caso se le puede sancionar), restaurar la integridad del equipo de forma que un ataque similar no vuelva a tener éxito, y poner de nuevo la máquina a trabajar (recordemos que la disponibilidad suele ser lo más importante en organizaciones de I+D). Pero, hagamos lo que hagamos, hay que cumplir una norma básica: no ponernos nerviosos; si no logramos mantener la calma podemos ser incluso más perjudiciales para el sistema que el propio intruso o podemos poner a éste nervioso, lo que puede convertir un simple fisgoneo en una pérdida irrecuperable de datos.

---

Desde el punto de vista de Unix, es posible que nos interese localizar el fallo de seguridad aprovechado por el pirata para cerrarlo y que el problema no vuelva a ocurrir; sin entrar en temas complejos como el jailing o la simulación, una de las formas que tenemos para realizar esta tarea es monitorizar las actividades del intruso, incluso arriesgando la integridad del sistema (podemos hacer una copia de seguridad por lo que pueda pasar). Para realizar esto, hemos de ser conscientes de que si alguien ha conseguido privilegios de administrador en la máquina, puede haber modificado desde los programas del sistema hasta las librerías dinámicas, pasando incluso por el subsistema de accounting de procesos. Por tanto, hemos de desconfiar de los resultados que cualquier orden nos proporcione, ya que el intruso puede haberlos modificado para ocultar sus actividades. Si queremos auditar las actividades del atacante hemos de utilizar programas `nuevos', a ser posible compilados estáticamente (sin dependencia de librerías dinámicas): podemos utilizar versiones de código fuente disponible para adecuarlas a nuestro sistema, compilarlas estáticamente en un sistema similar al atacadoA.5, y utilizarlas en la máquina donde está el intruso.

---

El proceso de modificar librerías dinámicas habitualmente excede los conocimientos del atacante medio de entornos I+D; como además conseguir programas estáticos para nuestro equipo suele ser complejo y lento en la mayoría de situaciones, y un objetivo básico es devolver el sistema a su funcionamiento normal cuanto antes, lo habitual no es utilizar programas compilados de forma estática sino confiar en que el intruso no haya modificado librerías dinámicas y utilizar versiones `limpias' de programas dinámicos; por ejemplo, podemos utilizar los programas originales del sistema operativo que se encuentran en el CD-ROM de instalación del mismo.

---

Si en lugar de intentar monitorizar las actividades del intruso en el sistema lo único que queremos es echarlo de nuestra máquina (esto tiene su parte positiva, pero también su parte negativa), hemos de tener siempre presente que desconocemos lo que ha hecho; la forma más efectiva de tirarlo de nuestro equipo es desconectando el cable de red (mucho mejor que utilizar ifconfig para detener la tarjeta o shutdown para parar el sistema, ya que el atacante puede haber contaminado estos programas para que realicen una actividad diferente a la que en teoría están destinados). Pero no nos podemos limitar únicamente a desconectar el cable de red: el atacante puede tener procesos activos en el sistema, bombas lógicas, o simplemente tareas destructivas planificadas con at o cron; hemos de chequear todo el sistema en busca de este tipo de amenazas. Un lugar interesante donde el intruso nos puede causar un problema grave es en los ficheros de inicialización de la máquina, situados generalmente en /etc/rc?.d/ o /etc/rc.d/.

---

Una vez detectado y solucionado el problema de seguridad hemos de restaurar un estado fiable de la máquina, esto es, un estado similar al que tenía antes de ser atacada. Aunque en muchos lugares se indica restaurar una copia de seguridad anterior al ataque, esto presenta graves problemas: realmente no sabemos con certeza cuando se produjo el ataque al sistema, sino que en todo caso sabemos cuándo se detectó el mismo, por lo que corremos el peligro de utilizar una copia de seguridad que ya esté contaminada por el atacante. Es mucho más seguro reinstalar el sistema completo y actualizarlo para solucionar los fallos que posibilitaron la entrada del intruso, por ejemplo aplicando patches sobre la versión que hemos instalado.

---

Restaurar y actualizar el sistema operativo y sus programas puede ser una tarea pesada, pero no implica ninguna complicación: con toda probabilidad tenemos a nuestra disposición los CD-ROMs con el software que hemos de instalar; los problemas reales surgen con los archivos de los usuarios: evidentemente, no podemos decirles que para evitar posibles conflictos de seguridad se les han borrado sus archivos, sino que lo habitual va a ser mantener el estado de sus ficheros justo como estaban durante el ataque o, en caso de que este haya eliminado o corrompido información, tal y como estaban exactamente antes del ataque. Por tanto, especialmente si mantenemos el estado de los ficheros de usuario, hay que estar atentos a posibles problemas que estos puedan introducir en el sistema, comentados en el apartado A.3.

Recomendaciones de seguridad para los usuarios

Con frecuencia la parte más complicada de una política de seguridad es concienciar a los usuarios de la necesidad de medidas básicas de prevención contra ataques. Demasiados usuarios opinan que las historias de crackers que atacan ordenadores sólo suceden en las películas o en organizaciones militares de alta seguridad; nada más lejos de la realidad: en cualquier universidad ocurren a diario incidentes de seguridad, de los que sólo una pequeña parte se detecta (y muchos menos se solucionan). Sería pues muy recomendable para el administrador imprimir una hoja con las medidas de seguridad básicas o la política del sistema, y entregar una copia a cada usuario al crear su cuenta.

• Contraseñas aceptables
  Es conveniente que los usuarios elijan claves medianamente resistentes a ataques de diccionario; una contraseña como patata o valencia es un gran agujero de seguridad para la máquina, aunque el usuario que la usa no tenga ningún privilegio especial. Hemos de ver la seguridad como una cadena cuya fuerza depende principalmente del eslabón más débil: si falla éste, falla toda la cadena. Sin embargo, el problema de estas claves es que pueden llegar a ser difíciles de recordar, de forma que mucha gente opta por apuntarlas en el monitor de su estación o en la parte inferior de sus teclados; obviamente, esto es casi peor que el problema inicial, ya que como administradores no podemos controlar estas situaciones la mayor parte de las veces. Podemos (y sería lo recomendable) recomendar a los usuarios que utilicen combinaciones de mayúsculas, minúsculas, números y símbolos para generar sus claves, pero de forma que la combinación les pueda resultar familiar: por ejemplo, combinar números y letras de la matrícula del coche con algunos símbolos de separación; claves de este estilo podrían ser V#GF&121, @3289?DH o JKnB0322. Obviamente estas claves son más resistentes a un ataque que beatles, pero tampoco son seguras: las acabamos de escribir.
• Confidencialidad de las claves
  Hemos de concienciar a nuestros usuarios de que las contraseñas no se comparten: no es recomendable `prestar' su clave a otras personas, ajenas o no al sistema, ni por supuesto utilizar la misma clave para diferentes máquinas. Este último punto muchas veces se olvida en sistemas de I+D, donde el usuario se ve obligado a utilizar passwords para muchas actividades y tiende invariablemente a usar la misma contraseña; incluso se utiliza la clave de acceso a un equipo Unix para autenticarse en juegos de red (MUDs o IRC) o, lo que es igual de grave, para acceder a equipos Windows, de forma que las vulnerabilidades de seguridad de estos sistemas se trasladan a Unix.
• Conexiones cifradas
  Hay que potenciar entre los usuarios el uso de programas como ssh/scp o
  ssl-telnet/ssl-ftp para conectar al equipo. La parte cliente de estos programas es muy simple de utilizar, y nos puede ahorrar muchos dolores de cabeza como administradores. Incluso existen clientes para Windows y MacOS, por lo que nadie tiene excusa para no usar sistemas cifrados (se puede conseguir que su uso sea completamente transparente al usuario); casi la mejor forma de que los usuarios los utilicen es dejando de ofrecer ciertos servicios sin cifra, como telnet, ftp, rlogin o rsh.
• Ejecución de programas
  Nunca, bajo ningún concepto, instalar o ejecutar software que no provenga de fuentes fiables; hay que prestar atención especial a programas que nos envíen por correo o por IRC, ya que se puede tratar de programas trampa que, desde borrar todos nuestros ficheros, a enviar por correo una copia del archivo de contraseñas, pueden hacer cualquier cosa: imaginemos que un `amigo' nos envía un juego a través de cualquier medio - especialmente IRC - y nosotros lo ejecutamos; incluso disponer del código fuente no es ninguna garantía (>qué usuario medio lee un código en C de, quizás, miles de líneas?). Ese programa puede hacer algo tan simple como rm -rf $HOME/* sin que nosotros nos demos cuenta, con las consecuencias que esta orden implica.
• Desconfianza
  Hemos de desconfiar de cualquier correo electrónico, llamada telefónica o mensaje de otro tipo que nos indique realizar una determinada actividad en el sistema, especialmente cambiar la clave o ejecutar cierta orden; con frecuencia, un usuario se convierte en cómplice involuntario de un atacante: imaginemos que recibimos una llamada de alguien que dice ser el administrador del sistema y que nos recomienda cambiar nuestra clave por otra que él nos facilita, con la excusa de comprobar el funcionamiento del nuevo software de correo. Si hacemos esto, esa persona ya tiene nuestra contraseña para acceder ilegalmente a la máquina y hacer allí lo que quiera; hemos de recordar siempre que el administrador no necesita nuestra ayuda para comprobar nada, y si necesita cambiar nuestra clave, lo puede hacer él mismo.
• Un último consejo...
  Cualquier actividad sospechosa que detectemos, aunque no nos implique directamente a nosotros, ha de ser notificada al administrador o responsable de seguridad del equipo. Esta notificación, a ser posible, no se ha de realizar por correo electrónico (un atacante puede eliminar ese mail), sino en persona o por teléfono.
  En muchas ocasiones, cuando un usuario nota un comportamiento extraño en el sistema, no notifica nada pensando que el administrador ya se ha enterado del suceso, o por miedo a quedar en ridículo (quizás que lo que nosotros consideramos `extraño' resulta ser algo completamente normal); esta situación es errónea: si se trata de una falsa alarma, mucho mejor, pero...>y si no lo es?

Referencias rápidas

Prevención

• Cerrar los servicios de inetd que no sean estrictamente necesarios.
• No lanzar demonios en el arranque de máquina que no sean estrictamente necesarios.
• Minimizar el número de ficheros setuidados o setgidados en la máquina.
• Instalar TCP Wrappers y utilizar una política restrictiva: echo ALL:ALL >/etc/hosts.deny.
• Utilizar TCP Wrappers para controlar el acceso a nuestro sendmail, o utilizar un wrapper propio para este demonio.
• Sustituir telnet, ftp o similares por ssh y scp.
• No permitir ficheros $HOME/.rhosts en los directorios de usuarios, y no establecer relaciones de confianza en /etc/hosts.equiv.
• Deshabilitar las cuentas del sistema que no corresponden a usuarios reales (uucp, lp...).
• Instalar un sistema Shadow Password para que los usuarios no puedan leer las claves cifradas.
• Deshabilitar las cuentas de usuarios que no conecten al sistema.
• Utilizar versiones actualizadas del núcleo del sistema operativo.
• Evitar sobrecargas de servicio planificando pkill -HUP inetd en nuestro fichero crontab.

Detección

• Configurar Tripwire nada más instalar el sistema y guardar sus resultados en un medio fiable; cada cierto tiempo, ejecutar Tripwire para comparar sus resultados con los iniciales.
• Chequear periódicamente los logs en busca de actividades sospechosas.
• Utilizar órdenes como ps, netstat o last para detectar cualquier evento fuera de lo normal en el sistema, pero no confiar ciegamente en los resultados que se nos muestran en pantalla: seamos paranoicos.
• Comprobar periódicamente la integridad de ficheros importantes de nuestro sistema, como /etc/passwd, /etc/exports, /etc/syslog.conf, /etc/aliases o ficheros de arranque.
• Comprobar también elementos como los permisos o el propietario de los ficheros que se encuentran en los directorios de usuarios.

Recuperación

• Nunca hay que ponerse nervioso: nuestra máquina ni ha sido la primera ni lamentablemente será la última en sufrir un ataque. No es el fin del mundo.
• Desconfiar de cualquier programa que se encuentre en el sistema; utilizar programas del CD-ROM del sistema operativo, o versiones estáticas de los mismos, para tracear las actividades del intruso.
• Si es posible, reinstalar el sistema operativo completo y aplicarle los parches de seguridad que el fabricante pone a nuestra disposiciónA.6; permanecer atentos a los directorios de usuarios y a los programas que éstos contienen.
• Si pensamos que la integridad del sistema peligra mucho, desconectar directamente el cable de red: utilizar ifconfig down o detener el sistema con shutdown puede incluso acarrearnos problemas.
• Obviamente, antes de poner el sistema de nuevo a funcionar en red, estar completamente seguro que los problemas de seguridad que el atacante aprovechó están solucionados.

Usuarios

• No elegir claves de menos de seis caracteres, y combinar mayúsculas, minúsculas, números, signos de puntuación...cualquier cosa que nos permita el teclado.
• No apuntar nuestras claves ni compartirlas con otras personas.
• No utilizar nuestra contraseña de acceso en otros sistemas, especialmente juegos en red o equipos Windows.
• Sustituir telnet y ftp por ssh y scp o similares.
• Nunca ejecutar programas que nos envien por correo o que consigamos a partir de fuentes poco fiables (como un `amigo' que nos pasa un programa por IRC). Tampoco ejecutar órdenes cuyo funcionamiento desconocemos, especialmente si alguien desconocido nos indica teclear `algo' para ver el resultado.
• Desconfiar de llamadas telefónicas o correo electrónico que nos incita a realizar cualquier actividad dentro del sistema, especialmente cambiar nuestra clave; si estas situaciones se producen, indicarlo inmediatamente al responsable de seguridad del equipo, mediante teléfono o en persona.
• Ante cualquier actividad sospechosa que se detecte es recomendable ponerse en contacto con el responsable de seguridad o el administrador, a ser posible por teléfono o en persona.