Friday, January 29, 2010

Recommended rfc networks to consider as filters

There are many ways to help protect your network from attack, one of the simpilist and most effective is actually to filter incoming and outgoing traffic from your network. An excellent place to start is to utilize the rfc's to define IPv4 addresses that are not or never will be in use on the public Internet and not allowing that traffic inbound. In the same vein, you can use the same information to limit what is allowed to leave your network, such as only IPv4 addresses that are legitimately routable on the public Internet.

This is not a new or unique solution but it is more commonly done at the service provider and larger enterprise level because those type of operations pay attention to the rfc's but also because they recieve much higher traffic loads on average traditionally. I believe that this technique is still useful for much smaller operations to use and is relatively simple to set up and maintain.

Here is a short list of rfc's to put in your firewall or edge router of addresses you should not be seeing from the Internet and ones that you should consider filtering out before sending traffic out to the Internet.

network RFC 1112
description - Host Extensions for IP Multicasting - in RFC 1700 also
240.0.0.0 240.0.0.0

network RFC 1700
description - assigned numbers - multicast, current, host, and reserved
224.0.0.0 240.0.0.0
240.0.0.0 240.0.0.0
0.0.0.0 255.0.0.0
127.0.0.0 255.0.0.0

network RFC 1797
description - Class A Subnet Experiment - may get reallocated - use the bogon list instead
39.0.0.0 255.0.0.0

network RFC 1918
description - reserved private IPv4 addresses
10.0.0.0 255.0.0.0
172.16.0.0 255.240.0.0
192.168.0.0 255.255.0.0

network RFC 2544
description - Benchmarking Methodology for Network Interconnect Devices
198.18.0.0 255.254.0.0

network RFC 3068
description - IPv4 reserved 6to4 IPv6 gateway services
192.88.99.0 255.255.255.0

network RFC 3171
description - IANA Guidelines for IPv4 Multicast Address Assignments
224.0.0.0 224.0.0.0 (covers 224.0.0.0 through 255.255.255.255)

network RFC 3927
description - Dynamic Configuration of IPv4 Link-Local Addresses - in 5735 above
169.254.0.0 255.255.0.0

network RFC 5735 (update of RFC 3330)
description - this rfc really collects all the other rfc with special use (reserved and limited IPv4 blocks) in a single doc, these is only a partial listing
192.0.2.0 255.255.255.0
169.254.0.0 255.255.0.0
224.0.0.0 224.0.0.0
14.0.0.0 255.0.0.0 (may be reallocated - use the bogon list instead just in case)

network RFC 5736
description - IPv4 Special Purpose Address Registry
192.0.0.0 255.255.255.0

network RFC 5737
description - reserved for test net
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0

Here are some reference URL's to get you started to determine what you should apply for your needs.
Wikipedia
IANA
Team CYMRU

In addition to using IP address list filters there are other protections you can take at the edge. You should consider putting more aggressive ICMP filters in and also filter specific IP protocol numbers from coming in or going out. I'll post more about that another time.
- Ed

Tuesday, January 26, 2010

Update your IPv4 Bogon list

Everyone should update their IPv4 bogon lists a bit faster now that we are below 10% of IPv4 addresses left and it seems that IANA is handing them out faster to force folks to update their lists a bit quicker and I imagine to put pressure downstream for the adoption of IPv6.

January 2010 the following IP blocks were allocated to APNIC: 1/8 and 27/8. This one has some significance because a lot of network engineers in labs or to test something use 1.1.1.1/32 or 2.2.2.2/32 or some other variation within 1/8 or 2/8. Neither should be used now due to the new APNIC allocation and also because in September of 2009 2/8 and 46/8 were allocated to RIPE and should have been removed from your bogon list!

In addition, the IETF obsoleted RFC 3330 with RFC 5735 and as a result the following IP blocks have been reserved for documentation purposes: 198.51.100.0/24 and 203.0.113.0/24. That means they should be added to your bogon list.

If you don't like search around and keeping this stuff up to date yourself the best resource out there is The Team Cymru Bogon List. This list is kept up to date and is super useful as it provides the list in all sorts of useful formats. Highly recommended.
- Ed

Thursday, January 21, 2010

Imperva Releases Detailed Analysis of 32 Million Breached Consumer Passwords

Seems that password security is still a huge issue for enterprises and for consumers. The recent analysis report from Imperva is a little scary and enlightening at the same time. Granted this is analysis of consumer grade passwords for a website but it still offers insight into how people go about using and generating passwords.

Some fascinating items from the reports findings of the most common passwords:
  1. 123456
  2. 12345
  3. 123456789
  4. Password
  5. iloveyou
  6. princess
  7. rockyou
  8. 1234567
  9. 12345678
  10. abc123
I think given that the website was rockyou.com we can safely remove that one from the list. What you are left with are passwords that you should be eliminating as acceptable within your environment. In addition, the graphs show in the report that only 3.81% of users used special characters in their passwords. They also state "Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on)."

Gets you thinking that OTP + pin or smartcards might be the only real way to enforce true high quality password security for consumers or enterprises.
- Ed

Tuesday, January 19, 2010

Microsoft DirectAccess - No ugly truth here

I just finished reading the following Infoworld article on Microsoft DirectAccess by Keith Schultz titled "Microsoft DirectAccess: The ugly truth. I think Keith is trying to get a response out of folks when there really isn't any ugly truth to reveal. I question some of Keith's claims in the article regarding some of the dependencies that he outlines and claims are ugly. Specifically, the deployment requirements for DirectAccess that are outlined are textbook Microsoft and (as is expected from the vendor) they include everything, likely far more than most customers would deploy for a working solution.

A more practical view is to realize that DirectAccess is specifically designed around a Windows Server 2008 and Windows 7 better together story. So, obviously, those two products need to be in use or planned to be deployed. Given the very fast adoption that Windows 7 is enjoying and the fact that Windows Server 2008 R2 is a solid deployment choice for an OS it is natural to start leveraging some of the better together options available. If you don't plan on using Windows 7 or Server 2008 R2 then guess what, don't deploy DirectAccess. I don't think that is an ugly truth it is just logic.

DirectAccess does not require that you replace any infrastructure but instead allows a company to simply upgrade a domain controller to Server 2008 SP1 or R2. Given the refresh cycle it is reasonable to assume that most IT shops will be adding Server 2008 SP1 or R2 into their environment very soon if they have not already. In addition, you will need to deploy (yes a new server or virtual machine) a DirectAccess server or Forefront Unified Access Gateway 2010 server. If you deploy the Forefront UAG 2010 solution you do not require a separate NAT64(NAT-PT is dead BTW) device (UAG provides this function) and UAG can be the DirectAccess solution as well.

I would also argue there are many AD configurations deployed today that are starting to use machine certificates for wireless 802.1x requirements and domain signed certificates for SharePoint and therefore a reasonable amount of customers have started deploying or are looking to deploy certificate services. DirectAccess can piggyback on the CA infrastructure in place or being planned. (As a side note, if you are deploying a CA on Windows Server 2008 R2 - remember to launch IE with "Run as administrator" when you are trying to see the newly copied certificate templates options you have added to the CA server.)

If you end up deploying DirectAccess with Forefront UAG 2010 the issue of having services internally not running IPv6 natively is a mute since it has the NAT64 option. Additionally, there is no requirement to run IPv6 or any transition services at all on the DirectAccess server if desired as it has the option to simply do DA over IP-HTTPS. You will notice in the TechNet article that it outlines transition services "available" for use in DA - not a requirement. Granted, I think running Teredo or 6to4 would be a good deployment option but it is NOT a requirement. Also, regardless of what any of the Microsoft documentation says, do not deploy DA with ISATAP, you will have nothing but headaches and no management or troubleshooting tools to determine why things are not working. You've been warned - no ISATAP!

One of the additional items listed is Network Access Protection (NAP). NAP is far from a requirement to deploy DA. All that Microsoft did was insure that DA conformed to previously designed deployment specification for NAP. That way shops that already have NAP deployed in their environment can continue to leverage and use it for health checks against machines regardless of how they are gaining entry to the network (wired, wireless, DA, ipsec vpn, ssl vpn, pptp.) So, if you are not running NAP and don't plan to then there is nothing to worry about. If you are running NAP already just know you can do integration with DA to leverage your existing investment in NAP.

So, more than likely the purchase of Forefront UAG 2010 with some small upgrades in a typical environment would allow for a successful DirectAccess deployment assuming you have decided that Windows Server 2008 R2 and Windows 7 are where you are going. I don't see a lot of ugly in any of that. The nice thing about choosing Forefront UAG 2010 is that it a high available solution option and builds the group policy configurations for you for DA, a pretty nice plus if you ask me.
- Ed

Friday, January 15, 2010

Microsoft MVP 2010 Summit in one month!

I'm really excited to be heading up to Redmond from Feb 15th to Feb 19th to participate in the Microsoft MVP 2010 Summit. I was first awarded in June of 2004 as a Windows Server - Networking MVP and was in that awardee category until it was eliminated in 2008. I was moved to the Enterprise Security category and continue to focus on networking and was re-awarded in that category in June of 2009.

I don't know if I ever expected to be a 6 year running Microsoft MVP awardee but it has been a wonderful experience and I am really looking forward to seeing a bunch of my fellow MVP's up in Redmond to hear about all the interesting things Microsoft is doing and to exchange ideas and information. I've managed to make it up every year I've been awarded so while not a veteran (compared to some MVP's out there) I am certainly no stranger to the whole extravaganza.

I owe a few shout outs to some Microsoft folks: Emily Freet, Connie Rennie, Jake Grey, Chris Avis, Stephen Rose, Joey Snow, Beth Massi, Chris Avis, Mike Wolfe, Joe Davies, Chris Henley, Sean Siler, Abolade Gbadegesin, Eddie Malik, Kevin Engman, Loretta Duncan-Brantley, Devrim Iyigun, Jeff Sigman, and many more (I hate knowing I forgot someone!)

And to non-Microsoft or former Microsoft, or Microsoft MVP folks: Kathy Jacobs, Steve Riley (ex-Microsoft, now Amazon cloud stud),Bill Pytlovany, Betsy Weber(the most awesome third party MVP supporter - love Techsmith!), Jennelle Crothers and of course PacITPros (and again, forgetting someone, I will correct the list as they come to me!)
- Ed

Thursday, January 07, 2010

Cisco ASA 8.2.1(11) and 8.0.5 comments

I've been running the ASA 8.2.1(11) code on several platforms for a couple of months now and have run into a few problems with it now, primarily site to site VPN issues. Seems that 8.2.1 is slightly better for some of those items (some cosmetic and some outright bugs), I am hoping a new code release comes out soon as the 8.2.1 release has some AnyConnect Client VPN issues with long split tunnel lists that are problematic.

Also, a new 8.0.5ED release came out in Nov for those that are staying on the 8.0 train. Given how stable 8.0.4 is and the fact that it was the default shipping code release on the platform for a long time I don't know how quickly folks will be updating to 8.0.5 now. I guess I will have to test it in the lab to determine if there are issues with running it.
- Ed

Monday, January 04, 2010

Cisco Nexus OS script for private vlans

There are often times when you need to provide layer 2 isolation for servers that logically make sense to keep on the same subnet. A good example are web servers that reside in a dmz that perform the same function but do not have any reason to communicate with each other, just with the public and the common back end application services they are addressing through a firewall. In this scenerio you could either put each server in a /30 subnet and write specific ACL's for that subnet or simply make use of a larger subnet and utilize private vlans.

The Nexus OS allows you to build out private vlans to perform this function. There are two types of secondary vlans you can create in a private vlan. A secondary vlan is one that is bound behind a primary vlan which is how you can control the behavior of the vlan ports. The two secondary types are community (a port that is in a community can talk to those that are in its community) and isolated (it can only talk to itself.) The primary interface should be a promiscuous port so everyone in a community or isolated port can talk to it. In this situation you can build out as many community and isolated secondary pvlans as you require and simply assign them to a primary vlan that is associated with a specific subnet. There are a couple of items to be aware of, things like multicast applications (those that are participating in multicast have to be in the same community) and some other minor requirements for things like clustering which might require those ports to be promiscuous instead of just in a community.

Here is a short sample script you can use to get started.
! - Nexus 7000 script
!
! - configuring private vlans
! - enable pvlans feature
feature private-vlan
! - create primary vlan 100
vlan 100
private-vlan primary
!
! - to confirm that the vlan is a primary do
show vlan private-vlan
!
! - create a secondary community vlan
vlan 200
private-vlan community
!
! - create a secondary isolated vlan
vlan 201
private-vlan isolated
!
! - now associate the secondary vlans with the primary
vlan 100
private-vlan association 200-201
!
! - to see the pvlan mappings do
sh vlan private-vlan
!
! - to put a port in a private-vlan do
interface eth1/1
switchport
switchport mode private-vlan host
switchport private-vlan host-association 100 201
!
! - to see the port status do
show interface eth1/1 switchport
!
! - to set up a promiscuous port
interface eth2/1
switchport
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 200-201
!
! - to see the port status do
show interface eth2/1 switchport
!
! - to set up an SVI (Layer 3 interface) association
feature interface-vlan
interface vlan 100
private-vlan mapping 200-201
!
! - to see the state of the vlan interface
show vlan internal vlan-info

That should get things started for a private vlan configuration on a Cisco Nexus platform.
- Ed

Friday, January 01, 2010

Pacific IT Professionals - User Group Craziness









It is official, I have been the sponsor coordinator (the person who make arrangements for vendors to pay and present at our monthly IT Pro user group meetings) for 6 years now. Somehow I have managed to get a lot of companies to come present and sponsor our group over the years and I want to thank them for being so generous and also seeing the value in coming to talk to a user group.

I've been involved with PacITPros (formerly SFNTUG) for well over 10 years now and have meet and had the pleasure of knowing a ton of people due to my time in the group. I also helped run and do the same roll over at TVNUG before we ran out of steam and I am involved with the East Bay Cisco User Group and the Silicon Valley Cisco User Group which I highly recommend for those that are involved with networking at all.

So, with any luck I will still be doing this in another 6 years and PacITPros will still be going strong. I've been fortunate to watch in grow from 20-30 folks meeting at a law office in the Embarcadero Center to well over 70 people per meeting per month with several thousand on the mailing list. A quick thank you to Doug Spindler (President) for trusting me to get sponsors, Jennelle Crothers for dealing with the pizza, raffle items and general organization of the group, Blaine Busse for dealing with troublesome folks who might show up from time to time, Robert Riebs for giving time and sweat to help keep Doug organized and to lots of others in the group who make the whole user group experience worth the time and effort.
- Ed