Day 24 - Site Security & Online Privacy

[SmokeTree]

Unless you have the luxury of a dedicated sysadmin or devops person, you'll be wearing the sysadmin hat from time to time. A good working knowledge of Linux and WordPress security will go a long way to help prevent you from finding yourself in the potentially costly and embarrassing position of dealing with a compromised server.

We'll be focusing on a shared server scenario with WordPress installed. With this type of setup, the hosting provider (e.g. GoDaddy, HostGator) is managing the servers and taking care of updating and patching the server itself as well as making sure it doesn't crash and burn. The only security you have to worry about in this case is the security of the WordPress install itself and any content you upload to the server. This in itself can be a great thing because you don't have to worry about the whole server, just your sites.

Assumptions

• You're all set up and ready to go with a shared server as @Ryuzaki talks about in Day 4 - Setting Up Your Site
• WordPress is installed, you know your way around a bit and have even installed a plugin or two
• You know how to use the file manager on your cpanel or an SFTP program. We'll be using this to change file permissions

Linux File Permissions

File permissions are the foundation of Linux security. In Linux, everything is a file, including directories. Each file has 3 permission groups and 3 permission types that, when used together, specify "who can do what".

The permission groups are:

• Owner/User : The owner of the file
• Group: The group assigned to the file
• World/Other: The rest of the world, such as website visitors

The permission types are:

• Read: Can read file. Represented by an "r"
  
• Write: Can write to a file. Represented by a "w"
  
• Execute: Can run a file as an executable. In the case of directories, this allows files within the directory to be listed. Represented by an "x"

File permission types are represented by numbers, with 3 numbers making up the "permission mode" for the file. The following illustrates how these 3 numbers are assigned to each permission type and how, added together, they form the permission mode.

Read (r) = 4
Write (w) = 2
Execute (x) = 1

When you view a directory listing of files on a Linux server (or Mac) you'll see something like the following for each file

-rw-r--r-- 1 wp-user wp-group 418 Sep 25 2013 index.php
drwxr-xr-x 9 wp-user wp-group 4.0K Aug 6 2014 wp-admin

The file permissions are that string of characters that look like "-rw-r--r--" in the beginning of each file. The first character is reserved for advanced permissions. For example, if the file was a directory, this character would start with a "d". If the file was a regular file it would start with "-". There are other advanced permission types such as symbolic links, but we'll focus on regular files and directories for now.

So back to the first file in the directory listing example. We have:

-rw-r--r-- 1 wp-user wp-group 418 Sep 25 2013 index.php

Which is a regular file because it starts with a "-". Then we have "rw-r--r--" which means the following:

• Owner can read (4) and write (2) to the file but not execute (rw-)
  
• Group can read (4) the file but nothing else (r--)
  
• World can read (4) the file but nothing else (r--)

We can say the first file has a permission mode of 644. Lets look at this file one more time but I'll use the following color coding for clarification

Owner (red)
Group (blue)
World (green)

-rw-r--r-- 1 wp-user wp-group 418 Sep 25 2013 index.php

• This is a regular file (starts with a "-") and it's named "index.php"
• The owner is "wp-user" and can read (4) and write (2) to the file. 4+2 is 6 which is the first number in the permission mode.
• The group is "wp-group" and can only read (4) the file and nothing else. 4 is the second number in the permission mode
• The world can only read (4) the file and nothing else. 4 is the third number in the permission mode
• The permission mode for this file is 644

Lets look at the 2nd file which is a directory. I'll color code again

drwxr-xr-x 9 wp-user wp-group 4.0K Aug 6 2014 wp-admin

• This file is a directory (notice the "d" as first character) and it's named "wp-admin"
• The owner can read (4), write (2) and execute (1) the file. Since this file is a directory, setting the "execute" mode will allow the owner to list files in the directory. 4 + 2 + 1 = 7 which is the first number in the permission mode
• The group can read (4) and execute (1) the file. 4+1 = 5 which is the second number in the permission mode.
• The world can read (4) and execute (1) the file. 4+1 = 5 which is the third number in the permission mode.
• The permission mode for this file is 755

Setting WordPress File Permissions

Now it's time to take what you've learned and ensure that the file permissions are set correctly for WordPress. Using your SFTP program or file manager on your cpanel, verify the permission mode for each file and directory. The parent directory that WordPress is in on your server will vary depending on which hosting provider you chose. Once you've found it, the following are the file permissions you will assign to each file and directory:

• Each directory should have a permission mode of 755 (drwxr-xr-x).
• Each file should have a permission mode of 644 (-rw-r--r--)
• The wp-config.php file should have a permission mode of 600 (-rw-------). This helps to prevent others (the world) from seeing your database password

Is there an easier way to set the file permissions for a WordPress install? Sure is, but you'll need to have a good understanding of the command line and also have SSH access enabled with your shared hosting IF they allow it. Working with the command line is outside of the scope of today's topic and will be something I'll be going into at a later time. Right now, it's good to learn the "cpanel" way of doing things because you'll more than likely be going with shared hosting until you're ready to move on to a VPS or dedicated server.

Also, please note that the correct file permissions might already be set for WordPress and if they are, great, that's one less thing to have to worry about.

If you'd like to do some further reading on Linux file permissions and more about how this works with WordPress, the following are great places to start:

• https://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions
• http://www.smashingmagazine.com/2014/05/proper-WordPress-filesystem-permissions-ownerships/

.htaccess file
What's .htaccess and why does it begin with a dot? The .htaccess file is a way to make actual configuration changes to the web server (Apache in most cases) as well as giving you the ability to block IP addresses, user agents (bad bots) etc on a "per directory" basis. It starts with a "." because files in Linux that begin with a dot are typically used for configuration purposes and won't show with a normal list command. They are also referred to as "hidden files". Many SFTP/SCP programs will show these files by default, others you'll have to configure to see the files.

The most common usage of this file is to place .htaccess in your website root folder and set up some rules in it. By doing this, all files and all folders that are inside the parent folder will have the rules applied to it and you have a "poor mans firewall" of sorts.

Let's say you have an IP address you want to block and the IP address is 123.45.67.89 You would put the following into your .htaccess file:

Order Allow,Deny
Allow from ALL
Deny From 123.45.67.89

Here's where things get a bit confusing. The first line, "Order Allow,Deny" is telling the server to process the "Allow" directives first, followed by the "Deny" directives. This is what's happening:

• User/Bot visits your site
• The "Allow From ALL" rule is matched first. At this point the User/Bot is allowed, but the show is not over yet because the server still needs to process the Deny rules.
• The "Deny From 123.45.67.89" rule is evaluated. If the IP of the user/bot matches the IP in the rule, we deny access to the site with a 403 (Forbidden) error
• If the IP of the user/bot doesn't match any Deny rule, the user/bot is allowed access

You can also block ranges of IP addresses. Lets say that after blocking 123.45.67.89 you see another bot log in right after that with 123.45.67.90 and another with 123.45.67.91. You may decide that you want to block the whole Class C of IP addresses (123.45.67.1 - 123.45.67.255) which might be overkill but we'll do this for demonstration purposes. Your .htaccess file would look like the following:

Order Allow,Deny
Allow from ALL
Deny From 123.45.67

All we had to do was leave the last octet of the IP address off and we're now blocking the entire class C. This is not something you'll want to do that often, but you can if you like.

Blocking IP addresses is all find and good, but how about blocking crawlers by their user agent. Let's say you don't want the Ahrefs service from crawling your site. You can put the following in your .htaccess file

BrowserMatchNoCase "AhrefsBot" badbots

Order Allow,Deny
Allow from ALL
Deny from env=badbots

There are other ways to block bad user agents using Apache's "mod_rewrite". Here's an article that covers most of what I've described and a few more tricks you might be interested in:
http://www.inmotionhosting.com/supp...-unwanted-users-from-your-site-using-htaccess

Tip: A quick word of caution about .htaccess If you have a lot of entries in this file, it WILL have an impact on your page load time and overall server performance. At that point, you'll want to look into setting up a VPS so you can put the rules in the main server config file. The reason .htaccess is slow is mostly because Apache has to read/parse the file with each request. That's why you are able to make changes to the .htaccess file and the rules will be applied the very next request. Here's the word from Apache on .htaccess
Source: https://httpd.apache.org/docs/2.4/howto/htaccess.html

"You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance."​

Principle of Least Privilege
The principal of least privilege is part of "computer security 101" (https://en.wikipedia.org/wiki/Principle_of_least_privilege). In a nutshell, it's all about only giving just enough access to a user or process to accomplish the task at hand and no more. Got a partner that only writes content? Give them "editor" access. How about people that do guest posts? Give them "contributor" access. Got a fly to swat? Use a flyswatter and save the nuke for warfare.

You should have only one admin account that you use to update WordPress, add/remove users, etc. All other users should have the "Editor" access level or below. This means your own personal account on the site should not have admin access. For more information on roles in WordPress, check out https://codex.WordPress.org/Roles_and_Capabilities

Strong Passwords
Ideally you want to go for passwords that

• Are a minimum of 12 characters in length
• Have a mixture of upper and lowercase letters
• Do not contain dictionary words
• Contain 1 or more symbols (e.g. !$%^#)

Plugins
When it comes to plugins, I'm a "less is more" kind of guy. Plugins alter the way WordPress works and the end result can be either good or bad. As a developer, you can create a plugin to do pretty much anything you need and make WordPress do all kinds of things it wasn't intended to do.

Think about that for a second. Plugins can be created to help make marketers millions, or they can be created to compromise your site security. Sometimes unskilled developers or even coding mistakes can open your site up to attack.

Every plugin you install should

• Accomplish something you have a real need for. It's far too easy to install every plugin under the sun, thinking "I might need this". Wait till you need the functionality, THEN install
  
• Have a decent "reputation" (rating). When you install a plugin, take a look at a few of the user reviews and note whether the users have a positive or negative experience overall. You particularly want to pay attention to any security related issues.

While we're on the subject of plugins, here's a well-rounded security plugin that will allow you to limit login attempts as well as a plethora of other security related things (too many to name here):
Wordfence: https://WordPress.org/plugins/wordfence/

Themes
As with plugins, take caution when installing themes. Not only can themes open up a site to attack, they can be just plain poorly coded/implemented, leaving you with a slow site. The "less is more" mantra applies here as well.

A good theme to start with is BuSo Lightning, created by BuSo's own, @Ryuzaki. Very light theme that's coded well and won't put your site in harms way as far as security goes: https://www.buildersociety.com/threads/buso-lightning-the-fastest-wordpress-theme.763/

Keep WordPress Updated
Since version 3.7, WordPress will automatically apply security updates. It is up to you to keep plugins, themes, etc updated. You can configure WordPress to automatically update plugins and themes if you like but for now it's a good idea to get used to logging in and keeping things updated yourself. If you'd like to read more about different configuration options for automatic updates, this will point you in the right direction: https://codex.wordpress.org/Configuring_Automatic_Background_Updates

The Next Level
Working with a cpanel is great (not really), but there is no cpanel in the world that can give you anywhere near the power that the Linux Command Line will. Does having the power of every programming language you could ever need at your fingertips sound sexy to you? Yes? No?

Maybe it would be better if I showed you what you're missing out on. How about a primer on the command line that will make your cpanel sing "baby come back"? Something that goes beyond the basics? And how about I throw in some server hardening tips for good measure? I'm going to bring you all of that and more, just not right now. I want you to know and understand the limits of your cpanel before I lift the veil for you and show you why I call the command line "The last cpanel you'll ever need". Be on the lookout for that. It might be out already, might not be. You'll know it when you see it

Now, stay tuned for my ramblings on "Online Privacy".

 

[SmokeTree]

In this topic, I'll be discussing ways that you can enhance your online privacy. You'll learn about various techniques that other websites use to track you and what you can do to make it more difficult for them.

Lets talk about the various ways you can be tracked, starting with your browser.

What other sites know about you​

When you visit a website, the server on the other end can access the following:

• Your public IP address (if not using proxy)
• Your browser's user agent (Browser version and Operating System)
  
• The referrer site (if you clicked through from another site)
• What browser plugins you have installed
• Screen Resolution
• Other details that can be gathered via JavaScript and browser plugins

IP Address
Unless you are already using a good proxy server, every website you visit will see your public IP address. With most home network setups, your desktops, laptops, and other things that connect to your wifi router or network will all have their own internal IP address (e.g. 192.168.1.2) and your router translates all that to a single public address assigned by your ISP. You can find your public IP address by visiting http://whatismyipaddress.com/

This means all the devices on your network are going to appear to be originating from the same public IP. It's your router's job to keep track of it all, but as far as websites are concerned it's all the same. Give it a try on your Desktop/Laptop, etc and you'll see they all originate from the same IP

The vast majority of websites keep logs of site visitors. Your IP is logged every time you post in a forum, pay a bill online, use Google (<- especially this one).

One of the biggest mistakes people make is trying to sign up for multiple accounts on forums and other sites under the same public IP and using these accounts to interact with each other. A common technique is when people use 1 account as a troll to spark something controversial and then use another account to appear "offended" and continue the fight. Sometimes several account are used like this to really stir things up. You'll notice these things pretty often in your online travels. Sometimes the most eloquent teacher is observation.

That technique is all fun and games till the forum admins and/or moderators start looking at the logs and seeing the same IP addresses. That's how accounts get banned. That IP is a huge part of how you are tracked.

There is a way to make it appear as if you are coming from a completely different IP address by using a proxy server or a VPN (Virtual Private Network) service. I'll talk about proxies in just a bit.

User Agent
The User Agent is a string that your web browser sends to a site as part of the HTTP Headers that identifies the browser name, version and the OS. For instance, for people running Firefox on Windows the User Agent might look like this:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

How about Chrome?
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

An iPhone?
Mozilla/5.0(iPhone;U;CPUiPhoneOS4_0likeMacOSX;en-us)AppleWebKit/532.9(KHTML,likeGecko)Version/4.0.5Mobile/8A293Safari/6531.22.7

This tells the site we're visiting a general idea of our browser name, version and our Operating System. The good news is this can be changed. For Firefox there is a very useful tool that will allow you to change your User Agent. You can get it here: https://addons.mozilla.org/en-us/firefox/addon/user-agent-switcher/

Changing user agents can be an eye-opening experience too. There are sites that implement a technique called "cloaking" where search engine spiders get shown a vastly different site than the site shown to "human" visitors for the purpose of ranking better in the SEPS. Using the User Agent switcher tool, you can change your agent to Googlebot or whatever user agent you like and see what the site looks like or to check to see if the site is blocking that particular User Agent.

Here's a great site that will help you analyze User Agent strings and also has a huge list of User Agent strings in use by pretty much every significant browser and crawler/spider you can think of:
http://www.useragentstring.com/

Browser Fingerprinting
Browser fingerprinting is a technique where information provided by a web browser is used to create a "digital fingerprint" of a web visitor's computer.

By taking bits of information gathered by using JavaScript and Flash (if you have it enabled), websites can get a pretty good idea of who you are. Maybe not your name, but your computer.

The way this works is analogous to how we describe people. If I told you to be on the lookout for a guy in a black shirt at a rock concert, that doesn't give you much to go on and probably describes about half the guys there.

Now, what if I were to say that the guy wearing the black shirt is also wearing a green baseball cap, has white sneakers and a tattoo of a pineapple on his right arm. Makes him a bit easier to find right? The chances of you finding 2 people that match the description are pretty low, probably next to zero.

With Browser Fingerprinting, JavaScript is used to gather various details about a visitor. The fingerprint consists of things like your User Agent (browser version, OS), Plugins Installed (Flash, Silverlight, etc) and various other details. When put together, you have a pretty unique combination of things that can be used to identify you.

How in-depth can things get? In some cases, even things like typing speed can be taken in consideration as well as mouse movements. The only limits are those of the JavaScript language and various plugins.

This website will show you just how unique your browser and configuration is. It's run by the Electronic Frontier Foundation (EFF), a privacy advocacy group.
https://panopticlick.eff.org/

If the topic of Browser Fingerprinting interests you, here are some links for further reading:
http://www.pcworld.com/article/192648/browser_fingerprints.html
https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy
https://panopticlick.eff.org/browser-uniqueness.pdf

Steps you can take to help smudge your digital fingerprint. ​

Use Multiple Browsers
I'm running Firefox, Chrome, Opera at any given time. For those of you on a Mac, Safari is a great browser as well. All of these can be configured to use a proxy server and are all very capable browsers. I've even heard of some people devoting certain browsers to certain forums/social media accounts and they keep those browsers configured with particular proxy servers to make sure that every time they use those accounts they are using that specific proxy.

Configure browsers to send "Do Not Track (DNT)" header
DNT or "Do Not Track" is a configuration setting in certain browsers that allows the browser to send a "DNT" header with the http headers to tell the websites we're visiting that we don't want to be tracked. DNT is analogous to the way robots.txt works. It's up to the site/service on the other end to honor the DNT header.

Setting this up can't hurt so I'll provide how to do this in Firefox. At the top menu in Firefox, select "Tools" then "Options". Once there, click the "Privacy" tab on the left and check the box that says "Tell sites that I do not wish to be tracked".

You can read more about DNT here: https://en.wikipedia.org/wiki/Do_Not_Track

Disable 3rd Party Tracking Cookies
When you visit multiple site that use the same ad networks (e.g. AdWords), those Ad networks can use 3rd party cookies to track you. This cookie is different than the ones websites themselves use to track your login via a session ID. In most cases it's a good idea to disable 3rd party cookies and thankfully that's easy to do. Go to the same screen you did to set the DNT header above and make the changes below in red.

Disable Flash
If you haven't already, disable the Flash plugin. Flash has a long history of security vulnerabilities and in certain cases can expose your public IP even if you are behind a proxy. If you really need to run Flash, consider setting it up per site in your browser settings so it only runs for sites you want it to.

Flash is a legacy technology that had its day. It is a leftover from the "Web 1.0" world. Here we have Alex Stamos, Chief Security Officer at Facebook tweeting that Flash needs to die:
https://twitter.com/alexstamos/status/620306643360706561

And here we have Mozilla disabling the Flash plugin for Firefox because of security issues:
http://thenextweb.com/insider/2015/07/14/firefox-rings-the-death-knell-for-flash/

About Google Services (Gmail, Google Drive, etc)
I could write a novel about how Google tracks, logs and builds profiles of people through the use of their various services. It all starts with search. People search for term after term, confiding in a search engine like it was their best friend.

Google is sitting there the whole time, logging info about your interest in clothes, cars, food and anything else you search for. Before you know it, just about every site you visit starts showing ads that look suspiciously like things you've searched for. That's because the ads ARE based on things you've searched for. Google has had years to learn how old you are, where you live, what your buying habits are and most importantly, where you would be the perfect target/victim for 3rd party advertising partners who would love to seduce the money from your virtual wallets.

Most people have a Gmail account and some even use it for their primary email address. One Google account ties you into all Google's services such as Webmaster Tools, Analytics, Gmail, Google Drive, etc. While you're logged into Google, your search history is logged to your account. Same thing goes for YouTube, which has been owned by Google for quite some time now.

Like to travel? Google Maps is a great thing right? You can get directions to anywhere you want to go. All you have to do is turn on location settings so the Google Maps service can know where you're at and give you guided directions to your destination, for a price. The price you pay is that Google logs the info about your trips.

Using Google Webmaster Tools to manage your sites definitely gives Google a pretty good idea that you either own theses sites, or you're affiliated with them in some way. Wouldn't you do the same if you were Google too?

If you're using Analytics or have used Analytics, you know that this means that Google pretty much knows who your visitors are and where they are coming from. There are alternatives to Google Analytics and one of them is Piwik (http://piwik.org/). This is a free Web Analytics software package you can install on your server and set up your own analytics platform. By doing things this way, you truly own your own data.

It goes without saying (almost), but it's definitely not a good idea to use your Gmail for things you would rather Google not know about, especially for any so-called "blackhat" sites/services.

Not to be paranoid here, but let's talk about Google DNS as well. If you use Google's DNS servers (8.8.8.8 & 8.8.4.4), guess who has a log of the sites your computer visits? For a DNS alternative, try OpenDNS, who is now part of Cisco: https://use.opendns.com/

By now you're probably ready for an alternative search engine to Google, one that doesn't track you. DuckDuckGo is a great choice: https://duckduckgo.com/

Use Multiple Email Addresses
With each domain you choose, you also have the capability of using the domain for email. By setting up email for each of your domains you now have additional emails you can use to sign up for social media, forum accounts, etc. Check your hosting provider for various email plans. You can use various apps such as Thunderbird (https://www.mozilla.org/en-US/thunderbird/) to keep track of various email accounts.

For those of you moving on to a VPS or Dedicated Server, you can also run your own email server with the capability of managing email for many domains. As with your website, the IP(s) of your email server is another way you can be tracked and the sites you manage exposed. Diversity is key.

Proxy Servers
A proxy server is an actual server on the Internet that you use and its job is to be the "middle man" between your web browser and the website or service you are visiting. With a good proxy server, the webserver at the the other end will see the IP address of the proxy server and NOT your public IP address. Some proxy servers will still pass the IP address of the origination point (i.e. your IP) in the form of headers such as "x-forwarded-for".

You want one that provides high-anonymity proxies which means that the service takes measures to ensure your public IP is not revealed. There are many proxy services out there and I can't recommend one over the other. A good start to finding one would be to pull up your favorite search engine and use the term "private proxy service". Ensure the provider offers "high-anonymity" proxies.

You can use the following link to help test proxy configurations:
http://whatismyipaddress.com/proxy-check

Github Alternative (*For advanced users only. Requires VPS)
If you are a developer and are using git for version control, there are a lot of times you have code you might not want on github. If you are running a VPS you can host your own git repositories, complete with access control with "gitolite". Just another way to take control of your own data: https://github.com/sitaramc/gitolite

Enable WhoisGuard
When you register your domain, make sure you enable "WhoisGuard" so that your name/address/phone isn't displayed when someone (or most likely a bot) looks up the domain. I'm a fan of Namecheap as my "goto" domain registrar and always include WhoisGuard when I buy a domain.

How does WhoisGuard work? I think it would be best to just show you an example of a site that has WhoisGuard enabled. Let's use a site we all know and love. How about we take a look at the "whois" for BuSo. If you are familiar with the command line on Linux or Mac you can run something like the following:

whois buildersociety.com

And this is what you'll see

Domain Name: BUILDERSOCIETY.COM
Registry Domain ID: 1859863590_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.enom.com
Registrar URL: www.enom.com
Updated Date: 2015-04-24T08:58:07.00Z
Creation Date: 2014-05-23T02:12:00.00Z
Registrar Registration Expiration Date: 2016-05-23T02:12:33.00Z
Registrar: ENOM, INC.
Registrar IANA ID: 48
Reseller: NAMECHEAP.COM
Domain Status: ok https://www.icann.org/epp#ok
Registry Registrant ID:
Registrant Name: WHOISGUARD PROTECTED
Registrant Organization: WHOISGUARD, INC.
Registrant Street: P.O. BOX 0823-03411
Registrant City: PANAMA
Registrant State/Province: PANAMA
Registrant Postal Code: 00000
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: BCE38CCE70CE4C5895FDF4C7B536E6CC.PROTECT@WHOISGUARD.COM
Registry Admin ID:
Admin Name: WHOISGUARD PROTECTED
Admin Organization: WHOISGUARD, INC.
Admin Street: P.O. BOX 0823-03411
Admin City: PANAMA
Admin State/Province: PANAMA
Admin Postal Code: 00000
Admin Country: PA
Admin Phone: +507.8365503
Admin Phone Ext:
Admin Fax: +51.17057182
Admin Fax Ext:
Admin Email: BCE38CCE70CE4C5895FDF4C7B536E6CC.PROTECT@WHOISGUARD.COM
Registry Tech ID:
Tech Name: WHOISGUARD PROTECTED
Tech Organization: WHOISGUARD, INC.
Tech Street: P.O. BOX 0823-03411
Tech City: PANAMA
Tech State/Province: PANAMA
Tech Postal Code: 00000
Tech Country: PA
Tech Phone: +507.8365503
Tech Phone Ext:
Tech Fax: +51.17057182
Tech Fax Ext:
Tech Email: BCE38CCE70CE4C5895FDF4C7B536E6CC.PROTECT@WHOISGUARD.COM
Name Server: NS1.BUILDERSOCIETY.COM
Name Server: NS2.BUILDERSOCIETY.COM
DNSSEC: unSigned
Registrar Abuse Contact Email: abuse@enom.com
Registrar Abuse Contact Phone: +1.4252982646
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
Last update of WHOIS database: 2015-04-24T08:58:07.00Z

See all those "WHOISGUARD PROTECTED" messages? This means that the pubic record for BuSo isn't divulging the real name, address, phone, email, etc of the owner. If you don't enable WhoisGuard or Whois Protection (depending on registrar), your name address/phone/email/etc will be shown. This is definitely not what you want.

Keep a list of usernames and proxies
If you have multiple accounts for forums, make sure you're not blowing your cover and mixing up proxies or worse yet, logging in with your public facing IP address. Keep track of that stuff using a spreadsheet or a password manager (more on that below).

Social Network Profiles
Another overlooked thing is how you have your own Social Network profiles set. Are you displaying your full date of birth and other information about yourself that would make you the perfect target for identity theft? How about your Friends list on Facebook? Can others see your entire list of friends so they can leech off the list too? How about your phone number? Do you want the world to know your mobile number? If the world can see it, a bot can see it too.

Facebook has an excellent feature that will allow you to see how your account looks to either someone on your friend's list or the public. The following link explains how to to use it: https://www.facebook.com/help/288066747875915

Use Password Management Software (*Never use the same password twice)
Each account you create should have a strong and unique password. You never want to get lazy and use the same username/password for every site; it's a sure road to ruin. To keep track of all these usernames/passwords you can use a service like "LastPass" (https://lastpass.com/) or you can download password management software.

I like to use a program called "keepass" to keep track of site passwords (http://keepass.info/). Keypass stores your passwords in an encrypted database which requires a password, keyfile, or both to open. This way, you can memorize just 1 password and have access to all of your passwords. Keypass has the ability to generate random passwords and I use this feature heavily when creating accounts for forums/social media.

Tor Project
No topic about online privacy would be complete without discussing The Onion Router (Tor). Pretty clever name if you think about the layers of an onion being comparable to the various "layers" that data is passed through via the Tor network.

From the "about" page of the Tor Project website: https://www.torproject.org/about/overview.html.en

"The Tor network is a group of volunteer-operated servers that allows people to improve their privacy and security on the Internet. Tor's users employ this network by connecting through a series of virtual tunnels rather than making a direct connection, thus allowing both organizations and individuals to share information over public networks without compromising their privacy."

Here's a good visual explanation of how Tor and HTTPS work to enhance your online privacy. It's interactive, safe for work and fun for the whole family.
https://www.eff.org/pages/tor-and-https

Deep Web
You hear people talk about the "Deep Web" like it's some kind of secret thing that only an elite few have access to. You hear stories of everything from porn to violence and just about any other legal/illegal activity, including buying drugs online and other things that even some of the more "blackhat" marketers won't even touch. What is the Deep Web?

The Deep Web, very simply put is the areas of the Internet that exist that search engines can't access. A simple example is a web service that you have to have a username and password to access. Take https://www.serpwoo.com/ for example. When you sign up for SerpWoo and login, everything you do is protected by your session. Google/Bing/DuckDuckGo/etc has no clue what the site it about except for the pages it is allowed to index.

The Deep Web can be used to exchange all kinds of knowledge. There are many websites that can only be accessed by using Tor and these websites are not indexed by search engines. While it is true that there are a lot of potentially "bad" sites out on the Deep Web, there is also information you won't find anywhere else. Never limit your access to knowledge.

Interestingly, "The Deep Web" is what we had in the beginning before there were major attempts to index the Internet. Why is it important? When you take into account that only about 4-5% of the Internet is "visible" to search engines, it puts a lot of things into perspective. A good start would be a search for "how to access the deep web". Just be careful not to get lost out there. Actually, just be careful anyway.

Website Footprints
A website footprint is simply any piece of text or content that can be used to identify or track a particular framework and even networks of sites that share the same footprint. For example, a common footprint for WordPress is "Powered by Wordpress" or "Proudly Powered by WordPress". Try either one in the search engine of your choice and see what happens.

Others

• leave a reply
• Name (required)
• Try some of these also: http://www.scribd.com/doc/146735706...st-2013-for-Finding-the-Best-Backlink-Sources

By studying other WordPress sites as well as sites from other platforms, you can gain a good understanding of the steps you'll need to take to minimize the footprint across your sites.

Aside from knowing what website footprints are, you'll want to know the best ways of finding them. When most people go to Google, Bing, etc and perform a search, they normally just enter a phrase (or part of one), click the search button and off they go from there. That's OK for lots of easy to find things, but there are better ways to search that will allow you to fine-tune your results. Google (and Bing) has quite a few "search operators" you can use. The best way this can be described is with some examples. Using Google:

WordPress sites that end in .gov. Substitute .edu, .com, .net, etc for other domains.
site:.gov intext:"Powered by WordPress"

WordPress sites that have pages/posts with "custom pool cues" in the title
intext:"Powered by WordPress" intitle:"custom pool cues"

Mastery of search operators is your key to finding anything you want on the web. A good searcher can spend minutes finding something that would take most people hours or even days, if they even find anything at all. The following is a great site to read more about how search operators work:
http://www.googleguide.com/advanced_operators_reference.html Learning these unlocks the ability to find anything you want on the web by significantly improving your signal-to-noise ratio.

*Warning - Use of advanced search operators can (and does) lead to you getting hit with one of those captcha pages where you have to enter the captcha to continue searching because Google thinks that perhaps there is a bot on the other end. The reason for this is that the average person doesn't use search operators, but bots do frequently.

 

[SmokeTree]

Conclusion
By now you should have a working knowledge of Linux/Unix file permissions and how to apply that knowledge to secure a WordPress site. Those skills alone will carry over to other projects such as static web sites and the use of other CMS (Content Management System) platforms. You've also learned good practices for setting up user access levels, use of strong passwords, password management software and how to use the .htaccess file as a mini "firewall" of sorts, and how it can slow things down too.

I hope that the "Online Privacy" section has given you some insight into how you are tracked and steps you can take to protect your privacy. You've also learned how to identify website footprints and how to use search operators to find niche specific sites that may be unaware of their own footprints. I even touched on the topic of the Deep Web and Tor, which is worth doing some serious reading on.

Please know I've only scraped the surface here with both of today's topics. Please use what you've learned here as a solid stepping stone into more advanced security/privacy concepts and practices.

 

[built]

@SmokeTree I changed my file permissions, does this look correct? Because this is what the plugin suggested I did, but I see from yours you recommend 600 for wpconfig

 

[SmokeTree]

@built I'd try 600 first and see if WP works after that. If nothing breaks then you're good to go. The first 6 gives read/write access to the owner of the file, which should be the same user the server is running as.

The suggestion of 444 by the plugin would give user/group/world read-only access to that file. It's the "world" having read access I worry about. Also, the 444 wouldn't even let the owner write to the file. If you have an instance where WP itself needs to write to the config file, you'll have to change the permission back just long enough to allow it to. I'd try the following in this order:

600
640
644 (or 444 if you don't mind changing permissions back if WP needs to write the the config file)

The rest of the config there looks ok as long as it works. You may need to add more permissions as needed till things are as secure as they can be and still be functional.

 

[finnegan]

I'm worried about the danger of accidentally linking accounts with one another.

Let's assume you have a regular social media account that you use for personal use and white hat advertising. You've spent years building up this account to acquire trust. Therefore, you don't wanna do something to get that account banned so you can't leave any trails.

Now...you've got multiple social accounts that you're cycling through on your browser using a proxy. If you forget to log out of that account and simply switch back to your standard IP and then go back to that site, you will accidentally be logging back on using your main IP, thus linking the accounts.

I'd like to find the best way to prevent this by isolating each account from your main one on your home box.

Would a virtual box be the best way to go here to prevent a moment of stupidity from sinking your accounts?

 

[SmokeTree]

Would a virtual box be the best way to go here to prevent a moment of stupidity from sinking your accounts?

A virtual machine is an invaluable tool in isolating accounts in situations like you describe above. You can set them up very easily too with various OS and all kinds of different configurations. As you can imagine, you can configure quite a few different profiles, using different proxies by default and keep things separate. You're simulating hardware with a VM so the sky is basically the limit. Even without a virtual machine, you can mandate certain accounts be used by certain browsers only, and those browsers can be configured to use certain proxies and different configurations.

Let's talk about your IP address though. An http/https proxy by itself, regardless of how anonymous it is made by not passing certain headers or other methods of divulging the IP, will NEVER guarantee that other sites can't figure out your IP. I'll describe one such approach that was used pretty often back in the day to see if a user was using a proxy (going back to around 2009-2010 here).

• User would use highly anonymous http/https proxy to visit website.
• Webserver (Apache/Nginx) logs IP of proxy, cause highly anonymous and stuff. Server-side script generates random token (GUID or something) and stores it along with IP. Here's where things start to get cool.
• A page on the website has a .swf (Flash) file that would fire off a simple script. All this script did was access a special URL and pass it the token that was generated.
• Flash ignored the proxy settings and accessed the URL without using the proxy. User didn't know that because when most people think of Flash, they are thinking of Youtube, Games, etc. But here it is, holding up the middle finger to proxy settings.
  
• The webserver logs the REAL public IP (thanks Flash) and now has a token that was passed. This is a smoking-gun match from the proxy IP to the public IP. Not hard to do at all.

This is just to show it's possible to get an end users "real" IP, and oftentimes in ways they would have probably never guessed. A proxy can be very effective and in most cases might be all you need. In other cases, a VPN would be the optimal choice. In the case of a VPN, the traffic is traveling through an encrypted tunnel and the "real" IP will be shown as the IP of the VPN if it is leaked. A proxy is just forwarding http/https traffic (and is almost certainly logging said traffic).

Another thing about proxies. The big boys are getting better and better at picking out which IP is likely to be a proxy. A good example is Google. If you're trying to scrape Google and you're using an IP that is on a class C (or even class B) that is known for activity that is consistent with bots, you'll get the familiar "prove you're human" captcha page we all know and love. With that said, other social Networks are blocking accounts that use IPs in ranges that are saturated with bots. I had a good friend lose one of their main accounts because of this.

Definitely not trying to do any fear mongering here, just saying that it is more important than ever to establish a good separation strategy with online accounts. Hope this helps

 

[Ryuzaki]

Actionable Wordpress Security Tips

Continuing to work on the assumption that most people reading this are using Wordpress for their content management system, I've collected some easy to implement tips that anyone can use following the directions below. Can this be extended further? Yes, depending on your willingness to take the deep dive. But following these concepts will keep you safe from most script kiddies and make the job of infiltrating your site too time consuming for pro's who often work on bulk scanning. Unless you cross someone skilled, you shouldn't become an all-or-nothing target.

There may be some slight overlap with the work of @SmokeTree above, and I want to give a shoutout to @turbin3 who introduced me to some of the methods as well.

Wordpress isn't any more hackable than other CMS's, fundamentally. The problem is largely that it has a database with inputs and plugins that interact with it, like all others except flat file CMS's, which are still vulnerable to server attacks.

Summary: Everything is vulnerable. It's up to you to make it as inconvenient as possible to attack your site, which stops most bad actors using automated means. What you want to do beyond this is to have daily rolling backups so as soon as you discover a problem, you save whatever new content you posted and roll back to a version five days ago and repost the content. Then you pay someone to find out how they got in and fix it.

Rolling backups are your safety net, but you need to be interacting with your sites daily to make sure they're okay. Last thing you want is to overwrite your oldest backup with the hacked one.

The great part is that Wordpress is on the ball about patching up a lot of problems (automatically updating your site for anything too bad). Another problem is they immediately announce to the world what the vulnerability is, and then it's a race between webmasters and hackers to see who can get to your site first. So you need to always be updating themes and plugins.

Themes & Plugins
Some of the worst things you can do is download a theme or plugin that someone else coded. Most of us can't do anything about that, so we need to be wise about how we select what to use. Yes, when you first get into this you see a lot of fun ideas and cool features you'd like to add to your site. It's a novelty and you're exploring the possibilities. But the real question to ask is whether or not that feature is going to make you money. That eliminates most crud.

You need to stick to themes and plugins that get updated constantly, especially if they're complicated ones with a lot of backend options. Don't get that theme by some random guy that only has 300 downloads since 2007. I'd recommend sticking largely to themes from the Wordpress repository too, since they go through strenuous amounts of nonsense to force you to be in perfect alignment with Wordpress' philosophy and anal-retentitiveness. You can definitely find trustworthy themes on other marketplaces, but you need to know what you're looking at in terms of making sure the developer's are active and fast to patch problems.

Plugins are the death of most sites. They get abandoned (even paid ones). Let me tell you... you don't need many plugins to make a site that earns gobs of money. There are a few you can trust to be constantly updated, either because the developers livelihood depends on it, or it's owned by Automattic (aka Wordpress).

Learn to identify these, like Yoast SEO, WP Super Cache, UpdraftPlus, Advanced Custom Fields, Akismet Anti-Spam, Contact Form 7, Plugin Organizer, etc. That's off the top of my head and pretty much all I use. I use WP-Optimize but only activate it when I'm using it and then deactivate it. Any plugins you aren't actively using need to be deleted. Don't collect 100 of them because you're too lazy to delete them. I've seen it too many times.

Isolate Your Sites
Being cheap and using shared hosting not only makes your site slow and guarantees it crashes if you ever go viral, but it also makes your entire network vulnerable. A virtual private server (VPS) isn't that much more expensive and lets you create different accounts. You want one per site with a unique username and password to access that cPanel account or whatever else you're using. This way, if one site is open to attacks and they get in, they can only mess with that one. Otherwise they need to attack your root account on the server at large. Good luck with that unless you do something dumb with your password. Most VPS providers have extreme security measures in place on their side. You can't even get port scanning done on my sites.

Set Up Layers of Access to WP-Admin
Most of the time, if someone can't access the dashboard, they'll give up. This includes bruteforce login attempts, MySQL Injection script kiddies, and more.

One thing that's worth doing if you're the only person ever accessing the backend of the site is to make it impossible for anyone not originating from your IP address from getting to it. I don't recommend this if you're not comfortable with SFTP clients and finding hidden dot files and potentially breaking your site. The problem is compounded if you work remotely or have dynamic IP addresses. There's a better way.

Many will tell you to rename the wp-login.php and wp-admin file paths, but all you need to do is create a another layer of security over it that handles rate limiting (stops bruteforce attacks) and doesn't even let people access the login form:

Note: This section is for Apache servers only.
The format is different for Nginx, which you can search for.

# PASSWORD PROTECT wp-login.php
<Files wp-login.php>
AuthUserFile /home/your_account/public_html/.htpasswd
AuthName "What Pops Up on Browser"
AuthType Basic
require user your_username
</Files>

This goes in your .htaccess (yes, you'll eventually have to get comfortable with it). What it says is, regarding any access to wp-login.php (including the redirects that non-logged in users get from /wp-admin/) will need to authorize themselves through a browser pop-up that asks them for a username and password. Notice the "your_account" part in AuthUserFile, you need to adjust that so the file path points to the hidden .htpasswd text file you'll create. And for require user, you need to change your_username. Do not use the same information as used for your Wordpress login. Use a 100% unique name and password never before used on any other site ever, no dictionary words, etc.

So what about the .htpasswd? You need to generate that with a text editor, upload it to the public_html using the File Manager within cPanel in your browser or through an SFTP client, and make sure in either case that hidden files are visible. Within it you need only one thing:

your_username:$xqr1$g8bSt9uoQo$DdxcpsScCraoaic8f9xaton24X/

This is a made up example, but it's one line, no extra lines or spaces anywhere. You simply want the user name you selected (no spaces in username!) and a colon after it, followed by the password.

This password can be anything you like, which you then have to encrypt into a MD5 hash, which you can do here: http://www.htaccesstools.com/htpasswd-generator/ You will be given the resulting user: pass line to paste into the .htpasswd file to upload.

When done correctly, when you browse to wp-login.php or wp-admin, you will see a pop up like this:

​

Now, nobody can even try to bruteforce your site or get into the dashboard without going through two passwords, one of which will maintain a blacklist of IPs that get hit by the rate limiting block.

Stop People From Scanning & Attacking
Okay, so that stops people from being able to get into your dashboard, even if they do a MySQL injection and manage to grab your password, because your password is now password protected!

So our goal now is to stop people from even deciding that your site is worth attacking. Again, most people are using tools to scan the net for vulnerable sites based on footprints. We need to clean up footprints in general so you don't fall into those lists.

The first thing we want to do is protect your .ht files, including your .htaccess and .htpasswd so nobody can get through your 2nd layer of protection. While we're at it, let's go ahead protect some files, including core Wordpress files, so that nobody can read them unless they log in through your hosting account:

# PROTECT wp-config.php
<Files wp-config.php>
order allow,deny
deny from all
</Files>

# BLOCK THE readme.html
<Files readme.html>
order allow,deny
deny from all
</Files>

# BLOCK THE license.txt
<Files license.txt>
order allow,deny
deny from all
</Files>

# BLOCK .HT FILES
<Files ~ "^\.ht">
order allow,deny
deny from all
</Files>

# BLOCK xmlrpc.php REQUESTS
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

# NO DIRECTORY BROWSING
Options All -Indexes

# BLOCK the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

What we have above is broken up so you can pick and choose what you want, but you can list a lot of them together into one <Files> directive. What you see stops people from reading wp-login.php unless they're authenticated, as well as some crap Wordpress uploads like readme.html and license.txt. These tell which version of Wordpress you're using and is used in scanning for matching vulnerabilities. Instead of deleting them each time you update, you can just block access.

We've also blocked access to .ht files as mentioned above, and then we also block any requests to XMLRPC.php, which is a remote access protocol so you can post to your site through other software editors or email and other crap you're likely not doing at all. Bad actors ping this non-stop all day long, eating bandwidth, slowing down your server, and trying to break into it. Just block access and make sure you use the code chunk below to disable it.

And finally, we stop directory browsing, which is where you can access the folders and list of folders if a public folder doesn't have some kind of index.html or .php in it to present a blank or alternative page. You don't need it, and nobody else needs to see under the hood of your site.

On-Site Footprints
We just dealt with file footprints, but we need to remove ones that render into your HTML, like Wordpress announcing to the world over and over which version you're using. Again, I'll make this easy with some copy and pasting of code chunks.

These all go into your functions.php file, and are collected from this thread which has a lot of other non-security related functions you may find helpful.

// Get Rid of WP Version Footprint Throughout Site
Don't be a target. Keep your core updated of course, but don't announce your version to scrapers.

// Get Rid of WP Version Footprint Throughout Site
function ryu_remove_version() {
return '';
}
add_filter('the_generator', 'ryu_remove_version');

// Remove Footprints and Search Engine Confusion from wp_head Function
Removes a lot of unnecessary meta data such as links to a million RSS feeds like categories, comments. Removes relational links such as previous and next from pages that don't need it. You can pick and choose what you want from here, as they aren't all related to security directly, but will stop some absurd crawling and scanning.

// Remove Footprints and Search Engine Confusion from wp_head Function
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'start_post_rel_link');
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'feed_links_extra', 3 );
remove_action('wp_head', 'feed_links', 2 );
remove_action('wp_head', 'parent_post_rel_link', 10, 0 );
remove_action('wp_head', 'start_post_rel_link', 10, 0 );
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);

// Disable XML-RPC
XML-RPC is old tech used to remotely publish content from other apps while on the go. Stuff like IFTTT will use it so make sure you want to get rid of it. Traditionally it's stuff like Windows Live Writer and Market Samurai that used it so you could post to all of your sites from one central application.

// Disable XMLRPC
add_filter('xmlrpc_enabled', '__return_false');

I need to give a heads up about the // REST API too. I disabled it when it first came out and then Wordpress made it impossible to disable, because they want to force adoption. The current problem is that you can make it spit out every username for every account on your site, which means all the bad guys now need is your password. Make sure you're using long, unique, and randomized passwords! This can't be stressed enough.

Conclusion
This is pretty much what I can think of at the moment. This will take you a long way, keeping the lowest level attacks away. Of course you still have the issues of plugin footprints, but when they can't be matched with Wordpress versions that helps.

After this, the main things you need to worry about are:
- server security (your host should have this taken care of if you aren't cheaping out, and you need to pay attention to file permissions),
- unsanitized inputs (Wordpress's own ones are fine, the plugins you choose screw this up a lot, especially if they aren't in the official repository) ,
- MySQL injections (bad theme coding, bad plugin coding)

These will always be problems for amateurs because they don't care or learn about security. You can escape nearly all of this by choosing wisely who you use as a host, theme, and plugin provider.

And as always - have daily or weekly rolling backups!

 

[Sutra]

Want to increase the security of my site and found this thread. Have some questions @Ryuzaki if you don't mind. See questions under quotes below:

1)

Set Up Layers of Access to WP-Admin
Most of the time, if someone can't access the dashboard, they'll give up. This includes bruteforce login attempts, MySQL Injection script kiddies, and more.

One thing that's worth doing if you're the only person ever accessing the backend of the site is to make it impossible for anyone not originating from your IP address from getting to it. I don't recommend this if you're not comfortable with SFTP clients and finding hidden dot files and potentially breaking your site. The problem is compounded if you work remotely or have dynamic IP addresses. There's a better way.

Many will tell you to rename the wp-login.php and wp-admin file paths, but all you need to do is create a another layer of security over it that handles rate limiting (stops bruteforce attacks) and doesn't even let people access the login form:

Note: This section is for Apache servers only.
The format is different for Nginx, which you can search for.

# PASSWORD PROTECT wp-login.php
<Files wp-login.php>
AuthUserFile /home/your_account/public_html/.htpasswd
AuthName "What Pops Up on Browser"
AuthType Basic
require user your_username
</Files>

This goes in your .htaccess (yes, you'll eventually have to get comfortable with it). What it says is, regarding any access to wp-login.php (including the redirects that non-logged in users get from /wp-admin/) will need to authorize themselves through a browser pop-up that asks them for a username and password. Notice the "your_account" part in AuthUserFile, you need to adjust that so the file path points to the hidden .htpasswd text file you'll create. And for require user, you need to change your_username. Do not use the same information as used for your Wordpress login. Use a 100% unique name and password never before used on any other site ever, no dictionary words, etc.

So what about the .htpasswd? You need to generate that with a text editor, upload it to the public_html using the File Manager within cPanel in your browser or through an SFTP client, and make sure in either case that hidden files are visible. Within it you need only one thing:

your_username:$xqr1$g8bSt9uoQo$DdxcpsScCraoaic8f9xaton24X/

This is a made up example, but it's one line, no extra lines or spaces anywhere. You simply want the user name you selected (no spaces in username!) and a colon after it, followed by the password.

This password can be anything you like, which you then have to encrypt into a MD5 hash, which you can do here: http://www.htaccesstools.com/htpasswd-generator/ You will be given the resulting user: pass line to paste into the .htpasswd file to upload.

When done correctly, when you browse to wp-login.php or wp-admin, you will see a pop up like this:

​

Now, nobody can even try to bruteforce your site or get into the dashboard without going through two passwords, one of which will maintain a blacklist of IPs that get hit by the rate limiting block.

Is doing the above the same as turning on 2 factor authentication in Wordfence?


2)

Stop People From Scanning & Attacking
Okay, so that stops people from being able to get into your dashboard, even if they do a MySQL injection and manage to grab your password, because your password is now password protected!

So our goal now is to stop people from even deciding that your site is worth attacking. Again, most people are using tools to scan the net for vulnerable sites based on footprints. We need to clean up footprints in general so you don't fall into those lists.

The first thing we want to do is protect your .ht files, including your .htaccess and .htpasswd so nobody can get through your 2nd layer of protection. While we're at it, let's go ahead protect some files, including core Wordpress files, so that nobody can read them unless they log in through your hosting account:

# PROTECT wp-config.php
<Files wp-config.php>
order allow,deny
deny from all
</Files>

# BLOCK THE readme.html
<Files readme.html>
order allow,deny
deny from all
</Files>

# BLOCK THE license.txt
<Files license.txt>
order allow,deny
deny from all
</Files>

# BLOCK .HT FILES
<Files ~ "^\.ht">
order allow,deny
deny from all
</Files>

# BLOCK xmlrpc.php REQUESTS
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

# NO DIRECTORY BROWSING
Options All -Indexes

# BLOCK the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

What we have above is broken up so you can pick and choose what you want, but you can list a lot of them together into one <Files> directive. What you see stops people from reading wp-login.php unless they're authenticated, as well as some crap Wordpress uploads like readme.html and license.txt. These tell which version of Wordpress you're using and is used in scanning for matching vulnerabilities. Instead of deleting them each time you update, you can just block access.

We've also blocked access to .ht files as mentioned above, and then we also block any requests to XMLRPC.php, which is a remote access protocol so you can post to your site through other software editors or email and other crap you're likely not doing at all. Bad actors ping this non-stop all day long, eating bandwidth, slowing down your server, and trying to break into it. Just block access and make sure you use the code chunk below to disable it.

And finally, we stop directory browsing, which is where you can access the folders and list of folders if a public folder doesn't have some kind of index.html or .php in it to present a blank or alternative page. You don't need it, and nobody else needs to see under the hood of your site.

For the above, where do we place the code you provided?


3)

On-Site Footprints
We just dealt with file footprints, but we need to remove ones that render into your HTML, like Wordpress announcing to the world over and over which version you're using. Again, I'll make this easy with some copy and pasting of code chunks.

These all go into your functions.php file, and are collected from this thread which has a lot of other non-security related functions you may find helpful.

// Get Rid of WP Version Footprint Throughout Site
Don't be a target. Keep your core updated of course, but don't announce your version to scrapers.

// Get Rid of WP Version Footprint Throughout Site
function ryu_remove_version() {
return '';
}
add_filter('the_generator', 'ryu_remove_version');

// Remove Footprints and Search Engine Confusion from wp_head Function
Removes a lot of unnecessary meta data such as links to a million RSS feeds like categories, comments. Removes relational links such as previous and next from pages that don't need it. You can pick and choose what you want from here, as they aren't all related to security directly, but will stop some absurd crawling and scanning.

// Remove Footprints and Search Engine Confusion from wp_head Function
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'start_post_rel_link');
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'feed_links_extra', 3 );
remove_action('wp_head', 'feed_links', 2 );
remove_action('wp_head', 'parent_post_rel_link', 10, 0 );
remove_action('wp_head', 'start_post_rel_link', 10, 0 );
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);

A) Will doing the above cause any issues when trying to upgrade Wordpress, or plugins, to the newest version?
B) You mentioned, "Removes relational links such as previous and next from pages that don't need it." does that mean it will remove pagination from Category pages?

Since the original post is 2+ years old, is there anything from this that should not be done (perhaps will cause conflicts, etc), or anything that can be done in an easier way today?

 

[Ryuzaki]

Is doing the above the same as turning on 2 factor authentication in Wordfence?

Pretty much. It'll stop someone that doesn't get your 2nd authentication code from logging in. I call the .htpasswd method "Two Layer" instead of "Two Factor" in my own mind. Different implementation, same results.

For the above, where do we place the code you provided?

All of that belongs in the .htaccess file on Apache servers.

A) Will doing the above cause any issues when trying to upgrade Wordpress, or plugins, to the newest version?

None of those will cause any issues during upgrades or for plugins. They simply remove them from being inserted into the HTML through the PHP wp_head();, but otherwise it's all functional on the backend.

B) You mentioned, "Removes relational links such as previous and next from pages that don't need it." does that mean it will remove pagination from Category pages?

It will not remove pagination, just those links "prev" and "next" links in the HTML header, which Google already abandoned and is no longer using. They were used in pagination for categories and in pagination for chopped up posts like "see the top 15 gallery of nice cars" so you get people loading ads more and more. Google doesn't need them because they understand how to follow the paginated links at the bottom now [1] [2] [3] ... [12] [13]. It's just bloat and crap for spiders to get distracted with nowadays.