Grupo de Trabajo IRIS MAIL/32. Salamanca, 15 Junio 2009

Transcripción

1 Grupo de Trabajo IRIS MAIL/32 Salamanca, 15 Junio 2009

2 Reflexiones maenales El correo electrónico se usa mucho mas que ayer y menos que mañana Se ha imbricado en la dinámica de trabajo de toda la sociedad y la toma de decisiones Ahora el problema no es el spam sino el uso y dependencia excesiva. La vida profesional se encuentra almacenada en miles de correo Su evolución no será tecnológica sino de modelos de geseón mas eficientes 2

3 Agenda IRIS MAIL/32 Resultados de "Encuesta externalización de servicios TIC en universidades" Experiencias de suites colaboraevas Zimbra: InsEtuto Nacional de EstadísEca (INE) Open Xchange: Universidad de Salamanca Grupo de Trabajo IRIS MONITOR. Resultados del protoepo Estado final y puesta en macha del Servicio Lavadora 3

4 Nuevos enfoques IRIS MAIL Sesiones por videoconferencia EVO Requisitos: Cámara (no necesaria) Cascos con auriculares y micrófono Estar registrado en EVO (h`p://evo.caltech.edu) Temas a tratar Intercambio de experiencias Tutoriales Cualquier tema de interés general 4

5 Nueva generación de modelos Posibles ideas a pensar Evaluación de un modelo distribuido de Webmal (suite colaboraeva) para toda la comunidad Evaluación de un servicio de Disco Virtual a usuarios para intercambio de ficheros pesados de forma ópema. (Dropbox) 5

6 Actualidad IRIS MAIL Resultados de la Encuesta de externalización de Servicios TIC en universidades 6

7 Actualidad IRIS MAIL Suites colaborativas Experiencias ZIMBRA (INE) Experiencias Open-Xchange (USAL) 7

8 Actualidad IRIS MAIL Servicio piloto monitorización de RedIRIS para servicios de correo electrónico Grupo de Trabajo IRIS-MONITOR 8

9 ObjeEvos El objeevo de esta iniciaeva de RedIRIS Realizar un GT para conocer el interés entre las insetuciones en este Epo de servicios Realizar un protoepo para evaluar las funcionalidades mas demandas en este Epo de servicios Recoger los resultados para desplegar un servicio en producción para la Comunidad RedIRIS 9

10 Historia del Grupo de Trabajo Servicio monitorización nació como una idea dentro del grupo RACE Exposición en IRIS MAIL/30 de Málaga (Mayo 2009) UNIZAR se propuso para poner recursos y desarrollar la maqueta del protoepo: Argos UNIZAR dispuso de un primer protoepo en Noviembre 2009 EVOTutorial de Argos en Febrero 2009 Encuesta de saesfacción Mayo

11 Actualidad IRIS MAIL Desarrollo del Grupo de Trabajo IRIS-MONITOR 11

12 MoEvaciones monitorización externa Muchas insetuciones usan monitorización interna de sus infraestructuras Estos sistemas sólo chequean variables significaevas para los administradores y operadores del servicio Muchos de los sistemas de monitorización forman parte de la misma infraestructura del servicio que monitorizan No se dispone un análisis de lo que realmente perciben los usuarios del servicio 12

13 ObjeEvos generales del GT Monitorizar servicios insetucionales desde puntos deslocalizado de sus infraestructuras Detectar situaciones de alerta en los servicios insetucionales Monitorización geográficamente redundante para evitar falsas alarmas. 13

14 ObjeEvos concretos del GT Monitorización conenua de servicios Emisión de alarmas ante malfuncionamiento de servicios Emisión de informes periódicos de disponibilidad y rendimiento de servicios Panel web informaevo con históricos y estado actual 14

15 ObjeEvos concretos del GT Monitorización periódica de parámetros específicos del Servicio de correo: Chequeos DNS Blacks Lists Chequeos DNS Reverse Lookup Chequeos SPF Records Chequeos DKIM Records Chequeos DNS MX Records Chequeos SMTP Connect Chequeos SMTP AuthenEcaEon Chequeos TLS Check Submit protocol 15

16 Módulos del desarrollo Argos GesEón de cuentas de usuarios Definición de monitores Sistema de chequeos GesEón de alertas Acceso a la información e informes Sistema de gráficos Exportación de datos Creación de paneles de control : Dashboards y API s Otras uelidades 16

17 Agentes de monitorización Argos Los usuarios de una organización acceden a sus servicios desde puntos dispersos de la red y es necesario saber la accesibilidad y velocidad de nuestros servicios desde cada uno de estos puntos. Con Argos se ha desplegado una infraestructura con varias estaciones (Agentes de monitorización) reparedos en disentos puntos de la red que chequean en paralelo los servicios y proporcionan información sobre disponibilidad y *empos de acceso. 17

18 Agentes de monitorización Argos Se recogen los resultados de los chequeos que pueden verses agrupados (media) o individual. Ofrece conenuidad del los chequeos evitando informes de disponibilidad erróneos por mal funcionamiento de algún agente. Un servicio se dará por "caído" cuando mas de la mitad de los agentes lo marquen como inaccesible. 18

19 Agentes de monitorización Argos 19

20 Actualidad IRIS MAIL Pantallazos de la plataforma Argos 20

21 21

22 22

23 23

24 Gráficos embebidos 24

25 Dash Board 25

26 Actualidad IRIS MAIL Conclusiones GT IRIS-MONITOR 26

27 27

28 Resultados La experiencia y resultados del Grupo de Trabajo han sido muy posievos Se ha constatado un gran interés por el servicio de monitorización 40 insetuciones uelizándolo Argos ha sido un extraordinario protoepo Argos es un servicio en desarrollo e inestable aunque seguirá operaevo como hasta ahora Se construirá una solución en explotación mas sostenible, flexible y extendible con carácter general para toda la comunidad 28

29 Agradecimientos Agradecer la colaboración de: Compañeros del Grupo RACE Las insetuciones que han parecipado en este GT aportando ideas, comentarios, mejoras etc. UNIZAR por la disposición de recursos sot/hard y especialmente a Pascual Pérez de UNIZAR que ha desarrollado la plataforma Argos de forma rápida y efeceva 29

30 Actualidad IRIS MAIL Servicio LAVADORA Plataforma Unificada de Correo Electrónico 30

31 Desarrollo Proyecto Mayo 08: Propuesta en Grupo de Trabajo Octubre 08: Desarrollo de Grupo de Trabajo Enero 09: Presentación a la dirección de RedIRIS Abril 09: Evaluación de fabricantes: Spamina y CanIT (Roaring Penguin). SepEembre 09: Se acota el modelo y presupuestos Noviembre 09: Aprobación por la dirección RedIRIS Marzo 09: Concurso de adjudicación Mayo 09: Adjudicación Agosto 09: Puesta en producción del Servicio 31

32 Modelo clásico DNS MX institución Relay institución Relay Lavadora Modelo LAVADORA Consultas LDAP Consultas LDAP Institución Institución

33 Evolución Modelo clásico Consultas LDAP DNS MX institución Relay institución Relay Lavadora Consultas LDAP Modelo LAVADORA distribuido Institución Institución

34 Modelo actual INSTITUCION Internet 34

35 Modelo propuesto Internet INSTITUCION 35

36 Definición del servicio Despliegue de la plataforma Dos años Dos fases Fases de despliegue 1ª Fase: 15 millones conexiones SMTP x día 2ª Fase: 25millones conexiones SMTP x día Tecnología seleccionada: Spamina 36

37 Despliegue del servicio 1ª Fase (SepEembre 2010) Se iniciará con 17 insetuciones que mostraron interés a finales de ª Fase Total: conexiones SMTP 11 universidades + 6 insetuciones Nuevas incorporaciones hasta los 15M 3ª Fase Ampliar infraestructura hasta 25M Evaluar recoger correo de la insetución 4ª Fase Por necesidad evaluar ampliación geográfica de la plataforma 37

38 Condiciones Condiciones de Uso del servicio 2 años mínimo Bloqueo en filtros de reputación Marcado en filtros de contenidos El Servicio se ofrece con: Soporte Nivel 1 a postmasters: RedIRIS 8x5 Soporte Nivel 2 y 3 a RedIRIS: 24x7 Monitorización: 365x24x7 Resolver incidencias del equipo: cambios de hardware etc Medir disponibilidad de componentes Mantener mediciones del caudal de trafico de correo Alertas de ataques 38

39 Esquema de la arquitectura 15/25 M: 13/18 servidores 39

40 CaracterísEcas técnicas Alta disponibilidad y redundancia Panel de control online con múleples opciones. Permite acceder a todas las trazas (Log) de las transacciones de todo el correo de su/s dominio/s. EstadísEcas de tráfico de correo de su insetución. En caso de caída del servidor remoto de la insetución el correo se almacenará durante 3 día aprox. La arquitectura permite ser distribuible en diferentes datacenter en el caso de que fuera necesario 40

41 Opciones del panel control (1) Acceso exclusivo y personalizado para el postmaster de la insetución RedIRIS proporcionará las credenciales, documentación, soporte y cursos para la correcta geseón del panel. ObjeEvo: simplificar al máximo la geseón GesEón a nivel de insetución y por dominio Alta de cuentas de correo integrada con LDAP, descubrimiento por SMTP o de forma manual 41

42 Opciones del panel control (2) GesEón de Listas Blancas y Negras propias para el dominio o cuenta Filtros de contenido por insetución, dominio o cuenta Posibilidad de acevar o desacevar filtros de contenido y/o AnEvirus. Disponibilidad de Logs de correo en modo online con amplia variedad de criterios de búsqueda y posibilidad de exportación para su explotación en estadísecas 42

43 Opciones del panel control (y 3) Diclaimers por insetución y dominio Informes de acevidad de la plataforma para el postmaster con todos los datos por dominio Personalización del panel de control y de los informes con el logo de la insetución 43

44 Esquema de filtrado RBLs ANTIVIRUS (ClanAV) Filtros de reputación Lista Blanca de RedIRIS Listas de reputación individuales SPF SENDER DOMVAL RECIPIENT CALLOUT (SMTP, LDAP, PROMO) MOTOR DE REGLAS BOGOFILTER SPAMASSASSIN SPAM / VIRUS Filtros de contenidos GREYLISTING DELAY ENTREGA CORREO LIMPIO 44

45 Filtros de reputación RBLs Lista Blanca de RedIRIS Listas de reputación individuales SPF SENDER DOMVAL RECIPIENT CALLOUT (SMTP, LDAP, PROMO) GREYLISTING DELAY 45

46 Arquitectura de filtrado: Reputación (1) Acción: Bloquear/retrasar y almacenar trazas en ficheros de Log Los filtros de reputación asegurarán la validez y reputación del origen de un correo. Cuando el sistema esté seguro que dicho origen es malicioso la conexión SMTP será bloqueada y dejará traza (From:,To:,Subject: Y Date:) en los ficheros de log de cada dominio. 46

47 Arquitectura de filtrado: Reputación (2) Se uelizarán diferentes tecnologías de verificación de la reputación del origen: Listas Negras (RBLs). Acción= Bloqueo Se chequearán varias RBLs ampliamente conocidas (IRISRBL, spamhaus.org, bl.spamcop.net, cbl.abuseat.org, dnsbl.sorbs.net, dnsbl.njabl.org). Para reducir el número de falsos posievos sólo se se bloquearan las incluidas un 40% de las RBLs chequeadas GreylisEng: Acción= Retardo Lista blanca de RedIRIS. Acción= PermiEr No se bloquearán las IPs incluidas en la lista blanca de RedIRIS 47

48 Arquitectura de filtrado: Reputación (3) Chequeos SPF (Sender Policy Framework). Validación del dominio del emisor. Se comprobará la existencia de registros MX en los dominios emisores para garaneza la entrega de correo Verificación del cumplimiento de diversos protocolos SMTP Control estricto de la validez de los desenatarios de los mensajes usando LDAP o SMTP. Sólo se entregará correo desenados a usuarios existentes en el dominio 48

49 Arquitectura de filtrado: Contenidos Acción= Marcado Filtro AnEVirus. ANTIVIRUS (ClanAV) Motor de Reglas. Filtros HeurísEcos y Bayesianos. MOTOR DE REGLAS SPAM / VIRUS Filtros de contenido personalizables. BOGOFILTER SPAMASSASSIN ENTREGA CORREO VÁLIDO 49

50 Opiniones? dudas? 50