Contact us

AS Relations

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.

Radar Monitor

1. What is Route Leak?

Route Leak is an illegitimate redirection of traffic in case of either an error in BGP routing configuration or hacker activity (MIT attack). This network anomaly is often hard to detect on the victim AS’s side as the only evidence for end-users is the increase of latency on certain directions. Radar is able to detect this type of anomalies by analyzing AS_Path attribute with the help of its own inter-AS relations model. The data about these anomalies is updated daily.

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

3. What is a Default route error?

Default route configuration error is another common source of the route loops. They appear when a border router in some autonomous system has wrong default route configuration.

4. 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. 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».


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

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

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.

7. 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 request OID.

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.

8. 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: \r\n
Man: "ssdp:discover" \r\n
MX: 3 \r\n
ST: ssdp:all \r\n

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

9. How can I check NETBIOS amplifiers presence?

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

nmblookup -A $ip

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

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

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

11. How can I check PORTMAP amplifiers presence?

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

rpcinfo -T udp $ip

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.

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

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

Radar Reverse LG

1. How does Reverse LG work?

Radar uses its own inter-As relations and priority model for building the reverse path. For each AS possibly present in the reverse path, its BGP decision is modeled according to the given routing policies of your AS.

2. Why do I need to launch BGP session with Full View in order to gain access to Reverse LG?

In order to provide correct representation of the reverse we need to detect in our model the all peerings accessible by your AS. The simplest way for that is establishing the BGP multihop session.

Contact us

Thank you for feedback!

We will contact you by provided email address.