Seguridad en servidores web

Son muchas las aplicaciones que, inicialmente, se disean para trabajar en local y
por tanto con niveles muy bajos de seguridad (a veces inexistentes por completo),
que terminan siendo parte de otra con conexiones a internet o a redes externas,
donde los requerimientos de seguridad son infinitamente ms altos que en redes
locales. Estas ampliaciones sin incluir mdulos de seguridad, representan un
grave peligro para los datos, y deben mejorarse cuanto antes. Recuerda que un
ataque desde el exterior, generalmente, no se debe a que tus datos sean ms o
menos interesantes para alguien, sino al simple y fortuito hecho de que un hacker
localice tu mquina y advierta que es vulnerable. La tentacin ser irresistible...
Hay muchas formas de intentar extraer datos de un servidor web, pero para todas
ellas, salvo agujeros graves de seguridad del sistema operativo o del programa
servidor, el atacante necesita conocer un usuario vlido y su clave de acceso. Y a
eso dedicar todos sus esfuerzos. El eslabn ms dbil de la cadena son los
propios usuarios. En efecto, casi siempre que lo consiguen es debido al poco
cuidado que los usuarios autorizados tienen con sus contraseas. A nadie se le
ocurre dejar las llaves de su casa puestas en la puerta, y si las pierde, se
apresurar a cambiar la cerradura por si acaso... pero esas elementales
precauciones no se tienen cuando de accesos informticos se trata. Por qu?
misterios de la naturaleza humana.
As pues, adems de cuidar con esmero las claves de acceso, lo primero que
debemos hacer es cerrar todas las puertas que no sean necesarias del servidor. En
un servidor web lo tpico necesario suele ser el propio servicio HTTP (puerto 80),
y tal vez, el de FTP (puertos 20 y 21). Una herramienta fundamental para
conseguir esto es instalar un buen programa firewall (cortafuegos), o utilizar el
propio del sistema operativo, si lo tiene, y configurarlo de modo que no se pueda
accecer a ningn puerto que no sean los mencionados. Tampoco es mala idea
deshabilitar todos los protocolos de comunicaciones que no sean de verdad
necesarios, como el UDP, y dejar solamente el TCP. Si hay algn otro servicio
instalado, pero que no es de uso pblico, conviene restringir el acceso filtrando el
nmero IP o la direccin MAC de las tarjetas de red de las mquinas autorizadas,
y bloquear todas las dems. Si el firewall dispone de temporizador, es interesante
establecer un horario de acceso y bloqueo: Muchos ataques se producen cuando
no hay nadie en la empresa vigilando la actividad del servidor, y si no hay nadie,
es perfectamente intil tener abierto el acceso de otras mquinas de la empresa al
servidor. El nico que puede necesitar permiso de acceso todo el dia suele ser el
servidor web.

El siguiente paso ser limitar los privilegios del usuario por defecto (anonymous)
que los servidores suelen utilizar para responder a las llamadas del exterior. Este
usuario genrico solamente debe tener permisos de lectura en el rea donde
residan los datos del web, y ocasionalmente, permisos de ejecucin de ficheros
de comandos u otro tipo de ejecutables, como CGI, servlets, scripts, etc., si los
hay. En resumen, se trata de que si alguien consigue entrar en el servidor
utilizando ese usuario, no pueda conseguir con l nada distinto de lo que
conseguira operando normalmente con un navegador.
Si tu web utiliza bases de datos, que como ya se ha dicho, deberan estar en otra
mquina, NUNCA utilizes el usuario administrador, o un usuario con privilegios
altos en tus aplicaciones. Crea un usuario especfico para estos fines, que no
pertenezca al grupo de administradores, con una clave de acceso buena (por lo
menos 10 caracteres alfanumricos aleatorios), con los privilegios lo ms
restringidos posible, los justos para que permita operar a la aplicacin, y no es
buena idea que tenga permisos de borrado, como mximo de modificacin. Si
hay que borrar algo, que lo haga el administrador personalmente. Y por supuesto,
no debe tener permisos que le permitan acceder a tablas del sistema.
Por ltimo, hay que acostumbrarse a revisar peridicamente los ficheros de
"loggins" de los servidores y los del firewall, verificando que no ha habido
accesos a horas extraas, ni de mquinas desconocidas, y de vez en cuando,
comprobar que todas las polticas de seguridad que hemos programado siguen
activas, ya que lo primero que un hacker hara es deshabilitarlas.
De viaje por la red
Una vez configurados los aspectos bsicos de seguridad del servidor, nos
debemos plantear cmo se movern los datos por la red. Evidentemente, la
decisin a tomar depender del tipo de datos de que se trate. No es lo mismo
enviar un comentario a un foro, que hacer una compra con tu tarjeta de crdito.
Internet es un medio de comunicacin muy inseguro debido a la propia estructura
de la red. Los datos que viajan entre el cliente y el servidor no se envian en un
nico paquete, ni viajan directamente de una mquina a otra. Se segmentan en
pequeos paquetes que se enrutan a travs de un nmero variable de nodos hasta
que llegan a su destino. En cualquiera de ellos se puede leer su contenido,
modificarlo o destruirlo, por lo que la confidencialidad puede decirse que no
existe. Recuerda que TODO lo que se hace en internet, de una forma u otra deja
rastro. La nica "proteccin", si es que se le puede llamar as, que la red ofrece es
la enorme cantidad de informacin que se mueve por ella, lo que dificulta un
tanto capturar los datos; no es nada insalvable para un buen hacker, aunque desde
luego no con la facilidad que se ve en el cine.

Existen varias tcnicas de proteccin que pueden aplicarse cuando la naturaleza

de los datos exige una mayor seguridad. Posiblemente la ms conocida es el
protocolo SSL (Secure SocketsLayer) diseado hace ya muchos aos por
Netscape. Para utilizarlo no es necesario hacer nada especial, simplemente
habilitarlo en el servidor (el navegador ya lo detecta automticamente) instalando
un certificado digital de servidor emitido por una Autoridad Certificadora (CA).
Al activarlo en el servidor no olvidar abrir el puerto 443 (por defecto) de este
servicio en el firewall. La direccin de los servidores que utilizan SSL comienza
por https:// en lugar del tpico http. Lo que hace SSL es cifrar, con un algoritmo
distinto para cada sesin, los datos intercambiados entre el cliente y el servidor,
es decir, lo que viaja por la red no es transparente, como hace el protocolo http.
Terminada la transaccin, los datos se guardan en el servidor sin cifrar.
Aunque muy extendido, SSL es un protocolo de seguridad que fue diseado para
propsitos generales, y no es una solucin absolutamente fiable si se requiere
gran seguridad, como en el caso de cormercio electrnico con pago. Para este
tipo de transacciones se dise en 1995 el protocolo SET
(Secure Electronic Transaction) , que despus de algunas modificaciones se ha
convertido en un estndar. Una de las diferencias con SSL estriba en que los
datos, adems de viajar encriptados por la red, permanecen as tambin en el
servidor, lo que asegura ms su confidencialidad an en el caso de que el servidor
sufriera un ataque con xito.
Si no se desea encriptar la informacin (que tambin podra ser interceptada, y
con paciencia, descifrada), se puede recurrir a crear una red virtual privada o
VPN (en ingls Virtual PrivateNetwork). Esto consiste en crear una especie de
"tnel" privado directo entre las dos mquinas que establecen el dilogo, de
forma que nadie pueda interferir lo que circula por ese tnel. El problema de esta
tcnica es que el cliente tiene que instalarse una pequea aplicacin que permita
establecer esa conexin especial, y aunque no es muy complicado, para algunos
usuarios puede ser problemtico (como casi siempre que se espera alguna accin
del cliente). Adems requiere del servidor ms recursos para mantener las
conexiones activas.
Seguridad en aplicaciones web
Hasta aqu, si se ha aplicado todo lo dicho, puede parecer que ya lo tenemos todo
controlado, pero todava nos queda el ltimo eslabn de la cadena software: la
aplicacin web con la que va a trabajar el cliente. Evidentemente, si los
contenidos de la pgina son estticos, pocos problemas pueden generarse, pero si
se utilizan bases de datos, la cosa cambia. En efecto, aunque la base de datos
utilizada por la aplicacin web contenga datos sin importancia, como por ejemplo

un libro de visitas, la aplicacin har llamadas al mismo servidor donde podemos

tener bases de datos que s contienen informacin que debe ser protegida.
Dependiendo de cmo se diseen las aplicaciones web, podemos estar, sin
saberlo, dando herramientas a un posible atacante para que llegue a donde no
debe. As pues, por insignificante que pueda parecer la importancia de algunas
bases de datos, no deben utilizarse de cualquier manera, ya que indirectamente
podra utilizarse el acceso a ellas para obtener informacin relevante del servidor.
Las primeras precauciones ya se han descrito antes, recuerda: no utilices el
usuario administrador, crea un usuario con permisos muy restringidos y con una
buena clave alfanumrica, y si es posible, que no tenga permisos de borrado. Al
margen de todo esto, hay que disear la aplicacin de forma que no se le puedan
hacer preguntas maliciosas al servidor. Dependiendo del lenguaje de desarrollo
utilizado y de la base de datos, la sintaxis de las tcnicas de ataque sern
diferentes, pero basadas en los mismos principios. A continuacin veremos
algunas formas de atacar a un servidor SQL Server con una aplicacin
desarrollada en ASP.