Irfan Salam

Latest ICT news, Technology Reviews and Tutorials

Category Archives: ICT News

New Consolidation CCNA Announced – Starting Feb 24, 2020

In a surprise move Cisco has discontinued all CCNA concentrations and announced new consolidated CCNA exam starting Feb 24, 2020.

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:

  • Network fundamentals
  • Network access
  • IP connectivity
  • IP services
  • Security fundamentals
  • Automation and programmability
Required exam Recommended training
200-301 CCNA Implementing and Administering Cisco Solutions (CCNA)

Detailed Topics of new CCNA Program:

1.0 Network Fundamentals


Hide Details

1.1 Explain the role and function of network components

  • 1.1.a Routers
  • 1.1.b L2 and L3 switches
  • 1.1.c Next-generation firewalls and IPS
  • 1.1.d Access points
  • 1.1.e Controllers (Cisco DNA Center and WLC)
  • 1.1.f Endpoints
  • 1.1.g Servers

1.2 Describe characteristics of network topology architectures

  • 1.2.a 2 tier
  • 1.2.b 3 tier
  • 1.2.c Spine-leaf
  • 1.2.d WAN
  • 1.2.e Small office/home office (SOHO)
  • 1.2.f On-premises and cloud

1.3 Compare physical interface and cabling types

  • 1.3.a Single-mode fiber, multimode fiber, copper
  • 1.3.b Connections (Ethernet shared media and point-to-point)
  • 1.3.c Concepts of PoE

1.4 Identify interface and cable issues (collisions, errors, mismatch duplex, and/or speed)

1.5 Compare TCP to UDP

1.6 Configure and verify IPv4 addressing and subnetting

1.7 Describe the need for private IPv4 addressing

1.8 Configure and verify IPv6 addressing and prefix

1.9 Compare IPv6 address types

  • 1.9.a Global unicast
  • 1.9.b Unique local
  • 1.9.c Link local
  • 1.9.d Anycast
  • 1.9.e Multicast
  • 1.9.f Modified EUI 64

1.10 Verify IP parameters for Client OS (Windows, Mac OS, Linux)

1.11 Describe wireless principles

  • 1.11.a Nonoverlapping Wi-Fi channels
  • 1.11.b SSID
  • 1.11.c RF
  • 1.11.d Encryption

1.12 Explain virtualization fundamentals (virtual machines)

1.13 Describe switching concepts

  • 1.13.a MAC learning and aging
  • 1.13.b Frame switching
  • 1.13.c Frame flooding
  • 1.13.d MAC address table

2.0 Network Access


Hide Details

2.1 Configure and verify VLANs (normal range) spanning multiple switches

  • 2.1.a Access ports (data and voice)
  • 2.1.b Default VLAN
  • 2.1.c Connectivity

2.2 Configure and verify interswitch connectivity

  • 2.2.a Trunk ports
  • 2.2.b 802.1Q
  • 2.2.c Native VLAN

2.3 Configure and verify Layer 2 discovery protocols (Cisco Discovery Protocol and LLDP)

2.4 Configure and verify (Layer 2/Layer 3) EtherChannel (LACP)

2.5 Describe the need for and basic operations of Rapid PVST+ Spanning Tree Protocol and identify basic operations

  • 2.5.a Root port, root bridge (primary/secondary), and other port names
  • 2.5.b Port states (forwarding/blocking)
  • 2.5.c PortFast benefits

2.6 Compare Cisco Wireless Architectures and AP modes

2.7 Describe physical infrastructure connections of WLAN components (AP,WLC, access/trunk ports, and LAG)

2.8 Describe AP and WLC management access connections (Telnet, SSH, HTTP,HTTPS, console, and TACACS+/RADIUS)

2.9 Configure the components of a wireless LAN access for client   connectivity using GUI only such as WLAN creation, security settings, QoS profiles, and advanced WLAN settings

3.0 IP Connectivity


Hide Details

3.1 Interpret the components of routing table

  • 3.1.a Routing protocol code
  • 3.1.b Prefix
  • 3.1.c Network mask
  • 3.1.d Next hop
  • 3.1.e Administrative distance
  • 3.1.f Metric
  • 3.1.g Gateway of last resort

3.2 Determine how a router makes a forwarding decision by default

  • 3.2.a Longest match
  • 3.2.b Administrative distance
  • 3.2.c Routing protocol metric

3.3 Configure and verify IPv4 and IPv6 static routing

  • 3.3.a Default route
  • 3.3.b Network route
  • 3.3.c Host route
  • 3.3.d Floating static

3.4 Configure and verify single area OSPFv2

  • 3.4.a Neighbor adjacencies
  • 3.4.b Point-to-point
  • 3.4.c Broadcast (DR/BDR selection)
  • 3.4.d Router ID

3.5 Describe the purpose of first hop redundancy protocol

4.0 IP Services


Hide Details

4.1 Configure and verify inside source NAT using static and pools

4.2 Configure and verify NTP operating in a client and server mode

4.3 Explain the role of DHCP and DNS within the network

4.4 Explain the function of SNMP in network operations

4.5 Describe the use of syslog features including facilities and levels

4.6 Configure and verify DHCP client and relay

4.7 Explain the forwarding per-hop behavior (PHB) for QoS such as classification, marking, queuing, congestion, policing, shaping

4.8 Configure network devices for remote access using SSH

4.9 Describe the capabilities and function of TFTP/FTP in the network

5.0 Security Fundamentals


Hide Details

5.1 Define key security concepts (threats, vulnerabilities, exploits, and mitigation techniques)

5.2 Describe security program elements (user awareness, training, and physical access control)

5.3 Configure device access control using local passwords

5.4 Describe security password policies elements, such as management, complexity, and password alternatives (multifactor authentication, certificates, and biometrics)

5.5 Describe remote access and site-to-site VPNs

5.6 Configure and verify access control lists

5.7 Configure Layer 2 security features (DHCP snooping, dynamic ARP inspection, and port security)

5.8 Differentiate authentication, authorization, and accounting concepts

5.9 Describe wireless security protocols (WPA, WPA2, and WPA3)

5.10 Configure WLAN using WPA2 PSK using the GUI

6.0 Automation and Programmability


Hide Details

6.1 Explain how automation impacts network management

6.2 Compare traditional networks with controller-based networking

6.3 Describe controller-based and software defined architectures (overlay, underlay, and fabric)

  • 6.3.a Separation of control plane and data plane
  • 6.3.b North-bound and south-bound APIs

6.4 Compare traditional campus device management with Cisco DNA Center enabled device management

6.5 Describe characteristics of REST-based APIs (CRUD, HTTP verbs, and data encoding)

6.6 Recognize the capabilities of configuration management mechanisms Puppet, Chef, and Ansible

6.7 Interpret JSON encoded data

Source: Cisco Certifications and Trainings Page

Click to access ccna-at-a-glance.pdf



DNS reflection defense – The Akamai Blog:

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.

How DNS 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, which is one of the authoritative name servers for the 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.

DNS reflection

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.

Eliminating DNS reflection attacks

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.

The open resolvers

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.

DNS server protection

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.

Response handling

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.

Rate Limiting

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.


Cisco Small Cell Solution

Indoor Cells for seamless 3G/4G coverage

Reverse Heartbleed – Protect Vulnerable Mobile Clients

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.


Gartnet Report on Enterprise Network Firewalls – Q1-2014

Level 3, du introduce ME fibre broadcast solution


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.

Dropbox Hits 200M Users, Unveils New “For Business” Client Combining Work And Personal Files

Thinner, lighter, FASTER: Early benchmarks show 50-65% improvement in MacBook Pro’s Iris graphics

Hackers use DDoS to mask bank thefts

Cybercriminals have used low-level DDoS attacks to distract the security response teams of the targeted banks, allowing them to steal millions from a number of accounts via wire payment, according to Avivah Litan, Vice President and Distinguished Analyst, Gartner.
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.


SDN, NFV creeping into provider networks


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.

%d bloggers like this: