Plus addressing (also known as sub-addressing) lets you receive messages into one email account from multiple sub-addresses, such as user+tag@example.org. For example, your main email might be user@example.org, but you can also use user+work@example.org for work-related apps and still receive all messages in the same inbox. This way, you’ll know which messages are work-related based on the address used.

Another bonus is when all such messages are automatically moved to a sub-folder named after the used tag (in this case work).

How To Achieve It In Stalwart

Good news — plus addressing works by default in Stalwart except for the bonus case, when you want to also move messages into appropriate folders. To achieve it, we need Sieve scripts.

Your first idea might be to add Sieve scripts into System scripts or User scripts in the Stalwart admin web UI. This will not work because you can’t use the fileinto directive in those scripts. We need to use something else.

Use ManageSieve

ManageSieve is a protocol (RFC 5804) for users to add and manage their own Sieve scripts on the mail server. You need a ManageSieve client to do it. I recommend SieveEditor.

This Sieve script detects the “tag” part of the email address, creates a folder if necessary, and moves the message into the folder.

require ["envelope", "fileinto", "mailbox", "subaddress", "variables"];

# Check if the mail recipient address has a tag (:detail)
if envelope :detail :matches "to" "*" {
  # Create a variable `tag`, with the the captured `to` value normalized
  set :lower "tag" "${1}";

  # Store the mail into a folder with the tag name:
  if mailboxexists "${tag}" {
    fileinto "${tag}";
  } else {
    fileinto :create "${tag}";
  }
}

Recently the company I work for started to use Palo Alto's GlobalProtect as a solution for VPN. The solution works quite well but has 2 flaws by default that I don't like.

First is that the GlobalProtect agent (client) runs automatically after the operating system turns on and this behavior can't be changed in the settings. You can find a solution for it on other blogs.

The second flaw is that it automatically sends ALL of my traffic through my company's VPN. I don't think this is beneficial for the company but most importantly it goes against my privacy. There is no need for the employer to know what goes on in my traffic.

This article describes:

• How to split traffic based on IP addresses

• How to do traffic splitting automatically after the GlobalProtect agent connects to VPN

I will only focus on Mac OS but similar steps can be taken also on other operating systems.

Traffic split with GlobalProtect

When you connect to VPN with GlobalProtect, it creates a new network interface and edits the routing table so all our traffic is sent through this new network interface.

To solve this we need to remove a route created by GlobalProtect and then create a few new routes for only those IP addresses which we want to be directed through our VPN.

We implemented it in Python (based on this blog post). Save the script as split_vpn.py to your home folder. Edit the lists VPN_NETS and VPN_HOSTS based on your needs. Then you can run it every time you want to split traffic.

#!/usr/bin/env python
import os
import re
import subprocess
import sys

WIRELESS_INTERFACE = 'en0'    # could be different on other systems
TUNNEL_INTERFACE = 'utun2'

VPN_NETS = [
    '172.222',                # subnets which should use VPN
]

VPN_HOSTS = [
    '90.131.25.244',
    '90.131.25.240',        # IP address which should use VPN
]


def get_tunnel_interface():
    # Get last utun interface.
    for line in reversed(subprocess.check_output(["ifconfig"]).splitlines()):
        match = re.match(r"(utun\d)", line)
        if match:
            return match.groups(1)[0]


def split_vpn_traffic():
    if os.getuid() != 0:
        sys.exit("Please, run this command with sudo.")

    gateway = None
    tunnel_interface = get_tunnel_interface()
    out = subprocess.check_output(("netstat", "-nrf", "inet"))
    routes = out.decode("utf-8").split("\n")[3:]

    for route in routes:
        route = route.split()
        interface = route[3]
        if interface == WIRELESS_INTERFACE:
            gateway = route[1]
            break

    if gateway is None:
        sys.exit("Unable to determine VPN default gateway.")

    print("Resetting routes with gateway " + gateway)
    subprocess.call(
        ("route", "-n", "delete", "default", "-ifscope", WIRELESS_INTERFACE)
    )
    subprocess.call(
        ("route", "-n", "delete", "-net", "default", "-iface", tunnel_interface)
    )
    subprocess.call(("route", "-n", "add", "-net", "default", gateway))

    print("\nAdding routes for addresses which should go through VPN.")
    for addr in VPN_NETS:
        subprocess.call(
            ("route", "-n", "add", "-net", addr, "-iface", tunnel_interface)
        )
    for addr in VPN_HOSTS:
        subprocess.call(
            ("route", "-n", "add", "-host", addr, "-iface", tunnel_interface)
        )


if __name__ == "__main__":
    split_vpn_traffic()

Automatic traffic split after connecting to VPN

Now that we have the script to split our traffic, we want it to run automatically after we connect to VPN with GlobalProtect. As it is stated in the documentation, GlobalProtect agent can run commands before connecting, after connecting and before disconnecting.

Follow these steps to run the script after GlobalProtect agent connects to VPN:

1. Disable and close GlobalProtect

2. Run killall cfprefsd

3. Open in editor /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist

4. Add to the section /Palo Alto Networks/GlobalProtect/Settings/ following (edit path based on your username):

<key>post-vpn-connect</key>
<dict>
        <key>command</key>
        <string>/Users/your_usename/post_vpn_connect.sh</string>
        <key>context</key>
        <string>admin</string>
</dict>

1. Add this script to your home folder and save it as post_vpn_connect.sh

#!/bin/bash
osascript -e 'display notification "Start" with title "VPN traffic split"'

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

${DIR}/split_vpn.py

country=`curl ifconfig.co/country`

osascript -e "display notification \"End. You country is $country\" with title \"VPN traffic split\""

Now your traffic should be automatically split each time you connect to VPN with GlobalProtect. Nice!

A few months back I worked on a website for a local city festival. It’s a popular festival with lots of guests from different countries and a quite long history.

I migrated the site from WordPress to a brand new Wagtail solution. We have also moved from shared hosting to VPS. I wanted to progress quickly with development. So I launched a new version of the website as soon as possible with just uWSGI responding to all the HTTP traffic. Soon after the launch, I started to get weird errors in Sentry:

Not truncated message from the error is:

Invalid HTTP_HOST header: 'corpse.xyz'. You may need to add 'corpse.xyz' to ALLOWED_HOSTS.

The message was clear. Requests were coming to my server from a domain that is not allowed. How it can be? “Maybe someone pointed his domain to my server’s IP address by mistake?” was first thought in my head. But there were many of those requests from many different domains. And they tried to access weird URLs like:

/wp-login.php
/wp/wp-login.php
/cgi-bin/test.sh
/cgi-bin/hello.sh

And also some of them came not from domain names but IP addresses. That was even weirder.

You can’t trust Host header

After some time I found the reason behind this strange behavior. Domains and IP addresses I saw in Sentry or logs are from the HTTP header called “Host”. And all HTTP headers are set by the client. In other words, you can’t trust HTTP headers. Clients can set the header to whatever value they like. For example, this is how you can do it in Python with library requests:

import requests

requests.get("http://hanusovedni.sk", headers={"Host": "corpse.xyz"})

Those weird requests were coming not from humans but from robots. There are a lot of robots that scan all IP addresses that exist on the Internet and are looking for vulnerabilities on websites. There are two groups of such robots:

1. attackers who want to misuse vulnerabilities

2. white-hat organizations like The Shadowserver Foundation finding and reporting vulnerabilities

Either way, you don't want your application to deal with them.

Solution

There is actually no real problem when you see this type of exception. It means Django is doing its job and filters malicious requests. But we want to filter out such requests as soon as possible. In most cases, it means filtering it at reverse proxy. In my case it‘s Traefik. You can create rules for Treafik as labels on your services in docker-compose.yml. This rule will pass to Django only requests with the Host header set to my domain.

traefik.http.routers.web-router.rule=Host(`hanusovedni.sk`, `www.hanusovedni.sk`)

The full definition of service from docker-compose.yml:

services:
  web:
    image: ${WEB_IMAGE}
    env_file:
      - secrets.env
    environment:
      DJANGO_SETTINGS_MODULE: "hanusovedni.settings.production"
    volumes:
      - /var/www/static:/static_root
      - /var/www/media:/media_root
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.web-router.rule=Host(`hanusovedni.sk`, `www.hanusovedni.sk`)"
        - "traefik.http.services.web.loadbalancer.server.port=8000"

What can an attacker do with the "Host" header anyway?

Let me introduce you to the world of HTTP Host header attacks. Your website can be in danger only if you (or any code that you run) use the "Host" header. A typical example is about sending an email with a link to reset the password. Let's assume you build the message this way:

def build_message_for_password_reset(request):
    token = "hash42"   # usually there will be some kind of hash
    link = "http://" + request.META['HTTP_HOST'] + "/reset-password/" + token
    return f"Click on this link to reset your password: {link}"

If the attacker sends as the "Host" header his website "evil-web.com" the user will (potentially) click on this URL:

http://evil-web.com/reset-password/hash42

At this point, the attacker can catch the token and reset the user's password and show the user whatever he wants.

Now you understand why it's important to correctly set ALLOWED_HOSTS in Django's settings. 😉