The fantastic Troopers 15 conference is in full swing… and I’m done with the presentations ;) The last talk I had during the conference focused on automating network security. The slides are already online; I’ll add the link to the recording when they upload the videos.
Pick a random headline related to security today and you’ll see lots of exclamation points and dire warnings about the insecurity of a something we thought was inviolate, such as Apple Pay or TLS. It’s enough to make you jump out of your skin and crawl into a dark hole somewhere never to use electricity again. Until you read the article, that is. After going through a couple of paragraphs, you realize that a click-bait headline about a new technology actually underscores an age-old problem: people are the weakest link.
We can engineer security for protocols and systems until the cows come home. We can use ciphers so complicated that even Deep Thought couldn’t figure them out. We can create a system so secure that it could never be hacked. But in the end that system needs to be used by people. And people are where everything breaks down.
Take the most recent Apple Pay “exploit” in the news that’s been making all the headlines. The problem has nothing to do with Apple Pay itself, or the way the device interacts with the point-of-sale terminal. It has everything to do with enterprising crooks calling in to Continue reading
Christoph Jaggi, the author of Metro Ethernet and Carrier Ethernet Encryption Market Overview published an awesome follow-up document: an evaluation guide that lists most of the gotchas one has to be aware of when considering encryption gear, from deployment scenarios, network overhead and key exchange details to operational considerations. If you have to deal with any aspect of network encryption, this document is a must-read.
On the heels of the BGP leak yesterday that briefly impaired Google services around the world, comes another routing incident that impacted some other important Internet services.
Beginning on Saturday, Ukrainian telecom provider, Vega, began announcing 14 British Telecom (BT) routes, resulting in the redirection of Internet traffic through Ukraine for a handful of British Telecom customers. Early yesterday morning, Vega announced another 167 BT prefixes for 1.5 hours resulting in the rerouting of additional traffic destined for some of BT’s customers, including the UK’s Atomic Weapons Establishment, the “organization responsible for the design, manufacture and support of warheads for the United Kingdom’s nuclear deterrent.”
Background
In early 2013, Ukrainian provider Vega (AS12883) became a reseller of BT services, but prior to Saturday had never announced any BT routes. Then, in the middle of a weekend night in Europe (02:37 UTC on Saturday, March 7th), Vega began announcing 14 prefixes typically announced by AS2856 of BT. These prefixes are listed below.
109.234.168.0/21 Thales Transport and Security Ltd (Barnet, GB)
109.234.169.0/24 Thales Transport and Security Ltd (Ealing, GB)
144.87.142.0/24 Royal Mail Group Limited (Sheffield, GB)
144.87.143.0/24 Royal Mail Group Limited (Chesterfield, GB)
147.182.214.0/24 Black & Veatch (Manchester, GB)
193.113.245.0/24 BT - 21CN (GB)
193.221.55.0/24 Svenska Cellulosa Aktiebolaget SCA (GB)
193. Continue reading
I don’t believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it’s all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.
A “role” in IOS is called a “view” and since views control which commands are available in the command line parser, they are configured under the parser. A view can be assigned a password which allows users to “enable” into the view. More typically, the view is assigned by the RADIUS/TACACS server as part of the authorization process when a user is logging into the device.
A view is configured with the “parser view <view-name>” config command after which commands are added/removed to/from Continue reading
This morning, users of Google around the world were unable to access many of the company’s services due to a routing leak in India. Beginning at 08:58 UTC Indian broadband provider Hathway (AS17488) incorrectly announced over 300 Google prefixes to its Indian transit provider Bharti Airtel (AS9498).
Bharti in turn announced these routes to the rest of the world, and a number of ISPs accepted these routes including US carriers Cogent (AS174), Level 3 (AS3549) as well as overseas incumbent carriers Orange (France Telecom, AS5511), Singapore Telecom (Singtel, AS7473) and Pakistan Telecom (PTCL, AS17557). Like many providers around the world, Hathway peers with Google so that their customers have more direct connectivity with Google services. But when that private relationship enters the public Internet the result can be accidental global traffic redirection.
Last fall, I wrote two blog posts here and here about the issues surrounding routing leaks such this one. Routing leaks happen regularly and can have the effect of misdirecting global traffic. Last month, I gave a talk in the NANOG 63 Peering Forum entitled “Hidden Risks of Peering” that went over some examples of routing leaks like this one.
Below is a graph showing the Continue reading
I've always said that its pointless investing in strong IT security because it will drag down profits and productivity which impacts your stock price in the current quarter. Be prepared for the media campaign that reacts to a security breach and make the most of the media coverage for promotion, exposure and business growth.
The post Being Hacked Is Good For Business! or Why You Need To Security Detection not Security Prevention appeared first on EtherealMind.
While working with firewalls for the last few years, I’ve seen many logs polluted with scanning traffic. Obviously this is the type of thing that I want to see when someone is legitimately scanning, or attempting to scan, through the firewall. However, there are a few cases that seeing this traffic is simply an indication of some other issue in the network.
An example I have seen on several occasions is someone configuring a network management station to discover 192.168.0.0/16, 172.16.0.0/12 or 10.0.0.0/8. If not properly handled in the routed network architecture, the associated traffic could make its way to the firewall or even to the ISP. An ASA might block the traffic due to policy, reroute it back toward the internal network, drop it due to the intra-interface hairpin configuration, or forward it onward. In most cases, this traffic will cause a lot of “noise” in the syslogs produced by the firewall.
To fully understand the problem, the diagram below can be used for discussion–
In this example, R1 has a static default route that points to the IP address of FW1. R1 advertises this via EIGRP to its internal neighbors. If a networked host attempts to reach Continue reading
procdump -ma VisualDiscovery.exe super.dmp