Global Enterprise Controller

From The MetaFlows Security System Documentation
Jump to: navigation, search

The Global Enterprise Controller (GES) is essentially a web server capable of providing a web-based interface using Firefox and Chrome web browsers with a Flash plugin to perform the following tasks:

  • Host a virtually unlimited number of user accounts
  • Allow each user to configure and manage one or more sensor configurations
  • Allow users to share the tasks of managing one or more sensors
  • Allow users to view the events and reports generated by each sensor and interactively investigate incidents
  • Allow each user to share information and collaborate online.

The GES controller also aggregates and automatically maintains all the network security intelligence feeds that are routinely downloaded by each of the sensors created by its users. The intelligence feeds are fetched using Wget or cURL from the following sites:

  • (code updates, rule updates, intelligence data)
  • (code updates)
  • (rule updates)
  • (rule updates)
  • (reputation data)
  • (intelligence info)
  • (vulnerability info)
  • (vulnerability info)
  • (vulnerability info)
  • (vulnerability info)
  • (maps)
  • (virus hashes)

Adding IP Reputation Feeds

The MSS sensors pull down the new intelligence feeds every twelve hours from the controller. In addition to the default intelligence feeds, it is possible to add additional user-defined IP reputation feeds dynamically to the controller. This, in turn, will propagate to all the sensor managed by the controller within twelve hours. Any IP reputation feed is supported as long as they have a single host or network address per line. If the feeds have a different format, customize the parsing to match the additional format. To add user-defined IP reputation feeds, perform the following steps:

  1. Customize and save the following script as /var/www/backend/
  2. Execute chmod +x /var/www/backend/
  3. Add the the line

in the file /etc/cron.daily/00metaflows-daily BEFORE the line /var/www/backend/

use LWP::Simple;



if ( ! -e "/var/www/db/$directory" ){
    `mkdir /var/www/db/$directory`;
foreach (@feedurls){
    if ($_ =~ /\/\/([^\/]*)\./){
        $thiscat = $1;
        $blcontent = get($_);
        @bllines = split /\n/m, $blcontent;
        print BL "src $thiscat.BL {\n";
        foreach (@bllines){
            if ($_ = /^s*(\d+\.\d+\.\d+\.\d+\/?\d?\d?)/){
                print BL "$line\n";
        print BL "}\n";

        $msg="Bad Reputation host from $thiscat";
        print RULEFILE "$tcp tcp $src any -> $dst $tdport (msg:\"SRI Rep: $thiscat TCP - $msg\";hasIP:$thiscat.BL;threshold: type limit, track by_src, seconds 300, count 1;classtype:bad-unknown;sid:".$sid."1;)\n";
        print RULEFILE "$udp udp $src any -> $dst any (msg:\"SRI Rep: $thiscat UDP - $msg\";hasIP:$thiscat.BL;threshold: type limit, track by_src, seconds 300, count 1;classtype:bad-unknown;sid:".$sid."2;)\n";
        print "problem parsing feed source\n";


The above script adds the IP addresses to /var/www/db/$directory/SRI_MALICIOUS.BL and each reputation feed is executed by the rules stored in /var/www/db/$directory/SRI_openrep_feeds.rules. This mechanism ensures that the IDS system leverage MetaFlows' fast IP matching code. After the daily cron runs, inspect these files to make sure they are correctly initialized.

Adding Commercial ModSecurity Rules

MSS sensors provide Passive ModSecurity functionality to detect web-specific attacks. The rules used to detect these attacks are maintained by SpiderLabs researchers and are downloaded as a gzip tar archive. By default, the GES controller uses the latest community rules. It is possible to customize the ModSecurity rules provided to the sensor with the following procedures.

Manual Rule Installation

  1. Download and extract the ModSecurity archive to a temporary directory with a command similar to:
cp modsecurityarchive.tgz /tmp
cd /tmp
tar xvfz modsecurityarchive.tgz (this will create a directory <modsecurity_directory>)
  1. Optionally customize the ModSecurity rules provided by SpiderLabs in <modsecurity_directory> according to their recommendations to match the particular set of web servers and web application environment.
  2. execute the following command to create a ModSecurity rule update file compatible with the MSS sensors:
/var/www/backend/ <modsecurity_directory> <tmeporaryarchive.tgz>

This command will execute a validation script to extract all the ModSecurity rules contained in the <modsecurity_directory> and

    1. delete any rule that is incompatible with our passive ModSecurity application.
    2. delete any duplicated rule
    3. delete any configuration directive that is incompatible with our passive ModSecurity application.

If the script encounters an error that it cannot fix, it will automatically invoke a vim editor so that the user can manually delete the offending line or modify the rule to make it work. After the script completes, it will create a distribution archive compatible with the MSS passive ModSecurity application. This archive can then be published as the ModSecurity distribution with the command:

cp <tmeporaryarchive.tgz> /var/www/metaflows/modsec.tgz 

The sensors will need to be restarted to fetch the new ModSecurity rules.

Automatic Rule Installation

It is possible to automate both the fetching of new SpiderLabs updates and publishing the ModSecurity updates by performing the following steps:

  1. Add the appropriate command to download the ModSecurity rules in the file /etc/cron.daily/00metaflows-daily and save the archive as a temporary file /tmp/update.tgz
  2. Add the following line after the download command:
/var/www/backend/ /tmp/update.tgz /tmp/cleanupdate.tgz
if [ $? == 0 ]; then 
 cp /tmp/cleanupdate.tgz /var/www/metaflows/modsec2.tgz

The above commands will publish the new distribution if the validation process succeeds. In this mode, the validation script will not ask for the user input if the validation is not successful - it will simply fail.

Previous Chapter Next Chapter