Skip to main content


Showing posts from April, 2012

NMAP port states explanation - TCP ACK -sA

ACK scan is meant to be used for mapping firewall rule sets rather than discovering listening ports on hosts. As we can see below all combinations gave the same result.   TCP ACK Service State No Firewall Firewall -sA Listening State: Unfiltered State: Unfiltered nmap target ACK RST nmap target ACK RST Not Listening State: Unfiltered State: Unfiltered nmap target ACK RST nmap target ACK RST

NMAP port states explanation - TCP Connect -sT

In TCP connect scan NMAP attempts to establish a full TCP connection (syn + syn,ack + ack) and then close it (rst,ack). Looking at the below table we can see that both listening and not listening firewalled ports respond with packets (segments to be more correct) that have the same flags set (rst,ack). NMAP is still able to distinguish the state (filtered vs closed). It must be using some other properties of the packet.  TCP Connect Service State No Firewall Firewall -sT Listening State: Open State: Filtered nmap target nmap nmap SYN SYN,ACK ACK RST,ACK nmap target SYN RST,ACK Not Listening State: Closed State: Closed nmap target SYN RST,ACK nmap target SYN RST,ACK Table info can be found here .

NMAP port states explanation - TCP SYN -sS

I've always struggled with various port states reported by nmap ( ). Different scan types report different port states for listening but firewalled ports, listening accessible ports or not listening and so on.  To make my life easier I decided to create tables of most common scan types. I armored myself with Wireshark and did some testing. I used a Windows Firewall running on the scanned machine (called target) for the purpose of this lab. Service State: Listening - means that there is a valid service listening on the scanned port Service State: Not Listening - there is nothing on the scanned port No Firewall column - firewall is off Firewall column - scanned port is firewalled   In a SYN scan NMAP attempts to establish a half-open TCP connection (syn + syn,ack + rst,ack). TCP SYN Service State No Firewall Firewall -sS Listening State: Open State: Filtered nmap target    nmap

Cisco IOS configuration compliance auditing using Nessus

To use this feature you need to be a Nessus professional feed subscriber. Tebnable provides a  number of audit policy files. They are available for download from support portal.  You can download CIS benchmark for both IOS devices and ASA firewalls as well as DISA switch and perimeter router audit files. Setting up a policy is straight forward. It requires that plugin 46689 "Cisco IOS Compliance Checks" is enabled. I generally keep scans separate for sake of report clarity so I enable only this plugin.  I normally enable SYN & UDP scans on all ports as well. As always with UDP, it makes scans much longer. On top of that I find that Nessus UDP scanner is not as reliable as NMAP.  Next we configure credentials. We configure user/pass in "SSH Settings" on "Credentials" tab. Nessus supports only SSH for Cisco audits and requires a user with privileges sufficient to get a full output of "show running-config" or "show startup-c

Determine if a Cisco switch or router is vulnerable

To patch or not to patch, that is the question.... Well, it is when it come to switches and routers.  With Cisco (and other vendors) devices it is not so simple. There are various configurations and various feature sets. For example You may be running version of IOS that has known security vulnerabilities but your device may be not vulnerable.  For example if there is a vulnerability in http server but your device doesn't have it enabled (no ip http server) you are not vulnerable. Obviously an http server may be enabled and some point and this would render the device vulnerable. That's where configuration management and change control come in.  Furthermore there are different feature sets of the same IOS version. You may be running "IP Base" set  which doesn't support MPLS but Nessus will show MPLS vulnerability. So in order to determine if our device is vulnerable we need to look at both Cisco advisory and configuration file. Understanding various feature

Nessus scanning policies

Nessus is a great tool. However, out of the box it's kind of unclear how to go about scanning. There are over 40.000 plugins to choose from. Starting with 4.x default install comes with 4 predefined policies which give some kind of idea. I considered making the policies (.audit files) available but decided not to. They would get out-dated as new plug-ins are released. Instead I'll step through creating them in a series of posts. We should be aware that new plugins are not autmatically enabled. This means that if you create a policy and enable whole "Windows" family, you will have to go back and enable new plugins as they are released. There are a number of good youtube clips from Tenable on Nessus.

Cisco switch and router patch scan policy using Nessus

There are a few caveats to scanning Cisco switches with Nessus. First: I recommend scanning only specific management IP addresses of devices rather than network ranges. The reason for that is that someone could set up a rogue SSH server and intercept the credential you use for scanning. You  can export to the list of IPs from CiscoWorks or use NMAP scan and import result to Nessus. Second: Nessus supports only SSH authentication for Cisco devices.  Third: our policy will include checks for IOS, CatOS and Linksys devices. Fourth: Probably the most important one. You may be running version of IOS that has known vulnerabilities but your device may not be vulnerable. For example if there is a vulnerability in http server but your device doesn't have it enabled you are not vulnerable. Furthermore there are different feature sets of the same IOS version. You may be running "IP Base" set  which doesn't support MPLS but Nessus will show MPLS vulnerability. To perfor

Network Distribution Layer Security

Distribution layer aggregates access layer switches. This is where all packet manipulation that hasn’t already been performed in access layer should take place. I’m focusing here on infrastructure protection rather than device hardening. Everything below is of little benefit if default passwords are used! Even though, properly configured ACLs restricting access to management interfaces would in some cases effectively prevent an attacker from being able to login to a switch. Hardening is essential. This is what we call defence in depth. -           Routing infrastructure protection o      Authenticate routing neighbours with MD5 (prevents rouge routing info injection and routing table manipulation) o     implement route filtering (as above) o     use default passive interfaces (tells an interface not to listen to or distribute routing protocols, this prevents infection and interception of routing data, furthermore it makes determining what routing protocol is in use mo

Network Access Layer Security

The campus access layer switching infrastructure must be resilient to attacks including direct, indirect, intentional, and unintentional types of attacks. In addition, they must offer protection to users and devices within the Layer 2 domain. The below terminology is Cisco specific, however similar features are available in products of other brands.  The key measures for providing switching security on the access switches include the following: • Restrict broadcast domains • Spanning Tree Protocol (STP) Security -        Rapid Per-VLAN Spanning Tree (Rapid PVST+)  (fast convergence) -        BPDU Guard (shuts port down if a BPDU is received, prevents STP manipulation)  -        Root Guard to protect against inadvertent loops (prevents other switches from becoming root bridge) -        BPDU filter (stops BPDUs from being broadcast to access ports) • DHCP Protection -        Implement DHCP snooping on access VLANs to protect against DHCP starvation and rogue DHCP s

Securing HSRP

In previous post I went over attacking HSRP using default authentication of "cisco". In this post I'll go over defenses. HSRP attacks are performed at Layer 2 so the attacker must be on the same L2 domain (same VLAN/subnet). Probably this is the reason no one pays much attention to it. "It's our LAN, it's behind firewall so it's safe. Right?" Maybe, but there are bored employees, there are misconfigurations, and there could be malware that would mess up your network. Either way, if it can be more secure it should be. That's what "defense-in-depth" is all about. HSRP supports authentication. Either a plain-text or md5 ca be used. Plain text option provides little to no protection as the plain text password is sent in clear text with every HSRP packet. MD5 authentication solves the problem. It uses a secret key to generate a keyed MD5 hash of the packet that is part of the outgoing packet. A keyed hash of an incoming packet is ge

Attacking HSRP

Hot Standby Router Protocol (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault-tolerant default gateway, and has been described in detail in RFC 2281 Source: HSRP is used in enterprise networks to provide default gateway redundancy in access layer. Enabling HSRP is as simple as executing two commands. The problem is that by default it uses clear text authentication with password of "cisco".  This can be captured as seen below and used to inject malicious HSRP packets. We will use "Yersinia" to capture and inject our own packets (this is always fun). Our network topology looks as follows: Let's ping the  two "real" addresses .2 & .3 and the vitual IP .1 to confirm everything is working: Now let's fire up Yersinia in GUI mode (the GUI is a bit buggy and sometimes crashes): # yersinia -G  Let's go to "

Reset Nessus user password on Windows

To reset Nessus user password: 1. launch CMD 2. CD to Nessus installation directory (by default %systemdirve%\Program Files\Tenable\Nessus) 3. execute "nessus-chpasswd.ext [username]"  C:\Program Files\Tenable\Nessus>nessus-chpasswd.exe test Authentication (pass/cert) : [pass] Login password : Login password (again) : password changed for test

Key threats to network infrastructure

I’ve been working on LAN infrastructure security assessment recently. As a part of it I’d been looking for bullet point-type summary of main threats to the 3 network architecture layers.  I couldn’t find anything like that which led me to compiling my own list. The below points don’t follow standard access, distribution, core split but Cisco’s “modular design” principle.  Below points are based on “Cisco SAFE Design Reference Guide”.     Enterprise Core: The following are some of the threat vectors affecting the enterprise core: Service disruption—DoS and DDoS attacks on the infrastructure. Unauthorized access—Intrusions, unauthorized users, escalation of privileges, unauthorized access to restricted infrastructure, and routing protocol attacks. Data disclosure and modification—Packet sniffing, man-in-the-middle (MITM) attacks of data while in transit.   Enterprise Campus:

login on-failure log - not logging?

Recently I needed to enable logging of failed logon attempts in Cisco IOS. There is a "login on-failure log" configuration command which helped me accomplish my goal. While testing I noticed that enabling it on its own didn't produce expected results. Basically failed login attempts didn't show up in the log upon enabling it. In the end I found out that it must be used in conjunction with "login block-for" command to actually log logon attempts. R3#show login failures *** No logged failed login attempts with the device.*** This the defualt configuration: R4#sh login      No login delay has been applied.      No Quiet-Mode access list has been configured.      Router NOT enabled to watch for login Attacks This is what we see after enabling "login on-failure log": R3#sh login      No login delay has been applied.      No Quiet-Mode access list has been configured.      All failed login is logged.      Router NOT enabled to watch