Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Infrastructure Security //

DNS

12/15/2017
09:05 AM
Larry Loeb
Larry Loeb
Larry Loeb
50%
50%

Russian DNS Gobbling Up Internet Traffic

BGPMON researchers have found that Russian DNS servers redirected Internet traffic through Russia several times earlier this month. The question is whether it's a test or a harbinger of things to come.

Two incidents that occurred over three hours on December 12 showed how vulnerable the Internet remains to misrouting.

Security firm BGPMON found that for the two incidents of three minutes each, traffic for 80 high-volume sites such as Facebook , Google (Nasdaq: GOOG), Microsoft Corp. (Nasdaq: MSFT) and Apple Inc. (Nasdaq: AAPL) were rerouted to Russia before being transmitted out. Researchers posted notice of this occurrence on their blog.

This unusual routing was done by rewriting the global Border Gateway Protocol (BGP) routing tables used by the Domain Name System (DNS) to push Internet traffic through itself. The BGP makes routing decisions based on paths, network policies or rule-sets that are configured by a network administrator, who is involved in making core routing decisions.

What happened was significant since it was picked up by a large number of other routing ISPs that connected to this rogue path, and several new more specific prefixes that are not normally seen on the Internet were generated by it.

High-volume prefixes were being broadcast; the kind that would attract high levels of traffic.

Now, the Origin Autonomous System (AS) 39523 (DV-LINK-AS) hasn't been seen announcing any prefixes for many years, except for one incident involving Google and Verizon that was also strange. The incident had traffic on its way to Verizon routed through Google, which can't handle it. There were some massive outages because of it.

BGPMON described the node's behavior at that time in this way:

In August Google learned a path to 66.232.224.0/24 (Kohls Department store) with origin 39523. Without knowing more about this prefixes, it looks strange and unexpected for Google to learn a 'Kohls Department store' Prefix via this path.

Now, this latest incident may have been some sort of test run. Considering the already announced plan by Russia to have its own "backup" DNS servers, this current effort could have been some sort of proof of concept that was run to see if the country could do it.

It did.

All of this shows that the connecting ISPs will have to accept that they can never totally trust the DNS routing tables they may get, but will have to add their own filters to the stream. Mistakes can happen due to Intent or from human error. The DNS system is based on trust, and that trust may be fraying.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3454
PUBLISHED: 2021-10-19
Truncated L2CAP K-frame causes assertion failure. Zephyr versions >= 2.4.0, >= v.2.50 contain Improper Handling of Length Parameter Inconsistency (CWE-130), Reachable Assertion (CWE-617). For more information, see https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-fx88-6c29-...
CVE-2021-3455
PUBLISHED: 2021-10-19
Disconnecting L2CAP channel right after invalid ATT request leads freeze. Zephyr versions >= 2.4.0, >= 2.5.0 contain Use After Free (CWE-416). For more information, see https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-7g38-3x9v-v7vp
CVE-2021-41150
PUBLISHED: 2021-10-19
Tough provides a set of Rust libraries and tools for using and generating the update framework (TUF) repositories. The tough library, prior to 0.12.0, does not properly sanitize delegated role names when caching a repository, or when loading a repository from the filesystem. When the repository is c...
CVE-2021-31378
PUBLISHED: 2021-10-19
In broadband environments, including but not limited to Enhanced Subscriber Management, (CHAP, PPP, DHCP, etc.), on Juniper Networks Junos OS devices where RADIUS servers are configured for managing subscriber access and a subscriber is logged in and then requests to logout, the subscriber may be fo...
CVE-2021-31379
PUBLISHED: 2021-10-19
An Incorrect Behavior Order vulnerability in the MAP-E automatic tunneling mechanism of Juniper Networks Junos OS allows an attacker to send certain malformed IPv4 or IPv6 packets to cause a Denial of Service (DoS) to the PFE on the device which is disabled as a result of the processing of these pac...