Asegurar el acceso al SFXAdmin

Manualillo de SFX

En tanto se publica en la Web de Expania, recogemos aquí la información sobre medidas para asegurar el SFXAdmin que citamos en nuestra presentación a las 4as Jornadas de Expania:

  • CARRILLO GONZÁLEZ, J.M; GALÁN CABILLA, J.L.: ¿SFXAdmin seguro? Estudio de Campo. 4as Jornadas Expania, Universidad Carlos III de Madrid, 7 de junio).
Tal como dijimos allí, nos parece imprescindible y de obligada consulta la siguiente presentación:

Las referencias al manual se refieren a la siguiente versión:

  • SFX 3.0. System Administrator’s Guide. Ex Libris, Last Update: May 28, 2007. 72 p.
    Además esta última actualización incluye en el capitulo de seguridad un apartado sobre como cambiar el Session time-out in SFXAdmin. Para mi gusto, el tiempo fijado por defecto es muy elevado. Se puede cambiar fácilmente tocando un sólo fichero.

MUY IMPORTANTE: No debemos olvidar que, tal como señala Jason Cooper, para el caso de las contraseñas por defecto, debemos aplicar estas medidas a cada una de las instancias (global, test y locales) que queramos asegurar.

 
Evitar indización por buscadores
  • Utilización del fichero robot.txt. Se puede encontrar información en la página oficial: http://www.robotstxt.org/wc/norobots.html
  • Si no podemos crear un archivo robots.txt, o si queremos personalizar las instrucciones página por página, podemos utilizar la etiqueta HTML <meta>.Por ejemplo, la etiqueta <meta name=”robots” content=”noindex, nofollow”>, indica al robot que no debe ni indizar el documento ni seguir sus enlaces.

    Las opciones que se pueden utilizar en content son: all, index, nofollow, noindex

  • Otra opción, fácil de implementar aunque menos segura, es personalizar la etiqueta <title> de la página de autenticación sustituyendo el título estándar que utilizan todas las instalaciones y que es el que facilita la localización por buscadores.

Si habilitamos el filtrado por IPs también estamos evitando la indización por buscadores por lo que no seria tan necesario aplicar estas medidas.

 
Cambio de nombres de instancias por defecto
  • Esta opción también dificulta la localización por buscadores. Las intrucciones sobre como hacerlo se encuentran en el apartado Changing the name of an instance in the URL de SFX System Administrators Guide (págs. 15-17).

Si habilitamos el filtrado por IPs también estamos evitando la indización por buscadores por lo que no sería tan necesario aplicar esta medida.

 
Filtrado de direcciones IPs
  • Esta es una de las mejores y primeras medidas que se pueden poner en práctica. Además si habilitamos el filtrado de IPs también evitamos la indización y localización por buscadores. Por si esto fuera poco, es muy fácil de implementar pues sólo requiere tocar un fichero de la instancia que queramos configurar. La información concreta sobre configuración se encuentra en el apartado 5.1. Restricting Access to SFXAdmin de SFX System Administrators Guide (pág. 58-59).
Uso de HTTPs
  • Esta medida es un poco más difícil de implementar, pero también es de las más necesarias ya que evita el envío del username y el password en claro (sin encriptar). La información concreta sobre configuración se encuentra en: SFX System Administrators Guide (págs. 61-66).
Política de seguridad y de contraseñas
  • La primera medida que debemos poner en práctica para asegurar nuestro SFXAdmin cuando pasamos a producción es, sin duda alguna, el CAMBIO INMEDIATO DE LOS USUARIOS Y CONTRASEÑAS POR DEFECTO y su sustitución por otros con cierta fortaleza: evitar que usuario y contraseña sean iguales o guarden alguna relación, evitar palabras que se encuentren en diccionarios, uso de 6 o más caracteres, utilización de caracteres alfanumérico y signos, etc.
  • MUY IMPORTANTE: No debemos olvidar, tal como señala Jason Cooper, que debemos cambiar las contraseñas en toda las instancias (global, test y cada una de las locales)
  • La configuración de SFX no permite implantar de forma cómoda un política de contraseñas de cara a su cambio periódico o al control de su fortaleza. Las únicas opciones disponibles son las de crear nuevos usuarios y cambiar contraseñas. Deberíamos solicitar a Ex Libris el desarrollo de esto, al igual que se está haciendo en la versión 19 de Aleph (Ver SCHECTER, Moshe (2007): Staff Permissions: Acces Rights and UI Workflow. AL.GEN.002 – Ex Libris System Seminar, Potsdam, Germany. May 13-16, 2007).No obstante, como guía de una política de contraseñas escrita puede consultarse el documento Password Policy (Sans Institute, 2006): http://www.sans.org/resources/policies/Password_Policy.pdf.
  • Además, existe una falta de sincronía entre la contraseña de Pivotal y la que utiliza SFXAdmin para notificar cambios a la KB: si cambiamos la contraseña de Pivotal, nos deja de funcionar la opción KB changes via CRM. Actualmente, la única opción disponible es cambiar la contraseñas desde Unix. Para ello, quienes estamos en hosting tenemos que facilitar la nueva contraseña a Greendata. Esto es un sinsentido pues supone hacer pública nuestra contraseña.
Publicado por: J.L. Galán – BE el 11 de junio de 2007
Comentario de J.L. Galán (13 de junio de 2007): “Hemos actualizado la información para adecuarla a la última versión del SFX Administrator’s Guide, aparecida el el 28 de mayo de 2007.”