ACLs by Country

Have you ever wanted to create an ACL by country?  There's a number of different ways you can go about it.  Certain models of firewalls have this functionality built in.  IOS based routers and ASA firewalls have no such capability, so we'll have to do this a bit more manually.  I'll present two methods.

The first method is detailed here.  In this post, wget goes out to the Internet and grabs the necessary data from the applicable RIR.  Some custom Perl code pulls out the subnets associated with that country and then builds the ACL.  This one is probably not for the faint of heart nor someone not very fluent in Unix command lines.

A simpler way is through a website called Country IP Blocks.  Navigate to The Create Country ACL page on their site and you can select one or more countries to build an ACL for.  Then pick which format you want the results in.  Cisco ACL is just one of 12 options here, and then click "Create ACL" and you're done.  Other sites such as ipdeny.com and countryacl.tools.uebi.net provide similar functionality.

These lists get pretty long. Want one that that will permit or deny United States based addresses?  That'll be 55,348 lines.  Want to create an ACL that will block Russia and China?  That's 27,386 lines.  Hope your router is maxed out on RAM.

TCL Scripting

According to it's man page, "tclsh is a shell-like application that reads TCL commands from its standard input or from a file and evaluates them. If invoked with no arguments then it runs interactively, reading TCL commands from standard input and printing command results and error messages to standard output. It runs until the exit command is invoked or until it reaches end-of-file on its standard input."  The TCL Developer Xchange describes the TCL language as  "a very powerful but easy to learn dynamic programming language, suitable for a very wide range of uses, including web and desktop applications, networking, administration, testing and many more. Open source and business-friendly, TCL is a mature yet evolving language that is truly cross platform, easily deployed and highly extensible. "

The language was created John Ousterhout at the University of California, Berkley.  It's either installed by default or available through the package repositories in nearly every Linux distribution and flavor of BSD.  ActiveState maintains an edition called ActiveTcl.  The community edition has precompiled binaries for Windows, Mac and Linux.  The Enterprise Edition adds binaries for HP-UX, Solaris and AIX.  ActiveState also the home of ActivePerl and ActivePython, which are solid editions of Perl and Python for the same platforms.

Tclsh was added to Cisco IOS in version 12.3(2)T and 12.2(25)S, and to Cisco NX-OS in Release 5.1(1) to provide scripting capability.  With it, you are able to run TCL commands directly from the Cisco IOS prompt, or to create and execute scripts written in the TCL language.  Just about anything you can do in tclsh on a Linux or BSD system can be done in tclsh on a Cisco router.  This of course assumes you're using straight TCL and not any add-on packages.

To use tclsh, simply type the command tclsh at the exec prompt.  To exit tclsh, type tclquit.  While within tclsh you can create scripts with the proc command, by typing proc script_name {, and then ending your script with a closing }.  A great example of the power of this scripting environment can be found in this post at INE, where Brian McGahan, along with an assist from reader Jason Cook, demonstrates a TCL script to generate a number of random IP addresses and subnet masks tied to Loopback interfaces.  I've used this script several times in the lab to quickly add routes into a routing protocol.  If you're feeling really adventurous, you can even get your router to Tweet.  And that's the beauty of scripting, you are able to quickly and easily automate the mundane tasks that aren't what you are working on and interested in, but still need accomplished.

And though it is not suggested, you can change your login shell on a Linux, BSD or Unix system to tclsh and do your day to day work in it as a means of learning the language and environment.  However, as noted, its not suggested as it's not really suited as being used a login script wasn't in the design goals.  See this article for more details.

I'll be getting more into TCL on IOS in the near future.

Some Good References to Get Started:

The official reference from Cisco:
Cisco IOS Scripting with TCL Command

The Cisco book:
Tcl Scripting for Cisco IOS

Some books that come recommended by the TCL Developer Exchange:

Practical Programming in Tcl and Tk, 4th ed.
Tcl/Tk, Second Edition: A Developer's Guide
Tcl and the Tk Toolkit, 2nd ed.
Tcl/Tk 8.5 Programming Cookbook

Hard Code DNS Servers with PowerShell

The following is a PowerShell script to quickly hard code DNS servers for every network interface present on a computer. It will overwrite the existing DNS servers configured on that machines interfaces.  In this example, we'll be using the IP addresses for OpenDNS servers.

# The servers that we want to use
$newDNSServers = "208.67.220.220","208.67.222.222"

# Get all network adapters that already have DNS servers set
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object {$_.DNSServerSearchOrder -ne $null}

# Set the DNS server search order for all of the previously-found adapters
$adapters | ForEach-Object {$_.SetDNSServerSearchOrder($newDNSServers)}

Do the Google

It still surprises me that in 2016, there are still people out there who cannot, or will not, use Google to find the answer to their question.  I'm the admin of a large group on Facebook that exists primarily for people pursuing the CCNA certification, though most technical discussion that stays on the right side of the law is permitted.  Since we get at least one question a day that involves something that could be solved in 10 seconds with Google such as "what is the CCNA?" or "what is Spanning Tree?" I've decided to put together a page explaining how to use Google to find what you're looking for.  And for the Microsoft slappies out there, you are more than welcome to try that other "search engine" as long as you're enjoying it's crap results.  I for one very rarely got good results when I tried it a couple times in the past.

In case you were wondering, the title of this post, "Do the Google" came from a poster on Reddit by the name of /u/sajaschi, in the Tales from Tech Support sub-reddit, that he heard from a family member who's computer he supported.   I liked the term and immediately told him that I'm stealing it. The thread is here for completeness.

Resequencing an ACL

Here's a quick post on a very useful command when working with ACLs.  I first heard about it while watching a CBT Nugget video, and I can say that it was definitely not covered in the NetAcad curriculum when I went through the classes, because I remember bringing it up to the instructor and it was news to him.

So let's begin by setting the scenerio.  You have the following ACL:

show ip access-list EXAMPLE

Extended IP access list EXAMPLE
    1 permit ip host 10.10.10.28 any
    2 permit ip host 10.10.10.10 any
    3 permit ip host 10.10.10.11 any
    4 permit ip host 10.10.10.45 any
    5 deny ip 10.10.10.0 0.0.0.255 any
    10 permit tcp any host 192.168.10.4 eq smtp

And let's say that we now need to allow one additional host out.  We could rewrite the ACL, but that could be a lot of work if its a long ACL.  Any other options?

Yes, the resequence command can help.  This command was introduced in IOS 12.2(14)S, and allows you to easily resequence an entire ACL.

ip access-list resequence EXAMPLE 10 10

This will renumber every line in the ACL starting with 10, and with an increment of 10 between each line.  This is the default sequencing for an access-list where no sequence numbers are entered.  The end result would be:

Extended IP access list EXAMPLE
    10 permit ip host 10.10.10.28 any
    20 permit ip host 10.10.10.10 any
    30 permit ip host 10.10.10.11 any
    40 permit ip host 10.10.10.45 any
    50 deny ip 10.10.10.0 0.0.0.255 any
    60 permit tcp any host 192.168.10.4 eq smtp

Old documenation will tell you that you can't edit a numbered ACL, but that's actually not true anymore.  

Reflexive ACLs on IOS Routers

In a nutshell, reflexive ACLs allow packets to be evaluated based on upper layer session information. You use reflexive ACLs in order to permit the return traffic from an established session, but deny all other traffic in that direction.  For example, you open up a browser and establish an HTTPS session with www.awesomewebsite.com.  Now obviously, you want the return traffic from the server hosting awesomewebsite.com to make it back to you so you can see this awesome website.  But you also do not want malicious traffic trying to reach your workstation to come in with it.  A standard or extended ACL does not allow this, it's all or nothing.  But a reflexive ACL allows you to do exactly that, allow the return traffic from your session with awesomewebsite.com, but deny all other incoming traffic.  I've heard reflexive ACLs described as "a poor man's stateful firewall."

Cisco documentation points out that you can also configure it in the other direction.  You can, for example, allow all incoming traffic to a server in your DMZ, but only allow return traffic from that server to go back out to the Internet. In this example, external users would be able to view the content on your DMZ server, but it would mitigate the risk of your server becoming part of a botnet and eat up your upload bandwidth participating in a DDoS attack.  While possible, I doubt it's used very often.  So in the configuration example, we'll focus on the more common scenario.

So lets configure a reflexive ACL.  We'll start out with a basic ACL in the outbound direction which will allow all outbound traffic.  As typical, I'll use upper case letters for words and names I've created so they stand out as such when viewing show statements. 

ip access-list extended OUTBOUND
  permit ip any any reflect REFLECTED

And that's it.  In this ACL, we are allowing all outbound traffic. The difference here between this ACL and no ACL at all is the keyword reflect.  This tells the router to remember all traffic matched by the permit ip any any, and create a dynamic ACL for the return traffic that will be allowed.  But we're not limited to this single permit in the OUTBOUND ACL, we can combine that with any combination of permit and deny statements as needed.  Note that reflexive ACLs can only be used as part of extended named ACLs.   But other than that, you're pretty much only limited by your imagination.

ip access-list extended OUTBOUND
  permit tcp host 10.10.10.10 any eq smtp REFLECTED
  deny tcp any any eq smtp
  permit ip any any reflect REFLECTED

Here, we're denying outbound smtp except from a single host (the company email server), and then allowing all other traffic to go out reflected. Next, we'll create a basic ACL for the inbound direction.

ip access-list extended INBOUND
  evaluate REFLECTED

Again, we're not limited to just a single evaultate statement in this ACL either, we can add in any other needed statements allowed by a named ACL.

ip acess-list extended INBOUND
  evaluate REFLECTED
  permit any host 10.10.10.10 eq smtp
  permit any host 10.10.10.10 eq http

Now we just need to apply those lists to the outward facing interface of the router.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out

If you have multiple outward facing interfaces, you can apply these same ACLs to multiple interfaces and the same REFLECTED dynamic list will be maintained between them, shielding you from the side effects of asymmetric routing.  Now if Cisco would only give us a way to share the state of reflexive ACL's between different routers (one pointed at ISP1 and one pointed at ISP2 for example), then we'd be all set.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out
!
interface Ethernet 1/1
  ip access-group INBOUND in
  ip access-group OUTBOUND out

Installing NDES on the Issuing CA

The Network Device Enrollment Service (better known as NDES) is a component of Active Directory Certificate Services.  It's based on the industry standard Simple Certificate Enrollment Protocol (SCEP) which is an Internet Draft by the Internet Engineering Task Force (IETF).  SCEP is designed to make digital certificate issuance as simple and scaleable as possible.  SCEP can be used to distribute certificates to network devices such as routers and firewalls, as well as mobile devices such as cellphones.

In this post, we'll go through the installation of NDES on the issuing CA.  There won't be many screenshots this time around since we've already seen pretty much everything installing the Active Directory Certificate Services role on both CAs. Note that I'll be using the domain name of firewallninja.info throughout.  Substitute the name of your domain as appropriate.

First, we need to add a service account.  On the domain controller, launch Active Directory Users and Computers (ADUC) from the Administrative Tools program group.  On the left side of the screen, you'll see the OU hierarchy for your domain. Right click on firewallnina.info and create a new OU called Admins.  Inside the Admins OU, create another OU called Service Identities.  Right Click on Service Identities and select new and then user.  Give this user the username of NDESService and a firstname of whatever (you have to give the user either a first name or last name in addition to a username), and on the next screen a password that you'll be able to remember. Uncheck User Must Change Password at Next Login and select Password Never Expires. Finish off the wizard to create the user. It will look as follows when you are done.

Now go back to the issuing CA.  Launch Computer Management from the Administrative Tools program group.  Expand out Local Users and Groups, and then Groups on the left side.  Double Click IIS_IUSRS, and then click Add.  In the search box that comes up, enter NDESService, and press OK.  Press OK on the IIS_IUSRS properties, And then close Computer Management.

Now in Server Manager, Select Add Roles and Features. 

• Hit Next a couple times until you get to the Server Roles screen.  
• Expand out Active Directory Certificate Services and check the box next to Network Device Enrollment Service. 
• OK additional pieces of IIS to install.  
• On the Specify User Account page, click Select User and enter the NDESService user and its password. 
• On the Specify Registration Authority Information page, give a name for the NDES service (different than that given for the issuing CA) and select a country from the drop down list.  The rest can be left blank.  
• On the Configure Cryptography screen, choose the settings that you used for the Root CA and Issuing CA.
• Review the information about IIS and hit next.
• Review the Confirm Installation Services page and hit next.
• Install NDES.

NDES has now been installed on the issuing CA and is ready to use.  We've now completed the setup of the issuing CA.

Backup Your Blog on Blogger

Here's a little quick and dirty post on backing up your blog on Blogger since every howto that I have seen online is a bit dated and things have moved.   But that's to be expected, things are always moving when it comes to Google.  Like all things in IT, you should make a regular backup of your blog just in case you have an oopsie, or Google determines you have violated their terms and shuts you down.

In your Blogger control panel, go into the settings for the blog you want to back up.  On the left side of the page, you'll see Settings at the bottom of the list of categories.  Click on Settings, then at the bottom of the Settings submenu, you'll see Other.  Click on Other, and at the top of the page you'll see "Import & back up."  Click the button labeled "Back up Content," and you'll be presented a save as dialog box which will let you save a single .xml file with all of your blog's settings and posts.  If you examine the outputted .xml file, you'll find everything there.  Should you wish to move your site do a different platform in the future, many platforms will be able to import this .xml file directly.

Research Results

Our survey was posted online for a period of one week. Following this period, data was pulled down from SurveyMonkey in the form of a Microsoft Excel spreadsheet. Survey results were converted from text to numeric answers. All statistical analysis was conducted in IBM SPSS v23 for Linux on the OpenSUSE Leap 42.1 operating system.

Building the Issuing CA

In the last post, we went through building the root CA which followed building the domain and generating a mess of test users.  Moving along this time, we're going to start building the issuing CA for the domain and for our network devices.  Once we get through this stage, the root CA can be powered down, and moved to long term permanent storage if necessary.

Once again, I'll be using the The 70-640 Self-Paced Training Kit from Microsoft Press as my guide, though the MCTS 70-640 Cert Guide from Pearson will work as well.  I actually prefer the Pearson book as it feels more in depth and complete than the Microsoft Press book.

First, ensure that the root CA and issuing CA are both running. Log into the issuing CA with an administrator account.  As with the root CA, you can use a local administrator on the issuing CA, but a domain administrator will be fine as well.  And unlike the root CA, if you are using Server 2008 or 2008R2 for the issuing CA, it needs to be Enterprise or Data Center Edition.  For Server 2012 and up, Standard Edition will be sufficient.

I'm really liking the decision now to go with Server 2008R2 for the root CA ,Server 2012R2 for the issuing CA, and Server 2016 for the domain controller.  The contrasting appearances of windows in the three operating systems really helps to make it clear which server is which in the screen shots.

Enough of the small talk, let's get started.  Launch Server Manager if it is not already running.  As with setting up the domain controller, start by selecting add roles and features.

Select the local server from the list if it is not the only one, just proceed if it is.

Select Certificate Authority from the list, and accept the prerequisite roles and features to be added.

There won't be any additional features to add, so just Next your way through.

Now options for the CA role appear.

Here we'll select Certificate Authority and Online Responder.  We'll be adding NDES later. With 2008 and 2008R2, you couldn't install NDES at the same time as any other CA role.  I don't recall if that is true still for 2012R2, but I'll just go with what I know here.

We'll have the options to configure IIS next.

The necessary IIS bits will be preselected, add any thing else you may want.

We're now at the confirmation screen where you get one last chance to go back.  Hit install whenever you're ready.

Everything selected will install.

Once the installation is complete, you'll find yourself back at Server Manager.  If you click on AD CS on the left, you'll notice that additional configuration for the AD CS role is required.  On the yellow bar, first click More, then configure.

Here is a dialog box giving you information about what needs to be done.  Click Configure again.

First, you will need to provide credentials. Give the currently logged in user, or provide a username/password for a different user.

Select both Certification Authority and Online Responder to configure.

Select Enterprise CA.  If you don't have the right edition of Windows Server, this option will be grayed out.

Next, select subordinate CA.

Create a new key.

Select your cryptography options.  I went with all the same options as before.  You can lower the strength if resources are at a premium.

 Here we'll name the CA.  Again, this is not the same as the server's hostname.  The defaults are fine.

Here we'll specify that we want to get a certificate from our root CA.  Click the radio button next to Send a certificate request to a parent CA, and then hit the Select button and choose the root CA.

Here's where the data files will live for the CA. The defaults are fine for a lab server.

Confirmation of your settings.

 Finish up the wizard and allow the configuration to take place.

Now, create a file share somewhere on the issue CA.  You'll be copying your cert to this share from the root CA later.  If you need a refresh on creating a share, Technet has you covered.

Finally when it is done configuring, you're ready to bring the issuing CA online.  Go back to the root CA and load the Certification Authority mmc.  In the Pending Requests folder, you'll see the request from the issuing CA.  Right click on this request and select issue.

Now you'll see that the cert has moved from Pending Requests to Issued Certificates.

Right click on it again and export the cert.  Once you have it on the HDD, move it to the file share on the issuing CA. For some reason on mine, it saved with a long random name with .tmp as the extension, but it worked.

Back at the issuing CA, right click on the server name and select All tasks, Import.  If you got a .tmp file as well, you'll have to change file type to All Files in the open dialog box.

You'll notice that there really isn't much difference in the layout and functionality of the CA mmc on the two different operating systems.  When you really dig in, there will be additional features in 2012R2, but other than that it's minimal and cosmetic.

With the certificate installed, you'll finally be able to start up the Certification Authority service.  From the CA mmc, right click on the server and select All tasks, start service.

Now that your issuing CA is up and running, wait through another group policy update cycle (roughly 90 minutes) and then you can shut down your root CA.  

Note that the issuing CA will not appear in the Certification Authorities container in Active directory as the root CA did.  Instead, check the Enrollment Services Container, which contains all CAs for Active Directory, not just the root CA.  For the purpose of this post, verification of the issuing CA is enough, but if you care to know more about the matter, you can find some great information on Technet.  I'll certainly cover more in depth information like this as my work in the lab gets to it.

The last step here is to install and configure the NDES service on the issuing CA, but this post is long enough so I'll save that for another post.