Learning the Right Lesson

I finally set a date to take the CCNA.  Actually, it's the part of the CCENT.  So I'm doing the two part CCNA thing.  Anyways, now that I have a date I have a limited time left to learn everything that I could possibly need to pass this thing.

And I'm doing everything different again.

See, success is a bad teacher.  I think I heard that from Bill Gates.

So far, I've had success.  But there were certain places that I had limitations.  Mental gaps in the knowledge.  I should be strong in all the information, not just sections.  But there are sections and specific information that I needed that just wasn't making it into my head in the correct manner.

It's funny.  At one point I was turning my CCENT notes into a book to sell.  That project was abandoned for various reasons.  But the main one being that what did good for the CCENT may not be good for the CCNA.  How can I know?

So I've been using Mnemosyne.  It's a flash card program that allows you to create your own flash cards.  So you end up getting a lot of flash cards that you study.  It seems I heard about flash cards for years, but always avoided them.

I didn't avoid them because they were complicated.

I avoided them because they were work.  I didn't need to work to learn everything.  Until I did.  And the methods I was doing weren't working.  And they didn't work for years.  YEARS.

So now, it's time to quit avoiding work.  Because that's what all this searching has been about.  Avoiding work.  And flash cards are work.

You are what you repeatedly do.

I think Aristotle said that.

Success is a bad teacher.

So if you want success, you must repeatedly do something.  And it's probably going to be work.  And it is going to suck.

And you can either do it now, or spend the rest of your life avoiding the work.

And you will keep ending up in the same scenario: wondering why you only get so far.

You are what you repeatedly do.  Excellence then, is not an act but a habit.
Success is a bad teacher.


Strangeness indeed.

Useful Cisco Commands

Here's a collection of Cisco commands I still haven't been taught by Cisco.  But I learned through various other methods.

terminal monitor
and
term no mon
Terminal monitor is the answer to all remote diagnostic issues.  So when you ssh or telnet into a client, you then get the output you would if you were on site.  The only problem is that output occasionally drives you mad as you try to figure out the solution to a problem.  How in the world do you turn it off?  That's where term no mon comes into play.  It turns off console connections for after they have been turned on with terminal monitor.  Terminal monitor is taught in class.  Term no mon is not.

term len 0
Another terminal command.  The terminal length command tells how many lines of output to display when you hit a key.  But term len 0 has a special use.  Let's say you want to do a quick examination of the entire running config of a site.  How do I do that?

Using Putty, turn on logging.  I'd actually recommend setting logging to default so it logs every piece of output forever. Might be useful when you have other issues.  Next, remote access the system via telnet or ssh.  Next.  term len 0.  You now just set the terminal length to 0, so it will display the entire output without having to press a single key.  Guess what?  No more parsing crud out of text files.  You now have a complete running config stored in the Putty log file that only needs minor parsing.  No more removing typing, input characters, or what not.  Just open the file and remove the login/logout sections.

Next, exit.  Do not save.  No not write.  That way, the next time you log in everything will be just as you found it before.  No weirdness or strangeness.  Otherwise you might have to use term len 10 or something to that effect to put it all back together again.

monitor session 1 source interface interface_name/number
monitor session 1 destination interface interface_name/number
The only pair of commands in my list.  I've only used these commands on switches.  They might work on routers as well.  Not sure.  But here's the great thing about these commands: along with Wireshark, you can kick back and examine all the traffic going through a device in order to try and troubleshoot communication issues.  It's kind of like a programmable hub, but better.  And, you can monitor as few or as many ports as you want.  I'm sure there's limitations to the commands, but like I said, these are things I've learned that classes have never taught me.

So, there you go.  A short collection of Cisco commands that seem to make life easier.  Or get rid of terminal monitor after you start it up.  Hope it helps.

post CCENT

I passed the CCENT.  Grading criteria was between 300 and 1000, and passing was 803.  I scored a 907.  Hooray for me.

The test was copyrighted 2013.  There was a lot of subnetting through out.  Not much IPv6.  There was four question problem on OSPF.  Another was on security settings.  Which reminds me.  I need to test one of the configurations they performed.  Because I think I know the answer, but I don't know if I was correct or not.  

I guess now on to something else.  Back to studying the stuff I've been studying.  I'm currently reading Simple Nature by Benjamin Cromwell.  After that, it's on to Mechanics and then my study of physics takes a temporary break.

Other stuff I'm currently reading include The Book of Five Rings by Miyamoto Musashi.  After that one is finished, it's off to The Hacker Playbook by Peter Kim.

There's an entire list of books after that, but that collection will keep me good for several days.

Remember: people don't grow without intentional effort.

As the world burns...

The world burns.  I study. 

I’m concerned with Dora (Discover, Offer, Request, ACK) the DHCP explorer and her friend Bubu  (broadcast, unicast, broadcast, unicast) and learn on source, forward on destination.    

Open suckiest path first:  Hello, dead beat dad.  Losers suck right?  Losers suck up.  Ack.  (link state packets for OSPF.)

Basic ACL near destination

Extended ACL near source

Deploy access class to limit access to console

Default information-orginate

Ip helper-address

I’ll know Thursday if I pass.  Wish me luck.

Leg Work

I always wanted to write a program that took forever to run just due to the amount of processing it did.  Now, I think I’ve got one. 

Unless I remember to run the thing frequently, it takes about 85 minutes to process through all the files I’ve collected to watch the status of my network.  That’s not pleasant, but it’s working on getting better.  It shouldn’t take as long the next time, as I’ve written in a few checks and balances that prevent it from re-checking every single file over again.  I end up running a “select everything and see if you return nothing” comparison.  Afterwards, I move the folder off to a different directory to archive and eventually clean up that directory.

Which, all of that seems to be working properly.  For the most part.  There are still some issues I need to debug, and some error conditions that need to be solved.  But it’s working better than it did.  The second part is that I’ve finally got it to where it will take multiple input units in the same file, so you don’t have to have multiple scripts logging in every five minutes.  The next part is to start working on NAT table translating and interpretation.  I’m not sure how I want to do that as of yet.  Show ip nat translations gives all the translations, but is that enough information?   What else would I want?

I think that’s the basic problem of all network security people.  You want to gather information, but it begs the question of what the correct amount of information is, and what really needs stored.  And there is always the question of when enough is enough.  

Flipping back through my Cisco book, it looks like I’m going to need show ip nat translations verbose for several different reasons.  The main reason is that is tells when that connection was last used, and that’s vital to proper identification of what has happened.  It provides the “when” and “how long” needed to trace information back to the source.

Show ip nat translations just gives a static view of an event that happened. The connection could have lasted for seconds or it could have lasted for hours.  There is no way to tell.  So the need is to translate the verbose method of the call.  

Where do I go from there?  I don’t know.  At some point I’ve got to figure out how make Apache work the way I want it to.  But that?  That’s another day.

Note: bold notations are specific Cisco commands.  

The next steps

Now that the Routing and Switching class is over, it's time to get ready for the CCENT.  I'm aiming for that in the next month.  I was aiming for two weeks, but I can get a voucher for half-priced testing, so I'm going to go for the voucher.

That being said, let's go back to network security.

I had a AHA! moment last week on network security, and it leads me to believe a very large vendor does not really provide security updates.  They also have some serious problems with their code.  It's all Apache web server, but it's an unpatched version of Apache that still has some serious vulnerabilities.

About a year ago, or maybe a little less, I realized when we replaced a router, all of our internal vulnerability scans started passing.  It was weird.  But I didn't know what it could have been.  Over the past couple of weeks, I've been working on replacing their router with my own.  After breaking our internal vulnerability scanner for a couple of weeks, our vendor finally fixed the device.

About the same time, we ran into a situation where a location suddenly started showing up as failing when it had been passing.  Thinking back, during the intervening period we had upgraded the site and swapped out the equipment.  At that point, we had swapped out a router.  And suddenly the site started failing scans.

Not suddenly, but it seems like it.  So I started thinking about what could have gone wrong during the upgrade.  Everything is built from standard equipment.  The results are pretty predictable and cookie cutter.  So how did this cookie fall out of the cutter mess up?  We'd tried a different configuration with the router, and the site ended up failing internal scans.

So, why did this router fail and other pass?  It's pretty simple: access control lists.  There was an implicit deny on the VLAN with the internal scanner.

Now I know why my scans are all passing.  The door to the scanner is closed.  And the equipment we're dealing with is no way near as secure as we thought.  All because of Apache.

It's also the realization that I can fake a passing scan in less than 30 minutes by simply throwing an ACL in every single router we have.  It'd be easy.  I already know the syntax.  Come to think of it, I could make it highly precise, so it wouldn't be something I could automate.

Anyways.

It just pisses me off that a multi-national company can't patch Apache.  Or, that I have to find the holes in their system.

Now, off to figure out Apache on my own so I can ramp up my network base lining and turn all the data I've collected into something usable.

I should probably write an article on that.   It's basically a combination of Java, mySQL, and some Ubuntu cron jobs.

end of a semester

Routing and Switching is over.   Finished the final with an 85, closed book closed notes.

That should give me an A for the semester.  I need to prepare for the CCENT for the next 2-3 weeks, and then go take that.  Based on the Routing and Switching final, I need to study OSPF more.  I missed more than I would have liked on that.

Scaling Networks is next.   The book is on order.  I spent a few minutes looking through the chapter headings on the final book, and found the PPPOE section.   Yeah.  Book 4, right before the CCNA.

Moving on.   Back to site construction tomorrow, now that finals are complete.   Yay.