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. 

Building the Root CA

In the lab, a single Windows Server running Active Directory and Active Directory Certificate Services.  But if you haven't figured out yet, I am a big fan of overkill and never do anything only to the level of minimum required.  I always like to do everything bigger and better, as there will be additional opportunities to learn that way.  I'm using The 70-640 Self-Paced Training Kit as a guide, one of the two books that I used years ago when I was studying for the MCSA 2008.  I actually liked the Pearson book by Don Poulton better, but the Microsoft Press book is sufficient, even if it is a bit thin in the details.

In a previous post, I created a domain with the name firewallninja.info on a server with Windows Server 2016 Technical Preview 4.  Today we'll continue building out the security lab by adding the first of a 2 tier CA hierarchy, the root CA.  I have previously built a VM with Server 2008R2, configured its hostname and IPv4 settings, and added it to the firewallninja.info domain.  If you need a refresher on adding a new server to your domain, here is a guide for Server 2003 and 2008 and here is a guide for Server 2012R2.  For the root CA, Windows Server 2008R2 Standard, Enterprise or Datacenter Edition can be used.

I selected to go with Server 2008R2 rather than going 2012R2 for both CAs for a couple of reasons.   First, when I had an MSDN account though school years back, I build a large volume of Server 2008R2 VMs and haven't used even a fraction of them yet.  And I probably won't, seeing as most of the labbing I do is on Server 2012R2 at this point.  This is a root CA that is going to be powered down and I'll probably never see it again, so why not.  Second, there are a few slight differences when working with 2008R2 and 2012R2, so I wanted to run through it on both for the sake of exposure.  Server 2008R2 is still out there, probably still in higher numbers than 2012R2 at this point.  I don't recall the root CA requiring any specific version of Windows Server to use the latest/greatest features on the issuing CA, so Server 2000 or 2003, or even Linux with OpenSSL may be sufficient as well.

So let's get started on the root CA.  Log into the server with an administrator account.  A local admin account is sufficient, but you can use a domain admin account as well.  Let the Server Manager load as that's the tool we'll be using.

On the left pane of Server Manager, find Roles and click on it.  On my server, nothing has been installed yet, so the box is blank and says 0 of 17.   Click on Add roles on the right.

Next, select Active Directory Certificate Services.  If you want to add any other server roles, you can select them as well.

Once you have selected Active Directory Certificate Services, you'll see the box change to include options for the role, or roles, that you have selected.

For this server, I'm only going to install Certificate Authority.  The others will be used on the issuing CA later.

Next, I'm going to select Standalone.  The difference is beyond the scope of this post, but you can read more about this at Technet, if you're interested.

Here I'm going to select Root CA.

Next, I'm going to have the server create a new private key.  Since this is a new setup, I don't have an existing key to give it.  If you were replacing a server that died and are fortunate enough to have the private key from that server, you can import it here.  Another reason why you would import a certificate here would be if you purchased one from a 3rd party CA such as GoDaddy.

I'm going to keep the default 2048 bit key, and I'm going to use SHA256.  Modern web browsers are either flat out dropping support for SHA1, or making it difficult to enable, so you should be thinking about that when configuring cryptography in your CAs.  The last option on the page, "Allow administrator interaction when the private key is accessed by the CA" is an additional security control that requires an admin user to interact with the CA.

Next, we'll choose the distinguished name for this CA.  This is not the same as the server's hostname, but can be.

I'm changing the lifetime of the certificate to 20 years.  This is a lab, and I don't want to have to worry about my cert expiring and then finding that the root CA that's been offline for 5 years doesn't want to boot up.  With any luck, I won't still be using this domain in 20 years.

Give the location on the filesystem for the CA data.  Like the AD data, the defaults are fine in the lab, but you'll want to spread the love around multiple spindles if possible in production.

Review your choices here, or don't, and then click Install.

Go grab a cup of coffee and/or a snack. This takes a few minutes, especially in a VM.

Finally, everything is installed and we're ready to go.

Back at the Server Manager, you can view the results of the installation.  For instance, in the events, you should see event 103 which indicates that your CA name has been added to the Certificate Authorities container in Active Directory.

After the next group policy cycle, you can move on to the issuing CA.  Now if we go back to the domain controller and dig down in ADSIEdit, we can see the root CA in the Active Directory schema.  The root CA can go offline once the issuing CA has its cert.

With the root server in AD and powered down, we will only ever need it again at such time that we need to generate a new root certificate.  Next up, the issuing CA.

Shortening ACLs

There are two main ways of shortening ACLs and improving their readability or performance. As you know, ACLs can grow to include hundreds of ACEs and cover many pages when printed.  So any way of minimizing the number of ACEs present may be welcomed.   A shorter ACL will consume less flash memory in the form of the startup configuration, less RAM in the form of the running configuration, and less CPU utilization when a packet is eligible to be analyzed by the ACL.

The first method of shortening an ACL is by using CIDR to combine multiple ACEs into a single statement. This method is useful when combining multiple ACEs specifying networks. For example, if you have two statements in an ACL which allow 10.0.0.0/8 and 11.0.0.0/8 as such:

     access-list 1 permit 10.0.0.0 0.255.255.255
     access-list 1 permit 11.0.0.0 0.255.255.255

These two statements can be combined into the single statement 10.0.0.0/7 as such:

     access-list 1 permit 10.0.0.0 1.255.255.255

Anyone who has worked with routers and routing protocols will recognize this method as summarization.  In a properly designed network, multiple networks can be combined, or summarized, into a smaller number of networks for use in ACLs and other purposes such as routing protocols/routing tables. You ultimately strive to be able to summarize down to one network wherever you can.

The second method of reducing the size of ACLs falls into the category of what I would call stupid router tricks. It is accomplished by utilizing binary math to combine two statements into one. This method is useful when combining ACEs that specify individual hosts.  To use this method, first convert the two host addresses into binary.   Second, do a bitwise AND of these two binary numbers. The result of this AND operation will be used and the address of the combined ACE. Next, do a bitwise XOR of the original two binary numbers. This output of this operation will be used as the wildcard mask of the new combined ACE. For example, if an ACL contained the following statements:

     access-list 10 deny host 10.20.30.40
     access-list 10 deny host 40.30.20.10

The result of this operation would yield

     access-list 10 deny 8.20.20.8 34.0.10.34

While this operation results in ACLs whose meaning is not clear, reducing the number of deny or permit statements in half definitely helps in a routers memory, flash, and CPU utilization. 

Would you be interested in a long ACL with dozens of cryptic statements such as the above?

Would Anyone Like to Take a Survey?

I'm looking for a little help for a research project. There are three sections to the survey, and I need answers for all three. You shouldn't spend even 5 minutes. I'll share the results of the study once the data has been analyzed

This study investigates the relationship between emotional intelligence and computer anxiety. In addition, this the study will further explore the extent that age moderates this relationship.

https://www.surveymonkey.com/r/VNDRXQF

Buyer Beware

While looking over the profiles of people sending me friend requests on Facebook (if I've never said two words to you before, don't bother) I came across this page Cisco Training Online which is selling CCIE bootcamps.  Just for the heck of it, I scrolled down the page.  Besides the ads for their bootcamps, one image jumped out at me. It was labeled TCP/UDP Port Numbers, and it had a very familiar theme to it.  Yes, it is one of PacketLife's cheat sheets, but with the copyright information conveniently chopped off.

So out of curiosity, I kept scrolling down the page. Everything that was text, I put into Google.  I found material copied directly from networklessons.com, material copied from a very old Cisco Press book, and material from other blogs.  They're charging money I'm sure, but have they created any original content at all?   Yes, I commented on the above post, and I commented on many others as well.  I doubt my posts will still be there by the time you see this.

If you don't stick with the well known training companies (I think it's safe to say Narbik Kocharians and Keith Barker aren't stealing content), then be sure to investigate what you're paying for.  Don't pay someone to give you material that is not theirs.  And more important, don't pay someone to give you material that is freely available on the Internet.  A web browser can do that for you free of charge.

Setting up the 2511 Part 2

There is one more feature of the Cisco access servers that I do not see mentioned very often. Maybe it's been talked to death and I just missed it. But either way, I think is hugely important. That is the ability to telnet through it to the connected devices without ever actually appearing to touch the access server itself. In this post, I'll go over that briefly.

To recap, in the previous post, which can be found here, I set up the 2511 on my network with an address of 192.168.10.10/24 on the Ethernet interface and 192.168.254.1/24 on Loopback0. Connected to line 1 is a 2611 router with no connection to the local network. There is a serial connection between term1 and r1, but I have not really done anything with it.

To prepare for this setup, the local network needs to know how to reach the loopback interface of the terminal server. There are a couple of ways you can do this. You can set up a routing protocol between the terminal server and your home router (we are studying Cisco networking here right? So why not?), you can put a static route into you computer

route add 192.168.254.0 mask 255.255.255.0 192.168.10.10 /p

or you can put a static route into your home router. I have done all three of these at one time or another, and they all work fine. This time around, I elected to put a static route into my SonicWall (counting down the days until I can replace this piece) because it is the simplest way to achieve network connectivity from my entire network. With this static route in place, I can see from the output of a ping to 192.168.254.1 on my computer, it receives a ICMP redirect from the SonicWall, and then the pings are successful.

Now that the loopback on the terminal server is reachable from your PC, lets experiment and see how things work. First, I'll telnet directly into the terminal server as usual, and it still works as expected.

linux1> telnet 192.168.10.10 Trying 192.168.10.10... Connected to 192.168.10.10. Escape character is '^]'. User Access Verification Password: term1>

So what happens when we telnet to the IP address of the loopback interface?

linux1> telnet 192.168.254.1 Trying 192.168.254.1... Connected to 192.168.254.1. Escape character is '^]'. User Access Verification Password: term1>

Again, this is what I expected to happen. So now let's acutally use this terminal server for what it is. Let's telnet into it on a different port and see what happens.

linux1> telnet 192.168.254.1 2001 Trying 192.168.254.1... Connected to 192.168.254.1. Escape character is '^]'. r1>

Notice how this time we essentially connected to the console port of r1. The one thing to take note of is when you hit exit, you are not returned to the command prompt of your host OS, instead, it shows console port behavior.

r1 con0 is now available Press RETURN to get started.

And of course, hitting enter at this point drops you back at the r1> prompt. I'm not quite sure how I feel about this behavior yet, it's going to take a little getting used to.

Setting up the Cisco 2511

Racked up in my lab, I have more routers, switches, firewalls and access points than I care to count.  These devices are all in the basement, which is a place I don't necessarily want to set up shop when I'm labbing due do a number of reasons such as the temperature and the constant hum of the dehumidifier.  So when I'm upstairs, any oopsie that causes loss of connectivity would require another trip down the stairs.

So what to do?  That's where my trusty Cisco 2511 comes in. This device, like many other devices in my rack, was rescued from the recycling pile at work and is becoming one of my favorite items. The only complaint that I have so far is the slow speed of the device. It's a 2500, so everything from the boot time to even just logging in is way slower than a modern router. Since I'll be using a number of these devices shortly, I'm going to set up the 2511 now.

The Cisco 2509/2511/2512 router is what is known as a terminal server. This 2511 that I have has what appear to be two 68 pin SCSI connectors that are used to plug in Cisco's proprietary octal cables. These octal cables give you 8 RJ45 connectors to plug into the console ports of your other devices, making these console ports all accessible from the 2511, and therefore from anywhere that the 2511 can be reached. This would include my laptop while I sit on the couch in my living room, or anywhere else in the house that isn't the basement. The 2509 is the same as the 2511 except for the fact that it only has one 68 pin connector so it can therefore only connect to 8 devices. And then there is the 2509-RJ and 2511-RJ, which do not have the connectors for the octal cables, but instead have RJ45 jacks for use with rollover cables. Finally, there is the 2512, which is the same as a 2511 except for the fact that it has a DB9 Token Ring interface in place of the AUI Ethernet interface. If you don't want to put your faith into something as old as a 2500 series router (they were introduced in 1994 after all), there is also the NM-32A which contains 4 of these connectors and can be used in pretty much any router with an NM port.

So let's get started with the 2511. I've powered up the 2511 and an additional router connected to the first port of the octal cable. The AUI Port has an Ethernet transceiver connected to it ($5 or so on eBay), and this transceiver is connected to my switch with a standard Ethernet cable. This gives me a staggering 10Mbps half-duplex connection over the network. On my octal cables, there is a yellow plastic band near the RJ45 jack with numbers from 1 - 8, indicating which one is which. Since these two octal cables that I have are the only two that I've seen, I cannot confirm whether or not this is standard. The second router, a 2611, doesn't really have any configuration on it except for setting a host name for convenience in identification when it comes time to switch back and forth between the two devices.
The first thing we want to figure out is the line numbers that will be used by the connections. The command show line will give you this information.

term1#show line Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 0 CTY - - - - - 0 0 0/0 - * 1 TTY 9600/9600 - - - - - 1 0 0/0 - 2 TTY 9600/9600 - - - - - 0 0 0/0 - 3 TTY 9600/9600 - - - - - 0 0 0/0 - 4 TTY 9600/9600 - - - - - 0 0 0/0 - 5 TTY 9600/9600 - - - - - 0 0 0/0 - 6 TTY 9600/9600 - - - - - 0 0 0/0 - 7 TTY 9600/9600 - - - - - 0 0 0/0 - 8 TTY 9600/9600 - - - - - 0 0 0/0 - 9 TTY 9600/9600 - - - - - 0 0 0/0 - 10 TTY 9600/9600 - - - - - 0 0 0/0 - 11 TTY 9600/9600 - - - - - 0 0 0/0 - 12 TTY 9600/9600 - - - - - 0 0 0/0 - 13 TTY 9600/9600 - - - - - 0 0 0/0 - 14 TTY 9600/9600 - - - - - 0 0 0/0 - 15 TTY 9600/9600 - - - - - 0 0 0/0 - 16 TTY 9600/9600 - - - - - 0 0 0/0 - 17 AUX 9600/9600 - - - - - 0 1 0/0 - * 18 VTY - - - - - 2 0 0/0 - * 19 VTY - - - - - 1 0 0/0 - 20 VTY - - - - - 0 0 0/0 - 21 VTY - - - - - 0 0 0/0 - 22 VTY - - - - - 0 0 0/0 -

Please excuse the formatting, I'm a networking guy not a web developer.

The TTY lines are what we're looking for here, and you'll see that on my router, they're conveniently numbered 1 - 16. Your mileage may vary if you're using an NM-32A and depending on which NM slot it's installed into. Note that in the column "Uses" you'll see a 1 for the first TTY line rather than a 0 as every other line has. The first TTY line is the one connected to my 2611 router.

Next I'll put a basic configuration on the device. I want it accessable on the network, and easily distinguished from the other router. And since this is my lab and not a production network, I'm looking for convenience rather than security here. Don't forget to set an enable password, otherwise it'll squawk that no password is set when you type enable. The IOS I have installed doesn't support SSH at all, so that will need to be addressed at some point.

Router(config)hostname term1 term1(config)enable secret 123 term1(config)interface Ethernet0 term1(config-if)ip address 192.168.10.10 255.255.255.0 term1(config-if)no keepalive term1(config-if)exit term1(config)line vty 0 4 term1(config-line) exec-timeout 0 0 term1(config-line)password 123 term1(config-line)login

Next, let's configure the the lines for reverse telnet. Cisco says "Reverse Telnet allows you to establish a Telnet connection out on the same device you telnet from, but on a different interface. For more information on Reverse Telnet refer to Managing Telnet Sessions.

term1(config)#line 1 16 term1(config-line)#transport input telnet term1(config-line)#no exec term1(config-line)#exec-timeout 0 0

We'll need a loopback interface with a usable IP address for reverse telnet purposes, and then we'll set up our devices. Starting with port 2001, the port numbers indicate which line that device is connected to. Where you see r1, r2, etc. are just the names I'll be using for these devices, name them as you wish though I highly suggest the names here match the hostnames of the devices. And finally, the IP address of the loopback.

term1(config)#int lo0 term1(config-if) ip add 192.168.254.1 255.255.255.0 term1(config-if) exit term1(config)host r1 2001 192.168.254.1 term1(config)host r2 2002 192.168.254.1 term1(config)host r3 2003 192.168.254.1 term1(config)host r4 2004 192.168.254.1 term1(config)host r5 2005 192.168.254.1 term1(config)host r6 2006 192.168.254.1 term1(config)host sw1 2007 192.168.254.1 term1(config)host sw2 2008 192.168.254.1

Now that this is all set up, we can attempt to connect to r1. Simply type in the host name you've assigned to the device and it should connect momentarily.

term1#r1 Trying r1 (192.168.254.1, 2001)... Open r1>

Note the prompt showing that we are indeed connected to r1. At any time, you can press the escape sequence of Ctrl + Shift + 6 and then X in order to return back to the terminal server.

Once back at the terminal server, you can use the command show sessions to see the open sessions.

term1#show sessions Conn Host Address Byte Idle Conn Name * 1 r1 192.168.254.1 0 0 r1

You can type 1 to return to the open session for r1, or you can type clear line 1 or disconnect session 1 in order to close the session.

term1#clear line 1 [confirm] [OK] term1# [Resuming connection 1 to r1 ... ] [Connection to r1 closed by foreign host] term1#

Also note that besides the otcal cables, the 25xx access server is otherwise a functional 2500 series router, running up to IOS 12.3. The 2511 and 2512 have 2 syncronous serial ports, and the 2509 has one. They support all the same routing protocols and features as any other 2500 series router, so they can pull double duty as a backbone router in your topology. A lot of rack rentals do exactly this. So all in all, a rather useful device.

Should I exceed the 16 devices that I can manage through the 2511 (which I'm sure that I will eventually), I also have a couple Digi PortServer II 16-port terminal servers which I'll probably do a post on in the future.

ASA Liscense Woes

This evening I was tasked with installing a PAK on an ASA 5512-X for a client.  Sales forwarded me the eDelivery Order Notification without event, I grabbed the serial number from the output of the "show version" command, and with a click on "Register Claim Certificates (PAKs)" within the email.  I already had this handy guide from one of my favorite blogs loaded up in my browser and figured I would be done in no time.

So where does the woe come in?  On the Cisco licensing page.  After clicking the link and then logging into the Cisco site, I was brought to the licensing page.  I selected the only outstanding item showing (the recently purchased license upgrade for the 5512-X), and clicked Proceed.  On the next page, it asked for the serial number of the unit.  As I had that handy already, I copied it and pasted it into the box.  Proceed remained grayed out.

After rereading the email, the output of show version and Pete's guide a couple more times, I was starting to think maybe the client would have to log in and enter everything into the licensing page under their account. So I tried one more thing before throwing in the towel for the night.  After clicking towards the end of the serial number box to ensure there were no stray spaces at the end, I hit enter for no particular reason. And wouldn't you know, the Proceed button became available, and after one more page, Cisco emailed me the new PAK which the firewall took with no problem.

I still can't complain as the entire process took me about 20 minutes, although well over half of it was spent wondering why the Proceed button was still grayed out.  Moral of the story: if you want me to press enter after I'm done entering something into the box, say so.