Archive for Remote Access
Author: Dave Lewis
January 21, 2008 at 7:45 pm · Filed under Apple, Remote Access
OK, this is cool. I was just messing around with my iPod Touch which I upgraded with the January release software. Thanks to a co-worker (thx Sab) I noticed that there is a VPN client on the Touch now. With the addition of email client (yes Gmail worked fine before) Google maps and a few other niceties this is quickly evolving into a light weight tablet computer for me. OK, from the initial screen, assuming that you haven’t made too many changes already after upgrading your iPod Touch. From the home page select your “settings” button (down on the right hand side).
More after the jump »
Author: Dave Lewis
January 12, 2008 at 6:18 pm · Filed under Remote Access
There are a lot and I mean a lot of folks out there that are a little more than perturbed with Check Point and their perceived heel dragging. Leopard has been out now for a couple months and still no news on the Secure Client VPN software for the latest iteration of Mac OS X. Earlier Check Point attempted to point to Apple as the reason for the delay citing a shifted release date. That answer didn’t hold water with, well, anyone. Now the grumbling is rising to something more than a din.
So, what is one to do? No, not roll over to Vista. There is an alternative that a reader, Tim, was good enough to point me to. IPSecuritas is a free, yes free, VPN client that is Leopard ready.
From Lobotomo Software:
IPSecuritas is the most advanced, yet free IPSec client for Mac OS X. It supports virtually every available IPSec compliant firewall, allowing you to connect safely to your office or home network from any location on earth.
Give a whirl. Did I mention that it was free?
Article Link
Tags: Leopard VPN, Mac OS X VPN, SecureClient, SecureClient Leopard
Author: Dave Lewis
January 9, 2008 at 1:19 pm · Filed under Remote Access
OK so, here we are months later and still no SecureClient for MAC running Leopard. WTF? On December 30th a Check Point staffer, Yoni, stated that it would be available on January 7th.
All, the public Early Availability of SecureClient for MAC, with support for MACOS 10.5 (Leopard) is delayed a bit and will begin on January 7th.
We’re still shooting for a General Availability in late January/ early February
Rgrds
Yoni
==========================
Yoni (Jonathan) Lebowitsch
Product Manager - Access Products
Check Point Software Technologies
==========================
Well, it’s now January 9th and no sign of the early access.
Come out, come out wherever you are.
Article Link
Tags: Check Point, SecureClient Leopard, SecureClient OS X 10.5
Author: Dave Lewis
December 18, 2007 at 5:06 am · Filed under Privacy, Remote Access
As if Vista had not managed to garner enough bad press on its own. Bruce Schneier reported yesterday that Microsoft has reintroduced its dual random number generator. This time in Vista SP1. That is the same as one he had written about previously. The catch is that, according to Schneier, this potentially provides an NSA back door. This is disabled by default. However, that is no guarantee that it won’t switched to the “on” position in a later patch release.
Article Link
Tags: DRNG, Backdoors, Bruce Schneier, Microsoft Security
Author: Dave Lewis
November 19, 2007 at 11:42 am · Filed under Apple, Remote Access
OK, the silence on the SecureClient for Leopard thawed out a little on Friday. A representative from Check Point managed to respond to all of the users clamouring for a VPN client that works.
From the forum message board by Robert Hughes:
Re: VPN-1 SecureClient and OS X Leopard
Posted: Nov 16, 2007 10:51 PM in response to: chwh…
All,
The most recent information I have is that the EA is scheduled to start around the end of this month. You can sign up for EA participation at http://www.checkpoint.com/eap/ once the program starts. You can also use the link to email the EA team for possible inclusion. I don’t know how many participants will be chosen, so just signing up is not a guarantee of inclusion.
Regards,
Rob
The crux of the email is that the testing phase for the Leopard SecureClient begins “around” the end of November. Nothing like staying on the cutting edge.
So, we wait…yup, still waiting…
Article Link
Tags: Check Point SecureClient Leopard, Leopard SecureClient, Check Point VPN Leopard
Author: Dave Lewis
November 6, 2007 at 10:12 am · Filed under Apple, Remote Access
From the Check Point forums we see this message posted this past weekend. Apparently, this was an email response from Check Point Account Services to a customer.
Thank you for contacting Check Point Account Services.
We currently have no plans to support Leopard. I do suggest that if you want these updates, then you will need to submit a Request for Enhancement. As the demand grows for the product, we will address it quicker.
Please contact us if you are in need of further assistance.
Thank You,
Jeff Limon
Check Point Account Services
Well, that’s a boneheaded reply if I have ever seen one. A couple hours later a Check Point employee posted this correction:
I just saw this post and it has to be corrected.
We actually had a Leopard build back in May 2007 when Apple was supposed to ship Leopard. It was working enough to start the EA/beta. Then to our surprise Apple delayed and we were 5 months too early with our EA.
In the recent Leopard beta takes we had some issues show up so we have not EA’ed yet. We are close to EA and we will post an expected date shortly.
Oh OK. I get it. It’s Apple’s fault because they delayed the release of the OS? Anyway, as soon as the release date is posted or sent in by our CP folks on the inside I’ll be sure to post it.
Article Link
Tags: Check Point SecureClient, SecureClient Mac OS X, Check Point VPN For Mac, SecureClient Leopard
Author: Dave Lewis
October 30, 2007 at 7:38 am · Filed under Remote Access
Mac OS X Leopard is a great new distro. But, if you expect to use Check Point VPN to connect to your office you’re pretty much screwed…for now. It appears that Check Point missed the boat ahead of the launch of what, by all accounts, is probably the slickest Mac OS offering ever. I reserve judgment as I have yet to upgrade.
That will be this weekend.
Now, from the Checkpoint support forums we see more of this problem as it develops.
Re: VPN-1 SecureClient and OS X Leopard
Posted: Oct 27, 2007 6:30 PM
I just upgraded to Leopard and the VPN client doesn’t work. I hope there is a fix for this soon. Here is my error log:
Oct 27 10:27:07 macbookpro com.apple.launchd[98] ([0x0-0x26026].SecureClient[301]): posix_spawnp(”/opt/CPsrsc-50/bin/SecureClient.app/Contents/MacOS/SecureClient”, …): Bad executable (or shared library)
Oct 27 10:27:07 macbookpro com.apple.launchd[98] ([0x0-0x26026].SecureClient[301]): Exited with exit code: 1
The response that was offered by a CP employee was this,
Re: VPN-1 SecureClient and OS X Leopard
Posted: Oct 27, 2007 9:12 PM
The current SecureClient build for OSX 10.4 does not support OSX 10.5.
More information regarding SecureClient EA and GA for OSX 10.5 will come soon.
OK so, we wait.
Article Link
Tags: Check Point VPN, Leopard VPN, Check Point VPN Mac OS X, Secure Client Leopard, Secureclient Leopard
Author: Dave Lewis
October 9, 2007 at 7:43 am · Filed under Mobile, Remote Access
With the modern workforce on the move a lot and things like the cost of fuel on the rise it only makes sense to think of remote access. These solutions help to lower the operating costs for a business and offer greater flexibility to the employee. That is, as long as they are rolled out in a sound fashion. SSL VPNs are one example of a remote access solution that offers people great flexibility. On my personal network I use SSL Explorer as it is a free solution to the home user. It is an extremely feature rich offering. In fact that can also be seen as one of its detractors. For enterprise customers they offer a licensed solution. As well, there is a veritable cornucopia of SSL VPN solutions available. A case in point. I was able to check my email from the coffee shop this morning from my iPod Touch using an SSL VPN.
This morning I found this piece on ARNnet:
Although the benefits of remote access are extensive, the trend challenges organizations to maintain an all-inclusive view of who is entering the corporate network and to create a well-controlled but user-friendly environment to access sensitive information. Security is a prime reason that many organizations resist enabling remote access, or confine it to a select group of users.
Opening the infrastructure for remote connection always involves risk. Without proper safeguards, organizations are susceptible to data and identity theft, network abuse, viruses, worms and other security threats.
To reduce the risk many organizations turn to virtual private networks (VPN), which lets users access the company network via the Internet. Before implementing a VPN solution, it is important to consider not only security issues that can occur when users connect remotely, but to evaluate how much and which information your organization is willing to share over a remote connection.
There is a wide field for you to pick from. Your choice should be based on your security requirements and not what the salesman tells you that you need. This might seem self evident but, time and again I hear stories from folks that bought the wrong solution because the salesperson told them it would do everything that they needed. Even make them coffee in the morning.
If that were true…I’d buy two.
Article Link
Tags: SSL VPN, Remote Access, Mobile, Mobility
Author: Dave Lewis
July 25, 2007 at 11:17 am · Filed under Remote Access, Security Mgmt
As gas prices rise (and how) and the simple fact that technology exists to support working from home it starts to dawn on govies that they too can work from home.
From GCN:
In the summer of 2004, the General Services Administration’s regional center in Boston was closed for nearly a week. GSA officials couldn’t blame the shutdown on anthrax, bird flu or terrorists.
They had no one to blame but Sen. John Kerry (D-Mass.).
The Democratic National Convention was held in the building next door, and the Secret Service had declared the convention a national security event. Every federal employee who worked at the center was required to work somewhere else that week.
Fortunately, the GSA center had been developing a telework plan since 1999. The Desktop 2000 plan is centered on a virtual connection from Citrix Systems. With Citrix MetaFrame installed in the office’s data center, GSA employees can launch applications via the Web. Every user — at every level — is issued a laptop PC.
Now, why can’t more businesses see the light? One of the things that I continue to run into is management types that are hard set on the 80’s mentality of wanting to see “butts in seats”. This is a notion that for all intents and purposes is a relic of days past. Sure there are times when people have to meet in person, no argument there. But, there is a lot of times that you just don’t have to be physically in the office.
Let’s take into account the morning commute. For me, I drive 45 minutes to work in the morning (on a good day). Thankfully, I have a boss who is enlightened and allows me to work remotely on occasion. But, that 1.5 hours per day could be better used. I know of folks like that have double that as a part of their daily commute.
But there is a wrinkle (isn’t there always?). With more and more teleworkers moving into the home office and companies realizing the financial benefits I wonder. Are they taking the time to secure these teleworkers appropriately? There is a worry that companies will take a lackadaisical approach to teleworkers thinking that since they VPN in that they are beyond the perimeter and therefore not a corporate concern. Not so. This is an extension of the perimeter and should be treated as such. Sure they can be labeled untrusted but, if they are dedicated resources then by definition they are part of the enterprise.
Telework can cut rush-hour traffic congestion in major cities. It can improve workers’ morale. It can help the environment. But perhaps one of the best arguments for telework is that — as GSA found — it is essential for continuity-of-operations planning.
“Back then, we were just talking about working off-site,” LeVerso said of Desktop 2000. “The heart and soul of the solution revolved around the concept of teleworking and had no real bearing on our fledgling COOP program at that time.”
Yet the ability to work remotely became the cornerstone of the center’s disaster response plan. “We learned very early on that COOP is telework,” LeVerso said.
More “old school” management types can learn from this.
Article Link
Tags: Teleworkers, Remote Access, VPN, Remote Worker, Virtual Office
Author: Dave Lewis
June 4, 2007 at 9:28 pm · Filed under Remote Access, Security Mgmt
There is a new document available from NIST on securing remote devices for teleworkers and remote access.
The draft NIST Special Publication (SP) 800-46 version 2, User’s Guide to Securing External Devices for Telework and Remote Access, is available for public comment. The publication is intended to help teleworkers secure the external devices they use for telework, such as personally owned desktop and laptop computers and consumer devices (e.g., cell phones, PDAs). SP 800-46 version 2 focuses on security for telework involving remote access to an organization’s nonpublic computing resources. It provides practical, real-world guidance on securing telework computers’ operating systems and applications and teleworkers’ home networks, and it also gives basic recommendations for securing consumer devices. The publication also provides tips on assessing the security of a device owned by a third party before deciding whether it should be used for telework. This publication replaces the original version of SP 800-46, which was released in 2002.
Download: NIST 800-46
Tags: NIST, Remote Access, 800-46
Next entries »
Explore
Security Bloggers Network
