Blog

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 offendingwebsite.com

;; ANSWER SECTION:
offendingwebsite.com. 86400 IN NS todd.ns.cloudflare.com.
offendingwebsite.com. 86400 IN NS pam.ns.cloudflare.com.

dig NS firedaemon.com

;; ANSWER SECTION:
firedaemon.com. 86400 IN NS logan.ns.cloudflare.com.
firedaemon.com. 86400 IN NS jessica.ns.cloudflare.com.


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

dig www.offendingwebsite.com

;; QUESTION SECTION:
;www.offendingwebsite.com. IN A
;; ANSWER SECTION:
www.offendingwebsite.com. 300 IN A 162.159.241.199
www.offendingwebsite.com. 300 IN A 162.159.242.199

dig www.firedaemon.com

;; QUESTION SECTION:
;www.firedaemon.com. IN A
;; ANSWER SECTION:
www.firedaemon.com. 300 IN A 162.159.241.199
www.firedaemon.com. 300 IN A 162.159.242.199

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 firedaemon.com 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.









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)
    MouseMove(10,10);
    MouseClick("left");
    Sleep(30000);
    WEnd;
  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



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.

    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.
    Tuesday, March 05, 2013

    FireDaemon Service does run and Process ID changes every few seconds

    If the process of your FireDaemon Service is changing rapidly, it's probably because it's crashing, not starting correctly or terminating. Generally it can be a pain to troubleshoot this kind of problem, but there are a few things you can do to fix it:

    1. Check the windows event logs, they usually reveal exactly what's happening.
    2. Try running your service as the user you installed the application as. This user should be a local or domain administrator. To change the service's user credentials set them in the Login section in the Settings tab: /manual/SettingsTab.html
    3. The local file system permissions might be wrong, see http://forums.firedaemon.com/threads/system-permission-on-local-drives.648/ for more information.
    4. If the executable is on a mapped drive or UNC path, your path might be in the wrong format, see http://forums.firedaemon.com/threads/how-do-i-use-mapped-drives-and-or-unc-paths.38/ for more information.
    5. Are you remotely connected via RDP?  Make sure the "Shadow Console" is enabled.  See
      http://forums.firedaemon.com/threads/accessing-the-shadow-console-via-remote-desktop-rdp-using-mstsc-admin-or-console.397/ for more information.
    6. If all else fails, then enable Debug Logging in the FireDaemon Service, let the service run a few times and then look at the debug log to see what's happening.  If you don't understand it, you can send a support ticket and attach the debug log to your ticket.
    Saturday, January 26, 2013

    Application doesn't launch under FireDaemon

    Often FireDaemon services are run off other local drives eg. E: F: etc. These drives could be a new local disk array, iSCSI targets or SAN LUNs. If you find your app is not launching under FireDaemon control then ensure you have checked that the Security permissions includes SYSTEM / Full Control. You need to check this as when you add a new drive to a machine and format with NTFS this permission is not automatically set. To check this:

    1. Go to My Computer and look for the local drive you want to check.
    2. Right click on the local drive and select Properties.
    3. Click on the Security tab
    4. In the list of "Group or user names" look for SYSTEM. If it is not there click Edit
    5. A new dialog box will be displayed titled "Permissions for E:"
    6. Click Add
    7. A new dialog box will be displayed titled "Select Users or Groups"
    8. In the "Enter the object names to select" type SYSTEM and click the Check Names button.
    9. Click OK
    10. Then in "Permssions for E:" dialog check Full Control
    11. Then click OK twice.
    Your FireDaemon apps should launch correctly.
    Monday, December 31, 2012

    Application Window is not visible when logged into remote desktop

    When you log into a computer remotely, by default you are only seeing the desktop of the user that you logged in as. Interactive services (including FireDaemon ones) are only visible on the shadow console session or on session 0. This is covered in the following article:

    http://forums.firedaemon.com/threads/accessing-the-shadow-console-via-remote-desktop-rdp-using-mstsc-admin-or-console.397/

    Tuesday, December 18, 2012

    Are administrative rights necessary to run FireDaemon?

    The FireDaemon Pro's GUI must be run as an administrator to function correctly on Windows XP and Windows 2003 Server.  On Windows Vista, 2008 and 7 the GUI's elevate correctly so the user should not need to be an administrator. Services can be run as any user,  however the privilege of that user will determine whether the service can interact with the desktop, access network resources and so forth. As a rule of thumb services should be run as Localsystem (that's the default). If network access is required then generally run your service as an administrator. FireDaemon will automatically grant user accounts "Log on as Services" rights.

     

    Friday, October 12, 2012

    Animal Logic uses FireDaemon for Automation

    Animal Logic

    Happy Feet, 300, Matrix Productions

    "The very simple service definition, automated process restarts and clean interface of the management console provides us with a "configure once and forget" solution, which maintains itself."

    An Interview with Jakub Krajcovic

    So what does Animal Logic do? Established in 1991, Animal Logic quickly earned a reputation as one of the world's leading design, visual effects and animation companies. With studios in Sydney, Australia and Los Angeles, California, Animal Logic continues to produce award-winning work for a diverse international clientele. Some of our productions include Harry Potter, 28 Weeks Later, AustraliaMoulin Rouge, 300 and the Oscar winning Happy Feet.

    What were the challenges you were facing? Delivering media to several playback and grading systems presented an ongoing challenge for Animal Logic’s technical staff. It was not possible to remove the deeply entrenched legacy system and start from scratch because of the prohibitive costs of development time and the effect it would pose for production. The media deliveries were not managed, this required a user to be logged on to the Windows console and there was no way of automatically restarting them in case one of the processes failed, except for manual operator intervention.

    Why did you choose FireDaemon? FireDaemon showed promise as a viable solution. And indeed, within a few clicks after installation it turned our previous system into an automated and well managed delivery infrastructure. The very simple service definition, automated process restarts and clean interface of the management console provides us with a "configure once and forget" solution, which maintains itself. FireDaemon‘s Trinity provides the added benefits of a web interface allowing us to manage several FireDaemon enabled delivery workstations from anywhere, without actually requiring a user to log in. FireDaemon has delivered a very strong management layer on top of our existing system without any ongoing costs.

    Guess what? Daily deliveries have been turned into a structured, managed and self-maintaining solution, which has minimal support time. FireDaemon has enabled us to focus on other things because we now know that we don't have to worry about getting data where it should be.


    Recent Posts



    Tags


    Archive

      Sign up for Product Updates and Discounts
      Captcha Image
      ×