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.
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). |