Rules
Be considerated or be yeeted. This does not need to degenerate into the last PIA post. I wanted this one to be productive. Plus you can learn a tad bit about PKI if you scroll down to the video. ;)
Mentioning israel or their intelligence directives has NOTHING to do with being jewish nor is meant to call anybody out from that region. Please nobody start sharing opinions related to them in a manner meant to hurt or insult one another
The Concern
So as we all know Kape Tech has bought all the big VPN names.
These were previously outside United States CIA jurisdiction do to being within the united states (if you believe they follow those rules). (most people considered this a good reason to actually have a VPN from within the US. Others are in the panama and swiss camp so to each their own)
Now they are in Israels hand who has a security cooperative with the United States. CIA and Mossad talk. Higher executives within the company are former Unit 8200. Unit 8200 for those not up to date on the military intelligence side of things is a secret Intelligence directive ran under the guise of support acitvity operations for the Israeli Defense Force. They are about as bad ass as they get and far more capable than the NSA in some regards because they dont have to worry about getting caught. That said they usually avoid doing so and thats why you havent heard of them.
Well one of there people that used to be really good at system exploiting is now the CEO of Kape tech.
Let this sink in, why is the top exploiter from mossad suddenly in charge of all these companies and who gains to win? Not to mention all his former buddies are in the CTO and chief engineer positions etc.
I know now your thinking whos this nut job whos talking about this, why would I care.
So this spawns a conversation about trust. Not just the chain of trust ins a PKI but trust overall. People put a lot of faith in services they can run on the cheap. This is fine from an obfuscation standpoint. Can we trust any major VPN provider? No and you never should have. Most of us people who knew this have anyway because we dont need to be an invisible man but more or less one amongst a crowd.
So why the need to make a post if we already shouldnt have trusted them? The problem is people use them as a trust worthy place to pipe their network traffic through. Its totally chill to use to bypass iSP restrictions.
How to eliminate VPN trust issues and still use it?
Unfortunately this means your going to break out the onion router within the VPN. You cant trust the VPN endpoint so to add obscufation and trust your traffic being safe its best to setup TOR within the VPN.
If you dont feel like sacrificing your connection speed for this you can always make your own VPN. You can get a VPS of config 2vCPU and 2 GB of ram which should be more than plenty for this or alternative the 1 VCPU as cheap as you can. Anyways what matters here is not the specification. If you want to be an invisible man or woman you have to decide how your going to run this even if you do not want to be invisible.
Invisble: (this would have a special purpose)
- Buy it with crypto currency (preferablly monero turned into bitcoin)
- DO not tie it to any email that can be traced back to you
- Do not connect it to known locations you stay like home and work
- Do not surf any personal traffic that can be tied to specifically you on it.
- Theres alot more you shouldnt do but we wont get into that. Educate yourself
Just a trusted VPN server:
- well buy it with a normal credit card. Who cares if its tied to you. Its just an endpoint like a SOCKS proxy would be.
So we have a choice of VPNs, @SgtAwesomesauce is a fan of wireguard and I completely understand why. His reasons for loving it he can reply about.
Im going to talk about the things that make me like it. Particularly on the cipher end.
Wireguard has what most consider to be a bleeding edge set of protocols.
- ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539’s AEAD construction
- SipHash24 for hashtable keys
- HKDF for key derivation, as described in RFC5869
- Curve25519 for ECDH
- BLAKE2s for hashing and keyed hashing, described in RFC7693
It has a lot less overhead and a very minimal code base. In comparison wireguard has about 4300 lines of code where openVPN has over 500000. This alleviates my concern of it not yet fully being audited as a security protocol. The less code the less chance you have for a bug or security flaw. It also makes the code far easier for the average programmer to audit. For those unfamiliar auditing is us trying to find a vulnerability and close it up. Not to mention the lack of so much overhead means way better performance. Anyways lets talk about one commercial option and also the setup guide to each on a personal VPS. The cons I have with it is that its in heavy development. So things change too often.
Trustworthy Commercial Wireguard VPN
Can confirm their logs are all sent to to /dev/null and you can pay with monero
OpenVPN Setup
Let’s assume you have easy RSA installed and OpenVPN on your choice of distro or OS (FreeBSD, Debian 10, CentOS)
This differs on every distribution so I dont want to get distribution specific. What you need to do first is find your EasyRSA vars file. (normally located in its installation folder).
set_var EASYRSA_REQ_COUNTRY "Panama"
set_var EASYRSA_REQ_PROVINCE "Panama"
set_var EASYRSA_REQ_CITY "Panama City"
set_var EASYRSA_REQ_ORG "Self Hosted VPN"
set_var EASYRSA_REQ_EMAIL "[email protected]"
set_var EASYRSA_REQ_OU "Obscufate"
These variables are to each their own. Lets get tough with the crypto digests, Find and change to 512:
#set_var EASYRSA_DIGEST "sha512"
Decide on the key you want. Either RSA or CURVE and find the following lines for either and change them to the key length you want respectively
#set_var EASYRSA_ALGO rsa
#set_var EASYRSA_KEY_SIZE 4096
or
#set_var EASYRSA_ALGO ec
# Lets use bitoins curve
#set_var EASYRSA_CURVE secp521r1
Set those variables to whatever you wish. It will be part of the certificate and key creation. RSA is trusty and strong but ec is new and rather fast but theres rumors it cant be trusted.
Run the initial PKI (aka build your CA and everything you need for the Private Key Infrustructure). Heres a link to understand out PKI works:
Lets build the PKI Infra:
# generate a directory to store all files
./EASYRSA_DIR init-pki
# generate cert authority
./$EASYRSA_DIR$ build-ca nopass
# gen server key and req
./$EASYRSA_DIR$ gen-req server nopass
# Gen server.ca
./$EASYRSA_DIR$ sign-req server server nopass
# gen client key and req
./$EASYRSA_DIR$ gen-req client nopass
# gen client.ca
./$EASYRSA_DIR$ sign-req client client nopass
You can choose to leave this all in this directory or you can clean up the directory structure to your liking. Either way I wont tell you what to do here.
Now on your VPS setup the firewall correctly to handle both ssh and port 443. Do not skip this step. (This is short hand). Using IP tables is pretty easy. Assuming its install you can find IPv4 rules here /etc/iptables/rules.v4. You can use ANY other firewall just configure it properly
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Forward the VPN traffic to <INTERFACE>
-A POSTROUTING -s 10.8.31.0/24 -o <INTERFACE> -j MASQUERADE
COMMIT
Setup loop back so you can get a functional internet connection between the VPS Ethernet connection and the VPN endpoint broadcast.
*filter
# Allow all loopback (lo) traffic and reject anything other wise
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A OUTPUT -o lo -j ACCEPT
# 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 <INTERFACE> -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o <INTERFACE> -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT
# Allow TCP traffic. (Or you can use UDP
-A INPUT -i <INTERFACE> -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
-A OUTPUT -o <INTERFACE> -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT
# Allow DNS resolution and limited HTTP/S on <INTERFACE> for updating etc
-A INPUT -i <INTERFACE> -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o <INTERFACE> -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT
# TUNNEL Traffic
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
# Else reject
-A INPUT -j REJECT
-A OUTPUT -j REJECT
COMMIT
Disable IPv6 in sysctl
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
Commit this with sudo sysctl -p and also remove any IP6 lines in your hosts config or anywhere that would otherwise resolve IP6. We want to disable it because IP6 is very unique and pinpointable as its usually not behind NAT and everyone gets a unique address thats no where else since it supports so many addresses. Further more block this is in /etc/iptables/rules.v6 for simple IPtables
*filter
-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT
COMMIT
Now we get to the nitty gritty. A good secure configuration
Server.conf:
#/$DIR$/openvpn/server.conf
local <IP>
dev tun
topology subnet <You can also isolate here>
proto tcp
port 443
server 10.8.31.0 255.255.255.0
tls-server
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
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
tls-version-min 1.2 <specify min (can be 1.3)>
persist-tun
compress <obvously>
persist-key
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 10.8.31.1"
push "dhcp-option WINS 10.8.31.1"
push "route-ipv6 2000::/3"
Client.conf:
# /$DIR$/openvpn/server.conf
client
dev tun
remote <IP> 443
proto tcp
resolv-retry infinite
compress
nobind
verify-x509-name "COMMON_NAME_OF_THE_SERVER_CERTIFICATE" name
remote-cert-tls server
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
tls-version-min 1.2
auth-nocache
persist-key
persist-tun
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
So what are we doing that hardens it? ONE we are moving away from UDP to TCP to avoid firewall limiting. We do this by specifying that protocol. We are also configuring it to the singular most open port of 443.
So logjam exploits do effect the hellman key exchange so to mitigate it we are using an EC based diffie hellman (change your configs up earlier to reflect it please).
We have replaced TLS-Auth with TLS-Crypt since its now recommended by most security gurus. Now we can gen the secret
openvpn --genkey --secret /$DIR$/openvpn/server/certificates/tls_crypt.key
cp /$DIR$/openvpn/server/certificates/tls_crypt.key /tmp/openvpn/client/certificates/tls_crypt.key
persist-tun and persist-key prevent leakage and key reading until the VPN is reestablished if we lose connection to the tunnel.
On your VPS harden the openvpn user
adduser --system --shell /usr/sbin/nologin --no-create-home ovpn
groupadd ovpn
usermod -a -G ovpn ovpn
Let’s talk about the alorithm of choice. You can use CBC but it has a vulnerability. GCM is much more versatile in my opinion and GCM is also parallelizable (if thats a word). Also if your using TLS 1.3 you must use GCM. To my understanding its more secure: Read here https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
I chose to use SHA512 to remove any chance of digest attacks and I dont cache the digest. This does make it slower because keys are not cached in memory. I also pushed IP6 though its blocked on the VPS to force a redirect to a dead endpoint. (Now you know how PIA blocks IPv6)
Im sure theres more optimization to both protocols but enjoy. I hope you can see how openVPN is configured and understand those choices your making in the frontend software of most VPNs
Wireguard Setup
Set it up on your VPS and make sure youve loaded the kernel modules (modprobe wireguard)
We need to generate keys and fortunately this is a much more simple setup than wireguard:
cd /etc/wireguard
umask 077
wg genkey | sudo tee privatekey | wg pubkey | sudo tee publickey
If you want some vanity to make public keys that have an identifier as to who is connect look up: https://github.com/warner/wireguard-vanity-address
Using your favorite way to edit a text file. Open /etc/wireguard/wg0.conf and enter what you need to in here
[Interface]
PrivateKey = <your server private key here>
Address = 10.8.31.1/24
Address = fd86:ea04:1111::1/64
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <INTERFACE> -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o <INTERFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <INTERFACE> -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o <INTERFACE> -j MASQUERADE
ListenPort = 443
Again changing the port to the single most allowed port in firewalls and throw this at the end of your sysctl. Its important we allow the forwarding:
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
and commit it by executing sysctl -p. Now we can bring the interface up and test it
wg-quick up wg0
by executing the command wg and seeing the interface information. Of course enable whatever firewall rules you need to do this so that you can get an internet connection working. See Open VPN instructions for some ideas.
For wireguard clients you will need to create peers on the device itself.
On the client you go ahead and setup wireguard like you did on your server and then modify wg0.conf just as above
This is what it should reflect
[Interface]
Address = 10.8.31.2/32
Address = fd86:ea04:1111::2/128
SaveConfig = true
PrivateKey = <your client private key here>
DNS = 1.1.1.1
[Peer]
PublicKey = <your server public key here>
Endpoint = <your server public ip>:443
AllowedIPs = 0.0.0.0/0, ::/0
CHMOD the configuration and connect to the server
chmod 600 /etc/wireguard/wg0.conf
Verify this was added properly
wg set wg0 peer <client-public-key> allowed-ips 10.8.31.2/32,fd86:ea04:1111::2/128
wg
If the output is correct you have all of what you need to run wireguard so go ahead and wg-quick up wg0 to reap the benefits and as per any good piece of software there is a way to automate it on boot. If you get no conenction or a firewall blocks it allow it through
iptables -A INPUT -p udp -m udp --dport 443 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --sport 443 -j ACCEPT
sudo systemctl enable wg-quick@wg0
For the paranoid please use TOR within either setup
Alright depending on the one you chose you now have a VPN server all to your own. Id love to see throughput comparisons of both technologies. Im going to gather wireguard will win.
At the end of the day
“Praise the God of all, drink the wine, and let the world be the world.”
.