Recent Posts

Pages: [1] 2 3 4
1
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
10.0.0.3 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 
more
2
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:

NVR

IP Address: 192.168.1.2
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:

Options:

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:

http://192.168.1.2


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
internally.

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).
3
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.
4
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.
5
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 nite, on the database cluster, using a full mysql dump.

Quote
root@db1 10:49:39 > /data/BACKUP/db # find ./ | grep vh
./[CLIENTNAME]
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-22-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-26-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-23-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-24-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-27-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-25-localhost.db.gz
./[CLIENTNAME]/[CLIENTNAME]-MySQL-db-2016-11-28-localhost.db.gz

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:
Quote
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.
I prefer (well insist) the backups be kept on separate disks/locations etc.

Looks like you already have some backups getting cut on your own:

I think really you just backup the site before work is done (like client changes) and let our backups do the rest.

You're at 1.2G of storage now, which is not bad ... but over half of that is just backups:
Quote
du -sh /var/www/[CLIENTNAME]/backups/
755M   /var/www/[CLIENTNAME]/backups/

If [CLIENT NAME] wants 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:
Quote
root@vs3 10:52:18 > /var/www # find [CLIENTNAME]/backups/
[CLIENTNAME]/backups/
[CLIENTNAME]/backups/files
[CLIENTNAME]/backups/files/1480345342.zip
[CLIENTNAME]/backups/files/1475001754.zip
[CLIENTNAME]/backups/database
[CLIENTNAME]/backups/database/1477667989@@[CLIENTNAME].sql.zip
[CLIENTNAME]/backups/database/1480345326@@[CLIENTNAME].sql.zip
[CLIENTNAME]/backups/database/1475001736@@[CLIENTNAME].sql.zip

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

root@vs3 10:52:27 > /var/www # ls -alt [CLIENTNAME]/backups/database/1480345326@@[CLIENTNAME].sql.zip
-rw-r--r-- 1 www-data www-data 556997 Nov 28 10:02 [CLIENTNAME]/backups/database/1480345326@@[CLIENTNAME].sql.zip
6
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.
7
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.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
8
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 Wordpress.org 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.
9
ADVANCE NOTE: Richweb has enabled and implemented the SRS feature on our SmarterMail mail servers. For more information about this, please visit: http://www.openspf.org/SRS

Many people want to take advantage of "email forwarding" in which a mail server auto forwards an incoming email to an email address on that local server to a different domain on a remote server. Oftentimes a user will have an ISP email address (Comcast or Verizon, for example), a free mail address (like Gmail, yahoo or Hotmail/MSN/Outlook) and a work email address. Instead of checking 2 or 3 different accounts the user will setup forwards for 1 or more accounts into an account that he/she will check, often times via a mobile device.

This is an extremely bad practice, and it is technically a broken model for multiple reasons which will be covered below. The proper way to do this (get email from multiple different accounts with different providers) is to setup a pop3 or imap pull of email from one mailbox.

For example, suppose our user has 2 email accounts: bestrealtor88@yahoo.com and bella.swan@bestrealty.net

Bella has had her yahoo account for 8 years and gets most of her email from that account and she has her smart phone programmed to check her yahoo account.  Instead of setting up her Bella.Swan@bestrealty.net account to FORWARD email to her yahoo.com account she should:
 
  • a. setup her smart phone to check both accounts;
  • - OR -
  • b. setup her yahoo account to login to her bestrealty.net account and PULL her email via pop3.
To understand why this is the case first we need to understand how email forwarding works.

If Bella were to ignore our advice and forward Bella.Swan@bestrealty.net to her yahoo account, what might happen?

If Edward.Cullen@friendlyvampires.net decides to send Bella an email to her Bella.Swan@bestrealty.net about an important contract, Bella would expect to get the email in her yahoo.com inbox, however she ALSO expects that the email will come FROM Edward.Cullen@friendlyvampires.net and NOT Bella.Swan@bestrealty.net, when she looks at the email in her yahoo account.

So the email system that operates bestrealty.net email services essentially has to impersonate friendlyvampires.net when it FORWARDS the email to yahoo.com so that the FROM header is set correctly.

Meanwhile, Edward has had a problem with Spammers impersonating his domain when they send spam. His service provider setup an SPF (Sender Permitted From) record in DNS so that only the friendlyvampires.net email servers are listed as authorized senders of email fromfriendlyvampires.net.

The yahoo email servers will pay attention to this SPF record whenaccepting email for Bella at her yahoo account. The yahoo servers may decided to block or score as spam the forwarded email because the emails servers for bestrealty.net ARE NOT listed in the SPF record as authorized senders for email coming from @friendlyvampires.net.

Clearly Edward cant contact each of the thousands of people that he emails and add any possible servers that might forward said emails he sends to anyone and add SPF records for each possible forward.

This is why the combination of an email forward and a source (SENDING) domain with an SPF record ALWAYS breaks. For source domains that DON'T use SPF records, the forwards may work (but generally be scored as more likely to be spam) so end users get confused. Bella seems to think the problem is with Edward, since "everyone else can send me email" but the problem actually lies with Bella.

Lets look at another problem that forwarding causes:

Lets say Rosalie has the domain test.com. Rosalie sets up an email forwarder for Rosalie@test.com to forward to her Rosalie2@hotmail.com.

The email service provider that runs test.com though has a big problem. Rosalie expects that ANYTHING sent to Rosalie@test.com is forwarded on - does the provider attempt to forward ALL email including all the spam that she has been getting lately, or does ittry to filter the SPAM? Since Rosalie is only using the intermediate email as a forward, she does not login to that account to set her spam settings, or check her spam folder most likely on a regular basis. The only reason she wanted to forward her email was to have only 1 mailbox to check. Having to manage spam settings on multiple mailboxes and track down where spam is trapped (if a legit message was snagged in a filter) defeats the whole purpose of the forwarding for Rosalie.

Lets say Rosalie get 10 valid emails a day on average. For most email addresses and/or domains that have been use for more than a year 10 SPAMs coming in for every legitimate email. This means that thetest.com email server is going to actually have to forward 100 additional SPAMs a day to Hotmail or some lesser number depending on how much they can filter out.

Of course the Hotmail Mail Firewall sees this behavior (100 SPAMs aday from the same sending machine) and quickly blacklists (refuses ALL messages from) the test.com email server. Not only is the email server that runs test.com seen as a SPAMMER, test.com is now seen as a SPAM SOURCE. This means that the reputation of both Rosalie's domain and her service provider is damaged - not good for Rosalie OR the operators of the mail server she hosts her test.com domain at. Rosalie can always get a new domain or try to get her domain off the blacklist, but for the company that operates the mail servers that host her domain the blacklisted ipv4 addresses of the mail server could cause thousands of mails to be dropped or delayed and many hours to sort out with many customers and domains affected.

Additionally, if Rosalie has setup a catch-all email address -i.e. @test.com so that sales@, info@, jules@, etc all work and go toher Hotmail account via a forward then we all have an even bigger problem. If a SPAMMER tries a dictionary attack against test.com - sending hundreds or thousands of emails to made up addresses @test.com then the test.com email service provider will be forwarding ALL of those messages on to Hotmail, which will have the server blacklisted within minutes.

Suddenly Rosalie stops getting ANY email into her Hotmail account thatshe expects from her forwarded account. Who does she call?

Well, she will be lucky if she can actually get anyone from a large ISP(Verizon/Comcast/Embarq, etc) or large mail provider (Hotmail, Gmail, Yahoo) to talk to. And even if she could she would get the no problem here, must be on the other end response, because as far as that provider is concerned, all they are doing is saving her the headache of getting an additional 110 SPAMs a day (her 100 SPAMs plus the 10legit emails).

Remember, when one individual user tries to deal with large companies that process millions of emails an hour, its impossible for them to really care or worry much about a few legit emails that get blocked. Blocking the massive SPAM inflow is much more important, because if their customers get thousands of SPAMs each day, they would simply not use and/or pay for their service.

So next Rosalie calls the provider of test.com to investigate the problem on their side. The answer she will get is: "no problem here,we see that Hotmail.com is blocking our attempts to send email". The provider may or may not be able to get Hotmail.com to take action and fix this. More often than not, this is very time consuming for the providers to track down a human on the opposite side that is able to fix the problem.

So email remains broken, or in a state of flux(sometimes works, sometimes does not, depending on whether Hotmail removes the blacklist after a period or not, and depending on how much SPAM comes through the auto forward).

Finally, to avoid the forwarding of SPAM mess discussed above. most providers (if they have any clue at all) will fully SPAM filter all email BEFORE its forwarded, so they avoid getting blacklisted for forwarding SPAM. This means that an email will take the following path:
SENDER :: FORWARDER_FIREWALL :: FORWARDER :: RECIP_FIREWALL :: RECIPIENT
Either of the 2 firewalls - FORWARDER or RECIPIENT can possibly rejecta message due to it matching:
 
  • SPAM or SPAM-like content (often the case if you forward off color jokes, or other chain letter type email)
  • VIRUS or SPYWARE
  • DANGEROUS file names or file contents (like a "cool" screensaver you found)
  • LARGE FILE ATTACHMENTS (multiple photos for example)
Each of the firewalls will have different policies (support FORWARDING firewall allows 20 MB attachments, but RECIPIENT firewall only allows5 MB attachments because its a FREE ACCOUNT!)

Troubleshooting where the email was blocked wastes the time and resources of each provider (FORWARDING and RECIPIENT) neither of which will be sure where the problem really is unless they investigate manually, which generates zero profits, only costs for the providers.

Many web hosts are now banning email forwarding to third party email accounts, removing the capability all together. And the result for these hosts is a serious decrease in spam complaints against their servers. Richweb does not ban email forwarding just yet, but it is inevitable that for most providers that forwarding email externally is just too much trouble, and the benefits to everyone by turning it off, far outweigh any benefits of having this so called "feature".
10
EDIT: Attached to the bottom of this post is Google's Search Engine Optimization Starter Guide. If used properly, it can provide you with valuable insight towards bolstering the SEO strength of your website.

Before we get into the details, we want to share two companies that we have worked with, and have referred customers over to, regularly. We do not favor one company over the other (they're both incredible groups of people to work with). It's also important to note that both companies are headquartered in Richmond, VA.

Net Search Direct (Ask for Jason McClellan)
Big Oak, Incorporated (Ask for Shell Harris)

Please note: We do not receive any commission from either company.  We have mutual customers and are happy to work with both companies. When contacting them, make sure you let them know you were referred to them by the Richweb team, please.

The answer is "Yes" and "No". Yes, by way of our suggestion of utilizing the Yoast SEO Wordpress Plugin. Let me explain a little bit more in detail.

The "No" part of this question:
The Search Engine Optimization process is one that requires an ongoing process to update your site regularly, while staying on top of the ever shifting trends, rules and guidelines by various search engines (Google, Bing, Yahoo, etc). A good SEO campaign takes about 4-6 months to implement to get your site properly indexed and moving up towards the first three pages of search results. In some markets (such as Real Estate), it's a monumental task due to the sheer number of competitors in that industry.

Getting your site listed on the first three pages of a search engine doesn't happen overnight. There are a lot of little things these SEO professionals have to tweak, consistently, while reviewing reports on your site's current traffic patterns.

Richweb doesn't have a dedicated person (or team) that is fully versed on these ever changing metrics. Partially because it can be time consuming (taking our resources away from day to day operations of a site), and partially because it requires having people on staff with in-depth knowledge of the requirement changes that can shift from one week to another. In many cases, we will refer customers out to a third party company that specializes in Search Engine Optimization.

We've seen cases where one method of optimization was valid yesterday, and is no longer valid today. Search Engines, themselves, have to constantly stay on top of their own game, so that they don't serve up a ton of spammed results when you're searching for XYZ.

Because of the fickle nature of Search Engine Optimization, this is (generally) not a low cost industry. We've seen some companies charge as low as $1500 per year, to as much as $3000 every three months for these changes to be made. It is an "uphill battle", at times, to stay at the top of your game when it comes to Search Engine Optimization Professionals.

The "Yes" part of this question:
That being said, there ARE a few things we can advise our customers to do, which will help get your site listed a bit better. Here's a list of items you/we can do:

SSL Certificates: Search Engines, last year, started "favoring" sites that ran exclusively under an SSL Certificate. It's sort of like "you've paid for your site to be `verified'... but what this is actually telling Google, Bing, Yahoo and others is that you've invested in your site, both financially, and with work. Most sites that are build for spamming keywords and descriptions will not extend the financial cost of running their sites under SSL Certs. Do keep in mind that these individuals/organizations frequently put 20-100 sites up overnight to try to spam search engines and get their stuff listed above legitimate sites like yours.

Richweb's suggestion: Get an SSL Cert!  We offer SSL certificates for $195 (three year SSL Cert) and can handle the entire process for you/on your behalf. Please note that there is an additional $2/mo or $20/year charge for putting your site on a dedicated IP (required for SSL Certs).

With or without the "www": It doesn't matter if you run your site with or without the WWW in the URL. My personal preference is to run it without the WWW. What you want to pay attention to is that your hosting provider redirects any incoming web requests for the "other URL" over to your primary one. If your website's URL is http://MaAndPasKettleCorn.com, you'll want to make sure that anyone that types in http://www.MaAndPasKettleCorn.com is automatically redirected over to the URL without the "www". Otherwise, Search Engines will see this as two separate sites with exactly the same content and "penalize" you for it.

Richweb's suggestion: Run your entire site under one and make sure your web traffic is being redirected over from the other one. We can do this very easily and effectively without any changes on your part. You just need to let us know if you want your site to run with or without the "www" in the URL.

Use the "Yoast's SEO Plugin" if running Wordpress: This is a bit of a tough one to address. The developers of this plugin often push out an update every 7-10 days, because of the little nuances centered around Search Engine Optimization (see below). Once you learn how to work with this plugin, it'll add maybe an additional 5-10 minutes of work any time you make a new post or create a new page. It's a *very* powerful plugin which does an incredible job of staying on top of SEO standards (guidelines). You just need to remember that the Green Lights are a very good thing... so you want to get as many of those as you can.

Richweb's suggestion: Use this plugin... heavily. Read the SEO section below each post/page entry and get as many lights green as you can. You'll have a better chance of successfully getting your site SEO optimized!

Is your website Mobile Friendly (Responsive)?: This is a HUGE one to pay attention to. Breaking its usual pattern of silence about changes to how its Search Engine Algorithms are handled... Google, last year, started warning website owners that, unless their website was Responsive, site owners would be penalized in their search engine rankings. Make sure you're using a website theme/template that is responsive.

Richweb's suggestion: Unless otherwise told by you, we're going to select a theme for your website that is responsive. You have to specifically tell us that you do not want a respolnsive theme if you don't want one.

Site Maps, Site Maps, Site Maps!: Are you using a Site Map? Yoast's SEO Plugin comes with one... but if you're not using that, you need to look at getting one situated for your site, whether manually done (there are websites that will generate them for you) or whether you have one programmatically created. You need to have one that's ready to go, no matter what platform your site runs under.

Richweb's suggestion: If running Yoast's SEO Plugin, you'll be situated with a Site map. Otherwise, we can create a site map for you, manually, or via custom programming, or via a plugin (if running Wordpress, Joomla, Drupal or another CMS).

Register for a Webmaster Tools account: Any SEO work done will almost always guarantee that you need to register for a Webmaster Tools account. Thankfully, these tend to be free (though some do offer paid upgrades). You'll need to have these situated ahead of time, so that you can monitor how people are finding your site and adjust accordingly.

Google: https://www.google.com/webmasters/tools
Bing: http://www.bing.com/toolbox/webmaster
Yahoo: https://siteexplorer.search.yahoo.com/mysites

Richweb's suggestion: Get yourself situated on all three, but don't submit your site for indexing just yet. Let Richweb finish everything off for you. Simply provide your login credentials for each of the above and we'll take care of the rest... especially if you're running Yoast's SEO Plugin (do you notice a recurring theme here?)


Let's get SOCIAL: Social Media really is one of the biggest and (in most cases) FREE resources you can take advantage of when it comes to promoting your site. Just remember one thing: It's SOCIAL Media... meaning that you should interact with people that ask questions or provide feedback based on your own updates to the various platforms. Twitter, Facebook, Instagram and Pinterest are some of the best resources available for you to grow your presence.

Richweb's suggestion: We have a few customers that are using "Social Networks Auto-Poster" Plugin by NextScripts, which automates posting your content to a myriad of Social Media platforms. They have free and paid versions available. It can take about an hour or two to fully integrate this into your site and train you on how to use it properly, a bit longer if we set up the Social Media accounts for you.

By implementing most, if not all, of the items above, you'll be on your way to getting your site indexed a lot deeper into search engines. Just remember, this isn't an overnight process, and by no means is this a complete list of things you can/need to do.
Pages: [1] 2 3 4