Richard Foley

Problem solved. Recompile Apache PHP adding to said resource.

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.   Tips are offered on a use at your own risk basis. Whilst most are simple, involving basic shell commands and SQL snippets, I stress that if not done properly some could lock you out of your Revive server. That would be a real bummer! Hence only do what you feel comfortable with, if you don't fully understand what's involved leave well alone.     1.0 Easy Stuff   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:   Lock chmod 444 /path/to/revive/var/your.domain.conf.php Unlock chmod 777 /path/to/revive/var/your.domain.conf.php     2.0 Slightly More Involved   2.1 Ensure your admin passwords are not sent as plain text by forcing users to access the admin console with HTTPS.   It your web server supports https, (type https://www.yourdomain.com into your browser, if your still unsure best to ignore this tip as you could lock yourself out of your server), or you are able to add https support do so and log into the Revive admin console as the ‘admin’ user and select ‘Configuration > User Interface Settings’.   Under the heading ‘SSL Settings’ tick the box ‘Force SSL Access on User Interface’ and save your changes.   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.0 For The Twitchy   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:   Current Users 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'); Updated Banners SELECT bannerid, htmltemplate from ox_banners order by updated desc limit 10; Recent Activity SELECT details from ox_audit where updated >= DATE_ADD(NOW(), INTERVAL -1 DAY); Injection SELECT bannerid, append, prepend FROM ox_banners WHERE append != '' OR prepend != ''; SELECT zoneid, append, prepend FROM ox_zones WHERE append != '' OR prepend != '';  
I considered adding general tips RE: hardening the host, MySQL, web server etc but decided to keep the scope solely to Revive. Be great if others added their tips below.
 
*Your tables prefix i.e. 'ox_' may differ in accordance with your preferences or if a clean install of Revive has been carried out as opposed to an upgrade from OpenX.

Hi Richard,
 
a feature request issue on github, even better a pull request. Of course with all the info on why it is required etc.
 
 
Cheers

Community member Ilya Behr at Black River in Toronto, Canada, wrote two extremely detailed online guides related to Conversion tracking using Revive Adserver.
 
The Conversion Tracking tutorial explains how to enable the feature, how to setup and implement a tracker, and how to analyze and interpret the statistics recorded by these trackers.
 
Next, the Debugging Conversion Trackers guide provides detailed instructions on how to check and validate the conversion tracking has been implemented correctly and reliably.
 
Thank you, Ilya, well done!

Hi Richard,
 
We've been considering this, but we do not think a sub-forum is a good place for that. In the future, there will be a separate section on http://www.revive-adserver.com/ with vendors and reviews.

If you have HTML banners containing http:// urls, then Revive Adserver won't serve them over SSL to avoid browser error messages. Please fix your banners, wait for the delivery cache to expire (or clean it up manually), then retry.

A campaign that's created inside one account is completely invisible from any other account. Likewise, a site and zone created in one account is not accessible from any other account.
 
The reason is that each account is a completely separate entity, what happens on one account is locked inside that account.

Yes, this should work just fine with Revive Adserver as well.

My first plugin using ldap library for authentication in revive.
https://github.com/karen-mikaela/ldap-auth
Maybe useful for someone.

I would suggest using the awesome Zone Chaining feature. Basically, you can chain a backup zone to your main zone, and if there are not banners available for display in the main zone then banners from the backup zone will show up.
 
You can do that on your zone editing screen like this:
 

The Revive Adserver project team is proud to announce the availability of a Beta release of the Revive Adserver software.
We’re asking members of the community to help us test this beta release of version 3.2.0, with focus on the following topics:
Asynchronous Javascript tags
We’re very proud to finally be able to offer support for Asynchronous Javascript tags. In short, these tags work in such a way that any delay in the adserver itself, will no longer cause a delay in the rendering of the webpage on which the tags are placed.
The new Asynchronous tags can be generated just as easily as before, by going to the Invocation Code tab of any zone. A new type of code will be presented when running the v3.2.0 beta: Creating invocation code for the new Asynchronous JS tags
We’ve tested the asynchronous tags in a variety of scenarios, but we might have missed a few. We’d like to ask the menbers of the community to test their banners with existing third party ad tags in combination with the new async tags. Do the third party ads work correctly when served via Revive Adserver onto a webpage? Likewise, we’d like to ask you to verify if the asynchronous tags, when trafficked into a third party ad server down the line, work correctly.
Language and translations
A lot of work went into a clean-up of the English language files of the product. At the same time, we’ve started a large scale translation project (see the recent blog post Translations for Revive Adserver). It is not unlikely that one or more or the English text lines have unknowingly been removed, but are still ‘in use’.
You would recognize this from a strange looking ‘placeholder’ text instead of the actual text you used to see in a screen, a field label, an explanation, a mouse-over, or anywhere else in the user interface.At the same time, a translator may have accidentally introduced something in a translation that breaks the user interface (for example, a line break was introduced or a special character that is not properly displayed). Delivery of contract campaigns
Version 3.1 (released in December 2014) introduced a set of fixes related to the correct and full delivery of contract campaigns. In this version 3.2.0-beta, we’ve fine-tuned this code even more to take better care of situations where the ad server is running in time zones with a positive offset from UTC. We thank community member Victor (Rhapsodyv) for this contribution to the project. We would like to ask members of the community to test delivery of contract campaigns. Of course, we would welcome any feedback on any of the other changes, improvements and fixes as detailed in the release notes below.

How to test this beta release?
Version 3.2.0-beta can now be downloaded and tested by the community.
The purpose of the beta testing phase is to allow users and developers to thoroughly test the new version before it will be released as a stable version. If the beta testing phase proceeds according to plan, we intend to publish the official version 3.2.0 two weeks after the beta release.
We recommend that users do not upgrade their existing ad server installations if it is mission critical, or if they are uncertain about their abilities to deal with bugs, upgrade issues, or other unexpected problems.
Please make sure to study the release notes below, including the notes on non-backwards compatible changes.
What’s New in Revive Adserver version 3.2.0-beta?
Version 3.2.0-beta of Revive Adserver does not include any security updates.
We have included the following new features and improvements:
Added new Javascript based asynchronous tags. Added new help dialogue for companion positioning option. Integrated (most) translations with Crowdin. Added plugin hooks to the VAST events in the VideoAds plugin. Added preliminary support for PHP7. Version 3.2.0-beta introduces a number of non-backwards compatible changes:
Fixed issue with interstitial images (e.g. close.gif) always using http:// even when the request came via https. Fixed issue with interstitial layers showing even when no matching banner was found, since the introduction of blank logging. Fixed issue that prevented the error message screen to be displayed when trying to install or run Revive Adserver with some required functions disabled via php.ini. Fixed issue causing campaign revenue to be improperly parsed when using a number format different than nnnn.nn. Fixed a problem with the destination URL not being available for new overlay video ads, and potentially other HTML-based custom banner types. Fixed the size of the search popup window under Chrome. Fixed missing translation string from statistics screens for conversions. Fixed issue preventing contract campaigns to reach their daily target when TZ had a negative offset. Fixed a problem with “Export Statistics to Excel” not working on some platforms. Version 3.2.0-beta introduces a number of non-backwards compatible changes:
The signatures of bannerTypeHtml/Text’s preprocessForm() and processForm() methods has been updated to what was actually used when invoking them. Albeit unlikely, this might clash with the definition used in some custom plugins. The full list of changes included in version 3.2.0-beta can be reviewed on the project’s Github pages.
Download, install and upgrade
Revive Adserver v3.2.0 Beta is now available for download.
Once downloaded, please refer to the instructions for Installations of Revive Adserver or for Upgrading Revive Adserver. Make sure that the server(s) being used meet the minimum technical requirements.


View the full article

Thanks for the input… for reference to the community, this is what I ended up with:
 
First a little background. We use an automated deploy system that utilizes the Ruby on Rails Capistrano gem. It allows us to store a specified number of versions of the site code on the server and, if necessary, roll back a deploy to a previous version. Using this system effectively means defining which 'stuff' should be held in the git repository and which stuff isn't necessary or too dynamic to be tracked. Revive Adserver seems to have been designed to be managed more through manual manipulation of the files via FTP therefore the documentation doesn't really cover our conundrum. 
 
In the Capistrano deploy system, the site account directory contains a releases directory, a shared directory, and a symlink of the site docroot that links to one of the releases. Capistrano manages building symlinks from any of the shared directory contents to the release, so file uploads and other dynamic content gets stored in the shared directory on the server. When the deploy script is run, the script downloads the latest version from the repository to a new, date-coded directory inside the releases directory then resets all the symlinks such that the new release is now connected to the appropriate shared content. It then deletes the oldest release from the releases directory. 
 
Through some careful monitoring of directory contents and a bit of trial and error, we ended up doing the following: 
We moved the core contents of www/images to our shared directory and symlinked the whole directory We symlinked var/cache We symlinked var/templates_compiled All of the directories noted were added to our .gitignore file so local changes wouldn't be captured or added to the repository. 
 
This is pretty much the advice shared by Mr. Foley (thank you VERY much by the way), but differs slightly pertaining to the var directory. The var directory also contains the primary config file and some text files that seem to indicate the state of the installation. We felt that they should be part of the repository in case the project is moved to another developer. Having access to those conf files also makes it easy to set the software up in another environment; by simply duplicating a .conf file and find/changing the domain name and database info we've found Revive Adserver is extremely portable from environment to environment. I currently have this installation running locally, in production and in a staging/test environment. 
 
Anyway, hope this helps someone some day… 

Hi Paul,
 
Easy on the ! please...
 
To answer your question: In the invocation code, instead of adding "&source=15", just add "&type=15". See also http://www.reviveconsultant.com/articles/how-to-dynamically-insert-an-affiliate-id-into-a-banner/ for a variation on this topic.

Targeting channels are related to delivery limitations but they have nothing to do with this question.
 
You need to add the site variable to the SPC code line:
 
<script type='text/javascript'><!--// <![CDATA[
var type = '02';
// ]]> --></script><script type='text/javascript' src='http:  //  www.example.com/www/delivery/spcjs.php?id=1&amp;target=_blank'></script>
 
becomes:
 
<script type='text/javascript' src='http:  //  www.example.com/www/delivery/spcjs.php?id=1&type=15&amp;target=_blank'>
 
That's all.

I installed 3.1.0 and so far it looks very sweet. Banners appearing fine, admin and stats. functionality all there, (from what I've seen so far). Looking very good. Just thought you might like to have a positive feedback for a change
 

The same here, i don´t know how to create a plugin for revive. 

Please review the upgrade instructions at http://www.revive-adserver.com/support/upgrading/
 
You will have to make sure all files and all folder and sub folder and all files inside those have the correct permissions. If they don't then the upgrade wizard will not let you continue.

We have developed many different types of filters. I choose not to disclose them here but we can catch proxy clicks, vpn, some bots, fast clicks, and much more. Catching impression fraud is difficult but not impossible. We focus more on the click fraud side of things because we are a CPC based ad network only (at this time). But have flirted with the idea of adding CPM but would need the anti fraud tools in order to keep it under control.
 
Has anyone started or developed filters to catch fraud and if so are they shared? If not then this is something that needs to be created so other members who have limited knowledge or do not have a developer at their side can benefit from others experience. Even for a fee to get these plugins it would be worth it. I have to talk with my lead developer about Revive and the development of such plugins.
 
Thanks
Jim