A blog about digital independence and autonomy


A highly secure OpenVPN 2.4 configuration in 2018

Written by Mirabellette / 04 november 2018 / 4 comments

Hello everyone,


Today I would like to talk about OpenVPN. For those who did not know, OpenVPN is a free and open-source software application that implements virtual private network (VPN) techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities * from Wikipedia. It is developed by OpenVPN Incorporation and they offered a service of VPN with the product privatetunnel.

Nowadays, there a plenty of OpenVPN tutorial which describe how to install and configure it. Contrary to them, I will try to choose the most secure configuration possible in 2018 of OpenVPN 2.4.0 with Debian 9.5. I will try to describe as much as possible each step of the tutorial in order to be clearly understood.


First of all, we have to install the OpenVPN package and some extra tools with the user root

apt update
apt upgrade
apt install -y iptables-persistent openvpn vim sudo

Generate certificates

Downloads and configuration of EasyRSA

To generate certificates, we will use EasyRSA. EasyRSA is command line interface utility to build and manage keys and certificates. You can download the latest version for your desktop here EasyRSA is one the easiest tool to use to generate Certificate for OpenVPN. This article was focused on OpenVPN configuration and not the certificate part. That means I used the recommend certificate generation tool by OpenVPN, EASYRSA.

Unfortunately, it appears it does not allow to use the more secure cryptographic digest available today to generate a certificate. If you really want to use them, you need to use OpenSSL directly. An amazing tutorial is available here and could help you.

mkdir /tmp/openvpn
cd /tmp/openvpn/
tar xf EasyRSA-nix-3.0.5.tgz
cd EasyRSA-3.0.5
cp vars.example vars
vim vars

You must now modify the vars file in order to enable elliptic curve mode and improves the hash algorithm uses. Regarding the elliptic curve choosen, it appears that curves and cryptographic tools provided by the National Institute of Standards and Technology (NIST) were deliberately weaken. That's why, I choose to recommend the curve Curve25519 because it is similarly strong than secp256, faster, safer and was not create by the NIST. They are curve which are more secure but they are also dramatically slow.

# Enable elliptic crypto mode
set_var EASYRSA_ALGO ec

# Define the named curve - choose what you like and what is supported - openvpn --show-curves
set_var EASYRSA_CURVE Curve25519
# In how many days should the root CA key expire?
set_var EASYRSA_CA_EXPIRE 3650

# In how many days should certificates expire?

# In how many days should the control happen?
set_var EASYRSA_CRL_DAYS 3650

# Define the Cryptographic digest use, unfortunately, only the md5 and sha family is currently available with EasyRSA
set_var EASYRSA_DIGEST "sha512"

Generate certificates

Please write carefully about the Common name you choose for each certificate, especially for the server certificate. This one will be used by the client to verify the server certificate in order to avoid Man in the middle attack.

# generate a directory to store all files
./easyrsa init-pki

# generate an autority certificate
./easyrsa build-ca nopass

# create server key (server.key) and certificate signing request (server.req)
./easyrsa gen-req server nopass

# sign server certificate signing request by autority certificate (
./easyrsa sign-req server server nopass

# create client key (client.key) and certificate signing request (client.req)
./easyrsa gen-req client nopass

# sign client certificate signing request by autority certificate (
./easyrsa sign-req client client nopass

Generate certificates

# we will now create a more easy to read directory tree
mkdir /tmp/openvpn/server/
mkdir /tmp/openvpn/server/certificates
cp /tmp/openvpn/EasyRSA-3.0.5/pki/ca.crt /tmp/openvpn/server/certificates/ca.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/issued/server.crt /tmp/openvpn/server/certificates/server.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/private/server.key /tmp/openvpn/server/certificates/server.key

mkdir /tmp/openvpn/client/
mkdir /tmp/openvpn/client/certificates
cp /tmp/openvpn/EasyRSA-3.0.5/pki/ca.crt /tmp/openvpn/client/certificates/ca.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/issued/client.crt /tmp/openvpn/client/certificates/client.crt
cp /tmp/openvpn/EasyRSA-3.0.5/pki/private/client.key /tmp/openvpn/client/certificates/client.key

Network configuration

Let's consider that the ssh server listens the 22 port and 443 for the VPN server.

Firewall rules

We have to define firewall rules in the file /etc/iptables/rules.v4:

# Forward the VPN traffic to eth0



# Allow all loopback (lo) traffic and reject anything
# to localhost that does not originate from lo.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s -j REJECT

# Allow ping and ICMP error returns.
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

# Allow SSH.
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT

# Allow TCP traffic.
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT

# Allow DNS resolution and limited HTTP/S on eth0.
# Necessary for updating the server and keeping time.
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT

# Allow traffic on the TUN interface.
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

# then reject them.


Be sure to adapt these rules to your needs before applying them.

sudo iptables-restore < /etc/iptables/rules.v4

We can check if the rules are correctly implied:

sudo iptables -L

Enable ipv4 forwarding and disable ipv6

In the file /etc/sysctl.d/99-sysctl.conf, add the following lines to enable ipv4 forwarding and disable ipv6:

net.ipv4.ip_forward = 1

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

and then apply the new configuration

sudo sysctl -p

Remove ipv6 lines in /etc/hosts:

#::1 localhost ip6-localhost ip6-loopback

Reject ipv6 traffic by editing the file /etc/iptables/rules.v6, it must contains:




and apply:

sudo ip6tables-restore < /etc/iptables/rules.v6

Examples of very secure configuration

In order to continue, we will use the highly secure configuration below. Be careful, you need to follow the tutorial until the end to make it workable.

Example of server configuration

Please copy the following code in /tmp/openvpn/server/server.conf. It is the OpenVPN server configuration. Don't forget to replace local IP_OF_YOUR_OPENVPN_SERVER by your server ip.

dev tun
topology subnet
proto tcp
port 443

ca /etc/openvpn/server/certificates/ca.crt
# crl-verify /etc/openvpn/server/certificates/crl.pem
cert /etc/openvpn/server/certificates/server.crt
key /etc/openvpn/server/certificates/server.key
tls-crypt /etc/openvpn/server/certificates/tls_crypt.key

dh none
ecdh-curve ED25519
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
tls-version-min 1.2

keepalive 10 120

user ovpn
group ovpn

status /var/log/openvpn-status.log
log /var/log/openvpn.log

push "redirect-gateway"
push "dhcp-option DNS"
push "dhcp-option WINS"
push "route-ipv6 2000::/3"

Example of client configuration

Please copy the following code in /tmp/openvpn/client/client.conf. It is the OpenVPN client configuration. Don't forget to replace remote IP_OF_YOUR_OPENVPN_SERVER by your server ip and COMMON_NAME_OF_THE_SERVER_CERTIFICATE by the Common name you gave to the server certificate .cf Generating certificates.

# /tmp/openvpn/client
dev tun
proto tcp
resolv-retry infinite
remote-cert-tls server
cipher AES-256-GCM
tls-version-min 1.2

status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3

ca /etc/openvpn/client/certificates/ca.crt
cert /etc/openvpn/client/certificates/client.crt
key /etc/openvpn/client/certificates/client.key
tls-crypt /etc/openvpn/client/certificates/tls_crypt.key

Harden OpenVPN configuration

This part will describe most of the security parameters chosen in the final configuration. You will be able to find an example of the final configuration in the last part.

TCP/IP protocol and port listening

In order to avoid most of firewall limit, it is highly recommended to switch from udp protocol to tcp. OpenVPN configured with TCP protocol is a little bit slower but it has more chances to be accessible from a network you do not control.

You also have to configure the OpenVPN server to listen the port 443. Port 443 is the usual port used by a web server configuration and it is most of the time open in firewall output. Moreover, it will also make your OpenVPN configuration harder to detect because it is not the standard OpenVPN port. The standard port is 1194.

proto tcp4
port 443


Diffie–Hellman key exchange is a method of securely exchanging cryptographic keys over a public channel. In OpenVPN, this protocol is used in the first steps of TLS establishment connection. With a key of 1024 bits and lower size, it is vulnerable to Logjam exploits. The authors of the vulnerability recommend using primes of 2048 bits or more as a defense or switching to elliptic-curve Diffie–Hellman. In this tutorial, we use elliptic-curve Diffie–Hellman

HMAC signature during TLS handshake

Since openVPN 2.4, it is recommended to replace tls-auth by tls-crypt. Mainly because tls-crypt will also encrypt the TLS control channel. That means, to add the following line in server.conf:

tls-crypt /etc/openvpn/certificates/ta.key 0

and generate the HMAC key file in the openvpn server directory and client directory:

openvpn --genkey --secret /tmp/openvpn/server/certificates/tls_crypt.key
cp /tmp/openvpn/server/certificates/tls_crypt.key /tmp/openvpn/client/certificates/tls_crypt.key

Persistent tun/tap device and key

While your connection might be interrupted and OpenVPN is trying to reconnect, you may be using the default network routes again, bypassing the tunnel. For accessing private networks this might not be a big issue as the network addresses may not be reachable from outside the tunnel, but it may expose information you'd rather keep private like an HTTP request containing cookies.

persist-key is not a security option but a problem solving in case OpenVPN restart and the OpenVPN user is not able to read the key file anymore. This parameter avoid this situation.


Limited user

Probably one of the most important configuration setting. In order to limit the impact of an OpenVPN vulnerability, it is highly recommended to run it with a user with limited rights. To do that, we have to create a user for our OpenVPN applications. This user has limited privileges:

adduser --system --shell /usr/sbin/nologin --no-create-home ovpn
groupadd ovpn
usermod -a -G ovpn ovpn

and specify the user in the OpenVPN configuration:

user ovpn
group ovpn

Ciphers and digests

In the file /etc/openvpn/server.conf, we have to specify the ciphers and digest we want to use. It looks recommended to use GCM instead of CBC. More information about why here and here

tls-version-min 1.2
ncp-ciphers AES-256-GCM:AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
ecdh-curve ED25519
dh none

We will force to use SHA512 to manage the authentication mechanism. unfortately the best digest available is still sha family. Enabling the auth-nocache parameter will prevent to cache passwords in memory.

auth SHA512

Compression algorithms

In the OpenVPN version 2.3, it was the LZ0 compression algorithm which was by default. Since OpenVPN version 2.4, the compression algorithm LZ4 is available. Contrary to what the documentation says, it is not the best one available. There is also the version 2, lz4-v2 of it which is available but not documented yet.

If security if your only criteria, you should disable this feature. Indeed, a family of vulnerability like Beast, Crime and Voracle exist . Those vulnerabilities could allow an attacker to gain information about an encrypted communication in very specific circumstances. To explain differently, if the attacker knows exactly what he is supposed to receive and capture enough packet with little predictable changes, this could help him to reduce the time required to break the encryption.

For me, in the real world, it is really complicated to use this kind of vulnerability. The OpenVPN company recommends to disable compression algorithm and already did it on their products. In the configuration files provide here, it is, of course, disable because we are only focused on security. Feel free to make some performance test with speedtest if you hesitate.

Pushing configuration to the client

OpenVPN is allowed to push some network rules to the server. The most important is push "redirect-gateway" which forces to route all the client traffic throw the vpn. This parameter replaces the gateway route in the client configuration.

A second very useful possibility is to push a route for ipv6 which does not work. This will avoid in case your client is configured to work with ipv6 to make it unusable.

push "route-ipv6 2000::/3"

Revoke and unrevoke a client

Revoke a client

Sometime, you want to revoke an access to the vpn to a client. OpenVPN uses Certification Revocation List (CRL) to determine if a certificate is revoked or not. You need to execute the following command:

./easyrsa revoke client
./easyrsa gen-crl

Those commands also modify the file index.txt in the directory of /tmp/openvpn/EasyRSA-3.0.5/pki. For our setup and since we had revoked client, this file should be like that.

V 893632988188Z CWGT67WFA9QLQ9YZ65VGB8FLJKUKV3JL unknown /CN=server R 943755258824Z Y9BFEB757EFV47Y9ENNBUGJLKGP9KQCD unknown /CN=client

As you can see,the first column is V or R. V means valide and R means Revoke. We also have a new file crl.pem in /tmp/openvpn/EasyRSA-3.0.5/pki. It is this file which contains the list of revoked certificate. We have to copy it in a place accessible for the OpenVPN application and modify server.confwith a command.

cp /tmp/openvpn/EasyRSA-3.0.5/pki/crl.pem /etc/openvpn/server/certificates/crl.pem
chown ovpn:ovpn /etc/openvpn/server/certificates/crl.pem
# in server.conf
crl-verify /etc/openvpn/server/certificates/crl.pem
systemctl restart openvpn

Unrevoke a client

The certificate revocation list contains is a unique value even if you revoke multiple client certificate. If you want to unrevoke a client, you need to generate a new certificate revocation list. To do that, you need to modify /tmp/OpenVPN/EasyRSA-3.0.5/index.txt and replace the R for the certificate by V then generate a new certificate revocation list and finally replace the crl.pem loaded by OpenVPN.

Tuning and performance improvement

OpenVPN could be tuned in a lot of way to improve performance. I will not talk a lot about that because it requires an article by his own. You could change for example, the encryption algorithm, the TCP/IP protocol or modify those parameters to improve it.

  • mssfix
  • fragment
  • tun-mtu
  • compression algorithm

Feel free to read this page to know more about tuning OpenVPN.

Deployement and cleaning

Congratulation! The most complicated part is over. We just have now to deploy each directory in the proper place.

Directory structure

You should have this directory structure in /tmp/openvpn/server/. The server will need the following files to run properly:

  • server.conf
  • certificates/ca.crt
  • certificates/crl.pem
  • certificates/server.key
  • certificates/server.crt
  • certificates/tls_crypt.key

You should now have this directory structure in /tmp/openvpn/client/. The client will need the following files to run properly:

  • client.conf
  • certificates/client.crt
  • certificates/client.key
  • tls_crypt.key

A reader made a very good comment about the client configuration file. You can summarize in client.conf all the cryptography data required to establish the connection to the OpenVPN server. It makes it easier to transport and manage. To do that, you should remove the line about ca, cert, key and tls-crypt and replace them with the following lines.


Last configuration and deployement

Before moving directories, we will make them available only for the root user in reading mode.

chmod 400 -R /tmp/openvpn/

We will also move the all public and private key to a safe place and move the server directory to the right place:

cp -r /tmp/openvpn/server /etc/openvpn/
cp -r /tmp/openvpn/ /etc/ssl/openvpn-pki
ln -s /etc/openvpn/server/server.conf /etc/openvpn/server.conf

In the client which should be another computer. You just have to copy and paste the directory /tmp/openvpn/client to /etc/openvpn/ and create a symbolic link from /etc/openvpn/client/client.conf to /etc/openvpn/client.conf


To run OpenVPN with Systemd, you need to modify /etc/default/openvpn by uncommenting AUTOSTART="all" and replacing "all" by the name of configuration file. For example with in the server side, you should replace "all" by "server".

systemctl daemon-reload

You are now able to run it with systemctl and the following command:

systemctl start openvpn

You need to do the same thing for the client.


Be careful, do not forget to remove the directory /tmp/openvpn. It contains all your certificates.


Social media

Thank you for your reading, I hope this article was helpful for you. Don't hesitate to comment and if you think I made a mistake, it will be a pleasure to discuss it. If you find this article interesting, feel free to subscribe to the RSS flux of the blog and to follow me on Mastodon.


This article would not have been possible if other people does not share information about it. Their work help me a lot, thank you!

Important principles in cybersecurity - 2/2

Written by Mirabellette / 01 august 2018 / no comments


Today, I would like to share the second part of the article about important principles in cybersecurity. You can find the first part of these articles about cybersecurity here.

No usability means no security

Probably one of the most important principles in cybersecurity. When you are a professional of security, you are concerned about the risk of leaks and passwords disclosure. That means you are ready to make to some effort to prevent this. However, even if you are aware of that, it is tiring and exigent.

Let's go with an example most of us know. Imagine you have hundreds of website you need to log in. Nowadays, websites ask for complex passwords with long size. People which are not concerns about security will choose a password and they will write it next to their keyboard or worst, easy thing to remember. That means, even if you force the user to use only very difficult passwords, if it is not easy for him to pass it, he will find a way to do it easily.

Speed is crucial

Each day, there are multiple vulnerabilities which are published and accessible by anybody. In an interview given by the NSA, they claimed to be able to transform a vulnerability into a usable exploit in 24 hours. That means, if you are targeted by them, you should be able to patch your services and systems before the exploit is ready. If an agency can do that in 24 hours, we could presume just another agency can fix and deploys with the same efficiency in 24 hours.

Come back to the real world, where we are just system administrator and developer which are maintaining systems and applications. Patches tend to be created before exploits are spread. It was the case for Petya and not Petya. That means, if you are fast enough, you can update your systems before they are attacking. But what can you do if you cannot?


Multiple layers of Security is the answer to threats

You must admit that each of your security layers could be vulnerable and compromised. It is your responsibility as system administrator, software developer or cybersecurity expert to reduce the vulnerability of the layers you are responsible for to the minimum. An example of the effective layer could be the user management system in all operating system. There is a normal user with reduced right and a superuser or root who has more right. It is a basic advice on security but not everybody really follows it. Even in the cybersecurity field where the famous penetration distribution Kali Linux has only a user with all right by default.

Always be sure about the information before doing something

There is a lot of mythology and approximation in every field. Cybersecurity is not avoided by that. As an important position in a company, your words matter and could have important consequences. That means you must be sure about what you say. Oftenly, people speak without knowing enough. For cybersecurity, that means you should answer these 3 questions:

  • Is the vulnerability real?
  • Could some of our systems or application be threatened by them?
  • Should I or how can I mitigate it?

Most of the time, people will ask you about the vulnerability/threat before you have a clear idea of the situation. It is important not to make a presumption. The more just you will be about what you know, the more you will be able to well react to the situation.

Let's make a try with the shiny vulnerability Efail.


We have a wonderful website, one public communication from EFF about what we should do BEFORE any information was publicly disclosed. The Electronic Frontier Foundation (EFF) is an international non-profit digital rights group based in San Francisco, California. EFF recommends to immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email. They are very listened by all of the people and have a quite good reputation. However, if we do what they recommend, that means changing something based only on the trust we have in them. At this moment, your shiny warning should be ringing a lot and asked you to wait for a little in order to know more about that.

The day later, the vulnerability explanation was published. When we read it carefully, it appears it does not concern OpenPGP but only some products which manage emails. Please to find below the specific conditions which are necessary to let an opponent exploit it.

  • Your email manager must be vulnerable.
  • Your email manager must decrypt encrypted email automatically.
  • You must have the private key of the encrypted email loaded in your email manager.
  • You must have HTML rendering enabled.
  • You must open the email.
  • An attacker must have encrypted contents he wants to decrypt from you.

For me, if we listen to the noises made before the explanation was released, it was a very high critical vulnerability. But after the reading, it was sensitive but not so critical as the noise could let imagine. Mainly because there are a lot of things required to exploit the vulnerability. The NIST quite agrees with me; it gave to the two vulnerabilities behind Efail a complexity grade of high and a global grade of 5.9 (medium).

This was an example to wait and be sure to have enough information before doing something.


I hope you enjoy this second article about cybersecurity. The tone I used was a little bit more engaged than usual.
Feel free to comment if you want to add ideas or discuss it. If you find this article useful, you can subscribe the RSS flux of the blog or follow me on Mastodon. Don't hesitate to share it if you think it could interest someone.


Important principles in cybersecurity - 1/2

Written by Mirabellette / 01 july 2018 / no comments


This blog is focused on privacy and digital autonomy. However, digital privacy could not be possible if you do not know about cybersecurity. Today, I would like to discuss cybersecurity and especially about principles, I think they are important to keep in mind when you begin to think about cybersecurity. This is the first article of a series of I think two or three articles. To begin with, nothing better than to define the terms. Let's listen what Wikipedia say about cybersecurity:

Cybersecurity, computer security or IT security is the protection of computer systems from the theft of or damage to their hardware, software or electronic data, as well as from disruption or misdirection of the services they provide.
Cybersecurity includes controlling physical access to system hardware, as well as protecting against harm that may be done via network access, malicious data and code injection. Also, due to malpractice by operators, whether intentional or accidental, IT security personnel are susceptible to being tricked into deviating from secure procedures through various methods of social engineering.

The important principles

Security is a process, not a product

During one of my previous jobs, a client asked me about what I am concerned the more about security in the company IT service. They have devices which are used by a thousand clients, cloud systems, and websites. For me, they have multiple weaknesses which could be abused, but I decided to say an unexpected answer. My most important concern was about how they manage cybersecurity. Security threats and vulnerabilities will always occur, it is inherent to computer science and product. What it makes the difference is how you manage it.

As often, I don't get the idea from nowhere. It is a famous quote from Bruce Schneier. Why security is a process and not a product. Threats and counter measure constantly evolve. Even if you enable every security feature today, at year +1 or year +3 you will have something to do to be "secured".

Some example here of things you should do manually:

  • Enable new security features, SE Linux, Content Security policies ...
  • Replace old cryptographic cipher by new
  • Verify update were done, some update could disable automatic update, Wordpress did once.
  • Law evolves and you should add new features or modify some, GDPR for the last well know example
  • Dealing with a compromised system
  • Dealing with a world breaker vulnerability (hihi hearthbleed)

Nothing is invulnerable


I am sorry to tell you but, if you think your system can be invulnerable, you should probably need to make some research about that. Even a computer not connected to the internet could be compromised. Stuxnet did well with disturbing Iranian nuclear plants in 2012. Nuclear plants which were not connected to the internet and run on a specific system. The only thing you can do to protect your systems it is to have a good cybersecurity policy and dedicate time to work on this.

Another good example, with this important rule, is in cryptography. A lot of people recommended to store data in Google, Microsoft or Amazon cloud services. When you asked them about privacy, they just replied by encrypting it and it is ok. I am sorry, but it is not ok, not ok at all. Do you really think a file encrypted with nowadays technology could resist in 5 years, 10 years or 20 years to the technology improvement? Even the highest secure current cryptographic standard will be broken in a reasonable time in 30 years, probably before. If you want to know more, you just have to make some research about quantum computing .

Cybersecurity is not easy

I read in some place that cybersecurity is easy. You just have to do this and this and this and you are secure. Or doing this and this and this and you have now compromised 10000 computers. Yes, but in no. I am sorry to tell you, but in general, in computer science, it is not doing the thing which is complicated. What is complicated is to understand how it works behind and to model the solution. This took plenty of time and required dedication and abnegation. An example, who is coming to my mind is when hackers made presentations about offensive cybersecurity. They often say it requires just 10 lines of codes to take control of something.

For me, they are all newbies. First of all, because they need 6 lines of code whereas you can do it in one line code (troll inside :p). Secondly, because the number of lines is not the point. The hard part of hacking is not writing a code, it is understanding how it works and how to make things together. If you show how to compromise a camera linked to a computer connected to the same Wifi you use, you need at least to understand:

  • How a local network works
  • Which system is connected
  • How to identify if it is vulnerable
  • How to penetrate to him
  • Which kind of print you let behind you

If you don't understand one of this step, you are a script kiddy which does things without understanding what he is doing. When I began this part by saying they are all newbie, It has been just provocative. I have an immense respect for other people and I truly know that I know just a few things with a lot of things I ignore.

Cybersecurity cursor is dictated by threats and associated risks

As for development, you need to have a cursor in order to avoid to spend your time in tasks which are not very important or, in cybersecurity, fighting against nonexistent risks. I think the most relevant indicator is the threat model. What do I have to protect against? If I have to protect against a government agency, I will tell you honestly, it is lost. If they really want to catch you, they can deal with it. In this case, the best thing to work around is to avoid to interest them in doing a bad thing.

My case is a little bit different because I am passionate about defensive security and work in this field. That's why I try to have the most secure stuff as possible. Even doing that, I know it is not enough, I accept it. Knowing threats and associated risks will help you to know what you have to prioritize. For example, if you are an unknown blogger as I am with an online website. I should not interest government agency or professional black hacker so I attached a very low probability to be attacked by them (still a possibility, you never know). I should also be attacked only by internet. If I do something offline, It should be "safe".

So, in my current situation, the most likely threats will come from the internet. It should be from bots. The second one in my threat model list is another blogger/tech guy which dislikes me or try to discredit me. This kind of person could have a high skill in computer science. That means they will probably attack the website with more specific tools than bots have but they will not persevere a lot (I hope). That's why I decided to set a security level to at least moderate (from my security ladder, a high level means the system should be able to resist to a professional pirate and a very high level means for me the system should be able to resist to a government agency).

In my scenario, I have to deploy and enable features to resist to bots and most common weaknesses. Concretely, that's why I decided to use Pluxml product. It is far less popular than Wordpress and Joomla that means bad people will less look for vulnerability and if they find one, there are few chances It was included in a bot. However, the maintenance of PluXml is currently quite abandoned, that is a problem and I will probably have to switch to another product. A high level of security would imply a static website, no available services; a very high level of security, no website at all.


I hope you enjoy this first article about cybersecurity. The tone I used was a little bit more engaged than usual. You can find the part 2 here.
Feel free to comment if you want to add ideas or discuss it. If you find this article useful, you can subscribe the RSS flux of the blog or follow me on Mastodon. Don't hesitate to share it if you think it could interest someone.

Fix openvpn mbuf packet dropped

Written by Mirabellette / 11 april 2018 / no comments

Hello everyone

I hope you are going great and everything was fine for you.

Use case

I have an openvpn daemon running with TCP on 443 port on a Debian system. I got thousands of error messages since months about MBUF packet dropped. The message was

openvpn MBUF: mbuf packet dropped

It occurs only if you use openvpn over TCP. I know it is considered to be a bad practice because it unneeded traffic but you have to make choice.

What I do

After hours of research, I was able to fix it. I add this two lines to the server configuration file:

tcp-queue-limit 4096
bcast-buffers 4096

Now, you have to restart openvpn with this command : systemctl restart openvpn or service openvpn restart if systemd isn't installed on your system.
You should not see this message in log anymore \o/ and get a little bit more stable connection thanks to the undropped packet.


Social media

If you find this article interesting, feel free to subscribe to my RSS flux and to follow me on Mastodon. Don't hesitate to share it if you think he could interest someone else.

Examples of script to renew automaticaly web certificates with let's encrypt

Written by Mirabellette / 13 october 2017 / no comments

Hello everyone,

I know it is a very long time that I didn't post any article but life is life. ^^
Today, I wanted to share two scripts I used to renew my web certificates with let's encrypt. I know there is a lot of documentation about that, but it could help some of you to keep some time.

Generation web certificates with a specific domain name

The script browses the given file and ignore the line which begin with # or ----------. These symbols are used in the given file to make the text easier to read. Each line is one of my domains name or sub domains I managed. I just have to add a new one to this list to be sure the certificate of this new domain name will be automatically renewed.

# file : /root/certs/
# Renew all certificates which are in the given file

while read c ; do
 if [[ ${c} != "#"* ]]; then
  if [[ ${c} != "----------" ]]; then
   echo $c
   echo "/opt/letsencrypt/letsencrypt-auto --apache --renew-by-default -d $c --rsa-key-size 4096 --uir --redirect" | tee -a $logFile
   /opt/letsencrypt/letsencrypt-auto --apache --renew-by-default -d $c --rsa-key-size 4096 --uir --redirect
done <$serverName
service apache2 restart
echo "service apache2 restart"

# file : /root/certs/serverName

To use this one, I create a cron task which run the script each month
0 6 01 * * /root/certs/ /root/certs/serverName
Warning : be careful that /root/certs/ need to executable (chmod 700)

A single web certificate with multiple domain name

The second one is very similar to the first one. The main difference is that it creates a single certificate with multiple domain name and do not get a domain name from a file given as parameter.

# file : /root/certs/

cmdRenew="/opt/letsencrypt/letsencrypt-auto --apache --rsa-key-size 4096 --uir --redirect"
while read domainName ; do
 if [[ ${domainName} != "#"* ]]; then
  if [[ ${domainName} != "----------" ]]; then
   echo $domainName
   cmdRenew="$cmdRenew -d $domainName"
done <$serverName

echo ${cmdRenew}
service apache2 restart
echo "service apache2 restart"

# file : /root/certs/server-name-mirabellette

To use this one, I create a cron task which run the script each month
0 6 01 * * /root/certs/

Warning : be careful that /root/certs/ need to executable (chmod 700)

I hope this article gave you some ideas to easily manage how to renew your web certificate.