<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Securism Blog &#187; Network Design</title>
	<atom:link href="http://blog.securism.com/category/network-design/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.securism.com</link>
	<description>Simple Security.</description>
	<lastBuildDate>Thu, 26 Aug 2010 21:53:11 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>WLAN Strategy &#8211; Segmented and Guest Networks</title>
		<link>http://blog.securism.com/2010/08/wlan-strategy-segmented-and-guest-networks/</link>
		<comments>http://blog.securism.com/2010/08/wlan-strategy-segmented-and-guest-networks/#comments</comments>
		<pubDate>Thu, 26 Aug 2010 21:53:11 +0000</pubDate>
		<dc:creator>Jon Janego</dc:creator>
				<category><![CDATA[How-to]]></category>
		<category><![CDATA[Network Design]]></category>
		<category><![CDATA[wifi]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=254</guid>
		<description><![CDATA[Continuing my small series on WLAN deployment strategy, now I&#8217;ll cover the two more uses for wireless networks in a business. Segmented Mobile Data Segmented Mobile Data networks can be found in retail environments for mobile point of sale, hospitals for critical bedside services, warehouses for inventory and logistics, or many other types of environments.  [...]]]></description>
			<content:encoded><![CDATA[<p>Continuing my small series on WLAN deployment strategy, now I&#8217;ll cover the two more uses for wireless networks in a business.</p>
<p><em>Segmented Mobile Data</em></p>
<p>Segmented Mobile Data networks can  be found in retail environments for mobile point of sale, hospitals for  critical bedside services, warehouses for inventory and logistics, or  many other types of environments.  The main idea behind the use of a  segmented mobile data network remains to isolate critical data; or to  isolate weaker security technologies from the rest of the wireless  network.  Regardless of the reasoning, the goal is the same: keep these  networks separated from everyone else.  The most critical design  decision, therefore, needs to be on the backend &#8211; deciding how exactly  to segment these networks off.</p>
<p>Professional grade wireless  infrastructure like the Cisco 5500 or Motorola RFS7000 is capable of two  completely separated WLANs using the same equipment, which is a  commonly used technique in such a design.  The infrastructure has an  internal firewall that is used to prevent traffic from crossing between  the two networks, and can use VLAN tagging to carry back to the main  network using a shared WAN connection, or can use two entirely separate  WAN connections.  Either way, the infrastructure is functioning as the  separation device.  This also generally needs to be backed up with a  firewall on the wired infrastructure side, restricting the data flows  from the segmented WLAN into the enterprise.</p>
<p>Another alternative  is to use two entirely separate pieces of hardware, with two separate  physical connections back to the enterprise.  Depending on the needs of  your organization, this may be required; if two physically separated  wired LANs are deployed, bridging them with a WLAN device may not align  with the networking vision.</p>
<p>The type of protection necessary for  the the segmented data network again comes down to the technology  available.  For data subject to technical compliance concerns, such as  PCI-DSS or HIPAA, the stronger the better.  At minimum, WPA2-AES with  pre-shared keys can suffice, although a certificate-based authentication  solution is always preferable from a strict data security perspective.</p>
<p>If  the network is being segmented due to equipment that cannot support  strong encryption and authentication technologies, use the strongest  available.  Unfortunately, many types of legacy equipment used in  warehouses today cannot support WPA2-AES, or even WPA-TKIP &#8211; some may be  stuck using WEP!  The weaker the level of protection, the more careful  your segmentation on backend should be.</p>
<p><em>Guest Internet Access</em></p>
<p>Guest  internet access generally is provided by a &#8220;hotspot&#8221;.  Users connect to an  unencrypted network, and are sent to a captive portal page, where they  can either login with pre-assigned credentials, or accept a terms of  service and proceed without any credentials necessary.  Either way,  authentication on such a network is accomplished only at the  application-level, and there is no data protection provided by the WLAN  itself.  As such, these networks should be treated as untrusted and kept  firmly segmented from the enterprise, using the techniques described  above.</p>
<p>A popular alternative deployment method for hotspot guest wireless networks  is to use an entirely separate physical network for guests.  This can dramatically increase the infrastructure costs, but it accomplishes pure segmentation.  A  typical use case for this type of physical segmentation would be a cafe  or retail environment that wants to provide guests internet access, but  doesn&#8217;t want to expose any of their business network.  Purchase a  separate internet backhaul and configure a Wireless LAN dedicated to  this network only.</p>
<p>If your business is subject to compliance regulations, such as PCI, I would strongly recommend using a physically segmented network for guest access.  While this increases capital expenses, it makes scoping activities related to compliance dramatically simpler.  When dealing with auditors, it is always advisable to have clear-cut boundaries around your critical data, and physically isolating any guest network is an easy way to do so.</p>
<p><em>Summary</em></p>
<p>Both of these network types rely on the network administrator segmenting the WLAN from the rest of the network.  It&#8217;s temping to plug an access point into an unmanaged switch and have the wireless &#8220;just work&#8221;, but this can open the network to many avenues of attack.  Assume the worse case at the beginning &#8211; that your WLAN is compromised &#8211; and design its place in the overall enterprise network to minimize the damage that an attacker could do from there.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2010/08/wlan-strategy-segmented-and-guest-networks/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>WLAN Enterprise Mobility Strategy</title>
		<link>http://blog.securism.com/2010/07/wlan-enterprise-mobility-strategy/</link>
		<comments>http://blog.securism.com/2010/07/wlan-enterprise-mobility-strategy/#comments</comments>
		<pubDate>Fri, 23 Jul 2010 18:17:28 +0000</pubDate>
		<dc:creator>Jon Janego</dc:creator>
				<category><![CDATA[Network Design]]></category>
		<category><![CDATA[wifi]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=251</guid>
		<description><![CDATA[Continuing my series on deployment strategies for enterprise WLAN, today I&#8217;m covering the most common type of WLAN deployment &#8211; extending the enterprise to mobile users. Basic Enterprise Mobility &#8211; Strategy Extending the enterprise&#8217;s wired LAN to wireless is one of the more straightforward tasks from a network design perspective, but the authentication piece for [...]]]></description>
			<content:encoded><![CDATA[<p>Continuing my series on deployment strategies for enterprise WLAN, today I&#8217;m covering the most common type of WLAN deployment &#8211; extending the enterprise to mobile users.</p>
<p><em>Basic Enterprise Mobility &#8211; Strategy</em></p>
<p>Extending the  enterprise&#8217;s wired LAN to wireless is one of the more straightforward  tasks from a network design perspective, but the authentication piece  for the Wireless LAN needs to be strictly controlled.  Fortunately,  wireless can benefit from the widespread deployment of another  technology in the enterprise world &#8211; centralized authentication servers.</p>
<p>Many  enterprise environments utilize a centralized authentication system to  manage their user accounts, with Microsoft Active Directory being one of  the most common.  This system can also be leveraged to provide  authentication to the Wireless LAN.  Active Directory can serve as an  802.1X authenticator, allowing the wireless network to use EAP  technology to authenticate users.  The two EAP methods most worthy of  consideration in a WLAN environment are EAP-TLS, and PEAP.</p>
<p>EAP-TLS  provides full mutual authentication, using a public key infrastructure  to create and manage certificates for both client devices and the  authenticating server.  In practice, it will allow users to seamlessly  authenticate to the wireless network, because the certificate exchange  occurs behind the scenes.  In an Active Directory environment, the  certificates used in authentication can be deployed remotely by the  Domain Controllers.  This works especially well with laptop users, but  can be a challenge with mobile devices that do not have a wired  connection to the network.  Certificates can be pushed to mobile devices  in several ways, such as by use of a dedicated management WLAN or  physical installation via memory cards or barcode scanning, but in a  large environment with many mobile devices, it may be wise to look into  alternatives.</p>
<p>Fortunately, a worthy alternative to EAP-TLS exists  with PEAP authentication.  PEAP provides for similar levels of security  to EAP-TLS, but does not rely on client certificates to authenticate  devices to the network.  Instead, PEAP uses a more traditional username  &amp; password combination.  These credentials can be integrated with an  Active Directory environment, allowing administrators granular control  over what users get access to the WLAN.  PEAP also mitigates the  potentially expensive maintenance cost of managing certificates on  mobile devices.</p>
<p>EAP-TLS and PEAP, combined with WPA2-AES, provide  the strongest authentication and encryption solutions available in  WLAN, and as such should be used to protect any critical data traveling  over the network.  While integration with Active Directory is not  mandatory, because many organizations have such an environment already  deployed, extending its use to cover WLAN authentication is an  attractive option.  If your organization does not have a centralized  authentication system in place already, the deployment of a WLAN can be a  strong motivation to do so.  Several free alternatives to Active  Directory also exist, such as FreeRADIUS.  Some enterprise-grade WLAN  infrastructure also provides the ability to generate and manage  certificates using an internal server hosted on the access point.  Given  the easy integration with common authentication systems, and the  availability of free alternatives, there really is no reason not to  deploy a centralized authentication solution to secure your enterprise  WLAN.</p>
<p>Pre-Shared Keys &#8211; also known as &#8220;Personal&#8221; authentication &#8211;  are generally not appropriate for enterprise environments.  WPA2-AES  using pre-shared keys does not have any documented vulnerabilities, but  any PSK solution relies on sharing authentication credentials between  multiple users and devices.  This can affect the integrity of the  network, and doesn&#8217;t provide any traceability to activities of users on  the network.  It should be avoided in a mission-critical environment.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2010/07/wlan-enterprise-mobility-strategy/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>WLAN In the Enterprise &#8211; Use Cases and Strategies</title>
		<link>http://blog.securism.com/2010/07/wlan-in-the-enterprise-use-cases-and-strategies/</link>
		<comments>http://blog.securism.com/2010/07/wlan-in-the-enterprise-use-cases-and-strategies/#comments</comments>
		<pubDate>Wed, 21 Jul 2010 18:41:34 +0000</pubDate>
		<dc:creator>Jon Janego</dc:creator>
				<category><![CDATA[Network Design]]></category>
		<category><![CDATA[Securism]]></category>
		<category><![CDATA[wifi]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=246</guid>
		<description><![CDATA[Continuing from my first post in the series, today I hope to cover the common use cases and general strategies for securing an enterprise WLAN. Depending on the size and business needs of the enterprise, a WLAN can be used in a few different ways: Basic Mobility &#8211; the most common use of WLAN is [...]]]></description>
			<content:encoded><![CDATA[<p>Continuing from my <a href="http://blog.securism.com/2010/07/deploying-a-world-class-wlan-in-your-enterprise/">first post</a> in the series, today I hope to cover the common use cases and general strategies for securing an enterprise WLAN.</p>
<p>Depending on the size  and business needs of the enterprise, a WLAN can be used in a few  different ways:</p>
<p><strong>Basic Mobility</strong> &#8211; the most common use of  WLAN is simply to extend the existing wired LAN to wireless users.  This  can have a very positive impact on productivity, allowing users more  flexibility throughout the workspace.</p>
<p><strong>Segmented Mobile Data -</strong> this type of WLAN is one where the network is  dedicated to use of a specific type of data that is segmented from the  main enterprise network.  Typical use cases here are in hospitals or  retail stores, where compliance regulations provide strict guidance on  data protection and segmentation.</p>
<p><strong>Guest Internet Access</strong> &#8211; common in cafes and  large businesses, this type of WLAN typically provides only internet  access and is entirely segmented from the enterprise wired LAN.</p>
<p><strong>Wired  LAN Replacement </strong>- this type of network is becoming a feasible  alternative to the hassle of running cable, and will likely continue to  grow in popularity as time goes by</p>
<p>These use cases can blend  together in any number of ways.  A well thought-out design at the  beginning, along with the right hardware planning, can accomidate these  uses and even more.</p>
<p><em>General Strategy</em></p>
<p>Like other  networking strategies, the use of proper segmentation at the Layer 2  level is critical when designing a WLAN.  Your most critical data flows  should have their own segment, protected by methods like VLAN  segmentation, firewalling, private IP spaces, and routing tables.   Regardless of the authentication and encryption method used for the WLAN  itself, properly designing its location within the enterprise wired LAN  is critical.</p>
<p>Data encryption in 802.11 is accomplished by a  combination of the authentication type with an underlying encryption  method.  Use of WPA2-AES encryption should be considered mandatory in  any new WLAN deployment.  This encryption technology has no documented  vulnerabilities and widespread hardware and software support.  If your  enterprise has devices that do not support WPA2-AES, strongly consider  replacing them.  When designing a network, its security should not be  determined by the weakest link.  Unless there is a business case for  doing something otherwise, use the strongest encryption and  authentication methods available.</p>
<p>My next post will get into some specifics about these different use cases!</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2010/07/wlan-in-the-enterprise-use-cases-and-strategies/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Deploying A World-Class WLAN in Your Enterprise</title>
		<link>http://blog.securism.com/2010/07/deploying-a-world-class-wlan-in-your-enterprise/</link>
		<comments>http://blog.securism.com/2010/07/deploying-a-world-class-wlan-in-your-enterprise/#comments</comments>
		<pubDate>Fri, 16 Jul 2010 15:23:32 +0000</pubDate>
		<dc:creator>Jon Janego</dc:creator>
				<category><![CDATA[Network Design]]></category>
		<category><![CDATA[Securism]]></category>
		<category><![CDATA[wifi]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=242</guid>
		<description><![CDATA[In the last decade, 802.11 Wireless LAN technology has had a dramatic impact on the technology world.  Reliable, high-bandwidth networking is now easily available to anybody who wants it, and the number of WiFi enabled devices continues to grow at a dramatic rate.  So naturally, businesses ranging from basic office environments, to complicated co-located warehousing/retail/office [...]]]></description>
			<content:encoded><![CDATA[<p><strong></strong>In the  last decade, 802.11 Wireless LAN technology has had a dramatic impact on  the technology world.  Reliable, high-bandwidth networking is now  easily available to anybody who wants it, and the number of WiFi enabled  devices continues to grow at a dramatic rate.  So naturally, businesses  ranging from basic office environments, to complicated co-located  warehousing/retail/office operations have begun leveraging the  technology as well.  Unfortunately, the ease of setup that WLAN offers  has led to some confusion among even seasoned IT practitioners.  In this series of  posts, I hope to provide some simple guidance to help clarify how to  securely and efficiently manage an enterprise Wireless LAN.</p>
<p><em>Some  History</p>
<p></em>I will not go into the history of the 802.11  standard in too much detail here, although there are a couple of  important points to recognize when thinking about how to deploy a WLAN  in your business.  The most important thing to know is this &#8211; many of  the WLAN security technologies that were being used in deployment until  three or four years ago are vulnerable to several well-known attacks.   If your business has a WLAN that has &#8220;just been working&#8221; for a while &#8211;  it should probably get some attention.</p>
<p>To elaborate on this a bit  further, the most common Wireless LAN encryption method used until late  2003, WEP, has been subject to some <a href="http://www.networkworld.com/research/2002/0909wepprimer.html">very public weaknesses,  almost since its inception</a>.  Its temporary replacement, WPA-TKIP, has  similar (although not as dramatic) weaknesses, that have been <a href="http://dl.aircrack-ng.org/breakingwepandwpa.pdf">public  since at least 2008.</a></p>
<p>Adding insult to these platform-common  weaknesses, some of the alternate, &#8220;more secure&#8221; based authentication  methods advised by vendors have also been picked apart and had their  vulnerabilities shown to the world.  I&#8217;m looking at you, <a href="http://www.wirelessdefence.org/Contents/AsleapMain.htm">LEAP</a>.</p>
<p>To  sum it up briefly &#8211; many networks that people thought were secure in  2003 or 2004 are definitely <em>not</em> secure today.  And unfortunately,  WLAN sometimes is treated like a part of the physical infrastructure &#8211;  if it ain&#8217;t broke, don&#8217;t fix it!</p>
<p><em>Current Tech</em></p>
<p>Fortunately,  802.11 is really starting to come into its own lately, and can be an  extremely secure &#8211; in some ways more secure &#8211; piece of critical  infrastructure.  The extremely solid (and so far unbroken) WPA2-AES  encryption standard defined by 802.11i has had widespread vendor support  since 2007.  And certificate-based authentication methods such as  EAP-TLS, PEAP, and EAP-TTLS have similarly experienced a growth in  support, among not just desktop OS platforms, but mobile operating  systems as well.  And Wireless Intrusion Detection Systems are hitting  their stride, ranging from several robust and effective professional  solutions from vendors like AirTight, Cisco, and Motorola, to fantastic  open-source applications like <a href="http://www.kismetwireless.net/">Kismet</a>.  And robust infrastructure  management software is now making the administration of Wireless LANs  more simple and effective.</p>
<p>In short, today it is possible to  deploy a WLAN that will meet all the use cases an enterprise can throw  at it, and that is as secure as a typical wired LAN infrastructure.</p>
<p>In the next post, I&#8217;ll cover typical enterprise WLAN use cases, and the strategies for designing and securing them.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2010/07/deploying-a-world-class-wlan-in-your-enterprise/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Integrated vs. Standalone RADIUS Servers in WLAN Deployments</title>
		<link>http://blog.securism.com/2009/06/integrated-vs-standalone-radius-servers-in-wlan-deployments/</link>
		<comments>http://blog.securism.com/2009/06/integrated-vs-standalone-radius-servers-in-wlan-deployments/#comments</comments>
		<pubDate>Tue, 30 Jun 2009 00:33:17 +0000</pubDate>
		<dc:creator>Walter Goulet</dc:creator>
				<category><![CDATA[Network Design]]></category>
		<category><![CDATA[EAP]]></category>
		<category><![CDATA[RADIUS]]></category>
		<category><![CDATA[wifi]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=201</guid>
		<description><![CDATA[Some WLAN infrastructure vendors have built integrated RADIUS servers into access points, thereby eliminating the need to have a RADIUS server deployed to provide advanced authentication schemes. However, relying on integrated RADIUS servers should be carefully considered against the advantages of standalone RADIUS servers.]]></description>
			<content:encoded><![CDATA[<p>Several popular WLAN infrastructure vendors include lightweight RADIUS servers directly in their access points. These lightweight servers are typically designed for use by vendors as a backup solution in the event that connectivity to an off-board RADIUS server is lost.</p>
<p>I recently had the opportunity to speak with a WLAN network administrator and we briefly discussed the merits of using an integrated RADIUS server on APs vs using an external RADIUS server for authentication. After thinking about it for a few days, I realized that relying solely on the integrated RADIUS server for wireless authentication is rarely a good idea.</p>
<ul>
<li>Integrated RADIUS servers on APs are typically minimal servers that are designed to serve a small number of clients. If the WLAN network grows in size, the number of users that will need to be configured could easily exceed the limits of the integrated RADIUS servers.</li>
<li>Some integrated RADIUS servers do not offer support for accounting services. This can be either a non-issue or a serious disadvantage depending on the purpose of the WLAN.</li>
<li>Integrated RADIUS servers typically use proprietary local database engines/management interfaces to administer the user database, which makes it difficult to do certain operations like import/export user databases between APs or switch to APs from a different vendor.</li>
<li>Standalone RADIUS servers offer advanced capabilities such as integrating with LDAP or Exchange servers to provide single sign-on capabilities. Integrated RADIUS servers in APs don&#8217;t have such capabilities due to the complexities and necessary protocol support required to interact with other authentication servers.</li>
<li>Integrated RADIUS servers can only support the EAP methods that are built into it, restricting the set of EAP methods that can be used in the WLAN. Standalone RADIUS servers can typically support a much larger number of EAP methods and therefore provide the WLAN administrator with a great deal of flexibility. Note that APs which are acting only as a NAS are only relaying EAP messages between clients and the RADIUS server and therefore don&#8217;t need to have support for the different EAP types built-in.</li>
</ul>
<p>However, even with all of the advantages a standalone RADIUS server offers over an integrated RADIUS server, there are some compelling advantages of the integrated solution: the integrated server is likely only to fail when the AP itself physically fails, the authentication sequence may be slightly faster since there is no extra hop between the AP and a RADIUS server, and of course it doesn&#8217;t require any additional capital expense for your network. In short, the decision between a integrated and standalone server solution should carefully consider short term and long term costs/network growth as well as flexibility in supporting both existing and future requirements of the network.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2009/06/integrated-vs-standalone-radius-servers-in-wlan-deployments/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Responsible Home Wi-Fi</title>
		<link>http://blog.securism.com/2009/01/responsible-home-wi-fi-draft/</link>
		<comments>http://blog.securism.com/2009/01/responsible-home-wi-fi-draft/#comments</comments>
		<pubDate>Thu, 29 Jan 2009 00:06:46 +0000</pubDate>
		<dc:creator>Jon Janego</dc:creator>
				<category><![CDATA[Fundamentals]]></category>
		<category><![CDATA[Network Design]]></category>
		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=158</guid>
		<description><![CDATA[Wi-Fi.  Everyone&#8217;s got it nowadays.  Your Comcast or Verizon broadband connection at home probably comes with a wireless router.  But do you really know how to set it up??  Better yet &#8211; do you really know how yours is set up currently?  Or does it &#8220;just work&#8221;? I want to briefly share my thoughts on [...]]]></description>
			<content:encoded><![CDATA[<p>Wi-Fi.  Everyone&#8217;s got it nowadays.  Your Comcast or Verizon broadband connection at home probably comes with a wireless router.  But do you really know how to set it up??  Better yet &#8211; do you really know how yours is set up currently?  Or does it &#8220;just work&#8221;?</p>
<p>I want to briefly share my thoughts on the subject and give you some advice on making a secure &#8211; or perhaps intentionally insecure &#8211; wireless network at home.</p>
<p>Let me explain some fundamentals.  The first thing that you need to keep in mind is that <em>all wireless traffic is visible to everybody</em>.  Your XBOX live session.  Your online banking from your laptop.  Your IM sessions.  It&#8217;s all out there, just waiting to be listened in on, on a very <a href="http://www.ieee802.org/11/">well-defined</a> and <a href="http://en.wikipedia.org/wiki/802.11">well-understood</a> protocol, 802.11.</p>
<p>Before you panic, you need to remember the second important thing &#8211; <em>nearly all wireless traffic</em> <em>can be well-protected</em>.  Walter has been doing a nice series on encryption, and even if you don&#8217;t follow all the details, the major takeaway can be that data can be wrapped up pretty tightly if you set it up correctly.</p>
<p>For most people, I am going to advocate running a closed network &#8211; encrypting your traffic and only allowing authorized users to use your home access point (AP).  This is the subject of some debate among the security community, most notably from <a href="http://www.schneier.com/blog/archives/2008/01/my_open_wireles.html">Bruce Schneier</a> (who advocates for keeping your wireless network open), but I&#8217;ll say that for the &#8220;average user&#8221; it&#8217;s better to close it off.</p>
<p>Your network can be secured through a combination of obscurity, exclusions, and encryption.  Obscurity is not openly advertising the name of the AP.  Exclusions are preventing unauthorized network cards from joining your network.  Encryption is wrapping the traffic in a difficult-to-break code that can only be understood by your wireless devices and your wireless router.  The first two methods are relatively trivial to subvert &#8211; any &#8216;serious&#8217; attacker could get themselves onto your network if they were the only two barriers to entry.  But the third is the most important, and here your choice is pretty clear &#8211; definitely encrypt!</p>
<p>But which encryption and authentication method to choose?  Home APs commonly come with a couple varieties of encryption options &#8211; WEP, WPA-PSK, and WPA2-PSK.  WEP has had known vulnerabilities since almost its inception, and is now easily broken in less than 10 minutes of work.  <strong>So don&#8217;t use it.</strong> Use WPA or WPA2, although WPA2 is relatively new and supported by less devices than WPA.</p>
<p><a href="http://www.portforward.com/">PortForward.com</a> has an <a href="http://www.portforward.com/english/routers/wireless/routerindex.htm">excellent guide</a> to the details of setting up security on many wireless routers.  I would personally recommend against masking the SSID (the &#8220;name&#8221; of the wireless network) and implementing MAC address filtering, just because they&#8217;re easily compromised anyways, and make the network a hassle to administer.  The slight tradeoff in security is worth it for the increased usability.  As long as you&#8217;re using WPA or WPA2 with a relatively long pre-shared key &#8211; at least 15 characters &#8211; you&#8217;re better off than many networks.</p>
<p>Finally, if you choose to run an &#8220;open network&#8221; &#8211; a network that freely allows any client to associate with it, with no encryption &#8211; there are a few ways to still be safe.  First, keep in mind, that while the wireless traffic may be easily &#8216;sniffed&#8217;, if the data itself has already been encrypted via SSL (look for the &#8216;lock&#8217; icon displayed in your browser) or a VPN tunnel, it&#8217;s a moot point &#8211; it&#8217;ll be garbage to an attacker.  So even though I menacingly mentioned that your bank traffic is visible earlier in this post &#8211; it&#8217;s only visible as encrypted gobbledygook, so no reason to panic just yet.</p>
<p>Summary &#8211; use WPA or WPA2.  Don&#8217;t bother with MAC filtering or SSID masking.  Don&#8217;t use WEP unless you really have to.  And you probably don&#8217;t want to run a wide-open network, but if you do so, don&#8217;t panic too much &#8211; most &#8216;important&#8217; traffic is probably encrypted anyways.</p>
<p>In another post I&#8217;ll go into some ideas for running a secure, yet open home wireless network.  But until then, keep my simple recommendations in mind and you&#8217;ll be just fine!</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2009/01/responsible-home-wi-fi-draft/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>The case (for/against) filtering subscriber to subscriber network traffic</title>
		<link>http://blog.securism.com/2008/12/the-case-foragainst-filtering-subscriber-to-subscriber-network-traffic/</link>
		<comments>http://blog.securism.com/2008/12/the-case-foragainst-filtering-subscriber-to-subscriber-network-traffic/#comments</comments>
		<pubDate>Wed, 31 Dec 2008 16:55:10 +0000</pubDate>
		<dc:creator>Walter Goulet</dc:creator>
				<category><![CDATA[Network Design]]></category>
		<category><![CDATA[filtering]]></category>
		<category><![CDATA[p2p]]></category>

		<guid isPermaLink="false">http://blog.securism.com/?p=43</guid>
		<description><![CDATA[Part of my job is to help customers decide when and where it&#8217;s appropriate to deploy firewalls and other security devices in their networks. One point that has come up in discussion with my colleagues has been whether or not it is a good design principle to filter peer to peer traffic in service provider [...]]]></description>
			<content:encoded><![CDATA[<p>Part of my job is to help customers decide when and where it&#8217;s appropriate to deploy firewalls and other security devices in their networks. One point that has come up in discussion with my colleagues has been whether or not it is a good design principle to filter peer to peer traffic in service provider networks. Let me first clarify what I mean by service provider networks. I am referring to networks that are specifically designed to provide connectivity for subscribers, either to the Internet, to private intranets, or to each other. The owner of this network (the service provider) is essentially providing &#8216;pipes&#8217; for his customers. Service providers earn money by creating and meeting service level agreements (SLA) with subscribers that guarantee bandwidth and availability to customers.</p>
<p>I define subscriber to subscriber traffic filtering as a network design which explicitly prohibits the exchange of packets directly between subscribers without first passing those packets through a firewall or access control lists. An example of this type of network is a typical cable or DSL service network provider where subscriber packets are filtered through a network access server (NAS) prior to being forwarded to their destinations. A metro Ethernet network is an example of a network that does NOT perform peer to peer traffic filtering (metro Ethernet provides layer 2 connectivity between subscribers).</p>
<p>From a pure service provider business perspective, you care little about the types of traffic that subscribers exchange as long as you are able to meet the SLAs that you have established. If the traffic that is exchanged happens to contain malicious information (viruses, malware etc.), the service provider isn&#8217;t really going to care as the type of traffic exchanged doesn&#8217;t affect their ability to provide service to subscribers.</p>
<p>From a subscriber perspective, you care a lot about whether or not your home/business network is subjected to malicious traffic originating from your outside network connection. However, you also care about having the freedom to use your outside network connection as a raw pipe and being able to exchange any kind of network traffic with anybody that you can connect to (especially home users who use BitTorrent and other P2P protocols).</p>
<p>From a regulatory perspective, as a service provider you care about meeting the legal requirements to provide service in the regions you operate in order to avoid penalties etc. Certain governments impose restrictions on the types of traffic that network users are allowed to exchange (China being a prime example with strict requirements on which websites can be viewed by Chinese residents).</p>
<p>As can be seen from these 3 different perspectives, the need to implement filtering controls to restrict subscriber to subscriber traffic is not immediately evident. From a security threat perspective, most service provider networks are designed to provide clean seperation of bearer data (subscriber traffic) and control/management data used by the provider to run their network. So the risk of subscribers actually accessing the service provider&#8217;s infrastructure is quite low. A slightly more obvious security threat is the risk of being non-compliant to regulatory requirements. In this case, the risk of non-compliance can be quite high depending on each country&#8217;s regulations.</p>
<p>In conclusion, when considering whether or not to implement peer to peer traffic filtering and whether or not the lack of this filtering is a security risk, consider the network design and the regulatory requirements governing the network operation. You may be surprised to find that there is in fact little to no security risks to the service provider by NOT performing peer to peer traffic filtering.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.securism.com/2008/12/the-case-foragainst-filtering-subscriber-to-subscriber-network-traffic/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
