Jump to content

mstuart

Approved members
  • Content Count

    4
  • Joined

  • Last visited


Reputation Activity

  1. Upvote
    mstuart got a reaction from Richard Foley in 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.   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.
  2. Upvote
    mstuart got a reaction from fritzgreen in 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.   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.
×
×
  • Create New...