I love Firefox. I’m a Firefox user, and hopefully always will be. Firefox is better than any other browser (plus it’s free and open-source). However, there have been a few technical things that I don’t like.

• Endless promotion of Mozilla VPN
• Firefox DNS over HTTPS silently fails
• Compact Toolbar Density not supported

Queue track: LCD Soundsystem – New York, I Love You but You’re Bringing Me Down

But, since Firefox can be customized, you can change these settings to what you like.

Mozilla VPN – Please stop bothering me

Since Firefox 93, Mozilla VPN promotions won’t go away. I understand Mozilla needs to make money. But I don’t want to constantly see this ad. I get it, you offer a VPN service. Unfortunately, there isn’t an easy way to hide the ads for their VPN. There isn’t even a documented way for the “user.js” settings, however I figured out a way to hide them when opening a new “Private” browsing window. This works in Firefox 94 to current (Firefox 96), and hopefully keeps working!

Update the Firefox user.js settings to fix this:

// FF94
user_pref("browser.privatebrowsing.vpnpromourl", "");

Before and after:

Firefox DNS over HTTPS silently fails open

Firefox has a built-in option for DNS over HTTPS (DOH). It’s great that you can set this up and add another layer of security from prying eyes. This actually isn’t a new thing, it has been around since Firefox 62.

However, I recently found out that it fails open by default with no warning.

What does this mean?
If the DNS over HTTPS server you pick stops working, Firefox silently fails to use DNS over HTTPS and uses your system’s default DNS settings instead. And there is no warning when this happens.

They say, a false sense of security is worse than no security at all. You thought you were more secure with DNS over HTTPS.

Read more about the option from:
Connection settings in Firefox
Firefox about DNS-over-HTTPS

And also read the Trusted Recursive Resolver wiki page carefully about the different options.

You can fix this by changing the setting for “network.trr.mode” to 3, which will force Firefox to only use the resolver you specify for DOH and if it fails, then Firefox won’t use the system’s DNS.

In the Firefox user.js settings file add:

//trr.mode 5 is no DOH. 2 is enable DOH. 3 is no failback to system dns
user_pref("network.trr.mode", 3);
user_pref("network.trr.default_provider_uri", "https://dns.quad9.net/dns-query");
user_pref("network.trr.uri", "https://dns.quad9.net/dns-query");
user_pref("network.trr.custom_uri", "https://dns.quad9.net/dns-query");
user_pref("network.trr.bootstrapAddress", "9.9.9.9");

The above also sets the DOH resolver to Quad9.

Also note:
When you change the setting (URL or Disable/Enable) in the Firefox Settings, it will reset “network.trr.mode” to 2 so you need to change this again!

Compact Toolbar Density option missing

I like the “Compact” Toolbar Density option because I don’t want a huge waste of space at the top of my Firefox window. I want to be able to optimize for these wide monitors we have, so vertical space is at a premium! Since Firefox 89 this has been hidden behind a configuration setting.

With this setting in the user.js you now have the Compact option again in Firefox:

// FF89
// Compact mode workaround in Firefox
// https://support.mozilla.org/en-US/kb/compact-mode-workaround-firefox
user_pref("browser.compactmode.show", true); // [DEFAULT: false]

Conclusion

Firefox is my browser of choice, and it is free and open-source. Its ability for customization means you can change it to your liking too. So these technical issues will (hopefully) always have a work-around.

The post Firefox, I love you but you’re bringing me down appeared first on Ryan Daniels.

Let’s discuss the background of firewall issues with Docker, and a working solution for my use case (either setup manually or using Ansible). By the end we will use a firewall on the server to lock down everything by default, only allowing my trusted IPs! With the option to open specified ports publicly (like SSH).

Note: This solution works with CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

Background

Firstly, even if you were using a firewall like iptables, Docker makes that useless. Docker punches a whole right through your firewall!

And if you try another firewall, like firewalld? Docker Swarm (and even regular Docker) with firewalld is a complete mess. Restart the firewalld service, or change the firewalld config, and you lost all the config that Docker needed. Now you have to restart Docker! What happens if the firewalld service failed and restarted? That Docker Swarm node is out of service.

Keep in mind, when I mention Docker, it means the regular Docker Engine. Docker Swarm means SwarmKit, which is the newer way of using Swarm. (The old way is the standalone solution which is old and not referenced at all here).

There are many attempts to solve this problem by users of Docker. Unfortunately the Docker team has been pretty quiet about these issues. They recommend a manual user solution, and to disable Docker’s use of iptables. I’m speculating here, but it seems like any future change from Docker will likely be a breaking change since this is a complicated issue to fix.

The attempted solutions (from users) are not very straight forward for a normal Docker user. And that’s the real issue. On top of that, out of the box (after you start one service with a published port), there is no security at the network layer. Anyone can connect to an exposed container’s port. Most importantly, even if you think you have a firewall protecting you.. Wrong, you don’t! With normal Docker, you can bind your service to your localhost which helps. But what about Docker Swarm? Nope, that doesn’t work.

There’s a great article about “The problem of forcing users to make choices (in security).” Definitely worth the read!

Roll your own solution

Until this is actually addressed in Docker, our only hope is to find the simplest solution possible. And turning off iptables integration in Docker is unacceptable (which is constantly recommended by the Docker developers). The other option is to move on from Docker and/or Docker Swarm. I hear this thing called Kubernetes is pretty great. Anyways, back to Docker.
Many people have spent hours trying to learn, and figure out iptables as a solution to this. You need to roll your own solution apparently! So iptables is probably the best approach, since that is what Docker needs to use to do it’s magic (and most other firewalls are just a wrapper for iptables anyway depending on your OS).

Something fun I found out while testing this, Docker Swarm uses iptables in an undocumented way. Docker Swarm uses the iptables INPUT chain! It’s only for encrypted overlay networks. But it’s not very fun realizing that! All of a sudden rules are being appended to the INPUT chain.

Okay, enough backstory. On with my futile attempt to roll my own solution. This took way longer than I thought it would! But it does work! Currently it works at least.. (That’s why I use the word futile!)

Problems I need to solve

1. Only allow traffic from multiple “trusted” IP addresses to my servers. Not all of these IPs will be in the same “IP block/range” either. This will be to all services running directly on the server, and also all of the Docker containers.
2. Let only specific ports be publicly accessible, like SSH.
3. I’m not managing which containers are accessible through the firewall. Meaning, I’m not manually adding ports into my firewall solution. That kind of manual work is not happening. I need a dynamic, and flexible solution that blocks by default except to my trusted IPs.
4. The firewall solution must be simple. More complex means more room for error.
5. The firewall solution must not impact performance significantly.
6. Restarting the firewall won’t break Docker.
7. Restarting Docker won’t break the firewall.
8. No impact to running server processes or Docker services when making a change. Things need to keep working!
   Firewall changes need to happen online and not impact Docker. Meaning I can’t be restarting Docker because I made a firewall change.
   Docker “changes” need to happen online. Meaning I can’t be restarting the firewall because I made a Docker change. (A Docker “change” means starting/stopping a container).

That sounds very simple! Unfortunately, it is not with Docker (and Docker Swarm).

Solution – Docker firewall with iptables and ipset

If you don’t know much about iptables, or ipset, that’s okay. You don’t really need to know. You should have some basic understandings though, so you don’t break your servers! The Arch Linux wiki has great information about iptables. Including this helpful visual about the iptables flow.

Note: This solution works with CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

High level summary

iptables with ipset will handle all of this for us. And keep our servers, and Docker locked down from the network level.

In this solution, we will use the iptables INPUT chain to jump to another chain (let’s call our custom chain FILTERS), but return if there’s some legitimate looking traffic, so the Swarm overlay can do whatever it wants in INPUT with IPSEC, or whatever it is appending to INPUT.
Inside our custom chain FILTERS, we drop everything that doesn’t match our trusted list of IPs. We also allow our SSH port and the basic default iptables stuff.. You can also add any OS port to be publicly accessible.
The DOCKER-USER chain only needs a few entries. Any internal Docker traffic is returned, and it will drop any other traffic that’s not in our allowed IP list. You can also add any container port to be publicly accessible.

One of the dangers with this approach is if Docker changes it’s behaviour our firewall could break, or our Docker services could stop working. Since Docker doesn’t offer any solution for their users, we need our own solution. So keep in mind that you need to test this when upgrading to a new version of Docker. That is the trade-off with a “roll your own” solution. But what choice do we have?

I’ve created an Ansible Role: iptables for Docker, on GitHub and Ansible Galaxy.

Warnings

Warning: Be sure you have everything needed in your configuration. Once the iptables firewall is started it blocks anything that wasn’t added! Don’t lock yourself out of your server. Be sure to have another way to connect, like a console.

Disclaimer: Keep in mind, you should test all of this in your lab or staging environments. I can’t guarantee this will be 100% safe and can’t be held responsible for anything going wrong!

SELinux Bug: If using SELinux, currently there’s a bug with SELinux which prevents saving the iptables rules to the iptables.save file.
Impact: Saving the iptables rules a 2nd time will silently fail. Workaround has been added so SELinux allows chmod to interact with the iptables.save file. See notes on GitHub for SELinux workaround steps. Alternatively you could disable SELinux, but that’s not recommended. Bug report: https://bugs.centos.org/view.php?id=12648

The manual way

Run the commands below. These commands are only for CentOS/RHEL 7. If you don’t want to do this manually, jump to the Automatic section, using Ansible (which also works with Ubuntu).

Prep

Make note of what you already have in iptables (if you are already using it). Be sure you have some background with iptables, since you could break things!

# iptables -nvL --line-numbers

Install the required packages for CentOS / RHEL:

# yum install iptables iptables-services ipset ipset-service

Configure ipset

ipset allows you to add a list of IPs that you can use with iptables. In our case, we will add a list of IPs we want to be able to connect to our servers.

Configure ipset with a setname of ip_allow.
Add IPs you want to allow. Change the IPs below to your actual trusted/allowed IP ranges. Be sure to include your Docker server IPs here, because if you don’t they can’t communicate with eachother:

# mkdir -p /etc/sysconfig/ipset.d
# vi /etc/sysconfig/ipset.d/ip_allow.set

create -exist ip_allow hash:ip family inet hashsize 1024 maxelem 65536
add ip_allow 192.168.1.123
add ip_allow 192.168.100.0/24
add ip_allow 192.168.101.0/24
add ip_allow 192.168.102.0/24

Start, and Enable the ipset service:

# systemctl status ipset
# systemctl start ipset
# systemctl enable ipset

See what ipset has in it’s loaded configuration:

# ipset list | head

Important: Make note of the size of “Number of entries”. If that number is close to the maxelem size (65536), then you need to delete the ipset and re-create it with a larger max size. If you only use a few IP ranges like above, you don’t need to worry and will be well below the limit.

Configure iptables

Next up, iptables. iptables is our solution for a firewall. We will create a file with our rules and then add those rules into iptables. The important part is to not flush the existing rules if you are already using Docker (or Docker Swarm) on your server.

Create an iptables file to use with iptables-restore, to add the rules into iptables:

# vi iptables-rules.txt

Add below to the file. There is a lot going on here..

*filter
:DOCKER-USER - [0:0]
:FILTERS - [0:0]
#Can't flush INPUT. wipes out docker swarm encrypted overlay rules
#-F INPUT
#Use ansible or run manually once instead to add -I INPUT -j FILTERS
#-I INPUT -j FILTERS
-F DOCKER-USER
-A DOCKER-USER -m state --state RELATED,ESTABLISHED -j RETURN
-A DOCKER-USER -i docker_gwbridge -j RETURN
-A DOCKER-USER -s 172.18.0.0/16 -j RETURN
-A DOCKER-USER -i docker0 -j RETURN
-A DOCKER-USER -s 172.17.0.0/16 -j RETURN
#Below Docker ports open to everyone if uncommented
#-A DOCKER-USER -p tcp -m tcp -m multiport --dports 8000,8001 -j RETURN
#-A DOCKER-USER -p udp -m udp -m multiport --dports 9000,9001 -j RETURN
-A DOCKER-USER -m set ! --match-set ip_allow src -j DROP
-A DOCKER-USER -j RETURN
-F FILTERS
#Because Docker Swarm encrypted overlay network just appends rules to INPUT. Has to be at top unfortunately
-A FILTERS -p udp -m policy --dir in --pol ipsec -m udp -m set --match-set ip_allow src --dport 4789 -j RETURN
-A FILTERS -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FILTERS -p icmp -j ACCEPT
-A FILTERS -i lo -j ACCEPT
#Below OS ports open to everyone if uncommented
-A FILTERS -p tcp -m state --state NEW -m tcp -m multiport --dports 22 -j ACCEPT
#-A FILTERS -p udp -m udp -m multiport --dports 53,123 -j ACCEPT
-A FILTERS -m set ! --match-set ip_allow src -j DROP
-A FILTERS -j RETURN
COMMIT

Use iptables-restore to add the above rules into iptables. The very important flag is -n. That makes sure we don’t flush the iptables rules if we have rules already in Docker (or Docker Swarm).

# iptables-restore -n < iptables-rules.txt

Next, add a rule to the INPUT chain, so we start using the new rules in FILTERS. It has to be at the top, and only needs to be added once:

# iptables -I INPUT 1 -j FILTERS

Save the iptables rules:

# /usr/libexec/iptables/iptables.init save

That will save any existing and our new iptables rules to the iptables configuration file so it will be persistent after a reboot.

In addition, it was needed to run the above iptables command manually since we want to ensure it’s only inserted once. And we can’t flush the INPUT chain to ensure that since Docker Swarm could have rules there already.

Start and Enable the iptables service:

# systemctl status iptables
# systemctl start iptables
# systemctl enable iptables

If you want to customize the iptables rules to allow more ports to be open to everyone, just add the port to the appropriate rule in the iptables file (tcp or udp), then re-run the same commands from above:

# iptables-restore -n < iptables-rules.txt
# /usr/libexec/iptables/iptables.init save

Don’t miss the Warnings from above! Especially about SELinux.

If you don’t want to do all of that manually, and you use Ansible, then do this instead..

The Automatic way with Ansible

Manually run all of the above, on every Docker server is not ideal. Let’s use Ansible instead!

I’ve created an Ansible Role: iptables for Docker, on GitHub and Ansible Galaxy.

This works on CentOS 7, RHEL 7, Ubuntu 18.04, and Ubuntu 20.04.

Install the Ansible Role using Ansible Galaxy:

$ ansible-galaxy install ryandaniels.iptables_docker

Or, clone the GitHub project:

$ git clone https://github.com/ryandaniels/ansible-role-iptables-docker.git roles/ryandaniels.iptables_docker

Create the Ansible Playbook, called iptables_docker.yml:

---
- hosts: '{{ inventory }}'
  become: yes
  vars:
    # Use this role
    iptables_docker_managed: true
  roles:
  - ryandaniels.iptables_docker

Make configuration changes to add desired IP addresses and ports as needed.

Don’t miss the Warnings from above!

Then run the playbook:

$ ansible-playbook iptables_docker.yml --extra-vars "inventory=centos7" -i hosts-dev

Conclusion

In conclusion, now we have secured our Docker (and Docker Swarm) environments using Ansible to perform the installation and configuration of iptables! None of our Docker published ports are exposed to the world, unless we want them to be! We have created a custom Docker firewall with iptables. Hopefully, some day this will be the default behaviour and shipped with Docker out of the box! Dare to dream. Security is hard.

References

Background for Docker’s undocumented use of iptables INPUT chain

See my previous post about this.

References and links

References, notes, and links about the Docker firewall discussion:

• Docker Documentation – Overlay Networks
• Docker bypasses ufw firewall rules
• unrouted – Solution using iptables. Not for Swarm. It clobbers the INPUT chain, which is used by encrypted overlay with Docker Swarm
• The big thread about Docker and a firewall
• Arch Linux wiki to the rescue to show iptables flow which links to a great visual
  
  

The post Secure Docker with iptables firewall and Ansible appeared first on Ryan Daniels.

TL;DR:
Website owners: Be careful when using third-party code that you don’t control.
Users: Hope for the best! Use a content blocker browser add-on like uBlock Origin. On your mobile device use Firefox with uBlock Origin.

What’s the problem?

Abandoned or unmaintained websites can be re-registered by malicious people. Any website using third-party code could be a victim.

To highlight the issue, let’s look at a specific example. This example luckily wasn’t extremely malicious. It could have been much worse! But it still highlights the current state of the web.

Recently there was an issue where 800+ websites were using javascript from an abandoned free service called “New Share Counts” which counted the number of Twitter shares.

Image of malicious code:

Securi and BleepingComputer have great write-ups on the details.

The problem is this third party website stopped offering their free service. They notified users via their website and eventually the resources they used for counting Tweets were abandoned. This included the Amazon S3 bucket they used. Unfortunately many website owners didn’t get the notice, or ignored it.

Image of a website including the malicious code in their source code:

According the research from BleepingComputer, on October 3rd the AWS S3 bucket was cancelled and on October 4th a “bad actor” registered a new AWS S3 bucket under the same name. Up until October 23rd, all 800+ websites that didn’t remove this javascript file were serving all of their visitors with a malicious script which redirected mobile users to a scam website.

As of October 23, 2018: the malicious javascript (newsharecounts.s3-us-west-2.amazonaws.com/nsc.js) has been blocked on the AWS S3 bucket. It is returning the error: Access Denied

Update October 28, 2018: AWS will not confirm the S3 bucket was banned on their side. The malicious code could return at any time, and possibly be worse next time. According to AWS they need other people to alert them if the malicious content re-appears! From AWS: “Should you see the content return or similar appear, please report it immediately.”

Update October 31, 2018: Malicious javascript is back online.

Update November 9, 2018: From AWS: “Content in question is not currently accessible”.

Update January 9, 2019: Malicious javascript is back online, again.

Update January 14, 2019: From AWS: “We have again blocked the content.”

Who can fix this?

• Individual website(s) that include the third-party malicious code
• Hosting provider where the malicious code resides
• Web browser blocks malicious code
• Web browser add-on blocks malicious code
• You and me? Social media? News outlets?

Unfortunately it’s hard to get all 800+ websites to fix this on their sites. So ultimately we need the company hosting the malicious content to step in.

It seems having this issue in the news and social media definitely helps put pressure on those who can take the malicious content down. In this case it was an Amazon S3 bucket hosting the malicious javascript.

But why is this so hard? Just take down the malicious code!

What about the hosting provider?

In this case, I submitted an abuse report to AWS the night of October 15th. It was only after Securi and BleepingComputer published news articles on October 16th/17th and some pressure on social media did AWS acknowledge the issue (to me at least). Then it took AWS over a week to take the resource down*. And that was only after countless back and forth emails with them. Thankfully, at least for now, the malicious javascript has been removed.

At first they said this malicious script didn’t violate their terms of service! I had to read through their terms of service (TOS) and provided them with exact details of how this malicious script actually does violate their TOS.
Such a painful process!

• At the time of publishing this post, AWS has not confirmed they took the malicious script down due to a violation of the terms of service. So hopefully this malicious script won’t come back online in the future at the same location!

A browser add-on can also help

I had a feeling it was going to take the hosting provider a while to respond, since these things take time. As a work-around, a browser add-on to the rescue!
uBlock Origin added this malicious javascript to their content filtering add-on 25 minutes after I opened an issue with them! Now that’s fast! So at least anyone using this popular browser add-on would be protected (well that is if they use Firefox on their mobile device, which actually isn’t the dominant browser).

What about the browser itself?

The most recent version of Firefox 63 now has Tracking Protection. But this can only block entire domains and not specific files. So that can’t help in this case.
Directly in the Chrome browser? Not currently an option either.

You and me? Social media? News outlets?

Unfortunately that seems to be what it’s come to. More on that below.

Luckily this example wasn’t worse. The malicious code only redirected a mobile user to a scam website when they pressed their back button on one of the 800 affected websites. It could have been cryptocurrency mining malware, or code to exploit some bug in Android or iOS. Who knows, maybe the hosting provider would respond much faster if it was more serious? Or the website owners? Maybe.. Maybe not.

Solution for users

Unfortunately web users have little control over what a website is serving their browser. One thing that can help is using a content filter add-on for your browser like uBlock Origin for Firefox or for Chrome. In the above case the malicious code was only affecting mobile users. Only Firefox supports add-ons for their mobile browser. This is another reason to use Firefox on your mobile devices! In a related post, check out how easy it is to upgrade your privacy using Firefox.

Long term solution for website owners

Website owners need to be careful when adding third-party code to their websites. However, this is extremely difficult in today’s modern web. Often websites use many, many different third-party services.

One solution is to host all third party code locally on your web server. Unfortunately, this has it’s own issues since there would no longer updates to the code by the developer unless the website owner manually updates their site.

Another solution is to use Subresource Integrity (SRI). Unfortunately this can be tedious to implement for a website owner. And even worse, if you use a CMS like WordPress, you rely on the plugin developer to implement SRI into their plugin or theme. There is a WordPress plugin called (SRI) Manager which can help add SRI to all plugins, but your mileage may vary with getting it to work.

Conclusion – Who should fix this?

Who can fix this versus who should fix this is a good question. In my opinion, this should be the responsibility of the individual website. However, getting 800+ websites to fix this in a timely manner.. not going to happen (and it didn’t in this example!). As of the time of this post, most websites still include a link to the malicious code on their sites! Thankfully now it does nothing since it no longer exists.
It really needs to be easier for website owners to have secure third-party code on their website, otherwise we continue down this path.

Who needs to drive this change?

Specifically in the above example of “New Share Counts,” was it only a concerned internet user (myself) that made this happen?
Probably not, since it was in the news. That’s probably the only reason there was any traction. But regardless, I contacted an infected website (which I randomly found while surfing the net. Mind you, only one website of 800+), initiated an abuse case with the hosting provider (AWS) where the malicious code was, and lastly, initiated a support ticket for a work-around using a popular browser add-on.

Maybe other people also contacted the hosting provider. Maybe I should have contacted more content filtering browser add-ons? More pressure on social media? Or something else in addition?

Maybe more people need to take action against these issues after they happen.

The next question is, who should be driving this overall change to make it easier to secure third-party code on websites? That’s also a great question..

However, until that’s figured out we need individuals and news outlets to raise these issues when they happen.
For instance, open abuse reports with the hosting provider, try to inform the websites impacted, find work-arounds when it’s taking too long. Raise awareness on social media platforms.

Currently, that’s all we can do. That is, if the issue is even detected in the first place.

Timeline

For anyone interested, here’s a timeline of events for the “New Share Counts” issue from what I observed. This isn’t meant to single out the hosting provider (AWS) in particular, they are probably flooded with abuse reports. But still, their generic responses are pretty funny. Bold used for emphasis.

2018/10/14 23:13 EST – Randomly found issue on one specific website (Latest Hacking News) while surfing the net on my couch (on my phone) and informed them about malicious javascript on their site.
https://i.imgur.com/4E6uSx5.png

2018/10/15 17:19 EST – Emailed “Latest Hacking News” with more details. Including script where the malicious javascript is located.

2018/10/15 17:47 EST – Abuse report submitted to the hosting provider (AWS). ( where malicious javascript is hosted: newsharecounts.s3-us-west-2.amazonaws.com/nsc.js ). Gave details on what this malicious javascript is doing and how to reproduce malicious behaviour.

2018/10/15 17:55 EST – Response from hosting provider: Generic response asking for logs.

2018/10/15 18:04 EST – Replied to hosting provider: Gave info where they can find a site infected with the malicious javascript. Also, exact steps to reproduce malicious behaviour.

2018/10/16 06:56 EST – Securi publishes article about malicious redirects from newsharecount.

2018/10/16 11:06 EST – “Latest Hacking News” removed the malicious javascript from their website.

2018/10/17 03:00 EST – BleepingComputer publishes article.

2018/10/17 18:22 EST – Replied to hosting provider via email: No response from hosting provider (AWS) since 15th. Asked for abuse case to be expedited and if they can shutdown this AWS S3 bucket / javascript file. Also mentioned to AWS this was now in the news via Securi and BleepingComputer.

2018/10/17 18:33 EST – Reply to BleepingComputer’s tweet, including AWS twitter handle to highlight lack of response from AWS.

2018/10/17 18:39 EST – Hosting provider responded via email: “This case has been investigated and being resolved by the appropriate team.”

2018/10/17 19:15 EST – Submitted issue with uBlock Origin (browser add-on to filter content) via their Github issue tracker.

2018/10/17 19:40 EST – uBlock Origin now blocks this malicious code. Only took 25 minutes! Anyone using the uBlock Origin browser addon (on mobile device) will not be affected by the malicious javascript.

2018/10/18 03:48 EST – Hosting provider responds via twitter that they are investigating.

2018/10/18 04:46 EST – “Latest Hacking News” responded via twitter, with thanks for finding the malicious javascript on their website.

2018/10/19 09:41 EST – Hosting provider responded via email:
“We understand your concern regarding the continued availability of the content you have reported. As noted previously, AWS customers are responsible for their activity on AWS. As a courtesy we notified our customer of your request to have the content removed or access disabled, however, as we do not consider this content to be in violation of our terms, we are not able to take additional action. We strongly encourage you to continue to work with our customer directly to address the concerns that you may have.”

2018/10/19 10:12 EST – Replied to hosting provider via email:
“It’s unfortunate that this bad actor’s malicious script/bucket can’t be removed since it is clearly hijacking users mobile browsers to serve them ads/malware/malicious script. I suspect that notifying the current AWS customer which owns this bucket will have no result, since they are responsible for this malicious script in the first place.”

2018/10/19 10:29 EST – Hosting provider responded, via email, stating the same thing again and the case was closed:
“As noted previously, AWS customers are responsible for their activity on AWS. As a courtesy we notified our customer of your request to have the content removed or access disabled, however, as we do not consider this content to be in violation of our terms, we are not able to take additional action. We strongly encourage you to continue to work with our customer directly to address the concerns that you may have. This case has been resolved by the appropriate team.”

2018/10/19 18:26 EST – Replied to hosting provider via email. I read through all of their Terms of Service and found where this malicious javascript violated their terms in two places. Provided details about how this malicious javascript was breaking their TOS in those two places.

2018/10/19 19:08 EST – Hosting provider responded via email:
“Thank you for your reply. We are looking into this issue further and passed it on to our customer.”

2018/10/23 16:30 EST – “Abandoned Tweet Counter Hijacked With Malicious Script” Podcast from Security Now! about this issue. Episode #686 Audio & Video.

2018/10/23 19:45 EST – Noticed http://newsharecounts.s3-us-west-2.amazonaws.com/nsc.js is down. Returning error: “Access Denied”.

2018/10/23 19:48 EST – Replied to hosting provider via twitter: Asking hosting provider to confirm they took down the javascript due to violation of their terms.

2018/10/25 16:53 EST – Replied to hosting provider via email:
“Can you confirm this S3 bucket is now suspended and can’t be used again?”

2018/10/27 – No response from the hosting provider at time of this post.

2018/10/28 09:19 EST – Hosting provider responded, via email:
“At this time the content appears to be no longer active or available. If you have any evidence otherwise, please let us know.”

2018/10/28 09:27 EST – Replied to hosting provider via email, asking for confirmation the S3 bucket is suspended and if not, to do so.

2018/10/28 09:39 EST – Hosting provider responded, via email. Due to privacy policies they cannot discuss what actions have been taken, and:
“Should you see the content return or similar appear, please report it immediately.”

2018/10/31 17:42 EST – Replied to hosting provider via email. Malicious content is back online.

2018/11/06 11:05 EST – Hosting provider responded via email.
“We have begun our investigation into the source of the activity or content you reported.”

2018/11/09 04:28 EST – Hosting provider responded via email.
“Content in question is not currently accessible.. If you believe this content is still live, please provide additional evidence and we will be sure to investigate further. At this time please consider this case as resolved.”

2019/01/09 05:42 EST – Emailed hosting provider. Malicious content is live, again.

2019/01/14 08:55 EST – Hosting provider responded via email.
“Thank you for advising us that the content has been uploaded again. We have again blocked the content.”

The post Malicious code and abandoned websites appeared first on Ryan Daniels.

The below commands are based on the post Upgrade your SSH keys. Check that out for more details.

Identify and rename old ssh keys

First, identify your old ssh keys:

$ cd ~/.ssh
$ for sshkey in $(ls *.pub);do echo $sshkey;ssh-keygen -lf $sshkey;done
/home/ryan/.ssh/id_rsa.pub
2048 SHA256:gIDkzI98pEna3j9+2Ja5di0+k2dCaXtCtx6k71dskA1 ryan@home (RSA)

From the output, this is showing it is an RSA 2048 key.

Next rename your old public and private ssh keys:

$ mv id_rsa.pub id_rsa_legacy.pub
$ mv id_rsa id_rsa_legacy

Stop using insecure keys

Use only keys that are greater than RSA 2048, or Ed25519.
Specifically, remove:

• DSA
• RSA 1024 and 2048
• ECDSA

Just be sure you aren’t using these ssh keys. Only remove them when you no longer need them and have the new keys setup and working.

Create or Change your existing password

If you old RSA ssh key didn’t use a password, now is the time to set a password. You can upgrade ssh keys that previously existed and didn’t use a password, without breaking anything. Also adding 100 rounds helps make your old key more secure when at rest if you need to continue using it.

$ ssh-keygen -f ~/.ssh/id_rsa_legacy -p -o -a 100

Upgrade ssh keys – Generate RSA 4096 ssh keys

RSA 4096 is good to use for legacy systems which do not yet support the new Ed25519 key.

Generate the RSA 4096 keys, and make sure to use a strong password:

$ ssh-keygen -t rsa -b 4096 -o -a 100
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ryan/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ryan/.ssh/id_rsa.
Your public key has been saved in /home/ryan/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:732MQCPPaMS815Y7MFXl4n2WXuawR1Zsat+PEG1TnPA ryan@home
The key's randomart image is:
+---[RSA 4096]----+
|         +. o+.oo|
|        o * .+*..|
|         B oo=Eo.|
|          =o=..oo|
|        S .BoBo+=|
|         .  *.Ooo|
|          .  B =.|
|        .   B * .|
|          .... . |
+----[SHA256]-----+

The “-o -a 100” means it is harder to crack the private key’s password using brute-force attacks. If your legacy system doesn’t support this, remove this option.

Upgrade ssh keys – Generate Ed25519 ssh keys

Ed25519 ssh keys work on modern systems (OpenSSH 6.7+) and are much shorter than RSA keys. Note, the “-o -a 100” option is implied with Ed25519 key generation.
Generate your new Ed25519 key and use a strong password:

$ ssh-keygen -t ed25519
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ryan/.ssh/id_ed25519.
Your public key has been saved in /home/ryan/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:oU44/TftLl2/d4IKQla36Z1TMqrcdK1xBcerye78fxM ryan@home
The key's randomart image is:
+--[ED25519 256]--+
|        . .      |
|     . . . . .   |
|    . o .   o o .|
|   .   + . o o = |
|    . + S * + +  |
|     = . = B  .E |
|      + B.=.oo ..|
|       =.=o.o ..=|
|      ..oo=+o..+=|
+----[SHA256]-----+

Now you have both RSA 4096 and Ed25519 ssh keys ready to go.

Next, add the keys to your ssh agent so it will remember the keys for you.

Install and configure ssh agent

Using an ssh agent allows you to type in a password once, and then the agent remembers the ssh keys.

On Ubuntu 16.04 there is one problem though. The built-in Gnome-keyring doesn’t support Ed25519. To work-around this, you could use the normal ssh-agent. But, I suggest instead to use gpg-agent and disable the gnome-keyring.

The below commands are based on the Arch wiki and an answer from the Ask Ubuntu Forum.

Disable Gnome ssh keyring daemon (reference):

$ cp -rp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
$ echo "Hidden=true" >> ~/.config/autostart/gnome-keyring-ssh.desktop

Install gpg-agent:

$ sudo apt-get install gpa gnupg-curl

Enable ssh support in gpg-agent, and set a timeout to remember the key and password for 1 hour, since this adds some convenience:

$ echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf
$ echo "default-cache-ttl-ssh 3600" >> ~/.gnupg/gpg-agent.conf
$ echo "max-cache-ttl-ssh 3600" >> ~/.gnupg/gpg-agent.conf

Edit your .bashrc to automatically load gpg-agent when you log in.

$ vi ~/.bashrc
# Set SSH to use gpg-agent
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="~/.gnupg/S.gpg-agent.ssh"
fi

Reload gpg-agent:

$ gpg-connect-agent reloadagent /bye

Next, add your new ssh keys to the gpg-agent:

$ ssh-add ~/.ssh/id_ed25519 ~/.ssh/id_rsa ~/.ssh/id_rsa_legacy

You will be prompted to enter your ssh key password. And after you enter that, another prompt will pop-up, from the gpg-agent. It will be used to unlock the gpg-agent’s key storage. This should be a different password than the password for your ssh keys. You will be prompted to enter this password every time you log in, or after the 1 hour timeout.

Enter the password that you want to use to unlock the gpg-agent key storage. And if you use the same password here for all your ssh keys, you only have to unlock it once:

And now you can list your keys stored in the gpg-agent:

$ ssh-add -l -E md5 # list fingerprint using md5 hash
$ ssh-add -l        # list fingerprint using sha256 hash
$ ssh-add -L        # list public key parameters

Re-deploy the new public keys

Lastly, you need to add your new public keys to your servers. This command will ssh to your server and add your new public keys to the authorized_keys file.
Change 1.2.3.4 to your server’s IP:

$ ssh 1.2.3.4 "mkdir -p .ssh;echo $(cat ~/.ssh/id_ed25519.pub) >> .ssh/authorized_keys;echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys;chmod 700 .ssh;chmod 640 .ssh/authorized_keys"

Be sure to do this for ever server you connect to.

Important: Be sure you don’t lock yourself out of your servers. Have another session open and test to make sure you can log in again after making this change.

Now you can remove your old ssh key from the ssh agent and only use the secure ssh keys:

$ ssh-add -d 2>/dev/null;ssh-add ~/.ssh/id_ed25519;ssh-add ~/.ssh/id_rsa

Be sure to add the Ed25519 key first, like above. Since it seems to be a feature that prioritizes RSA keys first. So add the Ed25519 key first.

SSH to your servers to test the new key is working. You can also see in the logs the type of ssh key being used.

Confirm using the new Ed25519 ssh key, on Ubuntu 16.04:

$ grep " sshd\[" /var/log/auth.log|grep "Accepted publickey"|tail
Feb 11 10:00:00 home sshd[1802]: Accepted publickey for ryan from 192.168.1.100 port 60708 ssh2: ED25519 SHA256:oU44/TftLl2/d4IKQla36Z1TMqrcdK1xBcerye78fxM

Conclusion

Now you have more secure ssh keys since you are using Ed25519 and RSA 4096 keys. You have been able to upgrade ssh keys that are insecure! Next, you should look into updating your ssh server and client settings to use better encryption settings, using these references.

And if you don’t want to manually deploy the new ssh keys to all of your servers, instead you can use Ansible for user management.

The post Upgrade SSH keys and use gpg-agent with Ed25519 keys appeared first on Ryan Daniels.

Using a VPN (Virtual Private Network) can help to protect your privacy. You can use a VPN to appear like you are in another country so you can reach a website that was previously blocked. You can also use a VPN to stop your ISP from restricting you to certain websites, and when travelling to protect your data while using insecure WiFi. There are many many more reason. However, there can be an extra benefit to using a VPN that people don’t usually think about: Automatic content blocking (also known as ad blocking).

Why?

Ad blocking is now a necessity because of dangerous ads. Some ad networks have had problems with ads containing malicious JavaScript which is actually malware. Even recently YouTube was showing ads that contained a cryptocurrency miner. An add-on like uBlock Origin for Firefox or Chrome can help. And customizing your Firefox privacy settings will also help. But what if apps on your phone are showing dangerous ads? Or, what if you have an old phone that’s no longer getting updates and you want better protection from the recent Meltdown vulnerability? A browser add-on alone will not help you.

Now, combine the benefits of a VPN, and ad blocking into one solution. This is where OpenVPN with ad blocking using dnsmasq comes in. For this to work you need control of the OpenVPN server configuration. So using a VPN provider is not an option. But, this way is cheaper! Plus you get the satisfaction of setting up your own VPN!

Setup a Raspberry Pi with OpenVPN

You can create your own VPN with a Raspberry Pi. If you live in Canada, a good way to get started is with the Raspberry Pi 3 CanaKit. There are many guides for setting up a Raspberry Pi with OpenVPN.

However, this method won’t help if a website restricts your country, or if your ISP blocks you from certain content, since you will have the Raspberry Pi at home. But, you can still use this method to protect you when using open WiFi while travelling, or when at home to get the benefit of ad blocking on your mobile devices.

Setup a VPS with OpenVPN

If using a Raspberry Pi isn’t your thing, you can buy an inexpensive VPS (Virtual Private Server) and host your VPN from there. This may seem like more work, but it’s pretty easy. And with a VPS you don’t need to worry about exposing your home network to the public internet. Also, when using a VPS that is only for OpenVPN, you can use common ports to have a better chance of being able to connect to your VPN.

Linode is a great VPS provider for $5 per month. Or, Vultr offers a VPS for $2.50 per month! (For IPv6 only, IPv4 is $3.50). Whichever VPS provider you choose, make sure to create your VPS in a country that’s right for you. For example, if you need to access a website usually only available to a certain country. Also make sure you obey their TOS.  I’m not responsible for anything you do from following this guide!

When using your own VPS, I suggest setting it up with OpenVPN using the Streisand project. It has many options to bypass blocking if you live in an oppressive country. Note that the commands below will only install OpenVPN (with stunnel) if using Streisand. Plus, Streisand does a good job at protecting your VPS with security tweaks and automatically updating packages.

Install OpenVPN

You can install OpenVPN many different ways. Here are two ways I recommend:

To install OpenVPN via PiVPN, follow these steps.

To install (only) OpenVPN (also with stunnel) via Streisand, follow the prerequisites steps, and then run:

$ remote_server_IP=1.2.3.4  # Change IP to your VPS/remote server IP
$ git clone https://github.com/ryandaniels/ansible-role-dnsmasq-adblock.git ~/ansible/roles/dnsmasq-adblock
$ git clone https://github.com/StreisandEffect/streisand.git && cd streisand
$ ~/streisand/deploy/streisand-existing-cloud-server.sh --ip-address $remote_server_IP --ssh-user username123 --site-config ~/ansible/roles/dnsmasq-adblock/files/streisand-local-site.yml

Change “remote_server_IP” to your server’s IP.
This will use the user “username123” with ssh keys for a passwordless ssh connection. Be sure to use a use that you’ve setup with ssh keys.

Setup ad blocking for OpenVPN using dnsmasq

Now that you have OpenVPN setup on a RaspberryPi or your own VPS you are ready for the last step, ad blocking. For this you can use a program called dnsmasq. It performs DNS lookups and you can modify the dnsmasq behaviour to block certain domains.

Manually install and configure dnsmasq on Ubuntu

These steps were modified from this github project by Bob Nisco and also uses Steve Black’s host project.

Install and configure dnsmasq using the DNS servers from OpenDNS:

$ sudo apt-get -y install dnsmasq
$ sudo wget https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts -O /etc/hosts_blocked

$ sudo cat > /etc/dnsmasq.conf << 'EOF'
domain-needed
bogus-priv
no-resolv
server=208.67.222.222
server=208.67.220.220
listen-address=127.0.0.1
listen-address=10.8.0.1
addn-hosts=/etc/hosts_blocked
EOF

Configure OpenVPN:

$ sudo vi /etc/openvpn/server.conf

Add below, and make sure no other lines have “dhcp-option DNS”:

push "dhcp-option DNS 10.8.0.1"

Create a script to update the domains being blocked. And have it run every week:

$ sudo cat > /etc/cron.weekly/adblock_dl_hosts << 'EOF'
#!/bin/bash
wget https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts -O /etc/hosts_blocked && systemctl restart dnsmasq.service
EOF

$ sudo chmod +x /etc/cron.weekly/adblock_dl_hosts

Restart dnsmasq and OpenVPN:

$ sudo systemctl restart dnsmasq.service 
$ sudo systemctl restart openvpn.service

Using Ansible to automatically install and configure dnsmasq on Ubuntu

If you are familiar with Ansible, then you can add a new role to handle the installation and configuration of dnsmasq for ad blocking automatically. If you are not familiar with Ansible but want to know more, check out my post explaining what is Ansible.

I’ve created this Ansible role to configure dnsmasq on Ubuntu or Raspbian.

Create the Ansible Playbook:

$ cat > ~/ansible/install-dnsmasq-adblock.yml << 'EOF'
---
- hosts: '{{inventory}}'
  become: yes
  roles:
  - dnsmasq-adblock
EOF

If using PiVPN or a normal OpenVPN installation (and not Streisand), clone the git repository and run the Ansible Playbook:

$ git clone https://github.com/ryandaniels/ansible-role-dnsmasq-adblock.git ~/ansible/roles/dnsmasq-adblock
$ ansible-playbook install-dnsmasq-adblock.yml --extra-vars "inventory=openvpn-server" -i hosts

If you are using Streisand, then you already cloned the git repositories. Just run the Ansible Playbook:

$ ansible-playbook install-dnsmasq-adblock.yml --extra-vars "inventory=streisand-host adblock_manage_openvpn=false" -i ~/streisand/inventories/inventory-existing

Conclusion

In conclusion, now you are more secure by using OpenVPN with ad blocking on your own Raspberry Pi or VPS. And if you are using your own VPS you can use the Streisand project to secure your installation and also to expose common ports to have a higher chance of being able to connect to your VPN from anywhere.

The post How to setup OpenVPN with ad blocking on Raspberry Pi or a VPS appeared first on Ryan Daniels.

Firefox is a fast and customizable web browser. And with the latest version called Firefox Quantum (version 57), it is faster than ever! It is great to load websites fast, but there’s another amazing feature. Changing the Firefox privacy settings to be more effective at making user tracking more difficult.

You are hopefully already using a content blocking add-on like uBlock Origin, to help eliminate things you don’t want to see (like maybe one or two ads), and also for your online safety. Customizing Firefox privacy settings is the next step.

To do this, normally you open a new tab, and type in “about:config”. Then you get tons of different settings to modify.

You can end up changing a lot of settings, all manually. But it can be easier, if you know how to save all your settings into a configuration file. And this works cross-platform (on Windows, Mac, Linux) as well.

The Problem

Nobody wants to manually type all these changes into Firefox. Especially in multiple places, like in your Firefox browser on your home computer, and your Firefox browser on your work computer.

What settings to change?

I keep mentioning changing settings, but what settings should you change? That’s a very good question. I’ll group the changes into two categories: Privacy and Usability. If you already know what you are doing, jump ahead to making the changes. If not, read on.

Firefox Privacy related changes

For some insights into what to change to be more secure, I recommend starting with privacytools.io. They have a helpful section for Firefox privacy settings. The entire website is good actually.
Another good resource is Firefox Profilemaker.
Keep in mind you should test after making a change, since websites can stop working!

The list of changes that I use is available on GitHub.

However, some changes might not work on the websites you use. So again, be sure to test. And take some time to understand what you are changing.

Firefox Usability changes

These changes are mainly to improve Firefox with my own personal preferences.

The biggest change for me was the tab sizes. I keep many tabs open (yes, probably way too many). And with Firefox 57, I find the tab width gets too small with many tabs open.

/* Fix tab width too small */
user_pref("browser.tabs.tabMinWidth", 100);

/* Change homepage */
user_pref("browser.startup.homepage", "https://startpage.com/");

/* Increase disk write timer to prevent SSD from dying
 * Source: https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/
 */
user_pref("browser.sessionstore.interval", 120000);

/* Turn off Smooth Scroll */
user_pref("general.smoothScroll", false);

/* Turn off warning on about:config */
user_pref("general.warnOnAboutConfig", false);

/* disable onboarding junk */
user_pref("browser.onboarding.enabled", false);

How to automatically change Firefox settings

Here are the steps to make all the configuration changes in Firefox. And without having to use “about:config”. Put all desired changes into a configuration file and then Firefox reads from this file when it starts.

Here are the steps:

1. Put all of your configuration changes into a file named: user.js
2. Open your profile directory, which you can find in “about:support” or “about:profiles”
3. Save this file into your profile directory
4. Restart Firefox. This overrides the previous settings with the user.js file when Firefox starts
5. Optional: Rename user.js file to something like user-unused.js

Renaming user.js  will make sure not to override the settings again, in case you do make the changes in “about:config”. However, it could be good to keep this file in place in case Mozilla gets any ideas about changing your default search engine without asking you (if you have that in user.js of course). Not that Mozilla would ever do something like that..

Conclusion

To summarize, now you have put all your Firefox privacy and usability settings into your user.js file. You can now copy this file to your other Firefox profiles, on your other computers, and automatically have the same settings loaded into Firefox. As an added bonus, you have now made user tracking more difficult.

Have a question? Contact me.

The post Firefox privacy and custom settings made easy appeared first on Ryan Daniels.

WordPress Security is very important. It is much easier spending a few minutes securing WordPress, then spending hours recovering from being hacked. Security is becoming even more important because of the increase in automated brute force WordPress attacks. Below are a several tips to help secure WordPress and Apache. If you have your own server or VPS (like Linode or Vultr), to help reduce brute force attacks a very good solution is to use CloudFlare custom “Page Rules”. That will stop the requests before even getting to your server. WordPress security doesn’t sound like an exciting topic, but it is important so read on!

To help reduce other vulnerabilities follow the rest of the tips to improve WordPress security. The best advice for this is to stay updated and delete ALL unused themes and plugins. An old theme or plugin that is no longer being developed is potentially very easy for an attacker to exploit through an old vulnerability. This is most likely how an attacker puts a backdoor into a site since WordPress on its own is secure.

Any comments, questions or suggestions are welcome in the comments section at the bottom or from the contact page.

2013/12/31: Added information about minimizing number of plugins and OSSEC.
2014/09/29: CloudFlare offers free HTTPS.
2016/09/28: Update from 5G Blacklist to 6G Firewall, and add blocking for xmlrpc.php.

#1. Stay updated

Keep WordPress, themes and plugins updated. Also if you run WordPress on your own server or VPS keep apache, php5 and other packages up to date. This is the most important for WordPress security and also general web server security.

#2. Delete unused themes and plugins

Deactivating a theme or plugin that isn’t in use is not good enough. It needs to be completely deleted because the files can still be accessed (and exploited). This is probably the most common way an attacker will gain access to your server and a major benefit to improve WordPress security in general. Another good practice is to reduce the number of plugins running. If you don’t really need it, then delete it.

#3. Activate CloudFlare

Use CloudFlare’s free service to utilize them as a CDN and more importantly use their built in security features. You can also try to use IPtables to block brute force attacks, but a much simpler solution is to use CloudFlare.
The only negative about the free CloudFlare service is that it cannot use HTTPS. (That is a paid only feature).
To use CloudFlare you must be able to edit the DNS settings of your domain (to change the NS records).
When using CloudFlare make sure to setup custom “Page Rules”. This will greatly reduce the login requests that make it to your server. What better way to improve WordPress security than to not even get the malicious requests!

Setup “Page Rules” using URL Pattern: “/wp-login.php*” (without quotes)
Change:
Always Online: Off
Security Level: I’m Under Attack
Browser Integrity Check: On

This will use Cloudflare to verify every login attempt (even your own) before getting to your server. After this change there will be very little traffic to the WordPress login page, since CloudFlare will be blocking most (if not all) of it.

#4. Remove the default “admin” account

Make sure the admin account is removed. This is one of the basic steps to improve WordPress security since automated attacks usually focus on this login, and if it isn’t there then it can’t be exploited.

Create another account with administrator privileges and then delete the admin account, or use a plugin that is mentioned below.

#5. Secure Passwords

Be sure to use a very secure password of random characters consisting of upper case, lower case, numbers and punctuation. Even if someone figures out the login name it will still be relatively secure if a strong password is used.

#6. Restrict access to WordPress login using .htaccess

It is a very good idea the restrict access to wp-login.php and the wp-admin directory to help with WordPress security and security in general. By restricting these pages based on an IP address it will cause anyone other than that IP to be blocked from logging in. CloudFlare is also a very good option (as previously mentioned) to help block access to logging in. If an attacker does get past the CloudFlare security, they will likely not get past this.

If you use CloudFlare use the first entry. Use either your exact IP or an IP range. You will probably need an IP range if your IP address changes often. Note that these requests still make it to your server. To further block access use CloudFlare page rules (as previously mentioned) if you can.

Be careful editing .htaccess files since you could potentially lock yourself out of WordPress. It’s best to have SSH access to your server.

For wp-login.php edit the main .htaccess file

If using CloudFlare (commented out line is for an IP range):

<files wp-login.php>
#SetEnvIf X-FORWARDED-FOR "^1\.*\.*\.*" allow
SetEnvIf X-FORWARDED-FOR "1.1.1.1" allow
order deny,allow
deny from all
allow from env=allow
</files>

If not using CloudFlare (commented out line is for an IP range):

<files wp-login.php>
order deny,allow
deny from all
#allow from 1.0.0.0/8
allow from 1.1.1.1
</files>

For wp-admin restriction edit the .htaccess file inside wp-admin directory

If using CloudFlare (commented out line is for an IP range):

SetEnvIf X-FORWARDED-FOR "1.1.1.1" allow
#SetEnvIf X-FORWARDED-FOR "^1\.*\.*\.*" allow
order deny,allow
deny from all
allow from env=allow

<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
</Files>

If not using CloudFlare (commented out line is for an IP range):

order deny,allow
deny from all
allow from 1.1.1.1
#allow from 1.0.0.0/8

<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
</Files>

#7. Reduce malicious URL requests

Use the 6G Firewall 2016 to reduce malicious URL requests. The list should be put at the beginning of the main .htaccess file. This helps in WordPress security since it stops an attack before it gets to the WordPress layer.

#8. Rename WordPress tables prefix

When first installing WordPress make sure to change the table prefix from the default “wp_”. If WordPress is already installed a plugin (like Acunetix WP Security, more on that below) can be used to easily make the change to something random like “notforyou_”. This will help WordPress security since attackers are less likely perform SQL injection attacks.

#9. Use WordPress Security Keys

Use the WordPress Security keys to make your stored passwords more secure and also by changing them it forces anyone that’s already logged in to re-authenticate. Overwrite the keys in the wp-config.php file after generating them here.

#10. Other tweaks using .htaccess

Remove access to readme.html and access to other unnecessary WordPress related files. This will improve WordPress security since it will be harder to determine the WordPress version. This also blocks other WordPress specific files. Blocking the xmlrpc.php file is a really good idea to prevent brute force login attempts unless you use the JetPack plugin, or another 3rd party tool to edit your posts.

Put at the bottom of main .htaccess file (After 6G Firewall 2016 and WordPress entries).

<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files xmlrpc.php>
Order allow,deny
Deny from all
</files>

#11. Remove WordPress version information

If an attacker doesn’t know the version of WordPress it can be harder to exploit since they can’t target a known vulnerability of an older version. This will help to improve WordPress security but there are many ways a determined attacker can gather this information. This will help with the basic attacks.
Edit the child theme’s functions.php file to include:

function wpnohead_remove_version() {
return '';
}
add_filter('the_generator', 'wpnohead_remove_version');

#12. Disable file editing in WordPress

If an attacker gains access through WordPress they can’t do much damage if they are unable to edit files on the server which will improve WordPress security.

Edit wp-config.php to include:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

#13. HTTPS for logins

If possible use HTTPS for logins. When using the free CloudFlare service this is not possible since only paid users can use HTTPS. CloudFlare now offers free HTTPS for everyone, so this will work if you are using CloudFlare.
If you can use HTTPS put this in wp-config.php (see info):

define('FORCE_SSL_LOGIN', true);

#14. Take regular backups

This doesn’t help WordPress security directly, but in general it is a very good idea. Use the plugin WP-DBManager to schedule automatic backups that can be emailed to you. If an attacker does get in this will help in the recovery.

#15. Security Plugins

Here are some security plugins that can come in handy to help with WordPress security.

Better WP Security – Can move login pages, rename admin account and change database table prefix. Moving login pages can help, since the attacker can’t easily find where to login (security through obscurity), but this isn’t needed if other measures are followed (Restrict access using .htaccess and CloudFlare page rules).

Acunetix WP Security – Can change database table prefix and perform some useful security audits. Checking files for date changes isn’t very useful since attackers can change timestamps of the files if they are already in your system.

Wordfence Security – Scans for known vulnerabilities. Another good feature is it scans core files, themes and plugins against WordPress.org repository versions to check their integrity. Verifying the security of your source. If/when you remove this plugin make sure to enable the option to remove all of the Wordfence options from your database, otherwise a large amount of data is sitting there. Option is at the bottom of the Wordfence ‘options’ page titled: “Delete Wordfence tables and data on deactivation?”

Limit Login Attempts – Useful if the same IP address keeps trying to login. But with the recent attacks there are many IP addresses trying to brute force the login and password. This plugin is no longer very useful.

AskApache Password Protect – Password protect logins using Apache built in security.

Google Authenticator – Two-factor authentication using the Google Authenticator app for Android/iPhone/Blackberry.

Threat Scan Plugin – Scans PHP files for backdoors added by hackers.

6Scan Security – Another option to use. Haven’t tried it yet.

All In One WP Security & Firewall – Another option to use. Haven’t tried it yet.

#16. Apache tweaks

If you have access to the main Apache configuration add the below lines. This isn’t specifically for WordPress security, it’s for the overall web server (Apache) security. Another obvious Apache security measure is to make sure Apache runs as a non-root user.

Prevent listing the index of folders.
In apache’s virtual host configuration files make sure to have:

Options -Indexes

Remove server signature (from error pages, etc) and remove server version from header requests.
In httpd.conf add these lines to the bottom:

ServerSignature Off
ServerTokens Prod

#17. Use SFTP

Do not use regular FTP since it is insecure. FTP login and password information is sent unencrypted. This is a general security tip and not really specific to WordPress security.

#18. Monitor Apache logs

Check the Apache logs for any errors or abnormal URL requests. This seems trivial but it is a very important step to ensure your site is working smoothly and there is no abnormal behaviour.

If using CloudFlare, make sure to install the CloudFlare module for Apache so the visitor IPs are in the logs and not the CloudFlare IPs.

#19. Host-based Intrusion Detection System (OSSEC)

Install a program that runs on the server to monitor the system’s health and check for exploits. A program like OSSEC is a good choice.

Other Notes

Port knocking with IPTables for WordPress logins is another option to provide further security through obscurity, but this is complicated and beyond the scope of this post about improving WordPress security.

Fail2Ban is another option to scan the Apache logs but this causes excessive load on the server and is not needed with all the changes above.

Another unnecessary but interesting option is hiding a custom field in the login form and using a browser extension to set that field only in your browser. But again this is now not needed.

Any comments, questions or suggestions are welcome in the comments section below or from the contact page.

References

Hardening WordPress
WordPress Consultant
Prevent badware: WordPress
How to Protect WordPress Sites
6G Firewall 2016
How To Protect WordPress from Intrusion: Your Must-Read Checklist
How to Improve the Security of your WordPress Blog
The Definitive Guide to WP Security
How to Password Protect Your WordPress Admin (wp-admin) Directory
Protect your wp-admin with this quick .htaccess trick
Password Protect your WordPress Admin Folder

The post WordPress Security – How to Protect WordPress appeared first on Ryan Daniels.