Spoofing Incidents

Automated network security incident reporting.

The internet is run by many (mostly) collaborating companies. This leaves a lot of room for mistakes and bad actors to show up.
When a configuration mistake is made or a bad actor shows up in an unprotected network segment it's possible for DDoS attacks and other malicious activities to be carried out. Our Spoofing Incidents helps by making network operators aware of potential malicious activities. On this page we discuss how this service work and offer potential remediation when a notification has been sent.

This system is fully automated and does not require any human intervention. The system is neither designed nor equipped to interrupt the operation of your connections with ERA-IX, the sole purpose is to create awareness. However, after a notification has been sent, it is recommended to look into the potential causes. On a larger, more complex network, finding the root cause of the notification might be more difficult. If you have received a notification and have no idea where to start or can't find the cause , please get in touch. We will try to be of assistance with suggestions and (more) tips.

Amplification Denial of Service attacks

In the image you can see an example of an Amplification Denial Of Service attack. Which is something this tooling helps to make network operators aware about.

A bad actor may send a packet with a 'spoofed' source IP address, causing the reply to aforementioned packet to go to another host (the target). The reply sent by the DNS-server ot the Attack target is larger than the request the bad actor had to send out. This allows a DDoS attack to be amplified.
By working to prevent spoofed IP packets from being sent out, and causing awareness where this is possible, network operators can take preventative action.

Common amplification attacks you may encounter are: DNS (UDP port 53), NTP (UDP port 123), CLDAP (UDP port 389). There are more protocols which could be utilized, but these protocols are (most) commonly left open to the internet and thus make for reliable amplification vectors.

It is recommended, when possible to close these ports towards the internet to prevent them being exploited for DDoS attacks.

Getting started with Spoofing Incidents

The Spoofing Incidents will not automatically be enabled on all connections. If your connection does not (yet) have Spoofing Incidents enabled, you can request it to be activated.
With Spoofing Incidents enabled, you will receive a notification any time an anomaly is detected, up to one per 30 days. In our portal, under the security tab for your connection you can view up to 25 anomalies that occurred in the last 7 days. You will be able to view these statistics regardless of if you have been opted in for notifications, allowing you to still review the statistics manually.

Spoofing notifications example
Example of spoofing notifications.

Detection and notifying

The system builds upon our advanced network telemetry systems, allowing it to operate alongside our other services such as our unique AS2AS destinations feature.
The system for detecting anomalies is based on IRR data, and we would be able to notify based on this. Unfortunately there's quite often a discrepancy between IRRdb data and the real world, for this reason we can not solely rely on IRR data to tell us which IPs should be originated by which network. To get reliable detection of configuration errors and anomalies we have put in place a few classifiers. When you receive a notification, the incidents will be listed along with the classifier that was hit.
NOTICE: The prefixes used may not be complete, and have solely been selected to offer the most reliable detection of misconfigurations

Classifier Subnets Possible Remediations
RFC1700
(Special addresses)
0.0.0.0/8, 127.0.0.0/8, 240.0.0.0/4 These IP addresses should never originate from a production network, locate the network segment the packets are originating from and remediate the issue.
RFC1918
(Internal use)
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Ensure (any) firewall responsible for NAT/PAT is configured properly.
Avoid configuring RFC1918 address connected directly to DFZ network segments.
RFC5737
(Reserved Documentation)
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 These IP addresses should never be configured on a production network, locate the network segment the packets are originating from and remediate the issue.
LINK_LOCAL
(APIPA)
169.254.0.0/16 Same as RFC1918. We found this to be caused mostly by auto-configured Microsoft Windows machines (APIPA).