Layered Architecture Captive Portal Technologies Information Technology Essay

In a layered architecture, captive portal technologies usually operate at layer 2 which provides many basic flaws of interoperability between switches and routers because of its lack of layer 3 IP authentication. In this paper, some feasible captive portal solutions were analyzed per layered topology in order to find out if they could operate in layer 3 environments and based on their results, a detailed solution was implemented and executed to fulfill the needs of a layer 3 captive portal solution. This research proved useful by increasing authentication security in captive portal technologies and giving it increased scalability.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Essay Writing Service

Introduction AND LITERATURE REVIEW

The first phase of this research will be to perform a literature study on existing solutions, the second phase will be to test these various solutions on both platforms and the third phase will be to implement or modify an existing solution. So far based on search results there exist quite a few number of present captive portal solutions which are licensed for free use. Based on findings by Wikipedia, these are the present solutions:

Air Marshal, software based for Linux platform (commercial)

Amazingports, Linux based software with integrated billing and payment implementing service-oriented provisioning, free and commercial

ChilliSpot, open source Linux daemon [abandoned]

CoovaChilli, open source Linux daemon based on ChilliSpot

CuteHotspot, Windows based (commercial)

Antamedia, Windows based HotSpot Billing Software, which helps you control and bill your customers for the Internet usage (commercial)

DNS Redirector, Windows based (commercial)

FirstSpot, Windows based (commercial)

Microsolut, Windows based professional hotspot software. Include billing and payment gateways. (Free / commercial)

LogiSense, Billing & OSS / Network Access Control (commercial)

m0n0wall, FreeBSD based firewall distribution

PacketFence, Linux based Network Access Control software featuring a captive portal (open source)

pfSense, FreeBSD based firewall software derived from m0n0wall

Recaptive, Linux based (commercial, cloud based, Free version available)

Untangle Captive Portal, Firewall featuring Captive Portal (Linux-based, free basic functionality, commercial directory integration)

WiFiDog Captive Portal Suite, small C based kernel solution (embeddable)

Wilmagate, C++ based and is executable both in Linux and Windows/Cygwin environments

Zentyal, Linux based firewall distribution

Zeroshell, Linux based network services distribution’

Before going into detail about the capabilities/functionalities of each of the captive portal solutions, it is imperative that the functionality of basic captive portal solutions be explained. There are two ways in which a user could become authenticated to use the services offered by a network. One could be to use Authentication and traffic encryption via WEP/WPA/WPA3 or captive portals. The former requires a client to be authenticated with the radius server prior gaining access to the network and the latter creates a completely open mode without any authentication and encryptions that enables a user to first gain access to the network and later request it’s services via web based authentication. However captive portal solutions are not as secured as the other but sometimes most suitable in scenarios because the users need to configure their client to authenticate via 802.1x which is not best suited for occasional users. Captive portal solutions work as a medium of authentication for wireless and Ethernet networks. This solution forces a node in a network trying to make an HTTP request to be redirected to a different web page (This redirected page is white listed in the IPTABLES thus making it accessible). This page could be an authentication page that requires a user name and a password or it could be some policy rules governing the use of internet access in that network. However today, most captive portal solutions are mostly used for business purposes where users need to pay for access. A common public well known hotspot solution today in Belgium is the TELENETHOMESPOT. Usually hotspot network technologies are always unencrypted and thus unsecure to network access. Meaning, any nodes within proximity of the wifi range can join that network with a DHCP IP provided. But what limits it is just the fact that authentication must be made before access to the internet.

Figure

Looking at the figure above, it is noticed that the network icon displays that the node is now connected to the network with an IP address but no internet access. Without the right login credentials, internet access is not guaranteed.

Figure

The figure above displays a different captive portal technology. Looking at the redirected link(http://143.169.249.244/cgi-bin/login?cmd=login&mac=02:0c:8b:a5:ea:4f&ip=143.169.222.185&essid=UA-guest&url=http%3A%2F%2Fgoogle%2Ecom%2F) after trying to access google.com, it is seen that ,

The request to google.com has been redirected to the gateway IP address 143.169.249.244 for login.

Captive portal solutions can be implemented using HTTP REDIRECTION, IP REDIRECTION AND DNS REDIRECTION. For the first method, if an unauthenticated node tries to access any website other than the login gateway, the browser does its normal duties by resolving the IP address of the site using DNS. After this process, an HTTP request is sent from the browser to the resolved IP address which is then intercepted by the firewall. The firewall now causes a redirection by sending the login page instead. Such a method is transparent to nodes since it is assumed that the website which they wanted to visit sent this redirection. The HTTP redirection uses is 302. The second IP redirect(layer 3) is actually the main goal of this research internship. Which enables client traffic to the redirected using IP redirect on layer 3. For DNS redirection, When a client requests a website, DNS is queried by the browser. The firewall will make sure that only the DNS server(s) provided by DHCP can be used by unauthenticated clients (or, alternatively, it will forward all DNS requests by unauthenticated clients to that DNS server). This DNS server will return the IP address of the Captive Portal page as a result of all DNS lookups. In order to perform redirection by DNS the captive portal is using DNS poisoning to perform a Man-in-the-middle attack. As a result a user will see an SSL certificate violation when attempting to visit an HTTPS page. To limit the impact of DNS poisoning typically a TTL of 0 is used. The use of a TTL value of 0 will still overwrite the users local resolver cache which may cause conflicts with previously authenticated services.

RESEARCH METHODOLOGY

The main idea as to why layer 3 captive portal solutions are highly deemed useful can be seen in respect to scalability. Legacy tools of captive portals(layer 2) had a limitation in the sense that, if a user install a non bridge device such as a router between a client and a captive portal server, it just won’t work because, the intermediary device won’t be able to assign IP addresses to the client therefore creating a barrier of scalability. The figures below in order of appearance shows a layer 2 and layer 3 topology in which these solutions should be able to operate on. Presently it is assumed that all captive portal solutions can operate on layer 2 so main tests will be carried out on layer 3.

Figure The operating system to be used in this research will be a Voyage x86 derived from Debian OS. Voyage is a stripped down Debian with limited capabilities which is able to fulfill the requirements of the test. This OS will be installed on an ALIX embedded system. When testing out Linux distribution solutions with embedded captive portal functionalities, an ATOM based computer will be used.C:UsersFrank-SeniorSkyDriveDocumentsMSc COMPUTER SCIENCEResearch Internshiplayer2.jpg

Figure C:UsersFrank-SeniorSkyDriveDocumentsMSc COMPUTER SCIENCEResearch Internshiplayer3.jpg

ANALYSES

Based on recent findings, Chillispot is has been a discontinued project since 2008 and doesn’t support the features of layer3 topologies. However it’s successor CoovaChilli has been promising and upon recent findings, it could be a feasible choice for layer 3. Microslut will be cancelled off the analyses since it’s a windows only implementation and not open source which goes against the hardware specs of the internship. Since the capabilities of my research strictly  rely of open source/free systems, the list above will be filtered to only open source solutions. Also, captive portal solutions that are linux open source distributions will be tested out as a last option after all present open based softwares must have been analyzed.

Free open source software

Free open source linux distributions

Free/Commercial

CoovaChilli

M0n0wall

Air Marshal

WifiDog

Zentyl

sweetspot

Zeroshell

CoovaChilli

Based on the pupolar outsource project chillispot which is now defunct brought to life this great tool CoovaChilli which as it’s mentor, It’s an open source software access controller. This tool provides captive portal solutions environments. This tool uses the well known RADIUS server for client server authentications/accounting as well as the http protocol. An figure below shows the authentication/network topology for this tool running on this network.

CoovaChilli.jpg

Figure

Coovachilli used layer 2 mac based authentication for its past released but now boost on its most recent implementation of layer 3 ip based technology. By default, coovachilli runs in layer 2 which in this layer all ARP requests are handled and it is it’s responsibility of also handling DHCP which by these means creates a relationship between the IP addresses of the subscribers and their MACS for authentication purposes. This can be done during building by building with -ENABLE-LAYER3. By doing this, coovachilli will no more operate at layer 2 to track subscriber sessions but on layer 3 based on IP addresses. In this mode all MAC address authentication methods will be substitudted for IP based. However is it said that Coovachilli can’t operate simultaneously in both L2 and L3.

Air Marshall

A review of Air Marshal hotspot technology proved that, this technology can operate on layer 3 IP routing and layer 2 transparent bridging. listed below are the specifications of this technology. Gotten from source http://www.wifihotspot.cn. But it is however unfortunate that this technology is not opensource although it has both free and commercial versions.

RADIUS/AAA Features

RADIUS Authentication of User credentials and Device/MAC address

RADIUS Accounting – detailed logging of IP, MAC, time and data usage, disconnect reason, etc.

Interim Accounting status updates

RFC3576 Mid-Session Disconnect

Periodic Session Reauthorization

Ascend Binary Data Filter VSAs

MAC based Device Pre-Authentication

WISPr Location, Redirect, Bandwidth control and Session limiting VSAs

Startup device reboot indication

Support for Backup RADIUS authentication and accounting servers

Network & Session Features

Layer 3 IP Routing

Private Address / NAT services

Layer 2 transparent bridging

TCP & UDP device authentication listeners

IP or network layer session tracking

Multiple networks and interfaces

Air Marshal General Features

Single server supports thousands of concurrent sessions

Browser based password encryption

SSL Encryption

Configurable Web HTML interface

User status display

Integrated ADMIN interface

Active session list

Setup a wallet garden

Local account management

Anonymous Access

Client Data Mirroring

Transparent web proxy

Maximum UL/DL data rates per user

Commercial session interruption

m0n0wall

Monowall is an open source project that provides embedded firewall solutions that when installed on embedded computers such as ALIX, it provides commercial level based firewall solutions. It is based on bare-bones version of FreeBSD. It provides a captive portal functionality in its package that controls HTTP browser access to the internet by redirection of unauthenticated users. Authentication is said to operate on the MAC layer although in its documentation is it stated that it provides services in layer 3 and 4. It is doubted if a layer 3 topology for captive portal solutions will operate. No study has been seen to clear this doubt.

Some features of the m0n0wall Captive Portal include:

Interface selection (typically the LAN interface)

Allow selected IP or MAC addresses

User authentication choices (none, local, or RADIUS)

Maximum concurrent connections

Concurrent user logins

Local user management option

Per user bandwidth restrictions

Idle and Hard timeout

Log out popup window

Redirection URL

MAC filtering

HTTPS authentication

Customizable portal page contents

Customizable authentication failure page

Voucher support (in the upcoming 1.3 m0n0wal

Wifidog

Wifidog is an open source project providing captive portal solutions(authentication and authorization), centralized network monitoring and location-aware delivery of internal and external content.

General Flow Description:

The client joins the network and attempts to visit a foreign URL e.g google.com

The Gateway’s firewall rules mangle the request to redirect it to a local port on the Gateway. When that’s the done, the Gateway provides an HTTP Redirect reply that contains the Gateway ID, Gateway FQDN and other informations

The Client does his request to the Auth Server as specified by the Gateway

The gateway replies the client by providing a login page or policy page.

The Client provides his identification informations (username and password)

Upon successful authentication, the client gets an HTTP Redirect to the Gateway’s own web server with his authentication proof (a one-time token), http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token]

The Client then connects to the Gateway and thus gives it his token

The Gateway requests validation of the token from the Auth Server

The Auth Server confirms the token

The Gateway then sends a redirect to the Client to obtain the Success Page from the Auth Server, redirects to http://auth_server/portal/

The Auth Server notifies the Client that his request was successful

Figure http://www.ilesansfil.org/dist/pascal/images/documentation/dev/FlowDiagram.png

ZEROSHELL

ZEROSHELL is a linux distribution with a “web based interfaces” that provides services for networks (Router/Bridge). This distribution feautures a captive portal solution to support web login on wired and wireless networks. The Captive portal solution uses keberos 5 for user authentication prior permission for internet. “Zeroshell implements the functionality of Captive Portal in native way, without using other specific software as NoCat or Chillispot” Zeroshell.org.

Figure Hotspot network protected by a Captive Portal Router

In Figure 7 the captive portal works as a Level 3 router connected directly to a modem which connects to the Internet. It acts as the default gateway for clients that connect to the network. In this configuration, said in Routed Mode, it is convenient the router performs the function of DHCP and DNS servers.

The Zeroshell’s Captive Portal can also work in Bridge Mode, where the network to be protected by the Captive Portal shares the same IP subnet as the rest of the LAN. Therefore, a client gets the same IP address if you connect from one side than the other and has the same default gateway that is a router ahead of the Captive Portal. In this case, DHCP and DNS to be used for the hotspot may be the same as those used for the rest of the LAN.

In previous versions of Zeroshell you had to explicitly declare the operating mode (Routed or Bridge) of the captive portal. Since the release 1.0.beta15, however, there are 2 news about:

It is handled the MULTI interface where you can declare multiple network interfaces on which to activate the Captive Portal. As shown in Figure Captive Portal can also be enabled on 802.1q VLAN (Virtual LAN Tagged);

Zeroshell selects the bridge or router mode automatically checking whether or not an interface is part of a bridge.

Putting together the two innovations, one deduces that the Captive Portal of Zeroshell can work simultaneously on the same hardware box as a router for some LAN segments and as a bridge for others.  RADIUS authentication is one of the most widely used protocols for the recognition of users on network devices such as Wireless Access Points or layer 2 Switches that allow access to level 2 only after authentication has been successful. The Captive Portal of Zeroshell allows RADIUS authentication requests to external servers via proxy. In other words, the captive portal requires authentication to its internal FreeRADIUS server, that if it discovers that it is not authoritative for the domain to which the user belongs, it forwards the authentication request to the external authoritative RADIUS server. Clearly, the external RADIUS server must be configured in the list of proxy servers by specifying the Shared Secret. On the other hand, even on the external RADIUS server, an entry must be added between the RADIUS clients to enable the IP address of the Captive Portal using the same shared secret. In the list of RADIUS proxy, you can add the DEFAULT RADIUS server that is used when none of the other servers is authoritative for authenticating the user. The default proxy radius is often used even when the captive portal has to authenticate against a RADIUS server hierarchy.  The captive portal can make authentication requests via PAP or 802.1x (EAP-TTLS with PAP and PEAP with MSCHAPv2).

Find Out How UKEssays.com Can Help You!

Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.

View our academic writing services

sweetspot

Sweetspot is an open source linux project based on the now defunct Chillispot, Sweet spot is a network access controller that has the capibilities of captive portal technologies. What makes this project so different from the others is that, it focuses mainly on layer 3 rather than layer 2 that adheres to large scale networks. Just like its mentor, it’s primary purpose involves the transmission of layer 3 packers between network interfaces. All traffic within the user and the internet goes through the chillispot daemon that provides authentication(access control) and accounting. Just like other captive portal solutions, it has the basic flow of authentication and redirection. The Sweetspot daemon can be viewed as a pipeline between two network interfaces with a valve in-between. This valve takes shape of a packet filter that can either pass or drop or redirect packets passing through. Authenticated IP addresses can be assigned individual packet filters or no packet filter at all. In contrary, all “captured” sessions share a single packet filter which may cause captivity and enforce user authentication for certain targets/protocols while it may also open up loopholes to freely available services. It is advised that IP address based authentication appears even more vulnerable as it may be a bit easier for user to fake IP compared to MAC address.

ZENTYAL

Zentyal is an open source linux distribution based on UBUNTU. It is basically a small linux platform with multiple capabilities. Some of them are :

Gateway

Infrastructure Manager

Unified Threat Manager

Office Server

Unified Communication Server

Zentyal implements a Captive Portal service, which allows you to limit the access to the network from the internal interfaces. However, there are no proven reviews stating it’s interoperability and functionality in layer 3 environments.

IMPLEMENTATION

Testout – 3 Solutions.

Provide references in report.

Will test these solutions and based on their functionality, provide feedback and conclusion.