jueves, 26 de abril de 2018

INGENIERÍA SOCIAL...


Cuando blindar sistemas informáticos no lo es todo... 







En el día de hoy son muchas empresas las que contratan personas con conocimientos avanzados, en el área de pentesting y hacking ético. Para fortalecer su esquema de seguridad y/o identificar aquellos huecos o vulnerabilidades que puedan existir en su red empresarial.
Sin embargo, la moraleja es bien sencilla no importa la tecnología de la que se dispone o cuán cara es esta, mientras intervenga el factor humano, el sistema sigue siendo vulnerable.

El usuario es el eslabón más débil de la seguridad.




El relato anterior nos lleva a hablar de la ingeniería social. Un conjunto de técnicas psicológicas y habilidades sociales que, utilizadas de forma consciente y muchas veces premeditada, permite la obtención de información, o recursos de terceros. Lo que se hace después con la información conseguida no tiene límites, aunque eso ya no entra dentro de la ingeniería social. Por ello, en lo que respecta al mundo de la informática, es posible que un ingeniero social nunca toque un ordenador ni acceda a ningún sistema.

Se han dado casos en los que tampoco es necesario que el ingeniero social trabaje la confianza de sus víctimas o las manipule, ya que puede aprovechar datos que están a la vista como un post IT en un escritorio, las notas de una libreta, los mensajes que se ven en la pantalla de un teléfono móvil o incluso buscar en la basura (un método conocido como trashing). Dicho de otra manera, puede obtener datos sin ejercer ningún tipo de presión, lo cual se traduce en que, en estos casos en particular, no estaríamos hablando de una técnica de engaño, sino de aprovechar el descuido ajeno.

Actualmente la ingeniería social es uno de los vectores de ataque más peligrosos y que más se está utilizando para acceder a las redes de las organizaciones, haciendo uso de los empleados de las propias organizaciones.
La ingeniería social se compone de técnicas de engaño de todo tipo, tanto en el mundo físico como en el virtual, y se basa en tres principios básicos de las relaciones humanas:
  • El primer movimiento es siempre de confianza hacia el otro.
  • Todos queremos ayudar.
  • No nos gusta decir No.

Supongamos que una persona del departamento de contabilidad está trabajando en los asientos que tiene que reflejar para que cierren el balance y recibe una llamada telefónica:




Este tipo de llamadas intentan jugar con los principios que comentábamos. La persona está ocupada, no tiene mucho tiempo disponible, y recibe una llamada de alguien que dice ser del departamento de informática de su empresa, que le pide su colaboración. ¿Por qué va a dudar de que le estén mintiendo?
Evidentemente nadie debe dar su contraseña de acceso. Pero, ¿y si el atacante consigue que alguien por falta de precaución o por ganas de colaborar en exceso la proporcione? Es cuestión de probar.

Caso Ubiquiti Networks y la ingeniería social inversa

Ubiquiti Networks es un proveedor estadounidense de servicios de redes de alto rendimiento para empresas. En 2015 sufrió un ataque que le hizo perder 39.1 millones de dólares. Para ello, los cibercriminales escribieron algunos correos haciéndose pasar por miembros ejecutivos de la empresa, y pidieron a algunos empleados del área financiera que realizaran transferencias de grandes cantidades de dinero a una cuenta bancaria en particular. Como era de esperar, esta era propiedad de los cibercriminales. Esta técnica de ingeniería social se aprovecha de ciertas debilidades del ser humano, como es el hecho de ser servicial, ya que eso podría incidir en el reconocimiento por parte de los superiores. También se beneficia en que hay muchas personas que son incapaces de negarse a hacer algo que, pensado fríamente, podría resultar perjudicial. Nadie se metió dentro de los sistemas informáticos de Ubiquiti Networks, tampoco robaron los datos de la compañía. En este caso, la brecha de seguridad estaba en los propios empleados, que carecían de la formación, y desconocían los procedimientos necesarios para protegerse ante este tipo de estafas.

Como vemos, para que la seguridad forme parte de la cultura de la empresa no es suficiente con crear normas y procedimientos, ni con implantar medidas técnicas de seguridad. Es necesario que el personal de las empresas conozca este tipo de estrategias cada vez más usadas por los ciberdelincuentes e informar a los empleados de cómo deben tener presente la seguridad en el desempeño cotidiano de sus funciones: concienciar y formar ya que para ellos “eso no existe” “solo se ve en películas” etc...
Porque están expuestos a muchos factores de riesgo como integrantes de la organización, y porque son fundamentales en el planteamiento de ciberdefensa de la información de su empresa. Como se mencionó anteriormente en este artículo “mientras intervenga el factor humano” siempre existirá esa brecha, que permita utilizar la ingeniería social. No con esto se quiere decir que se deba sustituir el trabajo humano por uno robotizado.

Una vez cometida la falta por parte de ellos y viendo que perjudica no solo su trabajo, sino el de sus compañeros y los jefes de la organización es allí en donde se dan cuenta, que sus acciones y la información que transmitan y comparten es sumamente delicada.


Juan Fernández.
Analista I/ Proyectos Junior.
Servicios de Proyectos y Consultoría SGSI 0526








viernes, 9 de febrero de 2018

Pasos para implementar mecanismo de validación SSO en redes empresariales con AD y WatchGuard








La importancia de establecer un mecanismo de validación conjugando simplicidad para el usuario sin perder de vista el esquema de seguridad en la red empresarial, debe ser un pilar fundamental en toda organización. Por eso, hemos querido aportar con este documento técnico los pasos a seguir para lograr la sinergia deseada utilizando nuestro servidor Microsoft Active Directory con la herramienta de validación SSO de WatchGuard Technologies con los dispositivos Firebox. Recuerde acceder a su portal WatchGuard y descargar las herramientas necesarias, contar con las actualizaciones a nivel de servidor Active Directory:


  • WG-AuthenticationGateway.exe
  • WG-Authentication-Client.msi



Verificar los requisitos de red.
Antes de configurar SSO para su red de usuarios, verifique que la configuración de red sea compatible con todos los requisitos necesarios.

Directorio Activo
  • Debe tener un servidor de Active Directory configurado en su red local de usuarios.
  • Su Firebox debe estar configurado para usar la autenticación de Active Directory.
  • Cada usuario debe tener una cuenta de usuario en el servidor de Active Directory.
  • Cada usuario debe iniciar sesión con una cuenta de usuario de dominio para que SSO funcione correctamente. Si los usuarios inician sesión con una cuenta que solo existe en sus computadoras locales, sus credenciales no se verifican y el Firebox no reconoce que están conectados.
  • El Agente de SSO y el Monitor de Registro de Eventos (ELM) deben ejecutarse como una cuenta de usuario en el grupo de seguridad Usuarios de dominio o Administradores de dominio
  • Si la cuenta de usuario está en el grupo de seguridad Usuarios de dominio, debe tener privilegios para ejecutar servicios en el servidor de Active Directory, buscar en el directorio y buscar toda la información de auditoría de otros usuarios.
  • Todas las computadoras desde las cuales los usuarios se autentican con SSO deben ser miembros del dominio de Active Directory con relaciones de confianza ininterrumpidas.
    • Las computadoras Mac OS X deben unirse al dominio de Active Directory antes de poder instalar el cliente SSO.
    • El Monitor de Exchange debe ejecutarse como una cuenta de usuario en el grupo de seguridad Admins. Del dominio.

    Notas previas:  Al momento de la instalación del WatchGuard Autentication Gateway (WAG), la opción Event Log Monitor (ELM) vendrá deshabilitada por defecto, habilítela y seguir con la instalación.

    Para implementar el SSO los computadores los clientes deben tener habilitados los accesos a los puertos NetBIOS (TCP/UDP 137, 138 y 139) y Samba (puerto TCP 445). NetBIOS habilita los puertos descritos si "File and Printer Sharing" está habilitado en el equipo cliente, al igual que Samba.
    Si no se habilita el puerto TCP 445, se obtendrá como resultado este error en el Traffic Monitor de nuestro dispositivo Firebox:



Más adelante se explicará de forma detallada los errores más comunes, y como solucionarlos.

 - Si se utiliza el cliente WatchGuard para las computadoras, es necesario habilitar el puerto 4116 (Esto a partir de la versión 11.10). Sólo es compatible con Windows 7,10, server 2007 (superiores).

 - El equipo donde se instalará el agente SSO debe tener instalado el paquete Microsoft .NET Framework al menos 3.0   o versiones superiores

1) Configurar el servidor SSO en el Firebox. - En Policy Manager --> Setup --> Authentication --> Authentication Settings. Allí configurar la dirección IP del Servidor que llevaría el Agente SSO. - Configurar posibles excepciones a la aplicación de SSO. 

2) En el servidor Controlador de Dominio con Active Directory Crear un usuario (sugerido y como ejemplo: sso_user). - Aplicar al usuario la propiedad "Password never expires". - Incluir como miembro del grupo "Domain Admins" y que este sea el primario para dicho usuario. - Permitir al usuario la validación para ejecutar un "Servicio". Administrative Tools\Domain Security Policy\Security Settings\Local Policies\User Rigths Asignment\Logon as Service --> Agregar el usuario creado con detalle del dominio (dominioX\sso_user).  

3) Instalará el agente SSO en el controlador de Dominio (Por defecto: WG-AuthenticationGateway.exe). - Realizar instalación típica Windows. - En la ventana que solicita los datos de validación (nombre de dominioX\usuario y contraseña) del usuario ingresar los del usuario creado (dominioX\sso_user).

¡Importante!: No agregar la parte secundarias del dominio como .com, .local, .net, etc.   
   
- Al concluir la instalación, en la consola de "Servicios" de Windows podrá ver un nuevo servicio con nombre "WatchGuard Authentication Gateway". 

4) Crear un Group Policy Object en la consola de políticas del controlador de dominio.

 - Crear una carpeta compartida para alojar el instalador del cliente para las PC's (\\domain_controller\Folder \WG-Authentication-Client.msi). Además, se le debe dar privilegios a los grupos que contengan los usuarios a quienes se les aplicaría el método SSO al trabajar con el Firebox (Nota: Esto debería coincidir con los definidos en el Firebox provenientes del Active Directory). 

- Editar la política de grupo creada en el domain controller y realizar la siguiente configuracion: User Configuration\Software Settings\Software Instalation" Buscar la ruta "compartida"(\\domain_controller\Folder\) donde se aloja la instalación del cliente WatchGuard .MSI y seleccionar dicho archivo (WG-Authentication-Client.msi) en modo "Assigned". 

- Al volver a la consola de Group Policy agregar en "Security Filtering" los grupos que contienen los usuarios para aplicar la instalación remota. (Nota: estos grupos deberían coincidir con los definidos en el Firebox para realizar la autenticación contra Active Directory). - Ejecutar en la línea de comandos gpupdate /force

Uso de la herramienta SSO port tester

Para verificar que el agente SSO pueda contactar al Event Log Monitor y Exchange Monitor a través de los puertos requeridos, puede usar la herramienta SSO Port Tester . Esta herramienta prueba la conectividad del puerto entre el servidor donde instaló el agente de SSO y además:
  • Rango de direcciones IP
  • Dirección IP única
  • Subred específica
  • Lista de direcciones IP específicas.
  1. Inicie sesión en la Herramienta de configuración del agente de SSO.
  1. Seleccione Edición> Configuración de contactos del agente SSO .
  1. Haga clic en Probar puerto SSO . 

  1. En la sección Especificar direcciones IP , seleccione una opción:
    • Rango de dirección IP del host
    • Dirección IP de red
    • Importar direcciones IP
  1. Si seleccionó el Rango de la dirección IP del host , en los cuadros de texto Rango de la dirección IP del host , escriba el rango de direcciones IP para probar. Para probar una sola dirección IP, escriba la misma dirección IP en ambos cuadros de texto.
    Si seleccionó Dirección IP de red , en el cuadro de texto Dirección IP de red , escriba la dirección IP de red para probar.
    Si seleccionó Importar direcciones IP , haga clic  y seleccione el archivo de texto sin formato con la lista de direcciones IP para probar.
  1. En el cuadro de texto Puertos, escriba los números de puerto para probar.
    Para probar más de un puerto, escriba cada número de puerto separado por una coma, sin espacios.
  1. Haga clic en Prueba.
  2. Para guardar los resultados de la prueba en un archivo de registro, haga clic en Guardar registro y especifique el nombre y la ubicación del archivo para guardar el archivo de registro.

  3. Para detener el proceso de la herramienta del probador del puerto, haga clic en Salir .

Mensajes de errores comunes.

Acceso denegado
Puede ver este mensaje de error si:
  • Hay dispositivos en la red que no son computadoras, por ejemplo, impresoras y enrutadores (recuerde agregarlos en la lista de excepciones)
  • Hay computadoras u otros dispositivos en la red que no son miembros del dominio
  • Un usuario proporcionó credenciales de dominio no válidas para SSO
  • Los servicios de SSO en el servidor o la computadora no tienen privilegios de administrador
Para solucionar este mensaje de error:
  • Verifique que la relación de confianza entre la computadora de dominio y el controlador de dominio sea correcta. Si hay un problema de membresía en el dominio, elimine la computadora del dominio y vuelva a agregarla al dominio.
  • Para confirmar que se resuelve el problema de membresía del dominio, intente conectarse a un servidor miembro de dominio en su red a través de una ruta UNC.
    Por ejemplo, si el nombre de su servidor de archivos es CompanyShare , en el símbolo del sistema de Windows, escriba \\ CompanyShare . Si no puede obtener acceso a esta carpeta y aparecen los mensajes de error de los permisos de Windows, verifique estas configuraciones en el servidor de Active Directory: configuración de la computadora, configuración de la cuenta de usuario y la relación de confianza.

  • A continuación se puede apreciar un ejemplo:

Usuario desconocido
Este error puede ser causado por:
  • Archivos de registro de eventos que no existen o están llenos
  • Una computadora que no es un miembro del dominio
  • Iniciativas de conexión SSO intentadas por usuarios RDP cuando necesita actualizar su software de componente SSO

    Debe ejecutar v11.10 o superior para que los usuarios realicen una conexión RDP con SSO.
  • ID de eventos de Windows que no son compatibles con los componentes WatchGuard SSO


Clientes SSO con Event Log Monitor
  • El puerto TCP 4135 está abierto en el controlador de dominio donde está instalado el Event Log Monitor
  • Event Log Monitor está instalado en un controlador de dominio para cada dominio de Active Directory en su red
  • Event Log Monitor se ejecuta como una cuenta de usuario en el grupo de seguridad Usuarios de dominio o Administradores de dominio.
Consejo: Se le recomienda que agregue una cuenta de usuario Administrador en su servidor del Active Directory para este fin. Como consejo configure la contraseña de la cuenta para que nunca caduque
  • Si la cuenta está en el grupo de seguridad Usuarios de Dominio, asegúrese de que tenga privilegios para ejecutar servicios en el servidor de Active Directory, buscar en el directorio y buscar toda la información de auditoria de otros usuarios.
  • Event Log Monitor está habilitado en la configuración del Agente de SSO. Para especificar el Monitor de registro de eventos como su método principal de SSO, configúrelo en Prioridad 1. Para configurarlo como su método de SSO de respaldo, configúrelo en Prioridad 2.
  • Después de habilitar los mensajes del registro de auditoría para que se generen para los eventos de inicio de sesión de la cuenta, el registro de eventos de seguridad en los equipos con Windows genera los eventos de Windows 4624 y 4634 después de las acciones de inicio de sesión y cierre de sesión.
  • El archivo de registro de eventos de seguridad no está lleno en sus computadoras con Windows
Para habilitar los registros de auditoría para los eventos de inicio de sesión de la cuenta:
  1. Seleccione Inicio> Herramientas administrativas> Gestión de políticas de grupo .
  1. Haga clic con el botón derecho en la Política de dominio predeterminada y haga clic en Editar .
    Aparece el Editor de administración de políticas de grupo.
  1. En Configuración del equipo , seleccione Políticas> Configuración de Windows> Configuraciones de seguridad> Políticas locales> Política de auditoría .
  1. Abrir eventos de inicio de sesión de cuenta de auditoría .
  1. Seleccione la casilla de verificación Definir estas configuraciones de directiva .
  1. Seleccione la casilla de verificación
     
  2. Para generar mensajes de registro adicionales que pueden ayudarlo a solucionar problemas de autenticación, seleccione la casilla de verificación Fallo
  3. Haga clic en Aceptar .
  1. Fuerce a las computadoras de los usuarios a obtener la política de grupo actualizada con uno de estos métodos:
    • Ejecute gpupdate localmente en la computadora, o de forma remota con el comando gpupdate / target 
    • Pídale al usuario que cierre sesión y vuelva a iniciar sesión.
    • Reinicie la computadora del usuario.
                                                                                                    
Configurar el monitor de registro de eventos SSO

Después de instalar Event Log Monitor, debe aplicar las configuraciones de puerto, registro de eventos y directiva de grupo para su red. También debe configurar el Agente de SSO para usar el Monitor de registro de eventos.

Para la implementación de SSO más confiable, recomendamos que use el cliente de SSO como el método de SSO principal y el monitor de registro de eventos como el método de SSO de respaldo.

Si el cliente de SSO no está instalado en las computadoras de los usuarios o no está disponible, puede usar el Event Log Monitor como el método de SSO principal para los usuarios de Windows. Esto se llama SSO sin cliente. Para SSO sin cliente, configure el Agente de SSO para obtener información de inicio de sesión del Monitor de registro de eventos SSO WatchGuard instalado en su red. Event Log Monitor sondea todas las direcciones IP de su red cada cinco segundos para encontrar nuevos eventos de inicio de sesión de Windows. 

El Event Log Monitor está instalado en uno o más servidores de miembros de dominio en cada dominio.

Consejo: Para obtener el mejor rendimiento de VPN y SSO, le recomendados que no utilice el Event Log Monitor en el túnel BOVPN

Para configurar SSO sin cliente para usuarios de sistemas operativos móviles Mac OS X, Linux, iOS, Android o Windows, debe usar WatchGuard SSO Exchange Monitor. Exchange Monitor está instalado en la misma computadora donde está instalado su servidor Microsoft Exchange.

Requisitos Previos.
Antes de instalar y configurar el Event Log Monitor, verifique que su configuración de red sea compatible con estos requisitos.

Puertos
Antes de configurar y habilitar la configuración para SSO sin cliente, asegúrese de que los equipos cliente de su dominio admitan una de estas opciones:
  • El puerto TCP 445 está abierto
  • Compartir archivos e impresoras está habilitado
Si el puerto TCP 445 no está abierto, Event Log Monitor no puede obtener información de usuario o de grupo, y SSO no funciona correctamente. Para probar si el puerto 445 está abierto, puede usar la herramienta SSO Port Tester. Como se mencionó anteriormente.

Registros de eventos de Windows

Event Log Monitor usa eventos de inicio de sesión de Windows para SSO. Para habilitar el monitor de registro de eventos para obtener las credenciales de usuario necesarias para SSO, en todas las computadoras con Windows de su red, debe asegurarse de que el registro de eventos de Windows esté activo y genere registros para nuevos eventos. También debe habilitar el registro de auditoría en todos los equipos con dominio de Windows para estos eventos:
  • 4624 y 4634
  • 4647, 4778 y 4779, si su red de Windows está configurada para Cambio rápido de usuario
Antes de que los usuarios de Remote Desktop Protocol (RDP) puedan usar Event Log Monitor para SSO, los eventos de Microsoft 4624 y 4634 deben generarse en sus equipos cliente y contener atributos de Tipo de inicio de sesión. Estos atributos especifican si un evento de inicio de sesión o cierre de sesión se produjo en la red local o a través de RDP. Los atributos 2 y 11 especifican los eventos locales de inicio de sesión y cierre de sesión. El atributo 10 especifica un inicio de sesión RDP o evento de cierre de sesión.

Políticas de grupo

En su controlador de dominio, debe configurar políticas de grupo que requieran que los clientes de Windows auditen los eventos de inicio de sesión.
  1. Abra el Editor de objetos de directiva de grupo y edite la Política de dominio predeterminada .
  1. Asegúrese de que la Política de auditoría ( Configuración del equipo> Configuración de Windows> Configuración de seguridad> Políticas locales> Política de auditoría ) tenga habilitados los eventos de inicio de sesión de la cuenta de auditoría y Auditoría de eventos de inicio de sesión .
  1. Abra un símbolo del sistema y ejecute el comando gpupdate / force / boot
    Aparece un mensaje de confirmación.

Aplicar la configuración de contactos del agente de SSO

Antes de que Event Log Monitor pueda enviar información de inicio de sesión de usuario al agente SSO, debe configurar los contactos del agente SSO para habilitar el agente SSO para conectarse al Event Log Monitor. Debe agregar un dominio de contacto (el nombre de dominio y la dirección IP del Event Log Monitor), si tiene:
  • Un dominio y el agente de SSO no está instalado en su controlador de dominio
  • Más de un dominio y Event Log Monitor está instalado en un dominio diferente al del Agente de SSO
Para configurar los ajustes de contactos del agente de SSO:
  1. Inicie sesión en la herramienta de configuración del agente de SSO.
  1. Seleccione Edición> Configuración de contactos del agente SSO .
    Aparecerá el cuadro de diálogo Configuración de contactos del agente de SSO.
  1. En la lista de contactos del agente SSO , seleccione la casilla de verificación para Event Log Monitor 

  1. Para cambiar la posición del Monitor de registro de eventos en la lista Contactos del agente de SSO , seleccione la casilla de verificación Monitor de registro de eventos y haga clic en Arriba o Abajo .
    No puede cambiar la posición del Monitor de Exchange. Si usa el cliente SSO, asegúrese de que el cliente SSO sea la primera entrada. Si especifica el cliente de SSO como el contacto principal, pero el cliente de SSO no está disponible, el agente de SSO se pone en contacto con el monitor de registro de eventos a continuación, pero esto puede causar un retraso.
  1. Agregue, edite o elimine un dominio de contacto para Event Log Monitor, como se describe en las siguientes secciones.
  1. Haga clic en Aceptar .

Agregar un dominio de contacto

Después de haber instalado Event Log Monitor en los dominios de su red y haber habilitado al agente SSO para contactar al Event Log Monitor para la información de inicio de sesión del usuario, puede configurar el agente SSO con las direcciones IP de cada Event Log Monitor, por lo que el agente SSO puede obtener información de inicio de sesión del usuario de cada Event Log Monitor en su red.

Si especifica más de un Monitor de registro de eventos en la lista Dominios de contacto , el Agente de SSO se pone en contacto con la primera entrada de la lista de credenciales de usuario e información de grupo. Si el primer Event Log Monitor no está disponible, el agente de SSO contacta al próximo Event Log Monitor en la lista. Este proceso continúa hasta que el Agente de SSO encuentra un Monitor de registro de eventos disponible.

Desde el cuadro de diálogo Configuración de contacto del agente de SSO :
  1. Haga clic en Agregar .
    Aparecerá el cuadro de diálogo Configuración del dominio.



  1. Para la opción Tipo , seleccione Event Log Monitor .
  1. En el cuadro de texto Nombre de dominio , escriba el nombre del dominio para el que desea que el Monitor de registro de eventos se ponga en contacto para las credenciales del usuario.
    Debe escribir el nombre en el formato dominio.com 
  1. En el cuadro de texto IP Addresses of Event Log Monitor , escriba las direcciones IP para el Event Log Monitor.
    Para especificar más de una dirección IP para el Event Log Monitor, separe las direcciones IP con un punto y coma, sin espacios.
  1. Haga clic en Aceptar .
    La información de dominio que ha especificado aparece en la lista Dominios de contacto.

Editar un dominio de contacto

Desde el cuadro de diálogo Configuración de contacto del agente de SSO :
  1. En la lista Dominios de contacto , seleccione el dominio para cambiar.
  1. Haga clic en Editar .
    Aparecerá el cuadro de diálogo Configuración del monitor de registro de eventos.
  1. Actualiza la configuración del dominio.
  1. Haga clic en Aceptar .

Eliminar un dominio

Desde el cuadro de diálogo Configuración de contacto del agente de SSO :
  1. En la lista Dominios de contacto , seleccione el dominio para eliminar.
  1. Haga clic en Eliminar .
    El dominio se elimina de la lista.
Juan Fernández.
Analista I/ Proyectos Junior.
Servicios de Proyectos y Consultoría SGSI 0526


miércoles, 15 de noviembre de 2017

Configuracion de Branch Office Tunel con IPsec entre un Firebox Watchguard y un Router Mikrotik

Todos sabemos lo traumático que puede llegar a ser configurar dispositivos de distintas marcas para establecer comunicación segura a través de un túnel Ipsec entre diversas sucursales de una organización, no hace falta más que tener control del entorno (incluyendo que puede ser lidiar con los ISP y los posibles bloqueos de puertos requeridos para establecer este tipo de conexiones) o configuraciones con nateos a partir de los enrutadores de cara a Internet para saber de lo que estamos hablando.

Pero contar con tecnologías tan potentes a través de los dispositivos Firebox Watchguard y MikroTik no es una de esas razones para no intentarlo. 

Protocolo de Internet Seguro, IPsec, nos permite establecer conexiones seguras entre nuestras oficinas o sucursales que requieran comunicación con servicios centralizados, tales como VPNs hibridas, acceso a servicios de voz y datos, monitoreo y compartimiento de información de forma segura, entre muchas otras bondades.

Procedemos entonces con el laboratorio de configuración entre un dispositivo Mikrotik RB951UI-2HND  y un dispositivo Firebox WatchGuard M440 en el otro extremo.


Inicialmente comenzaremos a configurar los parámetros del dispositivo Firebox Watchguard con los pasos a continuación:


1.     En el Policy Manager nos dirigimos hacia VPN – Branch Office Gateways – le damos clic en add, se nos abrirá el cuadro para la configuración del nuevo tunel VPN Ipsec:  

Visual de configuración de un nuevo Gateway VPN en el Policy Manager del Firebox

En este paso configuraremos los siguientes datos:

-        Gateway Name: Nombre del Gateway (peers utilizados)
-        En General Settings
Use Pre-Shared Key (Establecemos una clave para el túnel) recuerde que este valor debe ser exactamente igual en el otro extremo, sugerimos una clave de encriptamiento fuerte.
Al final en Gateway Endpoints le damos clic en add y nos aparecerá lo siguiente: 

Recuerde tomar en cuenta los detalles otorgados por su ISP, ya que requerirá las direcciones IPs de cada extremo, así como saber si cuenta con una dirección IP estática una o dirección IP dinámica otorgada por un servicio DHCP (requiere asociación a algún servicio de nombres como dyn)

En Interface externa debemos especificar la interfaz por la cual vamos a establecer el túnel.

Seguidamente seleccionamos By IP Address y colocamos la dirección IP pública correspondiente a la interface.

Luego, nos vamos a la sección Remote Gateway un poco más abajo y configuramos lo siguiente:

Si la dirección IP de nuestra sucursal remota es dinámica y se encuentra configurada con un Dyndns seleccionamos Dynamic IP Address y By Domain Information en el siguiente campo, si la dirección IP del otro extremo es estática seleccionamos Static IP Address y agregamos la dirección IP correspondiente, en la parte de abajo tildamos By IP Address tildada por defecto y asignamos la dirección IP correspondiente al otro extremo.

Luego de configurar estas opciones nos dirigimos a la pestaña Phase 1 Settings y configuramos los siguientes parámetros

(recuerde que este es un laboratorio, los mecanismos de autenticación y encriptación mientras más robustos mucho mejor)


Version: IKEv1
Mode: Aggressive
Tildamos NAT Traversal
Keep-alive Interval: 20 seconds
Tildamos IKE Keep-alive: 30 seconds
Max Failures: 5 seconds
Tildamos Dead Peer Detection
Traffic idle timeout: 20 seconds
Max retries: 5 seconds


En la sección de Transform Settings en la misma sección de Phase I

Editamos la configuración con los siguientes parámetros:

Authentication: MD5
Encrytion: 3DES
SA Life: 8 hours
Key Group: Diffie-Hellman Group1

Con esta configuración hemos finalizado la configuración de Phase I

Procedemos a Phase II y nos dirigimos a la siguiente ruta en el Policy Manager de nuestro dispositivo Firebox WatchGuard

VPN – Branch Officce Tunnels y le damos clic en add 

Sección de configuración de Fase II del túnel Ipsec a través del Policy Manager de nuestro dispositivo Firebox WatchGuard donde configuramos el direccionamiento IP o listas de acceso de las redes o host que se cruzarán tráfico a través del túnel Ipsec a establecer.

Procedemos a configurar los siguiente parametros:

Tunnel Name: Nombre para el túnel
Address: En esta sesión agregaremos la red privada local y la red remota privada que podrán comunicarse.

Luego procedemos a configurar la Phase 2 en la pestaña Phase 2 Settings

En esta sección le damos clic a add para agregar una nueva fase II y configuramos los siguientes parámetros:

Hasta este punto tenemos la configuración lista en nuestro dispositivo Firebox WatchGuard. Procedemos a configurar el otro extremo: dispositivo MikroTik, recuerde salvar los cambios.



Administramos nuestro dispositivo Mikrotik y nos vamos a la sección de Ipsec, nos aparecerá una pantalla parecida a la siguiente:



Damos clic en la pestaña Peer y configuraremos los parámetros de fase I de la siguiente forma:


En este caso el extremo donde esta nuestro dispositivo MikroTik cuenta con un direccionamiento Ip público dinámico, el otro extremo: Firebox, cuenta con direccionamiento IP público estático, es recomendable aplicar en el intercambio o modo de negociación automático en lugar de modo Main.

En Address colocamos la dirección Ip publica del dispositivo remoto, los demás parámetros los configuramos igual como lo tenemos en el otro extremo.

Luego pasamos a configurar la fase II y lo hacemos como se muestra en la captura

En Proposal o también llamado Fase II, definimos las redes que tendrán comunicación.

Nos aparecerá la siguiente pantalla, procedemos crear la misma configuración que creamos en el Firebox

Recuerde que los dos extremos deben ser exactamente iguales.
Luego de esto pasamos a crear y este punto es muy importante una política para permitir la comunicación entre las redes privadas.

Le damos clic en Ipsec, luego le damos clic en polices agregamos la política en Add New





Nos aparecerá la siguiente ventana:




En Src Address colocamos nuestra red local y en Dst Address colocamos la red local remota.

En SA SRC Address colocamos la IP pública local o en su defecto se puede colocar 0.0.0.0 que no indica cualquier red local.

En SA Dst colocamos la dirección IP publica de destino

Por último, debemos crear una Nat para permitir las redes privadas configuradas y lo hacemos de la siguiente forma:

Nos dirigimos a Firewall – NAT no saldrá la siguiente pantalla: 




Src. Address (Direccion IP privada de origen)
Dst. Address (Direccion IP privada de destino)

Ahora vamos a configurar un DYNDNS a nuestro Router Mikrotik, para ello nos dirigimos a la pestaña Sistema, Script. Creamos uno nuevo y le colocamos el nombre de DYNDNS, dentro del campo colocaremos el siguiente código:

Solo debemos modificar las primeras 3 líneas con la información de nuestra cuenta DynDns

# Define User Variables
:global ddnsuser "DYNDNSUSER"
:global ddnspass "DYNDNSPASS"
:global ddnshost "DYNDNSHOST"

# Define Global Variables
:global ddnsip
:global ddnslastip
:if ([ :typeof $ddnslastip ] = nil ) do={ :global ddnslastip "0" }

:global ddnsinterface
:global ddnssystem ("mt-" . [/system package get system version] )

# Define Local Variables
:local int

# Loop thru interfaces and look for ones containing
# default gateways without routing-marks
:foreach int in=[/ip route find dst-address=0.0.0.0/0 active=yes ] do={
  :if ([:typeof [/ip route get $int routing-mark ]] != str ) do={
     :global ddnsinterface [/ip route get $int interface]
  }
}

# Grab the current IP address on that interface.
:global ddnsip [ /ip address get [/ip address find interface=$ddnsinterface ] address ]

# Did we get an IP address to compare?
:if ([ :typeof $ddnsip ] = nil ) do={
   :log info ("DynDNS: No ip address present on " . $ddnsinterface . ", please check.")
} else={
  :if ($ddnsip != $ddnslastip) do={
    :log info "DynDNS: Sending UPDATE!"
    :local str "/nic/update?hostname=$ddnshost&myip=$ddnsip&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG"
    /tool fetch address=members.dyndns.org src-path=$str mode=http user=$ddnsuser \
        password=$ddnspass dst-path=("/DynDNS.".$ddnshost)
    :delay 1
    :local str [/file find name="DynDNS.$ddnshost"];
    /file remove $str
    :global ddnslastip $ddnsip
  }
}

Luego debemos programar el tiempo de actualización y lo hacemos de la siguiente forma:
Nos dirigimos a System – Scheduler  y agregamos el siguiente script:

/system scheduler
add interval=1m name=DynDns on-event=DynDns policy=ftp,reboot,read,write,policy,
test,winbox,password,sniff,sensitive,api start-time=startup 


En la línea Interval colocamos el tiempo y en name el nombre de nuestro Script.

En este punto hemos finalizado la configuración en el dispositivo MikroTik, listo para recibir las peticiones de un iniciador que bien puede ser el Firebox Watchguard o el mismo dispositivo Mikrotik.

Carlos Palomo.
Analista II/ Desarrollo de Proyectos.
Servicios de Proyectos y Consultoría SGSI 0526