Securing Revive

No instance of Revive is totally secure but I though it might be useful to share a few of the tips I’ve gathered over the years in regard to securing the ad server. The intention being for others to add their own, with any luck we’ll create a half decent resource for new users.

1.1 Subscribe to the ‘Revive Adserver Project News and Announcements’ forum http://forum.revive-adserver.com/forum/26-revive-adserver-project-news-and-announcements/ and keep your Revive installation up-to-date.

1.2 Protect yourself against simple brute force dictionary attacks by using random passwords for the admin user and insist all other users do the same. I still get clients using passwords like ‘password123’.

1.3 Secure, (lock), your conf file, (covered in detail in the Revive install FAQ). Assuming you’ve ssh access to your server, (you can also change file permission using an FTP client), logon and at the command prompt type:

chmod 444 /path/to/revive/var/your.domain.conf.php

chmod 777 /path/to/revive/var/your.domain.conf.php

2.2 Change the default ‘admin’ user name. Why make it easy for Jonny Hacker by using a known user name to authenticate the most important Revive user?

You’ll need to access to your Revive Database and some simple SQL to edit the ‘username’ field of the *’ox_users’ table. Locate the record with the username ‘admin’ and change it to something more unusual, be sure to remember your new username or you won’t be able to login!

UPDATE ox_users SET username = 'weirdusername1' WHERE user_id = 1; //assumes the default case of admin as you first user be sure to check!

2.2 Once your happy with your instance of Revive move – not delete – the install scripts to a folder inaccessible via your web server.

The best place to move the install files too is probably your home folder, hence should you ever need to, your be able to easily replace the files.

mv /path/to/revive/www/admin/install*.php ~/

2.3 It’s advisable to add a second level of authentication to your admin console.

The specifics of setting this up for Apache are detailed here https://httpd.apache.org/docs/2.0/mod/mod_auth.html. In a nutshell it involves choosing how to store authentication details, (password file etc), creating some valid users and adding something like the following to Apache’s httpd.conf:

<Directory /path/to/revive/www/admin>
    AuthName "Restricted Area"
    AuthType Basic
    AuthUserFile /apache/passwords
    require valid-user


    #its a good idea not to cache the admins pages so changes are immediately reflected
    ExpiresDefault A0
    Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
    Header set Pragma "no-cache"
</Directory> 

Once done anybody accessing your admin console will be asked for a password by their browser before they can proceed. Whilst not the strongest form of authentication it does add an extra level of security. Similar solutions for Nginx etc are just as easy to implement.

3.1 Most successful attacks on Revive, (to date), have involved the bad guys using the append / prepend function.

If your not using this functionality you can disable it entirely. Depending on your flavour of DB you can change the ‘type’ of the *fields involved, making them unusable, this won’t necessarily stop injection attacks but it adds extra complexity to any hack, allowing you detect a breach i.e. the hacker will have to revert the ‘type’ of the fields involved. For example if you’re using MySQL the SQL below will suffice:

alter table ox_banners change append append varchar(0);
alter table ox_banners change prepend prepend varchar(0);
alter table ox_zones change append append varchar(0);
alter table ox_zones change prepend prepend varchar(0);

To revet the change, change the fields type back to ‘text’.

3.2 Monitor Revive’s core tables and plugins.

At the time of writing Revive’s Plugins, (/path/to/revive/plugins/3rdPartyServers/ox3rdPartyServers), are normally < 3KB in size. If you find one or more files that are larger and / or have different creation dates from the rest it is possible that a malicious plugin has been installed.

It’s best to get help on the Revive forums before deleting or disabling a plugin you’re unsure of. Disabling core plugins will cause errors in displaying ads and / or recording of ad impressions.

If anything weird, (i.e. strange banners, zones, users or activity), appears in the tables ox_banners, ox_zones, ox_users, ox_audit you could of also been hacked.

Putting this all together, it’s useful to write a simple script that you can put in your cron and run as often as necessary to send your admin an alert if anything unusual is detected in the plugin directory or these *tables. A good starting point for such a script being the SQL below:

SELECT u.user_id, u.contact_name, u.email_address, u.username FROM ox_users AS u, ox_account_user_assoc AS aua WHERE u.user_id=aua.user_id AND aua.account_id = (SELECT value FROM ox_application_variable WHERE name='admin_account_id');

SELECT bannerid, htmltemplate from ox_banners order by updated desc limit 10;

SELECT details from ox_audit where updated >= DATE_ADD(NOW(), INTERVAL -1 DAY);

SELECT bannerid, append, prepend FROM ox_banners WHERE append != '' OR prepend != '';
SELECT zoneid, append, prepend FROM ox_zones WHERE append != '' OR prepend != '';