picture of the day - luxrender logos

Another selection of blast-from-the-blast illustrations, this time a collection of LuxRender logos I was working on. 

Enjoy!

Tracking Fortigate SSL-VPN User Activity with Kibana

The dream of the Elasticsearch stack is that you will be able to glean information that might not be easily derived (or, at all) from other sources. The real sizzle is that it might be able to tell you more than the things it has information on. Here's a real-world example using Fortinet Fortigate SSL-VPN activity (Forticlient User VPN connections).

The Use-Case

The Elasticsearch Stack can be used to find SSL-VPN concurrent use problems, which cannot be found with the Fortigate itself (without a true parsing of the raw logs, including the ones that are useless). To briefly review Fortigate SSL-VPN functionality, the administrator can disallow multiple concurrent logins with the same VPN account. This is good for both hosting revenue as well as security, as a client is forced to purchase a separate account for each user, and each client user's usage can be individually tracked for accounting/security purposes.

A common problem with this is that individual end-users may have more than one device that uses the SSL-VPN account, or a group of users may be attempting to use the same account. For instance, a remote-worker user may have the same SSL-VPN account in use on a desktop and a laptop, or a whole office of employees might be trying to use the same account. In either case, they'll experience a race condition between the competing devices attempting to use the same account (if concurrent account usage is disallowed). How do we see it in a particular user? We modify the query for them.

Pre-requisites

You must have users that use a Fortigate vdom SSL-VPN gateway that logs to Elasticsearch (ES). Using Kibana we'll construct a query based on the collected information, so if this is a single unit and not a vdom in a multi-chassis setup, pay attention to the query language changes below. You are encouraged to have Logstash brokering the information between the Fortigate and your Elasticsearch back-end. This is encouraged because it's "relatively easy" to have Logstash auto-bucket your categories of data so that ES can store it and Kibana can more easily reference it for the search we're going to perform. (Hint- I use the kv plugin, but be careful about merely accepting the labels as Fortigate reports them, src-port is different than source-port or source-prt, etc., especially if Fortinet devices are not the only ones reporting to your ES back-end.)

Construct the basic search Columns

In my setup I have multiple vendor sources reporting to ES (via Logstash), not just Fortigates. Regardless, I set up the columns in the Kibana discovery window including the following: user, group, bytes_received, bytes_sent, dst_ip, dst_port, duration, action, reason, remote_ip.

Construct the Query

Kibana can help a query along visually by being able to add filters literally with your mouse... but real men/women/trans know their true grit shows when the query itself includes all that filtering. It also makes it easy to communicate in a blog post like this one where there are no screenshots (maybe I'll add some later. LOL, who am I kidding? Just read it.) So, here's the complete query:

vd: "vdom_name" AND _exists_: "user" AND NOT user: "N/A" AND (( action: "tunnel-up" AND NOT reason: "N/A" ) OR ( action: "tunnel-down") ) AND NOT bytes_sent: "0"

You will want to substitute '"vdom_name"' with the name of your particular vdom. If you are running this against a standalone Fortigate unit and not a vdom in a Fortigate chassis, then you'll want to remove the 'vd: "vdom_name" AND ' entirely.

Viewing what we have so far, and what are we looking at?

Okay so we have the query and the result table set up. If your gateway is busy like ours you'll see lots of users. This query will only show their logins and logouts, with the time and data used within those sessions. Pretty handy, but let's narrow the query down to a single user to see if concurrent account usage is happening.

Modified query for one user

Using the account name "testaccount01" as the example, the revised query would be-

vd: "vdom_name" AND _exists_: "user" AND NOT user: "N/A" AND (( action: "tunnel-up" AND NOT reason: "N/A" ) OR ( action: "tunnel-down") ) AND NOT bytes_sent: "0" AND user: "testaccount01"

Once that's running (and a relevant amount of time to review access attempts, like 12 or 24 hours, has been defined) simply look at the "remote_ip" column. If there are different IP addresses showing up at the same time, then we have a winner! This is somewhat complicated if the competing devices are all behind the same NAT firewall, but their contentious activity will still be logged, and it should show busier than if a single user on a single device was successfully using the account by themselves.