Jamie Scaife - United Kingdom 🇬🇧 

Introduction to BGP Routing and Security - Part 2: Preventing Transit

Saturday 31st October 2020

A transit AS (Autonomous System) refers to an AS that is able to provide IP transit, i.e. it can receive packets from one peer and forward them on through another. In other words, a transit AS allows 'through' traffic, rather than just traffic explicitly destined for itself. It's a bit like the difference between a main road and a dead end on a road traffic network - a main road always leads somewhere else, while a dead end only leads to itself.

The most common example of transit AS's is large ISPs and transit providers, which each have multiple connections with a diverse range of networks, allowing for resilient routing and connectivity. However, any BGP setup that is multi-homed (i.e. has two or more unique peers) has the potential to become a transit AS, and this is by-design.

For example, if you are peering with two different upstream ISPs, but they don't have a direct connection between each other (or the connection is disrupted), the traffic might end up being routed through your network, as ultimately your network provides a valid path between the two ISPs.

If you are a network provider or ISP yourself, then this is most likely what you want to happen, as ultimately that's what your business is for. However, if you're simply wanting to announce the prefixes for your own network, it may be undesirable to become a transit AS, as your network resources and bandwidth may be used to handle traffic that is completely unrelated to your business operations. To use the road traffic network analogy again - it's like an emergency diversion routing traffic from a major road down a quiet back street and overloading it, much to the dismay of the residents!

This article will detail how you can configure your Quagga BGP daemon to prevent becoming a transit AS. Continue reading...

BGP DN42 Guide

Tor is a Great SysAdmin Tool

Sunday 9th August 2020

Tor is a fantastic networking and privacy technology that makes private and anonymous browsing available to millions. Despite this, it is unfortunately seen by some people as a system that solely exists to facilitate an illegal criminal underground,

However, to take a literal view, Tor is just a networking tool, and it can be used in any way that you want. The features that enable privacy and anonymity are also extremely useful for many of the tasks carried out by Network Engineers and Systems Administrators on a daily basis. For example:

• Testing IP address based access rules
• Testing internally-hosted services from an external perspective
• Making reliable external DNS lookups when operating in a split-horizon DNS environment
• Bypassing blocked outbound ports
• Exposing services when behind NAT or CGNAT

In this article, I will demonstrate how Tor can be used to carry out some of these tasks, and why using Tor may be advantageous to other methods. Continue reading...

Security Tor

Introduction to BGP Routing and Security - Part 1: BGP Peering with Quagga

Monday 1st June 2020

Quagga is a network routing software suite providing implementations of various routing protocols, including RIP, OSPF and BGP. It is a fork of the discontinued GNU Zebra project, and utilises a configuration syntax very similar to that of Cisco IOS.

An 1804 illustration by Samuel Daniell of a South African quagga, an extinct subspecies of plains zebra after which the Quagga network routing software suite was named. Source (Public Domain)

Unlike traditional routing daemons which interact directly with the kernel, Quagga operates a central kernel routing manager (known as zebra) which exposes an API to the various Quagga routing daemons. This allows the routing daemons to be enabled, disabled and configured on a 'pick and mix' basis, including the ability to run multiple of the same routing daemon on one machine.

This article and series will be primarily focusing on Quagga BGPd, which is Quagga's BGP routing implementation. Continue reading...

BGP DN42 Guide

Using SPF Macros to Solve the Operational Challenges of SPF

Monday 11th May 2020

Sender Policy Framework (SPF) provides a way to restrict the mail servers that are permitted to send as your domain, and is particularly effective when used with DMARC.

However, maintaining an SPF policy for a large or complex infrastructure with numerous distinct mail servers can pose a significant operational challenge. Some of the most common issues include:

• SPF record is too long
• Maximum number of DNS lookups has been reached
• Keeping your SPF record up-to-date when mail is sent by third-parties
• Keeping track of which whitelisted senders are for what, who put them there, and removing them when they're no-longer needed
• Having to globally whitelist third-party systems when they only need to send-as a single or small number of addresses
• SPF record syntax becoming messy or breaking when it is maintained by multiple different people

SPF macros, a seldom used yet widely supported feature of the SPF specification, provide a potential solution to some of these challenges.

This article includes an introduction to SPF macros, as well as several examples of how they can be used to solve the various operational complications that SPF so often poses. Continue reading...

Security RFC Guide