1. How does Radar determine providers?

Radar uses three factors in order to determine the providers:

• Where your AS’s prefixes are announced to by neighbors;
• What priority your routes have at your neighbors’ AS;
• What prefixes are announced by your neighbors to your AS.

2. My AS has a large number of peerings but Radar detects only some of them.

Radar uses the data from AS_Path attribute for building the relations model. In case neither your AS nor your peering partner exports the relevant route information, this peering is undetectable for Radar model. You can establish BGP multihop session with our reflector in your Control Panel and we will update the information about your peerings within 24 hours.

3. What do “unspecified relations” mean?

There are several cases when it’s impossible to exactly determine which one of the two AS is a client and which one is a provider. This situation may occur in case of common administrative operation (both AS belong to a single company) as well as in case when Route Leak happens for a significant number of prefixes.

1. What are Route Leaks?

BGP route leaks are explained in great detail within IETF RFC 7908 “Route leak is a propagation of routing announcement(s) beyond their intended scope. That is an announcement from an Autonomous System (AS) of a learned BGP route to another AS violates the intended policies of the receiver, the sender, and/or one of the ASes along the preceding AS_PATH.  The intended scope is usually defined by a set of local redistribution/filtering policies distributed among the ASes involved”. The result of a route leak can be a redirection of traffic through an unintended path that may enable eavesdropping or traffic analysis and may or may not result in an overload or black hole.  Route leaks can be accidental or malicious but most often arise from accidental misconfigurations. We are monitoring only routes with valley-free violations.

Prefixes in Route Leaks
This event is pushed by the Radar system when a route leak is detected on your prefixes.

Created Route Leaks
This event is pushed by Qrator Radar system when your autonomous system is generating a BGP route leaks event.

Accepted Route Leaks
This event is pushed by Qrator radar system when your autonomous system has accepted a BGP route that has been leaked by a misbehaving autonomous system on the Internet (this event can be received if you have a BGP session with the Radar system).

2. What are Hijacks?

BGP Hijack occurs if another BGP ASN advertises address space that belongs to a particular ASN without correct route object or ROA record. As a result of this incident, a significant part of the traffic can be redirected to the wrong BGP ASN where it may be analyzed or dropped.

Created Hijacks
This event is pushed when Qrator Radar system detects a BGP hijacks generated by your autonomous system. 

Affected Hijacks
This event is pushed by Qrator Radar when the system detects a BGP hijacks that could damage the connectivity of your autonomous system.

3. What are Bogons?

Bogon prefixes A bogon prefix is an IPv4 or IPv6 prefix address that should typically not be advertised to the Internet. Typically, it is about announcing IPv4 or IPv6 private addressing scheme, link-local address, 6to4 address, etc. If those prefixes get propagated through the Internet, it can result in providing connectivity to pieces of infrastructure that generally should not be reachable and then expose this infrastructure to any cyber-attacks like DDoS.

Accepted Bogon prefixes
This event is pushed by the Qrator Radar system when your autonomous system has accepted prefixes that are not supposed to be received from the public Internet (typically private addressing, link-local prefixes or invalid CIDR blocks).

Affected and accepted bogon PATH’s
This event is pushed by the Qrator Radar system when your autonomous system has announced or accepted BGP Path’s that are not valid for the public Internet. Typically, this event is happening when you are sending or accepting AS PATH with private AS number (as stated by IANA: AS0, AS23456 and AS ranges: AS64496 - AS131071, AS4200000000 -AS4294967295).

4. What are BGP loops?

BGP loops are dynamic loops that usually appear due to a change of the BGP configuration policy, e.g. when a new router starts announcing some prefixes and the existing routers still have not updated their configurations. Another common reason of such loops is simply an error in BGP configuration, e.g. improperly configured local preference policy.

5. What are DDoS Amplifiers?

DDoS amplifiers are serious vulnerabilities which can be used by attackers to produce large amounts of network traffic. Combined with IP spoofing, these vulnerabilities can be used for bandwidth consumption attacks.

Amplification attacks can be based on ICMP and UDP protocols. ICMP amplification is only possible in the case of serious network configuration errors. On the other hand, UDP amplification is often allowed by the default settings of a vulnerable server.

There exist about 15 network protocols vulnerable to amplification attacks. At this moment we are able to detect 9 most important protocols: DNS, NTP, SNMP, SSDP, NETBIOS, RIPv1, PORTMAP, CHARGEN, QOTD.

5.1. How can I check DNS Amplifier presence?

In order to detect whether the particular server is vulnerable, we simply need to send any general query to this server. In particular, we can use the following command:

dig @$ip +edns=0 +ignore com ANY

where $ip is the IP address of the server, and then look at the line containing «MSG SIZE».

Mitigation:

• Truncating large responses, forcing TCP mode;
• Securing your open recursive resolvers (see Link);
• Rate-limit at authoritative name servers (see Link).

5.2. How can I check NTP Amplifiers presence?

In case of NTP, amplification is achieved using monlist request. The following command detects whether a server is vulnerable:

ntpdc -nc monlist $ip

Each line in the response corresponds to one UDP packet with IP packet length 468.

Mitigation:
The best option is disabling monlist at NTP servers. This request type is not necessary for time synchronization and it has very few legitimate use cases. To disable this request, you need to add the following line to ntp.conf:

restrict default noquery

Another option is filtering monlist response packets, that is UDP packets with source port 123 and IP packet length equal to 468.

5.3. How can I check SNMP Amplifiers presence?

You can use the following command to detect if the server is vulnerable:

snmpbulkget -v2c -c public $ip 1.3

It checks for the most common vulnerability type. Here public is the default public community name for SNMP, and 1.3 stands for iso.org request OID.

Mitigation:
It is very important not to use the default value of the public community.
It is also recommended to restrict the range of allowed source IP addresses in requests.

5.4. How can I check SSDP Amplifiers presence?

To check for this vulnerability, you can send UDP packet with destination port 1900 and the following payload:

M-SEARCH * HTTP/1.1 \r\n
Host: 239.255.255.250:1900 \r\n
Man: "ssdp:discover" \r\n
MX: 3 \r\n
ST: ssdp:all \r\n
\r\n
                    

Mitigation:
The best solution is to restrict the range of allowed source IP addresses in requests.

5.5. How can I check NETBIOS amplifiers presence?

You can use the following command to detect if the server is vulnerable:

nmblookup -A $ip

Mitigation:
The best option is filtering NB and NBSTAT requests from external networks.

5.6. How can I check RIPv1 amplifiers presence?

The server is vulnerable to RIPv1 amplification attacks if it responds on the request of all routes. We can make such a request using the following command:

nmap -p 520 -sU -Pn $ip

Mitigation:
Switching to RIPv2 or a later version and turning on authentication.
Restricting the range of allowed source IP addresses in requests.

5.7. How can I check PORTMAP amplifiers presence?

To check for this vulnerability, you can use the following command:

rpcinfo -T udp $ip

Mitigation:
Disabling Portmapper along with all other RPC services across the open Internet.
Restricting the range of allowed source IP addresses in requests.
Forcing TCP mode.

5.8. How can I check CHARGEN or QOTD amplifiers presence?

In order to detect whether the server is vulnerable, you can send any UDP packet with destination port 19 (CHARGEN) or 17 (QOTD) to this server. In particular, you can use the following commands:

nc -u $ip 19 <<<''		# for CHARGEN

nc -u $ip 17 <<<''		# for QOTD

Mitigation:
The best solution is disabling all legacy protocols including CHARGEN and QOTD.

5.9. How can I check CLDAP amplifiers presence?

A query is used to get information about LDAP directories. You can use the following command to detect if the server is vulnerable:

printf "\x30\x84\x00\x00\x00\x2d\x02\x01\x01\x63\x84\x00\x00\x00\x24\x04\x00\x0a\x01\x00\x0a\x01\x00\x02\x01\x00\x02\x01\x00\x01\x01\x00\x87\x0b\x6f\x62\x6a\x65\x63\x74\x63\x6c\x61\x73\x73\x30\x84\x00\x00\x00\x00\x00" | nc -u -w1 $ip 389

Mitigation:
Ingress filtering of the CLDAP port (389) from the Internet will prevent discovery and subsequent abuse of this service.
Restricting the range of allowed source IP addresses in requests.

Alternatively, you can configure proactive filtering rules for snort.
Read more here.

5.10. How can I check CoAP amplifiers presence?

Protocol for working with the Internet of Things.
Amplification is based on referring to the .well-known\core endpoint to obtain links about resources hosted by a server.

You can use the following command to detect if the server is vulnerable:

printf "\x40\x01\xba\x77\xbb.well-known\x04core" | nc -u -w1 $ip 5683

Mitigation:
Configure appropriate filtering rules in firewalls for UDP port 5683.
Restricting the range of allowed source IP addresses in requests.

5.11. How can I check Quake amplifiers presence?

In this type of amplification, a "getstatus" request is sent to the game server.

You can use the following command to detect if the server is vulnerable:

printf "\xff\xff\xff\xffgetstatus" | nc -u -w1 $ip 27960

Mitigation:
Configure appropriate filtering rules in firewalls for UDP port 27960.
You can look towards filtering by matching payload string and rate limiting.

5.12. How can I check Steam amplifiers presence?

Obtaining information about the game server using the "Source Engine Query" command.
You can use the following command to detect if the server is vulnerable:

printf "\xff\xff\xff\xffTSource Engine Query\x00"| nc -u -w1 $ip 27015

Mitigation:
Configure appropriate filtering rules in firewalls for UDP port 27015.
You can look towards filtering by matching payload string and rate limiting.

1. Created Hijacks

For Hijack description, refer to the "Radar Monitor - Security Issues" section 2.

Notification Description:

• Created Hijacks: This event is pushed when Qrator Radar system detects a BGP hijacks generated by your autonomous system. On such an event, you should consider checking your BGP configuration and prefixes you announce towards your transit providers and adapt your BGP policies and prefixes to avoid the announcement;
• Target prefix:Prefix that is currently announced and that has created the hijack situation. This information should be used when you investigate the misconfigured router;
• Affected prefix:Prefix that announced by another AS and that is suffering from the hijack announced by the misbehaving autonomous system;
• Target AS:BGP autonomous system that propagates the BGP hijack prefix;
• Affected ASN:BGP autonomous system that owns the hijacked prefix and that could suffer from the BGP hijacks currently propagated;
• Propagation:Amount of ASN’s managed by radar where the BGP hijacks have been accepted and detected;
• Severity:always high, because it’s a critical error.

Network automation:You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (created-hijacks).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [HIGH] <AS197068> Created Hijacks

2. Affected Hijacks

For Hijack description, refer to the "Radar Monitor - Security Issues" section 2.

Notification Description:

• Affected Hijacks: This event is pushed by Qrator Radar when the system detects a BGP hijacks that could damage the connectivity of your autonomous system. On such an event, you should consider:
• You can generate routes with the more specific prefix (the prefix length is larger than the illegally announced) of the impacted prefix and thus return the traffic. In case if these routes can be considered as invalid ones announce route with the impacted prefix;
• If prepend policy was applied on affected prefixes it must be removed;
• The value for Origin attribute must be set to IGP;
• The BGP ASN that has generated the BGP hijacks and its upstream providers must be contacted via emails.
• Target prefix: Prefix the BGP Hijacks route is announcing;
• Conflict prefix: Prefix that is recorded to Internet authorities and that is suffering from the BGP hijacks announced by the misbehaving autonomous system;
• Target AS: BGP autonomous system that propagates the BGP hijack prefix;
• Conflict ASN: BGP autonomous system that owns the hijacked prefix and that could suffer from the BGP hijack currently propagated;
• Propagation: Number of ASN’s managed by radar where the BGP hijacks has been detected;
• Severity: Depends on hijack type and propagation (see table below).

	Local Propagation	Regional Propagation	Global Propagation
Less specific	Low severity	Low severity	Medium severity
Equal	Low severity	Medium severity	High severity
More specific	Low severity	Medium severity	High severity

Network automation:You should consider using Qrator Radar API generate automatic network remediation/configuration checks when this event occurs (affected-hijacks).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [LOW] <AS197068> Affected Hijacks

3. Prefixes in Route Leaks

For Route Leak description, refer to the "Radar Monitor - Security Issues" section 1.

Notification Description:

• Prefixes in route leaks: This event is pushed by the Radar system when a route leak is detected on your prefixes. We rely on the full view you share with radar via the eBGP sessions established between our two AS’s. On such an event you should consider:
• Contact the leaker ASN and its upstream providers via email;
• Add the ASN of the leaker in your AS PATH attribute for this route. By doing this, the leaker will drop its announcement due to the loop prevention mechanism of BGP. For example, you can send a route with an AS_PATH like this: ORIGIN_ASN, LEAKER_ASN, ORIGIN_ASN;
• Prefix: BGP route prefix suffering from route leaks;
• Origin: Origin ASN of the prefix;
• Leaker: Autonomous system which is misconfigured and generate route leaks;
• AS Paths: AS PATH observed by the Radar system and that has generated the route leaks event. We do see where, in the AS PATH, the misconfigured ASN is positioned;
• Propagation: the amount of autonomous system managed by Radar that has accepted the route leaks.
• Severity: Depends on propagation
• Local propagation – low
• Regional propagation – medium
• Global propagation – high

Network automation: You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (prefixes-in-leaks).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [MEDIUM] <AS197068> Prefixes in Route Leaks

4. Created Route Leaks

For Route Leak description, refer to the "Radar Monitor - Security Issues" section 1.

Notification Description:

• Created route leaks: This event is pushed by Qrator Radar system when your autonomous system is generating a BGP route leaks event. On such an event you should consider:
• Check your BGP ingress filter policies towards your peers;
• Pay particular attention to your communities’ configuration. Misconfigured communities are the more common mistake in such a situation;
• Prefix: IP prefix which is suffering from the BGP route leaks event;
• Origin: Origin ASN of the prefix suffering from the route leaks event;
• Leaker: ASN that generates the BGP route leaks issue. In most cases, this autonomous system has been misconfigured and needs to fix its BGP routing policies to solve the problem;
• AS_PATHs: AS_PATH that include the route leaks. The ASN that generate the route leaks is written in red;
• Propagation: the amount of autonomous system managed by Radar that has accepted the route leaks.
• Severity: Depends on propagation
• Local propagation – low
• Regional propagation – medium
• Global propagation – high

Network automation: You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (created-route-leaks).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [HIGH] <AS197068> Created Route Leaks

5. Accepted Route Leaks

For Route Leak description, refer to the "Radar Monitor - Security Issues" section 1.

Notification Description:

• Accepted route leaks: This event is pushed by Qrator radar system when your autonomous system has accepted a BGP route that has been leaked by a misbehaving autonomous system on the Internet (this event can be received if you have a BGP session with the Radar system). This feed could generate a significant amount of notifications. This feed should be managed via some form of automation for you to pay attention only to leaks towards destinations you are regularly using. On such an event you should consider:
• Create an AS PATH filter on the BGP neighbors sending the route leaks;
• Set a LOCAL_PREF value to zero for this particular route;
• Drop this particular route;
• Prefix: IP prefix that suffers from a BGP route leaks;
• Origin: BGP Origin ASN of the prefix;
• Leaker: BGP autonomous system that is misconfigured and that generates the route leaks;
• AS_PATH’s: AS_PATH attribute of the route. You will see where in the path the leaked ASN is present;
• Severity: Always set as medium.

Network automation: You should consider using Qrator Radar API generate automatic network remediation/configuration checks when this event occurs (accepted-route-leaks).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [MEDIUM] <AS197068> Accepted Route Leaks

6. Announced Bogon Prefixes

For Bogons description, refer to the "Radar Monitor - Security Issues" section 3.

Notification Description:

• Announced bogon prefixes: This event is pushed by Qrator radar system when your autonomous system is announcing routes with a prefix which is not valid for the public Internet. In most cases, it is a route with private addressing that should typically stay within your ASN and should not be advertised to the outside world. On such an event you should consider:
• Investigate a problem on your BGP filter configuration and in particular check the egress filters applied on eBGP sessions towards your peers and transit providers;
• Prefix: Prefix that has been identified by Qrator Radar has been undesirable in a public Internet BGP routing table;
• Origin: Origin autonomous system that has generated this bogon prefixes event and notification;
• Bogon type: Type of bogon prefix (private addressing, link-local, etc.);
• Propagation: Amount of autonomous system managed by Radar that has announced bogon prefixes; For announced bogon prefixes, during the propagation calculation, we exclude the source ASN from consideration, which can sometimes lead to a value of 0 if the route with these prefixes did not cross any other eBGP border. That happened historically, because sometimes BGP session filters towards our collector may be weaker compared to filters with other operators. Therefore, if the route has not spread anywhere beyond the given AS, but we still see it, then we want to display this situation as the safe one.
• Severity: Always set as medium.

Network automation: You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (announced-bogon-prefix).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [MEDIUM] <AS197068> Announced Bogon Prefixes

7. Accepted Bogon Prefixes

For Bogons description, refer to the "Radar Monitor - Security Issues" section 3.

Notification Description:

• Accepted bogon prefix: This event is pushed by the Qrator Radar system when your autonomous system has accepted prefixes that are not supposed to be received from the public Internet (typically private addressing, link-local prefixes or invalid CIDR blocks). On such an event, you should consider:
• Investigate a problem on your BGP filter configuration and in particular check the ingress filters applied on eBGP sessions towards your peers and transit providers;
• Prefix: Prefix that has been identified by Qrator Radar has been undesirable in a public Internet BGP routing table;
• Origin: Origin autonomous system that has generated this bogon prefixes event and notification;
• Bogon type: Type of bogon prefix (private addressing, link-local, etc.);
• Propagation: Amount of autonomous system managed by Radar that has accepted bogon prefixes;
• Severity: Always set as high.

Network automation: You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (accepted-bogon-prefix).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [HIGH] <AS197068> Accepted Bogon Prefixes

8. Accepted and Affected Bogon PATHs

For Bogons description, refer to the "Radar Monitor - Security Issues" section 3.

Notification Description:

• Accepted and affected bogon PATH’s: This event is pushed by the Qrator Radar system when your autonomous system has accepted or announced BGP Path’s that are not valid for the public Internet. Typically, this event is happening when you are sending or accepting AS PATH with private AS number (as stated by IANA: AS0, AS23456 and AS ranges: AS64496 - AS131071, AS4200000000 - AS4294967295). On such an event, you should consider:
• Investigate a problem on your BGP filter configuration and in particular check the ingress and egress filters applied on eBGP sessions towards your peers and transit providers. Depending on BGP implementation, we may have to explicitly ask BGP to remove those private ASNs from you paths;
• Prefix: IP prefix that suffers from a route with bogon ASN in AS_PATH;
• Origin: Origin autonomous system that has generated this affected bogon event and notification;
• Severity: Always set as medium.

Network automation: You should consider using Qrator Radar API to generate automatic network remediation/configuration checks when this event occurs (affected-bogon-paths, accepted-bogon-paths).

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject:
• [BGP ALERT] [MEDIUM] <AS197068> Accepted Bogon Paths
• [BGP ALERT] [MEDIUM] <AS197068> Affected Bogon Paths

9. Change in Prefixes

Notification Description:

• Change in prefixes: This event is pushed by the Qrator Radar system when a prefix change its status, namely been added or withdrawn from your BGP table. In addition, we check the following statuses:
• ROA following this procedure: https://tools.ietf.org/html/rfc6811#section-2.1;
• If the corresponding route object is not correct. Radar check the presence of equal or less specific objects for the specified prefix and ASN in the data of IRR databases. After Radar system has checked the route object, it could be:
• Valid - there is a record for the prefix with the correct origin;
• Invalid - there is a record for the prefix, but origin differs from the advertised;
• Unknown - there’s no record for the prefix in IRR database.
• Prefix: Prefix that has been identified by Qrator Radar has having a change in its state (see here under what is monitored for each prefix); 
• Origin: Autonomous System the prefix as being originated from and as it was received by Radar;
• Route object: check that the prefix does have a valid Route Object recorded towards IRR (Internet Routing Registry);
• ROA: Radar check that there is a valid ROA (Route Origin Authorizations) for the prefix;
• Severity: 
• High if ROA status is Invalid;
• Medium if route object status is not Valid;
• Low if ROA status is Unknown;
• Info if both statuses are Valid.

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject: [BGP ALERT] [INFO] <AS197068> Change in Prefixes

10. Change in Relations

Notification Description:

• Change in relations: This event is pushed by the Qrator Radar system when an autonomous system, directly peered to your autonomous system, is changing its relationship with your network. There are 3 types of relationships:
• Customer - Provider (c2p) — in this case AS may announce its prefixes and prefixes that are received from customers;
• Provider - Customer (p2c) — in this case, AS may announce prefixes that are received from all neighbors. In other words, AS announces full routing table;
• Peer - Peer (p2p) — in this case, likewise in a c2p scenario, an AS may announce its prefixes and prefixes that are received from customers;
• Unspecified - Not enough data to determine relation type
• Relations Type: This field provides the type of relationship between ASN’s reported by Radar;
• Severity: Always set as Info.

Example email notification:

• From: Radar by Qrator <no-reply@qrator.net>
• Subject:
• [BGP ALERT] [INFO] <AS197068> Change in Customers
• [BGP ALERT] [INFO] <AS197068> Change in Peers
• [BGP ALERT] [INFO] <AS197068> Change in Providers
• [BGP ALERT] [INFO] <AS197068> Unspecified Relations

Qrator.Radar team could provide you with sample data after an individual submission request sent at radar@qrator.net.

As we operate, process and analyze data which could be sensitive or abused by people with bad intentions, we weigh in every request regarding sharing the data. It doesn’t mean that we would ultimately deny such an application - it’s that we have to know for sure for what purpose you are asking the data, how you want to further process and analyze that, and what would be the planned outcome or result published.

If you think we can help you with research of your own, while being mentioned as the data source - let’s start a discussion.

You have probably found this page because of an activity which could be described as suspicious, though let us first explain what is going on.

Qrator.Radar is the BGP monitoring and analytics tool, as well as the vulnerability scanner for known networks.

That means that when scanning your network, Qrator.Radar analyzes the presence of any known amplificators and the amplification (https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification) factor itself. This data is further processed to give ISP (or, more precisely, ASN) owners the possibility to analyze the availability of any of those services, which could be exploited by malfunctors for DDoS attacks organization.

It would be best if you were not afraid of those scans as they are not harmful in any way for your hardware or software; we collect the data only to notify the rightful owners of the network of when and what amplificators became available within the networks they manage. We provide authorization of the AS owners before showing this kind of information we consider sensitive.

The yearly data on amplificators count and the amplification factor is available via Qrator Labs Annual Reports: https://blog.qrator.net/en/reports/.

If you are looking for guidance with managing BGP or learning best practices collected by the networking community, we strongly advise you to take a look at the NLNOG’s guide to BGP filters: http://bgpfilterguide.nlnog.net/.