ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Facebook      Twitter

Valid HTML 4.01 Transitional


      ¿Qué es esto?
      Imágenes
      Licencia
      Anuncios
      Lista de correo
      Forum
      Documentación
      FAQ
      Hardware
      Download
      Actualización on-line
      Kerberos Tutorial  
      Aviso legal
      Contacto


  Más detalladamente:
      Gráficos
      Net Balancer
      Router UMTS
      Antivirus proxy
      Punto de acceso WiFi
      OpenVPN cliente
      Servidor OpenVPN
      QoS
      OpenDNS
      Kerberos 5
      NIS y LDAP
      Certificados X.509
      RADIUS
      Portal Cautivo
      VPN
      Firewall





Todos   Genérico   Almacenamiento   La creación de redes   VPN   Seguridad Wi-Fi   

Preguntas de seguridad Wi-Fi de la red inalámbrica

  1. Tengo una red Wi-Fi y quisiera protegerla de accesos no autorizados. Es mejor usar un servidor RADIUS que me permite tener la autenticación 802.1X y la protección con WPA o WPA2 o utilizar un Captive Portal (portal cautivo) que autentica el acceso a través de acceso web?

    Servidor RADIUS, 802.1x, WPA, 802.11i (WPA2)

  2. En RADIUS terminología en referencia a la protección de la red Wi-Fi, ¿qué suplicante, autenticador, NAS y servidor de autenticación?
  3. ¿El servidor RADIUS de ZeroShell es compatible con WPA y protocolo 802.11i (WPA2) para proteger las redes inalámbricas?
  4. Cuando se configura, el suplicante en mi equipo, debe elegir el método de autenticación entre los EAP-TLS, EAP-TTLS y PEAP. ¿En qué consiste?
  5. Tengo un punto de acceso WiFi utilizando múltiples SSID funcionalidad de modo que diferentes SSID puede ser configurado y asignado en diferentes VLAN. Si utilizo ZeroShell que el servidor RADIUS, puedo asociar los clientes Wi-Fi en las VLAN diferente, basado en el nombre de usuario utilizado durante la autenticación 802.1x?
  6. Durante la configuración del punto de acceso y el servidor RADIUS, yo soy la especificación de un secreto compartido. ¿Qué es?
  7. El servidor RADIUS de ZeroShell también puede funcionar en modo de proxy. ¿Qué significa exactamente?
  8. ¿Tiene ZeroShell apoyo WEP y WPA-PSK para proteger las redes Wi-Fi?

    Portal Cautivo

  9. El Portal Cautivo de ZeroShell se compone de dos módulos: el servidor de Acceso a la Web y el portal cautivo gateway. ¿Cuál es la ventaja de la modularidad?
  10. Quiero crear una estructura de múltiples puerta de enlace con el Portal ZeroShell en cautividad. ¿Cuál es el número máximo de gateway que puedo tener en el servidor web?
  11. ¿Cuáles son las fuentes de autenticación utilizado por el captive portal para validar los usuarios?
  12. ¿Puede el ZeroShell Portal Cautivo utilizar un servidor RADIUS como una fuente de autenticación?
  13. ¿Puede el ZeroShell portal cautivo al mismo tiempo el uso de fuentes múltiples de autenticación?
  14. Me temo que un impostor, utilizando una dirección IP falso, puede reemplazar el servidor de acceso web, con una falsa y engañar a las puertas de enlace . ¿Hay algún peligro de esto para ZeroShell portales cautivos?
  15. Cuando autenticarse con el captive portal, inmediatamente después de introducir mi nombre de usuario y contraseña y pulse el botón de acceso a la red, al mismo tiempo que la ventana emergente aparece para controlar la conexión, el navegador me advierte de que mis datos no habrá problemas de seguridad encriptada, por lo que pueda surgir. ¿Debo preocuparme? ¿Estará disponible en la red?
  16. Caso de que un impostor capturar el autenticador en la red y, sin descifrar que, tal como se lo envía a la pasarela , él o ella puede obtener acceso ilegal a la red?
  17. ¿Por qué no el usuario cierre la ventana de control emergente que aparece después de la autenticación con el CaptivePortal?
  18. Captive Portal puede trabajar en modo enrutado o en Modo Bridge. ¿Qué significa eso?
  19. El portal cautivo es capaz de autenticar con certificados x.509?

  1. Tengo una red Wi-Fi y quisiera protegerla de accesos no autorizados. Es mejor usar un servidor RADIUS que me permite tener la autenticación 802.1X y la protección con WPA o WPA2 o utilizar un Captive Portal (portal cautivo) que autentica el acceso a través de acceso web?
    Tanto métodos tienen ventajas y defectos. Usar RADIUS con 802.11i que será más seguro debido al hecho de que no sea la autenticación de acceso, que se produce cuando el cliente se asocia a un punto de acceso, la capa de enlace de datos de la comunicación inalámbrica es encriptada con claves de encriptación que se cambian a intervalos regulares. Por otro lado, una puerta de enlace Portal Cautivo se limita a autorizar el acceso cuando el cliente ya tiene una dirección IP. En este caso, si los datos deben ser cifrados debemos hacer uso de otros expedientes, por ejemplo, redes privadas virtuales (VPN). El portal cautivo tiene la ventaja indiscutible de que no se requiere ninguna configuración del lado del cliente y puede trabajar con cualquier hardware Wi-Fi. En realidad, dado que funciona a nivel de layer 3 (IP), el portal cautivo puede proteger el acceso, incluso en una red cableada. En cambio, el sistema con un servidor RADIUS, además de ser más complicado de configurar para el usuario, requiere de hardware (punto de acceso y tarjeta de red inalámbrica) apoyo y soporte del sistema operativo. Para concluir, podemos decir que el portal cautivo se adapta mejor en HotSpots en el que el único objetivo es proteger contra el acceso indiscriminado a Internet. WPA y WPA2 con un servidor RADIUS adaptarse mejor a situaciones en las que es indispensable para garantizar tanto la confidencialidad de los datos y la autenticación de usuario.
  2. En RADIUS terminología en referencia a la protección de la red Wi-Fi, ¿qué suplicante, autenticador, NAS y servidor de autenticación?
    Un cliente que trata de asociar a una red autenticada con 802.1X se llama un suplicante. El suplicante término se utiliza a menudo para presentar el software en el cliente que administra el proceso de autenticación 802.1x: en Windows XP o Mac OS X el suplicante ya está integrado en el sistema, mientras que en Linux, para la mayoría de las distribuciones, la xsupplicant de paquetes de la open1x del proyecto debe estar instalado.
    Los términos autenticador y NAS (Network Access Server) se refieren a los puntos de acceso. Algunos puntos de acceso más barato puede no ser capaz de trabajar como un autenticador, ya que no puede manejar el protocolo 802.1x.
    Por último, el servidor de autenticación plazo indica que el servidor delegado la tarea de establecer si los usuarios que deseen acceder a la red son realmente quienes dicen ser. El servidor de autenticación y el servidor RADIUS son casi siempre los mismos.
  3. ¿El servidor RADIUS de ZeroShell es compatible con WPA y protocolo 802.11i (WPA2) para proteger las redes inalámbricas?
    Tanto WPA y WPA2 el uso del protocolo 802.1x como la autenticación y el sistema de generación de claves. Ya que el servidor RADIUS ZeroShell (Freeradius) es compatible con 802.1x con los métodos de autenticación EAP-TLS, EAP-TTLS y PEAP con la Ms-CHAPv2, WPA y WPA2 son automáticamente compatibles. Tenga en cuenta sin embargo que desde WPA2 requiere una capa de cifrado con el algoritmo de cifrado AES moderno, tendrá que comprobar que el hardware utilizado (Accesspoint y tarjetas Wi-Fi) apoyar este cifrado. En cambio, el WPA utiliza el mecanismo de la codificación RC4 (como en WEP, pero sin los problemas de seguridad debido a un acceso clave estática), incluso el viejo hardware en general funciona bien. la mayoría de los casos, se requiere una actualización del firmware y el controlador.
  4. Cuando se configura, el suplicante en mi equipo, debe elegir el método de autenticación entre los EAP-TLS, EAP-TTLS y PEAP. ¿En qué consiste?
    El 802.1x es un protocolo de autenticación, es decir, el método real a través del cual se produce la validación de usuarios, que se negocia entre los disponibles al mismo tiempo tanto por el supplicant y por el servidor de autenticación. EAP-TLS, PEAP y EAP-TTLS se encuentran entre los métodos de autenticación en cuenta al usar redes inalámbricas debido a que estos, con un SSL/TLS túnel encriptado, ofrecen mayores garantías de seguridad y apoyo para la generación y el intercambio de claves de cifrado utilizado en WPA y 802.11i .
    EAP-TLS requiere un certificado digital X.509 con la clave privada relacionada tanto en el servidor RADIUS y el suplicante. A menudo, dada la dificultad de proporcionar una empresa con una PKI X.509 capaz de proporcionar a cada usuario un certificado de que no tendrá en cuenta el uso de EAP-TLS, aunque este método es, sin duda el más seguro ya que el usuario no tiene que escribir un nombre de usuario o contraseña.
    EAP-TLS es ideal cuando se quiere autenticar el acceso de red a través de una tarjeta inteligente mediante el almacenamiento de la clave privada y el certificado de usuario directamente en este soporte.
    PEAP (Protected EAP ), al igual que EAP-TTLS, se requiere un certificado X509 y la clave privada relacionada sólo desde el lado del servidor RADIUS. Este certificado lleva a cabo la autenticación del servidor contra el cliente y, posteriormente, establece un SSL / TLS túnel en el que pasa a otro protocolo para autenticar al usuario para RADIUS. En general, este protocolo es MS-CHAPv2 en el que el usuario debe introducir es el nombre de usuario y contraseña.
    Entre PEAP y EAP-TTLS, PEAP con MS-CHAPv2 más utilizados. Esto se debe probablemente al hecho de que Windows XP ofrece soporte nativo para este protocolo. Si en cambio desea utilizar EAP-TTLS en Windows, necesitará un suplicante de terceros, por ejemplo SecureW2 Alfa y Ariss.
    Con respecto a Linux, el Xsupplicant apoya los tres métodos de autenticación.
  5. Tengo un punto de acceso WiFi utilizando múltiples SSID funcionalidad de modo que diferentes SSID puede ser configurado y asignado en diferentes VLAN. Si utilizo ZeroShell que el servidor RADIUS, puedo asociar los clientes Wi-Fi en las VLAN diferente, basado en el nombre de usuario utilizado durante la autenticación 802.1x?
    Es posible. En el formulario sobre el usuario, establecer el 802.1Q VLAN ID de la VLAN en la que desea asociar al usuario. De este modo, el servidor RADIUS, que autentica al usuario 802.1x, enviará los atributos Tunnel-Type (=VLAN), Tunnel-Medium-Type (=802 ) y Tunnel-Private-Group-ID (=ID de VLAN establecido para el usuario) al punto de acceso. Si la AP reconoce estos atributos (en general los puntos de acceso Cisco hacerlo) que el cliente se asocia automáticamente en el SSID con el que el VLANID corresponde.
    Si la autenticación se produce a través de EAP-TLS, y por lo tanto el uso de certificados X.509 en lugar de credenciales normales, el usuario se toma del valor del campo CN del certificado utilizado.
  6. Durante la configuración del punto de acceso y el servidor RADIUS, yo soy la especificación de un secreto compartido. ¿Qué es?
    Como su nombre lo indica, es una Shared Secret (secreto compartido) es una secuencia alfanumérica compartida sólo entre el punto de acceso y el servidor de autenticación RADIUS. Este secreto es garantizar la autenticidad de AP y el servidor que interviene en la autenticación del cliente: si el secreto compartido no se corresponde, los mensajes del protocolo 802.1x no se intercambian y autenticación falla inmediatamente. Tenga en cuenta que mientras que un único secreto debe estar configurada en el punto de acceso, uno está configurado para cada punto de acceso de direcciones IP para el servidor RADIUS para la autenticación que se autoriza.
  7. El servidor RADIUS de ZeroShell también puede funcionar en modo de proxy. ¿Qué significa exactamente?
    En el suplicante cliente inalámbrico que los intentos de autenticación mediante 802.1x, el nombre de usuario se pueden insertar en nombre de usuario@dominio formato (por ejemplo, pluto@EXAMPLE.COM). Con base en el dominio, el servidor RADIUS que recibe la solicitud decide si tiene la autoridad para administrar o si se debe delegar en otro servidor para hacerlo. En este caso, el servidor RADIUS primero dice que es un proxy RADIUS y requiere de un secreto compartido con el segundo, como si fuera un punto de acceso normal. Además, usted puede configurar un servidor RADIUS de forma predeterminada (DEFAULT) a la que se envían solicitudes de proxy para dominios no configurado explícitamente. Por último, tenga en cuenta que el servidor RADIUS de segundo a su vez podría no ser capaz de gestionar la solicitud y por lo tanto debe actuar como un proxy de otro servidor y así sucesivamente hasta que se llega a un servidor autorizado para gestionar la autenticación del dominio.
  8. ¿Tiene ZeroShell apoyo WEP y WPA-PSK para proteger las redes Wi-Fi?
    Tanto WEP y WPA-PSK son los sistemas de clave previamente compartida protección, lo que significa que un suplicante tratar de asociarse con un punto de acceso deben compartir una clave preestablecida con este último. Dicho esto, no es necesario disponer de un servidor de autenticación que valida cada usuario y por lo tanto preguntaba si ZeroShell soporta encriptación WEP y WPA-PSK no tiene sentido.
    Actualidad el WEP no es suficiente para proteger también un interno red inalámbrica dado el código RC4 en el que se basa y, junto con un vector de inicialización de sólo 24 bits para combinar con la clave compartida, puede ser rápidamente descifrar si son suficientes paquetes olfateó. WPA-PSK, que en su lugar utiliza un vector de inicialización de 48 bits, a condición de que se utiliza con una PSK de al menos 20 caracteres, se considera una solución aceptable en entornos domésticos o SOHO.
  9. El Portal Cautivo de ZeroShell se compone de dos módulos: el servidor de Acceso a la Web y el portal cautivo gateway. ¿Cuál es la ventaja de la modularidad?
    El en cautividad de puerta de enlace funcionalidad actúa como una puerta de enlace (enrutador o un bridge) que, sin embargo, para el que se los clientes autenticados, impide el acceso a una zona protegida de LAN y hacia adelante sólo las solicitudes en los puertos 80 (http) y 443 (https) a un servidor Web Nombre (también llamado servidor de autenticación). La tarea de este último es el de presentar una página web de autenticación del usuario para insertar un nombre de usuario y contraseña. Si la autenticación tiene un resultado positivo, la entrada en cautividad elimina las barreras para el cliente autenticado y permite el acceso a la zona protegida.
    Separación de estas dos funcionalidades en distintos módulos es ventajoso porque una estructura de múltiples puertas de enlace (Gateway) se pueden crear en el que varios cautivos pasarelas de proteger a las diferentes redes, que también son geográficamente distanciados y que utilizan el servidor web, mismo nombre de usuario. De este modo, la personalización de la entrada y la página web de la contabilidad llevará a cabo en un solo lugar en vez de en cada puerta de enlace.
  10. Quiero crear una estructura de múltiples puerta de enlace con el Portal ZeroShell en cautividad. ¿Cuál es el número máximo de gateway que puedo tener en el servidor web?
    En teoría, no hay límite al número de gateway que tiene en Internet una entrada servidor. En la práctica, sin embargo, el límite depende de múltiples factores, entre ellos: el rendimiento del hardware del servidor de autenticación (*), el número promedio de clientes gestionados por las pasarelas de varios cautivos y en consideraciones de tolerancia a fallos
    Nota (*): fácilmente se podría cometer el error de considerar la carga de trabajo del servidor web, acceder a ser menor que el de una puerta de entrada, dado el sólo la primera debe proporcionar una página web, la autenticación y, posteriormente, validar el acceso de usuarios a la red. Aparentemente es un trabajo pequeño. Sin embargo, las cosas no son como éste. Un montón de software, especialmente las técnicas de P2P utilizando, el uso no estándar TCP 80 y 443 puertos en un intento de superar los firewalls posible a toda costa. ¿Qué administrador de la red, de hecho, alguna vez cerca de los puertos de salida donde se encapsula el tráfico por defecto WWW? Casi ninguno. Skype, el sistema bien conocido y difundido la mayoría de la telefonía VoIP, es un ejemplo de dicho software. Después de haber intentado conectarse a través de diferentes puertos TCP en el rango de 1 a 65535 como el destino, intente utilizar el puerto 443 (https) y, si esto también falla, use el puerto 80 (http). El procedimiento se reiteró entonces si este último no tiene un resultado positivo. La puerta de enlace en cautividad, que no sabe que el tráfico generado en esos puertos no es desde un navegador web normal, pero a través de Skype, remite la solicitud al servidor de autenticación que a su vez un principio ignora el hecho de que el protocolo http no se utiliza, y se ve obligado a procesarlo. La solución a este problema sería aplicar una capa de 5 servidor de seguridad en las puertas de enlace, que actúan como filtros del contenido (layer 7) transportado en los paquetes TCP, por lo que hacia adelante sólo las solicitudes que realmente utilizan el protocolo http. ZeroShell no implementa esta característica.
  11. ¿Cuáles son las fuentes de autenticación utilizado por el captive portal para validar los usuarios?
    El cautivo portal de de Zeroshell puede utilizar las siguientes fuentes de autenticación: Kerberos v5 integrado de servidor para validar todos los usuarios locales, una externa 5 de Kerberos para autenticar a los usuarios de otro reino, por ejemplo, un dominio de Microsoft Active Directory , la autenticación entre el reino Kerberos v5 para autenticar a los usuarios de un dominio externo, que confían en el ámbito local.
  12. ¿Puede el ZeroShell Portal Cautivo utilizar un servidor RADIUS como una fuente de autenticación?
    Desde el ZeroShell 1.0.beta6 versión, el portal cautivo puede utilizar, aparte de Kerberos 5 de autenticación, la autenticación RADIUS con el servidor local como un proxy configurado hacia otros servidores RADIUS.
  13. ¿Puede el ZeroShell portal cautivo al mismo tiempo el uso de fuentes múltiples de autenticación?
    Sí, que puede. El usuario debe elegir el ámbito al que pertenece la página de acceso web. A partir de esta elección, el servidor de acceso web, puede comunicarse con el proveedor de autenticación correcta. La elección del dominio puede ocurrir mediante el cuadro de lista en la página de acceso web, o usando un nombre de usuario en el formato de nombre de usuario@dominio.
  14. Me temo que un impostor, utilizando una dirección IP falso, puede reemplazar el servidor de acceso web, con una falsa y engañar a las puertas de enlace . ¿Hay algún peligro de esto para ZeroShell portales cautivos?
    No, no hay peligro de esto porque el servidor de acceso web y los portales cautivos, que componen la misma infraestructura, compartir un secreto (un secreto compartido para ser configurados por el administrador). Después de que el servidor web de inicio de sesión autentica al usuario a través de Kerberos 5 o RADIUS, responde a la puerta de entrada a través de un paquete cifrado con AES256 con el secreto compartido como clave. Este paquete, llamado autenticador, contiene el nombre de usuario de dominio completo, la dirección IP del cliente y el servidor de marca de tiempo. Cuando la puerta de entrada cautivos recibe la respuesta, debe descifrar el autenticador de leer el nombre de usuario y la IP para que la conexión se abre. Sin embargo, si el servidor de autenticación es falso, la clave no se correspondería con la utilizada para cifrar el autenticador y la puerta de enlace no reconocen la autoridad del servidor. Tenga en cuenta que un autenticador tiene una vida muy breve para evitar ser capturado por un impostor y ser reutilizado ilegalmente al cruzar la red para abrir una conexión. Esto implica que, hasta las funciones de la infraestructura de portal cautivo correctamente los relojes en el sistema de servidor web de acceso y las pasarelas deben estar sincronizados dentro de una cierta tolerancia. Es muy recomendable el uso de NTP (Network Time Protocol).
  15. Cuando autenticarse con el captive portal, inmediatamente después de introducir mi nombre de usuario y contraseña y pulse el botón de acceso a la red, al mismo tiempo que la ventana emergente aparece para controlar la conexión, el navegador me advierte de que mis datos no habrá problemas de seguridad encriptada, por lo que pueda surgir. ¿Debo preocuparme? ¿Estará disponible en la red?
    No hay absolutamente ninguna necesidad de preocuparse acerca de este mensaje que viene desde el navegador. El nombre de usuario y contraseña se pasa el tipo a través de un túnel cifrado SSL, gracias a la utilización de las solicitudes de https. En cambio, cuando el servidor de acceso web, ya se ha autenticado la sesión ya no es encriptada y los datos a que se refiere el navegador no son otros que el autenticador que, creado por el servidor de autenticación, debe tránsito hacia la puerta de entrada. El autenticador ya está cifrado con AES256 y no hay necesidad de seguir utilizando la codificación SSL.
  16. Caso de que un impostor capturar el autenticador en la red y, sin descifrar que, tal como se lo envía a la pasarela , él o ella puede obtener acceso ilegal a la red?
    No es tan simple como parece. Una vez que el impostor ha olido el autenticador, antes de usarla él o ella debe esperar a que el cliente legítimos de abandonar la red. Las direcciones IP y MAC a continuación, se cambió y se corresponden con los del cliente que abandonó la red y, por último, el autenticador envía a la pasarela, a la espera de este último para permitir la conexión. De hecho, el impostor que esperar en vano por dos razones: el autenticador tiene una duración limitada en el tiempo y sin duda la mayoría, sobre el uso de un impostor, que ya han expirado, la entrada en cautividad puede recordar autenticadores utilizado anteriormente para permitir una conexión y ganó 't permitir el acceso a una réplica.
  17. ¿Por qué no el usuario cierre la ventana de control emergente que aparece después de la autenticación con el CaptivePortal?
    Debido a esta ventana, que no permite la desconexión forzada por el usuario, garantiza la continua renovación de la autentificación antes de su expiración. Si esta ventana se cierra la puerta de enlace, que ya no ve ninguna solicitud de renovación, se decide cerrar la conexión del cliente.
    Es probable que ya evidente que hasta que una puerta de enlace renueva un autenticador, éste deberá seguir siendo válido. La renovación por lo tanto prolonga la vida de un autenticador que ha de vencer.
  18. Captive Portal puede trabajar en modo enrutado o en Modo Bridge. ¿Qué significa eso?
    En enrutados modo lo gateway deben trabajar como un router IP y se configura como la puerta de enlace predeterminada de cada cliente asociado con la red inalámbrica. Por esta razón, la subred IP para la parte WiFi LAN es diferente de la subred en el resto de la red.
    En cambio, en Modo Bridge la puerta de enlace es una capa de 2 bridge que une a la protección LAN segmento con el resto de la red. Las ventajas más evidentes de este método es que los clientes pueden tener las mismas direcciones IP independiente de si se encuentran en WI-FI o en la LAN cableada. También es obvio que no sólo el protocolo IP se puede transitar de un lado a otro, sino también cualquier otro protocolo encapsulado en las tramas Ethernet. En particular, si se considera que en modo bridge de nivel 2 de difusión también se transmitió, en la red Wi-Fi no es necesario para activar un servidor dhcp a atribuir las direcciones, sin embargo usted puede hacer uso del presente de servidor en el resto de la LAN.
  19. El portal cautivo es capaz de autenticar con certificados x.509?
    A partir de la version 1.0.beta6, si el usuario presiona el botón X.509 que aparece en la página de acceso web y en el navegador de Internet no es una clave válida privada con el certificado X.509 relacionados firmado por una Autoridad de Certificación de confianza, el usuario es capaz de acceder a la red sin necesidad de introducir nombre de usuario y contraseña. El uso de este método de autenticación se puede utilizar la Smart Card para acceder a la LAN.



    Copyright (C) 2005-2012 by Fulvio Ricciardi