Wednesday, September 30, 2015

When Your Content Delivery Network Is Bad For Your Website's Health

Here at FireDaemon we use CloudFlare to not only protect our web infrastructure from DDoS attacks but also to accelerate content delivery by virtue of CloudFlare's global CDN.

One of our customer's located in Kazakhstan contacted us recently saying they could no longer access our website as it was classified as a "Drug Cultivation" website. What was going on?! They advised that a recent court order had forced local Kazakhstan telecommunication companies to block a variety of drug cultivation and drug paraphernalia websites. A copy of the court order is below (and obviously in Russian). The offending website is listed on the bottom right.

Court Order

Well it didn't take long to figure out the problem. The offending website was also being served out of CloudFlare's CDN! Taking a look at the Name Server (NS) records it's clear that both sites DNS are delegated to CloudFlare:

dig NS

;; ANSWER SECTION: 86400 IN NS 86400 IN NS

dig NS

;; ANSWER SECTION: 86400 IN NS 86400 IN NS

Then checking the CloudFlare served address (IN A) records for both websites:


; IN A


; IN A

As you can see the address records are identical. Clearly the blocking/filtering methodology by KazTelecomleaves a lot to be desired but the ramifications are obvious:

  • If you are using a CDN and if your website accidentally shares IP addresses with a banned website and the content filtering not only includes domain name but serving IP addresses then your site it going to get blocked
  • The blocking in this case is not at a company level but at a telco/nation wide level. This has the ramifications in terms of loss of business as potential customers can no longer access your site
  • There's the possibility of implicit association between our business and an illicit drug cultivation site leading to potential loss of reputation
  • If other bans are in place using similar filtering methodologies then you and your business might never know about it and see a drop in traffic. We only found out about this by virtue of the customer advising us.

We have contacted CloudFlare about the issue but have had no feedback yet. In the interim we have disabled CloudFlare across the domain and deployed an alternate CDN technology. The main implication is that whilst Content Delivery Networks are highly beneficial they obviously have a side effect that they may penalise your website unduly by content accelerating not only your web site but other other less desirable websites leading to your website being mis-classified and blocked too.

Monday, September 21, 2015

One-shot Windows System Event Notification at its finest!

When doing system-related programming, you are sometimes in need of getting notified of system events, e.g. when:

  • another process has quit
  • you want your application get notified it should quit
  • the terminal server is ready

In this article I’m presenting a handy C++ class that solves a common requirement: using the system thread pool in order to get notified once a handle becomes signaled, asynchronously and thread-safe.

The Problem

The task of watching a handle to become signaled is performed in a different thread of execution, because you don’t want to block the main flow of the program. A quick and dummy approach is creating a thread that waits for a specific handle and then quits. But then you realise you have spun up some threads that do nothing else than occupying system resources and sit around waiting. Also you probably had to create yet another thread class just for this very purpose. And deep inside you feel that there must be a better and de facto standard way saving you from reinventing the wheel once again.

Indeed, since Windows XP/Windows Server 2003 there is a system thread pool that was invented exactly for this purpose (and others), right at your hands via the RegisterWaitForSingleObject and its clean-up counter-part UnregisterWait[Ex]; with the advantage that:

  • it saves you from writing yet another thread
  • it is much more light-weight and resource-friendly by utilising a thread pool
  • you can leverage an existing asynchronous notification system

Now, that sounds simple and easy, but given the whole bunch of possibilities the API is offering, quite the opposite is true. On one hand it’s the way how to use the API to achieve what you want, on the other hand you are not exempt from the caveats of thread-safe coding when it comes to installing and cleaning up the event listener. Even as a seasoned and accurate programmer I had to read the documentation multiple times and investigate thoroughly how other people were using it.

One-Shot handle_watcher

There are enough blogs and mentions about those API calls out there on the net. The unique thing to my post is where the handle watcher comes into play: you only need to pass it a handle and a callback and make sure the callback function is thread-safe and its implementation non-blocking. As a usual bonus when encapsulating dedicated problems your code becomes spaghetti-free and worry-free.

Note: RegisterWaitForSingleObject and the system thread pool open up some powerful possibilities, e.g. periodic notifications. Here we are concentrating only on listening to a handle’s signaled state once, and that’s the only purpose of the handle watcher class.

Now, the core of the class is quite straightforward:

// Smart pointer closing the handle with a call to CloseHandle
typedef std::unique_ptr<void, int(__stdcall*)(void*)> handle_ptr;

/** @short Watches a given handle once until it becomes signaled, whereupon the callback (work item) gets called.
class handle_watcher
    /** @short Take ownership of the handle and register it to be waited on in the system thread pool.
        The callback (work item) is executed once the handle becomes signaled.
        it is reset as soon as it has been executed. If you have special bound parameters, ensure
        that destroying them is thread-safe.
        @return Whether the passed in handle is valid
    bool watch_this(handle_ptr handle, std::function<void()> workItem);
    bool watch_this(void*&& handle, std::function<void()> workItem);

    /** @short Unregisters conditionally (waiting for already queued callbacks to get called) from the system thread pool
        @return The returned handle comes in handy when you still need to use it for post-flight operations;
        it is valid only when the callback wasn't called before, otherwise it is null
    handle_ptr cleanup();

    // internal callback handler
    void signaled();

The way it works is as follows:

watch_this takes the handle (correct: taking ownership) to get registered in the thread pool and a callback function (which is also called a work item on MSDN). The callback is registered to be called exactly once and not everytime the handle would become signaled.

Now that being said you can figure what the private method signaled is up to: it is registered as an internal signal handler. When it gets called it invokes the callback you provided to watch_this, then resets the handle and unregisters it from the thread pool, unconditionally, meaning it doesn’t wait for any queued callbacks. This might be logical but it is an important detail when calling UnregisterWaitEx - the callback (signaled itself or the callback you passed to watch_this must be non-blocking).

signaled also resets the callback as soon as it has been executed - a measure of freeing resources early, which makes sense to me because the handle watcher usually lives during the whole application uptime. Because the handle watcher gets notified from any thread out of the thread pool one has to ensure that destroying possibly bound parameters is thread-safe.

cleanup is used when you stop watching the handle upon program exit. It unregisters the handle from the thread pool, but waits until any already queued callbacks have been called. This is another reason why the callback itself must be non-blocking, which in turn means it must not be called from your provided callback! cleanup is a no-op if the watcher has been notified - signaled has already performed the necessary cleanup.

In case the handle didn’t become signaled and the callback wasn’t called, cleanup releases the handle and returns it to the caller. The handle can then be used further e.g. for quitting the associated application. In case the handle became signaled and the callback has been invoked the returned handle is simply null.

Of course all of the operations are performed in a thread-safe way. The only thing you need to ensure is that your callback function, the work item, is thread-safe and non-blocking as well, otherwise the notifying thread cannot return to the pool or cleanup might dead-lock. Best practice is to asynchronously notify the thread that installed the watch, which gives you the simplicity of single-threaded processing (see the excellent comment on this topic).

A Usage Example

Let’s take a look at how you would ensure an application you started from your program keeps running. Let’s assume you have the following WTL window:

#include <Windows.h>
#include <atlbase.h>
#include <atlwin.h>
#include <atlmisc.h>
#include <atlcrack.h>
#include <atlapp.h>
#include "handle_watcher.h"

class MyWindow:
    public CWindowImpl<MyWindow, CWindow, CWinTraits<WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN>>
        MESSAGE_HANDLER_EX(ProcessTerminated, OnProcessTerminated)

    virtual void OnFinalMessage(HWND thisWnd) override;

    int OnCreate(LPCREATESTRUCT createStruct);
    void OnClose();
    void OnDestroy();
    LRESULT OnProcessTerminated(UINT msgCode, WPARAM wParam, LPARAM lParam);

    void StartMyProcess();

    enum UserMessages: UINT
        ProcessTerminated = WM_USER,

    handle_watcher processWatcher_;

void MyWindow::OnFinalMessage(HWND thisWnd)
    if (handle_ptr processHandle = processWatcher_.cleanup())
        // quit my app

int MyWindow::OnCreate(LPCREATESTRUCT)

    return true;

void MyWindow::OnDestroy()

void MyWindow::OnClose()

LRESULT MyWindow::OnProcessTerminated(UINT, WPARAM, LPARAM)

    return true;

void MyWindow::StartMyProcess()
    processWatcher_.watch_this(start_process(L"myapp.exe"), [this]()
        // might get called any time, retrieve hWnd once and check
        if (CWindow wnd = m_hWnd)

All set? Attached you will find the whole implementation of the handle watcher. Have fun and keep the copyright!

Klaus Triendl, Software Engineering Director @ FireDaemon Technologies Limited
Wednesday, September 16, 2015

Fixing InstallShield's Visual C++ 2015 Runtime Preqrequisite

NOTE: InstallShield Professional 2015 SP1 has been released which addresses this issue.

At FireDaemon we’re using cutting-edge production tools like Visual Studio 2015 Professional and InstallShield Professional 2015.

A C++ program usually depends on the C/C++ runtime and the recommended way of deploying it along with your product is by utilising the Visual C++ Redistributable for Visual Studio 2015 from Microsoft.

In order to create a pleasant end-user experience we are integrating the runtime package into our Session 0 Viewer installer as a "prerequisite". These are simply installer conditions packaged as .prq file. You can create such prerequisites on your own by using Installshield’s Prerequisite Editor. InstallShield however already provides a lot of such prerequisites, as you can figure from the following screenshot:

InstallShield Redistributables

The prerequisite file for the Visual C++ 2015 runtime isn’t included yet in InstallShield Professional 2015, but one can download it from their saturn server where they upload all the prerequisite files: download for x86, download for x64.

When we tested our installers we discovered a problem with the 32-bit installation on a 64-bit machine: Session 0 Viewer 32-bit wouldn’t work at all when we installed it after having installed and removed Session 0 Viewer 64-bit. We noticed that the 32-bit runtime wouldn’t get installed!

After investigating the problem further it turned out that the prerequisite for the 32-bit runtime checks the following registry key by default to have a certain value:


Unfortunately, this key is not only set by the 32-bit redistributable but also by the 64-bit redistributable:

InstallShield Prerequisites

The quick solution is simple: create your own prerequisite that doesn’t check for this specific registry value but where the DLL is explicitly present: %SystemRoot%\SysWOW64\vcruntime140.dll.

Since this is clearly an InstallShield issue we opened a support case and they confirmed the prerequisite needs to be updated. Good news! Here’s an excerpt of the communication with Flexera support:

“Hi Klaus,

I have an update from our engineering team regarding this case. They have updated the conditions on the C++ 2015 Prerequisite so that it is not incorrectly detected as installed when the x64 redistributable is installed. So the conditions will be correct when this prerequisite is released with InstallShield 2015 SP1. Thanks for reporting the issue.


Flexera Software Support”

Klaus Triendl, Software Engineering Director @ FireDaemon Technologies Limited
Sunday, November 23, 2014

Contagion Dedicated Server as Windows Service

How to run Contagion as a Windows Service with FireDaemon Pro

Contagion is a zombie apocalypse game with human survivors. Ammunition and weapons are scarce so teamwork is the key to survival. There are 3 game modes available that change the objectives but when a human player is killed they respawn as a zombie.

Contagion Dedicated Server as Windows Service

Contagion Dedicated Server can be run as a Windows Service using FireDaemon Pro. FireDaemon Pro will allow you to have Contagion Dedicated Server start automatically at boot prior to login, allow you to start multiple instances of Contagion Dedicated Server and restart Contagion Dedicated Server should it crash. This guide will show you how set it up. You can also use FireDaemon Fusionto manage FireDaemon and other Windows services via your web browser.

Contagion Dedicated Server Setup Under FireDaemon Pro

You can only install the server files if you own a copy of the game.  The easy way to install them is via Steam's SteamPipe servers, but the caveat to this is that the Steam account must have Contagion owned on it.  We suggest that you do not use your local client version of Steam as it will be logged out when you install/update the server files and you risk having your Steam account hijacked/stolen should your server ever be hacked (since the hackers could then get access to your steam account).

  1. To make your new steam account for your server, go here. If you want to use your existing Steam account that already has Contagion, then skip to step 3.
  2. Purchase Contagion from here and gift it to the server account you just created
  3. Download and extract SteamCMD. The download is small (< 2 MB).
  4. Download the Contagion server files via the Steam SteamPipe servers:

    First before you can download the files, go to the directory where you installed SteamCMD and create a shortcut to "SteamCMD.exe". In the shortcut, edit the properties and in the target box, at the end of it (with a space before the following), put:

    +login USERNAME PASSWORD +force_install_dir "C:\Contagion" +app_update 238430 validate +quit 

    Contagion SteamCMD

    Note: Replace USERNAME with your Steam username and PASSWORD with your Steam password.  You will need to enter a verification string if your steam account has SteamGuard enabled.  The verification string will be sent to the email you set up as your steam account email.  This string only needs to be filled in once.

    It might take a while to download everything because there are over 6.11 GB of files. You should also run the shortcut every month or so to grab the latest server updates (stop your server first though).
  5. The server files do not include any server configs. Download this ZIP file and extract the cfg folder containing the configuration files to the directory "C:\Contagion\contagion\".

    Contagion Configuration Files
  6. Download[/URL] and install FireDaemon Pro into the directory of your choice (typically C:\Program Files\FireDaemon). You can download the FireDaemon service definition XML file which makes initial setup of your FireDaemon service easier.
  7. Next start the FireDaemon GUI from the desktop shortcut. Click on the "Create a new service definition" button in the toolbar (or type Ctrl+N) and enter the information into the fields as you see below. Obviously adjust paths to suite your installation.

    Contagion FireDaemon Windows Service Program Tab

    The most important field on the tab is the Parameters. The Parameters define the initial setup of your server.

    -console -game contagion -secure +map ce_barlowesquare +log on +ip -port 27015 +exec server.cfg +rcon_password YOURPASS

    • "-console" enables text base server display. The server can only be automatically restarted in text based mode
    • "-game contagion" loads the game
    • "-secure" enables VAC protection of your server (valve anti cheat). You can remove this command if you do not want to use VAC
    • +map loads a specified map on server startup. You can change "ce_barlowesquare" to whatever map you want. This command should never be removed.
    • "+log on" displays the output of information on the screen. You can turn optionally it off (+log off), but keeping it on makes it easier to debug any errors you might encounter.
    • "+ip" should be the IP of your computer (not, go here to get your IP). This command should never be removed
    • "-port 27015" This is the default server port. Changing it is generally used when you host multiple servers (as each server has to use its own port when using the same IP). This command should never be removed.
    • "+exec server.cfg" This simply executes your server.cfg file on server startup. If you run multiple servers from the same installation, you can specify other config files (eg. server1.cfg)
    • "+rcon_password YOURPASS" This sets your rcon password in the command line.  It is crucial that you set it here and not in your server.cfg file because exploits exist that allow malicious players to download your server.cfg file and get your rcon password to wreak all kinds of havoc.  Replace "YOURPASS" with a hard to guess password (preferably a mix of letters, numbers and symbols).
    • Additional information about the command line parameters can be found here.
  8. Now click on the Settings tab. If you DON'T want to see Contagion Dedicated Server running, uncheck the Interact with Desktop check box. You can optionally Contagion Dedicated Server as the user you installed it as. In the Logon Account field type your username (eg. Administrator) and then enter the user's password twice in the Password and Confirm fields. You can change the Process Priority to allocate more CPU time to the dedicated server or specify which cores the dedicated server will run on.

    Contagion FireDaemon Windows Service Settings Tab
  9. Now click on the Lifecycle tab. Uncheck Graceful Shutdown

    Contagion FireDaemon Windows Service Lifecycle Tab
  10. Now click on the Dependencies tab. Make sure the service depends on the lanmanworkstation (Workstation) service to ensure the TCP/IP and CIFS stacks are both up prior to starting Contagion Dedicated Server

    Contagion FireDaemon Windows Service Dependencies Tab
  11. Now click on the Install button to install and start Contagion Dedicated Server! If you are running Windows Vista or later your server will start on Session 0. You will need to switch desktop to see your server running.

    Contagion FireDaemon Windows Service Dedicated Server Session 0
  12. Below is an example Contagion Dedicated Service server.cfg file

    // Hostname for server.
    hostname "Contagion Server"
    //Server password (Uncomment To Use) //sv_password PASSWD
    //Tags sv_tags
    // Set to lock per-frame time elapse host_framerate 0
    // Set the pause state of the server setpause 0
    // Control where the client gets content from // 0 = anywhere, 1 = anywhere listed in white list, 2 = steam official content only sv_pure 2
    // Is the server pausable
    sv_pausable 0
    // Type of server 0=internet 1=lan sv_lan 0
    // The region of the world to report this server in. // -1 is the world, 0 is USA east coast, 1 is USA west coast // 2 south america, 3 europe, 4 asia, 5 australia, 6 middle east, 7 africa sv_region 0
    sv_rcon_banpenalty 60 sv_rcon_maxfailures 10 sv_rcon_minfailures 5 sv_rcon_minfailuretime 45
    // bandwidth rates/settings net_maxfilesize 64 sv_minrate 0 sv_maxrate 0
    // Log Settings //
    // Enables logging to file, console, and udp < on | off >. log on
    // Log server information to only one file. sv_log_onefile 0
    // Log server information in the log file. sv_logfile 1
    // Log server bans in the server logs. sv_logbans 1
    // Echo log information to the console. sv_logecho 1
    // Client CVARS //
    // Restricts spectator modes for dead players //mp_forcecamera 0
    // Disables Server-Side Cheats sv_cheats 0
    // Enable Voice Communications sv_voiceenable 1
    // Players can hear all other players, no team restrictions 0=off 1=on sv_alltalk 0
    // Execute Banned Users exec banned_user.cfg exec banned_ip.cfg
Wednesday, August 13, 2014

Avoiding Session 0 Auto Logout with FireDaemon Pro and AutoIT

Check out the FireDaemon Session 0 Viewer. It supersedes the method of switching to an remaining on Session outlined below.

Session 0 is the default Windows session where interactive FireDaemon Pro services are run. You can use the Interactive Services Detection Service prompt or the FireDaemon Pro Switch To Session 0 button to switch to Session 0 from your currently logged in desktop.

 Avoiding Session 0 Auto Logout with FireDaemon Pro and AutoIT

FireDaemon Pro Switch To Session 0 Menu Icon

Irrespective of whether you are at your machine's physical console or you RDP into your server, Session 0 will automatically log you off if there is no mouse or keyboard activity seen after 60 seconds or so. To get around this you can use FireDaemon Pro in conjunction with AutoIT to inject synthetic mouse movements and mouse clicks into Session 0. Note that you cannot RDP directly into Session 0 nor return to Session 0 directly if your RDP session was closed. Note that this technique may work with Team Viewer and other similar remote control applications (but you will need to test them). So here's what you need to do:

  1. Download and install FireDaemon Pro
  2. Download and install AutoIT
  3. Create an AutoIT script in a text editor (eg. Notepad) and save the script in the folder of your choice (eg. C:\AIScripts). We have called the script: s0-keys.au3
    While (1)
  4. This script is really simple. It moves the mouse to certain X and Y coordinates and clicks the left mouse button. The script then sleeps for 30 seconds and does it all over again. You can adjust these settings as you feel necessary but don't make the Sleep too low (eg. less than 10 seconds) as the script will run again rapidly and you might find you have lost control of your mouse!
  5. Now create the following FireDaemon Pro service copying the contents of the screen shot below. Install the service, then switch to Session 0 and you will find you are no longer automatically logged off Session 0!

    FireDaemon Pro Session 0 Synthetic Mouse Movement and Key Press Service Configuration

Friday, July 11, 2014

WordPress Hardening Guide

WordPress is a great blog platform but like anything popular, it’s often targeted by hackers hence hardening your WordPress deployment is mandatory. Getting your WordPress site hacked can be very stressful and a potentially expensive problem.  It’s akin to getting your *insert something important here* stolen.  This is especially true if your WordPress site is critical to your online presence as downtime can destroy the traffic you’ve garnered not to mention it can hurt your website’s reputation.

NOTE: This WordPress hardening Guide is an intermediate to expert task.

This guide assumes you or your web host have already secured the server computer itself.  If this has not yet been done or you aren’t sure, then you should do it first or ask your web host to do it for you as your WordPress could still be hacked if your server is insecure. Search Google for guides like “hardening linux” and “securing /tmp”. Also check out SELinux, CSF and LFD. also publish an extensive WordPress hardening guide.

Step 1: Changing the WordPress Database Table Names

This one can be difficult to do but it is the absolute most critical.  By default, WordPress prefixes all its database tables “wp_”.  Changing the table prefix to a random string makes it difficult if not impossible for a hacker to execute remote SQL injection attacks.

Go to the to generate a random database table prefix. If you haven’t installed WordPress yet, then during installation you can change the table prefix to the random string you generated previously.  Make sure you add an underscore ( _ )  after the string so your tables are easier to read.

If you have already installed Wordpress, then you will need to edit wp-config.php and enter the new database prefix.  Then export the entire database and using a text editor, replace the prefix of every table to the random string you generated above. Again, make sure you add an underscore ( _ )  after the string so your tables are easier to read.

Table names are stored in the CREATE TABLE `NAMEHERE` or CREATE TABLE IF NOT EXISTS `NAMEHERE` lines. After you do the edits to the exported database, you will need to drop the WordPress database on your web host and import your edited database.

Step 2: Update Your WordPress, Plugins and Themes

Keeping your WordPress, Plugins and Themes up to date is the single most critical thing you can do.  Exploits are discovered daily and if you leave your WordPress running an older version, you risk getting hacked. To update WordPress, login to the Dashboard and on the right hand side look for "Updates".

Step 3: Secure Your Plugins

Since plugins add new functionality, they can also add functionality you don’t want such as backdoors.  Before installing ANY plugin, do the following:

  1. Search the exploit databases such as Secunia and Exploit-DB to see if there's any security advisories for the plugin.  If there are, make sure they aren't for the current version.
  2. Check if the plugin is compatible with the current version of WordPress.
  3. Check how many support requests have been solved in the past few months. If it’s a low number (less than 50%), then look in the support forum to see what questions people were asking.  Plugins with poor or no support tend to not get updated often so avoid them if you can.
  4. Only if 1, 2 and 3 are OK then can the plugin be installed.

Here's a few plugins that should be avoided as they increase the attack surface of WordPress or are just generally malicious:

Additionally, if you have any plugins that are disabled and you don't intend to use them then delete them.

Step 4: Choosing a complex password

It is critical that you choose a complex and hard to guess password.  Choosing an easy to guess password makes as much sense as leaving your front door unlocked in a neighbourhood with lots of crime. If you must insist on using an easy to remember password then add a few symbols to it.  For example replace the letter S with a dollar ($) symbol, the letter O with a zero (0), the letter I with an exclamation point (!).  You should have at least 2 symbols and 1 number in your password and it should be at least 12 characters long (to increase entropy and make it even harder to guess or brute force).  If you still aren’t able to remember your password, then get a password manager application like KeePass or Any Password. Try and avoid browser based or browser integrated password managers as browser highjacking is common.  When using a password manager, use the random password feature with symbols.  The password will be impossible for you to remember, but it will also be very very difficult for hackers to guess.

Step 5: Folder and File Permissions

Using your FTP program or the command line (if you have access to it), chmod the permissions of all folders and files.  This is critical for security and while it is a long and boring process, you need to do it.

All directories should be 750 or if they require write access, then 755. All files should be 644. Exception: wp-config.php should be 600 to prevent other users on the server from reading it. File and group ownership (UID and GID) should be ideally set to what the webserver itself requires (eg. apache.apache).

Most FTP applications allow you to change the permissions of a folder and file simply by right click the object and selecting CHMOD, Attributes, Permissions or something similar.  Read the help file that came with your FTP application for more information.  If you’re using the command line, then use the following command:  chmod ### <folder or file name>

So for example let’s say you were chmod’ing the wp-admin directory which is located in /home/yoursite/wordpress/public_html, the commands would look like:

cd /home/yoursite/wordpress/public_html
chmod 750 wp-admin

Everytime you install a new plugin or theme; you will need to set the folder and file permissions for those new folders and files accordingly.

Step 6: Securing wp-config.php

Move wp-config.php outside of the web directory (eg. one directory up).  WordPress knows to look for the file in other directories if it can't find it in the web directory.

For extra security, add the following to wp-config.php:


Choose new authentication keys and replace the old keys in wp-config.php with the new ones you generated.

Step 7: Securing Themes

Put the following in your theme’s function.php file:

add_filter('login_errors', create_function('$a', "return null;"));
remove_action('wp_head', 'wp_generator');

Search your theme's header file for the following and delete it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

If you have any themes that are not being used or are disabled, then delete them.

Step 8: Recommended Security Enhancing Plugins

The following plugins will enhance security and should be installed and configured:

For more information on securing and hardening WordPress please consult the extensive and comprehensive WordPress hardening guide over at

Wordpress hardening guide

Tuesday, July 08, 2014

Starting Interactive FireDaemon Services In Session via Automatic Logon and Scheduled Tasks

This article provides an alternate method of starting Interactive Windows Services and detection under FireDaemon control in the currently logged in session. In our previous article we discussed how to do this using logon scripts. In this article we discuss how to automate your Windows login and run interactive services using Scheduled Tasks.

Step 1: Install FireDaemon Pro and Setup Your Services This is fairly straight forward:

  1. Download and install FireDaemon Pro
  2. Create your FireDaemon services. Ensure they are set to Manual Start and they are running as the LocalSystem account (ie. don't specify a user in your configuration). Check out our HOWTOs if you need a guidance setting up your app under FireDaemon control.

Step 2: Setup Automatic Login You now want to set automatic login for user you want to run your services as. To do this on Windows 7:

  1. Run netplwiz.exe
  2. Uncheck "Users must enter a username and password to use this computer" then click OK
  3. Supply the autologin username and password. If you want to use a domain user account see this article.
Step 3: Create a Schedule You now need to create a scheduled to auto elevate FireDaemon the starting of your services:
    1. Create a new Task (not a Basic Task) as follows:
    2. Run sched.exe (Windows 7) or taskschd.msc /s (Windows 8). Then in the
      • General Tab
        • Name: FireDaemonServices
        • Check: Run only when user is logged on
        • Check: Run with highest privileges
        • Check: Hidden
        • Configure for: Windows 7, Windows Server 2008 R2 (change this to suite your app and version of Windows)
      • Actions Tab (add an action for each service to be elevated - click the New button. Replace ServiceA with the actual short name of your service)
        • Action: Start a Program
        • Settings / Program/Script: "C:\Program Files\FireDaemon\firedaemon.exe"
        • Settings / Add Arguments:  --start ServiceA --in-session
      • Conditions Tab
        • Uncheck Start the task only if the computer is on AC power
      • Settings Tab
        • Uncheck Stop the task if it runs longer than
        • Uncheck If the running task does not end when request
        • If the task is already running, then the following rules applies: Run a new instance in parallel
    Step 4: Create a Shortcut Lastly, create a shortcut in the Startup Folder of the user in question that points to: C:\Windows\System32\schtasks.exe /run /tn "FireDaemonServices" And that's it - when you boot/reboot your machine your machine will auto login and run all your nominated FireDaemon services interactively. Should a service crash or be terminated accidentally then FireDaemon will restart you app in session.
    Thursday, May 15, 2014

    Starting Interactive FireDaemon Services In Session At Login Using Login Scripts

    Windows Vista or later implements Session 0 isolation. What this means is that services with a GUI component that would normally interact with the Desktop are not visible if you RDP into your server or login via the console. You will have to switch to Session 0 via the Interactive Services Detection Service popup. You can run Interactive FireDaemon Services on your RDP session though. There are some caveats:

    1. The FireDaemon service must be configured to run as the LocalSystem account. When the service runs In Session it will run under the logged in users credentials
    2. If you log off the service will be killed. FireDaemon will restart the service for you but back on Session 0.

    You can write a Windows logon script to run your services interactively. To do this:

    1. Create all the necessary FireDaemon services using the FireDaemon GUI
    2. Decide whether you want these services to be Manual start (ie. let the login script start them) or Automatic start (ie. they are started when Windows starts)
    3. Write the logon script batch file and place it somewhere logical on your C: drive
    4. Configure the logon script to run at logon via the Local Group Policy Editor.

    Here's an example logon script - it uses the "call" directive to avoid UAC and elevate appropriately. Remember the user you login as in this instance must have the necessary privileges (eg. be a member of the Administrators group) in order to run FireDaemon effectively. Use this script if your services are manual start (ie. your services are started In Session and killed and stopped when you logoff).

    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Mercury --in-session > Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Runtime --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start Taskmgr --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --start LST_Server --in-session >> Log.txt

    Use this script if your services are set to automatic (ie. your services are restarted In Session and killed and restarted on Session if you logoff):

    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Mercury --in-session > Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Runtime --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart Taskmgr --in-session >> Log.txt
    call "C:\Program Files\FireDaemon\FireDaemon.exe" --restart LST_Server --in-session >> Log.txt

    For more information on the FireDaemon Command Line Interface and various command syntax please see this section in the manual.

    Monday, September 30, 2013

    Installing Perl and the VMXNET3 driver retrospectively on a minimalist vSphere CentOS 6 virtual machine

    When installing a minimal CentOS 6.4 VM on vSphere 5.1 or later, Perl is not automatically installed. This means you can't install VMware tools and thus the VMXNET3 driver to enable networking. You could change the initial setup of your VM (eg. add the Perl packages during the install of CentOS or install an E1000 adapter in addition to the VMXNet3 adapter) but you might be in the situation that requires a nice clean install. The steps below allow you to retrospectively install Perl and VMware tools.


    1. The VM was created with a single VMXNET3 adapter
    2. An x64 instance of CentOS 6.4 was installed using the "Minimal" default installation of CentOS
    3. The CentOS 6.4 ISO is still connected to the VM
    4. You can login as root via the Virtual Machine Console in the vSphere Client
    5. You have a DHCP server on your network

    Step 1: Mount the CentOS 6.4 ISO

    Ensure the ISO is connected to the VM. Then at the root prompt type:

    mount /dev/cdrom /mnt
    cd /mnt/Packages

    Step 2: Install the necessary Perl packages

    Now type using tab command completion (line is wrapped for readability):

    yum --disablerepo=* localinstall 

    6 packages should be installed.

    Step 3: Unmount the ISO

    Now type at the command prompt:

    umount /mnt

    Step 4: Install VMware Tools

    In the Virtual Machine Console go to the VM menu and choose Guest -> Install/Upgrade VMware Tools. Then at the command prompt:

    mount /dev/cdrom /mnt
    cd /tmp
    tar xvzf /mnt/VMwareTools-9.0.5-1137270.tar.gz
    cd vmware-tools-distrib
    umount /mnt

    Follow the prompts to install VMware Tools. The defaults usually suffice. Remember this only installs VMware tools for the currently running kernel. If you do a yum update you will need to reinstall VMware Tools. Additionally note that the exact VMwareTools tgz will depend on the version of the ESXi hypervisor you are running so you might have to adjust the file name to suite.

    Step 5: Check the VMXNET3 driver is loaded

    At the command prompt:

    lsmod | grep vmxnet

    You should see the following similar output - this means the driver is loaded and is unused.

    vmxnet3        42862   0

    Step 6: Edit the network settings

    Now edit the network settings:

    vi /etc/sysconfig/network-scripts/ifcfg-eth0

    Change your network settings as you see fit but minimally change the following line in ifcfg-eth0 in order to get a DHCP lease:


    Step 7: Restart the network and get a lease

    At the command prompt type:

    service network restart

    The network will restart and you should have an IP address assigned via DHCP. Type:

    eth0      Link encap:Ethernet  HWaddr 00:50:56:87:51:A9
              inet addr:  Bcast:  Mask:
              inet6 addr: fe80::250:56ff:fe87:51a9/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:338 errors:0 dropped:0 overruns:0 frame:0
              TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:40438 (39.4 KiB)  TX bytes:7155 (6.9 KiB)

    That's it! All done.

    Addendum from Tristan at Aptira:

    A simpler way as the VMXNET3 driver is included with CentOS minimal for all 6.x versions.

    1. Install OS
    2. vi ifcfg-eth0 and set ONBOOT=yes
    3. Reboot and the network should come up.
    4. yum -y wget
    5. Grab the latest VMware repo from here For example wget
    6. rpm -ivh vmware-tools-repo-RHEL6-9.4.5-1.el6.x86_64.rpm
    7. yum install -y vmware-tools-esx-nox
    8. Profit!



    Saturday, August 31, 2013

    Importing and Exporting FireDaemon Service Definitions

    FireDaemon gives you the ability to import and export service definitions. A service definitions is a text file containing XML. So, why would you want to import or export your service definitions? Well .... you might be rebuilding your server and need to backup your configs or migrating from an older server to new one. Alternately, you might want to replicate FireDaemon service configurations across multiple servers. FireDaemon gives you four methods by which you can import/export your service definitions:

    1. Drag and drop: simply click on a FireDaemon service in the GUI and then drag that service to your desktop or other folder
    2. Via the Service or right click menu: choose the services you want to export or XML files you want to import
    3. File open, save and view: in the FireDaemon Service Definition dialog click on the  four icons that allow you to Open, Save, Save As and View
    4. Via the command line: you can import, export and enumerate FireDaemon services at a command prompt
    A complete list of FireDaemon XML service definition tags can be found in the manual.

    Recent Posts



    Sign up for Product Updates and Discounts
    Captcha Image