Juniper SA SSL VPN – Migration to JUNOS Pulse

With version 7 (see previous post) of code having been released for Juniper SA, I have been busy testing all the new features in our lab and in some cases, deploying them for clients. One of the most interesting features has been Junos Pulse, which Juniper’s marketing team describe below.

"Junos Pulse is an integrated multi service network client that supports integrated connectivity, location-aware network access, acceleration, and security. Junos Pulse simplifies the user experience by letting the network administrator configure, deploy, and control the Junos Pulse client software and the Junos Pulse connection configurations that reside on the endpoint."

Junos Pulse is a replacement for Network Connect; it adds new functionality and interoperability with other Juniper Networks appliances (IC Series UAC Gateway Release 4.0, Secure Access Series Gateway Release 7.0, WXC Series JWOS Release 6.1, SRX Series Release 10.0). The following key features have been added in Junos Pulse:

• Credential saving – Ability to save credentials on the client machine.
• Host checker consolidated to Pulse client rather than a separate installer.
• WAN acceleration.
• Certificate trust and storage.
• Dynamic connections – Allows connections through newly discovered supported gateways through the web browser.
• Wireless suppression – Disables a wireless adaptor (if feature enabled) when a wired connection is available.
• Scan list – Allows a white list of SSIDs for wireless networks to be added.
  
• Location awareness – Allows conditional connection depending on where the endpoint is located.



• Enhanced Endpoint Security – Extra licence for endpoint security on the box, now present on the client.

Migration

Knowing the Juniper SA pretty well, in the first instance I decided to have a ‘tinker’ and see if I could work out how Pulse worked and how it could be activated for a small sub-set of users in the lab environment. This proved difficult, partially due to the labyrinthine depth of some of the menus and partially because of non-standard logic derived from hundreds of configurations I have done on the SA. After an hour or so of tenacious (mis)configuration, I decided to look for the admin guide on the Juniper website, which is well written and simple. It’s definitely worth reading it in its entirety (or at least pages 31-47 which are relevant to the SA) and the migration guide, located on the same web page. The admin guide contains a step-by-step for configuration on the SA (and for all the other appliances) and the migration guide provides information about which features are new and which are missing. A key point to note is that Network Connect and Pulse cannot function for the same role, even though they share the same split tunnelling policy and the documentation is very misleading on this point! What this will mean, is that once you have deployed Junos Pulse and users have installed it, they will no longer be able to connect to the same SA (or cluster) using Network Connect. Whilst discussing the solution, it’s worth mentioning the principle reason for this being an issue. Junos Pulse will ONLY work with Windows at present (Windows Mobile Included!) and this is an issue with the proliferation of Macs and desktop Linux distributions such Ubuntu and Fedora Core (especially in IT Security where pen’ testing rigs are almost always Linux based using Back|Track or a custom build). This means that it is no longer possible or logical to group all users of Network Connect together in one role as it previously was.

Advice on Testing

During a ‘live’ testing period with end users it’s advisable to provision both access methods in case there are any issues and to give an environment where you can easily test the same action with the other application. The optimal method (IMHO) is to create an additional role for Junos Pulse. I would advise copying an existing role that includes Network Connect as this will contain all the IP address pools and settings that will duplicate the user experience. I would recommend that you name these logically as “<role> Junos Pulse” and “<role> Network Connect” as this will help greatly with troubleshooting.

In order to correctly assign the roles to users I recommend either a regular expression to recognise the useragent (e.g. userAgent = '*Safari*' OR userAgent = '*Linux*') in the realm level role mapping or to update your OUs in Active directory (i.e. split the users into Mac / Linux / Windows). From experience, I’d advise the ‘regular expression’ method at the realm level role mapping and moving it to the top of the processing order and adding a stop rule. The next group, which should be your Windows users that have not hit the first rule, should then be mapped to both the Network Connect role and the new Junos role and the option “User must select from among assigned roles” selected. This will give the users the option of selecting the role they require upon login to the portal. Once this is set up, you will need to add the roles to the Network Connect resource policy. It doesn’t explain or tell you how to do this in the step-by-step guide, which means it can often be a gotcha! Simply add the role to the Access, NC Connection Profiles and Split Tunnelling settings (Users > Resource Policies > Network Connect).

Built-in Windows Security features ignored by most AV vendors and common desktop applications but is this important?

A widely discussed topic in a many security blogs of late has been that of DEP and ASLR being neglected in many common desktop applications and more notably, desktop Antivirus software. Most of the posts, even if not directly accredited, were spawned by an interesting research paper authored by Secunia.

Background

DEP (Data Execution Prevention) is a Windows security feature that was introduced in Windows XP SP2 and has persisted in both Vista and Windows 7 (despite changes in how it is invoked by the OS). DEP is designed to prevent execution of services and applications from non-executable regions of memory, blocking exploits that store code via buffer overflow. This feature has to be enabled explicitly within the application in order to provide protection. DEP will not guard against more complex coding techniques such as ‘return-into-libc’ attacks that change the return address of a stack to a different location in memory containing an alternative instruction. In order to overcome this ASLR (Address space layout randomization) was introduced with the release of Windows Vista. ASLR randomises the location of key data areas in memory (such as libraries, heap and stack) in order to make it difficult for attackers to guess their location. These two features in combination can mitigate attacks targeting memory space if they are enabled within the respective applications. Additionally, there are several things worth noting with ASLR. Firstly, ASLR is not proprietary to Microsoft or a new concept and its security is greatly improved by increasing entropy by means of a larger address space.

Issues

It appears that many applications, including Antivirus software, do not take full advantage of what is a proven and easy to implement technology (although they are by no means impossible to crack) present in most Windows implementations. Some interesting responses from AV vendors, posted by Brian Krebs on his security blog, give some insight into the state of AV programming.

“Mikko Hypponen from F-Secure said that “adding support for DEP and ASLR in our products is on our roadmap, but has not been implemented yet. This is because we’ve focused our development efforts lately to focus on performance. Once we have this feature ready, it will be available to all of our customers through our update channel.””

“Pedro Bustamante, a senior research adviser at Panda Security, said Panda decided not to use either ASLR or DEP in favour of their own technology “to provide protection not only for the single AV processes but also for other types of operations. For example our products include a Shield component which already takes care of the protection as offered by ASLR and DEP, in addition to other types of self-protections such as preventing a process from injecting a thread into a separate process, preventing certain applications from executing dangerous operations on the system (such as Adobe Acrobat dropping an executable in the system and running it), protection of the AV files in the installation directories, etc.””

Given the conflicting stances on these two technologies from antivirus vendors, it’s difficult to decide which approach is better or if either is (?). However, I do feel that deciding not to use built-in features of an operating system, to be adding complexity in an area where performance is quite obviously an issue. That said, it may be quicker to take a different approach to doing the same thing in a different way, but why then is one technology better than another? With this confusion in mind, it does bring one back the quantitative metric of detection rates and if we care about the ‘how’ if the results are good? It would be interesting to look at detection rates vs. implementation of DEP and ASLR, but that’s slightly beyond the scope of this blog! However, I digress, the main issue is that DEP and ASLR are built in protections which are not being utilised by many popular applications and some will even admit to being remiss (even if it’s accompanied by marketing spin) in their exclusion.
Although the primary focus of this post, it’s not only Antivirus software that suffers from a lack of these functionalities. The most alarming, in my opinion, being Java (Sun java JRE)! To quote Secunia’s paper “Java resources are loaded and processed in the java.exe process and not in the context of the browser opening a web page that embeds a Java applet. DEP was found to be disabled in the java.exe executable included in the latest version of the software (6 Update 20). Furthermore, default libraries are loaded at fixed addresses.”