Architecture is the key in securing WLAN
on
Are You Using 802.1X?
·
· Score: 2, Interesting
802.1X, TKIP, WPA and so on are all nice methods to control WLAN access, but even they cannot correct a louzy WLAN architecture.
The problem is that in several, even most places, people are connecting their access points directly to their intranet and then rely only on the WEP key, MAC address lists, 802.1X and the WiFi security standard of your choice. In this kind of architecture when a standard is broken or the access point is compromised or just mis-configured, the attacker is able to gain access instantly to the protected network.
In our university this was the starting situation. Every department had their own WLAN with own WEP keys and MAC lists and some didn't even have those, just completely open network without any kind of access control. Not to mention about radio channel allocation or planning. Instead of the seamless, combined radio coverage there were several separate networks often disturbing each other.
A project was then started to define a common architecture for building wireless network securely and to provide that seamless combined radio coverage instead of all these kind of wild networks. What we decided was that WLAN networks are hostile networks and they should be treated as such. In the new architecture the organisation wide WLAN network is separated outside protected networks so that even if the access control of the wireless networks is breached, the only access the attacker directly gains is the access to the Internet, not to organisation's protected networks.
We didn't choose to use WEP key and MAC access control lists because they were useless. We didn't yet integrate 802.1X as a access control, because the terminals aren't yet ready for it. Instead we chose to build our WLAN network by using a captive portal to control the traffic demanding less security and VPNs to protect the traffic demanding more. By providing several means to authenticate we achieved the better interoperability and usability of the WLAN network than before.
With this architecture we are now able to server several different terminals, utilise old access points not capable of WEP encryption and support the customised solutions the different departments want to use. The architecture supports even Radius-based WLAN roaming so that people between organisations may use their home user accounts for authentication in the roaming partner's public access network. The same roaming architecture can be then used even if the WLAN network is in the future migrated to the 802.1X.
So... since when does release schedule have ANYTHING to do with security? Sure, Debian and Slackware don't release new versions often. This doesn't mean they don't release security fixes.
I completely agree with this. Having the bleeding edge versions of software is not so important as having stable software and security fixes to those. Take for example the server environment - you don't need there the latest version of everything, you need things that work for sure.
Debian likes to make sure the release is rock solid before releasing it. I'll be the first to admit that sometimes it is a bit slow. But this does not make the distribution less secure. In reality, it helps make it more secure.
It seems to me that the author lacks knowledge of the very definition of security. The Security is not just fast updates, new versions and how vulnerable the system is for attacks. It's also about how stable the system and the software is, how easy it is to break/repair by inexperienced system administrators or users and how easy/hard is to lose data with it.
One thing the author of the article gets right, however, is that the time to get security updates to known vulnerabilities is quite a good way to compare distributions. So is the shape of the host (services up and inetd.conf) after the default installation has ended. But in my opinion also the stability and other things mentioned before should be tested and clearly no distribution or operating system should be excluded just because their release cycle is slow. I wonder how the author would have done the tests, if there had been for example Trusted Solaris included (with its ridiculously slow release schedule.).
Anyways, that comment alone was enough to make me skeptical of the actual knowledge of the author. It is a really ignorant, offhand remark to make, and has no relevance to security. But that is just me.
Well you're now the only one, but when I look also other tests about various issues (like performance) done nowadays, it seems that doing bad tests is more like a rule than an exception.
Slashdot Mirror
Then there are already versions for Symbian S60 platforms like:
g =en)
SymTorrent (http://www.aut.bme.hu/portal/SymTorrent.aspx?lan
802.1X, TKIP, WPA and so on are all nice methods to control WLAN access, but even they cannot correct a louzy WLAN architecture.
The problem is that in several, even most places, people are connecting their access points directly to their intranet and then rely only on the WEP key, MAC address lists, 802.1X and the WiFi security standard of your choice. In this kind of architecture when a standard is broken or the access point is compromised or just mis-configured, the attacker is able to gain access instantly to the protected network.
In our university this was the starting situation. Every department had their own WLAN with own WEP keys and MAC lists and some didn't even have those, just completely open network without any kind of access control. Not to mention about radio channel allocation or planning. Instead of the seamless, combined radio coverage there were several separate networks often disturbing each other.
A project was then started to define a common architecture for building wireless network securely and to provide that seamless combined radio coverage instead of all these kind of wild networks. What we decided was that WLAN networks are hostile networks and they should be treated as such. In the new architecture the organisation wide WLAN network is separated outside protected networks so that even if the access control of the wireless networks is breached, the only access the attacker directly gains is the access to the Internet, not to organisation's protected networks.
We didn't choose to use WEP key and MAC access control lists because they were useless. We didn't yet integrate 802.1X as a access control, because the terminals aren't yet ready for it. Instead we chose to build our WLAN network by using a captive portal to control the traffic demanding less security and VPNs to protect the traffic demanding more. By providing several means to authenticate we achieved the better interoperability and usability of the WLAN network than before.
With this architecture we are now able to server several different terminals, utilise old access points not capable of WEP encryption and support the customised solutions the different departments want to use. The architecture supports even Radius-based WLAN roaming so that people between organisations may use their home user accounts for authentication in the roaming partner's public access network. The same roaming architecture can be then used even if the WLAN network is in the future migrated to the 802.1X.
So... since when does release schedule have ANYTHING to do with security? Sure, Debian and Slackware don't release new versions often. This doesn't mean they don't release security fixes.
I completely agree with this. Having the bleeding edge versions of software is not so important as having stable software and security fixes to those. Take for example the server environment - you don't need there the latest version of everything, you need things that work for sure.
Debian likes to make sure the release is rock solid before releasing it. I'll be the first to admit that sometimes it is a bit slow. But this does not make the distribution less secure. In reality, it helps make it more secure.
It seems to me that the author lacks knowledge of the very definition of security. The Security is not just fast updates, new versions and how vulnerable the system is for attacks. It's also about how stable the system and the software is, how easy it is to break/repair by inexperienced system administrators or users and how easy/hard is to lose data with it.
One thing the author of the article gets right, however, is that the time to get security updates to known vulnerabilities is quite a good way to compare distributions. So is the shape of the host (services up and inetd.conf) after the default installation has ended. But in my opinion also the stability and other things mentioned before should be tested and clearly no distribution or operating system should be excluded just because their release cycle is slow. I wonder how the author would have done the tests, if there had been for example Trusted Solaris included (with its ridiculously slow release schedule.).
Anyways, that comment alone was enough to make me skeptical of the actual knowledge of the author. It is a really ignorant, offhand remark to make, and has no relevance to security. But that is just me.
Well you're now the only one, but when I look also other tests about various issues (like performance) done nowadays, it seems that doing bad tests is more like a rule than an exception.