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 (http://nmap.org). 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
SYN
SYN,ACK
RST
nmap
target   
nmap
SYN

SYN
Not Listening

State: Closed


State: Closed
nmap
target
SYN
RST,ACK
nmap
target
SYN
RST,ACK

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-config" (you can choose which one you want to audit). (Option "Save(show config)" has been deprecated). "Show running-config" requires a user with privilege 15 as only then  it is possible to get full output.



I tired creating "views" (using Cisco role based CLI) to no avail, I also tried lowering privilege level required to execute "sh run" which didn't work either. The problem here is that "show run" invokes a number of other commands (and sub commands) in the background. 


By default "show startup-config" requires privilege 15 too. Here we can work around by lowering privilege requires to execute this command.


To do so at the IOS prompt:


#conf t
#privilege exec level 1 show startup-config


This will allow any priv 1 (and higher) user to execute sh start. This user will then be able to see SNMP strings and passwords (if not encrypted), so the implications should be considered. 

If your security policy disallows SSHing directly with priv 15 accounts you can use 'standard' account and then use "enable" to elevate permissions instead. 



Last step is to import .audit file downloaded from Tenable's site. This is done in "Preferences" Tab. 

 To summarize:
  • download desired audit policy from Tenable
  • disable all plugins
  • enable 46689 "Cisco IOS Compliance Checks" plugin
  • specify credentials
  • import audit policy file
To create a privilege 15 user in Cisco IOS:

#conf t
#username auditor privilege 15 password somepass

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 sets is also helpful, this link can help here:


http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp


First we need to find out what version of IOS we run. We can do it using CiscoWorks LMS RME reporting feature. Here we can create an CSV report listing our devices and IOS versions. 


Alternately we can  connect to the device and execute: "show version" command which will give us both feature set (i.e xxx-IPBASEK9) and IOS version (I.E. 12.2(50)SE).


We will also need the config file which again we can get from CiscoWorks or directly from the switch by executing "show running-config" or "show startup-config". They generally should be the same, as a best practice you can compare them using CiscoWorks or manually using CSDIF for example. This will ensure that potentially vulnerable configuration are not be enabled upon reload.


Once we have that we can go to "Cisco IOS Software Checker" 


http://tools.cisco.com/security/center/selectIOSVersion.x


We paste in the version ID and hit submit:






Then we select "All previously published Cisco Security Advisories" and hit continue.


Once we are presented with the list of published vulns the fun begins. 








Knowing that are feature set is IPBASE we can straight away discard MPLS, IKE and Software Tunnels vulnerabilities as these are not support in this set. 


Now we need to analyse all remaining advisories.


Open relevant advisory and have a read. In most cases either "Vulnerable Product" or "Details" sections specify configurations that are.


In our example first advisory requires that http(s) server is enabled.  My sample switch is not vulnerable as my config file contains:


!
no ip http server
no ip https server
!


This should give you an idea of how it works.

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.

http://www.youtube.com/user/tenablesecurity/videos?query=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 perform this scan an IOS user with privilege 1 is sufficient. Nessus uses output of "show version". 


There are a number of approaches to creating Nessus scanning policies.

1. enable whole "Cisco" family.  This policy would however include checks specific to ASA, Aironet etc - This is Tenable recommended approach. 

2. create a filter (plugin name - contains - cisco) and enable all plug-ins. This policy would include things like CSA agent detection on Windows, VPN client software, etc. Lot of checks not applicable to switches or routers. 

3.use Nessus plugin filtering feature and selectively enable only switch/router applicable plugins - this is my proffered method as it reduces the risk of potential adverse effects the scan could have. Even though this should not happen (Nessus should not fire a plugin that's not applicable), last thing we'd like would be to bring a core switch down.

Here we go: 

1. Configure General settings:
  • disable both Netstat  SSH & WMI
  • disable SNMP Scan
  • enable UDP Scan
  • set port range to 1-65535
  • leave remaining settings on defaults
You may want to enable Network Congestion handling features depending on your network.  You may also want to limit number of maximum hosts scanned simultaneously (Max Hosts Per Scan). 






2. Configure Credentials:
  • Specify SSH User name




3. Select Plugins:

  • All plugins are enabled by default so click "Disable All"
  • Enable Cisco plugin family
  • Enable Settings family



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 more difficult)

o    log neighbour changes

-          Implement redundancy (good, resilient design is the key)

-          Implement ACLs (Network segmentation is implemented here, I.E. preventing finance VLANS access to HR servers)

-          Implement Infrastructure ACLs (or iACLs as Cisco calls them) to restrict access to infrastructure management IP addresses (be careful not to block transit traffic but only traffic aimed at Core or distribution devices / VLANS itself)

NOTE: iACLs are only applicable in the distribution layer of a multi-tier design where the routed edge interface is on the distribution switches. In a routed access design, this is enabled in the access layer.

-          Apply uRPF to block packets with spoofed IP addresses (Unicast Reverse Path Forwarding – the router will check if the source IP is reachable before forwarding a packet, the same can be accomplished using ACL that allow traffic only from subnets that exist in particular network segment)

NOTE: uRPF is only applicable in the distribution layer of a multi-tier design where the routed edge interface is on the distribution switches. In a routed access design, this is enabled in the access layer. 

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 server attacks
IP Spoofing Protection
-       Implement IP Source Guard on access ports to prevent IP spoofing
ARP Spoofing Protection
-       Implement dynamic ARP inspection (DAI) on access VLANs
MAC Flooding Protection
-       Enable Port Security on access ports (to limit number of MAC addresses allowed on a port)
Broadcast and Multicast Storm Protection
-       Enable storm control on access ports 
VLAN Best Common Practices
-       Restrict VLANs to a single switch (current design best practice, prevents STP issues)
-       Configure separate VLANs for voice and data
-       Configure all user-facing ports as non-trunking (DTP off)
-       Disable VLAN dynamic trunk negotiation on access ports (prevents VLAN hopping attacks)
-       Explicitly configure trunking on infrastructure ports rather than autonegotiation
-       Use VTP transparent mode
-       Disable unused ports and place in unused VLAN
-       Do not use VLAN 1 for anything
-       Configure native VLAN on trunk links to an unused VLAN (prevents VLAN hopping using double-tagged frames)


Source: Cisco SAFE Design Reference Guide

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 generated and if the generated hash does not match the hash within the incoming packet, the packet is ignored.

To enable MD5 authentication the following command is used in the interface configuration context:


R1(config-if) #standby authentication md5 key-string "the key"



HSRP packet with default authentication:


HSRP packet with md5 authentication enabled:


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: https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol

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" http://www.yersinia.net/ 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 "HSRP" tab and select "Edit Interaces"  (in my case it's eth1).
Once correct interface is selected Yersinia autmatically starts capturing interesting packets.



Here we go to "Launch attack" and pick what we want to do. For the purpose of this lab I selected option "becoming active router" and hit "OK" (first option crashes the GUI)
Yersinia starts sending HSRP "Hello (state Active)" packets, which basically say that I'm now taking over the virtual IP address. At this point both "R2" and "R4" become "stand by" routers and all traffic bound for the gateway flows to the attacker.

There two implications, firtsly it can be used for Man in the middle (MITM) attack (the same thing can be accomplished with ARP poisoining)  or cause a denial of service (DoS) condition where clients on the VLAN using this gateway wouldn't be able to connect to anything outside of the local network.
As seen below the virtual address didn't respond to ping while bogus HSRP packets were being injected.


This is not a great scenario to have to deal with during business hours, specially on a crowded access VLAN. 



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”.  http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap1.html
  

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:

 The following are some of the key threats that affect the campus:
  • Service disruption—Botnets, malware, adware, spyware, viruses, DoS attacks (buffer overflows and endpoint exploitation), Layer-2 attacks, and DDoS on services and infrastructure.
  • Unauthorized access—Intrusions, unauthorized users, escalation of privileges, IP Spoofing, and unauthorized access to restricted resources.
  • Data disclosure and modification—Sniffing, man-in-the-middle (MITM) attacks of data while in transit.
  • Network abuse—Peer-to-peer and instant messaging abuse, out-of-policy browsing, and access to forbidden content.
  • Data leak—From servers and user endpoints, data in transit and in rest.
  • Identity theft and fraud—On servers and end users, phishing, and E-mail spam.

Intranet Data Centre:

 The following are some of the threat vectors affecting the Intranet data center:
  • Unauthorized access
  • Interruption of service
  • Data loss
  • Data modification
Unauthorized access can include unauthorized device access and unauthorized data access. Interruption of service, data loss, and data modification can be the result of targeted attacks. A single threat can target one or more of these areas. Specific threats can include the following: privilege escalation; malware; spyware; botnets; denial-of-service (DoS); traversal attacks (including directory, URL); cross-site scripting attacks; SQL attacks; malformed packets; viruses; worms; and, man-in-the-middle.

Management Module:

The following are some of the expected threat vectors affecting the management module:
  • Unauthorized Access
  • Denial-of-Service (DoS)
  • Distributed DoS (DDoS)
  • Man-in-the-Middle (MITM) Attacks
  • Privilege escalation
  • Intrusions
  • Network reconnaissance
  • Password attacks
  • IP spoofing

Internet Edge:

The Internet edge is a public-facing network infrastructure and is particularly exposed to large array of external threats. Some of the expected threats are as follows:
  • Denial-of-service (DoS), distributed DoS (DDoS)
  • Spyware, malware, and adware
  • Network intrusion, takeover, and unauthorized network access
  • E-mail spam and viruses
  • Web-based phishing, viruses, and spyware
  • Application-layer attacks (XML attacks, cross scripting, and so on)
  • Identity theft, fraud, and data leakage 

Enterprise WAN edge:

The threats addressed in the WAN edge of an end-to-end enterprise architecture are focused on three key areas:
  • Malicious activity initiated by branch clients, including malware proliferation, botnet detection, network and application abuse, and other malicious or non-compliant activity.
  • WAN transit vulnerabilities, such as sniffing and man-in-the-middle (MITM) attacks.
  • Attacks against the infrastructure itself, such as unauthorized access, privilege escalation, and denial-of-service (DoS) attacks.

Enterprise Branch:

 The threats addressed in the branch of an end-to-end enterprise architecture are focused on the following key areas:
  • Malicious activity by branch clients, including malware proliferation, botnet detection, network and application abuse, and other malicious or non-compliant activity.
  • WAN transit vulnerabilities such as sniffing and man-in-the-middle (MITM) attacks.
  • Attacks against the infrastructure itself, such as unauthorized access, privilege escalation, and denial-of-service (DoS) attacks



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 for login Attacks


This is configuration that we need in order for the router to actually log failed attempts:

R3#sh login
     A default login delay of 1 seconds is applied.
     No Quiet-Mode access list has been configured.
     All failed login is logged.


     Router enabled to watch for login Attacks.
     If more than 3 login failures occur in 60 seconds or less,
     logins will be disabled for 10 seconds.


     Router presently in Normal-Mode.
     Current Watch Window
         Time remaining: 27 seconds.


To set it up we need to do the following:

1. Create local user:

username test privilege 1 password cisco

2. Force use of local authentication database for vty lines:

line vty 0 4 
login local 

3. Enable logging of failed attempts:

login on-failure log

4. Enable block-for feature:

login block-for 10 attempts 3 within 60


Now the router will log failures:


R3#show login failures
Total failed logins: 1
Detailed information about last 50 failures


Username        SourceIPAddr    lPort Count TimeStamp
test            10.0.0.2        23    1     00:08:40 UTC Fri Mar 1 2002


R3#sh login
     A default login delay of 1 seconds is applied.
     No Quiet-Mode access list has been configured.
     All failed login is logged.


     Router enabled to watch for login Attacks.
     If more than 3 login failures occur in 60 seconds or less,
     logins will be disabled for 10 seconds.


     Router presently in Normal-Mode.
     Current Watch Window
         Time remaining: 27 seconds.
         Login failures for current window: 0.
     Total login failures: 1.


More details on Cisco site: https://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_login_enhance.html