We received several submissions today on the topic of "Wireless Thoughts" from yesterday's Diary written by Marc Sachs. Here is Part II for Wireless Thoughts contributed by our readers and compiled by Marc.
Wireless Thoughts - Part II.

We received several emails today from
readers with additional suggestions and ideas for personal VPNs when
traveling. Here are some excerpts from the mailbag.

Holger suggests that, "WPA encryption will cover traffic only locally on the
link between your mobile device and the WiFi-hotspot. From the hotspot on
the data will travel unencrypted and hence unprotected - most likely through
the hotels local network infrastructure and an ISP's public backbone also.
So in my opinion, cryptographic protection, which is '"good enough" for most
of us", has to cover the communication on an end-to-end basis and WPA on
public hotspots may not be good enough most of the time..." In a follow-up
note he offered, "...while using public access even WEP/WPA is just not
"good enough" and additional means of (cryptographic) protection
(VPN/SSL/SSH or whatever) is required anyway."

In reference to SSH port forwarding, a reader wishing to remain anonymous
says, "...in newer version of OpenSSH there's a much nicer way. The -D
option on the client sets up a local SOCKS server which proxies data across
the SSH tunnel so you don't need to worry about configuring every protocol
you use as long as your application is SOCKS aware (as many are, and if they
aren't you can use API hooking to make them -- see FreeCap @
http://www.freecap.ru/eng/?p=index ; I also recommend the SwitchProxy
plugin for firefox). Dan Kaminsky added this feature and refers to it as
"poor man's VPN". Another option for the ultra-paranoid users would to use
something like Tor, a mix-based anonymizer ( http://tor.eff.org ), which
would set up a local SOCKS proxy, encrypt and do a decent job of anonymizing
your location as well for privacy in web browsing)."

Tina pointed us to a link from Intel that addresses this issue:
http://www.intel.com/personal/do_more/wireless/security/secure.htm

Brent reminds us that, "...some VPN implementations have a distinction
between "split-tunnelling" connections and non-split-tunneling.
Split-tunneling (at least with Cisco and the old VPNet VPN gear) means that
the ONLY traffic that gets encapsulated and encrypted is traffic both to and
from protected networks (the remote machine being considered "protected").
So... With a split-tunneling VPN solution, my machine could, potentially,
be attacked by another person with a wireless card while I was using a
public hotspot. Also, if I signed on to a service (like an IM client, for
instance) where the username and password were sent in the clear, someone
nearby with a wireless card could sniff the traffic and obtain my password
since that traffic would NOT be going across the VPN. This is why I always
set up users with wifi cards with two profiles in their Cisco VPN client.
One for use when they're on their broadband connection at home, and one
(with split-tunneling disabled) for when they're using a hotspot. When they
use the non-split-tunneling VPN profile, as soon as they've authenticated
with the VPN, ALL of their IP traffic gets sent over the encrypted VPN
tunnel back to the home office including internet access. This not only
gives them another layer of security (wifi packets sent to their machine
that are not encapsulated get dropped), but it means that their internet
access can't be sniffed by someone else in the local area with a wifi card."

Finally, Darrin told us that, "I follow a similar approach by tunneling my
traffic to a linux box running on my home broadband account. Using a dynamic
DNS provider (e.g. dynDNS), I can route traffic to my broadband connection
and not have to use an external hosting service."

Thanks, everybody!
Netgear Vulnerabilities

Two vulnerabilities have been found in Netgear's FVS318 firewall/router. The first one allows for hex encoded characters to bypass the URL filters. The second one is a vulnerability with the content filter/log viewer. A URL that is blocked and has JavaScript embedded in it will be logged. When that log is viewed, the JavaScript will be executed. For more information see:
http://www.securinews.com/vuln.htm?vulnid=103

Phishing Creativity

I spent part of today looking at four phishing attempts. All of them were different from each other and three of them were more creative than some I have looked at in the past. It seems that the folks doing these attempts are taking more actions to cover their tracks and to avoid detection. One of them even had several "presents" for their victim. As the creativity grows, detection and tracking becomes more difficult as they are involving more servers, code obfuscation, use of I-Frames, redirects, on-line form publishers etc. Tracking these down to find all the entities involved can take time and can be difficult. It will be interesting to see what the future holds in the realm of phishing. Anyone care to make any predictions?


Lorna Hutcheson

Handler on Duty

http://www.iss-md.com