Mashed Articles

Writen by Greg Lietz

Running a business from home has its advantages, including no commute, a more accommodating work schedule, fresh coffee and home-cooked meals at any time you want.

But running a business from home using a home wireless local area network (WLAN) with your computer may lead to thievery of confidential information and hacker or virus penetration unless proper actions are taken. As WLANs send information back and forth over radio waves, someone with the right type of receiver in your immediate area could be picking up the transmission, thus acquiring access to your computer.

Here is a list of things that you should consider as a result of implementing a home wireless network setup used your business:

Viruses could be loaded onto your laptop which could be transferred to the company’s network when you go back to work.

Up to 75 per cent of home wireless network WLAN users do not have standard security features installed, and 20 per cent are left completely open as default configurations and are not secured, but are made for the users to have their network up and running ASAP.

It is recommended that home wireless network router/access point system setups be always done though a wired client.

Always change the default administrative password on your home wireless network router/access points to a secured password.

Enable at least 128-bit WEP encryption on both card and access point. Change your WEP keys periodically. If equipment does not support at least 128-bit WEP encryption, consider replacing it. Although there are security issues with WEP, it represents minimum level of security, and it should be enabled.

Change the default SSID on your router/access point to a hard to guess name. Setup your computer device to connect to this SSID by default.

Setup router/access points so as to not broadcast the SSID. The same SSID needs to be setup on the client side manually. This feature may not be available on all equipment.

Setup your home wireless network router to block anonymous internet requests or pings.

On each computer having a wireless network card, network connection properties should be configured to allow connection to Access Point Networks Only. Computer to computer (peer to peer) connections should not be allowed.

Enable MAC filtering. Deny connection to wireless network for unspecified MAC addresses. MAC or physical addresses are accessible through your computer device wireless network connection setup and they are physically written on network cards. When adding new wireless cards / computer to the network, their MAC addresses should be registered with the router /access point.

Your home wireless network router should have firewall features enabled and demilitarized zone (DMZ) feature disabled. Periodically test your hardware and personal firewalls using Shields Up test available at http://www.grc.com. All computers should have a properly configured personal firewall in addition to a hardware firewall.

Update router/access point firmware when new versions become available.

Locate router/access points away from strangers so they cannot reset the router/access point to default settings. Also, locate router/access points in the middle of the building rather than near windows to limit signal coverage outside the building.

You should know that nothing is 100%. While none of the actions suggested above will provide full 100% protection, countermeasures do exist that will help. The good collection of suggested preventative actions contained herein can help you deter an intruder trying to access your home wireless network. This deterrant then makes other insecure networks easier targets for the intruder to persue.

Greg Lietz is an internet business man, freelance writer and computer enthusiast. His websites provide information on wireless internet networking and personal computer hardware that may be of interest to you.

While enjoying holidays, I read the book “Programming Amazon Web Services” by James Murty. As explained in my earlier post, I was most interested to learn how cloud computing could be leveraged for developing integration solutions.

The book discusses 5 Amazon Web Services (AWS):

• Simple Storage Service (S3)
• Elastic Cloud Computing (EC2), virtual Linux servers on demand
• Simple Queue Service (SQS), to deliver short messages
• Flexible Payment Service
• SimpleDB – simple database with no SQL support

The book goes into quite some technical detail and has code snippets showing in detail how to interact with the Amazon services. All the samples are written in Ruby. I don’t know Ruby, but the code is quite readable (should read Enterprise Integration with Ruby some day). The author prefers the REST and the Query API. Unfortunately, he does not show anywhere the use of the SOAP API to access Amazon WS.

The 1st chapter is introductory and e.g. explains how to use self-signed certificates to connect with AWS, explains how AWS were developed for internal use by Amazon and later turned into a products, come without an SLA (except for S3) and without real support.

In the 2nd chapter, the author builds up a library of Ruby code to access the Amazon Web Services. This is very well written and gives an immediate feeling for some aspects to take into account, e.g. clock differences.

S3 is covered in chapters 3 and 4. No standard file access but the use of buckets and objects through a non-standard API (REST or SOAP); no FTP, WebDAV or SFTP. And objects cannot be modified: only deleted and re-created (after the deletion has propagated). Ruby code is shown for all the options the API offers: bucket creation/lookup/deletion, object creation/listing/deletion, ACL update/retrieval and access logging file retrieval. Tricks with HTTP header fields (object metadata), posting data through forms, alternative hostnames and BitTorrent are discussed. The last part discusses signed URI’s: this is a neat trick to make S3 resources temporarily accessible to users without Amazon account.

Chapter 4 shows some applications of the S3 service: large file transfer, backup, turning S3 into a file system (with FTP or WebDAV). Interesting to note that the author has his doubts wrt. exposing S3 as a file system. The author also discusses his own Java open source application: JetS3t. This application is a “gatekeeper” for S3 resources and authorizes local agent applications after acquiring signed URL to upload files to S3 and download files from S3.

Chapter 5, 6 and 7 dive into EC2 and how virtual Linux systems (based on Xen) can be configured using Amazon Machine Images. Ruby code is shown for every available API: keypairs (for SSH access), network security (dynamically configure the firewall), images and instances. Chapter 6 explains instances in more detail and discusses how to create new images. This involves quite some commands and scripts at the Linux command prompt. Chapter 7 discusses some sample applications: VPN server, web photo album thereby backing up data on S3. Chapter 7 also discusses issues around dynamically assigned IP addresses and the use of dynamic DNS.

The Simple Queue Service (SQS) is discussed in chapters 8 and 9. Because of the small message size, SQS is clearly meant for events with actual data stored on S3 (or elsewhere). Again Ruby code to manipulate queues and messages. Chapter 9 describes a Messaging Simulator application, not that relevant in my opinion. The 2nd application – leveraging a video conversion tool – shows how to build generic service for implementing “batch” services (Command Message pattern). The 3rd application – LifeGuard – leverages SQS to manage EC2 instance pools and dynamically scale the number of EC2 instances.

The chapter on payment service I skipped and I only skimmed through the SimpleDB chapter. Enough to learn that SimpleDB is not an RDBMS but a basic storage mechanism (no data types) with proprietary query facilities (no SQL).

The author writes fluently and gives a non-biased view on the Amazon Web Services. Sometimes the code goes into too much detail, showing how to invoke every available method of the API. Although the book is very recent (March 2008), important new features such as elastic IP addresses, persistent storage for EC2 and availability zones weren’t yet available at the time of writing. The book definitely taught me that AWS is quite proprietary and not that trivial. And to use Amazon’s cloud computing and AWS, you’d better “think like Amazon”.