Yubikey and Windows Domain 2-Factor Authentication

Posted on March 24, 2013 by ipv6ne

Picking up where we left off last, I was showing you the awesome usefulness, security and affordability of Yubikey (Yubico’s 2-Factor authentication token) and using it for 2-factor authentication on network devices.  Well, I’d like to go another step forward: 2-Factor authentication for Windows computers to a Windows Active Directory environment.  If your enterprise deployment already has a smart-card/PKI environment for users and computers similar to the DoD (re: DoD PKI), then then rest of this probably won’t be useful for you.  If your users, servers and network devices still rely on single user names and passwords, then please read on.

AuthLite + Yubikey

This isn’t as “free” as the solution YubiRADIUS offers.  In fact there’s a licensing cost for each user.  Having said that, the cost is still less than an RSA SecurID deployment.  Yubico partners with a company called Collective Software which maintains the Yubikey and Windows AD integration called AuthLite.  At first, I was sceptical on how useful this was going to be.

First step is installing the software agent on your domain controllers.  This process is very simple:

  • Download the agent directly on your first domain controller: 64-bit (for Windows 2008 R2) or 32-bit (for Windows 2008 32-bit)
  • The user installing it must be an Enterprise Admin (or in a Schema Admins) group
  • Install as administrator
  • Don’t check the box until you install the other domain controllers since this is the first installation.
  • Click the defaults and let the installation finish.  If there are any errors it’s likely because AD replication may be having problems or your user account doesn’t have the right permissions.
  • Now you’ll be prompted to reboot – do this.
  • After you log back in the AuthLite Configuration window will pop up.  You won’t be able to do much until you at least get an evaluation license.  To do that go to http://AuthLite.com/License enter the License ID.  See picture below.  My ID is “AD” as it will likely be your domain name.
  • Once you fill out the license request you’ll get a key back via email.  Enter it in the “Enter Your License Key” area

config1

  • Once you are all licensed, you’ll need to enter either a user name or security group on the “Select AuthLite Users.”  I find it easier to control these functions by adding users to a group.  As shown below I called mine “AD\yubi”

config2

  •  Next go to “Offline Logon Permissions,” and add either a select group of computers or all of your domain computers and the security group the users are part of.  This allows users to logon when Domain Controllers (DCs) can’t be reached.  This is a good idea for users that need to access local documents and are not connected to the LAN.  Don’t worry the encryption info about the keys is stored locally so OTP (one-time password is still supported).  Given your security level, you may not want this because the encrypted seeds are now stored on user laptops.
  • Now install AuthLite on your other DCs and your workstations that will be part of this – remember to click the check-box on install to have it sync with current AuthLite installations.
  • Once you install on the workstation have the user login to the workstation hit CTRL+ALT+DELETE and select “Change a Password”
  • select the user
  • enter the current password and a new one (or just the same one), but make sure you have the Yubikey inserted in the USB port and you check the box “Set up a new AuthLite Key for this account.”  Now hit go.
  • You’ll be asked to delete the current key configuration.  You’ll need to delete it, so don’t do this on a Yubikey that has other purposes.
  • Now logout and log back in by entering your password, then tap the Yubikey button, and hit enter.  Provided installation, licensing and configuration were done correctly, you should login via 2-Factor without a problem.

 Adding Network Device Authentication to Yubikey + AuthLite

In the last blog I told you about using YubiRADIUS for network device login.  However, if you want to completely integrate authentication and 2-factor authentication, I recommend you use the RADIUS service and NPS Plugin.  Configure the “IAS/NPS Plugin” just like the below picture.  I recommend you make sure NPS is working fine before you continue.

config3

Once you restart both the AuthLite and NPS service, you should be able to authenticate with OTP and password on your network device.  The only downside to using NPS with AuthLite instead of YubiRADIUS is it only supports PAP RADIUS mode.  This means the username and password are sent in plain-text.  This may seem bad, but remember you are using 2-factor.  The OTP will always be different.  Having said that, there are many enterprises that feel this is too much of a security issue.

If having PAP is too much of a security issue for you and would rather use CHAP with YubiRADIUS, that is fine.  However, the OTP will be stripped off the AD logon request message sent to the DC.  There may be a way to use “One-Factor Authentication” on YubiRADIUS and have the password sent be both the password and OTP.  I have not tested this, so I am not sure this will work.  I will get back to everyone to let them know if it does.  Thanks again for reading!

 

 

Posted in Cyber Security, DoD, DoD UC APL, Enterprise Architecture, Routing and Switching | Tagged , , , , , , , , , | Comments Off

Secure and Affordable 2-factor authentication: Yubikey

Posted on February 24, 2013 by ipv6ne

In the DoD there is a strong requirement for 2-factor authentication in the network.  For systems and workstations they use a successful implementation with Public Key Infrastructure (PKI) and a DoD common access card (CAC) which has a client certificate.  The user has a PIN; therefore, 2-factor.   Nothing like this exists for network devices (routers, switches, etc).  It requires simple network devices to be able to authenticate client certificates using a DoD CA and OCSP responders.

Even if this were implemented by Cisco, Juniper, HP, Brocade, etc there’s still the issue of client-side software.  PuTTy has an experimental version called PuTTy-CAC, but it’s hard to test when nothing supports it on the server-side.  So this leaves network administrators to either have a vulnerable authentication system using standard RADIUS/TACACS+ and passwords, or they spend hundreds of thousands on implementations like EMC’s RSA SecurID.  However I’m not sure if that makes your network more or less secure considering how easy it was for the Chinese to get the RSA seed files – see my earlier post from a few years ago.  Enter Yubikey.

Secure AND affordable 2-factor Authentication

Yubico, a new technology start-up, trying to address the affordable and secure part, but also what to do with mobile devices.  Yubikey is their flagship 2-factor authentication device that works like a standard USB keyboard.  It costs about $30 (less if purchased in volume) and their more expensive key is the Yubikey NEO.  It is basically a Near-Field Communication (NFC) key – for mobile devices – that costs about $50.

The use for standard Yubikeys is to basically plug the key into the USB port (platform independent) and press the button.  The button generates an AES-128 encrypted one-time password (OTP).  Yubico’s technical documentation explains the authentication and verification process like this:

  1. The received string is converted back to a byte string
  2. The byte string is decrypted using the same (symmetric) 128-bit AES key
  3. The string’s checksum is verified. If not valid, the OTP is rejected
  4. Additional fields are verified. If not valid, the OTP is rejected
  5. The non-volatile counter is compared with the previously received value. If lower than or equal to the stored value, the received OTP is rejected as a replay.
  6. If greater than the stored value, the received value is stored and the OTP is accepted as valid

The process seems great for web applications like WordPress authentication or GMAIL, but what about the first point, 2-factor authentication for network devices?  Enter YubiRADIUS.  YubiRADIUS is a fully-configurable platform that integrates with a Windows domain and all those Yubikeys.  Oh, and YubiRADIUS runs on a hardened virtual Linux appliance – and is free.  So, in order to get full and secure 2-factor authentication in an enterprise – buy the $30 tokens and setup the free YubiRADIUS.  Also, did I mention it’s fully IPv6 enabled?

Currently, we have Yubikey and YubiRADIUS running in our DoD Unified Capabilities Approved Products List (UC APL) test lab and will be taking it into DoD UC APL testing as a viable network device 2-factor authentication solution soon.  Here’s some of what Yubikey and YubiRADIUS give you above solutions from SecurID:

  • validation server is part of YubiRADIUS and is free (as in free beer)
  • Yubikeys can be used for an enterprise and for personal GMAIL, wordpress, etc.  It’s not a single use token, very flexible.
  • Platform independent.  So is SecurID, but with SecrID, you have to type the OTP in manually instead with Yubikey you just hit the button.
  • YubiRADIUS will soon be available in a fully DoD STIGed and hardened platform.  We are currently working on that.
  • Pricing is easy.  Just buy the token once.  It lasts forever, with the configuration there’s no need for it to expire.  SecurID costs ~$265 for a pack of 5 that expire in 2 years.  Buy over 255 and you pay $55 per token that expire in 2 years.  Buy 50 Yubikeys and it’s only $15 per that never expire.  Did I mention the infrastructure (YubiRADIUS & Validation Server) are free?

Yubikey Awesome Add-Ons

If the above were not enough of a selling point, check out the list of extensible options you get with Yuibikey:

All in all, Yubikey gives a commercial enterprise, DoD enterprise, small business, and individual the power and affordability to finally ditch the single password and use 2-factor authentication.

 

Posted in Cloud Computing, Cyber Security, DoD, DoD UC APL, Enterprise Architecture, IPv6, IPv6 Security, Virtualization | Tagged , , , , , , , , | 1 Comment

FIPS 140-3 is Coming: Time to Plan

Posted on January 21, 2013 by ipv6ne

FIPS 140-1 and FIPS 140-2 had quite a bit of longevity.  However, FIPS 140-3 is almost here.  Based on previous NIST standards development processes, the 140-3 standard will most likely have a publication date of a year from now.  So sometime in February/March 2014, FIPS 140-3 will be the dominate federal crypto module certification.  Not familiar with FIPS 140 at all?

Federal Information Processing Standard 140

FIPS 140 is a standard which was meant to coordinate the cryptographic modules’ software and hardware design of commercial IT products.  The standard identifies what the product must do to restrict software library access to the crypto modules and protect it from unauthorized use.  The program created by the National Institute of Standards in Information Technology (NIST), is thought to be one of the most successful and pervasive in US Government history.

Part of the standard breaks out specific levels that can be attained.

  • Security Level 1: the lowest of security requirements.  Attaining this level is done by showing compliance on a purely software layer of crypto isolation.  This is actually the minimum requirement for most US federal procurements and testing.
  • Security Level 2: A more robust security requirement as it adds physical tamper-evidence and role-based authentication
  • Security Level 3: Adds physical tamper-resistance – meaning the crypto modules are not accessible from unauthorized users/libraries.
  • Security Level 4: Adds a physical element against environmental attacks like heat, cold, water, etc.

The NIST accredited 22 test labs within trusted nations to do this testing. They are all located here on NIST’s official test lab list:  http://csrc.nist.gov/groups/STM/testing_labs/index.html

Once a product has been certified, they are given a certificate and put on the FIPS 140-1 and FIPS 140-2 Validated Products List: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

What’s New with FIPS 140-3

Public law requires NIST to review new cryptographic technologies every five years, so FIPS 140-3 is required.  An earlier draft (2007 draft 1) had a 5th security level, but that had since been abandoned in the most recent draft (2009 draft 2).  Here are some of the new things that commercial products with crypto libraries need to be aware of with FIPS 140-3:

  • the addition of software/firmware security – gone are the days of loading a new bootable operating system/firmware with embedded security.  For example, Cisco has already started including signed IOS binaries called .SSA and .SSP IOS images.  Take a look: http://www.networkworld.com/community/node/46950
    • This will likely take the most effort for embedded operating system vendors
  • Periodic Self-Tests – FIPS 140-2 required power-up and conditional self-tests, but never periodic self-tests.  NIST defines this as, “Acceptable means for the on-demand initiation of periodic self-tests are: resetting, rebooting, and power.”

Get Your Product Development Houses Prepared

The last thing a product needs is to lose a sale based on poor federal certification planning.  There’s no guarantee that a FIPS 140-2 certification will last forever in government procurements (or even be grandfathered).  They are likely to require FIPS 140-3 within a few years of its signature.  So plan well!

 

 

Posted in Cloud Computing, Cyber Security, Enterprise Architecture, Federal Procurements | Tagged , , , , , , , , | Comments Off

Nexus vPC Peer-Link Interface Options

Posted on January 13, 2013 by ipv6ne

A colleague brought up a very important issue in regards to vPC survivability.  There are Nexus vPC Peer-Link interface options.  Take a look at the below diagrams.  As you can see, we have a big problem here with survivability that can often be overlooked: if the one single vPC layer-3 peer-link interface goes down for whatever reason (cable cut, SFP breaks, module goes down, etc) then the Nexus switches do something extremely horrible.  They split-brain-split-forward!

Basically, in the vPC world, all links are set to forward, and nothing blocks at layer-2 because Spanning Tree is not really in place here.  Cisco calls it a “split-brain” scenario.  If that vPC peer-link fails for any reason, both switches assume the role of primary.  This then creates the forwarding-loop-from-hell.  Cisco explains it much better here:

If the vPC keepalive link fails first and then a peer link fails, the vPC secondary switch assumes the primary switch role and keeps its vPC member ports up.

If the peer link and keepalive link fails, there could be a chance that both vPC switches are healthy and the failure occurs because of a connectivity issue between the switches. In this situation, both vPC switches claim the primary switch role and keep the vPC member ports up. This situation is known as a split-brain scenario. Because the peer link is no longer available, the two vPC switches cannot synchronize the unicast MAC address and the IGMP group and therefore they cannot maintain the complete unicast and multicast forwarding table. This situation is rare.

We recommend that you have a well-planned network design that includes spreading peer links and keepalive links to multiple ASICs or multiple modules and different cabling routes for keepalive and peer links to avoid a double failure.

So take a look at these options.  They show how to: (1) deploy vPC peer-links incorrectly with only one module, (2) deploy vPC peer-links correctly with two separate modules, and (3) deploy vPC peer-links correctly with only one module.

The below diagram is shown with only a single layer-3 interface as the vPC peer link – PLEASE DON’T DO THIS!

Switch # 1

NexusSwitch1(config)# interface e2/1
NexusSwitch1(config-if)# desc Single L3 vPC link
NexusSwitch1(config-if)# vrf forwarding VPC
NexusSwitch1(config-if)# ip address 192.168.1.1/30
NexusSwitch1(config-if)# vpc peer-link

NexusSwitch1(config-if)# exit 
NexusSwitch1(config)# vpc domain 100 
NexusSwitch1(config-vpc-domain)# peer-keepalive destination 192.168.1.2 source 192.168.1.1 vrf VPC

Switch # 2

NexusSwitch2(config)# interface e2/1
NexusSwitch2(config-if)# desc Single L3 vPC link
NexusSwitch2(config-if)# vrf forwarding VPC
NexusSwitch2(config-if)# ip address 192.168.1.1/30
NexusSwitch2(config-if)# vpc peer-link
NexusSwitch2(config-if)# exit

NexusSwitch2(config)# vpc domain 100
NexusSwitch2(config-vpc-domain)# peer-keepalive destination 192.168.1.1 source 192.168.1.1 vrf VPC

The below diagram is shown with  multiple layer-3 interfaces on a single module as the vPC peer link with a layer-3 port-channel configured- LESS BAD :-)

Switch # 1

NexusSwitch1(config)# interface e2/1-2
NexusSwitch1(config-if-range)# desc Single L3 vPC link
NexusSwitch1(config-if-range)# no switchport
NexusSwitch1(config-if-range)# vrf forwarding VPC
NexusSwitch1(config-if-range)# channel-group 100 mode none
NexusSwitch1(config-if)# exit 

NexusSwitch1(config)# int Po100 
NexusSwitch1(config-if)# desc VPC peer link 
NexusSwitch1(config-if)# no switchport 
NexusSwitch1(config-if)# vrf forwarding VPC 
NexusSwitch1(config-if)# ip address 192.168.1.1/30 
NexusSwitch1(config-if)# vpc peer-link 
NexusSwitch1(config-if)# exit 

NexusSwitch1(config)# vpc domain 100 
NexusSwitch1(config-vpc-domain)# peer-keepalive destination 192.168.1.2 source 192.168.1.1 vrf VPC

Switch # 2

NexusSwitch2(config)# interface e2/1-2
NexusSwitch2(config-if-range)# desc Single L3 vPC link
NexusSwitch2(config-if-range)# no switchport
NexusSwitch2(config-if-range)# vrf forwarding VPC
NexusSwitch2(config-if-range)# channel-group 100 mode none
NexusSwitch2(config-if)# exit 

NexusSwitch2(config)# int Po100 
NexusSwitch2(config-if)# desc VPC peer link 
NexusSwitch2(config-if)# no switchport 
NexusSwitch2(config-if)# vrf forwarding VPC 
NexusSwitch2(config-if)# ip address 192.168.1.2/30 
NexusSwitch2(config-if)# vpc peer-link 
NexusSwitch2(config-if)# exit 
NexusSwitch2(config)# vpc domain 100 
NexusSwitch2(config-vpc-domain)# peer-keepalive destination 192.168.1.1 source 192.168.1.2 vrf VPC

The below diagram is shown with  multiple layer-3 interfaces on multiple modules as the vPC peer link with a layer-3 port-channel configured- BEST OPTION!

Switch # 1

NexusSwitch1(config)# interface e2/1
NexusSwitch1(config-if)# desc L3 vPC link
NexusSwitch1(config-if)# no switchport
NexusSwitch1(config-if)# vrf forwarding VPC
NexusSwitch1(config-if)# channel-group 100 mode none
NexusSwitch1(config-if)# exit
NexusSwitch1(config)# interface e3/1 
NexusSwitch1(config-if)# desc L3 vPC link 
NexusSwitch1(config-if)# no switchport 
NexusSwitch1(config-if)# vrf forwarding VPC
NexusSwitch1(config-if)# channel-group 100 mode none
NexusSwitch1(config-if)# exit

NexusSwitch1(config)# int Po100 
NexusSwitch1(config-if)# desc VPC peer link 
NexusSwitch1(config-if)# no switchport 
NexusSwitch1(config-if)# vrf forwarding VPC 
NexusSwitch1(config-if)# ip address 192.168.1.1/30 
NexusSwitch1(config-if)# vpc peer-link 
NexusSwitch1(config-if)# exit 

NexusSwitch1(config)# vpc domain 100 
NexusSwitch1(config-vpc-domain)# peer-keepalive destination 192.168.1.2 source 192.168.1.1 vrf VPC

Switch # 2

NexusSwitch2(config)# interface e2/1 
NexusSwitch2(config-if)# desc L3 vPC link 
NexusSwitch2(config-if)# no switchport 
NexusSwitch2(config-if)# vrf forwarding VPC 
NexusSwitch2(config-if)# channel-group 100 mode none
NexusSwitch2(config-if)# exit

NexusSwitch2(config)# interface e3/1 
NexusSwitch2(config-if)# desc L3 vPC link 
NexusSwitch2(config-if)# no switchport 
NexusSwitch2(config-if)# vrf forwarding VPC
NexusSwitch2(config-if)# channel-group 100 mode none
NexusSwitch2(config-if)# exit

NexusSwitch2(config)# int Po100 
NexusSwitch2(config-if)# desc VPC peer link 
NexusSwitch2(config-if)# no switchport 
NexusSwitch2(config-if)# vrf forwarding VPC 
NexusSwitch2(config-if)# ip address 192.168.1.2/30 
NexusSwitch2(config-if)# vpc peer-link 
NexusSwitch2(config-if)# exit 

NexusSwitch2(config)# vpc domain 100 
NexusSwitch2(config-vpc-domain)# peer-keepalive destination 192.168.1.1 source 192.168.1.2 vrf VPC

Posted in Cloud Computing, Enterprise Architecture, Routing and Switching | Tagged , , , , , , , , , , , | Comments Off

DoD APL Website Down

Posted on January 2, 2013 by ipv6ne

aplits

***Update 7 January 2013: The APLITS website is now back up and serving the DoD APL community***

Continue reading →

Posted in Cyber Security, DoD, DoD UC APL, Federal Procurements | Tagged , , , , , , , | Comments Off

Nexus 7000 IPv6 Configuration Pitfalls

Posted on October 23, 2012 by ipv6ne

I have recently started working in a datacenter configuring quite a few Nexus 7000 series switches to act mainly as datacenter access switches – mainly making use of the popular features of Virtual Device Contexts (VDCs) and Virtual Port-Channels (vPCs).  Well, IPv6 is a key part of the network environment.

So for the last week, I discovered that IPv6 was not working across a few standard layer-2 untagged VLAN access ports – even thought IPv4 had no issues.  It took a Cisco TAC Case and a very nice engineer from Cisco to discover why.

Read the %^&*$# Manual

My environment consisted of a router-on-a-stick approach to layer 3 routed interfaces.  This is mainly due to High Availability (HA) considerations.  In this most recent example, I had two firewalls connected directly (logically through two access ports) and was using the Nexus 7000 switch to act as a go-between.  Meaning, in order to ensure $FAILOVER technology can function, there needs to be some layer 2 connectivity to each other.  So one firewall connects to one 10 GE interface and the other connects to another 10 GE interface on the same layer-2 VLAN like this:

interface e1/1
 description 1st Firewall Link
 switchport
 switchport access vlan 10

interface e1/2
 description 2nd Firewall Link
 switchport
 switchport access vlan 10

After much troubleshooting, and discovering this setup works just fine with IPv4, the great engineers at Cisco TAC informed me that a default configuration on Nexus 7000 switches with Fabric 2 Modules have the following issues with IPv6 (from Cisco):

Guidelines and Limitations for IPv6

IPv6 has the following configuration guidelines and limitations:

  • IPv6 packets are transparent to Layer 2 LAN switches because the switches do not examine Layer 3 packet information before forwarding IPv6 frames. IPv6 hosts can be directly attached to Layer 2 LAN switches.
  • You can configure multiple IPv6 global addresses within the same prefix on an interface. However, multiple IPv6 link-local addresses on an interface are not supported.
  • Because RFC 3879 deprecates the use of site-local addresses, you should configure private IPv6 addresses according to the recommendations of unique local addressing (ULA) in RFC 4193.
  • F2 Series modules do not support IPv6 tunnels.
  • On F2 Series modules, you must disable IGMP optimized multicast flooding (OMF) on any VLANs that require any IPv6 packet forwarding (unicast or multicast). IPv6 neighbor discovery functions correctly only in a VLAN with the OMF feature disabled. To disable OMF, use the no ip igmp snooping optimised-multicast-flood command in VLAN configuration mode. With OMF disabled, unknown IPv4 multicast traffic (as well as all IPv6 multicast traffic) is flooded to all ports in the VLAN. Note that unknown multicast traffic refers to multicast packets with an active source but no receivers (and therefore no group forwarding entry in the hardware) in the ingress VLAN.

Yeah, that last one got me.  Apparently, Cisco is trying to “help” me by taking multicast snooping to an all new level – killing any IPv6 communication.  Why this is important is because IPv6 Neighbor Discovery (think ARP for IPv4) goes over multicast.  So what I imagine the snooping is doing on F2 Modules is drop all Ethernet frames with the the destination MAC of 33-33-xx-xx-xx-xx.  The “XX” map to the IPv6 multicast group the frame is trying to reach.  For example, the all-nodes multicast address is ff02::1 the Ethernet MAC maps to 33:33:00:00:00:01.

So by disabling Cisco’s “optimized” multicast flood protection, you get IPv6 to work on a layer-2 interface.  The command should be done on the VDC you are working in.  You have to make sure you think in the Queen’s English for this one:

  • no ip igmp snooping optimised-multicast-flood

Posted in IPv6, IPv6 in the Industry, Routing and Switching | Tagged , , , , , , , , , , , , | Comments Off

2012 US Government IPv6 Mandate: The Day of Reckoning

Posted on September 28, 2012 by ipv6ne

Well, today is the day, or the last day I should say.  At midnight tonight, the US Government will have shut the books on yet another Fiscal Year.  Although, it’s not finances that has the technology industry glued to government tech news; it’s IPv6 adoption.  By the end of FY 2012, the entire US Government (all 1,498 federal domains per data.gov and NIST) should have followed through on their mandate to implement IPv6 on their publicly-facing services (per White House 2010 Directive).  Did they do it?  Not at all – that is, the mandate was to reach 100% adoption.  The good news is that a good portion made it.  The bad news is the agencies that had serious problems made almost no progress since four months ago.  This includes the DoD (e.g. DISA).

In May of 2012, only 43 websites had transitioned and made their website publicly accessible over IPv6.  Today that number is 272 (see graph below), and it’s only 25% total.   DNS and Mail followed a similar pattern.

If your curious about where your favorite agency falls, take a look at the NIST IPv6 Government Deployment Tracker here.

http://usgv6-deploymon.antd.nist.gov/images/graph-gov.png

Posted in DoD, Enterprise Architecture, Federal Procurements, IPv6, IPv6 in the Government, IPv6 in the Industry | Tagged , , | Comments Off

Cisco IPv6 IOS Hardening – DoD Style

Posted on August 26, 2012 by ipv6ne

Thousands of network engineers in the DoD out there looking at implementing IPv6 now have to address a few Security and Technical Implementation Guidance (STIG) items that they used to just annotate as “Not Applicable – NA.”  Now, IPv6 security is important.  If you are a vendor, it might be a good idea to look at what you will now absolutely have to address, or risk certification and accreditation of your products in an DoD enterprise.

The STIG Viewer

Whatever your feelings are with Java, the software engineers at DISA put together a great way to finally view, edit, and transmit those STIGs.  It’s called the DISA STIG Viewer (currently in version 1.1).  It’s available to everyone, regardless of operating system platform.  Not all of the STIGs are available to the average “Joe”, but a good majority are available.  In this blog I will be using the Cisco Perimeter Router STIG as an example.  The IPv6-secific STIG items are as follows.  The parts in bold are the actual commands.

The IPv6 STIG Items

NET-IPv6-004 – IPv6 Router Advertisements must be suppressed on externally-facing links

-This is usually your BGP peering points, but it’s good practice for all your Point-point router links:

ipv6 nd ra-supress

On an ASA it’s ipv6 ra-supress

NET-IPv6-006 – IPv6 Undermined Transport

-This is for IPv6 packets with Next Headers that are totally not correct

ipv6  access-list inbound-to-enclave
remark prohibit unknown protocols
deny ipv6 any any undetermined-trans log

NET-IPv6-008 – IPv6 Bogons

-This is for IPv6 address you shouldn’t see – like the old 6Bone

ipv6 access-list inbound-to-enclave
remark prohibit IPv6 Bogons
deny ipv6 3FFE::/16 any log
deny ipv6 any 3FFE::/16 log

NET-IPv6-011 – IPv6 Outbound ICMPv6

-This is for all thing ICMPv6 related

ipv6 access-list inbound-to-enclave
remark Filter ICMPv6
remark Allow outbound ping request from LAN subnet
permit icmp 2001:db8:60::/44 2000::/3 echo-request
remark Allow Path MTU to function
permit icmp 2001:db8:60::/44 2000::/3 packet-too-big
remark Allow flow control
permit icmp 2001:db8:60::/44 2000::/3 source-quench
remark Allow time exceeded messages for loops
permit icmp 2001:db8:60::/44 2000::/3 time-exceeded
remark Allow ND ICMP types generally, but not RD
permit icmp any any nd-na
permit icmp any any nd-ns
remark Explicitly block all other ICMP packets
deny icmp any any log-input

NET-IPv6-016 – Disable vulnerable ICMPv6 on external interface

-This is for the external interface and could be good on point-to-point, routed, untrusted interfaces

(config-int) no ipv6 redirects
(config-int) no ipv6 unreachables
(config-int) no ipv6 mask-reply

NET-IPv6-017 – IPv6 Routing Header (or just RH Type 0)

-This is for the IPv6 source routing header.  If you are running Mobile IPv6 use the first one, if not use the second one.

With Mobile IPv6 (Routing Header Type 2):

ipv6  access-list inbound-to-enclave
remark prohibit IPv6 routing header type0
deny ipv6 any any routing-type 0 log

Without Mobile IPv6 (Routing Header Type 2):

(config)no ipv6 source-routing

ipv6  access-list inbound-to-enclave
remark prohibit IPv6 routing header type0
deny ipv6 any any routing

NET-IPv6-022 – IPv6 Link-Local Unicast Addresses at perimeter

-This is one I don’t agree with and think DISA needs to remove this one.  Even at the permeter, Neighbor Discovery (ND) needs to happen.  Plus routing updates use link-local.  DISA gets a de-merit for this one :-)

***Don’t do this unless you want to break IPv6 routing***

ipv6 access-list inbound-to-enclave
remark prohibit use of link-local
deny ipv6 fe80::/10 any log
deny ipv6 any fe80::/10 log

NET-IPv6-025 & 26 – Block IPv6 Site-Local

-Site-Local was deprecated with Unique-Local Unicast.  Block these.

ipv6  access-list inbound-to-enclave
remark prohibit use of site-local
deny ipv6 fec0::/10 any log
deny ipv6 any fec0::/10 log

NET-IPv6-027 – Block IPv6 Loopback Address

-Loopback in IPv6 is ::1 just like IPv4′s 127.0.0.1, and you shouldn’t see these on any wire.  Block these.

ipv6  access-list inbound-to-enclave
remark block packets with local loopback address
deny ipv6 ::1/128 any log

NET-IPv6-028 – Block IPv6 Unspecified Address

-Unspecified in IPv6 is ::/0 just like IPv4′s 0.0.0.0, and you shouldn’t see these on any wire.  Block these.
ipv6  access-list inbound-to-enclave
remark block traffic with the unspecified address
deny ipv6 ::/128 any log
deny ipv6 any ::/128 log

NET-IPv6-029 – Block IPv6 Multicast Source Address

-You should never see an IPv6 multicast address as the source address anywhere.  They will only be destination addresses.  Block these.  Of course, DISA messed up the example in their STIG.  ***Only block the source – not destination!

ipv6  access-list inbound-to-enclave
remark block packets with multicast source address
deny ipv6 ff00::/8 any log

NET-IPv6-030 – Block IPv4-compatible Addresses

-You should never see an IPv4-compatible address on the wire.  Block these.

ipv6  access-list inbound-to-enclave
remark block packets with embedded IPv4-compatible IPv6 addresses
deny ipv6 0::/96 any log
deny ipv6 any 0::/96 log

NET-IPv6-031 – Block IPv4-mapped Addresses

-You should never see an IPv4-mapped address on the wire.  Block these.

ipv6  access-list inbound-to-enclave
remark block embedded IPv4-mapped IPv6 addresses
deny ipv6 ::FFFF:0:0/96 any log
deny ipv6 any ::FFFF:0:0/96 log

NET-IPv6-032 – Block IPv6 Unique Local Addresses (ULA)

-You should never see an IPv6 ULA on your border, it’s OK for internal use, but never allow them in or out!  Block these.

ipv6  access-list inbound-to-enclave
remark block IPv6 Unique Local Unicast Addresses
deny ipv6 FC00::/7 any log
deny ipv6 any FC00::/7 log

NET-IPv6-033 – IPv6 CEF enabled

-Enable IPv6 CEF

(config) ipv6 cef

NET-IPv6-034 – Egrees Outbound Source Reachable

-Very similar to uRPF.

ipv6 verify unicast source reachable-via rx  outbound-to-backbone

NET-IPv6-047 & 48- IPv6 NAT

-I don’t recommend you do IPv6 NAT, but don’t do what DISA recommends as it is the old NAT-PT.  Most everyone has moved to the new standard: NAT64.  There’s a lot of commands so go here to see it: https://supportforums.cisco.com/docs/DOC-22619

NET-IPv6-060 – Packet with Invalid Hop-by-Hop Header

-Fun with Extension Headers!  This is where is gets fun.  Only some values are within spec.  Block these.

ipv6  access-list inbound-to-enclave
remark block IPv6 HbH Invalid Options
deny 0 any any dest-option-type 4
 deny 0 any any dest-option-type 195
 deny 0 any any dest-option-type home-address

NET-IPv6-061 & 63 – Packet with Invalid Destination Options Header

-Fun with Extension Headers!  This is where is gets fun.  Only some values are within spec.  Block these.

ipv6  access-list inbound-to-enclave
remark block IPv6 DO Invalid Options
 deny 60 any any dest-option-type 5
deny 60 any any dest-option-type 194

deny 60 any any dest-option-type 195

NET-IPv6-062 – Packet with IPv6 Endpoint Identification

-Fun with Extension Headers!  This is where is gets fun.  Only some values are within spec.  Block these.

ipv6  access-list inbound-to-enclave
remark block IPv6 DO Invalid Options
 deny any any dest-option-type 138

 NET-IPv6-064 – Filter Undefined Extension Header Types

-Fun with Extension Headers!  This is where is gets fun.  Only some values are within spec.  Block these.

ipv6  access-list inbound-to-enclave
remark block IPv6 Invalid Extension Header Types
deny any any dest-option-type 2
deny any any dest-option-type 3
deny any any dest-option-type 6
deny any any dest-option-type 7
deny any any dest-option-type 8
deny any any dest-option-type 137
deny any any dest-option-type 139
deny any any dest-option-type 193
deny any any dest-option-type 196
deny any any dest-option-type 197
deny any any dest-option-type 198
deny any any dest-option-type 199
deny any any dest-option-type 200
deny any any dest-option-type 202
deny any any dest-option-type 255

NET-IPv6-066 – 6in4 or 6to4 Filtering

-Seems odd that DISA would block the whole address space just to add filtering guidance.  Many of you out there will have IPv6 over IPv4 tunnels.  So use this as guidance.

ipv6 general-prefix 6TO4_PREFIX 6to4 FastEthernet0/1

interface Tunnel0
ipv6 address 2001:db8::1/64
tunnel source FastEthernet0/0
tunnel mode ipv6ip 6to4 **or no 6to4
!
interface FastEthernet0/0
ip address 10.1.12.1 255.255.255.0
ipv6 address 6TO4_PREFIX ::1:0:0:0:1/64
ipv6 traffic-filter IPV6_EGRESS_FILTER in
!
interface FastEthernet0/1
description DISN CORE facing
ip address 198.18.0.1 255.255.255.0
!
ipv6 route 2002::/16 Tunnel0
!
ipv6 access-list IPV6_EGRESS_FILTER
permit ipv6 2002:C612:1::/48 any
deny ipv6 any any log

NET-TUNL-001, 2, 20 & 33 – Block Legacy Tunneling

-Some of these may be in use in your network so read carefully.  Only block what’s not being used.

ip  access-list inbound-to-enclave
remark block Legacy Tunneling
deny 4 any any log
deny 41 any any log **only if you aren’t doing 6in4 tunneling
deny 47 any any log **only if you aren’t doing GRE tunneling
deny 42 any any log
deny 93 any any log

 deny  97 any any log
 deny tcp any any eq 1723 log
 deny udp any any eq 1723 log

 deny udp any any eq 3544 log **Teredo

deny 98 any any log

ip  access-list inbound-to-enclave
remark block Legacy Tunneling
deny 4 any any log
deny 41 any any log **only if you aren’t doing 6in4 tunneling
deny 47 any any log **only if you aren’t doing GRE tunneling
deny 42 any any log
deny 93 any any log

 deny  97 any any log
 deny tcp any any eq 1723 log
 deny udp any any eq 1723 log

deny 98 any any log

NET-MCAST-001 – Block PIM – If not useing**

-Some of these may be in use in your network so read carefully.  Only block what’s not being used.

interface FastEthernet0/1
description DISN CORE facing
no ipv6 pim

NET-MCAST-002 – If using IPv6 PIM – filter

-If you are using PIM make sure to be specific about whom you are allowing to be a PIM neighbor

ipv6 pim neighbor-filter list PIM_NEIGHBORS

ipv6 access-list PIM_NEIGHBORS
permit host FE80::1 any
permit host FE80::3 any
deny any any log

NET-MCAST-009 & 10 – IPv6 Administrative Multicast Restrictions

-Be very careful with this one, especially if you are allowing IPv6 multicast routing in and out of the enterprise.

ipv6 multicast-routing
!
interface FastEthernet0/1
 description DISN CORE facing
 ipv6 address 2001:db8::1/64
 ipv6 multicast boundary scope 8

***(this only allows for any type over 8 – like global – if you have an admin or organization local IPv6 multicast infrastructure then modify this value!)

NET-MCAST-020 – IPv6 Source-Specific Multicast Groups

-If you aren’t configuring IPv6 SSM don’t worry about this one.  However, if you are do this.

ipv6 access-list SSM_RANGE permit  any ff3e::1:0:0/96
ipv6 pim ssm range SSM_RANGE

or

ipv6 pim ssm default *

**”default” means it will only use FF3x::/32 – where “x” is any valid scope value.

Posted in Cyber Security, DoD, Enterprise Architecture, IPv6, IPv6 in the Government, IPv6 in the Industry, IPv6 Security, Routing and Switching | Tagged , , , , , , , , , | Comments Off

Why 802.1x is Not Enough: How to Implement SeND – Part 2

Posted on August 23, 2012 by ipv6ne

Last month I presented the case as to why 802.1x authentication is not enough for local network (wired or wireless) security (go back here to read).  In this post I will present an alternative: IPv6 Secure Neighbor Discovery (SeND).  If you have an IPv6 enterprise, small IPv6 deployment, or a little IPv6 lab then pay close attention.  I will discuss what SeND is and what it is not, its limitations, and products/software that support and do not support it.  In the process of discussing SeND I will also show how it is setup on the router and host (configurations are in BOLD).  Feel free to use these same configurations in your own lab and/or enterprise production environments (or you can just hire us ;-)

What is SeND and How Does it Work?

SeND is an awesome method of port-based/segment-based authentication for every host, router, and packet in the network.  In fact, the only thing close to SeND in operation today is 802.1x.  However, SeND takes the 802.1x architecture and makes it much more hardened and usable.  Think: SeND is 802.1x on steroids.  One more aspect to SeND is Cryptographically Generated Addresses (CGA).  By using CGA, not only are the packets authenticated, but the host and router develop a unique RSA key that generates a unique and secure address that will change and re-negotiate securely – not just randomly (unlike Windows that basically just randomizes the IPv6 address).

Build the Public Key Infrastructure (PKI)

The fundamental architecture of SeND uses the Public Key Infrastructure (PKI).  The lynch-pin of any PKI environment is the Certificate Authority (CA) server.  So you can follow along here while I help you build your own CA on a Cisco router – or use your own CA.  If you have a Microsoft CA then use that.  Most organizations have a good PKI in-place.  It’s best to just use that.  However, it is a little more difficult to use a CA that’s not another Cisco router because of the auto-enrolment capability you get.

The Environment:

CA router: “SEND_CA”, IPv4 address: 172.24.1.254, CGA generated IPv6 address: 2001:DB8:1:1:3419:DE30:3DA7:1D02

Segment gateway router: “SEND”, IPv4 address: 172.24.1.1, CGA generated IPv6 address: 2001:DB8:1:1:20D5:2985:29C:40D5

Simulated host (standard 7200 router): “SEND_HOST”, IPv4 address: 172.24.1.2, CGA generated IPv6 address: 2001:DB8:1:1:3012:418C:2951:C89E

Configuration Steps

The first step is configuring the CA (if you are using a Cisco router).   This includes creating the PKI policy and trustpoint:

crypto pki server CA
 issuer-name C=US, ST=CA, L=domain, O=info, OU=dude, CN=CAO lifetime ca-certificate
!
crypto pki trustpoint CA
 ip-extension prefix 2001:DB8:1:1::/64
 revocation-check crl
 rsakeypair CA
!
crypto pki trustpoint SEND
 enrollment url http://172.24.1.254:80
 revocation-check none

Now let’s configure the router.  We need to generate the keys and add the CGA configuration:

 crypto key generate rsa label SEND modulus 1024
 ipv6 cga modifier rsakeypair SEND sec-level 1

 crypto pki trustpoint SEND
 enrollment url http://172.24.1.254:80
 subject-name C=US, ST=VA, L=domain, O=info, OU=NSSTG, CN=router
 revocation-check none
 rsakeypair SEND
 auto-enroll

Now we need to add the certificate request and get the signed certificate from the CA:

 crypto pki authenticate SEND

Certificate has the following attributes:
Fingerprint MD5: FC99580D 0A280EB4 2EB9E72B 941E9BDA
Fingerprint SHA1: 22B10EF0 9A519177 145EA4F6 73667837 3A154C53
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
 crypto pki enroll SEND

% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:

Now we just need to finish it up by applying our SeND and CGA configs on the interface to ensure all of our hosts can or should authenticate:

interface FastEthernet0/0
 ipv6 cga rsakeypair SEND
 ipv6 address FE80:: link-local cga
 ipv6 address 2001:DB8:1:1::/64 cga
 ipv6 nd secured trustanchor SEND
 ipv6 nd secured full-secure
 ipv6 nd prefix 2001:DB8:1:1::/64

The command “ipv6 secured full-secure” means that we are requiring any host on the network to authenticate.  To make your SeND policy a little less restrictive don’t enable “full-secure” and all hosts can still talk and if there is ever a conflict (meaning that an IPv6 address is being spoofed, SeND hosts on the network will ONLY listen to the properly authenticated one.

From the host side, the configuration is very similar to enrolling with the CA and setting the interfaces.  CA enrollment:

 crypto key generate rsa label SEND modulus 1024
 ipv6 cga modifier rsakeypair SEND sec-level 1

 crypto pki trustpoint SEND_CA
 enrollment url http://172.24.1.254:80
 revocation-check none
auto-enroll regenerate

crypto pki authenticate SEND_CA

Then exit to the global config and type:

 ipv6 nd secured sec-level minimum 1

Now on the interface let’s get going!

int f0/0
ipv6 cga rsakeypair SEND
ipv6 addr fe80:: link-local cga
ipv6 addr 2001:db8:1:1::/64 cga
ipv6 nd secured trustanchor SEND_CA
ipv6 nd secured timestamp delta 300
exit

Let’s get it on!
ipv6 nd secured full-secure

This will fundamentally enable it.  When you do the “show ipv6 neighbor” command, you probably won’t see anyone except for the router’s link-local address.  Go to the the router and copy the IPv6 address – you have to check it this way: “sh ipv6 int f0/0“.   Now ping the router from your “host router.” and do the show command again.  If everything works, you’ll see the Global Unicast address pop up in the IPv6 neighbor table.

So SenD is anything but intuitive, so let us know in the comments or send us an email if you have any questions, lessons-learned, or suggestions: info@tachyondynamics.com

What hosts and routers support IPv6 SeND and CGA?  Stay tuned for Part 3!

Posted in Cyber Security, Enterprise Architecture, IPv6, IPv6 in the Industry, IPv6 Security, Routing and Switching | Tagged , , , , , , , , | 4 Comments

Tachyon Dynamics helps NetApp Achieve DoD UC APL Certification

Posted on August 19, 2012 by ipv6ne

Fairfax, VA — (August 16, 2012) – NetApp, Inc. (NASDAQ: NTAP), a leader in data storage and storage provisioning enterprise and data center products achieved the Defense Department Unified Capabilities Approved Products List (UC APL) certification with the help of the Washington DC-based Information Technology firm: Tachyon Dynamics.

NetApp received its certification as the first Data Storage Controller (DSC) for all NetApp filers using Data ONTAP software version 7.3.6.  The UC APL certification is a DoD testing program that requires all IT equipment to go through rigorous Information Assurance (IA), Interoperability, and Internet Protocol Version 6 (IPv6) testing.

Tachyon Dynamics’ UC APL engineers helped NetApp through each part of the process from application, to hardening, to documentation and engineering design.  The engineers from Tachyon Dynamics were crucial to NetApp’s testing success.

More information about the NetApp UC APL Certification memo is located here: https://aplits.disa.mil/dispatchDocumentAPL.do?hd7%2B0f4irpw%3D

 

About Tachyon Dynamics
Tachyon Dynamics is a premier technology company focused on advanced technology enterprise planning, designing, and implementation like Internet Protocol version 6 (IPv6), virtual server systems, cutting edge networking systems, and proven cyber security technologies and processes.  We are a Service-Disabled Veteran-Owned Small Business (SDVOSB) that understands the importance of efficient and reliable communications.  tachyondynamics.com

About NetApp
NetApp creates innovative storage and data management solutions that deliver outstanding cost efficiency and accelerate business breakthroughs. Our commitment to living our core values and consistently being recognized as a great place to work around the world are fundamental to our long-term growth and success, as well as the success of our pathway partners and customers. Discover our passion for helping companies around the world go further, faster at www.netapp.com.

Posted in DoD, Enterprise Architecture, Federal Procurements | Tagged , , , , , , , , | Comments Off