Como ya vimos en el anterior post, lo primero que deberíamos hacer al instalar un apache es ocultar cierta información que podría ser usada para ponérselo más fácil a algún malintencionado para que nos ataque. Como bien se dijo en los comentarios, esto no proporciona seguridad en si mismo, si no que dificulta (un poco) un posible ataque.

Otro factor que creemos que debería tenerse en cuenta, sin entrar todavía en la protección activa, es el de ajustar la configuración según el uso se va a dar a la aplicación web que apache va a servir. Pasemos a describir los métodos mas esenciales que debemos tener en cuenta.

El objetivo de esta entrada es mostrar una manera de hacer un poco más seguro el acceso a una aplicación web (login) si ésta no dispone de SSL (HTTPS). Para los que son duchos en la seguridad, puede que esto les pueda parecer simple, e incluso obvio, pero en muchas empresas de desarrollo de páginas web, ni se plantean lo peligroso que puede llegar a ser el envío de credenciales en claro a través de Internet.

Un problema que nos encontramos los que nos dedicamos al desarrollo de software, y en concreto de páginas web, suele ser que el cliente no quiere (o no puede) pagar un certificado de servidor para su portal. Lo que tampoco queremos es que nuestras contraseñas vayan por la red en claro, siendo vulnerables a cualquiera que ande “esnifando” por la red. Supongo que existen varias soluciones a este problema, yo os voy a contar una que no es solución y otra que es un poco mejor (en temas de seguridad nunca me atrevería a decir que es infalible, porque creo que nada lo es). Para los ejemplos voy a usar como usuario a bob y como contraseña bob123.

Este es el primer post de una serie elaborada por José Luis Chica y Guillermo Mir. En ésta se quieren recoger los pasos que se pueden realizar (en muchos casos creemos debería ser imperativo realizar) para instalar y securizar un servidor Apache. Existen múltiples entradas y páginas que explican, de manera separada, como realizar diversas tareas, pero nosotros nos hemos propuesto exponerlas todas en esta serie, de manera que puedan servir de guía a todos aquellas personas que se han de instalar o gestionar un servidor de estas características. El sistema operativo que vamos a usar en los ejemplos es un Linux con distribución Debian Squeeze (6), pero esto sólo va a influir en las rutas dónde se encuentran los distintos ficheros de configuración.

Primer paso: Ocultando información

Una instalación por defecto de Apache muestra cierta información relacionada con el entorno donde ha sido desplegado. Dependiendo del sistema operativo, esta información puede variar pero en general, un posible atacante puede recopilar datos muy útiles que le puedan aportar vectores de ataque adicionales. Así pues, solo tendría que comprobar si existen vulnerabilidades conocidas en las versiones de las tecnologías utilizadas.

En uno de los últimos portales web que he tenido que desarrollar una de las principales premisas era que tenía que ser muy seguro. El nuevo portal tenía que suplir a una versión hecha en html puro, sin código en el servidor. ¿Para qué cambiar si la versión anterior ya era segura? Tampoco entraré en más detalles pero, ¿os acordáis de esas “bonitas” webs con montones de gifs animados y colores espartanos? Esas páginas eran bonitas al lado de esta. Al grano. Para el desarrollo del nuevo portal se estuvieron haciendo pruebas con varios CMS (Gestores de contenidos) en PHP. ¿Por qué en PHP? Pues porque los recursos del servidor eran limitados, y porque me gusta. Al final nos decantamos por Drupal, ya que ofrecía a priori una robustez y seguridad que otros no. ¡Ah!, y porque me gusta.

Una vez tenía el portal ya bastante terminado, me puse a indagar como podía añadirle más seguridad. Al final, en todos los gestores terminas instalando una infinidad de “plugins” (módulos) hechos por terceros que, aunque sea una comunidad muy rápida en resolver los problemas de seguridad, siempre existe cierto riesgo. Fue entonces cuando di con un módulo de Drupal llamado PHPIDS. El módulo actúa de “envoltorio” del programa PHPIDS.

Siguiendo con los filtros de acción en .NET, y partiendo de la base de lo que se hizo en el post anterior, esta vez voy a mostrar cómo crear un filtro de acción propio. No es el motivo de este post explicar cómo gestiona Visual Studio las clases y la base de datos de autenticación, así que se usará el sistema que viene por defecto para la demostración.

Si recordáis el estado del programa al finalizar el pasado post, añadimos el filtro [Authorize] en el controlador de la página principal, en la función de About, de manera que al tratar de ver esta página, la aplicación nos redirigía a la página de LogOn. El siguiente paso sería crear dos usuarios distintos en la aplicación. Al primero le voy a llamar ‘pedro’ y al segundo ‘juan’. El filtro va a permitir únicamente a ‘juan’ ver la sección “About”. Así pues, manos a la obra.

Hace ya algún tiempo, antes que la vida me llevara por estos lares en los que resido, solía realizar mis “creaciones” con un programita que algunos conoceréis y otros no, llamado Microsoft Visual Studio. Sí, habéis leído bien, Microsoft. Adorado y odiado a partes iguales, hay que reconocerle que esta gente es muy buena en muchas cosas (opinión personal, y con esto no quiero decir que el resto no lo sea), y hace fácil el desarrollo de aplicaciones para su plataforma. No es el motivo del post hacer publicidad de este producto, lo que quiero mostraros es lo fácil que pueden resultar algunas tareas gracias a este entorno (del que existe versión gratuita y con la que he realizado este ejemplo).

Lo primero, he descargado una aplicación llamada “Microsoft Web Platform Installer”, que es un gestor de descargas de software. Si realmente queréis probar lo que voy a tratar de exponer, sólo tenéis que ir a http://www.asp.net/get-started y seguir las instrucciones para instalar el “Microsoft Visual Web Developer Express” y el Framework “ASP.NET MVC 3” con el que realizaré este ejemplo. Como veis, voy a usar el patrón de diseño MVC con el Framework que Microsoft proporciona.

Brevísimo resumen del HTML

Corria el año 1995 cuando un organismo llamado IETF (Internet Engineering Task Force), logró organizar a un grupo de trabajo con el fin de publicar un estándar para un lenguaje de marcado, inventado por Tim Berners-Lee años antes. Fue el 22 de septiembre de ese año cuando vio la luz el primer estándar del, hoy ya famoso, HTML. Curiosamente, a esta primera revisión oficial del lenguaje, se la denominó HTML 2.0.

Un año más tarde, HTML “cambió de manos” y paso a ser la W3C (World Wide Web Consortium), la encargada de los nuevos estándares.

El 24 de Abril de 1998 se publicó una versión corregida, de una publicación original del 18 de Diciembre de 1997, llamada HTML 4.0. Esta supuso un gran salto desde las versiones anteriores. Entre sus novedades más destacadas se encontraban las hojas de estilos CSS, la posibilidad de incluir pequeños programas o scripts en las páginas web, mejora de la accesibilidad, tablas complejas y mejoras en los formularios.

A partir de ahí, y hasta la salida del HTML5, se han ido realizando modificaciones y revisiones del estándar, convirtiendo la web en lo que conocemos hoy en día, como dice Oscar Campos (genbetadev.com): “Hoy en día, la web es un sitio maravilloso donde procrastinar como campeones y navegar como jamás Chanquete lo hubiera siquiera imaginado.”

Hace ya varios años, cuando aún estaba estudiando en la facultad, me surgió la oportunidad de ejercer de moderador en una “asignatura” sobre las Ingenierías (y más concretamente, la informática) en el cine. Cada sesión se componía de dos partes: el visionado de una película y un debate posterior. Lo primero que tuve que hacer fue “documentarme” un poquillo, para decidir que películas podían ser interesantes, y que se podía sacar de ellas.

Esta claro que hoy en día no hace falta ver una película que hable de informática para ver el uso de ordenadores en ella, y se podría perdonar la falta de rigurosidad que estas pudieran tener. Lo triste es ver que en las películas en las que la informática forma parte de la trama principal, es las en las que más barbaridades se llegan a ver.