Use Cases for a VPN

People often ask me what VPN they should use but never ask how it actually protects them (and they probably couldn’t answer that). Using a VPN does not always make you more secure, and is only really beneficial in certain conditions and against certain adversaries.

When a VPN helpsWhen a VPN does not help
Protecting unencrypted data from an MITM (Man In The Middle) attackProtecting TLS/SSL (https) traffic (not much)
Stopping your ISP (or coffee shop) from seeing browsing habitsLowering video game latency
Bypassing location based blocking
(eg. seeing Netflix’s UK catalogue from the US)
Stopping advertisers from tracking you
Increase download speeds

A VPN encrypts all internet traffic exiting your device and sends it to a remote server which will decrypt the request and forward it on to its destination. In the case of a business VPN it would likely allow you access into the companies internal network even if you are not physically there connected directly to the network. Your ISP is able to see all of the destinations contacted by the various computers, phones, smart TVs etc. in your house. When a device is connected to a VPN, your ISP would only be able to see one destination; the VPN endpoint. If your web browsing connections use SSL/TLS only the domain name is unencrypted. Traffic such as the content of a webpage, or submitting a username and password are hidden from the ISP or any other man in the middle snooping on your connections. Even the portion of the URL after the domain name is hidden. Your ISP can see you went to, but they cannot see that you went to

When you’re not at home, this still stays relatively the same with coffee shop or airport wifi. Many free wifi services nag you when you connect with some kind of acknowledgement of there terms of service or show a login prompt that allows you to login as a paid user or continue as a guest. Many of these services have in their privacy policies provisions to sell any marketing data off to advertisers which is again, generally only the websites you visit and not specifics of what you do on those sites. As an example, Boingo Wireless which is found in many airports states directly in their privacy policy that they will share any information collected about you with “advertising partners”. Just seeing the domain name of a website you visit isnt really worth much, but a VPN would block it if you really care enough to pay for that.

VPN advertisements lean hard on the idea that an attacker nearby could “intercept your traffic”. If the URL bar in your browser says “https” instead of “http” and has a lock icon to the left of that, a successful attack is extremely unlikely. There are still certain attacks that can defeat this but they are highly complex and not likely to be deployed by some random guy who just happens to be at the same coffee shop as you. A VPN isnt the best mitigation for this sort of threat vector. You’re better off just not connecting to the free wifi or not checking your bank account on that wifi until you go home.

If you connect to a VPN but are still signed into your Google, Facebook, etc. account, that service will still know you are the person browsing. The VPN does nothing to hide your identity. Likewise, if you had cookies or other tracking markers stored before you turned the VPN on, those trackers would know you are the same person browsing and changing your IP address is still just as worthless. A better option would be to install an ad blocking extension on your web browser such as uBlock Origin (Chrome / Firefox) or use the Tor browser bundle.

The most common use for VPNs is to bypass geolocation blocks. You’ve probably run into the Youtube error message before saying that the video you are trying to watch is not available in your country, or you’ve wanted to watch a show on Netflix which has already released in the UK, but wont come to the US catalogue for another few weeks. By using a VPN, you can select an endpoint in another country where the video or content is available and spoof your location so that you can view the video. Youtube and other sites do not care if you were blocked from watching a video in the US and then tried viewing the same video 1 minute later from an IP address in the UK. The blocking system is based only on the geolocation of your IP and takes nothing else into account.

There are some services that claim to put VPN endpoints physically near or inside the same data centers that are used by various multiplayer servers and can lower latency and give you an edge in competitive games. This is never true. They are not able to some how reduce the number of hops between you and the multiplayer server. The number of hops will always increase by at least one and consequently increase latency.

The major downside of using a VPN is the necessary trust that comes with all of your data transiting through one server. VPN companies make claims that they dont retain or sell logs but there is no way to back that claim with evidence. They can only rely on the public’s trust. VPN companies tend to hide themselves behind shell companies and vague state of origin so that governments cannot deliver warrants because the VPN service is outside of any law’s jurisdiction. China has taken advantage of this to secretly run VPN services so that they can snoop the traffic of hundreds of thousands of people outside of China for the state’s own benefit. In 2018 a study was done which determined that more than half of all of the most popular searched for free VPN services were subsidiaries of Chinese companies.

As an aside, when I have this conversation with people there are two very common questions that come up that I might as well answer here:
Yes, I have had to report people for looking at adult sites while connected to their company’s VPN.
Yes, I have unfortunately had to report people for accessing sites that contain adult content involving minors. No, I did not have to testify in the matter.

Setting Up a Windows Gaming VM using GPU Pass Through on Linux


This guide contains complete instructions for setting up a GPU pass through GNU+Linux system other than the two following issues:
1. This guide does not consider using the ACS linux kernel patch. Using this patch is not recommended.
2. This guide does not support using GPUs that have USB support. most modern GPUs will pull USB3 XHCI drivers which are baked into the Linux kernel instead of being loaded as a kernel module. If your GPU requires XHCI drivers you have to work around this by compiling a kernel without USB support, compile a kernel module that supports USB, and configure your system to load the USB module AFTER the stub driver has attached to the passthrough PCI devices.

I have read through a large number of guides on how to set up a gaming VM in Linux and all of them seem to have a lot of holes in the process, incorrect information, or are too long and dense to be called a guide and act more as a technical paper on how IOMMU, DMA, etc. function on a low level. This guide hopes to be as complete as possible while also maintaining a step by step process and not going into so much detail that it becomes unreadable.

Be careful to replace example variables used in this guide with your own variables. The guide will instruct on how to find your own variables to use.

This guide was written using this hardware and software:
Host OS: Linux 5.0.0-37-generic #40~18.04.1-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
Qemu information:
Compiled against library: libvirt 4.0.0
Using library: libvirt 4.0.0
Using API: QEMU 4.0.0
Running hypervisor: QEMU 2.11.1
Aorus Pro X399
AMD ThreadRipper 2920x
Nvidia 960
Nvidia 740

Step 1: Enable IOMMU and Virtualization

1: Ensure your hardware is compatible with a full suite of virtualization tools. On Intel hardware you should ensure that it is compatible with both VT-x and VT-d. AMD hardware should be capable of AMD-Vi. AMD-V is not sufficient. It must very specifically be AMD-Vi. You can determine this by searching the web for the model of both your CPU and motherboard and “VT-d capable” or “AMD-Vi capable” depending on the hardware you are using.

2: Update your motherboard’s BIOS firmware: Mine was not able to enable the IOMMU feature until I updated. Even if you BIOS supports IOMMU already, a newer version may have better support that will fix issues causing slowness before the issue ever arises.

3: Enable virtualization features: on Intel systems you need to enable both VT-d and VT-x. On AMD you need to enable AMD-Vi. The specific instructions on how to perform this vary between BIOS, so once again it is best to search the internet on instructions on how to perform this task.
Ryzen caveat: On any BIOS that has the options “Auto | Disabled | Enabled” you should choose enabled. Auto will give worse groupings and make the most difficult portions of this process even harder.

4: Configure Linux to use IOMMU:
Edit the file /etc/default/grub. Find the line that starts with GRUB_CMDLINE_LINUX_DEFAULT= and add the following to the end of the line:
For AMD hardware: amd_iommu=on
For Intel hardware: intel_iommu=on
If your boot time is noticeably longer try changing amd/intel_iommu=on to iommu=1 or iommu=pt. If you have issues later where your VM is laggy or slow, you may need to addiommu=pt after amd/intel_iommu=on.

5: Update grub: Execute sudo update-grub

6: REBOOT: None of these changes take effect until after you reboot.

7: Check that IOMMU was enabled by running dmesg | grep -i -e DMAR -e IOMMU. You should see something like this:

[    0.842942] AMD-Vi: IOMMU performance counters supported
[    0.842994] AMD-Vi: IOMMU performance counters supported
[    0.847834] iommu: Adding device 0000:00:19.6 to group 8
[    0.847846] iommu: Adding device 0000:00:19.7 to group 8
[    0.847855] iommu: Adding device 0000:01:00.0 to group 0
[    0.847863] iommu: Adding device 0000:01:00.1 to group 0
[    0.850572] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.850574] AMD-Vi: Found IOMMU at 0000:40:00.2 cap 0x40
[    0.851486] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank).
[    0.851523] perf/amd_iommu: Detected AMD IOMMU #1 (2 banks, 4 counters/bank).

Intel hardware will obviously look different, and AMD hardware will not look exactly the same. This is only a snippet of the output I received from my own output.

Step 2: Gathering System Information to Determine Course of Action

Next you we need to get IOMMU configuration information and hardware IDs. The hardware IDs are used to blacklist the video card so that the host does not take ownership. If it does and you try to attach the video card to the guest, either the guest will hang at boot or the whole host will lock up and need a hard reboot. The IOMMU information is to know the identifier of the device that will be attached to the guest for pass through. IOMMU information is also needed to determine if the ACS patch will be needed. ACS and the downsides of its kernel patch will be explained in its own portion of this guide.

We will detect the hardware ID of the video card and black list it.
Get the hardware ID and IOMMU channel of the video card: Execute lspci -nn | grep -i vga to see all video cards installed. The output should look something like this:

08:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 710] [10de:128b] (rev a1)
41:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1) 

The first numbers before “VGA” is the channel of the device. The hex numbers in [brackets] near the end of each line is the hardware ID. The video card that I want to blacklist is the GTX 960, so the relevant information that I need is the channel 41:00.0 and hardware ID [10de:1401]. Your channel and hardware ID will be different. The HDMI audio device on the video card was not seen in the output, and we will need to pass that through too. It can be detected by running lspci -nn | grep -i audio.

$ lspci -nn | grep -i audio
08:00.1 Audio device [0403]: NVIDIA Corporation GK208 HDMI/DP Audio Controller [10de:0e0f] (rev a1)
0a:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller [1022:1457]
41:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fba] (rev a1)

As we can see, the video card is 41:00.0 and the audio card is 41:00.1. the last number should be 1-2 numbers off from the video card and the proceeding number should always be the same. The IOMMU channels should never start with different numbers.

We now have a complete list of devices that we want to blacklist:
GeForce GTX 960 video card
IOMMU channel: 41:00.0
Hardware ID: 10de:1401
GeForce GTX 960 HDMI audio
IOMMU channel: 41:00.1
Hardware ID: 10de:0fba

Next we need to look at the IOMMU channels. You can only pass all devices in the IOMMU group or none of them. If another device is in the same group it will have to be passed with the video card or you will have to use the ACS patch.

Execute ls /sys/kernel/iommu_groups/*/devices to see IOMMU groups. It will show each IOMMU device (channel) in every IOMMU group on the host. Example:

 0000:40:08.0@  0000:40:08.1@  0000:43:00.0@  0000:43:00.2@

For me, channels 41:00.0 and 41:00.1 are located in group 11:

 0000:40:03.0@  0000:40:03.1@  0000:41:00.0@  0000:41:00.1@

As we can see the group is tainted with other devices. Lets look at what these are:

lspci -nn | grep 40:03 will show us the other devices in the group:

40:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge [1022:1452]
 40:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453]

Device 40:03.0 is a PCIe Dummy Host Bridge and device 40:03.1 is a PCIe GPP bridge. Thankfully both of these devices can be ignored. The one caveat in needing to pass all devices in a IOMMU group is that bridges do not need to be passed, and further should not ever be passed.

If your IOMMU groups are not tainted you can completely skip the ACS portion of this guide. ACS can introduce security flaws, so you should not use the patch unless it is completely necessary.

Step 3: Blacklisting Devices

Your host computer’s BIOS selects a default video card to use when booting. If it defaults to using the video card that needs to be passed through to the guest, you should enter your BIOS settings again to select the second video card installed in your system.

Currently, when booting, Linux will detect each piece of hardware connected to your host and assign the best kernel driver to use, but we don’t want the video card using nvidia or amd drivers. We will blacklist the device three different ways. This is overkill, but will also ensure that the vfio-pci driver will always be used instead of the normal driver when rebooting.

1. Determine the current driver being used:
Execute lspci -nnk -d {your hardware ID}

$ lspci -nnk -d 10de:1401
41:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1)
         Subsystem: Corp. GM206 [GeForce GTX 960] [3842:2962]
         Kernel driver in use: nvidia
         Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

We can see that my video card is using the nvidia driver. The driver needs to change to the vfio-pci driver.

2: Blacklist via initramfs modules
Execute sudo vim /etc/initramfs-tools/modules
Add these lines, replace the driver and hardware IDs with your own:

softdep nvidia pre: vfio vfio_pci

options vfio_pci ids=10de:1401,10de:0fba
vfio_pci ids=10de:1401,10de:0fba

3: Blacklist via /etc/modules
Execute sudo vim /etc/modules and add these lines, replace the hardware IDs with your own:

vfio_pci ids=1002:699f,1002:aae0

4. Blacklist via /etc/modprobe.d/
Execute /etc/modprobe.d/nvidia.conf where nvidia is the name of the driver your system is currently using.
Add these lines, replace the hardware IDs with your own and nvidia with the driver your system is using:
softdep nvidia pre: vfio vfio_pci
Execute sudo vim /etc/modprobe.d/vfio_pci.conf . Add the following lines and replace the hardware IDs with your own:
options vfio_pci ids=1002:699f,1002:aae0

5. Update grub and initramfs, then REBOOT.

sudo update-initramfs -u
sudo update-grub
sudo reboot now

6. Execute lspci -nnk -d {your hardware ID} again. This time you should see that the driver changed to vfio-pci

$ lspci -nnk -d 10de:1401
41:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1)
         Subsystem: Corp. GM206 [GeForce GTX 960] [3842:2962]
         Kernel driver in use: vfio-pci
         Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

If the driver is still not showing vfio-pci, double check the previous steps for mistakes. The final, least stable method of blacklisting is to add the blacklist to grub. If vfio-pci is already in use, skip this next step.
sudo vim /etc/default/grub
On the line GRUB_CMDLINE_LINUX_DEFAULT= add vfio-pci.ids=1002:699f,1002:aae0. Change the hardware IDs to your own, then run sudo update-grub and reboot again.

Step 5: Installing Software Components

It get easier from here.

Step 6: Apparmor Caveat

Execute sudo apparmor_status
If apparmor is not installed and running skip this section. It doesn’t apply to you.
If you see apparmor module is loaded. in the output you will need to edit /etc/apparmor.d/abstractions/libvirt-qemu.
Executesudo vim /etc/apparmor.d/abstractions/libvirt-qemu
find the section commented # for usb access and change it to look exactly like this:

# for usb access
 /dev/bus/usb/** rw,
 /etc/udev/udev.conf r,
 /sys/bus/ r,
 /sys/class/ r,
 /run/udev/data/* rw,

If you want to pass a hard drive to the guest, you will also need to edit the same file and add the device. If you are using an Nvidia video card this step will be necessary later. Example:
/dev/sdb rw,

Afterwards execute service apparmor restart

If you are still having issue you can check dmesg for apparmor logs with dmesg | grep apparmor. If you see apparmor is still blocking things you can either troubleshoot it or remove apparmor entirely with the following commands:

service apparmor stop
service apparmor teardown
update-rc.d -f apparmor remove
apt remove apparmor
sudo reboot now

Step 7: Configuring the Virtual Machine

  1. Execute sudo apt install virt-manager qemu-kvm ovmf
  2. Download the Windows installation iso file.
    Disk images available directly from Microsoft here.
  3. Open virt-manager
  4. Create a new VM
  5. “Local install media”
  6. “Use ISO image” > browse to the ISO you downloaded
  7. Choose your RAM and CPU allocations.
  8. Check “customize configuration before install”
  9. Under the CPUs tab click the Topology drop down and change sockets to 1, threads to 1, and and cores to the appropriate number of core you want to use.
    Windows 10 is designed to only allow 1 socket, so it will only use 1 core in a 6/1/1 configuration instead of using 6 cores in a 1/6/1 configuration
  10. In the Overview tab change the chipset to Q35
  11. Double check the “current allocation” of CPUs in the CPU tab. It may have changed to 1 when the topology was fixed.
  12. In the Overview tab change firmware from BIOS to OVMF code.
  13. In the Sound tab:
    If you are using spice audio pass through leave the sound card as ich7.
    If you do not plan to do that, change the card to ac97.
  14. In the IDE disk 1 tab click the advanced options drop down and change the disk bus to SATA.
  15. In the IDE cdrom 1 tab change the disk bus to SATA
  16. Click +add hardware
  17. choose PCI host device
  18. Find the IOMMU channel of the device you previously blacklisted and set to use the vfio-pci driver. Select it and click finish.
  19. Repeat step the previous step for all other devices that you want to pass through.
    Remember, you need to pass the entire IOMMU group, so if your video card has a separate device for HDMI audio, that needs to use the vfio-pci driver and be passed through as well.
  20. Click begin installation.
  21. Follow the standard Windows installation steps.

At this point if you are passing an AMD video card to the guest everything should be working fine. You can start installing and playing games. If you are using an Nvidia card, the driver will install successfully, but the video card will fail to initialize when booting with error code 43. There is more work to be done to get the card running.

Bypassing Nvidia Error 43

virsh edit [guest name]
if you dont know your guest name run virsh list
if the list is empty or you get the error “failed to get domain ‘[guest name]'” try putting sudo before all of your virsh commands

<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
<vendor_id state='on' value='[anything 12 characters long]'/>
<hidden state='on'/>
<vmport state='off'/>
<ioapic driver='kvm'/>

Optional: Add a Physical Disk

The virtual disk I created for my Windows installation is only 120GB. Clearly that will only hold half a game with today’s inflated game sizes so I decided to mount an entire disk that I already had formatted as NTFS.

  1. Determine which device is the hard drive you want to mound with grep "/dev/sd*" /etc/mtab. Mine was sdd.
  2. unmount the device from the host with sudo umount <mount path>
  3. mount the drive to the guest with sudo virsh attach-disk <guestname> /dev/<disk> vdc. vdc is the mount point on the guest. More than likely vda and vdb are already taken by the C drive and a a virtual cdrom that holds the install ISO. If you have more than 2 virtual disks installed then something will have already been mounted in vdc. Choose a different letter Eg. “vdd”.

Dealing with the Sound Issue

This ended up being much more of a hassle than I expected. Using the ich6 driver and passing audio over the spice channel caused the same hitching that nearly everyone experiences. The ac97 drivers have not supported any Windows version after Vista. There is a workaround to install the driver anyway but I don’t like the idea of installing something that far out of support. I decided to try to use an HDMI audio isolator so that I could pull audio from the HDMI port. The first device was cheap and only passed mono sound. The second device was also cheap and didn’t pass any sound at all. The next option was more expensive than I was willing to pay. The solution I found was to use the ich6 driver with a cheap USB to 3.5mm sound adapter (Amazon). I used the “add hardware” wizard in qemu to add the USB host device without needing to do any device blacklisting, pulseaudio configuration changes, or IOMMU finagling to get it to work. Its been working flawlessly. The output from the guest and host are run into this mixer which outputs to a multi output amp that provides sound to my headphones and speakers independently.

Helm is not the Email Provider You Want

Update: 2022-12-27
Helm has shut down citing covid supply chain issues and to their credit have released a tool to convert a Helm box to armbian on github. They have also provided instructions on how to create a vpn bridge to enable mail sending.

Helm is a new software as a service provider touted by tech publications such as Ars, Verge, Mashable, and GeekWire that sells you a box to install in your home that can be configured to allow you to self host email, calendar, a VPN endpoint, and file hosting among other services. It costs USD $400 for the hardware plus a recurring yearly USD $100 subscription fee. Helm does not publicly provide the source code or binaries that are run on the box. The only way to get insight into what is run on the box is to look at their open source attributions. Among the attributions includes free email hosting software employed both by small entities (such as HighGuard) and large multinational organizations. The attributions include Postfix, Dovecot, SpamAssassin, openVPN, openSSH, rsync, Duplicity, and even wpa-supplicant. It seems that they use very little home grown software, which is both a good thing and a bad thing.

The good:

The open source software they use is well maintained, well secured, and well known. When Dovecot was tested by Cure53 in 2017 it was graded “near impenetrable”. All of the other open source software I mentioned previously is also known for its well secured status. This package offered automatically configures everything you need for a variety of services without the end user needing to know anything about configuring any of those services.

The bad:

It is dubious whether or not an owner could actually send email from this device because virtually all internet service providers in the United States block the required port 25 that is necessary to send email outbound. They do this because decades ago before the decision to block was made, malware would use home computers to send inordinate amounts of spam email. The block is generally considered a good move, even if it restricts a home user from running their own email from home.

All of the base software is free. The operating system is GNU + Linux, which is free. The service costs $400 plus $100 yearly for free software when yet with very little knowledge you could set your own (better) server running all of the same software for as low as ten dollars per month. With a Digital Ocean virtual private server, barely any knowledge about Linux or email servers, and Modoboa you can have a secure running email service that includes support for a web based email client (something Helm does not offer) and shared calendars. A simple script automatically configures a VPN endpoint on the server for you to use. By following the easy to understand OwnCloud or NextCloud installation instructions you can have a working self hosted DropBox alternative for hosting and sharing files in your own personal cloud. You can even host your own websites from the server for free using software like WordPress or Joomla.

The takeaway:

Helm’s website includes a lot of marketing material that talks about the importance of reclaiming one’s own privacy and maintaining security. I agree wholeheartedly with these views but do not believe that purchasing a Helm home server is the way to go. The actual cost to value ratio of the features provided is much lower than purchasing your own virtual private server hosted in a data center and self hosting all of your content and services. Helm does not provide the same level of control that you would get from owning your own server, as they still control how you use the box and what exactly is installed on it.

SecGen is a Great Tool for training your PenTesters

SecGen is a tool designed by Z. Cliffe Schreuders that generates intentionally vulnerable virtual machines that act as black boxes for training purposes. It is very easy to set up and you can have a running target in 10 minutes. SecGen comes with over 100 preconfigured scenarios and supports CTF events. You are also able to design customized scenarios specific to training needs.

After installing its requirements including vagrant and Oracle VirtualBox, you can have a randomly selected online vulnerable black box just by running ruby secgen.rb run. If the virtual machine can’t be reached it may require configuring a host only adapter in VirtalBox. specific scenarios can be selected with
ruby secgen.rb -s [xml file] run.

SecGen can be found at

Michael Shows Us a Great Example of why RFID Blocking Wallets are Important

Some credit cards contain Radio Frequency IDentification (RFID) chips that enable the “tap to pay” feature on credit terminals for faster payment. Unfortunately, they also open up a new avenue of identity theft.

This video demonstrates just how easy it is to skim the RFID chip found in most credit cards today. In the video, the “attacker” uses a common wireless card scanner but in the real world, there are people who will use much smaller pocket sized equipment to read your cards from your pocket just by “accidentally” bumping into you while in line or in crowded places. An attack I’ve been made aware of is to ask someone for gas money at the pump, and when they accept, joyfully hug them and use the opportunity of close contact to read RFID chips from cards in their pocket.

This attack is ingenious because with pickpocketing, you can be caught stealing from someone much easier because you have to actively take something from them. Putting your hands into someone’s pocket is much more noticeable than bumping into them. With RFID scanning attacks, the attacker causes much less of a nuisance and is therefore much less noticeable.

The Death of Facebook Would Make Everyone Safer

With recent news regarding Facebook and Cambridge Analytica there has been an uptick in comments about the lack of safety provided by Facebook to their users. Websites like Facebook and LinkedIn are valuable assets for attackers when crafting spear phishing attacks because large amounts of personal data are available and can be used imitate company employees as a part of an attack on a company. If Facebook were to fall to the wayside like MySpace and Google Plus, attackers would have one less tool to use against their chosen victims.

There is an even more important effect that would be created if Facebook were to disappear. Many websites and services use Facebook as a way of authenticating and signing people into accounts. Without Facebook’s authentication service many users would have to fall back to using email accounts to authenticate online. Each site would be it’s own account which would lead to “account fatigue”. Account fatigue is the annoyance of having to keep track of a different username and password for every website users log into. To mitigate this, tools like LastPass and Keepass would likely see a steep rise in popularity. Any decent password manager includes a feature to create randomized passwords. This guides users towards having different and complex passwords for every site. This would reduce password reuse. A common attack is to gather usernames and passwords from stolen password databases and try the same username and password combinations on other sites in hopes that users use the same usernames and passwords, allowing the attacker to log in to accounts they should not have access to. Password managers make it easy to mitigate this risk because it is easy to generate a random different password for every website used.

Use LetsEncrypt to Enable HTTPS on your Web Server for Free

LetsEncrypt offers free SSL certificates for websites, allowing you to protect users who access your site.

This guide will go step by step moving an unencrypted HTTP website to using HTTPS on Nginx. For the purpose of this guide, I’ll be using the website There is no content there.

Lets start with the site in nginx.

server {
listen 80;
listen [::]:80;
root /var/www/guide;
index index.html;
access_log off;
error_log off;
location /favicon.ico {
log_not_found off;
access_log off;
location ~ /\.ht {
deny all;

Right now the URL will show whatever is located at /var/www/guide/index/html on the server. To enable HTTPS we will need to get a certificate from LetsEncrypt using CertBot, then set up the site to use it and also redirect HTTP requests to use HTTPS in an intelligent manner. Lets start with getting the certificate.

Install Certbot with apt install python-certbot python-certbot-nginx, if you are using a distribution other than Debian, the package may have a different name or might not be available. The binary can be downloaded from the EFF.

Use Certbot to automatically create a challenge, request the certificate, download it, and install it.

certbot --nginx certonly

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0000_key.pem
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0015_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0015_csr-certbot.pem

The certificate is generated and dropped into /etc/letsencrypt/live/ Now we can make changes to the config file for the site to take advantage of the certificate. The easiest way to do that is to change the top of the server block so that it will use SSL, then add a new server block that uses non-SSL to redirect unencrypted connections to HTTPS.

The new server block:

server {
listen 80;
listen [::]:80;
return 301 https://$host$request_uri;
access_log off;

Then put the old server block right below that with minor changes. Change the listen ports from 80 to 443 ssl and add the path to the cert.

server {
listen 443 ssl;
listen [::] 443 ssl;
ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;
root /var/www/guide;
index index.html;
access_log off;
error_log off;
location /favicon.ico {
log_not_found off;
access_log off;
location ~ /\.ht {
deny all;

Google and Mozilla are pushing for HTTPS to be everywhere

If your default browser is Firefox or Chrome you have have notice recently that both browsers are starting to take a harder stance on insecure login pages.

Whenever inputting text to a field, or when on a login page not secured with HTTPS, both Firefox and Chrome have their own ways of notifying users that the data they are sending, such as passwords or credit card numbers could be intercepted by someone bad.

Chrome is showing “Not secure” next to the URL bar and Firefox puts a banner under the password field of text boxes.



Users on twitter are seeing these notifications and taking it up with the companies that run the sites.

Annoying Web Scanners with Zip Bombs

This one can be filed squarely under “so dumb it works”. This practice wont really do much to increase practical security of a website, but it does create roadblocks for the guys running the tools that look for holes in your security.

Zip Bombs are really large files that are basically empty, so that when you zip the file up it becomes way smaller. For example, is a 4.3 GB file that when fully decompressed is 4.5 PB (petabytes) of data. Thats 4,718,592 GB of data. When vulnerability scanners come in contact with these files they download it and try to unzip it to see whats inside, but because of the huge size of the file they crash or hang and give up with an error.

Vulnerability scanners are kind of annoying because they clog up your logs and don’t actually contribute to your site being any more popular. If your site ever does become vulnerable you could get hacked because everyone and their brother is trying to get in. By looking in access logs, we can see patterns of what resources bots are requesting and what their user agents are. With a simple bit of scripting, we can deliver a zip bomb to the scanner instead of a legitimate resource, wasting their time and hopefully crashing their software.

Read more at Christian Haschek’s blog.