Advanced scanning

eComscan runs out of the box on most infrastructure. In multi-server architectures, some manual configuration can help to reduce resource usage.

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.

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 root@10.0.0.8"). 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.

Prevent unwanted auto-scaling

eComscan is designed to use idle CPU capacity during peak scanning. This may trigger your auto-scaling threshold, leading to unnecessarily booted servers.

We recommend the usage of cpulimit to avoid unnecessary autoscaling during eComscan runs. If your threshold is set to 60%, you can avoid scaling up with this command:

cpulimit --limit 50 ~/bin/ecomscan [...]

Please note that the AWS utilization threshold is system-wide and that of cpulimit is per CPU.

If you prefer a precompiled version of cpulimit, we provide one here for Linux/AMD64.