• Best VPN Service

    Top VPNs that Unlock Netflix, provide Secure Torrenting, Strong Encryption, Fast Downloads, DNS Leak Protection, Identity Protection and have Cheap VPN prices.

    read more

    Hyper-V Concepts

    It's time to get familiar with Hyper-V Virtualization, virtual servers, virtual switches, virtual CPUs, virtual deployment infrastructure (VDI) and more.
    Read more

Hot Downloads

How to Perform TCP SYN Flood DoS Attack & Detect it with Wireshark - Kali Linux hping3

Posted in Network Protocol Analyzers

How to Perform TCP SYN Flood DoS Attack & Detect it with Wireshark - Kali Linux hping3 - 4.3 out of 5 based on 6 votes

wireshark logoThis article will help you understand TCP SYN Flood Attacks, show how to perform a SYN Flood Attack (DoS attack) using Kali Linux & hping3 and correctly identify one using the Wireshark protocol analyser. We’ve included all necessary screenshots and easy to follow instructions that will ensure an enjoyable learning experience for both beginners and advanced IT professionals.

DoS attacks are simple to carry out, can cause serious downtime, and aren’t always obvious. In a SYN flood attack, a malicious party exploits the TCP protocol 3-way handshake to quickly cause service and network disruptions, ultimately leading to an Denial of Service (DoS) Attack. These type of attacks can easily take admins by surprise and can become challenging to identify. Luckily tools like Wireshark makes it an easy process to capture and verify any suspicions of a DoS Attack.

Here’s an overview of what’s covered:

There’s plenty of interesting information to cover so let’s get right into it.

How TCP SYN Flood Attacks Work

When a client attempts to connect to a server using the TCP protocol e.g (HTTP or HTTPS), it is first required to perform a three-way handshake before any data is exchanged between the two. Since the three-way TCP handshake is always initiated by the client it sends a SYN packet to the server.

 tcp 3 way handshake

The server next replies acknowledging the request and at the same time sends its own SYN request – this is the SYN-ACK packet. The finally the client sends an ACK packet which confirms both two hosts agree to create a connection. The connection is therefore established and data can be transferred between them.

Read our TCP Overview article for more information on the 3-way handshake

In a SYN flood, the attacker sends a high volume of SYN packets to the server using spoofed IP addresses causing the server to send a reply (SYN-ACK) and leave its ports half-open, awaiting for a reply from a host that doesn’t exist:

Performing a TCP SYN flood attack

In a simpler, direct attack (without IP spoofing), the attacker will simply use firewall rules to discard SYN-ACK packets before they reach him. By flooding a target with SYN packets and not responding (ACK), an attacker can easily overwhelm the target’s resources. In this state, the target struggles to handle traffic which in turn will increase CPU usage and memory consumption ultimately leading to the exhaustion of its resources (CPU and RAM). At this point the server will no longer be able to serve legitimate client requests and ultimately lead to a Denial-of-Service.

How to Perform a TCP SYN Flood Attack with Kali Linux & hping3

However, to test if you can detect this type of a DoS attack, you must be able to perform one. The simplest way is via a Kali Linux and more specifically the hping3, a popular TCP penetration testing tool included in Kali Linux.

Alternatively Linux users can install hping3 in their existing Linux distribution using the command:

# sudo apt-get install hping3

In most cases, attackers will use hping or another tool to spoof IP random addresses, so that’s what we’re going to focus on.  The line below lets us start and direct the SYN flood attack to our target (192.168.1.159): 

Configuring Cisco WLC Link Aggregation (LAG) with Port-Channel EtherChannel. LAG Restrictions for WLC Models

Posted in Cisco Wireless

Configuring Cisco WLC Link Aggregation (LAG) with Port-Channel EtherChannel. LAG Restrictions for WLC Models - 5.0 out of 5 based on 1 vote

Cisco Wireless Controllers (WLC) support the configuration of Link Aggregation (IEEE 802.3ad - LAG) which bundles the controller ports into a single port channel. This helps simplify the configuration of the WLC interface ports, increase available bandwidth between the wireless and wired network, provide load-balancing capabilities between physical WLC ports and increase port redundancy.

To learn more about WLC interfaces refer to our article Cisco WLC Interfaces, Ports & Their Functionality article

The diagram below shows an example of a WLC 2504 with ports P1 and P2 in a LAG configuration connecting to a Cisco Catalyst or Nexus switch. In the configuration below WLC ports P1 and P2 are aggregated to provide a total of 2Gbps bandwidth:

WLC LAG Configuration with Cisco Nexus and Catalyst Switch

Let’s take a quick look of what’s covered:

Link Aggregation Restrictions - Considerations

While LAG is the preferred method of connecting the WLC to the network there however a number of restrictions we need to be aware of to ensure we don’t stumble into any unpleasant surprises.

  • On 2504 and 3504 WLCs you can bundle all 4 ports into a single link.
  • On 5508 WLC you can bundle up to 8 ports into a single link.
  • Link Aggregation Control Protocol (LACP) or Cisco proprietary Port Aggregation Protocol (PAgP) are not supported by the WLC. Port-Channel members must be set unconditionally to LAG (shown in the configuration below).
  • Only one LAG Group is supported per WLC, you can therefore connect a WLC only to one switch unless using VSS (Catalyst) or vPC (Nexus) technologies.
  • When LAG is enabled, if a single link fails, traffic is automatically switched to the other links.
  • After enabling LAG the WLC must be rebooted.
  • When enabling LAG, all dynamic AP manager interfaces and untagged interfaces will be deleted. (See related article WLC Interfaces – Logical Interfaces)
  • After enabling LAG, all Virtual Interfaces use the LAG interface. No backup port (under the Virtual Interface settings) is configurable:

wlc virtual interfaces with and without lag port channelClick to enlarge

Wireless Controller LAG Configuration – Enabling LAG

How to Detect SYN Flood Attacks with Capsa Network Protocol Analyzer & Create Automated Notification Alerts

Posted in Network Protocol Analyzers

How to Detect SYN Flood Attacks with Capsa Network Protocol Analyzer & Create Automated Notification Alerts - 5.0 out of 5 based on 4 votes

Network Hacker Executing a SYN Flood Attack

This article explains how to detect a SYN Flood Attack using an advanced protocol analyser like Colasoft Capsa. We’ll show you how to identify and inspect abnormal traffic spikes, drill into captured packets and identify evidence of flood attacks. Furthermore we’ll configure Colasoft Capsa to automatically detect SYN Flood Attacks and send automated alert notifications .

Denial-of-Service (DoS) attacks are one of the most persistent attacks network admins face due to the ease they can be carried out. With a couple of commands, an attacker can create a DoS attack capable of disrupting critical network services within an organization.

There are a number of ways to execute a DoS attack, including ARP poisoning, Ping Flood, UDP Flood, Smurf attack and more but we’re going to focus on one of the most common: the SYN flood (half-open attack). In this method, an attacker exploits the TCP handshake process.

In a regular three-way TCP handshake, the user sends a SYN packet to a server, which replies with a SYN-ACK packet. The user replies with a final ACK packet, completing the process and establishing the TCP connection be established after which data can be transferred between the two hosts:

tcp 3 way handshake

However, if a server receives a high volume of SYN packets and no replies (ACK) to its SYN-ACK packets, the TCP connections remain half-open, assuming natural network congestion:

syn flood attack

By flooding a target with SYN packets and not responding (ACK), an attacker can easily overwhelm the target’s available ports. In this state, the target struggles to handle traffic which in turn will increase CPU usage and memory consumption ultimately leading to the exhaustion of its resources (CPU and RAM). At this point the server will no longer be able to serve legitimate clients requests and ultimately lead to a Denial-of-Service.

Free Download of Capsa Enterprise or Standard

Detecting and Investigating Unusual Network Traffic

Fortunately, there are a number of software that can detect SYN Flood attacks. Wireshark is a strong, free solution, but paid versions of Colasoft Capsa make it far easier and quicker to detect and locate network attacks. Graph-oriented displays and clever features make it simple to diagnose issues.

As such, the first point of call for detecting a DoS attack is the dashboard. The overview of your network will make spikes in traffic quickly noticeable. You should be able to notice an uptick in the global utilization graph, as well as the total traffic by bytes:

Windows Server 2019 Free Webinar

Posted in Other Articles

With Microsoft Ignite just around the corner, Windows Server 2019 is set to get its full release and the signs look good. Very good. Unless you’re part of the Windows Server insider program - which grants you access to the latest Windows Server Preview builds - you probably haven’t had a hands-on experience yet with Windows Server 2019 but the guys over at Altaro have and are preparing to host a webinar on the 3rd of October to tell you all about it.

altaro windows server 2019 webinar

The webinar will be held a week after Microsoft Ignite so it will cover the complete feature set included in the full release as well as a more in-depth look at the most important features in Windows Server 2019. Whenever a new version of Windows Server gets released there’s always a lot of attention and media coverage so it’s nice to have an hour long session where you can sit back and let a panel of Microsoft experts cut through the noise and give you all the information you need.

It’s also a great chance to ask your questions direct to those with the inside knowledge and receive answers live on air. Over 2000 people have now registered for this webinar and we’re going to be joining too. It’s free to register - what are you waiting for?

Save your seat: https://goo.gl/V9tYYb

Nexus 7000/7700 Software Upgrade via ISSU. Complete Upgrade Guide, Configuration Check, Verifying ISSU Capability

Posted in Cisco Data Center

Nexus 7000/7700 Software Upgrade via ISSU. Complete Upgrade Guide, Configuration Check, Verifying ISSU Capability - 5.0 out of 5 based on 6 votes

nexus 7000 issu upgradeThis article shows how to perform an ISSU (In-Service Software Upgrade) on a Nexus Data Center switch (7000 and 7700 models) and avoid service and network disruption. We explain the importance of keeping your NX-OS software updated, how the upgrade process is executed, explain the purpose of the Kickstart and System images, provide methods on how to transfer the NX-OS images to the switch bootflash on both supervisor engines, verify ISSU capability and test/simulate the upgrade process.

In addition we cover useful commands to discover issues that might occur during the upgrade process, configuration backup methods, upgrading a Nexus 7000 and Nexus 7700 series with single or dual Supervisor Engines (SUP1 and SUP2 models).

Here is a quick overview of what’s covered:

Why Upgrade Your Nexus 7000/7700 NX-OS Software

Upgrading your NX-OS can be a daunting task as there is always the risk something might go wrong. Despite this, it is very important to ensure your core Nexus switch is running one of the latest and supported images.

If you’re looking for reasons why to take the risk and upgrade, here are a few that might help convince:

  • Old NX-OS images might be stable but usually contain a number of bugs and security vulnerabilities that can put your core network and organization in risk.
  • Your NX-OS version might not be supported any more. This means that in an event of a failure or problem, Cisco Technical Assistance Center (TAC) might require you to upgrade to a supported NX-OS version before providing any support.
  • Support of new features, services and technologies. By upgrading to a newer NX-OS you’ll be able to take advantage of newer features that will now be supported.
  • Support of new Modules and Supervisor Engines. When considering upgrading your Nexus Supervisor Engines or adding new modules it’s likely an upgrade will be required to support them.
  • Peace of Mind. Knowing you’re on a supported, tested and patched up version always helps sleeping better at night!

It’s always recommended to perform a thorough research of the NX-OS version under consideration to identify caveats or issues that might affect your production environment. This information can be found on Cisco’s website or by opening a Cisco TAC Service Request.

What is an ISSU Upgrade?

The ISSU upgrade process provides us with the ability to upgrade a Nexus 7000/7700 switch without network or service disruption. During the ISSU process all Nexus modules and Supervisor Engines are fully upgraded without requiring a switch reboot.

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup