ISA Server 2K6 VPN’s Chema Alonso Microsoft MVP Windows Security

Presentación del tema: "ISA Server 2K6 VPN’s Chema Alonso Microsoft MVP Windows Security"— Transcripción de la presentación:

1 ISA Server 2K6 VPN’s Chema Alonso Microsoft MVP Windows Security

2 Definición VPN = “Virtual Private Network” o Red Privada Virtual
Utilizar una infraestructura pública compartida para ofrecerle a un cliente las facilidades y ventajas de una red privada

3 Topologías existentes
Redes Virtuales VPN LAN Virtuales Redes Acopladas (Peer) VPNs con MPLS Redes Superpuestas VPNs nivel 2 ATM F/R X.25 GRE VPNs nivel 3 IPSec

4 Características de las VPN
Se requiere de un encapsulado capaz de proveernos de: Autenticación Usuario Equipo Datos Compresión de datos Cifrado de datos Direccionamiento dinámico Resolución de nombres Gestión de claves Soporte Multiprotocolo (IP, IPX, etc…)

5 Encapsulado Poner un paquete dentro de otro
Se encapsulan o envuelven los datos con otra cabecera con información de enrutamiento para que puedan atravesar una red publica hasta su destino. Puede encapsularse trafico a dos niveles del modelo OSI. Nivel 2: encapsulan tramas al nivel de conexión PPTP L2F L2TP Nivel 3: encapsulan paquetes al nivel de red IPSEC

6 Protocolos de encapsulado Nivel 2
Point to Point Tunneling Protocol (PPTP) Microsoft, Ascend, otros.. Layer Two Forwarding (L2F) Propuesto por Cisco Layer Two Tunneling Protocol (L2TP) Unifica PPTP y L2F en un único estándar para VPN PPTP is a Microsoft-developed protocol that has become the de facto industry standard due to its wide deployment in Windows; PPTP clients ship with all versions of Windows since Microsoft® Windows® 95, with Mac OS X, and with most Linux distributions. PPTP supports a variety of authentication methods, which we’ll discuss later, and it encrypts connections in both directions using a randomly generated, and periodically changed, symmetric key. You may have heard from customers that PPTP is insecure; in fact, there were some vulnerabilities discovered in the NT 4.0 timeframe, but Microsoft moved quickly to fix them. A few non-Microsoft PPTP implementations on Linux still have a number of implementation flaws. Unlike PPTP, the Layer 2 Tunneling Protocol (L2TP) is a pure tunneling protocol. It doesn’t incorporate any authentication or encryption, which makes it unsuitable for use on its own. L2TP is almost always combined with the IPsec extensions for VPN functionality: this combination provides strong encryption and authentication, plus tunneling that can be used either to link two remote networks or a single remote client to a network (we’ll discuss these two modes in the IPsec module). For the remainder of this course, we’ll treat the L2TP+IPsec combination as though it were a single protocol.

7 VPN en el Modelo OSI Soluciones VPN SSL IPSEC PPTP L2TP 5. Sesión
4. Transporte SSL 3. Red IPSEC 2. Conexión PPTP L2TP 1.Físico

8 Microsoft y las VPN

9 PPP Diseñado para enviar datos a través de conexiones bajo demanda o punto a punto. Encapsula Paquetes IP Cuatro fases en la negociación de la conexión: Establecimiento de la conexión (LCP) Autenticación de usuario (PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP) Control de devolución de llamada (CBCP) Protocolos de nivel de Red (IPCP, CCP, MPPC, MPPE) Fase de transmisión de Datos. Se encapsula los datos con una cabecera PPP y se comprimen y cifran según lo acordado en fase 1 y negociado en la fase 4 Point-to-Point Protocol (PPP) Because PPTP and L2TP depend heavily on the features originally specified for PPP, it is worth examining this protocol more closely. PPP was designed to send data across dial-up or dedicated point-to-point connections. For IP, PPP encapsulates IP packets within PPP frames, and then transmits the PPP-encapsulated packets across a point-to-point link. PPP was originally defined as the protocol to use between a dial-up client and a NAS. There are four distinct phases of negotiation in a PPP connection. Each of these four phases must complete successfully before the PPP connection is ready to transfer user data. Phase 1: PPP Link Establishment PPP uses the Link Control Protocol (LCP) to establish, maintain, and terminate the logical point-to-point connection. During Phase 1, basic communication options are selected. For example, authentication protocols are selected, but they are not actually implemented until the connection authentication phase (Phase 2). Similarly, during Phase 1, a decision is made as to whether the two peers will negotiate the use of compression and/or encryption. The actual choice of compression and encryption algorithms and other details occurs during Phase 4. Phase 2: User Authentication In the second phase, the client computer sends the user’s credentials to the remote access server. A secure authentication scheme provides protection against replay attacks and remote client impersonation. A replay attack occurs when a third party monitors a successful connection and uses captured packets to play back the remote client’s response so that it can gain an authenticated connection. Remote client impersonation occurs when a third party takes over an authenticated connection. The intruder waits until the connection has been authenticated and then traps the communication parameters, disconnects the authenticated user, and takes control of the authenticated connection. Phase 3: PPP Callback Control The Microsoft implementation of PPP includes an optional callback control phase. This phase uses the Callback Control Protocol (CBCP) immediately after the authentication phase. If configured for callback, both the remote client and NAS disconnect after authentication. The NAS then calls the remote client back at a specified phone number. This provides an additional level of security to dial-up connections. The NAS allows connections from remote clients physically residing at specific phone numbers only. Callback is only used for dial-up connections, not for VPN connections. Phase 4: Invoking Network Layer Protocol(s) Once the previous phases have been completed, PPP invokes the various network control protocols (NCPs) that were selected during the link establishment phase (Phase 1) to configure protocols used by the remote client. For example, during this phase, IPCP is used to assign a dynamic address to the PPP client. In the Microsoft implementation of PPP, the Compression Control Protocol (CCP) is used to negotiate both data compression (using MPPC) and data encryption (using MPPE). Data-Transfer Phase Once the four phases of PPP negotiation have been completed, PPP begins to forward data to and from the two peers. Each transmitted data packet is wrapped in a PPP header that is removed by the receiving system. If data compression was selected in phase 1 and negotiated in phase 4, data is compressed before transmission. If data encryption is selected and negotiated, data is encrypted before transmission. If both encryption and compression are negotiated, the data is compressed first, and then encrypted.

10 PPP en conexiones directas
Trama PPP Conexión sobre una línea dedicada PPP Proporciona conexión Punto a Punto Cliente Servidor

11 Protocolos de túnel PPTP L2TP
Desarrollado por Microsoft, es un estándar de facto Esta ampliamente implementado y existen varias implementaciones compatibles Suficientemente seguro para casi todas las aplicaciones L2TP Estándar de la “Internet Engineering Task Force” (IETF) Unión Algunos problemas de interoperabilidad. Tanto PPTP como L2TP utilizan PPP por debajo, lo que les proporciona gran parte de los requerimientos necesarios. PPTP is a Microsoft-developed protocol that has become the de facto industry standard due to its wide deployment in Windows; PPTP clients ship with all versions of Windows since Microsoft® Windows® 95, with Mac OS X, and with most Linux distributions. PPTP supports a variety of authentication methods, which we’ll discuss later, and it encrypts connections in both directions using a randomly generated, and periodically changed, symmetric key. You may have heard from customers that PPTP is insecure; in fact, there were some vulnerabilities discovered in the NT 4.0 timeframe, but Microsoft moved quickly to fix them. A few non-Microsoft PPTP implementations on Linux still have a number of implementation flaws. Unlike PPTP, the Layer 2 Tunneling Protocol (L2TP) is a pure tunneling protocol. It doesn’t incorporate any authentication or encryption, which makes it unsuitable for use on its own. L2TP is almost always combined with the IPsec extensions for VPN functionality: this combination provides strong encryption and authentication, plus tunneling that can be used either to link two remote networks or a single remote client to a network (we’ll discuss these two modes in the IPsec module). For the remainder of this course, we’ll treat the L2TP+IPsec combination as though it were a single protocol.

12 PPP en conexiones enrutadas
Trama PPP Conexión sobre Internet PPP Limitado al primer enlace de la red Router Router Cliente Servidor

13 PPP en conexiones enrutadas
Tunelizado Proporciona Tansmision de Tramas Punto a Punto Sobre Internet Tunelizado: Tramas PPP Encapsuladas en Packetes IP Conexion sobre Internet Router Router Cliente Servidor

14 PPTP Proporciona Tunelizado a las tramas PPP.
Utiliza la seguridad de PPP para asegurar las comunicación sobre el túnel. Autenticación de usuario PPP (PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP) Confidencialidad y cifrado PPP (MPPE). RC4 con claves de 40 o 128 bits

15 PPTP-Tipos de Tramas Control Datos
Creación de un control de conexión PPTP Conexión lógica que representa el túnel PPTP. El servidor utiliza el puerto TCP 1723 y el cliente un puerto dinámico. Determina los ID de la cabecera GRE entre cliente y servidor que identifican el túnel PPTP específico. Mantenimiento del control de conexión PPTP Finalización del control de conexión PPTP Datos Encapsulado y transmisión de datos PPP mediante (GRE). Generic Routing Encapsulation PPTP encapsulates PPP frames in IP datagrams for transmission over an IP internetwork, such as the Internet. PPTP can be used for remote access and router-to-router VPN connections. PPTP is documented in RFC 2637. The Point-to-Point Tunneling Protocol (PPTP) uses a TCP connection for tunnel management and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted and/or compressed. Figure 6 shows the structure of a PPTP packet containing an IP datagram. A PPTP control connection A logical connection representing the PTPP tunnel that must be created, maintained, and terminated through a series of PPTP messages. PPTP control connection traffic uses a dynamically allocated TCP port on the PPTP client, and the IANA-reserved TCP port of 1723 on the PPTP server. GRE encapsulation for data When data is sent across the PPTP connection, PPP frames are encapsulated with a Generic Routing Encapsulation (GRE) header, which includes information that identifies the specific PPTP tunnel for the data packet.

16 ID Protocolo IP (GRE) Conexión de Datos
PPTP-Conexiones ID Protocolo IP (GRE) Conexión de Datos Internet Pc Remoto Servidor RAS PPTP Puerto TCP 1723 Control de Conexión

17 PPTP Paquete TCP/IP IP Header TCP Header Payload Data Encapsulado PPP
Interface IP GRE Header PPP Header IP Header TCP Header Payload Data IP Interface IP Header IP GRE Header PPP Header IP Header TCP Header Payload Data Ehernet

18 L2TP Combina PPTP y L2F en un único estándar para VPN propuesto por la IETF Encapsula tramas PPP que pueden ser enviadas a través de IP, X.25, Frame Relay o ATM El estándar permite que se pueda utilizar la seguridad de PPP para asegurar las comunicación sobre el túnel. Autenticación PPP Confidencialidad y cifrado PPP (MPPE) La Implementación de Microsoft, no utiliza PPP para asegurar las comunicaciones. Utiliza IPSEC, lo que da lugar a L2TP/IPSec

19 L2TP sobre IP Paquete TCP/IP IP Header TCP Header Payload Data
Encapsulado PPP PPP Header IP Header TCP Header Payload Data L2TP Interface L2TP Header PPP Header IP Header TCP Header Payload Data UDP Interface UDP Header L2TP Header PPP Header IP Header TCP Header Payload Data IP Inteface IP Header UDP Header L2TP Header PPP Header IP Header TCP Header Payload Data Ehernet

20 L2TP/IPSec Encapsulado L2TP de la trama PPP
Encapsualdo IPSec del mensaje L2TP Cifrado IPSEc del contenido de los paquetes L2TP De los protocolos de IPSec (AH y ESP) se utiliza ESP (Encapsulating Security Payload)

21 Encapsulado L2TP/IPSec sobre IP
Paquete TCP/IP IP Header TCP Header Payload Data Encapsulado PPP PPP Header IP Header TCP Header Payload Data L2TP Interface L2TP Header PPP Header IP Header TCP Header Payload Data UDP Interface UDP Header L2TP Header PPP Header IP Header TCP Header Payload Data IPSec Inteface IPSec ESP Header UDP Header L2TP Header PPP Header IP Header TCP Header Payload Data IPSec ESP Trailer IPSec AUTH Trailer Encapsulation for L2TP/IPSec packets consists of two layers: 1.L2TP encapsulation A PPP frame (an IP datagram or an IPX datagram) is wrapped with an L2TP header and a UDP header. 2.IPSec encapsulation The resulting L2TP message is then wrapped with an IPSec Encapsulating Security Payload (ESP) header and trailer, an IPSec Authentication trailer that provides message integrity and authentication, and a final IP header. In the IP header is the source and destination IP address that corresponds to the VPN client and VPN server.The following illustration shows L2TP and IPSec encapsulation for a PPP datagram. IP Inteface IP Header IPSec ESP Header UDP Header L2TP Header PPP Header IP Header TCP Header Payload Data IPSec ESP Trailer IPSec AUTH Trailer Ehernet

22 L2TP/IPSec: Fases Negociación de las SA de IPSec para el trafico L2TP
SA en modo principal Autenticación IPSec SA en modo secundario Se establece el nivel y modo de cifrado de los datos. Negociación de la Conexión L2TP Se establece el control de conexión y la sesión L2TP Negociación de la Conexión PPP Establecimiento de la conexión (LCP) Autenticación de usuario (PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP) Protocolos de nivel de Red (IPCP, CCP, MPPC, MPPE)

23 L2TP / IPSec PPP Hdr PPP Payload UDP Hdr L2TP Hdr PPP Hdr PPP Payload
Trama PPP PPP Hdr PPP Payload UDP Hdr L2TP Hdr PPP Hdr PPP Payload Adjuntar Adjuntar IP Hdr ESP Hdr UDP L2TP PPP Payload ESP Trailer ESP Auth attach Normalmente Cifrado Cobertura del chequeo de Integridad El cifrado es con DES o 3DES con las claves que se obtienen de la negociación de las SA en modo secundario

24 Autenticación PPTP L2TP/IPSec
Autenticación a nivel de Usuario proporcionada por PPP L2TP/IPSec Autenticación a nivel de máquina proporcionada por IPSec Claves preestablecidas (No recomendado) Certificados Digitales de máquina.

25 Metodos de Autenticación NO RECOMENDADOS
Password Authentication Protocol (PAP) Envía la password en texto claro. NO RECOMEDADO Shiva Password Authentication Protocol (SPAP) Utiliza cifrado reversible NO RECOMNDADO Challenge Handshake Authentication Protocol (CHAP) Utiliza MD5 para proporcionar autenticación mediante desafio-respuesta Requiere almacenar las contraseñas con cifrado reversible en el servidor (DC) NO RECOMENDADO MS-CHAP Existen debilidades conocidas NO RECOMENDADO For backward compatibility, the Windows 2000 and Windows 2003 RRAS services include support for a number of authentication methods that nonetheless shouldn’t be used in production networks. While these protocols may sometimes be turned on to support legacy systems, you should be careful to point out the security implications of doing so to your customers. PAP sends the user name and password in cleartext. CHAP uses MD5 to provide challenge-response authentication. It is broadly supported, but it requires you to configure AD to allow storage of reversibly encrypted passwords. Doing so means that an attacker who can compromise a domain controller can obtain passwords for all users, so this is a really, really bad idea, especially since you normally have to force a password change so that users get their passwords changed. MS-CHAP is a Microsoft-developed variant of CHAP that provides a similar MD5-based challenge-response protocol but that doesn’t depend on reversible encryption of users’ passwords. This makes it a better choice than CHAP; however, the original protocol has a number of design weaknesses that have been known for several years. Accordingly, its use is not recommended. By default, the Windows Server 2003 family implementation of MS-CHAP v1 does not support LAN Manager authentication. If you want to allow the use of LAN Manager authentication with MS-CHAP v1 for older operating systems such as Microsoft® Windows NT® 3.5 and Windows 95, you must set the HKLM\System\CurrentControlSet\Services\RemoteAccess\Policy\Allow LM Authentication value to 1 on the authenticating server. Microsoft® Windows® 2000 Server supports LAN Manager authentication by default. Upgrading a computer running Windows 2000 Server to a member of the Windows Server 2003 family preserves the existing Allow LM Authentication setting.

26 Metodos de Autenticación RECOMENDADO
MS-CHAP v2 Versión mejorada de MS-CHAP Usada frecuentemente Desde el punto de vista del cifrado es mas fuerte que PAP, CHAP, MS-CHAP Recomendada cuando no es posible implementar EAP-TLS MS-CHAP version 2 (v2) addresses several weakness in the original MS-CHAP protocol: MS-CHAP allows LAN Manager encoding for responses, and that’s cryptographically weak. MS-CHAPv2 doesn’t use LAN Manager encoding for anything, including password changes. MS-CHAP provides one-way authentication: the server can authenticate the client, but there’s no way for the client to authenticate the server’s identity. MS-CHAPv2 provides two-way mutual authentication. MS-CHAP uses a key generation process that results in using the same key each time a user with the same password connects. MS-CHAPv2 adds random data to the password generation process so that cryptographic keys aren’t ever reused. MS-CHAP uses a single key for transmitting and receiving data. MS-CHAPv2 uses two separate cryptographic keys.

27 Metodos de Autenticación RECOMENDADO
EAP Extensible Authentication Protocol Soporta varios tipos de Autenticación EAP-MD5: Desafió/Respuesta. No muy seguro. EAP-TLS: Basado en cerificados; requiere pertenencia a un dominio; diseñado para ser utilizado con Smart Cards EAP-RADIUS: Mecanismo proxy de reenvió de datos en un formato EAP especifico a un servidor RADIUS El tipo a utilizar se puede especificar en el servidor o mediante políticas a un grupo especifico de usuarios. With the Extensible Authentication Protocol (EAP), an arbitrary authentication mechanism authenticates a remote access connection. The exact authentication scheme to be used is negotiated by the remote access client and the authenticator (either the remote access server or the RADIUS server). Routing and Remote Access includes support for EAP-TLS and MD5-Challenge by default. You can plug in other EAP modules to the server running Routing and Remote Access to provide other EAP methods.EAP allows for an open-ended conversation between the remote access client and the authenticator. The conversation consists of authenticator requests for authentication information and the responses by the remote access client. For example, when EAP is used with security token cards, the authenticator can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the remote access client passes through another level of authentication. When all questions have been answered satisfactorily, the remote access client is authenticated.A specific EAP authentication scheme is known as an EAP type. Both the remote access client and the authenticator must support the same EAP type for successful authentication to occur. Windows 2000 and 2003 support several EAP types: EAP-MD5 is used for challenge-response authentication between servers; it shouldn’t be used for user authentication, and Windows RRAS doesn’t let you choose it for such. However, third-party products that request EAP-MD5 challenges for RADIUS traffic will work. EAP-TLS uses digital certificates to exchange keys that are then used to establish a secure connection for authentication. This is the most secure EAP type supported by Windows 2000 (Windows 2003 supports PEAP, covered in the next slide). However, it requires clients to have client certificates, so it is mostly used with deployments that include smartcards or tokens that can hold the necessary certificates. EAP-RADIUS is a proxy pass-through mechanism that allows an RRAS server to accept data in a specified EAP type and pass it to a RADIUS proxy. It can’t be used for direct authentication. The specific EAP types used on a server can be set on a per-server basis; in addition, you can use remote access policies to determine which types may or must be used for specific groups of users.

28 Metodos de Autenticación RECOMENDADO
PEAP: Protected EAP Proteje las negociaciones EAP envolviendolas con TLS Se usa solo para conexiones wireless Soporta reconexiones rapidas para entornos grandes con roaming Puede usar PEAP plus EAP-MS-CHAPv2: añade autenticación mutua; requie que el cliente confie en los certificados del servidor; facil de implementar. EAP-TLS: Muy seguro; requiere una infraestructura PKI Hay documentación completa de como implementarlo en la Web de TechNet Protected Extensible Authentication Protocol (PEAP) is a new member of the family of EAP types. PEAP uses Transport Level Security (TLS) to create an encrypted link between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, usually an IAS server. PEAP itself does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MSCHAPv2, that can operate through the TLS-protected channel provided by PEAP. PEAP is used as an authentication method for wireless client computers, but is not currently supported for VPNs or other remote access clients.To enhance both the EAP protocols and network security, PEAP provides: Protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the RRAS server to cause the negotiation of a less secure EAP method. The encrypted TLS channel also helps prevent denial of service attacks against the IAS server. Support for the fragmentation and reassembly of messages, allowing the use of EAP types that do not provide this. A way for wireless clients to authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs. Protection against the deployment of an unauthorized wireless access point (WAP) when the EAP client authenticates the certificate provided by the IAS server. In addition, the TLS master secret created by the PEAP authenticator and client is not shared with the access point. Because of this, the access point cannot decrypt the messages protected by PEAP. PEAP fast reconnect, which reduces the delay in time between an authentication request by a client and the response by the IAS or RADIUS server, and allows wireless clients to move between access points without repeated requests for authentication. This reduces resource requirements for both client and server. You can deploy PEAP for wireless access in two methods: PEAP with EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2) is easier to deploy than EAP-TLS because user authentication is accomplished with password-based credentials (user name and password) instead of certificates or smart cards--only the IAS or RADIUS server is required to have a certificate. PEAP-EAP-MS-CHAPv2 provides improved security over MS-CHAPv2 by using mutual authentication, preventing an unauthorized server from negotiating the least secure authentication method, and providing key generation with TLS. PEAP-EAP-MS-CHAPv2 requires that the client trust certificates provided by the server.Additionally, the server certificate can be issued by a public CA. that is trusted by the client computer (that is, the public CA certificate already exists in the Trusted Root Certification Authority folder on the client computer certificate store. In this case, the server certificate is not downloaded and added to the client trusted root certificate store, and the user is not prompted to make a decision about whether to trust the server. PEAP with EAP-TLS provide a much stronger authentication method than those that use password-based credentials. PEAP with EAP-TLS (PEAP-EAP-TLS) uses certificates for server authentication and either certificates or smart cards for user and client computer authentication. To use PEAP-EAP-TLS, you must deploy a PKI because the client has to have a certificate issued by the same CA that the server's using.

29 VPN para acceso remoto de clientes

30 VPN conexión entre sedes

31 VPN para acceso remoto de clientes VPN entre sedes
DEMOS VPN para acceso remoto de clientes VPN entre sedes

32 Intelligent Application Gateway
Microsoft TechNet Seminar 2006 Generic Applications Applications Knowledge Centre OWA … ………... Citrix …….. Sharepoint . ……….... ISO7799 Corporate Governance SarbOx Basel2 Policy & Regulation Awareness Centre WHAT? COMPLIANT? Web Java/Browser Embedded Tunneling Authentication Application Aware Modules Client/Server Devices Knowledge Centre PDA ….... Linux …….. Windows . ………... MAC …..... SSL VPN Gateway Security Authorization User Experience WHO? Specific Applications High-Availability, Management, Logging, Reporting, Multiple Portals Client Exchange/ Outlook OWA WHERE? SharePoint/Portals Citrix 32 Seminar Name

33 Referencias Virtual Private Networks for Windows Server Layer Two Tunneling Protocol in Windows The Cable Guy PPTP Traffic Analysis - The Cable Guy VPN Quarantine Sample Scripts for Verifying Client Health Configurations

34 Referencias RFC 3947 : the official NAT-T standard
RFC 3715 : set the requirements for the NAT-T RFC RFC 3948 : encapsulating IPsec ESP packets within UDP Remote Access Quarantine Tool for ISA Server Windows98/ME/NT4 NAT-T Web download

35 TechNews Suscripción gratuita enviando un mail:

36

37 Contacto Chema Alonso chema@informatica64.com
Technews