Latest ICT news, Technology Reviews and Tutorials
The new CCNA program is designed to prepare you for today’s associate-level job roles in IT technologies. CCNA now includes security and automation and programmability. The program has one certification that covers a broad range of fundamentals for IT careers, with one exam and one training course to help you prepare.
Newly retooled for the latest technologies and job roles, the CCNA training course and exam give you the foundation you need to take your career in any direction. CCNA certification covers a breadth of topics, including:
| Required exam | Recommended training |
|---|---|
| 200-301 CCNA | Implementing and Administering Cisco Solutions (CCNA) |
Detailed Topics of new CCNA Program:
Source: Cisco Certifications and Trainings Page
Click to access ccna-at-a-glance.pdf
DNS reflection defense – The Akamai Blog:.
Recently, DDoS attacks have spiked up well past 100 Gbps several times. A common move used by adversaries is the DNS reflection attack, a category of Distributed, Reflected Denial of Service (DRDos) attack. To understand how to defend against it, it helps to understand how it works.
At the heart of the Domain Name System are two categories of name server: the authoritative name server, which is responsible for providing authoritative answers to specific queries (like use5.akam.net, which is one of the authoritative name servers for the csoandy.com domain), and the recursive name server, which is responsible for answering any question asked by a client. Recursive name servers (located in ISPs, corporations, and data centers around the world) query the appropriate authoritative name servers around the Internet, and return an answer to the querying client. An open resolver is a category of resolver that will answer recursive queries from any client, not just those local to them. Because DNS requests are fairly small and lightweight, DNS primarily uses the Universal Datagram Protocol (UDP), a stateless messaging system. Since UDP requests can be sent in a single packet, the source address are easily forgeable with any address desired by the true sender.
A DNS reflection attack takes advantage of three things: the forgeability of UDP source addresses, the availability of open resolvers, and the asymmetry of DNS requests and responses. To conduct an attack, an adversary sends a set of DNS queries to open resolvers, altering the source address on their requests to be those of their chosen target. The requests are designed to have much larger responses (often, using an ANY request, a 64 byte request yields a 512-byte response), thus resulting in the recursive name servers sending about 8 times as much traffic at the target as they themselves received. A DNS reflection attack can directly use authoritative name servers, but it requires more preparation and research, making requests specific to the scope of each DNS authority used.
An ideal solution would obviously be to eliminate this type of attack, rather than every target needing to defend themselves. Unfortunately, that’s challenging, as it requires significant changes by infrastructure providers across the Internet.
No discussion of defending against DRDoS style attacks is complete without a nod to BCP38. These attacks only work because an adversary, when sending forged packets, has no routers upstream filtering based on the source address. There is rare need to permit an ISP user to send packets claiming to originate in another ISP; if BCP38 were adopted and implemented in a widespread fashion, DRDoS would be eliminated as an adversarial capability. That’s sadly unlikely, as BCP38 enters its 14th year; the complexity and edge cases are significant.
While a few enterprises have made providing an open resolver into a business (OpenDNS, GoogleDNS), many open resolvers are either historical accidents, or resulting from incorrect configuration. Even MIT has turned off open recursion on its high-profile name servers.
Barring that, recursive name servers should implement rate limiting, especially on infrequent request types, to reduce the multiplication of traffic that adversaries can gain out of them.
Until ISPs and resolver operators implement controls to limit how large attacks can become, attack targets must defend themselves. Sometimes, attacks are targeted at infrastructure (like routers and name servers), but most often they are being targeted at high-profile websites operated by financial services firms, government agencies, retail companies, or whoever has caught the eye of the attacker this week.
An operator of a high-profile web property can take steps to defend their front door. The first step, of course, should be to find their front door; and to understand what infrastructure it relies on. And then they can evaluate their defenses.
The first line of defense is always capacity. Without enough bandwidth at the front of your defenses, nothing else matters. This needs to be measurable both in raw bandwidth, as well as in packets per second, because hardware often has much lower bandwidth capacity as packet sizes shrink. Unfortunately, robust capacity is now measurable in the 300+ gigabits per second, well beyond the resources of the average datacenter. However, attacks in the 3-10 gigabit per second range are still common, and well within the range of existing datacenter defenses.
For systems that aren’t DNS servers themselves, filtering out DNS traffic as far upstream as possible is a good solution, but certainly at a border firewall. One caveat – web servers often need to make DNS queries themselves, so ensure that they have a path to do so. In general, the principal of “filter out the unexpected” is a good filtering strategy.
Since DNS servers have to process incoming requests (an authoritative name server has to respond to all of the recursive resolvers around the Internet, for instance), merely filtering DNS traffic upstream isn’t an option. So what is perceived as a network problem by non-DNS servers becomes an application problem for the DNS server. Defenses may no longer be simple “block this” strategies; rather, defense can take advantage of application tools to provide different defenses.
While the total number of authoritative DNS server IP addresses for a given domain is limited (while 13 should fit into the 512-byte DNS response packet, generally, 8 is a reasonable number), many systems use nowhere near the limit. Servers should be diversified, located in multiple networks and geographies, ensuring that attacks against two name servers aren’t traveling across the same links.
Since requests come in via UDP, anycasting (the practice of having servers responding on the same IP address from multiple locations on the internet) is quite practical. Done at small scale (two to five locations), this can provide significant increases in capacity, as well as resilience to localized physical outages. However, DNS also lends itself to architectures with hundreds of name server locations sprinkled throughout the internet, each localized to only provide service to a small region of the Internet (possibly even to a single network). Adversaries outside these localities have no ability to target the sprinkled name servers, which continue to provide high quality support to nearby end users.
Based on Akamai’s experience running popular authoritative name servers, 95% of all DNS traffic originates from under a million popular name server IP addresses (to get 99% requires just under 2 million IP addresses). Given that the total IPv4 address space is around 4.3 billion IP addresses, name servers can be segregated; a smaller number to handle the “unpopular” name servers, and a larger amount to handle the popular name servers. Attacks that reflect of unpopular open resolvers thus don’t consume the application resources providing quality of service to the popular name service.
Authoritative name servers should primarily see requests, not responses. Therefore, they should be able to isolate, process, and discard response packets quickly, minimizing impact to resources engaged in replying to requests. This isolation can also apply to less frequent types of request, such that when a server is under attack, it can devote resources to requests that are more likely to provide value.
Traffic from any name server should be monitored to see if it exceeds reasonable thresholds, and, if so, aggressively managed. If a name server typically sends a few requests per minute, having name servers not answer most requests from a name servers requesting dozens of time per second (these thresholds can and should be dynamic). This works because of the built in fault tolerance of DNS; if a requesting name server doesn’t see a quick response, it will send another request, often to a different authoritative name server (and deprioritizing the failed name server for future requests).
As attacks grow past the current few hundred gigabit-per-second up to terabit-per-second attacks, robust architectures will be increasingly necessary to maintains a presence on the Internet in the face of adversarial action.
There’s no question that the Heartbleed vulnerability introduced a major vector of risk to companies around the world. Given that an attacker could exploit Internet-facing servers and access privileged information, it is clear why these measures were necessary.
However, with the widespread coverage focusing on the exploitation of web sites, one might be misled into thinking that Heartbleed is solely a server security problem. It’s not. OpenSSL is widely used in a variety of products, and it’s not limited to web servers. In fact, it’s also used as the cryptographic library for clients connecting to a web server, which introduces another set of security issues. Clients that are using affected versions of OpenSSL are vulnerable to reverse-Heartbleed, which reveals the contents of memory on the client rather than the server.
In this scenario, the attacker would set up a malicious web server that would be used to send the exploit against the Heartbleed vulnerability to the client, rather than the other way around. Security teams need to think about a different set of problems, namely how to intercept the exploit while patching applications and operating systems on endpoints and mobile devices.
The attack surface is quite large with these conditions, because OpenSSL is used fairly extensively in many different types of products. With respect to mobile devices, the good news is that Heartbleed does not affect iOS itself, and does not affect the majority of Android versions. The bad news, however, is that Android 4.1.1 is vulnerable, and depending on which set of statistics that you look at, it could affect anywhere from 10% to 34% of Android mobile devices in use today.
Endpoints and mobile devices are considerably different in terms of rolling out patches and updates. Managed endpoints typically have updates pushed out through system management software, and even unmanaged endpoints often receive updates by the software publisher to protect the public at large. However, mobile devices are not updated as frequently and there are questions about whether some of the affected devices will ever be patched, because the device manufacturer is typically responsible for pushing out the patch, and may not be actively doing so.
Heartbleed exposes a set of mobile device security challenges that many organizations had not previously considered: How do you safely provide access to applications using mobile devices that may not be (and may never be) patched?
Determine Platform Use
One of the biggest problems that companies face right now is that they have no idea what types of devices are being used, especially in light of BYOD. Are people using older operating systems that are vulnerable? Being able to firmly establish which devices are being used with company applications, and the ability to exclude ones that are not properly secure, is the first step to dealing with the problem of platform fragmentation and the availability of patches.
Manage Mobile Devices
Managing the mobile device is a critical step for protecting it and understanding what applications are in use. Gauging the use of applications is necessary in order to take the proper steps to secure the traffic from potential threats.
Protect Users with Threat Prevention
Palo Alto Networks next-generation security platform identifies exploits, harmful websites, malware and mobile exploits. GlobalProtect can be used to automatically establish a tunnel to the next-generation security platform and keep users behind a gateway for threat prevention.
Use Device Criteria for Policy
Organizations may want to classify specific mobile devices for use in their organization. For example, if the company decides to phase out the use of older operating systems, the organization might establish policies that govern which platforms can be used with corporate applications.
Source: http://www.commsmea.com/14182-level-3-du-introduce-me-fibre-broadcast-solution/#.UysCtc6pcm0
Dubai-based telecoms operator du and US-based carrier Level 3 Communications today introduced the expansion of Level 3’s Vyvx Solutions in the UAE market.
“This marks a welcome addition for international broadcasters to better meet viewers’ demand for high-quality content, such as major sporting events,” du said in a statement.
In delivering the service, Level 3 established a Point of Presence (PoP) at datamena, du’s UAE-based carrier-neutral data centre and connectivity platform that serves the MEA region.
The Level 3 suite of Vyvx services is intended to complement du’s existing broadcast services with global fibre-based video transport services, designed to meet expanding bandwidth needs. As a result, du hopes to provide broadcast network customers with on-net access from the local node to Level 3’s global network footprint.
Du and Level 3 have a joint presence at this year’s Cabsat, the Dubai World Trade Centre (DWTC)-hosted conference focusing on professional content management in the Middle East.
“These are exciting times – the UAE is well-known for hosting major sporting events and concerts as well as some of the world’s newest production studios which focus the world’s attention on the country”, said Martin Ford, senior vice president, Sales, Europe Middle East and Africa, Level 3 Communications.
“Our first Vyvx PoP in the Middle East will enable regional broadcasters and content producers to send and receive their content globally over Level 3’s secure, reliable and high-speed media network.”
“Level 3’s growing broadcast infrastructure and network scalability is helping us expand our business,” said Mahesh Jaishankar, vice president, datamena and Broadcast, du.
“As a leading provider of media broadcast solutions in the UAE, we service the major broadcasters. The introduction of Vyvx will play a critical role in delivering our customers the international reach they need, and to meet expectations of viewers for high quality content.”
Compared to traditional satellite services, fibre cables are considered less prone to interference, while also offering greater bandwidth capacity at a price point that has become more accessible. The Level 3 Vyvx service will use the new local PoP, as well as subsea cables reaching the UAE.
The attacks, which took place over the past few months, appeared to use high levels of access to the bank’s systems, to allow them to control the wire payment switch of each bank, which controls all of the bank’s wire transfer activities. This allowed the hackers to make multiple transfers from as many accounts as they liked, compared to a usual wire transfer attack, which would typically use a stolen login and card number to steal money from one account at a time.
It is not clear how the attackers gained control of the wire payment switch, but it is suspected that complex, persistent phishing attacks against bank staff were used to gain high level access.
Litan told SC Magazine that the attacks were different to recent ‘hacktivist’ sponsored DDoS attacks that aimed to completely take down the bank’s websites, but appeared to be used to divert attention and provide cover for the unauthorised transfers to take place.
“It wasn’t the politically motivated groups,” she said. “It was a stealth, low-powered DDoS attack, meaning it wasn’t something that knocked their website down for hours.
“Considerable financial damage has resulted from these attacks. One rule that banks should institute is to slow down the money transfer system while under a DDoS attack. More generally, a layered fraud prevention and security approach is warranted,” she added.
DDoS attacks had already been seen in co-ordination with unauthorised transfer attacks on banks, as reported by Dell SecureWorks in April. Researchers noted that a $200 crimeware kit, called Dirt Jumper, was used to create a botnet to launch DDoS attacks of short duration, generally after an unauthorised transfer had taken place.
Source: http://www.itp.net/594617-hackers-use-ddos-to-mask-bank-thefts#.UjWOIT-TOkw
source: http://www.networkworld.com/community/node/83381
Network operators are starting small with their SDN and Network Functions Virtualization (NFV) deployments, containing them to parts of the network where they can evaluate performance before rolling it out, according to Infonetics Research. The market research firm recently surveyed global service providers, representing 53% of worldwide telecom capital spending, to determine the timing and priority of SDN and NFV implementations.
Infonetics found that most are isolating SDN and NFV projects to “contained domains” of their networks to kick the tires before widespread deployment. Despite the cautious testbeds, momentum for SDN and NFV is strong, Infonetics reports, as the majority of operators participating in the survey plan to deploy the technologies in the core, aggregation and customer access tiers of their networks.
But that might take a while. Infonetics believes it will still be “many years” before SDN controls larger operator domains or a whole service provider network.
Interest in SDN and NFV is being driven by demands for operational efficiency and quicker turn up of revenue generating services. Study participants rated content delivery networks (CDNs), IP multimedia subsystems, and virtual routers/security gateways as the top applications for NFV, Infonetics found.
The top 5 network domains targeted by operators are: within data centers; between data centers; operations and management; CDNs; and cloud services. Eighty-six percent of surveyed operators also plan to deploy SDN and NFV technology in their optical transport networks as well, once standards are finalized, Infonetics found.
Irfan Salam 