Notas del Mundo Real 2.0

Ayer (08 de Diciembre de 2010) se cumplió un año desde la liberación de Exchange Server 2010, y como toda guagua (así les decimos en Chile a los bebés) ha crecido MUY rápidamente y ha aprendido muchas cosas nuevas: ya tiene un Service Pack en el cual fueron incluidas nuevas funcionalidades 😉

Les dejo como referencia los posts (en inglés) del Grupo de Producto de Exchange y del Grupo de Producto de Comunicaciones Unificadas en celebración

Si eres de Chile y aún no eres parte del 25% de las empresas que ya migraron sus antiguas versiones a Exchange 2010, te invito a asistir a la conferencia técnica que daremos el próximo 21 de Diciembre en MS Chile:

• Migrando a Exchange 2010: Bien y a la Primera! (Trucos desde las trincheras)

Gonzalo

Hola. Hace unos post atrás les comenté sobre el Analizador de Conexión Remota, y lo útil que resulta para realizar pruebas y resolver problemas de conectividad desde clientes externos o móviles hacia servidores Exchange. Ahora vuelvo a escribir pues esta herramienta gratuita fue liberada en idioma Español.

Lo único que debes hacer es tener configuradas las opciones de idioma (en español) en tu navegador favorito y cuando accedas a la página www.testexchangeconnectivity.com encontrarás los menús, opciones y resultados en español.

Selección de Test:

Resultado del test:

Ahora, sólo tienes que comenzar a usarla

Gonzalo

Amigos, hoy 17 de noviembre estaría de cumpleaños Emerson González, recientemente fallecido MVP de Forefront, con quien tuve la oportunidad de compartir  en el ámbito de las charlas organizadas por este servidor y patrocinadas por distintos grupos de usuarios de Chile. Además, tuve la posibilidad de compartir con él una conferencia técnica en Microsoft el 14 de abril de 2009 llamada: "Herramientas Gratuitas Microsoft: Mejorando la seguridad y facilitando la administración”.

Puesto que muchas de estas herramientas están vigentes o han evolucionado durante este tiempo, y como forma de recordar la labor que Emerson realizó para las comunidades técnicas, es que creo pertinente dejarles la presentación (slides al final del post), así como los links a la grabación del evento y un link desde donde pueden descargar el material utilizado durante la presentación.

• Grabación Conferencia Técnica.
• PPT y Material Entregado durante la conferencia.

 

Un saludo a todos quienes leen este blog, pero muy especialmente a la familia de Emerson.

Gonzalo.

Hace unas semanas atrás, junto a Jorge Díaz (MVP en Exchange) dimos un webcast de la serie IT Manager sobre cómo ahorrar costos en las empresas utilizando las nuevas funcionalidades que trae Exchange Server 2010.

Aunque más abajo les dejo las slides utilizadas, les recomiendo que le den una mirada al webcast, pues fue bastante atípico y entretenido

WEBCAST: Ahorrando costos con Exchange 2010

 

Espero que les sea de utilidad y como siempre cualquier pregunta es bienvenida.

Gonzalo

Aquí les dejo la presentación de la charla que dimos junto a Pablo Campos para el evento Techdays 2010, los temas tratados fueron:

• Arquitectura de Hyper-V
• Alta disponibilidad en Hyper-V
• Memoria Dinámica SP1
• Inter-operatividad e Integración con Linux
• Versiones y Licenciamiento

Gonzalo

Hola a todos.

Por segundo año consecutivo se realizará el evento Techdays Chile. Este año nuevamente estaré presente con una charla de virtualización, junto a un partner de lujo: Pablo Campos, MVP en Virtualización

En esta charla revisaremos conceptos y recomendaciones de Diseño e Implementación de Hyper-V en Alta Disponibilidad, pero nos centraremos en las nuevas características que trae el SP1 de Windows Server, con mucha demo

Instalación de los Integration Services 2.1 de Linux sobre Hyper-v
Memoria Dinámica en el SP1

 

 

IMPORTANTE: Para quienes no puedan asistir presencialmente, pueden seguir la transmisión en vivo en www.techdays.cl

Nos Vemos!

Gonzalo

 

NOTA: Este post fue publicado originalmente en mi anterior blog el 24/08/2007.  Hice algunos cambios, modificaciones y adiciones para actualizar y mejorar el artículo

 

Hoy recibí el llamado de un amigo preguntándome cuales proveedores de listas negras yo uso.

Update: Hace un par de días, a través de las Comunides Técnicas MS en Chile recibí una solicitud para actualizar este artículo y escribir su segunda parte 🙂

Una de las opciones de filtrado de mensajes por conexión que nos ofrece Exchange 2003 (y versiones superiores) es el uso de RBL’s. (En Exchange 2000 había que usar productos de terceros o add-ons para poder usarlas).

Desde el punto de vista del administrador de un servidor de correo, las listas negras pueden ser un gran aliado, o un gran dolor de cabeza si caes en una :(.

Nota: al final de este artículo hay un pequeño procedimiento para salir de ellas

Veamos Por Qué.

1. Qué son las listas negras?

Para quienes no lo sepan, las listas negras (Black List), o RBL’s por Real Time Block/Black List, son Bases de Datos que contienen listados de direcciones IP’s pertenecientes a servidores de correo que han sido detectadas o reportadas como Open Relay, o que envían Spam.

2. Cómo Funciona el uso del filtrado de conexión usando listas negras?

Cada vez que llega una conexión SMTP a nuestro servidor, éste realiza una consulta de DNS reverso a su proveedor de lista negra, preguntando por la dirección IP del servidor de correo que está tratando de entregarnos un mensaje.

Por ejemplo, si el servidor que está estableciendo conexión a nuestro servidor de correo tiene una dirección 192.168.8.2, y nuestro proveedor de listas negras es odioelspam.org, entonces nuestro servidor Exchange hará una consulta de DNS Reverso de la forma: 2.8.168.192.odioelspam.org.

Nuestro proveedor de listas negras nos dará una respuesta, la cual podría ser:

• «Host Not Found«: indicando que la IP del servidor que nos está tratando de enviar un correo NO ESTÁ en su base de datos.
• «127.0.0.Código«: El proveedor no está indicando que la dirección IP del servidor que nos está tratando de enviar un correo SI ESTÁ en la Base de Datos. El «Código» que viene en la respuesta varía de proveedor en proveedor, no hay un estándar, pero generalmente indica el tipo de «abuso» con que se ha registrado la dirección IP en la lista negra (spam, masivo, open relay, etc). Consulte la documentación de su proveedor 😉

Si la dirección IP del Servidor que nos está tratando de enviar correo está en la lista negra, entonces nuestro servidor Virtual SMTP entregará un código de error 550 5.x.x como respuesta al comando RCPT TO.

Personalmente recomiendo utilizar más de un proveedor de Listas negras. Se puede establecer el orden en el que serán consultados.

NOTAS IMPORTANTES:

1. Puesto que este es un filtrado de conexión, el mail no es recibido, por lo que no se (mal)gastan recursos de red ni de máquina (procesando por virus o spam en otros niveles).
2. Este filtrado aplica sólo a nivel de Servidor Virtual SMTP, es decir, no sirve para mails internos enviados por MAPI (Outlook), OWA, RPC sobre HTTPs, etc.
3. Esta técnica es bastante efectiva, pues cuando recibimos mails de un servidor que envía spam, generalmente nos trata de enviar MUCHOS mensajes en la misma conexión (tratando de hacer un ataque de Directory Harvest), por lo que me basta con sólo una consulta al proveedor de RBL’s para bloquear MUCHOS mensajes que provengan de la misma dirección IP.

3. Cuánto Cuestan?

Hay proveedores de Listas Negras pagados, pero también hay proveedores gratuitos, como SpamCop.Net y SpamHaus.org.

La principal diferencia entre un servicio gratuito y uno pagado radica en la velocidad con la cual se actualizan las bases de datos y en la posibilidad de poder descargar una réplica local de la Base de datos (zona DNS Reversa) del proveedor, con lo cual puedes acelerar mucho el tiempo de respuesta a las consultas.

4 . OK. Se ven Bien, pero, Aplican a la Realidad Latinoamericana?

Esta es una pregunta que yo me estuve haciendo mucho tiempo, y la respuesta es… Claro que Si!!

Update: últimamente ya aparecen países de América latina en la lista de  las principales fuentes de spam en el mundo , y mucho del spam que se genera llega a “nuestros” servidores.

Cuánto es mucho?
Para motivarlos un poco más a que utilicen el filtrado de conexión basado en listas negras, les muestro las estadísticas (reales), sacadas mientras escribo este artículo, desde un servidor en producción configurado con los 2 proveedores gratuitos ya mencionados:

• Consultas DNS Realizadas Block List: 30.510
• Conexiones Rechazadas debido a Reglas de Block List: 18.549

El 60% de las conexiones que se tratan de establecer con este servidor Exchange son rechazadas debido a que las IP’s están en listas negras!!!

5. Bonus: Yo soy Administrador de un servidor de correo y creo estar en una lista negra. Qué Hago?

El procedimiento para salir de una lista negra es bastante simple:

1. Primero: debe saber en cuáles listas estás metido, y por qué.  Puedes revisar al final de éste artículo, la sección correspondiente a las listas negras y cómo saber en cuales estás 😉
2. Segundo: debes resolver tu problema (generalmente debido a opciones de relay mal configurado o de equipos en tu red, posiblemente infectados con virus, que están enviado spam).
3. Tercero: debes comunicarte con el administrador de las listas negras en donde estabas metido, para contarles (generalmente mediante un formulario de contacto) que ya solucionaste tu problema y que te quite de la lista.
4. Esperar… a que seas removido de la lista.

 

Espero haber podido explicar qué son, como funcionan y los beneficios de usar filtrado de conexión basados en Listas Negras (RBLs). En un próximo artículo, les muestro cómo y dónde se configuran estas opciones en Exchange Server 2003

Update: y en Exchange 2007 y 2010!

Gonzalo

Como es de conocimiento mundial, el 27 de febrero hubo un “mega-terremoto” con devastadoras consecuencias, tanto en pérdida de vidas humanas como en pérdidas de miles de hogares y cuantiosos daños a la infraestructura pública.

En lo estrictamente informático, esto trajo muchas consecuencias, como las que revisa Luis Montenegro en su blog sobre planes de contingencia, pero una de las consecuencias más importantes que el Gobierno de Chile determinó retrasar el cambio de horario de invierno, el cual se aplaza desde la media noche del sábado 13 de marzo (cuando debiese ocurrir) a la medianoche del sábado 3 de abril (nueva fecha)

Microsoft liberó un hotfix que actualiza los sistemas operativos para este cambio de horario, el cual puede ser descargado en la siguiente dirección:

• http://support.microsoft.com/kb/981128/es

Le recomiendo leer detenidamente la información referente al hotfix y luego solicitarlo desde el link “Ver y Solicitar la descarga de la revisión” que aparece al inicio de la página. Se recomienda instalar la actualización lo antes posible.

 

Aprovecho la oportunidad para responder un par de preguntas que ya he recibido:

1. ¿Cómo se aplica el hotfix en un entorno virtualizado con Hyper-V?
   El Hotfix DEBE ser aplicado tanto en la partición padre (host) y como en las particiones hijas (guests). Hay que tener cuidado con las máquinas virtuales que están sincronizando la información de horas con con el host de virtualización.
2. ¿Cómo afecta este cambio a los Usuarios/Administradores de Exchange Server?
   Las citas del calendario se verán desfasadas 1 hora durante el período entre el 13 de marzo y el 3 abril.
   Una vez aplicado el hotfix, hay 4 formas para enfrentar esto:
   A. No hacer nada, y decir a los usuarios que confirmen sus reuniones por mail o por teléfono.
   B. Pedir a los usuarios que revisen y re-programen manualmente sus reuniones para ese período de tiempo.
   C. Utilizar la herramienta “Time Zone Data Update Tool for Microsoft Outlook” en cada estación de trabajo.
   D. Utilizar la herramienta “Microsoft Exchange Calendar Update Configuration Tool” , con la cual se pueden actualizar las citas en el calendario centralizadamente, pero ojo, pues es un proceso complejo.
   Como pueden ver, hay varias opciones y la mejor dependerá de su entorno particular (cantidad de usuarios, uso de outlook para calendarios, etc.)

Más información:

• Información más detallada pueden encontrarla en este post del grupo de soporte para latinoamérica (En Inglés)
  http://blogs.technet.com/latam/archive/2010/03/11/guidance-for-chile-dst-changes-effective-saturday-march-13-2010.aspx
• Información en Español desde el sitio de MS Chile:
  http://www.microsoft.com/chile/cambiodehora/

Cualquier duda pueden hacerla como comentario, o a través de la lista de distribución del Grupo Latinoamericano de Usuarios de Exchange (G.L.U.E.)

Gonzalo

• Cómo enviar Correo Eletrónico a mano, Parte I.
• Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado
• Cómo saber si tu servidor de correo permite Relay?:
  • Qué es el Relay, distinguiendo entre «Relay Bueno» y «Relay Malo».
  • Cómo verificar manualmente que nuestro servidor no permita Relay
• Verificando las opciones de Relay en Exchange 2000/2003 (Exchange Blog Latino): Verificar en nuestro servidor y desde internet usando herramientas en línea, que no seamos un Open Relay.

Ahora, me gustaría hablar un poco sobre cómo efectivamente y de forma «segura» permitir el Relay (Reenvío) a través de nuestro servidor SMTP.

La pregunta obvia es: Por qué razón alguien querría permitir Relay en sus servidores de correo?
Razones pueden haber varias: Clientes de correo qué sólo poseen compatibilidad para POP3/IMAP4 necesitarán un servidor de correo SMTP para enviar mensajes (Por ejemplo, aún hay dando vueltas clientes de correo antiguos o dispositivos móviles y PDAs que no soporten ActiveSync.), usuarios que viajan, etc.

La esencia del Relay Bueno es que sólo permitiremos el envío de correo para los usuarios del dominio que se autentifiquen con nuestro servidor de correo. En el artículo sobre Cómo enviar Correo Electrónico a mano, Parte II: SMTP Autenticado, vimos este comportamiento. Ahora les mostraré cómo hay que configurar el Servidor para que funcione de ésta forma.

Paso 1. Cerrar el Open Relay

En Exchange 2003 el Open Relay viene cerrado por defecto. De todas formas, les sugiero comparar la configuración de su servidor con la mostrada en éste artículo:

Verificando las opciones de Relay en Exchange 2000/2003.

Paso 2. Permitir el Relay SOLO a Usuarios Autenticados

En las propiedades del servidor Virtual SMTP (Exchange System Manager -> … -> Servidor -> Procolos -> SMTP -> SMTP Virtual Server), en la lengüeta Acceso (Access) presionamos el botón de Autenticación (Autentication). Tendremos un par de ventanas como las del siguiente dibujo:

En la ventana de Autenticación, deben estar seleccionados los 3 checkboxes principales (como muestra la figura).
Ahora presionamos el botón Usuarios (Users) y se abrirá una nueva ventana.

En esta nueva ventana debemos dejar solamente el grupo de Usuarios Autenticados (Authenticated Users), con los permisos de Enviar (Submit) y Reenviar (Relay).

En este último paso realizamos la configuración más importante: le dijimos al servidor smtp que los usuario autenticados y sólo éstos (es decir, los usuarios que se identificaron exitosamente con su nombre de usuario y contraseña al establecer la sesión smtp), pueden reenviar correo a través de este servidor smtp a direcciones que no pertenecen a la organización (dominio smtp).

Luego cerramos todas las ventanas y reiniciamos el servicio SMTP para que se apliquen los cambios.

Finalmente, debo recordar que toda la información de usuarios y sus claves que se envían al servidor smtp (y al pop3 y al imap4), viajan en texto plano (o codificadas en Base64), por lo que es trivial con un sniffer poder obtener estas contraseñas.
En Consecuencia, es recomendable usar otros protocolos de envío/recepción de correo (Mapi, RPC sobre HTTP(S), HTTPS, ActiveSync, HTTPS, etc), o al menos cifrar las comunicaciones a estos servicios usando TLS (con certificados digitales para cada protocolo).

Gonzalo

 

Muchas veces nos hemos encontrado con que al reiniciar servicios éstos se quedan “colgados” en estado “deteniendo” o “iniciando”.

Una forma para detener realmente estos servicios (o aplicaciones) es usando el par de comandos: tasklist y taskkill.

Nota para mis amigos Linuxeros: cualquier parecido con ps/kill es sólo coincidencia… supongo… :p

Los pasos son bastante simples:

1. Elegir el Objetivo.

Para poder usar taskKill necesito conocer el ID de proceso que quiero “eliminar”. Este proceso puede ser una aplicación o puede ser un servicio. Si estoy usando Windows 2008/R2 me basta con ir al administrador de tareas y en la lengüeta de “Procesos” o “Servicios” y leer desde ahí el Si es una aplicación es bastante fácil, pues me basta con ir al administrador de tareas (taskmanager) y obtener desde ahí el número de Proceso, o PID (Process ID).

Pero si estoy usando Windows 2003 Server, obtener el PID de un servicio es un poco más complejo.

A. Ejecutar desde la línea de comandos: tasklist. se obtiene una respuesta como la siguiente:

para poder filtrar por el nombre del servicio podemos usar el comando findstr para que busque el nombre del servicio “spool” en en la salida:

tasklist | findstr spool

y obtenemos el número del proceso: 1312

(si, ya se que parece powershell, pero en realidad no es nada nuevo!)

2. Dispara!

Ya sabemos que queremos pasar a mejor vida el proceso 1312, así que ahora simplemente ejecutamos:

taskkill /PID 1312 /F

Notas:

• El modificador /F es para “Forzar” la finalización del proceso.
• Como siempre es posible invocar los comandos seguidos de un “/?” para conocer todas las opciones.
• En el caso de eliminar un proceso con taskkill, solamente terminamos su ejecución, no estamos “borrando” el proceso, éste se volver a ejecutar cuando demos inicio nuevamente al proceso manualmente (más abajo) o al siguiente reinicio.

IMPORTANTE: este comando debe ser ejecutado con privilegios de administración, o con una interfaz de comandos ejecutada como administrador

 

De esta forma terminamos definitivamente con el proceso problemático, y ahora es posible darle inicio nuevamente usando el comando:

net start <nombre_proceso>

 

 

 

 

 

Finalmente, el servicio volvió a subir, pero esta vez con un nuevo PID, es decir, es un nuevo proceso para el sistema:

Espero que les sea de utilidad.

Gonzalo