Do You Need Extra Protection for WordPress?

Extra Protection for WordPress: Reflected XSS

This is a question I hear quite often. People will ask me what I think about various popular WordPress security tools such as Sucuri, WordFence, etc.

My honest answer is that while such services can offer great value for a specific set of users, depending on the kind of hosting services you are using it might be pointless to have them, and that the money you would spend on such subscriptions might be better spent elsewhere.

I am probably getting way ahead of myself by stating that as far as WPX, I honestly think you don’t have to bother any sort of third-party security tools. So let me explain my position.

First, I need to talk a little bit about the threat model against WordPress websites in general.

 

Table of Contents

Application and Server Level Attacks

Most WordPress website operate on the ‘open’ Internet. This means that by design they are freely accessible from everywhere and by anybody. They run open-source software (the WordPress core itself; plugins, themes), which anybody can examine.

There is a vibrant community of experts who do code reviews and safety tests, and most issues these days are caught before they can cause any damage. But the unpleasant group of people who prefer to look for exploitable faults and keep their discoveries to themselves still exists.

Because the specifics of such exploits depend on the software platform, these threats can collectively be named ‘application level threat vectors’. They work by letting an attacker plant some nefarious code that will then get served to unsuspecting users along with the content they have requested.

Such code can run will local permissions inside the browser and change the page contents or even hijack the entire user session. The attacker might end up taking over the victim’s account with that website.

Attack Types: Reflected XSS

WordPress runs on what is called a “web stack”: a combination of a web server software and a few services stacked on top of it, such as database engine (MySQL, MariaDB) and a scripting language interpreter to take care of active content (PHP).

Sometimes a server-level attack will attempt to exploit specific server behavior, or cause a glitch in its operation with the intent to create an information leak.

Example Server Exploit Attack

Because the common link between the attacks against this stack is the data-leaking server, the second threat vector can be called a ‘server level threat vector’.

User Credentials Reuse

The third way to compromise the security of a WordPress website is to attempt login using leaked or stolen credentials from breaches at other services, and/or trying multiple combinations until successful.

Protection against this is really, REALLY simple: just don’t reuse passwords, ever. Password managers exist for a reason. Password guessing is easy to detect and block on either platform or server level.

User Credentials Reuse Attack

The commonality between those attack types is that they generally attempt to breach known points and use identifiable patterns. An apt analogy would be that of a burglar’s attempt to enter a house by trying either the front or back door lock, window locks, and other possible entrances via the basement or the attic/roof. 

Similarly, effective protection relies on placing cameras and alarm triggers on specific places inside the house. A successful breach would require the unlikely simultaneous failure of several different detectors (door/window open sensors, vibration or glass breaking sensors, IR camera movement registration…), and this is how active protection against this kind of exploits works in principle.

User Behavior Dependent Attacks

The fourth way to compromise WordPress security is by luring or convincing the user to manually install software of unknown origin (cracked or nulled themes and plugins) that carry some sort of payload that can compromise the server on which they are installed.

This approach is different than the others because here it could be more difficult to spot suspicious patterns in behavior, as it is sometimes hard to spot what and how has been altered in a back-doored plugin or theme.

Using Nulled Themes or Plugins

Fortunately, this one is also the easiest to prevent: just make it a principle to never use cracked or nulled software. Period.

There is a variation of the user-dependent attack vector: the case when a website gets hacked because of outdated, unpatched versions of the WordPress core, or third-party themes and plugins. Do not ignore updates, especially when they are clearly marked as including security fixes.

It is excusable to postpone updates that carry functional updates or changes, because these might need extensive testing, but when the changelog mentions a security patch or something similar, drop whatever other task you have at hand and just press that ‘Update’ button.

Network-Based Attacks

The final way to compromise a website is to simply try to take it down using a DoS (denial of service) attack. In these attacks, the objective is not to gain access to the website itself, but to prevent it from working for everybody else.

DOS Attack Example

An attack directed against a single website is a nuisance for the hosting provider, because it disrupts normal operations and degrades the quality of service for their other customers as well. It also irritates upstream network providers (the companies from which the hosting company buys internet connectivity wholesale).

DoS attacks usually succeed by making it economically infeasible for the hosting service provider, or even for their upstream network provider, to carry the particular website under attack. This is the network-level attack vector.

How to Defend Oneself Against All of This?

A good security solution would need to be able to:

  • prevent block platform-level and server-level penetration attempts by either detecting known exploits, or by identifying patterns that suggest illicit behavior
  • prevent repeated attempts at password guessing and other exploitative patterns that are otherwise difficult to distinguish from normal user behavior (e.g. somebody slightly forgetful who always needs several attempts to key in their WordPress admin password)
  • periodically scan and identify code-level exploits caused by users who did something stupid such as installing a nulled plugin or theme, or left their software outdated
  • prevent network-level attempts at causing denial of service

Because of the way these kinds of attacks are spread over the connectivity spectrum, it is impossible for a local (as in, integrated with your website) solution to handle all of these tasks together. It needs some outside help.

Competent web hosts are constantly taking measures to defend their customers against all possible attack vectors. This is the perfect time to take a slight detour and talk about the way WPX.net actually protects their web infrastructure, and your website(s).

I want to thank Alexander Tihov, Sysadmin Team Lead at WPX for answering my questions about OpSec patiently and in great detail.

How WPX.net Protect Their Customers

WPX.net employ a multi-layered protection schema that is specifically configured to accommodate the hybrid nature of their service (a network of origin locations that operates along a second overlay network of edge/caching servers).

Let’s have a look first at the most ‘boring’ type of attacks: those who intend simply to take down a website via DOS/DDoS (denial of service/distributed denial of service) attacks.

DOS/DDoS Protection

At the time of writing, WPX.net have 3 data centers: in USA, Europe and Australia. For each of these origins, WPX have a SLA (Service Level Agreement) with a carefully chosen DDoS mitigation services provider: Path.net (USA), Voxility (UK) and 5gnetworks.au (Australia). The DDoS mitigation protection can protect the WPX origin datacenters against multi-million packet per second attacks.

But that is not all: if you have enabled the WPX bespoke XDN caching service, which is available free of charge to all WPX customers, you benefit from another layer of resilience on top of origin server protection. 

Every XDN PoP (point of presence) — of which there are no less than 40 as I am writing this, and that number is expected to keep growing — has similar kind of protection at data center level as the origin PoPs. Moreover, the XDN network works in such a way that if any edge location goes off-line for whatever reason, end-users will not even notice: they will keep receiving content from another nearby edge server.

This is possible because the WPX XDN uses anycast: a special mode of the IP routing protocol which allows multiple different servers to respond as if they own the same IP address. The traffic for each site visitor is routed towards the geographically closest WPX PoP.

Because of the properties of IP anycast, every DDoS attack is automatically mitigated by a factor of 40× simply because every hijacked computer or IoT device harnessed to overload the hosting web server will hit a different edge location.

Application and Server-Level Protection

DoS/DDoS attacks can take down a website, but they can’t usually cause data damage or loss. Application and Server-Level attacks however have a much greater potential for damage, and must be treated with great care. 

The WPX.net security team employs a range of different instruments to defend against attacks towards their hosting servers and the WordPress applications running on top.

Since about 2017, WPX hosting servers run LiteSpeed Web Enterprise Server — the most modern web server software available today. One of the security features of LSWE is built-in support for the industry-standard web application firewall (WAF) called ModSecurity.

ModSecurity began its life as a module for the venerable Apache web server whose job was to inspect the incoming HTTP requests and responses, and compare these against a (Real-time Blocking List).

Gradually, ModSecurity evolved into two components: a server-specific module that performed the filtering tasks, and a common format for sharing rulesets about known vulnerabilities that should be blocked.

Examples of ruleset providers are OWASP (a non-profit organization), Immunify360 (for-profit enterprise), TrustWave (for-profit enterprise) and many others.

Comparing every incoming HTTP request against a huge list (the latest copy of the OWASP ruleset contains more than 500KB worth of rules) is a very CPU-intensive process. The developers of LiteSpeed Web Enterprise Server are particularly proud with how fast their in-house written ModSecurity engine handle traffic filtering.

WPX have ongoing subscriptions for several ModSecurity rulesets and also maintain a separate list of rules for unsafe code in WordPress themes and plugins identified by the WPX security team in the course of investigating security incidents.

These rulesets are updated several times a day and propagate among all WPX servers across all data centers. This means that as soon as a vulnerability is discovered in one website, and a blocking/patching rule get published, all customers’ websites get to immediately benefit from it.

The efficiency of the server rule matching engine is compounded by the fact that all offending traffic is immediately blocked for all WPX customers. This would be impossible if each customer used a separate block list and did not share the results with the rest of the swarm. That is why all 3rd party WordPress protection tools also operate remotely and need to route your traffic through their networks, causing unnecessary delays.

Brute-Force Attacks Protection

If you have ever created a WordPress site from within your WPX.net Client Area, you will have noticed that without having to do anything special, you will be presented with a special reCaptcha page upon login. Once you solve that reCaptcha, you can work undeterred for a long time, and perform multiple log-off/log-on operations without ever seeing another reCaptcha message.

Only if sufficiently long time has passed, or if you try to open your website from another device, will you see the reCaptcha page again.

This safety feature is nice to have, but the WPX security team have improved on that idea. Every failed reCaptcha solve is registered and in case such failures exceed a pre-determined limit, or there are indications that the traffic source is a bot (e.g, requests arrive at a very quick rate, or there are multiple failed requests from the same IP try to log into multiple unrelated WordPress sites), that IP address gets blocked for a specific period of time at network level — it gets added to the inbound router’s block table and future request get dropped without even going inside the WPX network.

In other words, the reCaptcha protection operates in self-reinforcing way. It does not treat individual websites in a vacuum but instead collects behavioral information and when it detects abnormal behavior, it preventively blocks the offender from reaching ANY of the websites hosted by WPX.net

Ah, and it also makes automated attempts at ‘credentials stuffing’ somewhat impossible. Even if you have used the same username/password combination on another website and it leaked them in plaintext, WPX.net will not let the hacker to start trying the combinations before they solve the captcha first.

Protection against User Behavior-based Attacks

These attacks are more difficult to recognize, because it is not always possible to detect what code the user uploads within their accounts, or whether a specific type of operation is performed for legit or nefarious purposes.

Also, false alarms need to be brought down to a minimum, because repeated cases of misidentified actions train users to ignore signals and reduce trust in the system’s overall ability to prevent breaches.

But even here, the hosting servers are configured in such a manner that all eventual negative consequences from any specific user’s inconsiderate actions would only reflect onto him/herself.

WPX uses ClamAV with several paid 3rd party detection lists to perform daily automated scans that will detect most common malware heuristics like the use of  base64_encode, base64_decode, serialization, eval() and other PHP functions associated that hackers frequently use to transfer illicit data.

In case some high-impact exploit is announced, the security team will quickly patch the definitions ruleset and then perform an out of schedule scan, just to be sure that nothing has passed through.

At the time I am writing this (June 2022), WPX are in the process of implementing ImunifyAV+ in their workflow. This tool will give an incredible boost to the productivity of the malware cleanup team, because it allows single-click cleanup of every infected file.

In the unlikely but not impossible case of a runaway infection caused by a “0-day” vulnerability, automated cleaning will make recovery many times faster for all WPX customers that have been affected.

The (Im)practicality of Local 3rd Party WAF Tools

I am certain that even after taking the panoramic tour around the WPX security model, some of you might still feel tempted to add some ‘local’ and ‘lightweight’ form of protection, just to get that extra bit of safety.

Here are at least three reasons why this is not a good idea.

Any protection tool is as good as it its most current ruleset. A local ‘firewall’ application needs to stays updated. Are you always online and ready to press that ‘Update’ button?

Firewalls work by comparing incoming each and every request against a RBL (Real-time Block List). This is a time-intensive task and your web host usually keeps 1 or 2 CPU cores allocated specifically for that task. Once a bad actor has been detected, it gets blocked at network level. Further requests from that IP address will get dropped at the doorstep of the web host’s network, and all customers will be safe from that particular attack.

If you run a RBL locally, you don’t have any of these luxuries. Checking every request against your block list will add many milliseconds to every request, and will consume your own resource allotment. Even the blocking mechanism of the local firewall is less effective: the malicious requests will keep coming and keep getting dropped at server level. An unsuccessful attack will therefore still degrade the quality of your service and will induce delay in the loading of every page.

This is why no modern 3rd party WAF service operates on a single server. Each security software replicates the model that WPX uses, because it is the most efficient one. Every WAF intercepts traffic on application level, but blocks it on network level.

However this means that you need to ditch the free and performant WPX CDN network that is optimized for both speed and security, in order to get protection from a different CDN network that will presumably be only optimized for security. If you ever see a WAF that advertises itself as the fastest in terms of page loading speed (not inbound traffic analysis speed, or threat detection speed!), please let me know. I would love to put their claims to the test.

What Do 3rd Party WordPress Protection Tools Actually Do?

“OK”, the good old sceptic in you concedes, “I understand why a local WAF is pointless. But how about all of these popular WordPress security tools that everybody is talking about? Surely they are experts in the field of IT security and should be offering ‘more’ of it?”

Sure, let’s check the websites of several WordPress security tools that have established themselves as good online security solutions, and see what each one of them promises to do. Where possible, I’ve copy/pasted text directly from a vendor’s site.

Sucuri Web Application Firewall

Price: $19.98/mo (the $9.99/mo tier is useless because it does not support SSL).

Virtual Patching and Hardening
If a security patch is released, but you can’t update your site, it becomes an easy target for hackers. We constantly update patches and server rules to protect your site.

✔ This is the very same thing WPX does for you when adding new rules to the RBL either automatically, or by hand.

Block DDoS Attacks
Avoid downtime with our global Anycast network and web application firewall (WAF). Patch vulnerabilities and block threats with our WAF’s intrusion prevention system.

✔ This is the very same way WPX protects you. Do you need another CDN on top of your XDN? Also note how in the second sentence they repeat the previous claim.

Protected Pages
Add another layer of protection to sensitive pages by enabling the Protected Page feature. Add passwords, CAPTCHA, 2FA (via Google Authenticator), or IP allowlisting.

✔ WPX protects your login pages by default without you having to do anything. You can add a plugin to enable 2FA via Google Authenticator, hardware keys, etc. “IP allowlisting” is just a line in a .htaccess file

IP Allowlisting
Allowlisted IP addresses ensure that only your team can access website administrative areas. Restrict your admin panels so malicious users don’t gain access.

✔ Again, repeating the previous claim about IP Allowlisting. This is something that you can do yourself, or ask a WPX support tech to help you. This shouldn’t be something to pay for!

Application Profiling
Each site has its own CMS, server software and other unique technolgies in its stack. We analyze all traffic requests to block those that don’t fit your web application’s profile.

✔ This means they use different RBL lists depending on the website platform. WPX do the same except they support a single platform: WordPress. No need to support Prestashop or Magento on a WordPress-optimized shared hosting service, right?

Signature Detection
All HTTP/HTTPS web traffic is inspected before reaching your server. With heuristic and signature-based techniques, we block malicious requests and attack patterns.

✔ This is the job of ModSecurity. This claim basically repeats what all previous claims say.

Sucuri Malware Removal & Security Protection

Price: $199.99/yr or $299.99/yr or $499.99/yr depending on how fast you want your website taken care of. Reaction times should be taken with a grain of salt, because the Malware Removal SLA says ‘Ticket response time is an estimate and resolution time may vary based on complexity and volume of tickets in our queue.’

Advertised functions: same as for the previous package, with added ‘unlimited’ malware & hack removal as insurance. WPX do that for you, for free. They, too, do not give guarantees about how long it will take to remove the malware, simply because there can always be an epidemic caused by some 0-day that is keeping their whole support staff busy. But at least you will have someone to talk to, and WPX support agents respond live within 30 seconds on average, not via tickets some 30 hrs / 12 hrs / 6 hrs later.

WordFence

Available plans: Premium ($99/yr) — Care ($490/yr) — Response ($950/yr)

Common features (all plans):
Malware Scanner: Real-time signatures (same for WPX)
Real-Time IP Blocklist: yes (same for WPX)
Country Blocking: yes (WPX do not offer this)

Extra features for Care ($490/yr) and Response ($950/yr):
Security Audit & Recommendations: once a year (WPX do not offer this)
We Monitor your Site Security: WPX do that for free.
Investigation and Malware Removal: WPX do that for free.
Post-incident Blocklist Removal: I don’t think WPX will do that for you. But then again, how many blocklists do you know of, and are you sure WordFence knows them all?
Post-incident Search Engine Security Cleanup: WPX do that for free.
Detailed After-action Reports: WPX will do that upon request.

Extra features for Response ($950/yr):
24/7/365 Incident Response: Yes. WPX SecOps and Support run 24/7/365 as well.
1-Hour Response Time: WPX aim for 30-seconds initial response time. That’s 120× faster!

Additional plugin functions (all plans):
Plugin/Theme Vulnerability Monitoring: WPX will not do that but you can with a free 3rd party tool (see here).
File Change Detection: WPX will not do that. Nice to have.
Intrusion Alerts: WPX will not send notifications, but you could do that with a 3rd party tool.
Rate Limiting: WPX have that.
Brute Force Protection: WPX have that.
Login Security – 2FA & RECAPTCHA: WPX have smart reCaptcha (explained above) and you can add 2FA via plugin.

iThemes Security Pro

Available plans: for 1 site* ($80/yr) — for 1 sites ($127/yr) — Unlimited** ($199/yr)

* Single-site license allows use on a separate dev/staging copy. This is actually nice.
** It can’t be really ‘unlimited’. There must be some kind of easily reinforceable limit check, because otherwise the whole internet would be served via single $199 iThemes package.

Stops automated attacks:
Brute force attacks refer to the trial and error method used to discover usernames and passwords to hack into a website. WordPress doesn’t track any user login activity, so there isn’t anything built into WordPress to protect you from a brute force attack. iThemes Security Pro works to secure and protect the most attacked part of your website, the WordPress login, by blocking these automated attacks.

✔ Yup, same does WPX.

Monitors for suspicious activity
iThemes Security Pro keeps track of important security events that occur on your website. These events are important to monitor to indicate if or when a security breach occurs. The information found in these records can be used to lockout bad actors, highlight an unwanted change on the site, and help to identify and patch the point of entry of a successful attack.

✔ I honestly don’t know what those ‘important security events’ are, and what records are being kept. It sounds a bit too much like ad copy and too little like factual information. Also, I really don’t like the ending: ‘help to identify and patch the point of entry of a successful attack’. As if, all of these important security events can’t prevent the site from being hacked. Ah well.

Strengthens user credentials
The iThemes Security Pro plugin offers several layers of user security enhancements, such as strong password requirements, two-factor authentication, and password-less logins. These important user security measures decrease the likelihood that a privileged user account can be exploited to successfully hack into a site.

✔ Same can be achieved using free 3rd party plugins. There is nothing inherently difficult about it.

Scans for vulnerable plugins and themes to apply updates
The iThemes Security Pro Site Scanner is our way to secure and protect your WordPress website from the number one cause of all software hacks. The Site Scanner checks your site for known vulnerabilities and automatically apply a patch if one is available.

✔ Same can be achieved with a combination of ‘Enable Auto-updates’ from within any WordPress instance or via the WPX Client Area, and a 3rd party tool such as InfiniteWP to check & update those plugins that can’t update automatically.

Blocks bad bots and reduces spam
The reCAPTCHA feature in iThemes Security Pro protects your site from bad bots. These bots are trying to break into your website using compromised passwords, posting spam, or even scraping your content. reCAPTCHA uses advanced risk analysis techniques to tell humans and bots apart.

✔ Bot filtering and reCaptcha, got it. Same as WPX.

Automatically takes actions on your behalf to secure your site
One of the best parts of the iThemes Security plugin is the actions it will automatically take to secure your site. iThemes Security automatically locks out users, bans user agents and IP addresses, applies version updates, and more, all on your behalf.
✔ WordPress applies version updates on its own as well. WPX takes care of the auto-banning.

What These Tools Do, that WPX Doesn’t

If I am to be objective, I must mention that there are a couple of things that WPX protection does not offer. But a simple file update or a 3rd party tool can make up for it. Anyway, here are the 3 functions that I find useful, and what are the ways to add them (if possible).

Folder Hardening

There are certain folders within WordPress which do not generally require executable PHP scripts within them, such as:

wp-content\uploads
wp-content\plugins
wp-content\themes

What Sucuri does is add .htaccess files in each of these directories, with the following directive that prevents the server from executing PHP files within.


deny from all

When Alexander Tihov read this part of my column, he suggested that I talk a little bit about the downside of hardening. It turns out that this approach is simply not reliable enough. There exist many plugins that haven’t been coded to standard and for whatever reason require execution permissions outside of their own folder. Such plugins may break when folder hardening is enabled.

The less experienced the end-users, the less likely they are to realize that a plugin they have just installed will not work because of a security feature that had been activated many months ago.

This incompatibility ultimately becomes a liability for the web hosting company as it requires time to diagnose and resolve, while at the same time it also decreases reputation among less technical customers.

From the standpoint of WPX, this ‘pros vs cons’ math doesn’t come out positive. Based on their past and vast experience, hardening is a high-risk, low-reward compromise that they have decided not to add to their security solutions stack.

Added/Modified/Deleted Files Tracking

The WordPress Core, themes, and plugins follow a somewhat fluid structure, where it is not 100% necessary to follow a specific naming convention (exception made for themes). However what is generally not expected inside WordPress is to create or modify files inside a theme or plugin folder outside of an update cycle (and even then, very rarely, and only for new plugins that are under active development, or old plugins that are being refactored). Therefore, keeping a log of file/folder state is a good second-hand indicator of possible intrusion.

Core Integrity Check

Because WordPress is very popular and widely available, the source code files for its current and older versions are readily accessible via the two most popular version tracking tools:

Subversion: https://core.svn.wordpress.org/
Git: git://core.git.wordpress.org/

It is very easy to scan the WordPress core folders and create control sums for all files, and then to compare these control sums against the control sums of the files published in the official repositories. This is a very quick and sure way to detect changes to the WordPress core, and Sucuri are doing this.

In theory, the very same can be done for themes and plugins, but due to the sheer number of modules and themes available, this doesn’t seem feasible to do for Sucuri.

So… Is It Worth It?

I think you already know the answer to this one. Third party WordPress ‘security’ software can give you some extra peace of mind, but in practice it is not required in most cases.

Most of the ‘active’ protection performed by such plugins (the WAF functionality offered by WordFence, Sucuri et. al.) is already done for you at a server level, at a much faster speed, and without putting extra stress on the CPU limitations of your hosting plan (if any).

The things that WPX will not do (folder ‘hardening’, modified files tracking, WP Core files checksumming) might improve your security and allow for faster detection of malware, but are they worth it, when the first one you can do for free and the second one you can reproduce with a simple shell script that force-syncs with the latest WordPress core release from the official Git or SVN repo?

In Conclusion

“So, Ivan,” you continue your silent dialog with me, “does this mean that 3rd party security products are totally worthless?”

No, OF COURSE NOT.

All of these products, along with many others who have been building their reputation for a decade or more, are totally worthy — for a specific group of customers.

It just so happens that if you have selected a quality shared web host, you are not among the users who will benefit from the protection offered by the WordFences, Sucuris (Sucurii?) and iThemes of the world.

Web hosting companies (the good ones, anyway) care about their customers more than you probably think. They have every bit of motivation to predict and prevent most common problems before they hit you. Also, they have much bigger axes to swing than you do (unless you are willing to spend the same amount of money they do).

This, combined with the fact that everybody is using the same source data (RBL lists, vulnerability reporting, etc.) means that these tools are mostly the same. And if you get them for free (as in the case of WPX customers), you will not achieve significant security advantage if you pay more money for a subscription to a 3rd party service.

It is a simple as that.

What is needed of you in order to be a First-Class WordPress citizen is to follow several simple things:

  1. Keep your website(s) always up to date. Be religious about this.
  2. Do not touch pirated software.
  3. Do not reuse passwords, and add 2FA to protect yourself against theft of credentials.
  4. There is no number 4. There are only 3 rules. That’s it.

 

 

 

 

2 replies on “Do You Need Extra Protection for WordPress?”

Hi Hamza, I agree. The point I am driving in the article however is that sometimes it doesn’t make sense to throw more protection on top of the protection our websites receive at server level.

Most WAFs (web application firewalls) for example rely on the same set of filtering rules. So in theory, both I personally, and my webhost can have running subscriptions to receive the latest rule updates and apply them accordingly.

But I am a single person, and my webhost has a whole team that runs 24/7 to control if new rules arrive and if they are applied immediately. Even though we use the same data, my webhost is many times more efficient than I am at keeping their WAF up to date for all of their customers.

Every responsible webhost has some sort of protection in place for all of their customers on managed hosting plans. Some webhosts do a bad job of explaining what they actually do.

But customers share a little responsibility here as well — they should ask a webhost about the kind of protection that is provided, and make the response to that question an important part of the decision whether to move there or not.

Leave a Reply

Your email address will not be published.