What is it?
In greater details:
Proxy with Antivirus
WiFi Access Point
NIS and LDAP
All Generic Storage Networking VPN Wi-Fi security
Questions on Wi-Fi Wireless network security
- I have a Wi-Fi network and would like to protect it from unauthorised access. It is better to use a RADIUS server that allows me to have 802.1x authentication and protection with WPA or WPA2 or use a Captive Portal that authenticates access via web login?
RADIUS server, 802.1x, WPA, 802.11i (WPA2)
- In RADIUS terminology in reference to WiFi network protection, what does supplicant, authenticator, NAS and authentication server mean?
- Does the ZeroShell RADIUS server support WPA and 802.11i (WPA2) protocol to protect the wireless networks?
- When configured, the supplicant on my computer, must choose the authentication method among EAP-TLS, EAP-TTLS and PEAP. What is involved?
- I have an Access Point the uses the Multiple SSID functionality so that different SSIDs can be configured and mapped on different VLANs. If I use ZeroShell as the RADIUS server, can I associate the Wi-Fi clients on the different VLANs based on the username used during 802.1x authentication?
- During configuration of the access point and the RADIUS server, I am requested to specify a Shared Secret. What is it?
- The ZeroShell RADIUS server can also function in proxy mode. What does it mean exactly?
- Does ZeroShell support WEP and WPA-PSK to protect Wi-Fi networks?
- The ZeroShell Captive Portal is composed of two modules: the Web Login server and the Captive Gateway. What is the advantage of such modularity?
- I want to create a multi-gateway structure with the ZeroShell Captive Portal. What is the maximum number of captive gateways I can have on the same web login server?
- What are the authentication sources used by the ZeroShell Captive Portal web login server to validate users?
- Can the ZeroShell Captive Portal use a RADIUS server as an authentication source?
- Can the ZeroShell Captive Portal simultaneously use multiple authentication sources?
- I am afraid that an impostor, using a spoof IP address, can replace the web login server with a fake one and trick the gateways into making them authorised clients that shouldn't be there. Is there any danger of this for ZeroShell Captive Portals?
- When I authenticate with the ZeroShell Captive Portal, immediately after inserting my username and password and pressing the network access button, at the same time as the popup appears to control the connection, the browser warns me that my data will not be encrypted and therefore security problems may arise. Should I be worried? Will my data be available on the network?
- Should an impostor capture the authenticator on the network and, without decrypting it, sends it as is to the captive gateway, could he or she obtain illegal access to the network?
- Why should not the user close the popup control window which appears after the authentication with the CaptivePortal?
- Captive gateways can work in Routed Mode or in Bridged Mode. What does that mean?
- Is the ZeroShell's Captive Portal able to authenticate the clients by using X.509 certificates?
I have a Wi-Fi network and would like to protect it from unauthorised access. It is better to use a RADIUS server that allows me to have 802.1x authentication and protection with WPA or WPA2 or use a Captive Portal that authenticates access via web login?
Both methods have benefits and faults. Using RADIUS with 802.11i you will be more secure due to the fact that other than access authentication, which occurs when the client associates to an access point, the data link layer of wireless communication is encrypted with encryption keys which are changed at regular intervals. On the other hand, a Captive Portal gateway simply authorises access when the client already has an IP address. In this case, if the data must also be encrypted we must avail of other expedients, for example VPNs. The captive portal has the undisputable advantage that it does not require any client side configuration and can work with any Wi-Fi hardware. In reality, given it works at IP level, the Captive Portal can protect access even on a cabled network. Instead, the system with a RADIUS server, other than being more complicated to configure for the user, requires hardware (access point and wireless network card) support and operating system support. To conclude, we can say that the Captive Portal is better adapted in HotSpots in which the only objective is to protect against indiscriminate Internet access. WPA and WPA2 with a RADIUS server better adapt to situations where it is indispensable to guarantee both data confidentiality and user authentication.
In RADIUS terminology in reference to WiFi network protection, what does supplicant, authenticator, NAS and authentication server mean?
A client that tries to associate with a network authenticated with 802.1x is called a supplicant. The term supplicant is often used for software present on the client that manages the 802.1x authentication process: in Windows XP or Mac OS X the supplicant is already integrated into the system, while in Linux, for the majority of distributions, the Xsupplicant packet of the open1x project must be installed.
The terms authenticator and NAS (Network Access Server) refer to access points. Some cheaper access points may not be able to work as an authenticator since they cannot manage 802.1x protocol.
Lastly, the term authentication server indicates the server delegated the task of establishing whether the users wishing to access the network are really who they say they are. The authentication server and the RADIUS server are almost always the same.
Does the ZeroShell RADIUS server support WPA and 802.11i (WPA2) protocol to protect the wireless networks?
Both the WPA and the WPA2 use the frame 802.1x encrypted keys as an authentication and keys generation system. Since the ZeroShell RADIUS server (FreeRadius) supports 802.1x with the authentication methods EAP-TLS, EAP-TTLS and PEAP with Ms-Chapv2, WPA and WPA2 are automatically supported. Note however that since WPA2 requires an encrypted layer with the modern AES encryption algorithm, you will need to check that the hardware used (Accesspoint and Wi-Fi cards) support this encryption. Instead, the WPA uses the RC4 mechanism as coding (as for WEP, but without security problems due to static key access), even old hardware generally works well. At most, an update is required of the firmware and driver.
When configured, the supplicant on my computer, must choose the authentication method among EAP-TLS, EAP-TTLS and PEAP. What is involved?
The 802.1x is an authentication frame, that is, the actual method via which user validation occurs, it is negotiated among those simultaneously available both by the supplicant and by the authentication server. EAP-TLS, PEAP and EAP-TTLS are among the authentication methods considered when using wireless networks because these, using a SSL/TLS encrypted tunnel, provide greater safety guarantees and support for the generation and exchange of encrypted keys used in WPA and 802.11i.
EAP-TLS requires an X.509 digital certificate with the related private key on both the RADIUS server and on the supplicant. Often, given the difficulty of providing a company with a PKI X.509 capable of providing each user with a certificate we won't consider the use of EAP-TLS, even if this method is definitely the most secure since the user doesn't have to type a username or password.
EAP-TLS is ideal when you want to authenticate network access via a smart card by storing the private key and the user certificate directly on this support.
PEAP (Protected EAP), as does EAP-TTLS, requires an X509 certificate and the related private key only from the RADIUS server side. This certificate performs server authentication against the client and subsequently establishes a SSL/TLS tunnel in which other protocol passes to authenticate the user for RADIUS. In general, this protocol is Ms-CHAPv2 in which the user must insert the username and password.
Among PEAP and EAP-TTLS, PEAP with MS-CHAPv2 is the most used. This is probably due to the fact that Windows XP provides native support for this protocol. If instead you wish to use EAP-TTLS on Windows you will need a third party supplicant, for example SecureW2 by Alfa & Ariss.
With regard to Linux, the Xsupplicant supports all three authentication methods.
I have an Access Point the uses the Multiple SSID functionality so that different SSIDs can be configured and mapped on different VLANs. If I use ZeroShell as the RADIUS server, can I associate the Wi-Fi clients on the different VLANs based on the username used during 802.1x authentication?
It is possible. On the form concerning the user, set the VLAN ID 802.1Q of the VLAN on which you want to associate the user. By doing so, the RADIUS server, having authenticated the user with 802.1x, will send the attributes Tunnel-Type (=VLAN), Tunnel-Medium-Type (=802) and Tunnel-Private-Group-ID (=VLAN ID set for user) to the Access Point . If the AP acknowledges these attributes (in general the Cisco APs do it) the client will be automatically associated on the SSID with which the VLANID corresponds.
If authentication occurs via EAP-TLS, and therefore using X.509 certificates instead of normal credentials, the username is taken from the CN field value of the certificate used.
During configuration of the access point and the RADIUS server, I am requested to specify a Shared Secret. What is it?
As the name suggests, a Shared Secret is an alphanumeric sequence shared only between the access point and the RADIUS authentication server. This secret is to guarantee the AP authenticity and the server which intervenes in client authentication: if the shared secret does not correspond, the messages of the 802.1x protocol are not exchanged and authentication immediately fails. Note that while a unique secret must be configured on the access point, one is configured for each access point IP address for the RADIUS server for which it authorises authentication.
The ZeroShell RADIUS server can also work in proxy mode. What does it mean exactly?
In the wireless client supplicant that attempts authentication via 802.1x, the username can be inserted in username@domain format (e.g. pluto@EXAMPLE.COM). Based on the domain, the RADIUS server that receives the request decides if it has the authority to manage it or whether it must delegate another server to do it. In this case, the first RADIUS server says that it is a RADIUS proxy and requires a shared secret with the second, as if it was a normal access point. You can further configure a default RADIUS server to which proxy requests are sent for non explicitly configured domains. Lastly, note that the second RADIUS server could in turn not be capable of managing the request and must therefore act as a proxy for another server and so on until it reaches a server authoritative to manage the authentication of the domain.
Does ZeroShell support WEP and WPA-PSK to protect Wi-Fi networks?
Both WEP and WPA-PSK are preshared key protection systems, meaning that a supplicant trying to associate with an access point must share a preset key with the latter. That said, it is not necessary to have an authentication server that validates each user and therefore wondering if ZeroShell supports WEP and WPA-PSK is pointless.
Nowaday, WEP is insufficient to also protect a domestic wireless network given the RC4 code on which it is based and together with an initialisation vector of only 24 bit to combine with the shared key, it could be quickly cracked if enough packets are sniffed. WPA-PSK, which instead uses a 48 bit initialisation vector, on condition that it is used with a PSK of at least 20 characters, is considered an acceptable solution in domestic or SOHO environments.
The ZeroShell Captive Portal is composed of two modules: the Web Login server and the Captive Gateway. What is the advantage of such modularity?
The Captive Gateway functionality acts as a gateway (router or bridge) which, for the yet to be authenticated clients, prevents access to a protected LAN zone and forwards only the requests on ports 80 (http) and 443 (https) to a Web Login server (also called the Authentication Server). The task of the latter is to present an authentication web page to the user to insert a username and password. If authentication has a positive outcome, the captive gateway removes the barriers for the authenticated client and allows access to the protected zone.
Separating these two functionalities into distinct modules is advantageous because a multi-gateways structure can be created in which multiple captive gateways protect the different networks, which are also geographically distanced and which use the same web login server. By doing so, the customisation of the login and accounting web page take place in one place only instead of on each gateway.
I want to create a multi-gateway structure with the ZeroShell Captive Portal. What is the maximum number of captive gateways I can have on the same web login server?
Theoretically, there is no limit to the number of gateways you have on one web login server. In practice, however, the limit depends on multiple factors, including: the performances of the authentication server hardware (*); the average number of clients managed by the various captive gateways and on fault tolerance considerations.
Note (*): you could easily make the mistake of considering the work load of the web login server to be less than that of a gateway, given the first should only provide an authentication web page and, subsequently, validate user access to the network. It is apparently a small job. Yet, things are not quite like this. Lots of software, especially those using p2p techniques, use non standard TCP 80 and 433 ports in an attempt to overcome possible firewalls at all costs. What network administrator in fact would ever close the outbound ports where default WWW traffic is encapsulated? Almost none. Skype, the well-known and most diffused system of VoIp telephony, is an example of such software. After having tried to connect using different TCP ports in the range of 1-65535 as the destination, try using the 443 port (https) and, if this also fails, use the 80 port (http). The procedure is then reiterated if the latter doesn't have a positive outcome. The captive gateway, which doesn't know that the traffic generated on those ports is not from a normal web browser, but by Skype, forwards the request to the authentication server which in turn initially ignores the fact that http protocol is not used, and is forced to process it. The solution to this problem would be to implement a layer 5 firewall on the gateways, which would act like filters of the content transported in the TCP packets and therefore forward only the requests that really use http protocol. ZeroShell does not implement this feature.
What are the authentication sources used by the ZeroShell Captive Portal web login server to validate users?
The ZeroShell Captive Portal authentication server can use the following as authentication sources: the integrated Kerberos v5 server to validate all local users; an external Kerberos 5 to authenticate the users of another realm, for example, a Microsoft Active Directory domain; the cross authentication between the Kerberos v5 realm to authenticate users of an external domain which is trusted by the local realm.
Can the ZeroShell Captive Portal use a RADIUS server as an authentication source?
From the ZeroShell 1.0.beta6 version, the Captive Portal can use, other than Kerberos 5 authentication, RADIUS authentication using the local server as a proxy towards other configured RADIUS servers.
Can the ZeroShell Captive Portal simultaneously use multiple authentication sources?
Yes, it can. The user must choose to which domain it belongs on the web login page. Based on this choice, the web login server can contact the correct authentication provider. The choice of domain can occur using the list box in the web login page or using a username in the format username@DOMAIN
I am afraid that an impostor, using a spoofed IP address, can replace the web login server with a fake one and trick the gateways into making them authorised clients that shouldn't be there. Is there any danger of this for ZeroShell Captive Portals?
No, there is no danger of this because the web login server and the captive gateways, which compose the same infrastructure, share a secret (a Shared Secret to be configured by the administrator). After the web login server authenticates the user via Kerberos 5 or RADIUS, it responds to the gateway via an encrypted packet with AES256 using the shared secret as the key. This packet, called the Authenticator, contains the complete domain username, the IP address of the client and the server timestamp. When the captive gateway receives the response, it must decrypt the authenticator to read the username and the IP for which the connection opens. However, if the authentication server is fake, the key would not correspond to that used to encrypt the authenticator and the gateway would not recognise the server authority. Note that an authenticator has a very brief life to avoid being captured by an impostor and being illegally reused while crossing the network to open a connection. This implies that until the Captive Portal infrastructure functions correctly the clocks on the web login server system and the gateways must be synchronised within a certain tolerance. It is highly recommend the use of NTP (Network Time Protocol).
When I authenticate with the ZeroShell Captive Portal, immediately after inserting my username and password and pressing the network access button, at the same time as the popup appears to control the connection, the browser warns me that my data will not be encrypted and therefore security problems may arise. Should I be worried? Will my data be available on the network?
There is absolutely no need to worry about this message coming from the browser. The username and password you type pass through an encrypted SSL tunnel thanks to the use of https requests. Instead, when the web login server has already authenticated your session it is no longer encrypted and the data to which the browser refers are none other than the authenticator which, created by the authentication server, must transit towards the gateway. The authenticator is already encrypted with AES256 and there is no need to use further SSL coding.
Should an impostor capture the authenticator on the network and, without decrypting it, sends it as is to the captive gateway, could he or she obtain illegal access to the network?
It is not as simple as it seems. Once the impostor has sniffed the authenticator, before using it he or she must wait for the legitimate client to abandon the network. The IP and MAC addresses would then be changed and made correspond with those of the client who abandoned the network and lastly send the authenticator to the gateway, while waiting for the latter to enable the connection. In fact, the impostor would wait in vain for two reasons: the authenticator has a limited duration over time and most certainly, on use by an impostor, will have already expired; the captive gateway can remember previously used authenticators to enable a connection and won't allow access to a replica.
Why should not the user close the popup control window which appears after the authentication with the CaptivePortal?
Because this window, other than allowing forced disconnection by the user, guarantees the continuous renewal of the authenticator before it expires. If this window is closed the gateway, which no longer sees any requests for renewal, will decide to close the client connection.
It is probably already evident that until a gateway renews an authenticator, the latter must be still valid. The renewal therefore prolongs the life of an authenticator which has yet to expire.
Captive gateways can work in Routed Mode or in Bridged Mode. What does that mean?
In Routed Mode the captive gateway must work as an IP router and is configured as the default gateway on each client associated with the wireless network. For this reason, the IP subnet for the WiFi LAN part is different from the subnet on the rest of the network.
Instead, in Bridged Mode the gateway is a layer 2 bridge that joins the protected LAN segment with the rest of the network. The most obvious advantages of this method is that clients can have the same IP addresses independent of whether they are located on WI-FI or on the wired LAN. It is also obvious that not only IP protocol can transit from one part to another, but also any other protocol encapsulated in the Ethernet frames. In particular, if you consider that in bridged mode the level 2 broadcast is also forwarded, on the Wi-Fi network there is no need to activate a dhcp server to attribute the addresses, however you may avail of the server present on the rest of the LAN.
Is the ZeroShell's Captive Portal able to authenticate the clients by using X.509 certificates?
Starting with the release 1.0.beta6, if the user press the button X.509 that appears in the web login page and in the web browser there is a valid private key with the related X.509 certificate signed by a Trusted Certification Authority, the user is able to access to the network without insert Username and Password. Using this authentication method you can use the Smart Card to access to the LAN.