Administración de un servidor de directorio en Linux.

En este tutorial se muestra el proceso de instalación y configuración de un servidor de dirctorio en Linux, usando la base de datos OpenLdap.

ADMINISTRACIÓN DE UN SERVIDOR DE DIRECTORIO EN LINUX openldap

WSUS en Windows Server 2008

En este tutorial se explica el proceso de instalación y configuración de un servidor de actualizaciones en Windows Server 2008.
Instalación y configuración de un servidor WSUS

Entrevista de Seguridad de la Informacion

Esta es una entrevista realizada por una compañera a un experto en seguridad de la información

Integrando Squid con Ldap.

Squid

es un popular programa de software libre que implementa un servidor proxy y un dominio para caché de páginas web, publicado bajo licencia GPL. Tiene una amplia variedad de utilidades, desde acelerar un servidor web, guardando en caché peticiones repetidas a DNS y otras búsquedas para un grupo de gente que comparte recursos de la red, hasta caché de web, además de añadir seguridad filtrando el tráfico. Está especialmente diseñado para ejecutarse bajo entornos tipo Unix.

http://es.wikipedia.org/wiki/Squid_(programa)

Ldap

Son las siglas de Lightweight Directory Access Protocol (en español Protocolo Ligero de Acceso a Directorios) que hacen referencia a un protocolo a nivel de aplicación el cual permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos (aunque su sistema de almacenamiento puede ser diferente) a la que pueden realizarse consultas

http://es.wikipedia.org/wiki/LDAP

Instalación e Integración de Squid y Ldap.

*Instalar los paquetes necesarios.

* Configurar el Ldap, para especificar el nombre de dominio, el "cn" del administrador, y el password de dicho administrador.

* Creamos los usuarios en el Ldap, estos son los usuarios contra los que se va a autenticar el Squid. (En este caso usare un administrador gráfico para el Ldap, llamado Jxplorer).

* Ahora, aparte de la configuración básica de Squid (http://www2.linuxparatodos.net/web/comunidad/base-de-conocimiento/-/wiki/53931/Servidor+Proxy/maximized?p_p_auth=eBgvR2yo), debemos modificar estas lineas en su archivo de configuración, para que acepte autenticación Ldap.

* Ahora declararemos la acl necesaria para que el proxy requiera autenticación.

* Ahora solo reiniciamos el Ldap y el Squid, para que la configuración surta efecto.

/etc/init.d/squid restart

/etc/init.d/ldap restart

* Abrimos un navegador y comprobamos que la autenticación Ldap este funcionando.

* Si el usuario y la contraseña son correctos, y estaremos navegando en Internet.

* Ahora lo que haremos, sera implementar unas acl's basicas, como por ejemplo:

- Restricción por dirección IP

- Restricción por palabras

- Restricción por horario

En el archivo de palabras, solo debemos poner las palabras que queremos sean denegadas para su acceso.

Con esta configuración, lo que hará el proxy sera:

- Pedir autenticación al iniciar el navegador.

- Denegar la navegación si se encuentra fuera del horario establecido.

- Denegar el acceso a paginas que contengan esas palabras.

- Restringir la navegación al equipo que tenga la dirección IP designada.

OpenID y OAuth

Hasta el momento, la autenticación y la autorización se hacia directamente contra el servidor que alojaba la pagina web que el usuario necesitaba. Este representaba una amenaza a la seguridad de nuestros datos, ya que si un intruso informático llegaba a atacar dicho servidor, podría llevarse toda la información personal que tuviéramos almacenada en este. 

Afortunadamente se han estado investigando unos estándares de autenticación y autorización, que en síntesis se convertirían en un proceso de tres vías, ya que los agentes que intervienen en en son: el usuario, el servidor que contiene la aplicación (consumer), y el proveedor de autenticación y autorización (provider). Este esquema funciona así:

1. El usuario pide autenticarse contra el servidor de la app web.

2. El servidor web pide verificación de identidad del usuario contra el provider.

3. El provider pide verificación de identidad al usuario.

4. El usuario confirma su identidad contra el provider. (Generalmente es un clic).

5. El provider genera un Token de confirmación de identidad del usuario y se lo envia al servidor web.

6. El servidor web almacena el Token, y le permite el acceso al usuario.

En este esquema, el usuario no tendrá que generar un usuario y una contraseña para cada servicio que utilice, si no que or el contrario usara un solo token generado por los providers. En este momento hay tres providers "reconocidos": 

* Google

* Facebook

* OpenID (Por ser los creadores de este estándar).

Este estándar tiene sus ventajas y sus desventajas:

* La principal ventaja es que el usuario no tendrá que recordar varias contraseñas, y que ademas tendrá la seguridad de que su provider sera virtualmente imposible de vulnerar.

* La principal desventaja es que si el provider genera el token sin tiempo de vida (Que se pueda utilizar eternamente), y el consumer llega a ser vulnerado, se podría tener acceso a todas las cuentas del usuario.

OpenID

El sistema OpenID fue desarrollado originalmente por Brad Fitzpatrick de LiveJournal, aunque David Recordon de VeriSign, Josh Hoyt de JanRain y Dick Hardt de Sxip son ahora co-autores. Las futuras especificaciones de OpenID serán desarrolladas en una meritocracia basadas en la lista de distribución. Para apoyar la implantación de OpenID, un grupo de empresas anunció en agosto de 2006 un programa de contribuciones de desarrollo, ofreciendo 5000$ a los primeros diez proyectos de software libre que implemente total compatibilidad con OpenID.

A partir de la versión 1.1, OpenID utiliza el protocolo de búsqueda de servicios Yadis. En diciembre de 2007 vio la luz la versión 2.0 de la Autenticación OpenID³ 

La Fundación OpenID (en los Estados Unidos), así como su filial OpenID Europe, se crearon en 2007. Es una organización sin ánimo de lucro cuyo papel es la organización y el desarrollo del framework OpenID para la comunidad, así como administrar su propiedad intelectual.

A partir de la versión 2.0 de la autenticación OpenID (y en algunas de las implementaciones de OpenID 1.1), hay dos tipos de identificadores: URLs y XRIs.

Identificadores OpenID.

URLs

Hay dos formas de obtener una URL OpenId valida que pueda ser usada para registrarse en todos los sitios que soporten OpenID.

1. Primero, usar una URL existente que tu controles (como tu blog o página personal), y si sabes editar HTML podrás insertar los tags OpenID apropiados en el código siguiendo las instrucciones de las especificaciones de OpenID. Comentar que usando un subdominio podrás hacer que tu OpenID sea más fácil de escribir, pero no es necesario.
2. Segundo, registrar tu identificador OpenID con un proveedor de identidades. Estos ofrecen la posibilidad de registrar URLs (habitualmente terceros niveles de dominio) configuradas automáticamente para ser utilizadas con servicios de autenticación OpenID.

XRIs

Los XRIs son un nuevo sistema de identificación en nternet, diseñado específicamente para identidades digitales de dominio cruzado. Los XRIs son de dos formas i-nombres e i-numeros que son habitualmente registrados simultáneamente como equivalentes. Los I-nombres son reasignables (parecidos a nombres de dominio), mientras que los i-números nunca son reasignados. Cuando un i-nombre XRI es usado como un identificador OpenID, este es resuelto inmediatamente por el i-número equivalente (el elemento CanonicalID de un documento XRDS). Este i-número es el identificador OpenID almacenado por la parte confidente. De esta manera el usuario y la parte confidente están protegidos contra los cambios de identidad que podrían suceder con una URL basada en un nombre DNS reasignable.

OpenID ha recibido numerosas críticas de base relativas a problemas desde distintos ámbitos, pero en especial de seguridad y privacidad. La unificación de todas las identidades conlleva altos riesgos, unido a que el servidor de identidad conocerá todas las webs que se visiten cada día. Es más, si se comprometiera la seguridad del ordenador usuario o del servidor, toda la vida digital del usuario quedaría desprotegida.

http://openid.net/

http://es.wikipedia.org/wiki/OpenID

OAuth

Es un protocolo abierto, propuesto por Blaine Cook y Chris Messina, que permite autorización segura de un API de modo estándar y simple para aplicaciones de escritorio, móviles, y web.

Para desarrolladores de consumidores, OAuth es un método de interactuar con y publicar datos protegidos. Para desarrolladores de proveedores de servicio, OAuth proporciona a los usuarios un acceso a sus datos al mismo tiempo que protege las credenciales de su cuenta. En otras palabras, OAuth permite a un usuario del sitio A compartir su información en el sitio A (proveedor de servicio) con el sitio B (llamado consumidor) sin compartir toda su identidad.

OAuth comenzó en noviembre de 2006, cuando Blaine Cook desarrollaba la implementación de OpenID para twitter. Mientras tanto, Ma.gnolia necesitaba una solución que permitiera a sus miembros con OpenID a autorizar widgets del dashboard para acceder a su servicio. Entonces, Cook, Chris Messina y Larry Halff de Ma.gnolia se reunieron con David Recordon para discutir el uso de OpenID con las APIs de Twitter y Ma.gnolia para delegar la autenticación. Llegaron a la conclusión de que no existía ningún estándar abierto para delegar acceso a las APIs.

En abril de 2007 se creó el grupo de discusión de OAuth, para que el pequeño grupo de implementadores escribiera un borrador de propuesta para un protocolo abierto. DeWitt Clinton de Google se enteró del proyecto OAuth y se mostró interesado en apoyar el esfuerzo. El equipo terminó el borrador inicial de la especificación en julio de 2007. Eran Hammer-Lahav se unió y coordinó las diversas contribuciones a OAuth, creando una especificación más formal. El borrador definitivo Oauth Core 1.0 se publicó el 3 de Octubre de 2007.

http://oauth.net/

http://es.wikipedia.org/wiki/OAuth

Caso de Estudio: Ingeniería Social.

Toda esta historia comienza en una institución educativa, con un simple reto informático propuesto por un docente (Pedro), el cual consistía en ingresar a un servidor configurado en la nube, y de este extraer una palabra clave. Para ingresar a este servidor existían dos formas (fuerza bruta y un bug de seguridad que tenia la app WEB instalada en el). Este reto solo fue superado por una persona, la cual llamaremos "Carlos", por fuerza bruta.

Al día siguiente Pedro le explica a Carlos y a su amiga (Carla), la forma de resolver este reto informático con el método fácil (bug), aparte de esto Pedro agrega que esta información es confidencial. Pedro a su vez propone el mismo reto a un grupo de personas como parte de una "nivelación" por bajo rendimiento académico. Carlos haciendo caso omiso a la advertencia de Pedro, le explica a un grupo de amigos la forma de resolver el reto de la manera fácil (Lo que es una clara muestra de fuga de información). Esta información por medios aun desconocidos, llega a oídos de una de las personas que hace parte del grupo que tiene asignada la "nivelación", y que en este caso llamaremos "Paola".

Paola en cuestión de 15 minutos resuelve la nivelación y la entrega, en ese momento Pedro se percata que existe algo raro y comienza una investigación exhaustiva acerca de este tema, encontrando un fraude en la culminación del proceso de nivelación de Paola. De este modo sale a la luz un claro sospechoso (Carlos), por ser el único que conocía la solución a ese reto y haber divulgado información privada.

Luego de una investigación detallada se determina que Carlos no fue el que cometió el fraude, tomando una serie de decisiones: a Paola se le suspende 5 años de la institución educativa, a Carlos se le impone una tarea de ingeniería social, y a Carla se le impone un trabajo de investigación (por haber visto la fuga de información en progreso y no haberla detenido).

La tarea de ingeniería social de Carlos consiste en crear una pagina básica en PHP, que cumpla con los siguientes requisitos:

* Lo mas real posible.

* Tener un espacio para introducir una contraseña.

* Tener un botón que redireccione a otra pagina.

* La contraseña ingresada en la primer pagina, debe quedar almacenada en un archivo de texto.

* La segunda pagina debe sacar un porcentaje aleatorio que diga que tan "segura" es la contraseña introducida.

* Debe estar almacenada en un hosting gratuito para de esta manera ser accesible desde Inet.

Ademas, Carlos debe crear una trama, de tal forma que pueda capturar un mínimo de 50 contraseñas de personas diferentes, estas contraseñas solo son usadas como evidencia del trabajo realizado, y no tienen ningún valor, ya que la pagina solo almacena contraseñas (sin nombre de usuario ni pagina correspondiente)

Para esta tarea Carlos cuenta con un mes de plazo, para su realización, en muchos momentos siente que no va a ser capaz de terminar con éxito este trabajo, ya que no tiene ni idea de programación de paginas WEB, en muchos momentos intento buscar ayuda sin encontrar  nadie que le pueda dar una solución valida a sus dudas.

Dos días antes de que el plazo se cumpla, Carlos consigue programar la pagina WEB totalmente funcional, ahora el problema es alojarla en un hosting gratuito, ya que la mayoría de hosting demoran entre uno y tres días actualizando su DNS y la URL con la que cuenta es muy poco creíble.

Carlos toma la decisión de empezar su trabajo de ingeniería social con esta URL, teniendo en cuenta la clase de personas que va a "atacar", ya que sabe que una persona con un mediano conocimiento del tema no va a introducir sus contraseñas en cualquier parte, y mucho menos con una URL tan fantasiosa.

La trama que Carlos se ha inventado es realmente muy sencilla, ya que consiste en decirle a sus "victimas" que esto es un proyecto de final de semestre en su institución educativa, y que ademas necesita hacer una exposición con gráfica y cuadro de probabilidades para Pedro.

Sin embargo, Carlos en su proceso, se lleva varias sorpresas, entre las mas destacadas están:

* Una mujer que ingresa sus cuatro contraseñas a la pagina creada anteriormente, y luego le dice a que corresponden.

* Un grupo de personas que sin saber la verdad del asunto, se ponen en la tarea de ayudarle en su recolección de contraseñas.

* Una persona que estando en el mismo grupo en su institución educativa, cae en su proceso de ingeniería social.

* Una persona que estando mas adelantada en su proceso de aprendizaje, ingresa su contraseña a la pagina, y ademas ayuda en este proceso de recolección (sin saber la verdad del tema).

CONCLUSIONES.

* Antes de ayudar a cualquier persona en alguna cosa, se debe preguntar a fondo sobre el tema, ya que se puede meter en problemas sin saber.

* Cuando digan "información privada", por favor respetar la confidencialidad de esto.

* Estar bajo investigación es muy incomodo, por favor no haga motivos para ser sospechoso de algo.

* No siempre ayudar es la mejor opción, a veces debemos dejar que las personas se estrellen contra el mundo para que de esta forma puedan aprender de sus propios errores.

* Las personas son demasiado confiadas con las personas que "conocen".

* La ingeniería social es un arma de doble filo, y si no se sabe usar, podría traer complicaciones.

* Haciendo un balance de las contraseñas capturadas, nos damos cuenta que las personas cada vez están generando claves mas fáciles de deducir.

* Hacer ingeniería social es bastante fácil.