Popular Post mstuart Posted January 6, 2014 Popular Post Report Share Posted January 6, 2014 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 well 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 Its 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 youre 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 Revives 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. Its 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. Richard Foley, King of Ads and fritzgreen 3 Quote Link to comment Share on other sites More sharing options...
Dragonia Posted June 6, 2015 Report Share Posted June 6, 2015 An alternative to creating a password level protection to the admin folder would be to block all access to the admin area to all except for a few ip address. This would be in a file called ".htaccess" (or in the httpd.conf) in the www/admin folder It would look something like this <IfModule mod_rewrite.c> RewriteEngine On #####IP Lockdown to prevent Unauthorised access from unauthorised IP RewriteCond %{REQUEST_URI} !/www/admin/unauthorised.html RewriteCond %{REMOTE_HOST} !^your\.ip\.addr\.ess RewriteCond %{REMOTE_HOST} !^your\.ip\.addr\.ess RewriteCond %{REMOTE_HOST} !^your\.ip\.addr\.ess RewriteCond %{REMOTE_HOST} !^your\.ip\.addr\.ess RewriteCond %{REMOTE_HOST} !^your\.ip\.addr\.ess RewriteRule $ /www/admin/unauthorised.html [R=404,L] </IfModule> Explaination This requires the mod_rewrite to be enabled RewriteCond is the condition in which you will be redirected to the rule Remote host is the ip ! - signifiys not this ip address and the rewriterule is to a page to display as a result. The pros: You are whitelisting ip addresses that can have access. This works well if you have a fixed ip in an office/home. If you have a dynamic address though, then you would need to read documentation on the rewrite rule to see if you can include a dyndns in wome way. I have not found out how to do this successfully yet. The cons: You could inadvertently lock yourself/or other uses out. Probably not good for everybody using this. Potential I guess you could mask the fact that adserver is even installed if you did something with referers but if you have many there again, won't be feasible for everyone. Quote Link to comment Share on other sites More sharing options...
Neurogami Posted July 5, 2016 Report Share Posted July 5, 2016 (edited) Is there a way to enable logging of sign-in attempts (both good and bad)? I want a log file to use with fail2ban to lock out bad actors. Update: Since Revive offers no built-in logging for admin access I added a few lines myself to log failed attempts. Edited July 31, 2016 by Neurogami Updated info Quote Link to comment Share on other sites More sharing options...
Neurogami Posted July 31, 2016 Report Share Posted July 31, 2016 I run fail2ban to check logs fro a number of sites I host. There is constant URL sniffing, where I see attempts to access files with names such as admin.php, administrator.php, and the like. That the typical software installation uses common, well-known names is a problem. For one app (a different ad server) I renamed assorted files; I could then watch for 404 errors on failed attempts when bots tried to find files. The renaming preocess was qite tedious; I had to check all the app files and careful rename hard-coded references to assorted admin pages. I'm thinking of doing the same for Revive. Any ideas on the down-side to doing this? What I really want to do is change the path "www/admin" to something else. Then have fail2ban look for any attempt to access files using the wrong path. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.