Jump to content


Approved members
  • Content Count

  • Joined

  • Last visited

About mstuart

  • Rank

Recent Profile Visitors

768 profile views
  1. 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. Where do others go to get their list of bots to block? Thought it might be useful to offer a list here to refine over time. I offer a starting point - any amends welcome. googlebot Googlebot-Mobile Googlebot-Image bingbot slurp msnbot Adidxbot blekkobot teoma ia_archiver GingerCrawler webmon httrack webcrawler FAST-WebCrawler FAST Enterprise Crawler convera biglotron grub.org UsineNouvelleCrawler antibot netresearchserver speedy fluffy jyxobot bibnum.bnf findlink exabot gigabot msrbot seekbot ngbot panscient yacybot AISearchBot IOI ips-agent tagoobot MJ12bot dotbot woriobot yanga buzzbot mlbot yandex purebot Linguee Bot Voyager CyberPatrol voilabot baiduspider citeseerxbot spbot twengabot postrank turnitinbot scribdbot page2rss sitebot linkdex ezooms mail\.ru discobot heritrix findthatfile europarchive.org NerdByNature.Bot sistrix crawler ahrefsbot Aboundex domaincrawler wbsearchbot summify ccbot edisterbot seznambot ec2linkfinder gslfbot aihitbot intelium_bot facebookexternalhit yeti RetrevoPageAnalyzer lb-spider sogou lssbot careerbot wotbox wocbot ichiro DuckDuckBot lssrocketcrawler drupact webcompanycrawler acoonbot openindexspider gnam gnam spide web-archive-net.com.bot backlinkcrawler coccoc integromedb content crawler spider toplistbot seokicks-robot it2media-domain-crawler ip-web-crawler.com
  3. Spot the muppet - holds head in shame - the wizard wants the absolute path to the existing install, not the path relative to the server root. No idea why I was so sure the relative path was required, trawled through InstallController.php to discover my school boy error. Too much coffee!
  4. I've upgrading openx many times over many years, but tonight whist trying out a test upgrade from OpenX 2.8.11 to Revive 3.0.2 I've been presented with an error message I've never see before: "One or more plugin files couln't be located, check the install.log file for more information" My upgrade workflow is very similar to that given at revive-adserver.com, create a new DB, copy over config, edit config with new DB name, check permissions etc, etc - nothing at all unusual. Worth mentioning that a previous test upgrade from OpenX 2.8.11 to Revive 3.0.1 was successful, I know since there has been some tweaking to the wizard and its handling of plugins due to the disabling of plugins issue. The upgrade wizard recognises an upgrade and proceeds normally until the penultimate stage when it asks for the path to my previous install, (I don't recall this field not being autofilled before - perhaps i'm wrong), I give the path, (the current working install of openx), proceed and the error message above is shown. Edit the path, (add a trailing slash etc), and the same error is shown. The applicable section of install.log shows the problem: Starting file-check for plugins... Plugin: openXBannerTypes - Unable to locate XML files Plugin: openXDeliveryLimitations - Unable to locate XML files Plugin: openX3rdPartyServers - Unable to locate XML files Plugin: openXReports - Unable to locate XML files Plugin: openXDeliveryCacheStore - Unable to locate XML files Plugin: openXMaxMindGeoIP - Unable to locate XML files Plugin: openXInvocationTags - Unable to locate XML files Plugin: openXDeliveryLog - Unable to locate XML files Plugin: openXWorkflow - Unable to locate XML files Plugin: openXVideoAds - Unable to locate XML files Finished file-check for plugins The adserver is being installed on a dedicated server, currently running openx 2.8.11 with no problems. If I roll back the attempted install and try and repeat the same error is displayed. A quick search for the *.xml I think the wizard is looking for returns the following results within the root folder of the version of OpenX i'm upgrading: ./plugins/etc/oxHtml/oxHtml.xml ./plugins/etc/oxText/oxText.xml ./plugins/etc/openXBannerTypes.xml ./plugins/etc/Client/Client.xml ./plugins/etc/Client/etc/changes/Client_upgrade_1.0.2.xml ./plugins/etc/Geo/Geo.xml ./plugins/etc/Site/Site.xml ./plugins/etc/Time/Time.xml ./plugins/etc/openXDeliveryLimitations.xml ./plugins/etc/ox3rdPartyServers/ox3rdPartyServers.xml ./plugins/etc/openX3rdPartyServers.xml ./plugins/etc/oxReportsStandard/oxReportsStandard.xml ./plugins/etc/oxReportsAdmin/oxReportsAdmin.xml ./plugins/etc/openXReports.xml ./plugins/etc/oxCacheFile/oxCacheFile.xml ./plugins/etc/oxMemcached/oxMemcached.xml ./plugins/etc/openXDeliveryCacheStore.xml ./plugins/etc/oxMaxMindGeoIP/oxMaxMindGeoIP.xml ./plugins/etc/openXMaxMindGeoIP.xml ./plugins/etc/oxInvocationTags/oxInvocationTags.xml ./plugins/etc/openXInvocationTags.xml ./plugins/etc/oxDeliveryDataPrepare/oxDeliveryDataPrepare.xml ./plugins/etc/oxDeliveryDataPrepare/etc/changes/changes_tables_oxDeliveryDataPrepare_002.xml ./plugins/etc/oxDeliveryDataPrepare/etc/changes/schema_tables_oxDeliveryDataPrepare_001.xml ./plugins/etc/oxDeliveryDataPrepare/etc/changes/changes_tables_oxDeliveryDataPrepare_001.xml ./plugins/etc/oxDeliveryDataPrepare/etc/changes/schema_tables_oxDeliveryDataPrepare_002.xml ./plugins/etc/oxDeliveryDataPrepare/etc/tables_oxDeliveryDataPrepare.xml ./plugins/etc/oxLogClick/oxLogClick.xml ./plugins/etc/oxLogConversion/oxLogConversion.xml ./plugins/etc/oxLogImpression/oxLogImpression.xml ./plugins/etc/oxLogRequest/oxLogRequest.xml ./plugins/etc/openXDeliveryLog.xml ./plugins/etc/openXWorkflow/openXWorkflow.xml ./plugins/etc/openXWorkflow.xml ./plugins/etc/vastInlineBannerTypeHtml/vastInlineBannerTypeHtml.xml ./plugins/etc/vastInlineBannerTypeHtml/etc/changes/schema_tables_vastbannertypehtml_013.xml ./plugins/etc/vastInlineBannerTypeHtml/etc/changes/vastInlineBannerTypeHtml_upgrade_1.8.5.xml ./plugins/etc/vastInlineBannerTypeHtml/etc/changes/changes_tables_vastbannertypehtml_013.xml ./plugins/etc/vastInlineBannerTypeHtml/etc/tables_vastbannertypehtml.xml ./plugins/etc/vastOverlayBannerTypeHtml/vastOverlayBannerTypeHtml.xml ./plugins/etc/oxLogVast/oxLogVast.xml ./plugins/etc/vastServeVideoPlayer/vastServeVideoPlayer.xml ./plugins/etc/videoReport/videoReport.xml ./plugins/etc/openXVideoAds.xml Before I start digging, or report as a bug, I thought it worth asking if anybody encountered this issue before. Thanks,
  • Create New...