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.

I could find pretty much nothing about this, anywhere.

Wait, let’s take a step back. What am I talking about?

I was testing iptables with Docker. What a nightmare. Anyways, I noticed something strange with my three node Docker Swarm test VMs. Some very strange rules at the top of the iptables INPUT chain.

# iptables -nvL INPUT
Chain INPUT (policy ACCEPT 33477 packets, 8115K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir in pol ipsec udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100600"
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100600"
   21  3669 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir in pol ipsec udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100100"
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100100"
    1   101 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir in pol ipsec udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100200"
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:4789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100200"

What is that? Some kind of rules using a Docker port, and something about IPSEC.

Searching the internet has no information about this, that I could find at least. Only some random Docker issues on GitHub. It does have some similar details in the INPUT chain though.

Also found were two references to the Docker documentation.

The Docker documentation does have a pretty good section about iptables. But no mention of the INPUT chain. They very specifically say they only modify the DOCKER-USER and DOCKER chains in iptables.

There’s also some information about the overlay network in the Docker documentation, but unfortunately it’s also very high level. No details about the Docker magic that makes all the networking work seamlessly! However, it does mention using IPSEC. Time to do some testing.

When testing in Docker Swarm, by starting containers which use an encrypted overlay I get those iptables rules in the INPUT chain. Fun!

Conclusion

Not a very exciting mystery. But very unexpected that Docker is modifying the INPUT chain in iptables! That changes a few thing when trying to secure Docker.. Hopefully other people weren’t relying on having the last rule in the INPUT chain.

Only Docker knows how their next version of Docker will behave. Anything a user does to try and secure Docker at the network layer is futile.

That being said, I’ve attempted to secure Docker with an iptables firewall. Check it out!

The post Docker and the iptables INPUT chain appeared first on Ryan Daniels.

Background on firewalld

Firewalld is a firewall which runs on many Linux distributions. It is software which runs on a server, and is used to locally secure the server. For example, it can restrict which ports are available for all source IPs, or it can further restrict access by allowing only certain IPs to a specific port (and zone). Check out the documentation to read more about the features of firewalld.

Everything is blocked when firewalld starts! The only exception is for ssh on port 22. This is normally what you want on a new server.

Problem

However, firewalld isn’t with out it’s limitations. To run commands to configure which ports you want to allow through firewalld, you need to have the firewalld service running. But, what if you are adding firewalld to a server that has an application which is already in use? As soon as you start firewalld, it will be blocked!

There are two ways around this.

1. Copy your firewalld config files in the right place, with all the right ports, zones, etc. And then start firewalld. This can work. But having Ansible copy files around and deal with all that is a challenge since firewalld behaves a certain way.
2. Use the “offline” firewalld commands!

Let’s explore options 2. And lucky for us, we want to use Ansible to help us manage this configuration. And, Ansible can make use of “offline” mode.
But, unlucky for us, the Ansible module which handles firewalld can’t do everything. (At least not everything that I want it to do).

I want the configuration for firewalld to be as simple as possible. I don’t want the configuration for services in one place, and the configuration for ports in another.
But more importantly, I don’t want any service interruption.

Solution

Create my own Ansible role that does what I want.

If you’re new to Ansible, check out my Ansible Getting Started Guide.

I want firewalld to behave in a certain way. Meaning if I have an application already running, and I want firewalld to start restricting access, I don’t want an outage on that application as soon as I start up the firewalld service on the server.

Firewalld Limitations

Firewalld does have some limitations. You should be aware of this before using it.
Anything firewalld is not aware of in the back-end (for example if using iptables), will be removed since firewalld wants to be the single source of truth for firewall rules.
This is why firewalld and Docker do not get along.
See details from: here, here, and here.

In case you missed that..
Do not use firewalld and Docker.
Update: Instead, if you need a solution to work with Docker try using iptables directly. See my post about securing Docker with iptables and Ansible.

Firewalld Ansible Role

You can find my firewalld Ansible Role on GitHub or in Ansible Galaxy.

This Ansible Role manages firewalld in offline and persistent mode only. I don’t want to mess around with non-persistent changes. And using online mode is not an option.

It uses the Ansible module for firewalld for a few things, but most changes have to be done using the command module. Specifically: “firewall-offline-cmd”.

Why? What’s the benefit doing it this way? It let’s you create your own custom service in firewalld. Even built-in firewalld services can be used, and easily modified. For example, moving the ssh port from 22 to something else. (Warning, be careful changing your SSH port. You could lock yourself out!)

Here’s a short example of the configuration:

rhel_firewalld_zone_source:
  - zone: internal
    state: enabled
    source:
      - "192.168.22.64/26"
      - "192.168.23.64/26"

rhel_firewalld_custom_service:
  - name: zabbix-agent
    zone: public
    state: enabled
    port_protocol:
    # - 10050/tcp
      - 3333/tcp
  - name: openvpn
    zone: public
    state: enabled
  - name: app123-public
    zone: public
    state: enabled
    description: app123 firewall rules for public zone
    port_protocol:
      - 5000/tcp
  - name: app123-internal
    zone: internal
    state: enabled
    description: app123 firewall rules for internal zone
    port_protocol:
      - 8080/tcp
      - 9000/tcp

In the variable rhel_firewalld_zone_source:
This will configure the Zone named internal to only allow IP ranges that are in source.

In the variable rhel_firewalld_custom_service:
This will configure the zabbix-agent service (which is actually built-in) for the zone public, but not use the default port (of 10050, commented out for demonstration). Instead it’s using port 3333.
The openvpn service is added to the zone public, and will just use the default configuration (since this is also a built-in firewalld service). You need to know it’s built-in, if you don’t specify a port. So it’s usually better to just specify a port all the time!
Last, there are two custom services, app123-public and app123-internal, which are added to their defined zones. They are also adding port 5000 using tcp (attached to the public zone), and adding ports 8080 and 9000 both using tcp (attached to the internal zone).

If you decide you want to change a port, just remove it from the configuration.

More details are on GitHub. Be sure to read the README!

Getting Started – Ansible firewalld

Install from Ansible Galaxy:

ansible-galaxy install ryandaniels.firewalld

Or, clone the GitHub project:

git clone https://github.com/ryandaniels/ansible-role-firewalld.git roles/firewalld

Create the Ansible Playbook, called firewalld.yml:

---
- hosts: '{{ inventory }}'
  become: yes
  vars:
    # Use this role
    rhel_firewalld_managed: true
  roles:
  - firewalld

Make configuration changes add desired firewalld services and ports.

Warning: Be sure you have everything needed in your configuration. Once firewalld is started it blocks anything that wasn’t added!

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!

Then run the playbook:

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

Conclusion

In conclusion, Ansible is now being used to manage firewalld rules! We have a custom firewalld service created using two different zones. The built-in firewalld services are also enabled, but we don’t really care they are built-in, since we can change the port they use if we want.
We have a nice and simple configuration, and this was all done in “offline” mode so there was no impact to any existing services using the ports.

Again, your mileage may vary. Always test in your lab or staging environment first! I’m not responsible for anything you break.

Stay safe!

The post Manage firewalld with Ansible appeared first on Ryan Daniels.

It’s time. Windows users, Upgrade to Linux. Windows 7 is reaching the end of the line after January 14, 2020. Users must upgrade to something else. Do not replace Windows 7 with Windows 10. That is not an upgrade! How else can I say this? Do not downgrade from Windows 7 to Windows 10. Instead, upgrade Windows 7 to Linux!

In case you haven’t heard, do not use Windows 10, for many reasons. It’s a “Privacy Nightmare”!
Also, it’s actually really bad to use. They add junk into your Desktop menu at random. And it will come back even if you delete it.
Do you like ads? Microsoft is infesting Windows 10 with annoying ads.
You are not in control.

And then there’s the many problems with Windows 10 updates. So many crazy problems! It’s just plain bad. Did you know Windows 10 deleted user’s personal data! Also there are problems with Windows 10 booting after updating.

Linux, Everybody’s doing it!

There are so many reason to upgrade to Linux. If all you do on your computer is use a web browser, occasionally open pictures, sometimes open a spreadsheet or text document then you should definitely upgrade to Linux.

Even if you are a power user, there’s probably a Linux application that will replace that Windows app. But, even if there isn’t, you can use software like Wine to run Windows apps on Linux!

Do you game? Steam is an easy way to game on Linux! And it’s easy to install.

And then there’s the Linux community. It is absolutely amazing. When you do have an issue, there is so much help available by just searching.

Top 5 Reasons to switch to Linux

1. Linux just works
2. Linux is more secure
3. Surprise, Linux is easy to upgrade
4. Linux works on old hardware
5. Linux is easy to customize
6. Bonus Reason: Amazing community for help

Which Linux Desktop to Choose?

Linux on the Desktop has many distributions to choose from. There’s no single company to dictate what you can do!

With so many options to choose from, how do you pick? If it’s your first time using a Linux Desktop, try a distro that’s easy to get up and running.
“Linux Mint Cinnamon Edition” is a great choice to get started!

Why? Linux Mint is based on Ubuntu which is very popular and easy to use. If you need help, you will be able to find an answer since Ubuntu is so popular. And Linux Mint uses a nice desktop environment by default, called Cinnamon.

More screenshot can be found on the Linux Mint website.

Don’t want to use Linux Mint Cinnamon? Try Ubuntu instead. That’s what Linux Mint is based on after all! Kubuntu has a very nice desktop environment similar to Windows.

How to Upgrade from Windows to Linux Mint

Test it out before Installing

You can even try out Linux Mint before you install it to your hard drive. Actually most Linux distros can do this! Just download the ISO image and add it to a USB stick using LinuxLive USB Creator. Then reboot your computer and boot from the USB stick. Now you are test driving Linux Mint on your computer! Need a step by step guide? Check out their documentation.

Backup Windows

Before you install, be sure to backup your existing installation. A great tool for this is called Macrium Reflect. This can save an “image” of Windows to a file. Then later when running Linux Mint, you can start up your old Windows image as a virtual machine using VirtualBox!

Install Linux Mint

There are many guides online if you do a search. One thorough guide can be found here.

Conclusion

After you have upgraded to Linux, you are now free from Windows! No more worrying. You are free to enjoy Linux and all it has to offer. Next maybe you want to customize a few things. Linux (and Linux Mint) make that so easy.

Goodbye Windows, Hello Linux Mint!

The post 5 Reasons Why You Should Upgrade Windows to Linux 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.

What’s the problem?

If you have multiple servers to manage, it can be a pain to manually add a new user, change a password, or lock an old account. Manually logging into all of your servers and performing these tasks is a real pain, and a huge waste of time.

Luckily there are several solutions.

Solution: Red Hat IDM

There are many different solutions for user management. Red Hat Identity Management (IDM) is a very good solution that works with many Linux servers. IDM is a central location that holds all the user configuration. And it can even connect to Windows Active Directory.

However, if you don’t have a subscription to Red Hat Enterprise Linux there are other options.

Solution: FreeIPA

FreeIPA is the upstream open source project for Red Hat Identify Management. So you can download the FreeIPA package and follow one of many available tutorials for setting up a server and client.

Solution: Ansible for user management

If the above solutions seem too complicated there’s another option. However, you should really take some time to setup user management properly. Use FreeIPA. It’s free!

But, if you want to use another solution while you are setting up FreeIPA, and you already have Ansible as part of your environment then you have another option. Ansible can do this of course!

The reason Ansible is a decent option for user management is because it is idempotent. This means, Ansible will only make a change if the change is needed to get to the desired state. So you can run the same Ansible Playbook multiple times, and if the Ansible tasks are written properly Ansible will only make a change the first time.

Just keep in mind, I warned you to use FreeIPA. This solution is not “enterprise” grade. But it certainly works for certain scenarios, like in a lab environment. And if you want to use Ansible for something new, there is a user management role available on GitHub or on Ansible Galaxy.

If you aren’t familiar with Ansible, check out my Getting Started with Ansible guide.

This Ansible role is tested on:

• Ubuntu
• Red Hat Enterprise Linux (RHEL) 7.x, 6.5, 5.9
• CentOS 7.x, 6.5, 5.9

What this user management Ansible role does

This role will manage users in the user list configuration file (list is in the file vars/lab_users.secret in the example below).
It can add users, change passwords, lock/unlock user accounts, manage sudo access (per user), add ssh key(s) for ssh key based authentication.
This is done on a per “group” basis (using Ansible group variables), as set in the configuration file. The group comes from the Ansible group as set for a server in the inventory file.

Note: Deleting users is not done on purpose.

The great thing about Ansible Playbooks, if you don’t like something it’s easy enough to modify.

Install the Ansible user management role

First let’s install the Ansible role to manage users into your Ansible control server:

$ su - ansible
$ cd ~/ansible
$ git clone https://github.com/ryandaniels/ansible-role-create-users.git roles/create-users

Or, you can use Ansible Galaxy to install this role:

$ su - ansible
$ ansible-galaxy install ryandaniels.create_users

Setup Ansible Vault

If you don’t already have Ansible Vault configured, you will need to set it up now. Vault uses AES encryption to store your sensitive information. And we need Ansible Vault to encrypt our user configuration file since we don’t want to be exposing even a hashed password into source control.

First, (if using git), make sure to update your .gitignore file so your Vault password isn’t saved to your source control. And also add the secret file we will be creating later:

$ vi .gitignore
.vaultpass
secret
*.secret

Next, create a password for your Ansible Vault and save it in your Password Manager (like KeePassXC). Then create the .vaultpass file, add the Vault password, and fix the permissions:

$ vi .vaultpass
#Enter password here

$ chmod 600 .vaultpass

Also you need to update the Ansible config file to reference where the Vault file is located:

$ vi ansible.cfg
[defaults]
vault_password_file = ./.vaultpass

Create Ansible Playbook

Next, create the Playbook file:

$ vi create-users.yml
---
- hosts: '{{inventory}}'
  vars_files:
    - vars/lab_users.secret
  become: yes
  roles:
  - create-users

Create configuration for user management

Next, add your users into a configuration file. The below is only an example, don’t use it in your user management configuration file. Also, make sure the filename matches a .gitignore entry. In this case it will match “*.secret”.
Use the special Ansible command to create the encrypted Ansible Vault file:

$ mkdir -p vars
$ ansible-vault create vars/lab_users.secret
---
users:
  - username: alice
    password: $6$/y5RGZnFaD3f$96xVdOAnldEtSxivDY02h.DwPTrJgGQl8/MTRRrFAwKTYbFymeKH/1Rxd3k.RQfpgebM6amLK3xAaycybdc.60
    update_password: on_create
    comment: Test User 100
    shell: /bin/bash
    ssh_key: |
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8crAHG/a9QBD4zO0ZHIjdRXy+ySKviXVCMIJ3/NMIAAzDyIsPKToUJmIApHHHF1/hBllqzBSkPEMwgFbXjyqTeVPHF8V0iq41n0kgbulJG alice@laptop
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8crAHG/a9QBD4zO0ZHIjdRXy+ySKviXVCMIxxxxxxxxxxxxxxxxxxJmIApHHHF1/hBllqzBSkPEMwgFbXjyqTeVPHF8V0iq41n0kgbulJG alice@server1
    exclusive_ssh_key: yes
    use_sudo: no
    use_sudo_nopass: no
    user_state: present
    servers:
      - webserver
      - database
      - monitoring

  - username: bob
    password: $6$XEnyI5UYSw$Rlc6tXtECtqdJ3uFitrbBlec1/8Fx2obfgFST419ntJqaX8sfPQ9xR7vj7dGhQsfX8zcSX3tumzR7/vwlIH6p/
    ssh_key: AAAAB3NzaC1yc2EAAAADAQABAAACAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8crAHG/a9QBD4zO0ZHIjdRXy+ySKviXVCMIxxxxxxxxxxxxxxxxxxJmIApHHHF1/hBllqbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbulJG bob@laptop
    use_sudo: no
    user_state: lock
    servers:
      - webserver
      - database

In the above example, there are two users. Users: alice and bob. If you are familiar with user management on Linux, then most of these settings are self explanatory. For example, both Alice and Bob have a hashed password and ssh keys. Alice actually has two ssh keys configured. But Bob’s account is locked so he can’t log in.

The interesting part is the list of “servers” in the configuration. These are groups defined in your Ansible hosts file. So you can give certain users access to a specific group of servers, depending on the user’s role.

Important note: Be careful with the update_password setting. When set to always, the user’s password will be changed to what is defined in password. This might not be what they wanted if they’ve manually changed their password so it’s usually safer to use on_create.

For details about all the different settings, see the README on GitHub.

Going forward, to update the file, instead of the “create” command line option, use “edit”:

$ ansible-vault edit vars/lab_users.secret

And don’t forget to save this into your source control (git).

Run the Ansible Playbook

$ ansible-playbook create-users.yml --extra-vars "inventory=all-dev" -i hosts-dev

Marvel at the output generated by Ansible. All these users are created, updated, or locked, but only if something needed to change since Ansible is idempotent.

Bonus: Add this in Jenkins

If you also use Jenkins for your CI/CD pipeline, you can add this Ansible Playbook into Jenkins.

You just need to setup Jenkins to use Ansible and Ansible Vault. And there is a great Jenkins Plugin to help. Just follow this guide to use Ansible Vault with Jenkins. Keep in mind that updating the user configuration file is only possible from the command line, since it’s encrypted using Ansible Vault.

Conclusion

In conclusion, there are many options for user management on Linux servers. From enterprise solutions like Red Hat IDM. Or, using the upstream open source software IDM uses directly, FreeIPA. If you decide to use Ansible, then the above Ansible role will get the job done. And you can also add it into Jenkins.

The post User Management with Ansible appeared first on Ryan Daniels.

If you are new to Ansible, read the getting started with Ansible post first.

Why use Ansible Vault?

You want to use Ansible Vault when you need to use sensitive data with Ansible, like a login and password, or SSH keys. Instead of storing this sensitive information in plain text, where anyone can read it when you save your Ansible Playbooks to your source control (like git), Vault uses an AES cypher to encrypt your data.

For more details, read the documentation.

Ansible Vault with Jenkins

Jenkins is software for Continuous Integration and Continuous Delivery. You can add plugins to Jenkins to extend its base features. And one handy plugin allows you to use Ansible with Jenkins.

Recently, the Ansible Plugin for Jenkins was updated to version 0.8.0, and as a result it now works seamlessly with Ansible Vault.

Install Ansible plugins for Jenkins

The first thing you need to install is the Ansible plugin for Jenkins.
Also, install the dependent plugin called Credentials Binding.

One thing to note is you can only read from encrypted Ansible Vault encrypted files. You cannot create or modify them using the Jenkins Ansible plugin. So you will still need to use the CLI to modify your encrypted files.

Add Vault password to Jenkins

The simplest way to use Ansible Vault with Jenkins is to add your Vault password into a Jenkins Credential. Then you can bind the credential to an environment variable, or use it directly as a “Vault Credential”.

Configure your Jenkins freestyle project that uses an Ansible Playbook. If you have the newest version of the Ansible plugin, under the “Build” section you will now see an option for “Vault Credentials” since this is a new feature.

Add a new Jenkins Credential as “Secret text”, and enter your Ansible Vault encryption password.

Next, select the new Vault Credentials and you are ready to use your encrypted files in your Jenkins build job from your Ansible Playbooks.

Conclusion

In conclusion, you are now using Ansible Vault encrypted files automatically inside of your Jenkins build jobs. This helps you to keep your sensitive data secured in your source control. And Jenkins is helping you to deploy your Ansible Playbooks, while seamlessly decrypting your files.

Next, you can add a job to Jenkins that requires Ansible Vault. If you want to use Ansible for user management on Linux servers, check out the guide for User Management with Ansible.

The post Ansible Vault with Jenkins 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.