Cosas Interesantes 17/01/2007
Claves: WPF/E, Orable 10gR2, Vista, Arquitectura de soluciones, Domain Isolation, Forefront, Expression Design
Grids en WPF/E y exportar de Adobe illustrator a XAML
Guia de instalación y buenas practicas de Oracle 10gR2 en Windows Server 64
http://www.microsoft-oracle.com/oracledb/Pages/Workshops.aspx
Como agregar fuentes de contenido a las busquedas en vista.
Microsoft Architecture Journal 10.
Nuevo numero de esta revista sobre arquitectura de soluciones.
http://www.architecturejournal.net/
Webcast sobre seguridad. (Momentum Webcast: Windows Vista, Server and Domain Isolation, and Forefront Client Security)
In this webcast, we explore how Microsoft delivers layered, integrated protection that helps IT professionals protect their client applications against a broad range of threats while simplifying administration and integration into existing infrastructure. Join us to see how the Windows Vista operating system, Microsoft Forefront Client Security, and server and domain isolation solutions work together to help you protect your client applications from a broad range of threats.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032321939&Culture=en-US
Usando Expression Design
Mi amigo Miguel Jimenez se ha pegado con el invento y nos cuenta su experiencia.
El síndrome de Estocolmo y Citrix.
Mucho tiempo atrás, cuando las organizaciones tenían la necesidad de acceder a terminales Windows, solo teníamos un producto, Citrix, con tiempo salio NT Terminal Server.
Aun recuerdo aquellos CDs de NT TS, la ilusión con la cual los recibí, la exaltación al instalarlo y probarlo, y la incomprensión de la gente cuando les decía que ese era el mayor salto que Windows había dado en mucho tiempo y que seria clave en el futuro.
Pero seamos sinceros NT TS era una “muestra” de la tecnología, no se podía trabajar con ello a gran escala, aunque algunos nos aventuramos, y sufrimos, sobre todo por que el hardware de la época no era el apropiado.
Así que seguimos montado Citrix, pero si algo tiene el mundo de la informática es que cambia.
Como arquitecto, nunca defiendo cosas por que si, así que aun recuerdo la primera vez que llegue a una gran empresa y recomendé no usar Citrix y hacer un piloto con Terminal Services de la beta de Windows 2000, sobresalto, gritos de hereje ;-D, aseveraciones del tipo de que TS no escala sin Citrix o alusiones a problemas de impresión.
La realidad; partners que quieren seguir ganando dinero, técnicos que no quieren probar nuevas tecnologías y pocos clientes con ganas de probar las cosas antes que seguir pagando impuestos revolucionarios.
Por suerte algunos responsables de Informática luchan por salir de esos tópicos y valorar las cosas por si mismos, gracias a esto, ya hay grandes granjas de terminales sin citrix dando servicio a miles de usuarios concurrentes.
Cuando hoy en día alguien me dice que tiene que renovar licencias de citrix o que esta montando citrix, le pregunto ¿has probado solo con Terminal?, la respuesta siempre es igual, o te cuentan problemas de la época de NT, o no lo han probado, o por ejemplo te cuentan temas de despliegue sin saber nada de softgrid o GPOs.
Muchas de las organizaciones que tienen Citrix suelen sufrir del síndrome de Estocolmo, ya sea por reticencias al cambio o por falta de recursos o iniciativa para probarlo.
Con esto no quiero decir, que no haya casos en los que montaria citrix, solo digo que en muchos sitios en los que se monta citrix, se podria montar TS y mejorar el TCO.
Se resisten a valorar usar los TS de Windows y dejar de pagar licencias adicionales con escaso retorno de la inversión.
Por supuesto que Citrix aporta valor añadido sobre TS, pero ¿Cuántos clientes lo usan?, y si lo usan ¿justifica la inversión?, ¿es algo que no se puede hacer con otras tecnologías de MS?
La migración de Citrix a TS no es traumática, y los clientes suelen quedar asombrados por los resultados.
Además os insto a que probéis los servicios de terminales sobre Longhorn que incluyen grandes mejoras, podéis leer mi articulo sobre el tema: http://geeks.ms/blogs/dmatey/archive/2007/01/16/terminal-services-en-longhorn.aspx
Para los que necesiten clientes de RDP para Linux podéis ver esta iniciativa http://www.rdesktop.org/
Terminal Services en Longhorn
Sin duda una de las cosas que mas me apasiona de Longhorn son los servicios de terminales, creo que las mejoras en el protocolo RDP y otras nuevas capacidades vienen a mejorar uno de los aspectos de Windows que mas aportan a las infraestructuras informáticas de las grandes empresas.
La verdad es que cuando te enfrentas a granjas de decenas de servidores de terminales con miles de usuarios concurrentes toda nueva funcionalidad o mejora es mas que interesante :-D.
Vamos al Grano…
Una de las cosas mas interesantes que podemos ver es el uso por Terminal de aplicaciones de forma que aparentemente corran en el PC, esto se debe a que el usuario para entrar solo tiene que ejecutar un icono en el escritorio o en el menú de inicio, ambos iconos los podemos configurar de forma centralizada, como veremos luego.
Una vez ejecutado el icono, el usuario no vera el interfaz de Terminal si no la aplicación corriendo en su propia ventana, de hecho los cuadros de dialogo que la aplicación despliegue flotaran sobre esta pudiéndolos mover fuera de la ventana.
Icono de Notepad en terminal
Otra de las ventajas es que podemos asociar extensiones de archivos a aplicaciones de Terminal de forma que cuando se ejecuten, se arrancara la aplicación por Terminal y se abrirá el archivo.
Podemos generar paquetes de instalación MSI o archivos RDP desde las herramientas del servidor y luego desplegarlas por GPO o por otros medios, estos paquetes configuraran todas las opciones en el puesto y crearan los iconos si así lo deseamos.
En Windows 2000 y 2003 existía un cliente de Terminal en Activex con el cual se podía acceder desde una Web a una sesión RDP, este cliente activex seguía usando el puerto RDP de toda la vida no http, con lo cual se solucionaba poco, también usando este Activex se podían embeber aplicaciones RDP dentro de portales como Sharepoint.
En Longhorn han ido un poco mas lejos, ahora cuando creas una aplicación remota puedes publicarla en “TS Web Access” esto es una pagina web, totalmente configurable y personalizable que además incluye una web part que podemos poner en Sharepoint.
Solo aparecerán los iconos de las aplicaciones que tengamos asignadas al usuario ya sea por grupos de Windows o por GPO, las aplicaciones pueden correr en su propia ventana.
Pero esta funcionalidad, al igual que antes sigue usando el puerto rdp con lo cual tenemos que abrir dicho puerto en nuestros firewalls, ademas si en el escenario que tuviéramos necesitarmos acceder desde Internet, tendríamos que o bien dejar el RDP abierto o acceder por VPN.
En Longhorn podemos usar una característica llamada TS Gateway para acceder a Terminal por http, los servidores que hagan de gateway estarán publicados en la red de la que vengan los clientes y “trasformaran” el http en RDP y al contrario.
Para usar esta característica necesitaremos el ultimo cliente de Terminal, por ejemplo el que viene con Windows Vista.
Los gateways son balanceables por NLB pueden exponer granjas de servidores de terminales y ser publicados fácilmente con ISA o con otros firewalls, permiten la validación por smarcard, password y también pueden usar certificados de servidor.
Hay diversas opciones para los logs de los Gateways y también podemos usar NAP para garantizar que los puestos cumplan con nuestras políticas de seguridad antes de acceder al Terminal.
Otra de las grandes noticias es la posibilidad de usar licencias por usuario, de forma que cuando el mismo usuario acceda desde varios ordenadores o dispositivos solo use una licencia.
Ahora podemos administrar varios servidores juntos formando una granja esto facilita algunas operaciones de configuración, también es mas fácil la configuración del session directory que nos permitirá que los usuarios se reconecten al servidor de la granja en el que ya tenían una sesión abierta, en caso de que la pierdan, esto es especialmente util, para garantizar que un usuario solo tenga una sesión en toda la granja.
La seguridad esta presente en todos los sitios, mejor encriptación y mas opciones.
La limitación de los recursos que se mapean es mas granular, tanto en el servidor como en el cliente.
Por ultimo una nueva opción del cliente la /span que nos permite expandir el escritorio remoto a varios monitores.
Instalando Exchange 2007 en un solo servidor
Pues nada, veo que algunos no se aventuran asi que empiezo con este articulo lo que espero que sea un empujon que os anime a darle vueltas a este gran producto y gran cambio
Instalación básica de Exchange 2007.
Exchange 2007 es la nueva versión del servidor de correo de Microsoft, aunque en realidad Exchange es mucho mas que un servidor de correo.
Os recomiendo que leáis otros artículos sobre Exchange 2007 que podéis encontrar en este blog o en la propia web del producto en http://www.microsoft.com/exchange.
Este articulo se hizo con la Beta 2 de Exchange, pero creo que no ha cambiado nada importante.
En este articulo mostrare como realizar la instalación mas básica de Exchange 2007, instalando todos los servicios para prestar correo electrónico en una empresa en un solo servidor.
El servidor tendrá que tener instalado Windows 2003 SP1, framework 2.0, powershell y mmc 3.0, tiene que ser un miembro de dominio y tanto el dominio como el forest tienen que estar en modo de compatibilidad Windows 2003.
No es necesario usar Windows 2003 R2.
El servidor tiene que tener el IIS funcionando pero no el SMTP ni el NNTP.
En futuros artículos trataremos la instalación en cluster o con los roles en diferentes servidores, si queréis podéis ver un ejemplo de infraestructura con Exchange 2007 en el siguiente articulo: http://geeks.ms/blogs/dmatey/archive/2007/01/16/ejemplo-de-dise-o-de-arquitectura-de-mensajeria-con-exchange-2007.aspx
Empezamos, instalando los prerrequisitos:
Ahora que ya tenemos todo, podemos instalar Exchange.
Las alertas que nos muestra la pantalla anterior, son avisándonos de que la versión de 32 bits no esta pensada para producción.
Bien, ya tenemos Exchange instalado, el siguiente paso será crear el primer buzón de correo.
Esto se puede hacer por script, por powershell desde users and computers y desde la propia consola de Exchange, dado que esto ultimo tiene algo de novedoso, usaremos este interfaz para crear la cuenta y el buzon.
Como veis en la pantalla anterior, cada vez que ejecutamos una acción desde la consola, esta nos regala el script que tendríamos que correr para poder realizar la misma acción con powershell.
Esta funcionalidad me parece fantastica asi que no puedo evitar detenerme un poco en ella.
Pulsaremos control + c para copiar el script y lo pegamos en notepad
Una vez que lo vemos en el notepad, nos damos cuenta de que la password del usuario ha sido sustituida por una cadena que hace referencia a un string seguro.
Asi que para que podamos usar este script para crear una cuenta y darle un buzon tendremos que usar nuestros conocimientos de powershell.
Haremos que el script pregunte la contraseña al administrador, la meta en una variable y luego la use dentro de la sentencia que crea el buzon.
Quedaria asi:
Pegaremos y ejecutaremos en la shell de Exchange los dos pasos del script.
Ya tendremos otro usuario creado
34
El paso siguiente sera indicarle a Exchange que acepte correo del domino publico que tengamos.
Por defecto Exchange 2007 aceptaría correo del dominio DNS del AD a través de un servidor de Exchange con el rol de Edge.
En esta instalación no tendremos un servidor Edge y nuestro domino interno no es igual que el externo, asi que hay que realizar algunos cambios.
Añadimos el dominio:
Nos conectamos por telnet y lo probamos:
Ops, no nos deja, el servidor que estamos usando no es un Edge, nos estamos conectando al SMTP del rol de Hub Transport, este rol esta preparado para que otros servidores de nuestra organización se conecten para enviar correo, por lo tanto exige que estos servidores se validen.
Tendremos que modificar el conector de recepción de correo para que acepte validación anonima.
Para hacer esto correremos otro script de powershell.
Y probamos de nuevo
Y con el domino externo también:
Nos queda entrar en el buzón y ver el correo, para lo que usare el OWA.
En próximos artículos espero poder enseñaros mas y mas bonito.
Un Firewall es un accesorio de cocina (Probando ISA Server 2006)
Notas sobre este articulo: Este articulo esta publicado en ingles en isaserver.org (http://www.isaserver.org/tutorials/ISA-Server-2006-Kitchen-Utensil-Part1.html)
Un firewall es un accesorio de cocina
Normalmente la gente ve los firewalls como si fueran sólidos muros llameantes, como la milagrosa solución a todos los problemas de seguridad en las empresas.
Los firewalls hacen que la gente se sienta segura, pero desgraciadamente los firewalls no hacen seguras las redes, en realidad solo las hacen algo más seguras.
En mi opinión los firewalls son coladores, el tamaño de los agujeros del colador depende de cómo es administrado el firewall.
Según esta teoría los hackers serian como los grumos que no quieres en tu zumo 😀
Los usuarios legítimos de los servicios acceden a ellos a través de los agujeros del colador, por lo tanto la seguridad dentro de los servicios accesibles a través del firewall es tan importante como la del propio firewall en si.
En teoría ¿si un administrador de seguridad estuviera completamente seguro de la seguridad de sus servidores necesitaría firewalls?, yo opino que si.
He terminado de configurar mi firewall, ¿ahora que hago?
En realidad ahora empieza lo difícil, tienes que asegurarte de que tu firewall hace lo que realmente tú crees que hace.
También tienes que asegurarte de que la seguridad que te ofrece el firewall no se degrade con el tiempo debido a una mala administración.
En este artículo podrás aprender más sobre:
· Como probar un firewall con ISA 2006.
· Como ISA 2006 reacciona a un ataque.
· Algunas herramientas que los hackers podrían usar para atacar tu red.
· Algunas nuevas funcionalidades de ISA 2006
La siguiente figura muestra la red de ejemplo que se usara en este artículo.
Diagrama 1. Red de Ejemplo
No te lo creas, pruebalo
Después de que hayas instalado tu firewall y creado las reglas iniciales, la primera cosa que debes hacer es auditar tu firewall.
Auditando tu firewall desde dentro y desde fuera de tu red, obtendrás una clara visión de cual es tu superficie de ataque.
La primera cosa que un hacker hará si quiere atacar tu sistema es encontrar información sobre el.
Una de las fuentes de información más valiosa que un hacker puede tener son los port scanners.
Por esta razón un administrador de seguridad, debe conocer como sus sistemas reaccionan a un scan y que información obtendrán los atacantes al escanearle.
Una de las herramientas más famosas para hacer port scanning es NMap.
Nmap es una de código abierto que soporta docenas de técnicas de escaneo, además provee de algunas técnicas que en teoría se denominan “ocultas” y con las cuales se supone que los sistemas escaneados no deberían detectar que lo han sido.
Puedes encontrar NMap y más información sobre el en: Insecure.org
En arquitecturas informáticas enfocadas en la seguridad, es común encontrar IDS e IPS que pueden detectar escaneos, las técnicas “ocultas” tratan de engañarlos para que no sean detectados.
Ahora vamos a scanear nuestro firewall en la red de ejemplo, durante esta parte del test, debes recordar que el puerto 80 del firewall esta publicando una web y por lo tanto esta abierto.
Figura 1. Escaneo basico NMap Scan (sS)
NMap Detecta el puerto 80 abierto.
Pero ISA Server detecta varias cosas extrañas en la actividad de red; el número de conexiones que NMap establece para realizar el escaneo hace que ISA lance una alerta y escriba un evento en el log.
Figura 2. Alerta de conexiones denegadas por minuto.
Esta alerta también escribe un evento en el visor de sucesos, este evento es fácilmente capturable desde herramientas de monitorización como MOM.
Figura 3 . Evento de conexiones denegadas por minuto.
Esta alerta es producida por una nueva funcionalidad de ISA 2006 que trata de evitar ataques de tipo DOS y gusanos, al final de este articulo hablaremos mas sobre estas nuevas funcionalidades.
Pese a que en un escaneo básico con NMap se usa una técnica llamada SYN que en teoría es de las denominadas “ocultas”, ISA Server detecta el trafico y obviamente lo deniega, excepto por supuesto el dirigido al Puerto 80 que esta abierto.
Figura 4. Trafico Denegado y aceptado.
Cuando una regla de ISA Server deniega un paquete, el firewall hace un “drop” del paquete y de la conexión, debido a este comportamiento, los port scanners no pueden saber si el puerto esta cerrado o filtrado, dado que no reciben ningún tipo de contestación.
Otra famosa técnica de escaneado es usar paquetes fragmentados, ISA Server solo corre en servidores Windows y Windows por defecto descarta todo el tráfico fragmentado, por esta razón escanear un ISA con paquetes fragmentados no tendrá ningún resultado.
ISA 2006 por defecto no escribe ninguna alerta o evento sobre escaneos de puertos, para cambiar esto, hay que configurar el firewall de forma específica:
Figura 5. Habilitar la detección de escaneos (paso 1).
Figura 6. Habilitar la detección de escaneos (paso 2).
Para mas información sobre esta configuración puedes leer el siguiente artículo de Microsoft: ISA Server Port Scan Alerts .
Después de que hayas activado estas opciones, ISA Server escribirá una alerta y un evento cada vez que detecte un escaneo que cumpla con las condiciones que hayas especificado.
Si después de este cambio, escaneamos de Nuevo el firewall veremos la siguiente alerta:
Figura 7. Alerta de escaneo de puertos detectado.
También se escribe un evento en el visor de eventos, si tenemos MOM, este evento es recogido también por el management pack de MOM para ISA 2006.
Nmap provee de otras técnicas de escaneo, en este articulo las probaremos todas, para ver como reacciona ISA.
Aviso de que NMap permite indicar opcionalmente conjunciones de Flags de TCP para realizar otros tipos de scans, esas combinaciones nos las probare, dado que según mis pruebas los resultados no afectan a la conclusión de este articulo.
Null Scan
De la ayuda de NMap: “The null scan (sN) does not set any bits (tcp flag header is0)”
Los resultados del null scan en ISA son:
Figura 8. Alerta: Null Scan.
Figuras 9 y 10 Eventos Null Scan.
NMap no detecta ningún Puerto específicamente abierto, para el todos los puertos están abiertos o filtrados, pero recordar que el Puerto 80 si esta abierto, por lo tanto en realidad el hacker no obtiene ninguna información útil.
Figura 11. Resultado del Null scan .
Figura 12. Trafico detectado por el firewall.
FIN Scan
De la ayuda de NMap:”The FIN scan sets just the TCP FIN bit.”
Los resultados del FIN scan en ISA son:
ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.
Figura 13. Resultados del FIN.
Figure 14. Trafico detectado en los logs del firewall.
Xmas Scan
De la ayuda de NMap: “Xmas Scan sets the FIN, PSH and URG flags, lighting the packet up like a Christmas tree.”
Los resultados del Xmas scan en ISA son:
ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.
Figura 15. Resultados: Xmas Scan.
Figura 16. Trafico detectado en los logs del firewall.
TCP ACK Scan
De la ayuda de NMap: “The ACK scan probe packet has only the ACK flag set (unless you use –scanflags). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don’t respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are labeled filtered.”
Los resultados del ACK scan en ISA son:
ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.
Figura 17. Resultados:ACK Scan.
Figura 18. Trafico detectado en los logs del firewall.
TCP connect scan
En este tipo de scan, NMap usa al sistema operativo sobre el que corre para hacer un connect() de forma completamente normal, por esa razón este tipo de scan se detecta de forma muy simple, cualquier IDS o IPS y por supuesto ISA, lo detectan.
Los resultados del TCP Connect scan en ISA son:
ISA escribe una alerta de intrusión y un evento, NMap encuentra el puerto 80 abierto.
Figure 19. Alerta: Intrusion detection.
Figura 20. Resultados: TCP Connect Scan.
Figura 21. Trafico detectado en los logs del firewall.
TCP Window Scan.
De la ayuda de NMap:”Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window field of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. So instead of always listing a port as unfiltered when it receives a RST back, Window scan lists the port as open or closed if the TCP Window value in that reset is positive or zero, respectively.”
Los resultado del TCP Window scan en ISA son:
ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.
Figura 22. Resultado del escaneo.
TCP Maimon scan
De la ayuda de NMap: ”The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as Null, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.”
Los resultados del TCP Maimon scan en ISA son:
ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.
Figura 23. Alerta de conexiones denegadas.
Figura 24. Resultados del escaneo.
Tabla 1. Port Scanning ISA Server 2006
Reaccionando a un escaneo de puertos.
ISA Server puede reaccionar a un ataque o escaneo ejecutando una accion desde la alerta.
Figura 25. Configurando las definiciones de alertas.
Figura 26. Modificando la definición de la alerta de intrusión.
Figura 27. Configurando las acciones de una alerta.
Es sencillo hacer un script que bloquee todo el tráfico que tenga como origen al atacante.
Firewall Fingerprint.
NMap también nos provee de técnicas para detectar el sistema operativo que corra en el objetivo del escaneo, esto se realiza gracias a una base de datos de huellas de las pilas de TCP IP de los diferentes sistemas operativos.
Cuando un atacante usa esta opción sobre ISA, solo podrá averiguar que ISA corre sobre una maquina Windows.
Un hacker podría presuponer que se esta corriendo ISA y buscar vulnerabilidades conocidas para atacarlo.
Security focus tiene una base de datos de vulnerabilidades ampliamente reconocida, si un atacante trata de buscar vulnerabilidades de ISA 2004 o 2006 solo encontrara una, y además no es de firewalling si no de proxy, además no supone un riesgo a nivel de intrusión.
Trata de buscar vulnerabilidades de Firewall 1 y no te asustes!!! 😀
Figura 28. Security Focus ISA 2004 vulnerabilities.
Que es lo siguiente?
Si un atacante acepta el riesgo de ser detectado, podría conseguir información sobre tus puertos abiertos, el siguiente paso que tratara de realizar es atacar los servicios que estén publicados en el firewall, como por ejemplo servicios SMTP, paginas Web, etc.
Para realizar este trabajo un hacker usara herramientas de escaneo de vulnerabilidades como Nessus, Nikto, etc, pero este no es el objeto de este articulo así que no hablare mas sobre las técnicas de ataque a los servicios publicados.
Como buena practica, hay que tratar siempre de limitar el origen de las conexiones a los puertos publicados, por ejemplo si tienes que publicar un servicio web y no será usado por cualquiera en Internet, trata de que te indiquen desde que ips será usado.
Tus firewalls pueden ser seguros, pero desde luego si publicas un servidor NT 4, con una web IIS 5 sin securizar puedes estar seguro de que tu red será insegura, tienes que securizar todos tus servidores y servicios, especialmente los que estén publicados en Internet.
Mantener todos tus servicios actualizados con los últimos productos de cada familia es una pequeña garantía de seguridad.
Ok, ahora conozco mi superficie externa, ¿puedo descansar?
Desafortunadamente no, el 80% de los ataques provienen de la red interna, normalmente tendrás como mucho una docena de servidores publicados en Internet, pero puedes tener cientos de servidores en tu red interna.
Las redes internas son una pesadilla para los administradores de seguridad.
Las redes internas suelen estar segmentadas en DMZs pero es común encontrar servidores que están en el mismo segmento de red que los usuarios.
Para los servidores que no están en las DMZ puedes usar IPSec y firewalls locales, pero…. ¿Qué pasa con las DMZ si un hacker esta dentro de tu red?
Antes decía que las redes internas son una pesadilla para los administradores de seguridad, las dos claves técnicas para hacer esta afirmación son el envenenamiento ARP con todas sus variantes y los sniffers.
Las razones no técnicas están claras, normalmente se tiene una falsa sensación de seguridad con todo lo que se denomina “interno” además siempre que hago una auditoria oigo la misma frase: “quien nos atacaría desde dentro, eso no pasara, concentrémonos en el exterior”
Recuerdo un cliente hace varios años, tras decirnos esto, nos disfrazamos de técnicos de manteamiento, entramos por la puerta sonriendo y saludando a todo el mundo, nos metimos en una sala de impresoras y colgamos de la red un router wifi con un sniffer metido en el firmware, tras enseñarles lo fácil que había sido, nos dijeron que nadie haría una cosa así. ¿en serio?, recuerdo otro caso en el que nos llevamos una SUN por la puerta del edificio :-D, en fin siguen existiendo muchas empresas que invierten grandes cantidades en I+D pero que no quieren creer que haya nadie capaz de robarle sus ideas.
Volviendo al tema del ISA, en las redes internas, normalmente los administradores de ISA pueden usar dos elementos con el fin de distinguir a los usuarios que pueden usar una regla de los que no:
–La IP de origen; La ip de origen de una maquina se puede cambiar con facilidad y usando técnicas ARP, es posible secuestrar la IP y la MAC de un equipo. En Internet los hackers solo pueden ver los puertos que el firewall tenga abiertos para toda la red externa o para las subredes en las que se encuentre el hacker, pero en las redes internas, un hacker se puede hacer pasar por cualquier equipo y así averiguar que puertos están abiertos, aunque no sean para el.
-El usuario logeado en la maquina; Los administradores pueden poner reglas que se basen en el usuario que esta usando la maquina, desgraciadamente un hacker puede usar técnicas ARP y Sniffers para snifar las passwords en la red. Además las redes internas en muchas ocasiones contienen servicios poco seguros, cientos de servidores corren en muchas ocasiones desactualizados o con viejas versiones, en otros casos, hay servicios que usan contraseñas en texto plano o autenticación básica, o bien se usan antiguos hashes NTLM fácilmente capturables, otros servicios como webs o Terminal services no securizados, proxies ,etc también ponen fácil a un hacker averiguar contraseñas.
Las siguientes pruebas se realizaran desde dentro de la red de ejemplo, además habrá un regla que permita el trafico desde la red interna a un servidor en la DMZ (192.168.10.2) esta regla contendrá una excepción que impida acceder al equipo del hacker al servidor en la DMZ.
Figura 29. Regla en el ISA Server.
Figuras 30 y 31. Detalles de la regla.
En este punto si se escanea la ip del servidor web en la DMZ veremos que todos los puertos están abiertos o filtrados, por lo que el hacker no obtiene ninguna información de valor.
Figura 32. Resultados del escaneo.
Todo lo que separa la hacker de su objetivo es su IP y una password.
¿Que pasaría si usamos NMap para enviar los paquetes simulando tener otra ip?, ¿Qué pasa si esa ip esta en otra red de ISA como por ejemplo la DMZ o Internet?
Figura 33. Usando NMAp para usar una IP falsa de otro segmento de red del ISA, con el comando; “nmap –p 80-90 –e eth0 –S 10.10.10.2 –P0 192.168.10.2”.
Figura 34. ISA detecta los paquetes del spoofing packet y deniega el trafico.
Figura 34b. ISA detecta el ataque de spoofing y escribe un evento.
Bien, ¿pero que pasa si el paquete viene de la red correcta?
Se puede usar NMap para hacer spoofing de MACs e IPs pero hay que ir probando ip por ip dentro de tu subred, para este trabajo es mejor usar otra utilidad llamada IRS que esta hecha por los creadores de Cain & Abel.
Con IRS podemos escanear un objetivo y un Puerto hacienda spoofing de ips dentro de nuestra subnet, adicionalmente también podemos usar una MAC falsa.
Figura 35. Usando IRS (1)
Figura 36 Usando IRS (2), Configurando la tarjeta de red.
Figura 37. Usando IRS(3), Estableciendo el objetivo.
Figura 38. Resultados Usando IRS (4)!!!!!
Ahora el hacker ya sabe que ips tienen acceso y que ips no.
El protocolo ARP y los sniffers nos permiten otros muchos interesantes juegos.
Podemos capturar el tráfico de la red buscando passwords.
En el mundo real, la seguridad es atómica, o todo es seguro o nada es seguro, si tienes sistemas inseguros y no puedes securizarlos, lo mejor es aislarlos del resto de tus sistemas, haz otro dominio para los sistemas inseguros y haz que tus usuarios usen otro usuario y password para acceder a ellos, a nivel de seguridad es muy poco eficiente que un usuario entre en un sistema inseguro con la misma password que usa para entrar en nuestro sistema mas moderno y seguro, tal vez el usuario este muy contento con tener una sola password pero estaremos poniendo en peligro la seguridad de un porcentaje mucho mayor de nuestra red.
Si tus usuarios usan la misma password para validarse en sistemas inseguros que en sistemas seguros, un hacker puede usar un sniffer y ataques de tipo ARP como los de “man in the middle” (MITM) para encontrar las passwords de los usuarios.
Toda esta situación se agrava si además esos servicios inseguros usan el directorio activo para validar las contraseñas.
Programas como Ettercap, hacen las dos cosas, capturan el tráfico de red y usando decodificadores de protocolos buscan las passwords, Ettercap también permite hacer ataques de tipo MITM.
Hay gente que piensa que los switches de red impiden por defecto que se esnife el trafico, pero desgraciadamente muchos sabemos que no es así.
Figura 39. Usando Ettercap (1) Capturando el trafico de red.
Figura 40. Usando Ettercap (2).
Figura 41. Usando Ettercap (3) Passwords detectadas.
Figura 42. Usando Ettercap (4), MITM.
Con estos dos pasos, un hacker en la red interna habría obtenido la información que necesita para atacar nuestros servicios en la red DMZ, pero…. ¿Qué pasa si el hacker es realmente una mala persona y nosotros no hemos tomado precauciones?, en este caso, un hacker podría evitar toda comunicación entre las redes que conecte el ISA o cualquier otro router/firewall, incluida la red Internet.
En nuestra red de ejemplo, el firewall alcanza Internet a través del router con la IP 10.10.10.2.
¿que pasaría si un hacker engaña al firewall comunicándole una falsa MAC del router de Internet?, repuesta: que el firewall no se podría comunicar con Internet, este ataque es del tipo D.O.S (Denial Of Service)
Figura 43. Usando Nemesis desde el ordenador del hacker para inyectar un paquete ARP en el firewall.
Bien; Has visto lo malo y lo peor, déjame enseñarte lo bueno.
La primera cosa que debes saber, es que los ataques ARP y MITM son muy difíciles de hacer sobre Internet.
Los hackers tienen herramientas, pero los administradores también, para evitar un ataque DOS o de tipo MITM, se deben añadir rutas estáticas ARP en los firewalls y otros dispositivos de red.
Para realizar esto, se puede usar el comando ARP:
Figura 44. Creando una entrada ARP estática en el firewall.
Los dispositivos de red, pueden ser el mejor aliado de los administradores para combatir el spoofing.
Se pueden crear vlans que eviten el broadcast ARP y muchos dispositivos de red, disponen de capacidades que pueden ayudarte a hacer más segura la red, hoy en día se compra una electrónica de red estupenda pero de la que apenas se usa el 10% de las funciones.
Lo que de ninguna forma puede pasar, es que los hackers tengan más interés en mejorar sus conocimientos que los administradores de seguridad, si esto pasa, la batalla estará perdida.
Otras herramientas que los administradores tienen, son los IDS (Intrusion Detection System) o IPS (Intrusión Prevention System), estos programas usan sniffers para analizar el trafico de red y encontrar patrones maliciosos de uso, para encontrar estos patrones se usa una base de datos de reglas que se actualiza desde Internet.
Snort es uno de los IDS gratuitos mas famosos, IDSCenter es un interface grafico para Snort sobre windows.
Se puede configurar Snort para detectar ataques ARP contra IPs especificas, como firewalls, routers, proxies, etc.
Snort también detecta los ports scans y otros cientos de eventos de seguridad.
Figura 45. Configurando Snort para detectar ataques ARP.
También puedes configurar Snort para correr scripts que bloqueen el trafico desde la ip del atacante o te envíen un mail informándote del evento.
Figura 46. Configurado la notificación de alertas de Snort.
Figura 47. Evento de Snort: ARP Spoof detected.
Figura 48. Evento de Snort: Port scan detected.
Si instalas el agente de MOM en el servidor que tenga instalado el Snort, podrás capturar los eventos de Snort desde la consola de MOM, disparando alertas sobre eventos.
Flood Mitigation.
Algunas de las nuevas funcionalidades de ISA 2006 son las de mitigación de ataques DOS y gusanos de red.
Figura 49. Flood mitigation (1)
Figura 50. Flood mitigation (2)
Figura 51. Flood mitigation (3)
Para cada tipo de ataque se puede configurar un límite y un límite personalizado que solo se aplicara a una lista de excepciones por IP.
Para este ejemplo incluiremos la IP de un ordenador interno en la lista de excepciones y estableceremos un límite personalizado de 3 para las conexiones TCP/IP concurrentes.
Figura 52. Flood mitigation (4)
Figura 53. Flood mitigation (5)
Figura 54. Flood mitigation (6)
Con estos ajustes el ordenador con la IP 192.168.0.30, tendrá limitadas sus conexiones concurrentes a través de ISA a 3.
Para probarlo lanzaremos varios telnets desde el ordenador con la IP 192.168.0.30 al puerto 80 del firewall, también observaremos el numero de conexiones TCP/IP de ISA en tiempo real usando el performance monitor.
Figura 55. Flood mitigation (7)
Cuando el ordenador trata de abrir la cuarta conexión concurrente ISA deniega el tráfico y lanza una alerta.
Conclusiones
ISA Server es un gran producto, tiene certificaciones de seguridad al mas alto nivel y es “seguro por defecto”, a su vez Windows nos provee de una gran cantidad de características de seguridad que nos ayudan a luchar contra los hackers.
Pero la ultima responsabilidad de mantener tu red segura esta en tu manos, en tu trabajo y por supuesto en tus conocimientos.
Cosas Interesantes
Como publicar informes de reporting services en MOSS
La VoIP puede convertirse mas aun en un objetivo de los hackers.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=277590
Un script para hacer inventario y hard y soft de los PCs.
Yo tengo algo parecido modificado para guardarlo en BD y del que luego saco informes con Reporting, pero este os vale como guia.
http://addicted-to-it.blogspot.com/2007/01/ad-coit-v23-inventory-tool-released-on.html
Un poco de publicidad: Mi articulo sobre monitorizar dispositivos SNMP con SCOM 2007 publicado en ingles por momresources.org.
http://www.momresources.org/scom/how-to/Manage_SNMP_Devices.doc
Longhorn Build 9660 disponible para descarga en Technet Plus.
Ya la tengo bajando, creo que hare un articulo sobre clusters 😀
Cuidadin: Parche para publicar Exchange 2007 con ISA.
- The Attachment Blocking feature has been removed when publishing Exchange 2007. To block OWA attachments, we recommend that your configure attachment blocking in Exchange 2007.
- This software update also updates the ISA 2006 MMC snap-in.
Ejemplo de diseño de arquitectura de mensajeria con Exchange 2007.
Desde que salio la primera Beta, varias personas me han preguntado sobre como seria la arquitectura de un servicio de correo basado en Exchange 2007.
He tratado de explicar a estas personas mi opinión sobre el tema, y dado que parece haber gustado, voy a exponerla aquí para compartirla con la comunidad.
Todo diseño se basa en unas premisas, en este caso usaremos las más comunes hoy en día:
- Sistema de correo completamente centralizado.
- Diseñado pensando en la seguridad.
- Alta disponibilidad.
- Correo Anywhere.
- Mayor valor añadido posible.
Centralización.
Tengo que aclarar que el concepto de correo completamente centralizado, es un objetivo común hoy en día y por el que además hay que luchar.
La centralización supone un gran ahorro de costes, tanto de servidores y licencias como de gastos de administración y operación.
Hoy en día Exchange 2003 permite una gran escalabilidad, Exchange 2007 dispone de algunas nuevas funcionalidades que elevaran el numero de usuarios por servidor.
El ancho de banda con el que se cuenta cada vez es mayor, los servidores mas potentes y los clientes y protocolos mas optimizados, es hora de que los arquitectos diseñemos los sistemas aportando a nuestros clientes los beneficios de la centralización.
Seguridad.
La seguridad es un aspecto esencial de cada diseño que se realiza, así que cada elemento del diseño tiene sus propios detalles a nivel de seguridad.
Sistemas de encriptación, antivirus y antispam, y otras herramientas de seguridad son tan importantes como las políticas de retención de los correos u otras políticas relacionadas con el mismo como tipos de contenidos permitidos.
Tambien es importante hacer ver que la seguridad es igual de importante hacia fuera como hacia dentro.
Alta disponibilidad.
No se puede pensar en una solución para mediana y gran empresa que no contemple la alta disponibilidad, alcanzar los cinco nueves de disponibilidad es un objetivo exigente pero factible si contamos no solo con un buen diseño si no con algo mas esencial para la disponibilidad, una administración y operación excelentes.
En Exchange 2007 aparece un nuevo tipo de servicio, el UM o mensajeria unificada, este servicio es de suponer que empiece a despertar en las empresas, pero de momento en la mayoría de los proyectos no será mas que un piloto que madurara con el tiempo, por esta razón, no será normal al principio pensar en la tolerancia a fallos de esta parte de la solución.
Correo Anyware.
Un sistema de correo actual, ha de poder servir el correo a una gran cantidad de dispositivos y en diferentes situaciones.
Este tipo de dispositivos, no solo estarán en Internet, si no en redes wireless dentro de las redes de las empresas.
Dentro del diseño hay que pensar en prestar estos servicios con el mismo nivel de calidad y seguridad que el resto de la solución.
Mayor valor añadido posible.
Si no aportamos valor añadido a las soluciones que diseñamos y no somos capaces de innovar, ¿que aportamos frente a la competencia?, es aqui donde se demuestra la valia del arquitecto.
Si hay algo que me haga usar los productos de Microsoft es que sus productos están llenos de “pequeños regalos”, que nos permiten dar mucho valor añadido a las soluciones que diseñamos.
Si complementamos estos “regalos” gratuitos con otras herramientas de gran potencia como MOM o Sharepoint podemos encontrarnos con una gran cantidad de pluses que ofrecer a nuestros clientes sin prácticamente coste adicional.
Un amplio conocimiento de las tecnologías de programación existentes nos permitiran crear complementos a las herramientas de administración que permitan realizar algunas tareas rutinarias de forma mas automática y garantizando la mayor fiabilidad con los procesos de la empresa.
MOM es por supuesto un elemento fundamental de todo despliegue de Exchange, evidentemente lo es una vez terminado el proyecto, pero no hay que despreciar su utilidad para detectar problemas durante el despliegue.
Hay que hacer hincapié en el mantenimiento de la solución y en aprovechar el proyecto para mejorar la operación de los servicios de correo dentro de la empresa.
Adicionalmente el que Exchange 2007 requiera de hardware de 64 Bits nos da la oportunidad de hacer un buen trabajo eligiendo el hardware a la vez que permitirá implantar nuevas tecnologías y facilitar la migración.
Por ultimo decir que de nada valdrá un gran diseño de Exchange si flaquean otros servicios como el directorio activo o la seguridad global.
Este articulo esta pensado para arquitectos que estoy seguro que enlazaran rápidamente con las ideas de cada punto, por esto y por que tampoco hay que quitar el misterio 😉 no entrare en grandes detalles, solo lo suficiente para haceros pensar.
Diagrama De la Solución.
Detalle del diagrama
1) Frontera Externa.
Sin duda la frontera externa seria ISA Ent 2006 o 2004 SP2, la razón es la excelente seguridad y facilidad de publicación de los servicios.
Pensar que son varios los servicios a publicar (RPC sobre HTTP, SSL, SMTP) y que además el uso de dispositivos móviles con tecnología Push hace que haya un gran numero de conexiones contra los firewalls.
La posibilidad de acceder a los ficheros y sitios de las intranets a traves de OWA, también intensificara el trafico y las necesidades de seguridad en esta parte tan sensible de la arquitectura.
La posibilidad de ISA 2006 de contar con varios métodos simultáneos de autenticación también es un funcionalidad a tener en cuenta.
En disputa con Thom Shinder y a favor de Steve Riley tengo que aconsejar que este array de ISA no forme parte de un dominio interno, si no que o bien forme parte de un grupo de trabajo o pertenezca a un dominio solo existente en este segmento de la red y sin relaciones de confianza ni intervención en ningún otro servicio interno.
2) DMZ de alto riesgo.
Aunque se diga que las DMZ están muertas, siguen siendo una de las mejores formas de elevar la seguridad de ciertos segmentos de la red.
Esta DMZ se encuentra entre los firewalls de frontera y los internos o perimetrales.
Es una DMZ de confianza Nula y de alto riesgo.
Seria común encontrar un IDS y una honeypot en este punto de la red.
En la solución que estoy comentando, nos encontramos con un Array NLB de servidores con Exchange 2007, estos servidores no forman parte del dominio y usan ADAM para validar las direcciones.
En la terminología de Exchange 2007, estos servidores son los “Edge Servers”
De esta forma no se pone en riesgo la seguridad del resto de información del directorio activo y se evita que se puedan usar estos servidores y sus servicios para escalar privilegios.
El puerto 25 (SMTP) de estos servidores esta publicado en Internet en las IPs de los registros MX.
La función de estos servidores es recibir y enviar el correo hacia Internet.
Estos servidores contarían con Microsoft ForeFront para Exchange Server, este antivirus evolución del Antigen de Sybari permite escanear cada correo en un numero variable de engines, uno de dichos engines es el propio de Microsoft.
ForeFront para Exchange también cuenta con AntiSpam.
El Sender ID framework también forma parte de la configuración.
Estos servidores han de mantenerse continuamente actualizados y son de alto riesgo por lo que se aconseja no poner ningún otro servicio en ellos y fortificarlos convenientemente.
3) Frontera Interna.
Nos encontramos aquí con la ultima frontera en forma de Array hacia los servidores y el resto de la LAN.
Aquí podremos elegir entre dos corrientes de pensamiento;
Escoger un producto que no sea ISA con el fin de que si existe una vulnerabilidad en el producto, un atacante no la pueda aprovechar para traspasar las dos fronteras.
Poner ISA esta vez formando parte del dominio interno para obtener la mayor funcionalidad.
La elección dependerá de muchas cosas, especialmente de los servicios que queramos prestar.
4) DMZ de riesgo Moderado.
Prácticamente todos los servidores han de estar separados de la LAN de los usuarios, esto incluye AD, servicios de red, monitorización , ficheros, intranets, etc.
Para conseguir esto, tendremos que crear varias DMZ, reglas IPSec, etc.
Dado que el acceso a esta red se produce tras dos niveles de firewalls y con solicitudes ya validadas consideraremos esta red de riesgo moderado.
Es aquí donde pondremos algunos de los elementos que compondrán la solución.
5) Front End.
Los servidores de front-end permiten a los usuarios usar su correo web, pop3, imap o acceder desde las PDAs y móviles, tienen un riesgo de seguridad algo menor que los servidores de Edge pero sigue teniéndose que tener en cuenta dado que son los que prestan en realidad la mayoría de servicios visibles en Internet.
Algunos pensaran que seria mas lógico ponerlos en la DMZ de algo riesgo, en mi opinión los requisitos de reglas en los firewalls que imponen estos servidores, me parecen mas graves que mantenerlos dentro de la DMZ de riesgo moderado.
Evidentemente estos servidores también cuentan con antivirus ForeFront dado que son el punto de entrada del correo saliente para algunos tipos de clientes.
Usaremos un Array NLB para aportar escalabilidad y tolerancia a fallos.
La fortificación de los servidores y una correcta administración y actualización son claves para garantizar la seguridad de la infraestructura.
La ip virtual del array ha de ser publicada en los firewalls internos para luego ser publicada a su vez por los firewalls externos usando para ello la IP virtual del array de firewalls internos.
Se usara autenticación por formulario bajo SSL y exigiremos que todos los dispositivos que usen activesync hayan tenido que ser autorizados para poder usar los servicios de correo.
6) Servidor de mensajeria unificada.
Este servidor cuenta con una conexión a un gateway SIP o centralita (PBX).
Nos permitirá por ejemplo:
Acceder a nuestro buzón llamando por teléfono, al hacerlo una amable señorita nos contestara de momento en ingles y tras introducir un PIN podremos hacer leer al sistema nuestros correos citas, contactos, etc, el sistema cuenta con reconocimiento de voz de gran calidad y la propia “voz” de Exchange es un gran avance.
También se puede usar este servicio para modificar nuestras citas.
En caso de que nos llamen a nuestra extensión y no estemos, nos podrán dejar un mensaje de voz que podremos oír desde nuestro Outlook y OWA, podremos introducir notas a la vez que oímos el mensaje para luego poder usar las avanzadas tecnologías de búsqueda de Exchange 2007 para buscar en ellas.
Si queremos podemos indicar al Exchange que reproduzca el mensaje usando nuestro teléfono móvil y así de esta forma evitar que alguien mas lo escuche por los altavoces del ordenador.
Exchange 2007 guarda las extensiones en un atributo del usuario en el AD.
Serán comunes las sinergias de este tipo de servidores con otros del tipo de LCS.
7) Los servidores de buzones.
Aquí es donde residen los buzones de los usuarios, usaremos clusters MSCS para aportar tolerancia a la vez que facilitar las actuaciones en los servidores.
En vez de usar un solo cluster de muchos nodos es aconsejable ir creando clusters de 3 o 4 nodos.
Podremos usar ISCSI o HBAs tipicas contra las SAN, en este caso yo recomiendo esta ultima opción dado el mayor rendimiento actual, si el presupuesto es suficiente, valoraria soluciones multi-path.
Exchange 2007 no permite el esquema activo/activo así que usaremos el Activo/Activo/Pasivo para obtener el mayor equilibrio entre inversión y rendimiento.
Exchange 2007 permite disponer de replicación continua dentro de un mismo cluster, esto nos permitirá disponer de nodos de hardware menor dentro del mismo cluster que repliquen las bases de datos y disponer de ellas en caso de caída o para realizar los backups.
Si disponemos de las comunicaciones apropiadas podemos poner ese nodo en el centro de respaldo.
El dimensionamiento del hardware es esencial en este punto y determinante para el éxito del proyecto.
8 y 11) Clientes.
Exchange 2007 y Outlook 2007 permiten que un puesto se configure solo una vez validado, esta funcionalidad es tremendamente cómoda.
Ya hemos hablado de los diferentes medios que usaran para acceder a sus datos, además hay que tener en cuenta el numero de conexiones que exige el push y el roaming entre wireless y telefonia movil.
9) Frontera del centro de respaldo.
Con el fin de superar algún posible desastre tendremos que contar con un centro de respaldo.
Los centros de respaldo suelen estar mas adaptados a los presupuestos que a las necesidades.
En mi opinión creo que la clave para el diseño de un centro de respaldo, es el equilibrio y la sinceridad, es un punto de la solución en el que hay que aceptar riesgos, si no invertiremos una gran cantidad de recursos.
La mayoría de las empresas aun no han alcanzado una madurez dentro de IT lo suficientemente arraigada y fuerte como para garantizar que la inversión en un centro de respaldo sea eficiente en caso de necesitarlo bajo un entorno de presión.
La falta de procedimientos de emergencia y de simulacros hace que muchos centros de respaldo solo valgan para enterrar grandes cantidades de dinero.
Muchas empresas tienen en sus centros de respaldo el talón de Aquiles de su seguridad.
En esta solución contaremos con un solo firewall externo y si es posible otro interno, usaremos IPSec y vlans para garantizar la seguridad hacia dentro encaminando como única vía de contacto fuera del centro de respaldo los firewalls internos del CPD habitual.
10) DMZ en el centro de Respaldo
En la DMZ del centro de respaldo contaremos con un servidor de maquinas virtuales conectado a un sistema de almacenamiento.
En este servidor residen las maquinas virtuales que sean necesarias para prestar los servicios de Exchange en caso de fallo del CPD principal, el uso de un dispositivo SAN ISCSI permitirá adaptar dinámicamente el CPD de respaldo virtual.
Usando la tecnología ISCSI con discos SATA y maquinas virtuales disponemos de un centro de respaldo con un excelente equilibrio entre inversión y posibilidades.
Evidentemente las maquinas virtuales en este grado de consolidación no podrían dar servicio a un gran numero de usuarios, por esa razón en caso de emergencia dispersaríamos esas maquinas virtuales por el hardware que pudiéramos adquirir con urgencia o bien emplearíamos métodos V2P a través de ADS para convertir las maquinas virtuales en físicas escalando así con rapidez y garantías.
Evidentemente el centro de respaldo tendrá que contar con servidores que repliquen el AD y con otros servicios adicionales.
EL firewall del centro de respaldo también publicara un MX adicional cuyo SMTP estará localizado en una maquina virtual, que permitirá que los correos sigan entrando en caso de caída de líneas del CPD principal o alguna emergencia de mayor grado.
Según el presupuesto con el que contemos usaremos, replicación hardware, replicación de Exchange o copias de seguridad y BDs de recuperación para mantener los datos sincronizados en el centro de respaldo, cumpliendo así con la mayor premisa de todo centro de respaldo, no perder datos en caso de emergencia.
Espero que os gusten algunas de las ideas aquí expuestas y que hayáis aumentado vuestro conocimiento de las funcionalidades que aporta Exchange 2007.
Asuntos de familia y el buen gobierno de IT.
Después de tanto tiempo en esto, he pasado por muchas empresas muchas como consultor, colaborador o asesor y varias como empleado directo, cada una me ha contado sus problemas, y yo las he ayudado a solucionar parte de ellos.
En algún momento todas me han dicho la misma frase, “Tienes que entender que lo nuestro es diferente, es muy particular”, por supuesto que cada empresa tiene sus diferencias, pero en realidad informaticamente hablando y por supuesto dentro de los mismos grupos de sectores y tamaños; ¿son tan diferentes unas de otras?.
Si las necesidades informáticas, no son tan diferentes; ¿Por qué hay tantas diferencias entre los departamentos de IT de las empresas?
Para mí el pilar principal de las diferencias es una simple elección estratégica:
“Lo mejor de cada familia o…… una buena familia”.
Analicemos los prototipos de las empresas según tomen una alternativa o la otra:
Empresas “lo mejor de cada familia”:
Estas empresas se caracterizan por:
Suelen analizar mucho los productos que implantaran, curiosamente suele haber “demasiada gente” en las reuniones para valorar los productos, la decisión final se toma habiendo tenido en cuenta junto a las legitimas y verdaderas necesidades del negocio, supuestos que es poco probable que sucedan, casos de uso anecdóticos, personalizaciones costosas, opiniones no contrastadas, etc.
Las decisiones de compra en estas empresas suelen terminar en “lo mejor de cada familia”, Citrix, WebSphere, SAP, Oracle, Vignette, Chekpoint, Patrol, Tivoli, Remedy, etc.
Aun cuando se escoge la solución adecuada, se suele complicar el proyecto en exceso, especialmente debido a la integración con otros productos y las ya mencionadas personalizaciones costosas y casos de uso improbables, he visto intranets, en las que se han invertido miles de € en secciones usadas una docena de veces en un par de años, pero que fueron fundamentales a la hora de diseñar el proyecto o sustituir intranets de cientos de miles de € por otras desarrolladas en semanas.
Suelen tener hardware muy variado y de varios fabricantes, DELL, IBM, HP, incluso si cuentan con varios sistemas de almacenamiento, es normal que sean de diferentes fabricantes, el hardware sule o ser antiguo o desmesurado, he visto dcs con 4 procesares itanium, o servidores de ficheros con tarjetas de 100mb conectados a concentradores con decenas de GB de capacidad de backbone.
Usan muchos programas de diferentes empresas para tareas muy especializadas.
Cuentan con departamentos normalmente numerosos y con presupuestos elevados y de peso dentro de la empresa, suelen tener un nivel considerable de externalización, los proyectos suelen ser largos y hacerse aun mas largos.
Usan varios sistemas operativos, Windows, Unix, Linux, Solaris, Novell.
Es común encontrar en producción servidores NT, redes Novell antiguas, etc, en un caso vi un Exchange 5.5 usando una SAN de 300.000€, después de tres años desde la compra de la SAN, siguen usando Exchange 5.5, aseguran que “dada su complejidad especial es muy costoso migrar a Exchange 2003”, el problema esta en que el mismo partner que le vende la SAN es el que les hace el proyecto de migración a Exchange 2003, como resultado el proyecto incluye mas SANs, replicaciones con software propietario, herramientas de administración propietarias, etc, etc.
En estas empresas solo se ve la complejidad de IT, apenas se mira el negocio, ni desde el punto de vista de las necesidades reales ni desde el punto de vista del equilibrio coste/calidad.
Son foco de sorpresas como oficinas completas sin DHCP o inversiones alucinantes en proyectos de seguridad, cuando tienen servidores sin parchear desde mas de 10 años.
Suelen estar en manos de sus partners, aunque se sienten protegidos por SLAs y cláusulas y cientos de anexos en los contratos de servicios, no suele existir un arquitecto de infraestructuras o soluciones y no hay nadie fuerte técnicamente hablando en los puestos de mas responsabilidad, por lo que el conocimiento tecnológico solo lo tienen los partners.
Suelen invertir grandes sumas en integrar los sistemas o sea hacer que cada mejor miembro de una familia hable con otro de otra familia.
La mayoría de los proyectos nacen en IT y para IT, e incluso los proyectos que nacen sponsorizados por el negocio, terminan estigmatizados por IT.
Cuando son conscientes de su situación tratan de arreglarlo con grandes proyectos de ITIL y terminan igual, pero con mas burocracia, menos agilidad y en el mejor de los casos un partner nuevo.
Empresas “una buena familia”
Estas empresas están regidas por la coherencia, el equilibrio y la sobriedad.
Aplican un enfoque práctico a todas las decisiones.
Han comprendido que mas iteraciones y mas cortas son una buena forma de trabajar que grandes y ambiciosos proyectos, que IT es un departamento de cambio y que hay que asumirlo y gestionarlo.
Han encontrado en los productos de Microsoft una forma de ahorrar en costes de integración y recursos, esto unido al enfoque práctico de los proyectos, hace que puedan prestar servicios a la empresa de una forma muy agil.
Suelen tener un hardware equilibrado, moderno y normalmente de un solo fabricante básicamente Dell o HP.
He visto casos en los que contaban con hasta 5 veces menos personal que empresas equivalentes.
La externalización no suele ser constante, solo se usa en situaciones de pico de trabajo y proyectos puntuales, después de cada proyecto el conocimiento se suele quedar “dentro”, se tiene poca dependencia de los partners y proveedores.
Suelen contar con algún perfil avanzado técnicamente y los responsables también son técnicos aunque buenos conocedores del negocio y “hombres de empresa”.
Aunque preocupados por los procedimientos y las buenas practicas, no se suelen dejar llevar por la burocracia ni los aspectos no prácticos de las metodologías.
Suelen tener más de un 90% de los sistemas sobre Windows 2003 y suelen mantenerse en la última versión de cada producto, están dentro de un proceso constante de migración.
No se suelen llevar por modas ni tienen complejos.
La mayoría de los proyectos surgen por una necesidad de la empresa.
Conclusiones.
Muchas grandes empresas y organismos públicos trabajan con “lo mejor de cada familia” en el caso de los organismos públicos las normas que los regulan, hacen casi imposible trabajar de otra manera, pero en el caso de las empresas privadas, cada vez son mas los que son capaces de tener una visión a mas largo plazo y darse cuenta de los axiomas que conducen a una gestión de IT de excelencia:
-Completa alineación con el negocio.
-Obsesión por la calidad y por la eficiencia presupuestaria.
-Uso de la tecnología como herramienta y no como sentido del departamento.
-Soluciones prácticas, ágiles, con pocos gastos de integración, mantenimiento y puesta en marcha.
-Comprensión del ciclo de vida de las soluciones.
Desde mi punto de vista profesional, como arquitecto de infraestructuras, cuando una empresa quiere trabajar asi, a día de hoy, solo Microsoft me ofrece una familia de productos que me permiten diseñar una arquitectura integrada y agil, fácil de mantener y llena de ventajas.
Si alguien me pregunta como se transforma una empresa del primer tipo en una del segundo, dire que yo hasta ahora solo soy el arquitecto, y que como tal solo seria la mano derecha del verdadero artifice del cambio, solo un ejecutivo de ideas claras y gran carisma rodeado del equipo adecuado y con el apoyo de su organización, puede realizar una transformación de este tipo, por suerte para mi he conocido al menos uno de estos titanes, y tengo la suerte de poder seguir aprendiendo de el.
Dimensionando Exchange 2007 (lio de cores)
Si piensas en que Exchange 2007 solo correrá sobre procesadores x64 y que por lo tanto la mayoría de las organizaciones tendrán que tirar la casa por la ventana y comprar todo nuevo, llegaras a la conclusión de que hay que pensar muy bien que hardware comprar.
Pocas organizaciones montaran Exchange de forma descentralizada, así que podemos suponer que una organización media-grande comprara del orden de 11 a 20 servidores.
Al ser un conjunto nuevo de servidores, mi opinión es que lo mejor es comprarlos en Blade, mi consejo esta en valorar los Blade de la familia C de HP, que ofrecen a mi parecer un buen diseño y excelente rendimiento (http://h18004.www1.hp.com/products/blades/components/c-class-components.html).
Soy partidario de distribuir los nodos de los balanceos y clusters en dos chasis pero esto esta muy discutido y hay opiniones en todos los sentidos, dado que el chasis practicamente no tiene puntos de fallo.
Siendo realista es muy difícil que el chasis falla, pero aunque sea poco probable si requiriera de un mantenimiento con necesidad de reinicio o apagado, afectaría a los 16 servidores que puede llegar a contener con lo que el 99.999 de disponibilidad pasaría a la historia, la SLA tiene su precio y hay que ser mas suspicaz de la cuenta, pero esto depende de la organización, y tal vez otros proyectos justifiquen la compra de dos chasis.
Todos los procesadores x64 tanto de Intel como de AMD son dual core.
Todos sabeis que Exchange 2003 apenas escala por encima de 4 cores aunque el store.exe puede manejar una afinidad de 8 cores (http://support.microsoft.com/default.aspx?scid=827281).
El otro dia en una reunion con HP hablamos sobre este tema y me quede con la duda de si Exchange 2007 escalaria mas, habia leido que ese problema se mantenia, pero finalmente he investigado y segun parece Exchange 2007 escala bien a 8 cores
El equipo de desarrollo de Exchange nos revela esta tabla sobre el dimensionamiento de los procesadores:
Tendremos mas información para realizar un dimensionamiento correcto leyendo el siguiente parrafo:»
Mailbox Role: The recommended configuration for the Mailbox role is based predominantly on mailbox count and user profile. A 4 x Processor Core server provides a good balance between price and performance and should be able to host several thousand mailboxes. Rule of thumb sizing for the Mailbox server role requires an understanding of the average client user profile.»
Y este otro:
«Rule of thumb sizing used primarily for budgeting purposes can be accomplished by calculating that 1000 Average profile mailboxes will require 1 x Processor Cores. E.g. A 4000 Mailbox server with an Average usage profile can be estimated to require 4 x Processor Cores. A Heavy usage profile will effectively double this calculation (500 Mailboxes/Processor Core). The maximum number of processor cores the Exchange 2007 Mailbox role will efficiently utilize is eight. Deploying Exchange 2007 Mailbox on servers with greater than eight cores will not provide significant scalability improvements. »
En cuanto a la memoria tenemos:
Con lo cual saco las siguientes conclusiones:
Los servidores de 8 cores ocupan un slot completo de un chasis blade o varias Us de los racks, además solo tendrían sentido si tratáramos de gestionar, calculo que unos 6200 usuarios y CCS solo en un nodo, asi que con un cluster A/A/P tendríamos mas de 12.400 usuarios.
Para 6200 usuarios de tipo medio serian 32 Gb de ram por nodo.
Nota para los precios de los servidores, usare precios orientativos de la web de HP de maquinas no blade.
Los servidores de 8 cores son exponencialmente mas caros que los de 4 cores, un sevidor x64 con 4 micros dual core y 32 gb de ram y una HBA pueden costar mas de 20.000€ x 3 nodos = 60.000€ / 12.400 Usr= 4.83€ por usuario, por supuesto no contamos con el almacenamiento que es independiente prácticamente del Nº de servidores que usemos (con la excepción de los fabric)
Un servidor de 2 micros x64 AMD rev F de 2 cores (4 cores) con 12Gb de ram usando CCS creo que tendria que poder mover unos 2800-3000 Usuarios por lo tanto necesitaríamos unos 4 servidores, por arquitectura lo ideal seria crear dos clusters uno A/A/P y un A/P , por lo tanto serian 5 servidores a mas de 7.000€ por servidor = 35.000€, con un coste por usuario de 2.82€ si usamos blades además esta la ventaja de que las maquinas de 2 cores de las ultimas generaciones como el BL465C ocupan medio slot, por que en un chasis entran 16.
Por lo tanto, por facilidad de operación, coste y menor superficie de fallo, en mi opinión es mejor disponer de mas maquinas de menos potencia, decantandome por los servidores de 2 micros y 2 cores, si es posible unos 2800 buzones en 3 bases de datos.
Por supuesto a todo esto tenemos que sumar licencias, mas HBAs si queremos redundancia y el almacenamiento.
Para los que sigan pensando que mejor 8 cores, les recomiendo que vean esta comparativa (http://www.microsoft.com/exchange/evaluation/performance/default.mspx) que se basa en el test MMB3 de benchmark de mensajeria, un 2 micros DC obtiene el record con un indice de 13.500 y un 4DC se queda en 12.000 obviamente esto es por que son dos maquinas de diferente fabricante con diferentes MHZ y buses, pero reflejan que la diferencia no justifica la inversión.
Si alguien piensa preguntarme que si Intel o AMD, de momento no tengo nada que decir, todos conocemos los resultados de opteron y desde luego tiene mi apoyo, pero hasta que me traigan un par de cada para probar y comparar ;-), no tengo una opinión cerrada, sin embargo el palpito me tira por el Intel para los mailbox y AMD para el frontal, edges y UM.
De todas formas os remito una vez mas a la biblia del dimensionamiento de Exchange 2007: http://msexchangeteam.com/archive/2006/09/25/428994.aspx