TaoSecurity Blog

I was looking for resources on campus network design and found these slides  (pdf) from a 2011 Network Startup Resource Center presentation. These two caught my attention: This bothered me, so I Tweeted about it. This started some discussion, and prompted me to see what NSRC suggests for architecture these days. You can find the latest, from April 2018, here . Here is the bottom line for their suggested architecture: What do you think of this architecture? My Tweet has attracted some attention from the high speed network researcher community, some of whom assume I must be a junior security apprentice who equates "firewall" with "security." Long-time blog readers will laugh at that, like I did. So what was my problem with the original recommendation, and what problems do I have (if any) with the 2018 version? First, let's be clear that I have always differentiated between  visibility and control . A firewall is a poor visibility too...

Last week the Christian Science Monitor published a story titled  How North Korea built up a cadre of code warriors prepared for cyberwar . It contained the following section: North Korea is faced with tremendous limitations. All of its Internet connections go through servers in China, for example. But it soon may find other ways to connect to the outside world. North Korean leader Kim Jong-Un is expected to meet with Russian President Vladimir Putin later this year in a bid to, among other things, begin running networks through Russia, too. This caught my attention. Years ago I bought a giant map of Asia for my office at Mandiant. I was fascinated by the small part of the world where Russia and North Korea share a border, shown below. If you zoom into that area, you see the following. China, Russia, and North Korea share a common border near the Russian town of Khasan . From that location, Russia and North Korea share a border dividing the Tumen River, approximately...

If you've read TaoSecurity Blog for a while, you remember me being a fan of companies like Renesys (now part of Dyn Research ) and BGPmon . These organizations monitor Internet-wide routing by scrutinizing BGP announcements, plus other techniques. (I first posted on the topic almost 12 years ago.) I am well aware that an organization, from its own Internet viewpoint , cannot be absolutely sure that the other end of a conversation truly represents the IP address that it seems to be. The counterparty may be suffering a BPG hijack. An attacker may have temporarily positioned itself in BGP routing tables such that the legitimate IP address owner is not the preferred route. There have been many examples of this, and on Thursday Dyn Research posted a great new blog titled The Vast World of Fraudulent Routing that describes six recent examples. A Tweet by Space Rogue about Dyn's post caught my attention. He said: You really want to tell me that an IP Address is enough fo...

I've been writing about the routing infrastructure monitoring company Renesys for several years. James Cowie's post Staring Into the Gorge contains some real gems: Here We Go Again. Imagine an innocent BGP message, sent from a random small network service provider's border router somewhere in the world. It contains a payload that is unusual, but strictly speaking, conformant to protocol. Most of the routers in the world, when faced with such a message, pass it along. But a few have a bug that makes them drop sessions abruptly and reopen them, flooding their neighbors with full-table session resets every time they hear the offending message. The miracle of global BGP ensures that every vulnerable router on earth gets a peek at the offending message in under 30 seconds. The global routing infrastructure rings like a bell, as BGP update rates spike by orders of magnitude in the blink of an eye. Links congest. Small routing hardware falls over and dies. It takes hours for t...

This is a follow-up to Black Hat DC 2009 Wrap-Up, Day 1 . I started day two with Dan Kaminsky. I really enjoyed his talk. I am not sure how much of it was presented last year, since I missed his presentation in Las Vegas. However, I found his comparison of DNS vs SSL infrastructures illuminating. The root name servers are stable, dependable, centrally coordinated, and guaranteed to be around in ten years. We know what root name servers to trust, and we can add new hosts to our domains without requesting permission from a central authority. Contrast that with certificate authorities. They have problems, cannot all be trusted, and come and go as their owning companies change. We do not always know what CAs to trust, but we must continuously consult them whenever we change infrastructure. Dan asked "are we blaming business people when really our engineering is poor?" I thought that was a really interesting question. Imagine that instead of being a security engineer, yo...

In November I posted BGPMon on BGP Table Leak by Companhia de Telecomunicacoes do Brasil Central . A lot of people saw that activity but the overall effect was negligible to nonexistent. Yesterday I received a more personalized alert from BGPMon: You Receive this email because you are subscribed to BGPmon.net. For more details about these updates please visit: http://bgpmon.net/showupdates.php ==================== WithDraw of More Specific (Code: 23) 2 number of peer(s) detected this updates for your prefix 3.0.0.0/8: Update details: 2009-01-01 08:33 (UTC) 3.3.3.3/32 ==================== Possible Prefix Hijack (Code: 11) 2 number of peer(s) detected this updates for your prefix 3.0.0.0/8: Update details: 2009-01-01 08:31 (UTC) 3.3.3.3/32 Announced by: AS15475 (NOL) Transit AS: 8452 (TEDATA TEDATA) ASpath: 29073 9009 19151 4788 8452 15475 Checking WHOIS data for AS15475 shows: % Information related to 'AS15475' aut-num: AS15475 as-name: NOL descr: Nile O...

Last month I posted BGPMon.net Watches BGP Announcements for Free . I said: I created an account at BGPMon.net and decided to watch for route advertisements for Autonomous System (AS) 80, which corresponds to the 3.0.0.0/8 network my company operates. The idea is that if anyone decides to advertise more specific routes for portions of that net block, and the data provided to BGPMon.net by the Réseaux IP Européens (RIPE) Routing Information Service (RIS) notices the advertisements, I will get an email. Well, that started happening last night: You Receive this email because you are subscribed to BGPmon.net. For more details about these updates please visit: http://bgpmon.net/showupdates.php ==================== Possible Prefix Hijack (Code: 11) 1 number of peer(s) detected this updates for your prefix 3.0.0.0/8: Update details: 2008-11-11 01:55 (UTC) 3.0.0.0/8 Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central) Transit AS: 27664 (CTBC Multimídia) ASpath: 27664 16735 ...

Thanks to Jeremy Stretch's blog for pointing me to BGPMon.net , a free route monitoring service. This looks like a bare bones, free alternative to Renesys , my favorite commercial vendor in this space. I created an account at BGPMon.net and decided to watch for route advertisements for Autonomous System (AS) 80 , which corresponds to the 3.0.0.0/8 network my company operates. The idea is that if anyone decides to advertise more specific routes for portions of that net block, and the data provided to BGPMon.net by the Réseaux IP Européens (RIPE) Routing Information Service (RIS) notices the advertisements, I will get an email. I noticed that RIPE RIS provides dashboards for the 3.0.0.0/8 prefix or AS 80 with interesting data.

When I attended the FIRST 2008 conference in Vancouver, BC in June, one of my favorite talks was Threats to Internet Routing and Global Connectivity by Earl Zmijewski from Renesys . I've always liked learning about the Big Internet, where 250,000+ routes are exchanged over BGP and 45,000 updates per minute is considered a "quiet" load! I was This was the first time I heard of Pretty Good BGP , summarized by the subtitle of the linked .pdf paper: Improving BGP by Cautiously Adopting Routes.

The reason so many security researchers can run their l33t 0-day attacks on Web appz is that they (usually) don't have to worry about the underlying network layers failing them. I've always been more interested in network plumbing, particularly at the WAN and backbone levels. If you sympathize, you must read the Renesys Blog . Posts like Pakistan Hijacks YouTube and Iran Is Not Disconnected are primers on how the Internet works. Those guys rock.

I was quoted in the Manchester Union Leader regarding Renesys , a company that monitors global routing tables. I heard of them a few years ago and posted research they did on the northeast blackout of 2003.

One of the cooler sections in Extreme Exploits covers ways to learn about a target network by looking at routes to those networks. I showed a few ways to use this data two years ago , but here's a more recent example. Let's say I want to find out more about the organization hosting the Extreme Exploits Web site. First I resolve the hostname to an IP address. host www.extremeexploits.com www.extremeexploits.com has address 69.16.147.21 Now I use whois to locate the owner's netblock. whois 69.16.147.21 Puregig, Inc. PUREGIG1 (NET-69-16-128-0-1) 69.16.128.0 - 69.16.191.255 VOSTROM Holdings, Inc. PUREGIG1-VOSTROM1 (NET-69-16-147-0-1) 69.16.147.0 - 69.16.147.255 # ARIN WHOIS database, last updated 2005-08-14 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. Now I telnet to a route server and make queries about this netblock. route-server.phx1>sh ip bgp 69.16.147.0 BGP routing t...

Slashdot alerted me to an online report on the effects of the northeast blackout on individual routers. Renesys monitored BGP announcements and watched routers drop out of the tables, as shown in their graph below. From the report: "The majority of the power failures began at about 16:10 EDT. Immediately thereafter, the number of routes in global routing tables dropped rapidly, falling by nearly 1000 within five minutes. This likely corresponded to the loss of reachability of networks which did not have alternative backup power sources. Table size then continued to drop, though at a slightly more gradual pace. We suspect that losses during this time correspond to networks with limited backup power which were able to stay online temporarily until those power supplies were exhausted. By 19:00 EDT, routing table sizes had reached their low point, a full 2500 networks fewer than the current baseline size."