Automate OpenVPN client on CentOS 7

I need to setup OpenVPN client to start automatically on a CentOS 7 server for one of our recent projects at work.  I’m not well versed in VPN technology, but the majority of the time was spent on something that I didn’t expect.

I go the VPN configuration and all the necessary certificates from the client, installed OpenVPN and tried it out.  It seemed to work just fine.  But the setting it up to start automatically and without any human intervention took much longer than I though it would.

The first issue that I came across was the necessary input of username and password for the VPN connection to be established.  The solution to that is simple (thanks to this comment):

  1. Create a new text file (for example, /etc/openvpn/auth) with the username being the first line of the file, and the password being the second.  Don’t forget to limit the permissions to read-only by root.
  2. Add the following line to the VPN configuration file (assuming /etc/openvpn/client.conf): “auth-user-pass auth“.  Here, the second “auth” is the name of the file, relative to the VPN configuration.

With that, the manual startup of the VPN (openvpn client.conf) was working.

Now, how do we start the service automatically?  The old-school knowledge was suggesting “service openvpn start”.  But that fails due to openvpn being an uknown service.  Weird, right?

“rpm -ql openvpn” pointed to the direction of the systemd service (“systemctl start openvpn”).  But that failed too.  The name of the service was strangely looking too:

# rpm -ql openvpn | grep service
/usr/lib/systemd/system/openvpn@.service

A little (well, not that little after all) digging around, revealed something that I didn’t know.  Systemd services can be started with different configuration files.  In this case, you can run “systemctl start openvpn@foobar” to start the OpenVPN service using “foobar” configuration file, which should be in “/etc/openvpn/foobar.conf“.

What’s that config file and where do I get it from?  Well, the OpenVPN configuration sent from our client had a “account@host.ovpn” file, which is exactly what’s needed.  So, renaming “account@host.ovpn” to “client.conf” and moving it together with all the other certificate files into “/etc/openvpn” folder allowed me to do “systemctl start openvpn@client“.  All you need now is to make the service start automatically at boot time and you are done.

base32 advantages over base64

Andrey shares some of the advantages of base32 over base64 encoding:

  1. The resulting character set is all one case, which can often be beneficial when using a case-insensitive filesystem, spoken language, or human memory.
  2. The result can be used as a file name because it can not possibly contain the ‘/’ symbol, which is the Unix path separator.
  3. The alphabet can be selected to avoid similar-looking pairs of different symbols, so the strings can be accurately transcribed by hand. (For example, the RFC 4648 symbol set omits the digits for one, eight and zero, since they could be confused with the letters ‘I’, ‘B’, and ‘O’.)
  4. A result excluding padding can be included in a URL without encoding any characters.

Personally, I don’t think I’ve heard about base32 until today.

Yet another bit on security

Here are a couple of interesting articles from the last few days on Slashdot.

First, comes in a very non-surprising survey saying that “40 percent of organizations store admin passwords in Word documents“.  Judging from my personal experiences in different companies, I’d say this number is much higher if you extend the Word documents to Excel spreadsheets and plain text files.  I think pretty much every single company I’ve worked at used such common files for admin password storage (at least at some point).

“Why or why?!!!”, the security concerned among you might scream.  Well, I think there are two reasons for this.  The first one is that password management is complicated.  There are tools that help with this, but even those are rarely easy to use.  Storing the passwords in a secure, encrypted storage is one thing.  But, how do you share them with just the right people? How do you trust the tool? What happens if the file gets corrupted, the software updates, the license expires, or the master password is lost?  The risk of losing admin access to all your equipment and accounts is scary.  On top of that, there is the issue of changing passwords (especially when people leave the company) – not a simple job if you have a variety of accounts (hardware, software, services, etc) and a lot of people who have a varying degree of access.  Or automation scripts that need access to perform large scale operations.  Personally, I don’t think this problem has been solved yet.

The second reason is in this other Slashdot post – “Sad Reality: It’s Cheaper To Get Hacked Than Build Strong IT Defenses“.  This is very true as well.  A simple firewall and a strong password policy is often more than enough for many organizations.  The risks of compromise are low.  In those cases where it does happen, you’d often get some script kiddie consequence like a Bitcoin mining app or affiliate links spread across your website.  Both are quite easy to detect and fix.  Is it worth investing hundreds of thousands in equipment and personnel to prevent this? For many companies it is not.

The fact of the matter is that a lot of people don’t really care about security or privacy on the personal level, and that then translates into the organizational mentality as well.

Just think about people leaving in all those high crime areas.  Some of them think the risk is worth it – maybe then can make more money there or have a more exciting life.  Some of them simply can’t afford to move anywhere.  That’s very similar to the digital security, I think.  Some don’t care and prefer to run the risk, saving the money on protection. Some simply can’t afford to have a decent level of security.

Steven Black hosts files

StevenBlack/hosts repository:

Extending and consolidating hosts files from a variety of sources like adaway.org, mvps.org, malwaredomains.com, someonewhocares.org, yoyo.org, and potentially others. You can optionally invoke extensions to block additional sites by category.

Categories include: adware, malware, gambling, porn, and social networks.

PHP backdoors

PHP backdoors repository is a collection of obfuscated and deobfuscated PHP backdoors. (For educational or testing purposes only, obviously.)  These provide a great insight into what kind of functionality the attackers are looking for when they exploit your application.  Most of these rotate around file system operations, executing commands, and sending emails.

One of the things from those files that I haven’t seen before is FOPO – Free Online PHP Obfuscator tool.