System Overlord

A blog about security engineering, research, and general hacking.

(Virtually) Setting Up A Test Lab (Part 1)

30 Oct 2011 in Linux (Reading time: 2 minute)

I've spent a little bit of time today doing something that was long overdue.  I've transitioned most of my day-to-day data to my laptop, so I decided it was time to put my desktop to use as a "virtual lab."

I've set up KVM on my desktop with two virtual machines (so far) in it.  The first one I call "LabManager" -- it's effectively a head node from the "Lab" network out to the real world.

Currently, LabManager has two interfaces -- one of them is bridged to eth0 on the desktop, and the other is only bridged to other VMs.  The other VMs have no direct connectivity.  At this time, LabManager is not forwarding packets, bridging, or routing.  It is running dnsmasq for DNS & DHCP and apt-cacher-ng to allow systems behind it to download packages.  Additionally, LabManager is running a tftp server to perform PXE boot installs.  These installs use a preseed file so the only manual entry is a hostname.  Everything else is automatically setup.

It's my hope that keeping the networks segregated will let me play around with "dangerous" things without posing any risk to my real home network (or the internet).  The use of RFC 1918 IPs and restrictive firewalls should help with this.  I've got the preseed installing puppet, but I haven't set up the puppetmaster yet.  That'll be the 2nd phase, which I'll hopefully get around to by next weekend.

Phase 3 will be providing distributions other than Debian stable via PXE boot.  I'd like to provide both some bleeding-edge work and some older software for pentesting practice.

Suggestions for improvement are welcome!

KSU Cyber Security Awareness Day 2011

26 Oct 2011 in Security (Reading time: 3 minutes)

Today was the KSU Cyber Security Awareness Day, presented by KSU's Information Technology Services (a sister department to the department I work in), and it was a resounding success!  There were several presentations that had standing-room only attendance, and for good reason.

My personal favorites:

Mike Rothman from Securosis on finding happiness in information security.  Mike's presentation was as much about being happy in your job and in your life as it was about cyber security, but he asked a number of very pointed questions.  Questions about pay/salary, job satisfaction, and life priorities.  I found the questions unsettling, not because of the actual question, but because I realized that I'd been subconsciously thinking those same things for quite a while now.  The take away from his presentation can probably be summed up as "Is what you're doing today getting you where you want to go?"

Rob Ragan of Stach & Liu came to talk about "Google hacking" and the Diggity tool he's put together.  Rob presented a number of very revealing things that can be found just by performing searches on the common search engines, and a number of people in the audience were disturbed to find out how information can be (mis-)handled.  At one point, Rob stated he had run a search on Kennesaw's web presence and found about 11,000 possible pieces of sensitive information.  It was mildly amusing to see the reaction of the members of our ISO until it was realized that he had searched on "ksu.edu" and not "kennesaw.edu".  I hope K-State is aware of the 11,000 possible hits.

Chris Sandy of our own ITS Information Security Office actually presented twice.  One presentation (that I rather enjoyed) was used as filler due to a last-minute cancellation.  Chris talked about the physical aspects of information security, but particularly about physical locks and lockpicking.  I had no idea KSU had a sport lockpicker on campus -- it makes me even more interested in picking up lockpicking, as a sport.

Overall, it was a great one-day event, and I hope that it helped open the eyes of the students, faculty, and staff attending the session.  I know our InfoSec guys worked really hard to put it together, and I think that did an outstanding job.  Having done conference planning before, I know its no easy task, but they pulled it off quite well.

Things I Wish Undergrad Had Taught Me

24 Oct 2011 in Personal (Reading time: 6 minutes)

This is not an attempt to knock any particular program, professor, or course of study.  It's just some things that I think should be included in an undergrad CS program that I don't feel like I got.

  1. Serious study of data structures and algorithms.  While I know how to implement a linked list, structs, classes, vectors, and other data structures, not a whole lot was said about the best use cases for each.  That's something I've had to discover on my own.  And the most complex tree we discussed was the Binary tree.  We never talked about balanced binary trees, red-black trees, or generic n-ary trees.  Although I was taught the general idea behind Djikstra's algorithm, and can tell you the big-O runtime for about a half-dozen sorts, practice implementing them and discussion of their comparative strengths and weaknesses is not something I remember from my undergrad.  Also, there was NO discussion of time-memory tradeoffs involved in implementing some of the algorithms.  In fact, (and I'm embarassed to admit this) I only recently found out about the in-place implementation of quicksort!
  2. How to find your focus.  If there's ever been a real-world example of an NP-complete problem, it's finding your niche.  I'm still searching, and as I get into more things, I'm finding more interests than I am able to exclude.  IT/Computers/Technology is a massive field and even narrowing it a little is hard.  About the only things I've narrowed down are that I don't want to do end-user support, that I don't want to manage people, and that I want to work with/develop Open Source.  Oh, and that I like not doing the same thing every day.  (As it is, my current job is getting on the monotonous end of things.)  I hope I'll find my focus before its too late.
  3. How to develop with others.  This is a skill I've developed over the past few years of the "real world", but I'm not sure everyone I've worked with has gotten it down.  There were too few group projects in my undergrad, and those that I had were comparatively small.  We never had the big software engineering problems, and never really had to develop good APIs for others to depend on.  The division of work never seemed to be "you do the UI, I'll do the database components, and he'll do the business logic."  It was always "you do the UML diagram, I'll do all the code, and you do the final report."  That's not how it works in the real world (ok, well, sometimes it is, but it's not how its supposed to work).
  4. How to effectively use source code management.  Using SCM is critical to any serious development.  Not once in my entire undergrad career was that discussed.  No mention of any SCM.  While my experience in open source had led to me using and understanding SCM, I can say that I've seen how well prepared others are to use it -- and it's pretty scary.
  5. How to do requirements definitions and other software engineering tasks.  When I started my undergrad, there weren't really any dedicated software engineering programs -- everyone did CS or IS.  In the CS side of things, there was one software engineering class.  You can't learn to estimate time, do requirements definitions, manage deliverables, and all the other tasks that go into a software lifecycle in one class.  While I realize not every CS student will end up doing software engineering, the software engineering class should be early in the program (in my program, it was nearly at the end) and those concepts should be incorporated into every major project you do for the rest of your degree.  You've gotta do things more than once to really understand it.
  6. How to do dev/test/prod.  Much like #5, the words "unit testing" never came up in my undergrad program.  There also wasn't really any discussion of maintaining existing software, and of the different environments.  I knew about them, but not from my undergrad, and I've had to learn a lot about them "on my feet."  I'm still trying to get some of our practices at my job into this lifecycle in a sane manner, but it turns out: doing things the right way requires more work up front.  It'll save you in the long run, but it's hard to get that initial investment when it looks cheaper to "fix things later."  (It's not, by the way.  Doing it right the first time is always cheaper.)

I'm still learning a lot -- but if you're not learning, you're stagnant.  There are just some things that make you slap your forehead when you realize how nice it would have been to know those skills 5 years ago.

A Hard Lesson Learned

17 Oct 2011 in Work (Reading time: 4 minutes)

For a few months now, I've been working on a side project for a local girl's volleyball club.  While the people I'm working with are very nice, this whole project has been a lesson in how bad of a businessman/project manager I am.  I'm struggling with whether this is a sign I should stop taking on these side projects, or if its a sign that I really need to pay more attention to the business side of things.  If nothing else, I hope this will serve as a warning to others on what not to do.

Lesson One: It's Going to Take Longer Than You Think

No matter how much time you think it's going to take, you're likely underestimating it.  When I first got involved in this project, I expected it to be about 100 hours of work.  I stopped counting the actual hours invested on this project at 200 because it just got to be too much to think about.  There are components to this project that are similar to, but not exactly the same as, tasks I had completed before.  However, these tasks turned out to be far more involved than I had anticipated, and so my initial estimates were quite a bit off.

Lesson Two: Have a Detailed Statement of Work

At some point, there's going to be a difference in interpretation of some part of the project design.  No specification can be so complete as to eliminate every possible point of contention.  However, the more detailed the original statement of work is, the smaller these issues should be.  Having a very detailed statement of work allows both parties involved to have a clear understanding of what is expected, and prevents the last minute "it was supposed to..." statements.

Lesson Three: Have a Contract

I'm not saying you need some behemoth document that requires a $150/hr lawyer to understand, but there needs to be a legally binding document that includes when you will deliver the work, in what format, how much you will be paid, and when you will receive payments.  Having this makes sure there's no surprises for either party involved -- you know your deadlines and when and how much you will be paid.  The customer knows when they will receive what they're paying for and how much that is.

Lesson Four: Have a Change Request Process

There will be changes during the development or delivery process.  It's going to happen, and you can't change that.  What you can have is a process to deal with it.  The customer needs to know what costs they're incurring by asking for changes and whether or not the changes will affect the delivery date.  You need to build a revised detailed spec with the new changes in it.

The Bottom Line

I hate paperwork, meetings, and managing.  However, it turns out that, to an extent, those may fit in the category of "necessary evils."  If you read through the list of lessons above, you can probably imagine the mistakes I feel I've made on this project.  I've unfortunately lost quite a bit to this project, including most of my weekends for the past 3 months and a LOT of sleep.  Hopefully, I'll learn how to do things the right way -- and maybe you won't have to learn this lesson the hard way!

What I learned from Steve Jobs

05 Oct 2011 in Computer (Reading time: 3 minutes)

Unless you've just awoken from a coma, you're probably well aware that Steve Jobs passed away a few hours ago.  It might be the very first time that the death of a "celebrity" has saddned me.  Steve was more than a celebrity, he was visionary like none other.

Steve had a vision that was unmatched by anyone else, even his Apple cofounder Steve Wozniak.  The Woz and I are much more on the same wavelength -- fascinated by the technology, fascinated by doing things just to see them done.  Jobs, on the other hand, saw the bigger picture instantly.  He saw how the technology would change the world, and he got there first (most of the time).  Lesson one: See the big picture.  Even if you don't control the big picture, see how your part fits into the big picture, and make it better.

Steve had many successes, but he wasn't infallible.  He worked a number of menial jobs in college, and got fired from several of them.  The Apple Lisa left a lot to be desired, both in technology and in sales.  He was fired from the company he cofounded.  Did he give up, or decide he shouldn't be in the business?  No.  Steve picked himself up, and showed people that they were wrong about him.  Lesson two: Fail.  Learn from failure.  Repeat until you succeed.  (A corollary lesson: being told you can't do something should make you want to do it even more.)

The biggest thing I've learned from the life of Steve Jobs came about just tonight.  No matter how rich you are, how popular you are, how smart you are, no matter what you've done in your life, it comes to an end entirely too soon.  Steve didn't wait for things to come to him, he made things happen for himself.  Time and time again, he did things.  Lesson three: We all die, and for many it's entirely too soon.  So get out there and do things.  Make your obituary interesting.

RIP, Steve.  You were a pillar of the technology industry.  You will be missed.