Advanced scanning tips

Scanning cluster setups

Many larger stores run on a cluster environment, with different servers acting as web, file or database server. We recommend to install eComscan on each of these servers, unless the server has a read-only filesystem, where it does not make sense to monitor for file changes.

eComscan scans databases and shared filesystems by default. If multiple servers in your cluster are simultaneously scanning shared resoures, this may cause unnecessary network traffic. In that case, we recommend the following setup:

• Web servers only scan their local code base and do not scan shared resources such as NFS shares and database servers. eComscan should be ran with the --one-file-system and --skip-database options, and should use a scan path that is local to the web server (such as /var/www/yourdomain)
• If you have a shared file system (eg for media uploads), the best is to scan this on the file server (to prevent unnecessary network traffic). eComscan should be ran with the --skip-database option there (unless the file and database server are the same).
• With a separate database server, eComscan should run with default options, pointing to the platform configuration file (such as env.php, local.xml or wp-config.php). If required, the database connection can be overridden (see next section).

Override database connection

eComscan typically accepts a (disk-) path argument and will start scanning from there. Whenever it encounters a commerce configuration file, such as local.xml or wp-config.php, it starts scanning the relevant database.

For most stores this is sufficient. However, if your store uses dynamic database configuration, or you want to enforce a specific connection, you can override the connection information using the --force-dsn command line option. This takes a DSN, which is in the form:

USER:PASS@tcp(SERVER)/DBNAME

So for example:

maguser:s3cr3t@tcp(database1.provider.com)/magento

To get a DSN dynamically from a Wordpress setup, you could use the following script, which you could call wp-dsn:

#!/usr/bin/php
<?php
    require_once($argv[1]);
    printf("%s:%s@tcp(%s)/%s?prefix=%s\n",
        DB_USER,
        DB_PASSWORD,
        DB_HOST,
        DB_NAME,
        $table_prefix
    );
?>

First, check that your DSN generator works:

wp-dsn /path/to/dynamic/wp-config.php
# should show DSN

If that works, you can call ecomscan like this:

ecomscan --key=YOURKEY --force-dsn=$(wp-dsn /path/to/dynamic/wp-config.php) /path/to/wordpress

You can also override the DSN by setting an environment variable before running eComscan:

export ECOMSCAN_DSN=$(wp-dsn /path/to/dynamic/wp-config.php)

Scanning auto-scaling cloud servers

eComscan is a self-contained executable that you can add to your auto-scaling base image. Make sure that it is writable so it can securely self-update when necessary. Use the --one-file-system and --skip-database options so auto-scaling nodes will not scan your shared media and database.

If you deploy to anonymous cloud servers, the eComscan reports may not be immediately attributable to a specific store (eg. “report for [email protected]”). You can use the eComscan tag option to mark your mail and Slack alerts:

ecomscan --tag <projectname> 

Additionally, if you run in monitoring mode (only report new issues), eComscan keeps a local state file. Should an issue occur (eg a new Magento vulnerability is discovered), every autoscaling server will report an issue upon its first scan. If you want to prevent this, you can instruct eComscan to use a shared state file with:

ecomscan --state-file /path/to/shared/storage/ecomscan.state

The shared media storage (if writable) is generally a good location for this.