lunes, 31 de enero de 2011

Seguridad de TI: Instalación de WSUS

Como ya adelanté en “Seguridad de TI: Generalidades”, para mi la primera trinchera de defensa a los Virus, Malware, Troyanos y demás bichos nocivos es la manutención actualizada de los Sistemas Operativos sobre todo de los basados en Microsoft Windows. Microsoft difunde, al menos una vez al mes, un conjunto de mejoras  (patchs) de seguridad de sus programas y sistemas operativos… para la adopción de estas mejoras, Microsoft tiene previsto en la configuración de Windows la opción del bajado de éstas “de alguna manera” (puede ser desatendido, puede ser que alerte únicamente, puede ser que baje el producto pero no lo instale…). En un ambiente corporativo, donde se supone que la administración de TI es centralizada, no puede delegarse a los usuarios la decisión de aplicar o no una mejora de seguridad; adicionalmente si todos los PC tienen configurado el bajado de la mejora en forma automática, cuando ésta llegue se podría colapsar el acceso a Internet con 200 o 300 PCs tratando de ir a downaload.microsoft.com a buscar sus mejoras!
Por lo antes expuesto lo mejor es tener alguna herramienta que permita la administración de las mejoras de los productos de Microsoft en forma centralizada, ordenada y eficiente.

Hay productos comerciales que facilitan la administración y distribución de las mejoras de Microsoft y otros productos, nosotros preferimos usar la herramienta WSUS suministrada por Microsoft ya que es suficiente para lo que necesitábamos y además sin costo.

Para la instalación de WSUS se utilizó un servidor “standard” pero con  bastante espacio en disco disponible debido al gran volumen de software a bajar del Website de Microsoft (nosotros bajamos lo relacionado con toda la familia de productos de Windows en español y en inglés y lo relacionado con Office 2003 y 2007). El download inicial fue bastante pesado y lo dejamos haciendo durante varias noches para no molestar el acceso a Internet del día a día, también se configuró WSUS en cuanto a las políticas de autorización por parte nuestra antes de su distribución (por ejemplo no se distribuyeron los Service Pack ya que quisimos que estos se efectuaran bajo nuestro control directo). Por otro lado se implementaron unas políticas de seguridad, distribuidas por el Directorio Activo, para la implementación del “reboot” automático desatendido en caso que hiciese falta.

Inicialmente se había previsto toda una política de prueba de las mejoras ANTES de su implantación en los servidores de producción para evitar que, eventualmente, éstos dejaran de funcionar. Al final esto no pudo llevarse a cabo ya que la implementación era tremendamente engorrosa, hubiese sido necesario tener un departamento completo dedicado a probar las mejoras antes de que llegasen las siguientes… así que, en aras de la simplicidad, lo que hicimos fue asegurarnos que se tomara un Full System Backup el día anterior a la implementación de las mejoras y así poder ejecutar un eventual “roll back” en caso de que hiciese falta.

En una próxima entrega comentaré sobre los resultados de esta experiencia.

martes, 25 de enero de 2011

Raid en discos internos de Servidores

Desde hace ya unos años, los mayores fabricantes de Hardware (IBM, HP, Dell, Sun, etc.) han incorporado a sus servidores la inteligencia para la implementación de algún tipo de redundancia: RAID-1, RAID-5, RAID-10 o de manejo adicional de los discos con RAID-0. Nuestra experiencia fue con los servidores HP de la línea DL y RX, los xSerie de IBM y algunos SunFire de Sun.

Los mejores servidores en este aspecto resultaron ser los HP: la implementación de cualquiera de los RAIDs mencionados fue realmente simplemente una cuestión de leer en pantallas lo especificado y seguir los pasos. Con IBM se consiguieron resultados parecidos pero su interfaz de disco “Standard” no tenía la facilidad de RAID-5 por lo cual, a veces, se tuvieron que adquirir otras tarjetas más completas.

Los servidores Sun del año 2004 con procesador UltraSparc eran muy buenos en este sentido (los V240 y V440), pero no así los con Intel (los V65x). Los servidores V65x no tenía la facilidad de RAID-1 “transparente” para el sistema operativo, así que se tuvo que comprar una tarjeta Intel que lo hiciese pero, increíblemente, el sistema operativo Solaris x86 no lo soportaba mientras que el Linux de Red Hat si (de esta manera se implementó Linux en 3 de estos servidores).

Lo cierto es que, una vez implementado el arreglo de discos, la falla de un disco no ocasionaba ningún tipo de interrupción: veíamos el bombillo avisando el problema, se llamaba al proveedor correspondiente (estando en período de garantía), éste venía con un disco, lo cambiaba en caliente y, automáticamente, se disparaba el procedimiento que volvía a copiar la información del disco sano al dañado sin impacto alguno para los usuarios finales.

Mi recomendación es la de no tener ni un servidor de producción en el Data Center que no tenga, al menos, el disco donde está el Sistema Operativo en espejo por hardware; de esta manera se evitan largos procedimientos de reconstrucción de un servidor por una falla a un disco. Para el caso de los discos donde se almacenan los datos, idealmente también deben tener un esquema de protección del tipo RAID-1 o RAID-5, pero, en caso de una falla que los afecte, el daño sería menor puesto que sería simplemente una cuestión de: 1) cambiar el disco dañado, 2) formatear el nuevo disco, y 3) bajar el último respaldo.

Otra recomendación es la de tener un pequeño stock de discos duros para casos de fallas ya que, debido a la constante y meteórica evolución  tecnológica, es muy probable que al cabo de 3-4 años sea difícil conseguir discos de las mismas capacidades y tecnologías de los adquiridos inicialmente.

martes, 18 de enero de 2011

El Sistema de Correos Electrónicos

Hay mucho que decir a la hora de seleccionar un sistema de correo para una organización, para mi lo más importante es estar claro en el uso que se le va a dar: hay necesidad de tener embebidas las agendas de los usuarios? Se desean tener control sobre los recursos a usar (salas, proyectores, etc.)? Cual es el balance entre mensajes internos y externos? Se desean listas de correos? Se necesita interfaz con SMS?...
Como se puede ver hay muchas variables que pueden inclinar la balanza hacia una solución de mensajería u otra y no nombré una vital: los costo de licenciamiento del software, de manutención y del hardware.

A lo largo de más de ocho años trabajando en una organización multi-compañía, aprendí que los usuarios usan al sistema de mensajería para recibir y mandar correos… todo lo demás, aun cuando se tenga disponible para el uso, raramente es usado… pero si muy bien pagado! Bajo esta premisa la organización mantuvo un sistema de mensajería que hizo el trabajo a la perfección: Postfix, la herramienta de correo que viene con todos los servidores Unix incluyendo Linux.
Comenzamos con un PC (literalmente) IBM Think Centre con un Pentium IV, 512MBytes de memoria RAM, un disco duro de 40GBytes y Linux Red Hat. Este servidor le dio servicio de correo a unos 200 usuarios divididos en 4 dominios distintos quienes tenían configurados sus cuentas en Outlook con IMAP. Tener configuradas las cuentas con IMAP implica que los mensajes no se descargan sino que se mantienen en el servidor: increíblemente el PC con Linux hizo el trabajo por más de dos años sin fallar nunca!
Luego evolucionamos a un ambiente mucho más robusto: un Sun V440, con 2 CPU Ultrasparc IV, 4GBytes de memoria RAM, 4 discos internos de 36GBytes y un arreglo externo de discos Sun 3330 con una capacidad de 5 discos de 72GBytes cada uno los cuales, configurados en RAID-5, dieron un espacio disponible de unos 280GBytes (era nuestro antiguo servidor de producción para Oracle); claro está con sistema operativo Solaris 10 y el mismo sistema de mensajería Postfix.

Si el PC hizo el trabajo bien, el V440 lo hizo mejor aun: se le pusieron cuota de disco a los buzones, segmentados en distintas categorías, se instaló el sistema antivirus ClamAV (gratis), se impidieron los envíos y la recepción de correos superiores a 4MBytes. Como sistema de respaldos se usó el  BrightStore de CA el cual instala un cliente en el servidor Solaris que funciona a la perfección con la consola de respaldos en Windows.

En el momento tope, se tuvieron a unos 500 usuarios, en 8 dominios, la mayoría de los cuales configurados como IMAP (algunos prefirieron POP), también se implementó el acceso mediante Web, así que los usuarios podían consultar sus cuentas a partir de cualquier PC conectado en Internet. Personalmente tenía configurado en mi casa la cuenta con Outlook exactamente igual que en la oficina, de esta manera veía la misma información en ambos sitios SIN necesidad de conexiones especiales vía VPN.

Este servidor siempre dio la talla, nunca tuvimos problemas de exceso de uso del CPU, se tuvieron que aplicar normas restrictivas en cuanto al envío y a la recepción de mensajes personales ya que estos podían colapsar el almacenamiento en disco (la suma de las cuotas de los usuarios era superior a la disponible en disco).

Postfix sirvió a la perfección para lo que se necesitaba, además no se pagó ni un céntimo en licenciamiento de software (las demás soluciones cobran por servidor y por usuario), no se necesitaron clientes especiales en los PC, no hicieron falta grandes requerimientos de hardware, el servidor nunca tuvo amenazas de virus, prácticamente sin mantenimiento, etc.

En mi opinión se dejaron de hacer dos cosas importantes que hubiesen sido una gran mejora al sistema:

  1. Integrar los usuarios del correo (que eran los usuarios del servidor Unix) al Directorio Activo de Windows para integrar el esquema de cambio de password, la desactivación, etc. y
  2. Ofrecer a los usuarios consultas sobre el directorio corporativo para poder conseguir la dirección de correo de cualquier empleado.

martes, 11 de enero de 2011

Seguridad de TI: Generalidades

Aun cuando todas las presentaciones de especialistas de seguridad dicen que el 80% o más de las violaciones de seguridad provienen de personal interno, personalmente difiero de esa apreciación (quizás porque mi experiencia se limita a Venezuela): mientras estuve trabajando en instituciones financieras, los robos, estafas y afines (que SI ocurrieron) fueron perpetrados por personal que tenía acceso a los sistemas, no tuvieron necesidad de apropiarse de algún password poniendo un sniffer en la red, simplemente ejecutaron operaciones que podían realizar! Para enfrentar estas amenazas hay que tomar medidas que, definitivamente, no corresponden a la plataforma de TI como tal, no se trata de meter IDS o IPS o analizadores de logs para detectar ingresos sospechosos a los servidores, sino de analizar los accesos a los sistemas con los reportes propios de auditoría de los sistemas en cuestión.
Lo que SI definitivamente es una amenaza a la continuidad de la operación en cualquier empresa, es una propagación de virus en la red ya que puede fácilmente comprometer los servidores Windows y el acceso a Internet; si la contaminación es mayor, podrían colapsar servidores de otras plataforma (típicamente Linux/Unix) tales como el servidor de correos, las aplicaciones internas basadas en Web, los servidores DNS e inclusive la red como tal (lo cual impediría hacer cualquier cosa). Contra este tipo de amenazas definitivamente hay que estar preparados.

Dado que no hay una solución perfecta, es bueno tener elementos de seguridad en distintas “capas” tales como:

Antivirus en el perímetro
Hoy en día prácticamente todos los Firewalls del mercado poseen un motor antivirus que es actualizado sistemática y automáticamente por el proveedor, estos elementos atrapan una gran cantidad de Virus tratando de propagarse, así como Spyware que viajan en correos electrónicos. Indudablemente los firewalls son un factor clave en la seguridad, sin embargo su eficacia puede socavarse cuando algún usuario trae su portátil contaminado desde su casa. En nuestro caso usamos firewalls Fortigate 400 de Fortinet, son elementos muy buenos, eficientes, relativamente simples de usar, versátiles… quizás lo único malo es el precio de renovación de la licencias para la actualización del software y de las huellas de antivirus, IDS e IPS, pero desconozco los precios de las otras marcas.

Antivirus en el servidor de Correos
Hay soluciones de antivirus que se instalan en el servidor como tal, en nuestro caso el servidor era un Sun con Solaris (antes había sido un Linux Red Hat) y servicios de correo Postfix standard que viene en la caja (sobre esto volveré próximamente). Instalamos entonces un software libre antivirus  denominado ClamAV con quién nos fue bastante bien.

Antivirus en los PC y Servidores
Como herramienta antivirus se seleccionó a Kaspersky la cual resultó ser bastante buena (no perfecta), con una buena administración centralizada y un buen firewall personal. Este último módulo casi no se usó debido a la interferencia que producía con aplicaciones del negocio… se hubiese podido ajustar perfectamente, pero no se tuvo el tiempo necesario para hacerlo.

Políticas específicas en los PC
Para prevenir la difusión de virus como Conficker (o Kido) cuya reproducción se hacía mediante la ejecución automáticas de drives de Windows (típicamente los Pen Drives), se establecieron políticas de seguridad en el directorio activo para prevenir este tipo de situaciones. Eso incluía, por ejemplo, la desactivación del Schedule para la ejecución de tareas (que virtualmente ningún usuario utiliza) o inclusive compartir carpetas. Siempre gracias a la difusión de políticas de seguridad del directorio activo, se incorporaron algunas reglas que permitieron tener funcionando el Personal Firewall del SP2 sin que afectara las aplicaciones del negocio.

Actualización sistemática de Windows
Para mi ésta es la primera “trinchera” para la defensa de los PC y los Servidores de los ataques de los virus, troyanos, gusanos y afines. Generalmente es el mismo Microsoft quién descubre una falla de seguridad en el sistema operativo y otras aplicaciones, tales como el IE ó el Media Player, y difunde el remedio correspondiente, pero los hacedores de virus programan el explotador de la debilidad sabiendo que van a conseguir la mayoría de PCs y servidores sin haberse actualizado… por lo tanto es clave aplicar los “patch” de seguridad de Microsoft a la brevedad posible. Sobre este último punto hablaré la próxima semana.

De esta manera los Virus tenían que vencer a varios filtros distintos para poder penetrar todas las defensas: el antivirus del Firewall, el antivirus del servidor de correo (cuando éstos vienen embebidos en mensajes) y el antivirus del PC. Así se disminuyó la incidencia de virus notablemente.

martes, 4 de enero de 2011

Sobre la construcción del Data Center

Las características del Data Center fueron dictadas por un firma de consultores que había sido contratada con antelación por la presidencia, esta firma en general hizo un buen trabajo pero se equivocó en cuanto a la estimación del tamaño del Data Center: la cantidad de Racks que teóricamente podían caber, fue errada tanto en el número total de racks como en sus tamaño, ellos siempre pensaron en racks “cortos” cuando los servidores ya venían “largos” (ya hablé sobre este punto). La equivocación nos obligó a efectuar algunos ajustes: los operadores ya no estarían en una antesala al Data Center, sino que estarían adentro (la Sudeban luego nos hizo sus observaciones al respecto ya que no respetaba sus normas e inclusive algunos operadores se quejaron a RR.HH. por el ruido excesivo al cual estaban expuestos); la remoción de la antesala para los operadores también implicó la remoción de la doble puerta de seguridad (otra observación de la Sudeban en cuanto a las normas de seguridad física).
Lo relativo al enfriamiento se delegó a los constructores civiles quienes no tenían conocimientos particulares al respecto. Se cometió entonces el error de preocuparse en enfriar todo el ambiente cuando en verdad lo que hay que enfriar son los equipos que se encuentran en el Data Center, la consecuencia fue que los racks que tenían la mayor cantidad de los servidores (ver distribución de los servidores en los racks) tenían una temperatura mucho más alta que los demás, inclusive los discos de los servidores Sun presentaron un gran número de fallas que, cuando el equipo técnico de Sun vino a efectuar su evaluación, determinó que era problema de temperatura.

Lo mejor que se puede hacer para la construcción física de un Data Center, es contratar a una empresa con experiencia y trabajar junto a ellos para el logro de un ambiente que sea confortable para los equipos, sea eficiente en cuanto al enfriamiento, sea oportuno en cuanto a la distribución de las cargas eléctricas y sobre todo que contemple crecimiento de la plataforma.

martes, 28 de diciembre de 2010

Virtualización de Servidores: Tips

A lo largo de nuestro trabajo con la virtualización de servidores obtuvimos algunas experiencias útiles que se pueden compartir:

  1. Tener un software para pasar de un servidor físico a uno virtual. Nosotros lo hicimos con Acronis que es una herramienta para respaldos, hoy en día hay programas  especializados que facilitan la tarea.
  2. La memoria lo es todo. Definitivamente lo más importante es la cantidad de memoria disponibles para los servidores virtuales, el uso del CPU es secundario (en nuestro caso el promedio de uso de los servidores anfitriones estaba cerca del 15%). Obviamente hay que tener espacio en disco suficiente para mantener a los servidores virtuales cuyo tamaño mínimo puede ser de 5GBytes.
  3. Cuidado con las VLans. Puede ocurrir que se tenga la necesidad de colocar un servidor virtual que esté en una VLan distinta a la del servidor anfitrión, de ser así el servidor anfitrión deberá tener otra tarjeta de red con una dirección IP de la otra VLan (obvio); lo que hay que tener cuidado es el Default Gateway a colocar entre las distintas propiedades IP de las distintas tarjetas para que el flujo de datos sea eficiente.
  4. Aislar Servidores Virtuales intensivos. Si se tienen servidores virtuales que hagan uso intensivo del disco, es prudente que cada uno de ellos se aísle en un volumen del servidor anfitrión para permitir una defragmentanción de su disco sin molestar a los demás servidores virtuales residentes en el mismo anfitrión.
  5. Respaldos Totales. Lo mejor de los servidores virtuales es que el respaldo es trivial: se copia la carpeta que lo compone al servidor de respaldos y punto!
  6. En el tiempo de espera para cargar un Servidor Virtual cuando se inicia el servidor anfitrión, es prudente espaciar cada servidor virtual en 90 o 120 segundos para no sobre cargar el servidor anfitrión.
  7. Si se van a usar servidores anfitriones con Windows Server 2008, hay que recordar que hace falta una tarjeta de red únicamente para su administración, si luego se desean hospedar servidores virtuales en distintas VLANs y además con redundancia en las tarjetas de red… habrá que comprar tarjetas adicionales de red.
  8. Para que los servidores virtuales sean realmente “transportables” de un servidor anfitrión a otro, hay que disminuir los factores variables de los cuales ellos dependen:
    • Mapeo a las tarjetas de Red: si se mantiene una norma estricta sobre la nomenclatura de las tarjetas de red, este problema se subsana.
    • Mapeo a discos externos: Un servidor virtual puede mapear un disco a un disco físico del servidor anfitrión… si esto se hace… adiós a su portatibilidad!
    • Usuario que levanta el servidor virtual: lo mejor es tener un usuario del dominio para esta función, sin embargo mi experiencia es que el password no se copia de un servidor anfitrión a otro, así que siempre se tendrá que reparametrizar.

lunes, 20 de diciembre de 2010

Virtualización de Servidores: en producción

Al poco tiempo de haber cosechado el primer éxito virtualizando servidores de desarrollo, decidí pasar a la etapa de virtualizar servidores de producción.

Para dar este importante paso primero me aseguré de tener una herramienta de software que permitiese pasar de un servidor físico a uno virtual sin mayores traumas; el analista encargado luego de investigar se decidió por Acronis, este es un software para efectuar respaldos que toma imágenes de servidores Windows. La metodología era la de tomar una imagen del servidor a virtualizar con Acronis, “vaciarlo” en el cascarón de un servidor virtual y luego fajarse con los ajustes normales de Windows Server ya que el servidor se estaría “despertando” en un hardware distinto al que estaba acostumbrado (esto se resuelve teniendo el CD del Windows Server en cuestión a mano). Lo cierto es que en un tiempo relativamente corto, se podía pasar un servidor físico a uno virtual.

Para la instalación de un servidor anfitrión para servidores virtuales de producción, nos hizo falta adquirir un hardware adicional. Adquirimos un HP DL380G4, con dos discos de 72GBytes y otros tres discos de 146Gbytes, también tenía 8Gbytes de memoria RAM. El servidor lo configuramos con los dos primeros discos en RAID-1 y los otros 3 en RAID-5, de esta forma Windows Server tendría a su disposición “un” disco de 72Gbytes (para el sistema operativo y posiblemente un servidor virtual) y un segundo disco de 280Gbytes.

Con el pasar del tiempo fuimos virtualizando servidores físicos: algunos eran PCs, otros eran servidores HP DL380 o IBM x346, la mayoría de los casos se trataba de servidores con funciones de Front End con IIS o Sun Application Server o programas propietarios, pero también se virtualizaron servidores que manejaban datos propiamente con Pervasive (para el famoso sistema LA de la Casa de Bolsa) o con Sybase (para el sistema IcaavWin de la Agencia de Viajes). Se virtualizaron servidores de desarrollo de las Agencias bancarias, se virtualizó la pasarela de autorizaciones de transacciones para POS y ATM y hasta se virtualizaron dos servidores Linux de Red Hat (así es, Red Hat dentro de Servidores Windows)… todo funcionó perfectamente!

En la cúspide la virtualización tuvimos tres servidores anfitriones (uno para la VLAN de Desarrollo, uno para la VLAN desmilitarizada y otro para la VLAN de Producción) que mantenía un total de unos 24 servidores virtuales con sistemas operativos variados:

-          Windows Server 2003 R2
-          Windows Server 2000 SP4
-          Windows Profesional 2000 SP4
-          Windows XP SP3
-          Linux Red Hat 3

Lo que nunca pudimos virtualizar fue un servidor Novell Netware (nos daba problemas la tarjeta de red) pero tengo que reconocer que no hicimos nuestro mejor esfuerzo al respecto.

A lo largo de los cinco años que duró nuestra experiencia con servidores virtualizados, nunca tuvimos caídas “extrañas” imputables a la plataforma implementada, ni en los servidores anfitriones ni en los servidores huéspedes.