More specifically, the variables described in this article are used when configuring a startup command in a Tunnel Set definition to allow TCP/UDP based applications to be used inside a SSL tunnel.
A sample use case is a user that needs to access to his home directory and we do not want to create as many tunnel set as users in the system.
The Startup Command in a Tunnel Set is executed as soon as the tunnel has been successfully established, to automate the launch of a given application.
In this example, the Startup Command content in SSL VPN Tunnel Set configuration could contain something like:

\\192.168.100.1\[$uid]

This particular $uid variable will be replaced with the user ID when the startup command will be invoked by the system.

I report below the other useful variables that can be used in the same context:

[$ehost]  =   the access point server name including port number

[$eprot]  =   HTTP or HTTPS

[$uid]  =   The external user name

[$iuid]  =   The internal user name (usually the same of $uid)

As many YouTube videos demonstrate, you never know when someone may be watching. A good thing to keep in mind at Black Hat as well, particularly when you are using a laptop or other mobile device. Be mindful of the fact that hackers may be watching your screen and your fingers as you type. From this they can capture information off your screen and capture your logins and passwords for use later on. Often this hack is accomplished by using a video camera on a cell phone or by pretending to take a picture of a nearby attraction. So keep your fingers covered as much as possible, and be prepared to change your passwords often. If you can avoid using your laptop or smartphone in open areas, do so and reserve the work for after you return to your hotel room or other private location.

Black Hat has also been famous in the use of social engineering and ATM hacks. There’s a presentation on ATMs at this year’s conference. Be sure to avoid any stand-alone or third party ATMs within the casinos, or any ATM that is not at a bank branch office. These stand alone ATMs can be cheap copies, or purchased off eBay or other sites, and reconfigured to capture your account data, while providing no money.

Just one more quick review: turn off wireless and Bluetooth on all devices whenever possible. Avoid wireless if at all possible, and use a 3G cellular modem instead. Be careful typing in passwords, and also what you work on while in open areas. Don’t trust ATMs or storage devices of any kind. Keep your mobile devices up to date with the latest software updates and patches, and use encryption and firewalls whenever and wherever possible.

Remember to enjoy the conference and have a great time knowing you won’t be joining others on the Wall of Sheep!

The X-Files principle of Trust No One holds true in this case as well. We all love schwag, whether it’s simple things like stress balls, to more advanced things like iPad giveaways. In between everyone loves to pick up those USB sticks, which can be plain and simple or disguised as cute animals. But be careful, those animals can turn on you. In general, for a safer computing experience at Black Hat, do not trust any storage device handed to you by others. Whether it’s a USB drive or CD, or anything else (even that iPod you just won), they can contain viruses, Trojans or malware of any form. Even the ones that look professional can be dangerous. At best it’s good to discard them; if not at least scan them on a separate, up-to-date, sacrificial system first.

Second, if you are bringing a laptop, install and verify the operation of full-disk encryption software. Use AES-256 bit encryption or better. If the hard drive has a hardware encryption option as some external ones do, use that instead. And while you’re at the conference, be sure to power off or hibernate your laptop whenever it isn’t in use to maximize the effect of the encryption software. Free disk encryption programs exist, and modern Windows and OS X systems include encryption technologies built-in.

To learn more about computing safely, to try your hand at Hack The Lab, and to learn about Stonesoft’s award-winning network security solutions, be sure to stop by Booth 33!

Our first security tip for a safer Black Hat computing experience is about network security. We’re starting with this one since it’s the heart of our StoneGate network security solutions as well. While at Black Hat, try to avoid connecting to any networks, including wired and wireless ones. For wireless networks especially, don’t connect if you can help it, even if the SSID of the network looks trustworthy (for example, it looks like a network operated by the casino…it may not be). If it’s possible to use a cellular modem instead, it is recommended to do so. If you do need a network, remember that any communications can potentially be intercepted, and passwords and logins should not be sent in clear text.

If you do connect, be sure you are using a VPN with strong encryption and that your laptop or mobile device is up-to-date with the latest patches and updates, and that a firewall and virus scanner are installed, updated and operational. If you don’t need it, be sure to turn off wireless and Bluetooth. If the devices you have use a hardware switch to disable these functions, use it instead of the software option. Whenever you are not using the networks, be sure to disconnect and disable the functionality on your device to reduce your risk exposure.

More tips for a safer experience at Black Hat will follow, so stay tuned!

…you can believe it or not.

This is exactly the power that new StoneGate SSL VPN version 1.4 gives when assessing a Windows workstation trying to access corporate applications.

You can decide to verify case by case antivirus, age of pattern file, etc for a number of Antivirus engines (and customize parameters if you need to) such as McAfee, Trend Micro, Sophos, Panda Software, Norman, Grisoft, CA eTrust and others.

You can event check for running processes, registry paths, listening ports… or you can simply trust Windows Security Center when it says I’m OK! since quite often this means:

• Windows is updated from patch perspective
• Windows Firewall (or equivalent) is properly operational
• Antivirus is running and updated

Here’s how to do that.

Access Administrator’s interface, then click on Manage Resource Access – Access Rules and create a new access rule based on Assessment.

From Plugin list, select Security Center as shown below:

Click Next

Decide which options to enable in the check as shown below:

Click Next – Next – Next – Finish

Apply, in logical AND or logical OR, the access rule to protect the resources you are interested in.

Easy, right?

StoneGate SSL VPN provides similar techniques to assess also Mac OS X for checking files, directories and related has values.

Assessing mobile users. Simplified.

Most admins don’t feel comfortable using the console (over ssh), and ofcourse it is not as trivial as it seems – especially remembering the exact commands. So, for the community, and for my own personal use, I’ll document a small issue I just had, and how I “solved” it.

A customer called, saying: “I use the StoneGate VPN to connect to my server with RDP, and all I get is a black screen”.  Now, that’s something that’s (unfortunately) not too uncommon. Google for “MTU”, “Path MTU Discovery” and “Black Hole Detection”, and you’ll get tons of info, which all come down to:

Single packets in ethernet networks have a maximum size of 1500 bytes (RFC 879). 1460 bytes of data + 40 bytes header (ip-addresses, ports, settings etc.). All tunneling protocols (VPN, PPTP,PPPoE, etc.) add some bytes to the header part. This means less room for the data part.

Both “client” and “server”  agree to send packets with max. 1460 bytes of data. The first few packets of the connection aren’t large, perhaps 1000 bytes max, and fit through perfectly. Client and server agree to communicate, draw a frame of the correct size, etc. Then however, comes the Windows Logo, a picture that is over 3000 bytes of size.  That means,  2  large packets are sent.  Somewhere on the connection from server to client, these packets do not fit. So, the picture the server sent, does not reach the client. A black screen of the wanted size just sits there, and waits… and waits…. and waits…..

Since I do not want to discuss what causes this,  but just want to know if it IS an MTU issue, I do following:

• check if both sides agree to use 1460 bytes of data
• reduce the packet size on either client or server side to 1310 bytes of data
• test whether RDP works again

So, lets see what happens (this is where we get technical, sorry non techies).

I’ll explain what the commands do later on. I start my Putty SSH Client, and logon to the firewall with root/mypassword. Since I want to see the traffic going from firewall to the server, I put in the server-interface, filter for the server and the RDP port 3389, as well as not to show my own IP:

root@fw-zentrale1:~# tcpdump -i eth1 host 192.168.101.103 and tcp port 3389 and not host 259.79.49.139

I tell the customer to connect, and the first 3 lines show:

14:23:36.348613 IP 192.168.101.142.1326 > 192.168.101.103.3389: S 1913531291:1913531291(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,sackOK>
14:23:36.348803 IP 192.168.101.103.3389 > 192.168.101.142.1326: S 2569746333:2569746333(0) ack 1913531292 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
14:23:36.517536 IP 192.168.101.142.1326 > 192.168.101.103.3389: . ack 1 win 65535

Yes, dear readers, that’s what packets actually look like. I highligted the part where the data size is set. It seems both sides agree to send 1460 bytes of data. I ask the customer to lower the MTU on his laptop from 1500 to 1350 bytes, using “drtcp021.exe”, one of the ancient tools in my toolbox. You can get it from serious sources easily. The customer reboots his laptop for the MTU to be set, I press “enter” a few times, to get a few newlines and ask the customer to connect once more.

14:32:58.634817 IP 192.168.101.142.1114 > 192.168.101.103.3389: S 720573675:720573675(0) win 65535 <mss 1310,nop,wscale 1,nop,nop,sackOK>
14:32:58.634903 IP 192.168.101.103.3389 > 192.168.101.142.1114: S 858372081:858372081(0) ack 720573676 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
14:32:58.825297 IP 192.168.101.142.1114 > 192.168.101.103.3389: . ack 1 win 65535

Aha! The client now want to send a maximum of 1310 bytes per packet, the server still wants to send 1460 bytes per packet. Ofcourse, both agree to use the lower value, so they can speak together. the Windows image is now sent in slightly smaller portions, and arrives at the client. The logo appears, the customer can login, and is astonished.

Now starts the long discussion as of why this happens, what can be done against it, and why the heck this problem bugs him alone! (it doesn’t). That has been discussed a lot on lots of sites and platforms, but does not belong here. I will just end it here with a short explanation of the command, and some nice tips to further explore the possibilities of actually looking at the packets themselves.

• tcpdump : available on virtually all unix/linux based environments
• -i eth1 : show packets on ethernet port 1. use “ip addr” as a command for an overview of interfaces and ip’s
• host 192.168.101.103 : show packets going to or coming from this ip-address
• and tcp port 3389 : but only packets on the RDP (Remote Desktop) port
• and not host 259.79.49.139 : but not the packets from my own session to the server

you can also use “and not icmp” or “and not udp port 23” instead of showing tcp packets. If you like your filter, but things go too fast for your eyes, use “-w jebdump1.dmp” to write the packets on the firewall, where you can get them using scp or sftp (hint: winscp and root/password). On windows, you can then use “wireshark” or “packetyzer” to have a (colorized) view at your own speed. Sometimes you’ll want to add “-s 0“(that’s zero) to get the full 1460 (or 1310) bytes of the packets that pass by. By default tcpdump doesn’t record the full data part of the packets, but just the start of it.

Try not to be scared of the console, it can really help you out sometimes!

In this article I’m taking it one step further, since StoneGate SSL VPN can authenticate a user presenting a valid certificate without even knowing who the user is, and use then whatever field of the certificate to perform SSO to protected resources.

The idea of testing and verifying this came, as usual, from a customer case discussed earlier this week in a webinar.

The customer wanted to have their users presenting a valid certificate, having the SSL VPN system validating them and granting the direct access to a backend application.

To minimize the usage of passwords, they wanted that SSL VPN extracts from the validated certificate a whatever field and uses this to SSO to backend application.

Here’s how to configure it.

First, access to StoneGate SSL VPN Administrator interface and click on Manage System – Authentication Methods.

Select the Certificate Authentication method you have defined (if you did not define, refer to previous article linked in first sentence).

Select Extended Properties tab.

Add two extended properties if they are not there:

• Allow user not listed in any user storage set to true
• Certificate Attribute set to the certificate field you are interested to use as a User ID (for instance CN, OU, O, etc)

Documentation reports that this field should be only used in conjunction with User Attribute to execute the match as described previously, but the reality is that if you reference this alone, then StoneGate SSL VPN will use this as the user ID of the authenticated user as shown below (I referenced the attribute O to get the organization’s name):

Soon I’ll publish another article about how to use this credential in Form Based SSO to an application, but for instance you can already configure the system to pass this information to backend application within the HTTP Header as a cookie: click on Manage Resource Access,  Global Resource Settings, Advanced and mark the checkbox User ID.

Save and publish and now the system is configured to add the User ID in a cookie within the HTTP request to backend resource.

Certificate based authentication. Simplified!

• how to access to existing user repositories?
• what if I need a new one aside?
• what if I need access to multiple repositories?
• which information can I use?
• what about grouping?

StoneGate SSL VPN provides a very flexible and powerful answer to these questions, and this article will provide some useful details.

First, let’s deepen the concept of a user storage and why it is useful.
The user storage is the external location where users are stored and it is used by the Policy Service as part of the authorization process.

In StoneGate SSL VPN you can define multiple user storages, of different types, using the predefined supported types (MS Active Directory, OpenLDAP, Novell eDirectory, IBM RACF) or configuring a customized one.

This article will show you how easy, quick and flexible is to define an external OpenLDAP as a user storage.

Once defined, a user storage allows you to link user profiles, to define group membership based access rules, to use user attributes for Single Sign On purposes and numerous other operations in StoneGate SSL VPN.

After defining an OpenLDAP instance on Ubuntu 8.10 system, I realized the video reported below to show you the “less than two minutes” process.

The video is also available at higher resolution here.

Now, let’s see some examples about how can I use the information in a user storage.

• Define user properties location groups, and reference them as access rules
• Define user location groups, and reference them as access rules
• Configure user profile attributes in Federated ID assertions
• Use user attributes as variables in notifications channels definitions, for example mail address and sms based messages
• Define user profile attributes (for example, samaccountname) in Single Sign On domain configuration
• Automatic user definition through linking process (in Administrator interface, click on Manage Accounts and Storage, then User Linking in left hand menu)

User storage definition is a great idea to reference existing user repositories to leverage them as basis for flexible and powerful secure access to corporate applications.

Enjoy!

Finnish CERT (CERT-FI) recommends to pay special attention to certain address blocks.  They mention the DROP-list by the Spamhaus project as the most up-to-date list of malicious addresses.

It is always boring and time consuming to type long lists of addresses, so I made a quick-and-dirty script, which converts the DROP-list into StoneGate elements, and creates a group of them.  You can feed the DROP-list to this script, zip the result and import it into SMC.

Being an oldtimer, I wrote this with an ancient tool called awk, which you can find in most unix-based systems, including linux.  The most common variant is the GNU awk, gawk.  Someone would probably write this in 2 lines of Perl…

I provide this script as is, with no expressed or implied guarantees of any kind.  Use this at your own risk.  If you manage to break something with this, you have been warned and you assume full responsibility.  I have tested this on one system (Fedora Core 9) with one input, today’s DROP list from Spamhaus.org.

So, take a look at the code and decide yourself if you trust this.  Especially see the comment in the beginning.  Change the element naming convention to suit your needs and enjoy.

Just right-click any column header in the Log Browser and select some of the log statistics shortcuts from the menu that opens. Note that these shortcuts are all related to the column you originally selected.

A picture is worth a thousand words! Log Statistics provide you efficient tools to drill in to the relevant pieces of log data.