06 June 2014

FSecure's FreedomeVPN - what does "tracking protection" really mean?

Since my previous blog entry on FSecure's "FreedomeVPN" app and how it after my previous test didn't block Google's tracking cookies, there have been a couple of conversations on Twitter on this matter. One such conversation took place last night, when twitter user @PrivacyMatters referred them to my blog post and asked for FSecure and Mikko's take on it. It went something like this:

Interesting... they apparently disagree that their failure to block Google's tracking cookies* is not really tracking, or maybe that Google is not a tracking company, or maybe that Google is not in the advertising or selling-user-data to-advertisers business.

* = Google's persisted tracking cookies include a long unique number assigned to each visitor, and identifies each site visitor, where they came from, and on Google's end can be matched up to everything else that Google knows about that user.

So... maybe I am just to picky. Maybe Google don't track users, and their tracking cookies is not part of FSecure's "untrackably invisible claim". This morning I decided to take FSecure's FreedomeVPN for another 3-minute test just to see how their tracking protection measure up, and if I am maybe just too picky.

This time I decided to simply check if Facebook is able to track me around the web with FreedomeVPN's tracking protection is active. You may have noticed that many sites around the web have embedded Facebook Like boxes.

The Facebook like box shows if you and any of your friends have clicked "like". It comes in a few different shapes and sizes, but whenever it is present on a site, it means that every time you visit that site Facebook will know you did so through the use of their own tracking cookies. This seems like something that I would expect Freedome's "tracking protection" to block.

If Facebook is unable to identify you, the tracking box will state how many people have clicked "like" on the site and show some random profile pictures of people who have clicked like:

If Facebook is able to identify you, the tracking box will show if you at any point have clicked like, and it will show your own profile picture and profile pictures of any of your friends that have done so too, rather than profile pictures of other random Facebook users:

My test today was simple, and as follows. I installed FSecure's FreedomeVPN again (to ensure I had the latest and greatest version installed for the test):


* = Note the "become untrackably invisible" slogan is still there...

After installing, I activated all the protection features, including "tracking protection" with an exit point in Finland.

Surely I was now "untrackably invisible" to all datamining and advertising companies..? Easy to find out, just hit a (non-FB) website with an embedded FB asset*.

* = FB like button/like box/share button/login button/etc all work the same and come with the same tracking features.

Lo and behold. Despite having all FreedomeVPN's "anti tracking" and now being "untrackably invisible", Facebook was able to identify me when visiting a third party site. This means they are able to track me on ANY site around the internet that has an embedded FB Like, Share, Login, etc button embedded.

Sorry, FSecure and Mikko Hyppönen: I think we have different views on what "tracking protection" and "untrackably invisible" means.

After the test, the FreedomeVPN control panel says they have blocked one tracking attempt. Obviously not the one from Facebook, but maybe some other more obscure tracking service in that case...?

This app doesn't seem to do what FSecure's marketing claims it does, so I will uninstall it for now. Maybe I will try it again some time in the future if FSecure's developers catch up with what their marketing team's claims.

27 May 2014

False sense of security: FSecure's freedome VPN service

Every now and then, political events in different parts of the world can trigger situations where internet freedom is reduced. Such is the case at the moment in the South East Asian country where I reside; due to a recent military coup, some people are now afraid of increased monitoring, censorship, or other moves to reduce freedom of information by those in charge. This fear has led to an increased interest in using VPN services.

Earlier today, I came across an advertisement from Finnish antivirus company F-Secure where they used current events in Thailand to push their VPN client and VPN service for Android and iPhone, dubbed FreedomeVPN. This is one of their twitter ads:

I thought it would be a good idea to take FreedomeVPN for a test-spin, so I installed it on my Samsung Galaxy S4, a fairly up-to-date and modern smartphone.

This is what the the VPN app's main screen looked like once it was running on my phone:

A few swipes later, the app showed this reassuring statement in the "tracking protection" ring. It was very nice to read that they protect me from hackers, advertisers, and data collection companies...

I would like to know more about how that works, so I clicked on the "How does this work?" statement and got another warm and fuzzy/reassuring statement:

My interpretation of the statement shown in that screen is that FSecure's VPN service will not only give me a new exit point in another country, but it would also block tracking cookies from advertisers and data collection companies.

That's nice to hear, so I took it for a test spin and hit a server where I could see server side what was sent in the HTTP header, or in layman terms in the information that your web browser will send to every web server you visit. This is what my HTTP header looked like when masked by FSecure's FreedomeVPN service:

...and this is what it looks like when I hit the same server from the same device without running FSecure's FreedomeVPN with "tracking protection" enabled:

Guess what: they're exactly the same. NOTHING is masked when it comes to cookies and other http header data.

Tracking cookies from Google (one of the world's largest advertising companies), latest referral URL from a Google tracked site, and other semi-unique things (that combined can form a unique-enough combination to identify an individual user, such as the combination of user-agent, accepted languages, etc) are passed through as-is.

Nice move of F-Secure to offer a "free for a few months" VPN service, but maybe a good idea to cut down on feature claims that don't stand up to a 3 minute test-spin?

27 April 2014

Huagati DBML/EDMX Tools is now free to use

The latest version of Huagati DBML/EDMX Tools (v 2.34, released on 27 Apr 2014) has all license checks removed. This means it is now free to use. $0/user, no cost, no strings attached.

22 February 2014

Blocking RDP brute-force logon attacks

One thing that has annoyed me for some time is RDP brute force attacks on my servers. If you have a physical or virtual Windows server hosted in a datacenter or in the cloud, you most likely use RDP (Remote Desktop) to access it. Script kids trying to gain access to systems of course like to attempt to do so via RDP, and they use automated tools they found on some "hacker" site to try to brute-force servers with open RDP listeners.

If you have a secure combination of username and password to log in to your server (or VM), brute-force attacks are unlikely to succeed. If you use a bad/insecure password, you will be hacked in a whiff. If your password is even on the top 10k list of reused passwords, you're likely to be hacked sooner or later.

I believe my choice of username and password is secure enough to survive RDP brute force attacks for the time being, but I still find it annoying that these kids are trying to break into my server so I wanted to have a way to block them.

Signs of a RDP brute-force attack

Whenever a server is under attack, it will log large amounts of Audit Failure events with event id 4625 in the Security event log. Each entry contain details about the login attempt, including the remote IP address of the attacker. It looks something like this on a Windows 2008 R2 server:

Blocking attackers

Since the event log entries contain the attacker's IP address, they can of course be blocked by adding them to a firewall rule. Naturally, noone would want to do that by hand, as it would be time consuming and most likely too late (the attack has either failed and the attacker moved on, or been successful and the server compromised).

Instead, I updated and repurposed a service I wrote back in the days of the ASP.NET POET vulnerability. The service simply monitors the event log for a pre-defined type of events (in this case the above mentioned Audit Failures), and if it detects too many originating from the same source IP within an hour it adds the originating IP to a firewall block rule, and optionally sends an email alert to the server admin.

In short, the service creates an event log listener and will listen for failed login attempt event log entries. If the same IP address has more than a configurable (default 10) number of failed logins within an hour, it is added to a firewall block rule in the Windows firewall. Warning: this will of course also block legitimate users if they have forgotten their username and/or password and try to log in repeatedly with invalid credentials.

The service also looks for signs of a distributed attack; if failed logins from multiple IP addresses exceed a pre-defined threshold (default 50) within an hour, it sends an email notification to the server admin.


I have made a beta version of the RDP blocker service available for download for anyone brave enough to test it. Binaries for the compiled version is available here: HuagatiRDPBruteForceBlockerService_release_v112.zip, and the source code is available here: HuagatiRDPBruteForceBlockerService_source_v112.zip

Disclaimer: Use at your own risk. If used incorrectly, or if there is a bug or flaw I didn't think of, this service can potentially lock you out of your server permanently and/or prevent legitimate users from accessing it.  Do not use on vital/important/production systems. Any use (or misuse) is your own responsibility. No support provided. Batteries not included. Don't use this service if you don't know what you are doing, and even if you do it has not yet been tested enough to be deemed safe. I have only tested this service on a Windows 2008 R2 system with US-English Windows. Using it on other versions of Windows and/or other localized variants may have unintended consequences. Depending on network configuration and/or firewalls in front of your server, *all* external traffic may appear to come from the same (internal NATed) IP address to your server. If this is the case, the service will block all traffic to your server.

Installing and configuring the service

The following steps are required to install this service:

  1. Download the service onto the server where you are going to install it.
  2. Right-click on the zip file, go to Properties, click on the "Unblock" button.
  3. Unzip the contents into a folder where you want to install the service.
  4. Run installutil /i HuagatiRDPBruteForceBlockerService.exe to register the service in the Windows service configuration. The installer will prompt for the username and password that the service will run under, this account must have administrative privileges to be able to create firewall blocking rules.

    Installutil is part of the .net framework and can usually be found under C:\windows\Microsoft.NET\Framework\v4.0.30319.
  5. Edit HuagatiRDPBruteForceBlockerService.exe.config using your favorite text editor. Update all relevant configuration options* to match your system/environment.
  6. Start the service from the windows service manager.

* = The configuration file contain several configurable parts. The following describes the important ones that you need to, or may want to update:

SMTP settings

configuration/system.net/mailSettings - this section contains the details needed by the service to send email via your SMTP server. You need to update (at a minimum) the host name, user name, and password used to authenticate against your SMTP server. Additional details about available configuration options are available here.

Service app settings

configuration/applicationSettings/HuagatiRDPBruteForceBlockerService.Properties.Settings - this section contains the settings that controls the configurable parts of the service's behavior.

The following describes each of those settings:
  • MaxFailedLoginsPerIP - numeric value, number of failed login attempts allowed for one individual IP address within an hour.
  • UseFirewallBlock - boolean (True/False), controls if firewall blocking is enabled. If you want to run the service in "warnings only" mode where it sends email alerts without blocking potential attackers, set this to false.
  • SendEmailNotification - boolean (True/False), controls if email notifications are enabled. If you do not want the service to send email alerts/notifications when detecting potential brute-force attacks, change this settings to false.
  • EmailNotificationFrom - email address that will appear as the sender for all notification emails sent from the service.
  • EmailNotificationTo - email address that any email notifications will be sent to.
  • WhiteList - comma separated list of IP addresses that the service will not attempt to block/blacklist. Add your own static IPs to this list to avoid getting blocked if you mistype your password.
  • EventLogName - the name of the security event log on the local system.
  • EventLogQuery - event log listener query used for finding failed login attempts in the Security event log.
  • IPMatchRegEx - regex used to find the IP address of the attacker in the event log entry.
  • DistributedAttackWarningThreshold - threshold for number of failed login attempts allowed from multiple IP addresses within an hour before an alert is sent for a potential distributed attack.

Again, feel free to grab the blocker service from the download links, but use at your own risk. If you have any comments/feedback/questions, please feel free to post in the comments section below.

19 May 2011

Entity Framework Model Creation beyond ‘Database First’ / ‘Model First’

The built in tools for Entity Framework 4 in Visual Studio forces users to make a distinct choice between the “Database First”, “Model First”, or “Code First” model creation and update strategies. A recent MSDN Magazine article by Julie Lerman describes the options and choices that has to be made on which approach to use for updating the model.

I think those three choices are a bit limiting in that not being able to continually evolve both the model and the underlying database is not an ideal situation for many projects. Applications evolve and so do the underlying databases, often with changes made by several people using different tools. That is the reason why I created the Model Comparer for EF4 in the first place.

Even if the model is based on an existing database, a.k.a. ‘Database First’, I think it should be possible to use the EF designer built into Visual Studio to update the model and add/remove/change entities/tables, members/columns, associations/foreign keys etc.

Likewise, if the model is designed from scratch in the EF designer (‘Model First’), it should be possible to make incremental changes with SQL-DDL diff scripts, as well as making schema changes directly in the database and sync those changes back to the model.

I made a short (4½ minute long) screencast illustrating how this is possible to do with the EFv4 visual designer together with the model comparer. In this video I make changes both to the database in SQL Server Management Studio and to the model in Visual Studio and then sync it up to replicate the changes into both the database and the model.


The video above is also available on youtube at http://www.youtube.com/watch?v=doqYOlcEAZM , although the youtube version is lower resolution and has more MPEG compression artifacts than the one embedded above.

Oh, and if you want to try it out yourself, you can download the add-in that makes this possible from http://huagati.com/dbmltools/ and get a free trial license from the same site.

18 January 2011

Redistribution licenses for the HuagatiEDMXTools.dll EDMX file object model

In an earlier blog post, Creating or modifying Entity Framework EDMX files from code: an introduction to HuagatiEDMXTools.dll, I wrote about the EDMX file wrapper that is used by the Huagati DBML/EDMX Tools add-in for parsing, updating, creating, and writing EDMX files. HuagatiEDMXTools adds an easy to use object model on top of EDMX files (see documentation at http://huagati.com/edmxtools/help ), making it a lot easier to create/read/update EDMX files, and to write LINQ queries against Entity Framework 4 metadata. It also has a number of built-in queries and lookup functions that make it a breeze to work with Entity Framework 4 EDMX files from code.

Previously, using the HuagatiEDMXTools runtime library required an end-user license for Huagati DBML/EDMX Tools. As of the latest version (v 2.20) this has been extended with a new redistributable license option, allowing third party applications to use and include HuagatiEDMXTools.

Redistribution licenses are divided into three categories:

  • Non-development tool license: allows redistribution of HuagatiEDMXTools.dll together with software products not primarily targeted at software developers and whose primary purpose is not to develop software. This may be line-of-business applications that need to generate, update, or read EDMX data to fulfill some functional requirement.
  • Development tool license: allows redistribution of HuagatiEDMXTools.dll together with software products whose primary purpose is to assist software development. This may be a tool specifically for working with Entity Framework 4 EDMX files, such as a new model editor or EF model designer.
  • Source code license: Source code licenses includes the source code for the HuagatiEDMXTools runtime library. The source code can not be redistributed, and any libraries/assemblies based on or derived from it may only be distributed as part of another software product that is not substantially similar to or competitive with HuagatiEDMXTools. (It may however be used for products competitive with the Huagati DBML/EDMX Tools add-in.)

Pricing and additional details are available at http://huagati.com/dbmltools/

28 December 2010

Inferring Foreign Key Constraints in Entity Framework Models (Part 2)

In my last blog entry, Inferring Foreign Key Constraints in Entity Framework Models, I wrote about a new feature in the Model Comparer for EFv4 that allow foreign key constraints to be inferred and added to an Entity Framework model even if some or all FKs are missing in the database. The inferred FKs can then be used to generate associations and navigation properties in Entity Framework models.

In the latest release of Huagati DBML/EDMX Tools, the FK inference feature has been improved with a new regex match-and-replace feature for matching foreign key columns to primary key columns. This allows FKs to be inferred even if the FK/PK columns to be matched use inconsistent naming and/or are named with special prefixes/suffixes etc.

Of course, the basic name matching feature described in the previous article is still there, and can be used under many (if not most) common scenarios. However, when the PK/FK naming is more complex then using Regex match+replace comes in handy for resolving what columns in one table can be mapped to the PK in another table.

The following screenshot shows the settings dialog with the new settings for RegExp-based column matching:


In addition to allowing the standard regular expression language elements to be used in the Match field, and the substitution elements to be used in the Replace field, there are two reserved keywords that can be used in the replacements as well; %pktable% which is replaced with the name of the primary-key-side table and %fktable% which is replaced with the name of the foreign key table when the match is evaluated.

The above screenshot shows how regular expression replacements plus the %pktable% substitution keyword can be used to match two tables even if the PK column is named “id” and the FK column in another table is named using the PK table’s name followed by “_key”; if the result of the Match+Replace on both sides evaluate to the same value, a foreign key constraint is inferred and will be displayed in the diff-tree and diff-reports in the Model Comparer’s main window.

The Model Comparer

If you want to read more about the Model Comparer and the other features for Entity Framework contained in the Huagati DBML/EDMX Tools add-in for Visual Studio, see the following links:

Introducing the Model Comparer for Entity Framework v4
What’s new in the latest version of the Model Comparer for Entity Framework 4
Using the Model Comparer to generate difference reports for Entity Framework v4 models
Mixing inheritance strategies in Entity Framework models
SQL Azure support in Huagati DBML/EDMX Tools
Inferring Foreign Key Constraints in Entity Framework Models
Simplify Entity Framework v4 models with complex types

…and of course, there is a brief summary of the add-in’s supported features for both Entity Framework and Linq-to-SQL at the product page: http://huagati.com/dbmltools/ where you can also download the add-in and get a free 30-day trial license.