Recent Posts

Pages: [1] 2 3 4
Wordpress version 5.0, anticipated to be released on November 19th, 2018, is coming with a brand new way to handle theme and plugin integrations/development, called Gutenberg.

Although Wordpress has advised theme and plugin developers of this new interface, there are still a lot of themes and plugins that may not be compatible with Gutenberg.  Thankfully, Wordpress will also provide a plugin for allowing us to disable the Gutenberg interface.

Due to the unique nature of everyone's Wordpress site here at Richweb, we cannot equivocally state "Yes, your site will be okay", or "No, this site will break if you enable XYZ".

As a result of this, we're asking all of our clients to hold off on any Wordpress updates.  Starting the day after Thanksgiving, we will begin working through each and every one of our customer's sites to upgrade to Wordpress 5.0, and either install the "No Gutenberg Interface" plugin, or to make sure that Gutenberg works correctly for your site.

We will absolutely take a backup of your site so that we can restore a previous version (prior to updates) or anything else you might need to have done with this upgrade.

Thank you!
Pre-Sales questions / Re: Customer Self-Backups and Richweb Backups
« Last post by Doug Hazard on December 03, 2017, 11:23:43 pm »
Our wordpress customers are hosted on our standalone vmwp nodes which is a quad core (full cores) vm with 10G of ram and typically a block of 8 to 12 ips and 12 to 15 sites.

Each vmwp node has a built in load balancer and content acceleration engine but the database is pointed at one of the MySQL storage nodes.

The vmwp nodes backup their content each nite to a replication server. This is all of the website files, images, php code, js and css files, etc - all media and code files.

Odd nites use an on site replica server, even nites are pushed to QTS for offsite backup.

Once a month a full snapshot is taken. We keep 2 months of snapshots.

The databases are backed up each nite (full snap) and pushed the same way - evens and odds. 10 days of backups are kept, and then monthly archives for 1 year are kept.

If you have need to recover old data its best to ask quickly, before backups are over-written. Recovering data from 6 months ago for example can be a challenge.

Full snaps of the filesystem web dirs are stored in: /data/BACKUP/content/

And can be uncompressed to fetch files as needed.

We can also ship backups to a customer ftp site if desired. And we can arrange for longer term storage of backups if needed, like plugging in the GlobalWeb RBS system for long term storage of file backups.
Maintenance and Network Updates / Re: Network Compliance Questions - open RDP
« Last post by jlarsen on April 18, 2017, 08:16:14 pm »
I see we also 
have rdp enabled:

pass in quick on $ext_if proto tcp from any to $fwip port 3390 rdr-to port 3389

Customers will (and have) gotten hacked with this setup. You then end up having a security 
risk if anyone has a weak passwd.

Just so you know - PCI compliance and other audits will fail if you have 
any open windows rdp on the ip they scan. If you have something like
citrix secure gateway (what UMFS ran) you can get away with that being   
open as long as the ssl security checks pass. But open rdp wont work any 
Maintenance and Network Updates / Security Cameras
« Last post by jlarsen on April 18, 2017, 02:17:34 pm »
We had a security guy here today. We are having an problem viewing the cameras from phones/devices according to our vendor the modem needs port forwarding.

The following info is what we have for the NVR (recorder) and cameras:


IP Address:
Need to do port forwarding for ports:
Server Port: 55115
HTTP Port: 80
RTSP Port: 10554

Note: The system can use tcp and udp for the non-http ports mentioned above. But first we need to look at the security:


1. I have the info I need to punch holes in the firewall on the rtr to restore the workings.

Pros: cheap

Cons: your vendor is a residential systems provider and they are not doing any kind of security updates on
your system. So if we open those ports up to the internet there is a chance that box can get hacked. Anyone that hacks that box will
have the ability to try to hack from the inside your pcs, servers, cloud, etc.

Note: YOU WILL FAIL YOUR SECURITY AUDIT IF THIS IS DISCOVERED. If you have to PCI/(credit cards) or do any other form of external
scan you will fail this scan and have to pay to have it fixed (i.e option 2 or 3 below):

2. Leave the ports closed, and vpn into the cloud to attach to the camera at:

Open a browser to this url next time you are logged in remote and see how it runs:

Pros: no work needed, very secure, camera vendor can have access as well if he needs to get in remotely. Audit-compliant

Cons: have to open a vpn client to do the work (1 more step)

3. Open the ports BUT also vlan/restrict off the system so that it can go to the internet but CANNOT touch any of your systems

Pros: audit-compliant, most secure

Cons: have to pay Richweb to make the changes and your vendor to re-ip his NVR and cameras -  this will prob. be a few hrs of
work for each team to complete and test.  grey is willing to do this (probab. would be good for us to teach him some new tricks if
he is going to work with commercial systems or else he can get into legal hot water).
Maintenance and Network Updates / Network Compliance Questions
« Last post by jlarsen on April 18, 2017, 02:16:16 pm »
Making sure your network is secure at all times.
Maintenance and Network Updates / Network Outage at Noon today (Status update)
« Last post by Doug Hazard on March 22, 2017, 06:06:30 pm »
Around noon a Richweb engr made an incorrect settings adjustment to the vlan allow list for the hyper-v cluster switch. This prevented internet and lan access from working properly for about 20 minutes until it could be discovered, and then it was manually corrected.

Storage was not affected. This was an operator error and not any issue with the hardware or systems.

The reason for the change(s) (frequency and timing) I will explain below. We are investing a lot of engery and money in our cloud to make sure that it offers excellent performance for our customers.

Some of the MS Windows memory settings as originally configured last fall were found to be sub-optimal and we are fixing that (requires a vm reboot) one by one, after hours.

In addition, Richweb has been wrestling with storage issues the past 2 months where VMs will disconnect from their storage. We are pretty sure the issue is a problem with Infrascale backups locking the VMs on a backup snapshot run and then not releasing them properly.

This can cause a whole host to hang in some cases, and require a reboot (we slide the vms to another host in the pool first of course). But its a problem when the vm manager does not agree with where the vms are running. In some cases the vms are turning themselves off when there is a conflict and then from the manager we are not able to correctly restart them. Needless to say, this is not acceptable and we are working on fixing this.

Actions taken/in progress:
We have disabled whole-vm snapshots+backups to test this scenario out. We are still running the backups of the data inside the vms and that is working fine. Its just the whole-snap level backup that seems to be causing a conflict.

Sunday morning at 6AM the storage array that handles some of the web and email hosting (san9) went down for about 10 minutes due to conflicts and contention and the same issue happened again at Monday at 820AM on a different set of vms and storage arrays.

san9 has been replaced (it was scheduled for upgrade anyway) but some of the details captured from the monday event are making it clear that this is likely the backup software that is breaking and not anything with our storage or hyperv cluster.

Since disabling the backups we have seen no storage conflicts (fights over who can read and write to a disk) whereas before we would see them every nite.

Richweb has 4 storage arrays for our cloud hosting:

san8 (new as of summer 2016)
san5 (brand new nfina array with enhanced caching - just purchased)
san11 (new as of fall 2016, rebuilt caching config in mar 2017)
san10 (original array, unchanged)

We have been making a large set of changes to the storage configuration over the last 2 months. 4 older arrays have been retired and 2 new arrays brought into service). In addition the performance on san11 as originally configured was not what it should have been so the hardware and software configs were rebuilt and its now working properly.

The pace of the changes should settle down now that upgrades are mostly completed.
Pre-Sales questions / Customer Self-Backups and Richweb Backups
« Last post by Doug Hazard on December 05, 2016, 11:09:35 am »
Believe it or not, this actually goes hand in hand with the "Richweb / Globalweb Hosting and MySQL Database Backups" post I've made.

We already backup the databases each night, on the database cluster, using a full mysql dump.

root@db1 10:49:39 > /data/BACKUP/db # find ./ | grep vh

We already backup the filesystem too - nightly rsync off site on even days and nightly rysnc onsite on odd days.

And there are 2 historical files - full tarballs - of the site kept as well  back 45 days or so:
2016-10-20_data_gwebvs3.tar.gz  2016-11-20_data_gwebvs3.tar.gz

My problem with php web app driven backups is they:
  • Write the backups into the web files, making the backups ever larger;
  • They never get deleted;
  • Rely on wget of a url to run, which means they run from the web process, which is shoddy (error prone), timeouts, etc; and
  • They can easily be deleted or damaged accidentally or intentionally via an  ftp client mistake.
We prefer (well insist) the backups be kept on separate disks/locations etc.

If you want an extra level of backups, you can setup a job to run once a month, and then have a script that logs in via ftp and pulls them back to your site if you want. We can create a script that pushes our backups to an ftp server of your choice too, just would take a little time to set it up.

Backups I see now:
root@vs3 10:52:18 > /var/www # find [CLIENTNAME]/backups/

root@vs3 10:52:21 > /var/www # ls -alt [CLIENTNAME]/backups/database/1477667989@@[CLIENTNAME]
-rw-r--r-- 1 www-data www-data 554256 Oct 28 11:20 [CLIENTNAME]/backups/database/1477667989@@[CLIENTNAME]

root@vs3 10:52:27 > /var/www # ls -alt [CLIENTNAME]/backups/database/1480345326@@[CLIENTNAME]
-rw-r--r-- 1 www-data www-data 556997 Nov 28 10:02 [CLIENTNAME]/backups/database/1480345326@@[CLIENTNAME]
Pre-Sales questions / Security of Internet Appliances
« Last post by Doug Hazard on October 06, 2016, 10:46:30 am »
In years past, embedded devices were programmed with very limited hardware (slow cpus, not much memory, and little storage) that tended to be very proprietary. If a device was intended to be a camera, or a copier, it was purpose built, in terms of its firmware (embedded software), to do just that task.

Even if an attacker could guess a password or exploit the unpatched firmware to gain access, it was very hard to modify the device to do anything other than what it was intended to do by the manufacturer.

Hardware appliances these days are very different in nature. Often, they are actually an embedded PC that runs a standard CPU, with plenty of memory, and storage that can be very useful for an attacker, like compact flash or even a small solid state disk. The manufacturers are building their products in software code that runs on top of what is basically a small, general purpose computer.

This is a VERY attractive target for attackers because the hardware can be easily modified to do many useful things for an attacker such as:

  • launch attacks on other systems;
  • launder (hide) connections to other systems for illegal activities;
  • denial of service attack victims on the internet;
  • launch further brute force break-in attempts on other computers; and/or
  • spy on the victim's local network and gather more valuable data to steal.
Busybox is a powerful program that packs the functionality of 60 to 100 popular utilities and commands into one single binary. BusyBox is often installed on these devices to allow developers and administrators to interface with the device. If an attacker can get remote access to a device Busybox makes it much easier to modify the system to suit the attackers purpose(s) above (and new ideas the attacker may consider/discover).

How to defend against this threat?

  • Don't install devices on your production network if you don't have time to administer (patch and monitor) them.  Consider putting the device on a guest network and disconnect the device when its intended purpose has come and gone, otherwise an attacker will find a NEW purpose for your forgotten device.
  • Password Safety:
    • Always change the password to a secure account.
    • Always record the password in a database or file that is regularly backed up / archived.
    • NEVER leave a device with its default password.
    Having passwords written on paper in an envelope in a safe is also a good backup. IT workers lose countless dolars/time each year on lost passwords.
  • Disable remote access to your devices, especially edge routers and firewalls. Your support vendor should have a set of static (NON-CHANGING) ip addresses that he/she will do remote administration from at all times.
  • Retire devices and disconnect them from your network if they are no longer supported by the vendor. Install vendor security patches for your device(s). If you can't for any reason, build a secure vlan to house your devices that cannot be secured via conventional methods.
  • Don't assume your home network is secure. For example, if your game console is hacked, then your entire home network can be at risk. Put your game console on a protected vlan or guest wireless network.
Pre-Sales questions / Richweb Wordpress Lockdown Plugin version history
« Last post by Doug Hazard on July 11, 2016, 09:59:53 am »
Starting with version 2.0, we will only keep the three most recent version notes inside the Richweb Wordpress Lockdown Plugin. The rest of the version history will now be posted inside of this thread.
Version 2.6 - November 8th, 2017
  • Fixed a timezone bug that was impacting dates/timezone issues with certain calendar / events plugins.
  • Removed version 2.3.2, 2.4 and 2.4.1 notes from plugin's "About" page (was put on forums in 2.5 update, but not removed from plugin version update details).
Version 2.5 - April, 2017
  • Moved RW WP Lockdown configuration from "Lock & Unlock" into a new "Config" tab.
  • Changed Theme error handling (it was providing an incomplete error report).
  • Removed duplicate theme checking. Wordpress improved theme handling, internally.
  • Changed "RW WP Logs" tab wording to "Lock Logs".
Version 2.4.2 - Dec 1st, 2016
  • Bug fixes and enhancements related to version 2.4.1 changes (Polling and remote locking).
Version 2.4.1 - Nov 10th, 2016
  • Bug fixes related to version 2.4 changes (Polling and remote locking).
  • Clean up of some un-needed HTML in version info.
  • Relocated older version history (4 entries) to the linked forum post (below).
Version 2.4 - Nov 1st, 2016
  • Added an API function to allow us to 'Poll' the status of users on the website (Online/Offline + Timestamp).
  • Added an API function to allow us to 'Lock' the website remotely.
  • Modified behavior on lock/unlock button functionality (now Javascript based).

Version 2.3.2 - September 21st, 2016
  • Implemented a check to see if CURL is installed. If not, provides directions on how to install it on every web server.
  • Fixed a missing image on the error/alerts tab.
Version 2.3.1 - September 7th, 2016
  • With the introduction of the database table in 2.3, I had to bump up the minimum supported Wordpress version from 3.4.0 to 3.5.0
Version 2.3 - September 1st, 2016
  • Implemented a logging feature to record who has locked/unlocked the site, recording their username, IP, the day/time and LOCK/UNLOCK status.
  • Minor tab and code adjustments.
Version 2.2 - August 2nd, 2016
  • Removed some unused functions (used in the past, but with recent updates, no longer needed).
  • Some additional PHP/HTML cleanup/tidying.
  • Combined the "About this plugin" and "Version History" tabs into a new tab called "About...".
  • Corrected an issue inside the CSS file with a typo on a class name.
  • Fixed a wording bug when locking/unlocking the site (Jacob Dunn identified this issue)
  • Relocated Wordpress Theme and Plugin error issues into its own tab. Provides better error handling, including paths to themes/plugins with issues.
Version 2.1.1  - July 29th, 2016
  • Improved error message display to show ALL issues at once, plus actual location of theme/plugin causing issues.
  • Corrected a PHP variable inside the error area (a Plugin error handler was using a Theme name handler.)
  • Due to improvements, version number update references were mislabled on line numbers. Now fixed.
Version 2.1  - July 18th, 2016
  • Enhanced error message section after you lock/unlock the site. This was a result of a few sites not properly locking down.
  • Added a "Text Domain" (slugname) entry.
  • Added the site's IP record (DNS Lookup) to both the Richweb Reporting utility, and to the "WP Version Info" tab.
  • Implemented an on-screen error check for Plugins & Themes having the same name under their "Plugin Name" & "Theme Name" (respectively) lines, causing issues while communicating with the Richweb Reporting system (which will return an error when locking a site).
  • Improved Error Handling/notification immediately when accessing the Plugin's main page. Errors that can stop successful reports to Richweb's Central reporting system will now show immediately for needed fixes.
Version 2.0  - July 12th, 2016
  • is_dir() returns an on screen warning if on screen errors are enabled. Now suppressing via @is_dir().
  • Added a Unique Site identifier for our new Customer Info Centralization system
  • Restructured information we're collecting for our central data system
  • Separating out the data we're collecting from the HTML output to provide better organization of the code internally. Improved documentation as a result.
  • Re-did the HTML layout for WP Version Info, so you know what data we're collecting for the purpose of being more efficient on updates.
  • Implemented and improved data submission tool into our central repository area.
  • Wording improvements to provide a more clear understanding about the primary nature of this plugin.
  • Fixed an unclosed HTML tag. Added WP_MULTISITE and NAME to the UNLOCK string.
  • Added links to "WP Version Info" & "Version History" to provide more info.
  • Changed button wording on Lock/unlock tab to provide better understanding of what each button does.

Version 1.9.1 - Oct 9th, 2015
  • On the file counter, the time estimate variables were flipped.
  • After working on a site that had over 57,000 files, we adjusted the time calculator/estimator.
  • Changed the position to the RW Lockdown link on the Admin menu to the top.
Version 1.9 - Oct 6th, 2015
  • Some features of 1.8 were inadvertently rolled back to 1.7 as a result of the emergency fixes in 1.86. Version 1.9 restores those features.
  • Added Server Hostname and Path to Wordpress installation under the "Need Help" section
  • Created JSON list of Core Wordpress info (version, theme info, plugin info, Richweb account status, etc) for a future Richweb Wordpress management feature. Output is commented out, for the time being.
  • Added file counters for Wordpress Directory.
  • Added a warning indicator if you have over 16,500 files in your Wordpress directory, noting approximately how long it will take to lock/unlock a site.
Version 1.86 - Sept 8th 2015
  • Emergency fix to a few parts of the plugin to allow it to integrate with the changes we made to the server-side Daemon. Emergency fix was inadvertently based off of version 1.7. Corrected and restored all features back in version 1.9.
Version 1.85 - Sept 4th 2015
  • Implemented additional security settings to prevent anyone from locking/unlocking a site they don't own/operate (MD5 Checksum checks)
Version 1.8 - June 1st 2015
  • Changed Admin Menu icon to indicate whether a site is locked or not. Now gives you a visual cue without needing to go into the RW Lockdown page itself.
  • Corrected Theme Counter under "WP Version Info". Was using incorrect variable name
  • Corrected one of the authors' name (changed "Dout" to "Doug")
  • Corrected a typo under one of the error messages ("Broken Pipe error message)
  • Added an Alert Icon to indicate potential configuration issues.
  • We now automatically update the Automatic Update Notification (AUN) system on each version update (in case the AUN system has an update itself).
  • We now tie in each Lockdown set up with a Richweb Client ID (needed for future Richweb Wordpress Lockdown Plugin features coming). We also strip out any HTML in this field for security reasons.
  • Enhanced security on a (now previous) potential concern between locking and unlocking the site.
  • Added Plugin name and Version info at the top of the Plugin itself.

Version 1.7 - May 6th 2015
  • Added an Admin Menu padlock icon.
  • Due to display issues on some sites, relocated Version History to within the Plugin itself, rather than externally.
  • Improved commenting within the Plugin itself to better identify what each section does.
  • Implementing an Update notification feature (requires one additional plugin - you'll see a notice for this at the top of the RW Lockdown page).
  • Added a readme.txt file to comply with WP Update guidelines and scripts.

Version 1.6 - May 3rd 2015
  • Modified Lock/Unlock form to indicate, visually, whether a site is locked or unlocked.
  • Implemented Wordpress style commenting (Per JD's request)
  • Implemented a lock/unlock image as well as the Richweb logo on all tabs.

Version 1.5 - May 1st, 2015
  • Added support for WP Multi-Site setup (Network Admin) functionality.
  • Added detection for whether Richweb's user account is present. If so, show email and account role.
  • Added detection for whether Wordpress installation is a Standalone or Multi-Site set up.
  • Added detection for Multi-Site set up and whether the Richweb User account is a Network/Super Admin or not.
  • Added "WP Version Info" tab.
  • New tab now includes Wordpress Version and current theme/version info.
  • New tab now lists all Wordpress themes and versions.
  • New Tab now lists all Wordpress Plugins, Versions, Activation Status (and if active AND MultiSite, Network Activation Status).

Version 1.4 - April 30th, 2015
  • Changed the layout of the Plugin itself.
  • Adjusted Plugin description to make it more readable.
  • Added "About" info on Plugin itself.
  • Provided ways to obtain support & more info.
  • Added Version History.
  • Modified the info on the forums to explain our Wordpress security a bit more in detail.

Version 1.3 - March, 2015
  • Updates to Description, Version, Author information and Author URI.
  • Added Version Tracking and Changes.

Version 1.2 - March, 2015
  • Changed the script to now allow for the Plugin to work from any directory Wordpress is installed in, rather than assuming that wp-admin is in the main root folder.
  • Cleaned up white space in script.
  • Reorganized HTML output to make this MUCH easier to see whether locked/unlocked (visual improvements)

Version 1.1 - March, 2015
  • Reordered the <label> part to ensure words are clickable for radio buttons to enable/disable

Version 1.0
  • Initial Development
With version 2.0's release of the Richweb Wordpress Lockdown plugin, we're introducing a brand new feature that will help protect your site a bit more, as well as allow the Richweb staff to work more efficiently in the near future.

Let me preface this with a note that we are NOT collecting any information on your site beyond the CORE Wordpress information, our "richweb" user account and information on themes/plugins. On your Wordpress site, under the "RW Lockdown" link to in your WP Admin area, under the "WP Version Info" tab, you'll be able to see the information we collect on your site, any time you lock/unlock your site.

I am attaching two screen grabs from my own personal site to show you the exact information we collect.

There's three reasons for this:

First Reason: We care about the security and safety of your website. When the Lockdown is in LOCKed mode, your site is virtually unhackable. In the near future, we will implement a centralized system that will identify any site that has been UNLOCKED for more than X amount of time (we're leaning towards four hours), we will automatically issue a command to LOCK your site down.  Keeping your site LOCKED is crucial to ensuring that you won't be hacked.

On June 9th, 2016, one of our customers unlocked their site, and inadvertently forgot to lock their site back down. Later that evening, the first stage of a site hack took place. On June 11th, the hackers then completed the rest of that hack, and used that one site to launch an outbound attack against several other sites, in addition to "seeding" the hack in multiple places on our customer's site. We received several abuse reports early on June 12th. It took us nearly 10 hours to clean up that site to stop the outbound attacks and to re-secure the site back to its normal operational state.

The site hack occurred literally within hours after a major security issue was identified with Wordpress version 4.5.2. It's important to note that (as of this moment), we still have several customers running 4.5.2, however, because their sites are locked, they are not at risk of being hacked/compromised.

To summarize: If we find a site that's been left in an UNLOCKED state after a period of time, we will proactively issue a command from our central server to lock that site down.

Second Reason: When it comes time to proactively perform updates, we literally have to log into each of our customer's sites to ascertain who needs an update and who doesn't. With the fact that we now collect version information on Wordpress, the themes and plugins, and then store that inside of a central database, we will soon be able to run a quick command on our database to see who's running what version of Wordpress, a theme or a plugin. We will then have a once a week (maybe more often) check against the servers to see if there are any sites that updates that need to be performed. We can then take that information, compare it to what's in our central database and then only log into customer's sites that need updates.

This will be a major time saving feature for Richweb, which will allow us to focus our time more wisely on tasks that aren't Administrative in nature.

Again, please review the two attached images below to see a sample of what we collect.

Third Reason: When a customer comes to us to manage their Wordpress based site, we often set up a user account by the name of "richweb". When a customer contacts us for assistance using the "wecare" email address, we currently have to do a password reset if we're not aware of what the current password is (usually set by one person on the Richweb team). When we do a password reset, it generates an email that gets sent to the entire Richweb Web Development team.

We now have a feature inside of our central database that allows us to store the passwords for our own account. In addition to that, we have the ability (by customer request ONLY) to store additional usernames and passwords, if desired. The password storage feature is NOT tied into your Wordpress system, so if a password gets changed on the site itself, it will not automatically update it on our side.

By storing the password for our "richweb" account, we can reduce the amount of emails our web team gets, and have easy access to view this information inside of our own infrastructure.

Some Final Notes:
It's important to note that no customer has access to the information stored in our central database, so you do not need to worry that someone outside of the Richweb team will see what you're running.

We've taken great pains to safeguard this information as much as possible.

This feature only works on a Richweb server. We may, in the near future, release a "Richweb Wordpress Version Info" plugin that will stand alone from the lockdown portion of the core plugin.
Pages: [1] 2 3 4