Have you noticed an interesting twist in the ICMP Redirects saga: operating systems of some network devices might install redirect entries and use them for control plane traffic – an interesting implementation side effect of the architecture of most modern network devices.
A large majority of network devices run on some variant of Linux or *BSD operating system, the only true exception being ancient operating systems like Cisco IOS1. The network daemons populate various routing protocol tables and compute the best routes that somehow get merged into a single routing table that might still be just a data structure in some user-mode process.
iCloud Private Relay is a new Internet privacy service from Apple that allows users with iOS 15, iPadOS 15, or macOS Monterey on their devices and an iCloud+ subscription, to connect to the Internet and browse with Safari in a more secure and private way. Cloudflare is proud to work with Apple to operate portions of Private Relay infrastructure.
In this post, we’ll explain how website operators can ensure the best possible experience for end users using iCloud Private Relay. Additional material is available from Apple, including “Set up iCloud Private Relay on all your devices”, and “Prepare Your Network or Web Server for iCloud Private Relay” which covers network operator scenarios in detail.
The design of the iCloud Private Relay system ensures that no single party handling user data has complete information on both who the user is and what they are trying to access.
To do this, Private Relay uses modern encryption and transport mechanisms to relay traffic from user devices through Apple and partner infrastructure before sending traffic to the destination website.
Here’s a diagram depicting what connection metadata is available to who when not using Private Relay Continue reading
Every other blue moon I get a question along the lines of “how could I contribute to netsim-tools”. The process is pretty streamlined and reasonably (I hope) documented in Contributor Guidelines; if you want to get started with an easy task, try implementing OSPFv3 for one of almost a dozen devices (vSRX implementation by Stefano Sasso is a picture-perfect example):
Every other blue moon I get a question along the lines of “how could I contribute to netlab”. The process is pretty streamlined and reasonably (I hope) documented in Contributor Guidelines; if you want to get started with an easy task, try implementing OSPFv3 for one of almost a dozen devices (vSRX implementation by Stefano Sasso is a picture-perfect example):
Recently whilst using pynetbox to create NetBox environment objects I had a need to use variables in the URL of the API calls to allow for reusable functions to perform API calls based on the URL and data fed in as arguments. The reason the URL needs to be fed in as an argument when calling the function is because each NetBox element uses a different API URL.
The purpose of this guide is to provide a procedure that you can use to […]
The post Mikrotik RouterOS Upgrade from Version 6 to 7 first appeared on Brezular's Blog.
DDoS protection quickstart guide shows how sFlow streaming telemetry and BGP RTBH/Flowspec are combined by the DDoS Protect application running on the sFlow-RT real-time analytics engine to automatically detect and block DDoS attacks.
This article discusses how to deploy the solution in a Cisco environment. Cisco has a long history of supporting BGP Flowspec on their routing platforms and has recently added support for sFlow, see Cisco 8000 Series routers, Cisco ASR 9000 Series Routers, and Cisco NCS 5500 Series Routers.
First, IOS-XR doesn't provide a way to connect to the non-standard BGP port (1179) that sFlow-RT uses by default. Allowing sFlow-RT to open the standard BGP port (179) requires that the service be given additional Linux capabilities.
docker run --rm --net=host --sysctl net.ipv4.ip_unprivileged_port_start=0 \
sflow/ddos-protect -Dbgp.port=179
The above command launches the prebuilt sflow/ddos-protect Docker image. Alternatively, if sFlow-RT has been installed as a deb / rpm package, then the required permissions can be added to the service.
sudo systemctl edit sflow-rt.service
Type the above command to edit the service configuration and add the following lines:
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
Next, edit the sFlow-RT configuration file for the DDoS Protect application:
sudo vi /usr/local/sflow-rt/conf.d/ddos-protect.conf
If there’s an IPv6 netblock you’d like your host to stop responding to, one tactic is to blackhole the traffic. That is, send any traffic from your host destined to the troublesome IPv6 netblock into a blackhole. Blackholes are also called null routes.
Let’s say I’m getting repeated SQL injection attacks from various hosts in IPv6 block 2a09:8700:1::/48. Just a totally random example with no basis in reality whatsoever, whoever you are in Belize. There are various ways I can defend against this, but one (sorta ugly) option (I don’t actually recommend, read to the bottom to see my logic) is to create a blackhole aka a null route.
On many flavors of Linux, including Ubuntu 18.04, 20.04, and 22.04, I can accomplish this task with the ip route utility. Let’s take a look at our existing host routing table.
user@host:~$ ip route
default via 123.94.146.1 dev enp1s0 proto dhcp src 123.94.146.227 metric 100
169.254.169.254 via 123.94.146.1 dev enp1s0 proto dhcp src 123.94.146.227 metric 100
123.94.146.0/23 dev enp1s0 proto kernel scope link src 123.94.146. Continue reading