There is no doubt that the siren song of wireless networks is becoming louder and more compelling as the maximum data rates climb. While the current breed of wireless can't as yet hold a candle to the data rates of a wired network, many users find trading speed for mobility an acceptable exchange.
If you're like me, you probably cringe at the thought of introducing wireless into your network. With all of the security issues that you have to manage with a wired network, it seems masochistic to introduce a technology that is infamous for security breaches. (Ask any technologically inclined teenager what "war driving" is.) One thing is certain, though. If your users want wireless and you don't provide it, they will. And they won't be doing so with network security in mind. Instead, they'll be using whatever they purchase at the local office supply store, which, by default, will be open access points, broadcasting ESSIDs like "Linksys" and "Belkin" to the world. They may not even take the time to enable the minimal security provided by Wired Equivalent Privacy (WEP) encryption.
Like it or not, you fall into one of two categories: those who already have adopted wireless technology or those who will. If you're in the latter category, you may want to look at a Linux-based solution.
It's Abysmal
Before bringing up the topic of wireless security, I do need to report the current state of wireless technology support in Linux. In a word, it's abysmal—at least when measured against the standard set by wireless support in Windows. It's not that way because Linux software developers don't have the talent to support wireless—far from it. Wireless support is lacking because the manufacturers of the networking cards are loathe to release the specifications for their hardware, thus making the task of writing a driver difficult.
Hardware manufacturers cite two primary reasons for withholding the information. The first is the standard disclaimer used by companies: that the information would expose trade secrets. I might actually buy this excuse were it not for the fact that anyone who wants those trade secrets can certainly disassemble any binary-only driver and discern the inner workings of the hardware it supports, legalities notwithstanding. Besides, the companies could follow the path blazed by graphics card manufacturers such as ATI and nVidia, who provide binary drivers that use GPLed hooks into the Linux kernel to give excellent support for their products.
The second reason is based on the fact that the frequencies on which wireless networking operates and the power output permitted the devices is governed in the United States by the FCC. Worldwide, there are more channels available than what is permissible in the U.S., so manufacturers limit radiated power and channels through their drivers. They argue that by releasing the technical details of their hardware to the open-source community, they expose themselves to possible legal problems should their hardware be operated outside the limitations imposed by the FCC. To me, this reason seems more plausible, albeit tenuous, but I'll give that one to them.
Suffice it to say that Linux support for wireless is spotty. Cards with readily available specifications are well-supported. Cards with scant information will require special voodoo to make them work, and sometimes no amount of chicken sacrifices will coax them to life. You can do a quick Google search on "Linux" and your card model number to see if the card you possess or are considering is supported.
Despite my gloomy report of Linux wireless support, I urge you not to give up on a Linux solution for your wireless needs. The support (or lack thereof) for wireless doesn't necessarily have to negatively affect your ability to employ the great networking features of the Linux kernel, as we shall soon see.
Seamless Transition
Configuring a wireless network for security is really not all that different from configuring a wired network for security. You want some kind of access control to the inbound network connection, and you want the data that traverses the wire (or in this case, the ether) to be encrypted. Those inexpensive wireless routers and access points accomplish this via Wi-Fi Protected Access (WPA) or WEP encryption. You configure your router with a given key and provide to any clients that key and the ESSID you are using for your router. When clients attempt to connect, the key they present will be used for validation and subsequent encryption. Of the two, WEP is older and less secure yet more compatible with Linux because the WEP-only cards are older and better supported. WPA is a relative newcomer that allegedly offers better security than WEP. Beyond that, high-end wireless gear can offer even more sophisticated authentication and encryption than the mass-market stuff, assuming that your budget can withstand the onslaught.
If you apply your knowledge of wired network security (with special regard to the security you apply at your borders) to a wireless network, you'll find that there is very little you need to change to adapt to wireless. The characteristics of a wireless network make it just as untrustworthy as your connection to the Internet, and if you treat it the same, you'll find the transition seamless. In other words, consider the wireless connection to be equivalent to the Internet, and suddenly all of what you already know about security is directly applicable.
Do you have road warriors in your company? Do they connect via IPSec or another VPN solution from their hotel room to your company's network? They can just as easily do that over a wireless network as they can over the wired version (and in some hotels, they are using a wireless network). All of the security measures that you provide for these travelers are applicable to your own internal wireless networks. The trick is to envision your wireless connections as coming from outside your fortified walls, in spite of the fact that the connection may be originating from the office next to yours.
The $100 Solution
While Linux may not directly support many of the wireless cards, it does have superb networking capabilities. How do we take advantage of them? The answer is surprisingly easy and straightforward. You can do your homework and pick a wireless network card that is well-supported, you can delegate the task of managing the wireless connection to a device that was built for the purpose (a wireless access point), or you can purchase a wireless router that is capable of hosting a custom Linux configuration, such as the Linksys WRT54GL.
For the first two suggestions, you need an installation of Linux that has been configured especially for this duty. All the box needs to provide is a DHCP server so that clients can be assigned an IP address, an appropriately tuned firewall/router, and a VPN server (unless you want to route this traffic to another internal server configured for this purpose). Creating an instance of Linux for this is straightforward, but if you want a turnkey solution, you can turn to one of the firewall Linux distributions, such as IPCop. Whether you use a wireless access point or a Linux-supported wireless card in the Linux box itself is irrelevant; the results are the same. I tend toward using wireless access points for two reasons: 1) I don't have to spend huge amounts of time trying to research which of the currently available PCI wireless cards are supported, and 2) I can actually hook multiple access points to the Linux box via a switch. This makes it easy to provide wireless access in multiple areas yet have only one box to administer.
Another interesting solution is to combine the aforementioned Linksys wireless router with a copy of Sveasoft's drop-in firmware. In this scenario, we have what amounts to an appliance; it's physically smaller than what you'd get with a PC-based solution and costs around $100 yet provides the same features available in hardware costing so much more. I have employed this solution in a couple of client locations with great success—even where no wireless access was desired. The firmware makes it easy to disable the wireless interface, so what you end up with is an excellent little firewall/router/VPN server at minimal cost. The only downside is that you have a greater administrative burden should you need to deploy more than one of these in your network.
No Worse Off
When I first started considering wireless, I evaluated the threats I'd be introducing and came to the conclusion that, with the right configuration, I'd be no worse off from a security standpoint than I am by providing inbound access through my Internet connection. The threats are all the same. The only major difference is that I have a much more difficult time keeping people from eavesdropping on a wireless connection than I have on a wired connection. As a result, I have almost completely given up on the modicum of security provided by WEP/WPA encryption and have, instead, decided to redirect the burden of security back onto the Linux box I built for the purpose. While I don't run an open wireless access point (I have to make it a bit sporting for the war drivers, after all), I really could. Connecting to one of my access points isn't going to get you anywhere other than to the interface of my Linux box, and that's no more dangerous than having access to my wired firewall interface. Should the war drivers collect enough packets to deduce my encryption key, they'll only find themselves looking at the encrypted data stream provided by my VPN solution, just like anyone who managed to sniff wire-bound packets on the Internet would.
All That You Need
If you need to provide wireless access to your networks, I recommend you look at a Linux-powered solution. The cost can be significantly less than the cost of a proprietary solution, and it might provide a better fit for your company's needs as well. While Linux may not provide the latest bells and whistles that the expensive, proprietary solutions provide (e.g., hardware keys or biometrics), it may be all that you need to keep the gang in accounting from taking matters into their own hands.
Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online