Generales sobre seguridad de servidores web y bases de datos

Un ataque malintencionado a un servidor web o a una base de datos son un tremendo dolor de cabeza para las compañía, los desarrolladores y por supuesto los administradores de sistemas. En la mayoría de los casos los ataques son realizados tomando ventajas de vulnerabilidades que se nos han pasado por alto, y cuando descubrimos que se pudo preveer nos pesa aún más. No siempre la mejor seguridad es la que va de la mano con costosos equipos, podemos crear nuestro muro de seguridad con herramientras open source y seguimiento constante, es por eso que voy a tratar algunos puntos básicos y otros no tan básicos en la seguridad de nuestros servidores:

1. Remover los servicios innecesarios: Por defecto la mayoría de los sistemas operativos instalan muchos servicios que no vamos a utilizar para ciertas tareas específicas (en el caso de un webserver o base de datos es poco probable que necesitemos un servidor de impresión o un acceso remoto a los registros). Mientras más servicios instalados tenemos, más puertos abiertos hay en nuestro servidor, además de que tener muchos servicios corriendo se traduce a mayor consumo de recursos.

2. Acceso remoto: Hoy en día ya no es practico tener un acceso remoto por un canal no encriptado. En caso de que sea necesario mantener una conexión remota a un servidor de producción, favor siempre tener en cuenta el restringir el acceso por IP, usuarios o ambos o usar un túnel de conexión VPN con toda la seguridad que esto demanda. Nunca accese a un servidor de la compañía desde un computador público como en un centro de internet o una conexión inalámbrica pública.

3. Separar los ambientes de desarrollo y producción: Además de que se hace fácil, es muy prático y aconsejable mantener separados el servidor de desarrollo y el de producción, empecemos por el hecho de que si cometemos un error en el código el usuario final obtendrá precisamente UN ERROR y quizás eso se traduzca a data errónea en la base de datos. Si no tenemos los recursos suficientes para mantener dos servidores de iguales prestaciones para estos fines, siempre podemos optar por un servidor de menos rendimiento para el ambiente de desarrollo, pero si tampoco podemos costearlo entonces se recurre al método de desarrollo en diferentes directorios o en diferentes particiones del disco y con dos bases de datos idénticas, para no hacer cambios en el ambiente de producción a nivel de base de datos.

4. Programar subida de cambios: No es conveniente estar subiendo nuevos cambios en el código al servidor de producción varias veces en un día o inmediatamente se cambie el código, todo nuevo desarrollo debe ser adecuadamente examinado y probado, lo ideal sería programar dichas subidas al inicio del siguiente día laboral, evitando subirlas al final de la jornada para no encontrarnos con errores al día siguiente. Igual podemos coordinar las subidas dos veces por semana, dependiendo siempre de la urgencia de los cambios.

5. Subversionar las versiones: Importante punto el de las versiones sobre todo cuando tenemos un equipo de trabajo desarrollando el mismo proyecto. Existen actualmente muchos manejadores de versiones, siendo el mejor y de más renombre el proyecto desarrollado por Linus Torvalds, GIT.

6. Usuarios, privilegios y permisos: Tratemos siempre de no utilizar la cuenta de usuario root para ejecutar nuestros servicios críticos, podemos crear un usuario con los mismos privilegios que root trae inicialmente y luego restarle privilegios al root o crear grupos de trabajo para luego asignarles los privilegios y permisos adecuados a este grupo en el cual estarían los usuarios apropiados. Es necesario crear un usuario por cada persona que interactuará con nuestro sistema.

7. Monitoreo y auditoría constante: Debemos estar al pendiente los logs que va generado el servidor, mantenernos informados de los accesos, los mensajes de error, las advertencias, cada mensaje es importante y nos dice mucho. En sistemas Unix/Linux usualmente cuando un proceso se ejecuta correctamente no tenemos mensaje de salida, cuando lo tenemos es que algo no anda del todo bien. La auditoría de la base de datos y la aplicación también viene a jugar un papel importante, es aconsejable estar probando de forma rutinaria los módulos de la aplicación y comparar los resultados de forma tal que podamos detectar cualquer anomalía con prontitud.

8. Política de contraseñas: Las políticas de contraseñas deben ser creadas y mantenidas de forma rigurosa, es aconsejable cambiar las contraseñas varias veces al año, al menos la de los usuarios que mantienen acceso a las bases de datos y el código fuente. Con respecto a las contraseñas para las conexiones, debemos usar frases largas con minúsculas y mayúsculas, números y carácteres especiales. Pensemos en una contraseña de al menos 10 o 15 caracteres de longitud y nunca por favor, nunca la mandemos por correo electrónico o la dejemos archivada, es algo que debemos tenerla en un solo sitio, nuestra cabeza.

9. Encriptado de la información: Mucha información crítica debe ser encriptada pensando en la seguridad y en el valor de nuestra información. Hay diversos mecanismos para encriptar, siendo dos de mis preferidos el Triple DES y el Blowfish, preferiblemente usarlos ambos al mismo tiempo. En las bases de datos como MySQL, así como en Linux hay funciones nativas para encriptar y desencriptar con ambos métodos, favor utilizarlas sobre todo para los números de tarjetas de crédito, seguridad social, identificaciones personales, y copias de seguridad.

10. Políticas de backup: Por más seguro que estén nuestros servidores si no tenemos backup estamos a medio camino, cualquier falla en los equipos nos dejaría con las manos sobre la cabeza. El código puede ser escrito de nuevo, pero cuando tenemos una enorme base de datos el asunto es más crítico, ya que no hay vuelta atrás. Se debe hacer copias de seguridad de forma sistemática, sean estos incrementales o no. Estas copias de seguridad deben ser almacenadas al menos en dos lugares, una cerca de los servidores y otra en un lugar geográfico distinto en caso de que suceda alguna catástofre que afecte las instalaciones de la compañía.

11. Alta disponibilidad y redundancia: Manejar una redundancia en equipos no es malo, todo lo contrario. El escenario ideal para un servicio web sería tener dos DNS que manejan las peticiones y redirecciones de forma balanceada a dos servidores web que a su vez van a un servidor de base de datos poderoso como maestro y otro como esclavo haciendo de espejo en tiempo real. Con esta configuración mantemos un balanceo de carga y una alta disponibilidad para una pequeña y mediana plataforma, en caso de ser una aplicación de mayor demanda, entonces el número de equipos se verá proporcionalmente incrementado.

13. El usuario inexperto: Dejo este punto de último ya que aunque suene chistoso he vivido casos en que el usuario inexperto juega un papel importante en el mantenimiento de una aplicación o una base de datos. Sucede que como expertos en lo que hacemos a veces damos por sentado que todo funciona y ha sido probado, pero nosotros aunque minuciosos no somos tan curiosos como los usuarios finales de la aplicación, son ellos quienes realmente ponen a prueba nuestro trabajo del día a día y van descubriendo errores pequeños que para ellos no pasa de ser un error, pero para un hacker es una entrada a nuestra infraestructura. Por eso es bueno tener a mano un par de capas ocho que estén poniendo a prueba lo que nuestras mentes orquestan, que siempre, pero siempre tendrá errores que debemos ir solucionando sobre la marcha.

Espero les haya servido de orientación estos pequeños puntos y que si algo de esto no lo han puesto en marcha, lo hagan con la mayor brevedad posible.

No hay respuestas

  1. 18 junio, 2013

    […] Generales sobre seguridad de servidores web y bases de datos […]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *


*

Markup Controls
Emoticons Smile Grin Sad Surprised Shocked Confused Cool Mad Razz Neutral Wink Lol Red Face Cry Evil Twisted Roll Exclaim Question Idea Arrow Mr Green