Secure Wireless Access to Corporate LANS

Figure 5 expands on a scenario described earlier in this paper: securing WLAN traffic destined for intranet servers on the corporate LAN. Employees using WiFi-enabled laptops in a conference room, cafeteria, or other public space can increase business efficiency by accessing their company's internal network resources, or news server. To prevent sniffing by AirSnort or WEPCrack, each laptop uses SecureCRT® to forward ports on the localhost to ports 80 (HTTP), 443 (SSL), and 119 (NNTP - News) listened to by these servers.

Figure 5: Secure Wireless Access to Corporate LANs

An IMail server with browser-based mail access is reached with the URL http://localhost:3080. An IIS server is reached with the URL http://localhost:4080. In this example, different local ports are assigned to forward the same application to different remote hosts. Because we have just one NNTP server, we can simply map local port 119 to remote port 119. As the user navigates these server's web pages, only URLs relative to forwarded hosts (webmail.corp.com and intranet.corp.com) will be accessible.

Since HTTP can be encrypted with SSL (443), why tunnel this over Secure Shell? In this example, only users with known public keys (including those extracted from laptop certificates) may access these intranet servers. The firewall between the 802.11b Wirless Access Point (WAP) and VShell® protects the corporate LAN from the WLAN. Therefore, the only wireless traffic that can penetrate this LAN are authenticated, authorized applications tunneled over Secure Shell. On the other hand, simply opening 443 on this firewall would give any application a free ride into the LAN through this port, reaching any destination without authentication. Finally, multiplexing applications over Secure Shell reduces the total number of TCP connections, optimizing firewall performance.