When it comes to IT, labs are one of the best tools for learning. Unfortunately, many of us tend to follow along, rather than experimenting with different configurations or tools.
I like to divide learning labs into two broad categories:
- Existing Labs. These are the types of labs found in courseware or training material. Anything where you’re supplied with instructions, and possibly answers or working examples.
- Self-Directed labs. These are the lab scenarios we create ourselves, usually to look at a particular technology, tool, or feature. I’ve found myself using these to extend my knowledge or where I’m self-learning without any particular study material to follow.
Well-designed course material will give you labs with clear instructions and a known outcome to reach. The procedure may include purposeful “mistakes” to show you what happens if you miss a step or misconfigure something. If it is from a training course, there is likely an answers section that will show you what you should expect.
Self-directed labs tend to be more ambiguous. You might know the outcome you want to achieve, but not know how to confirm you’ve actually achieved it. The whole lab might be more trial-and-error. Or in many cases, just error.
We’ve Forgotten What Labs Are For
We call them labs, but most of us have forgotten what this means.
If you look up the word laboratory in a dictionary, you might find an answer similar to this: a place to conduct scientific tests, to provide the opportunity for experimentation and observation.
And an experiment is a test to learn or discover something.
Labs Are For Experimentation
When was the last time you experimented in a computer or network lab, just to see what would happen?
In an existing lab, one provided for us, it becomes too convenient to race through it without really paying attention. We type in the commands, show the output, and might vaguely pay attention if the result we have differs from the answers in the lab guide.
A self-directed lab presents more opportunities to learn. We’re not necessarily following a strict set of instructions and there is a good chance that what we’re doing won’t work the first time. We fiddle around with it, trying to make it work, but once it is working enough, we stop.
In both cases, most of us rush through without questioning too much. We’re focused on the outcome, not on what we’re learning.
We need to slow down. To ask questions and try different things out.
I am loathe to use the phrase, but, we need to use a hacker mindset. At its most basic, we can think of this as curiosity, outside-the-box thinking, and tenacity.
Curiosity to ask questions, even if others might find some of them annoying. Like a child repeatedly asking why. How does this work? What happens if I do this? What happens if I do something unexpected? Why on Earth did that happen? What if I configured this wrong on purpose?
And tenacity to keep going, to keep experimenting, and to see what happens.
Once we get to the actual why or how behind something, it makes understanding it a whole lot easier.
Labs Are For Exploration
Labs are also for exploration, but sometimes, that exploration needs a bit of containment.
I’m not a scientist, so when I think about a laboratory, I think about a school science lab. This tends to involve teenagers with access to heavy falling objects, fire, hot liquids, suspicious chemicals, and a scary amount of overconfidence.
We contain all of this within a lab to provide a safe environment for them to experiment with science while limiting the harm they can inflict on the rest of the school. Think of safety barriers and fume hoods.
For our labs, we create environments that are sandboxed away from production environments. This might be separate hardware that is isolated from production networks, or virtualized environments that run on a laptop.
These environments are where we can try things that might be harmful if we try them on live networks or against production hosts. If we break the lab, we can always rebuild it. Or, even better, with virtualization we use snapshots to reduce the hassle of fixing the lab.
Consider the following examples.
In networking, we know that OSPF can have multiple areas and that we always need an area 0 to act as a backbone between different areas. What if we connected two OSPF areas without a backbone, what would happen?
Most material you find will tell you not to do this, and that it won’t work. But what happens when you try it?
Doing something wrong on purpose can throw up all sorts of interesting questions. It broadens our experience and exposes us to issues we’re unlikely to see in production networks. This can help build our troubleshooting skills, skills directly transferrable from the lab to production environments.
Next, let’s look at some security tools, like sqlmap and nmap. There are probably hundreds, if not thousands of examples of how to use these tools. Many will cover the basics. As a beginner, you might think this is all you need, but both of these are powerful tools. They have many options.
What I mean by exploration is that you should take any tool you use and explore all of its functionality. How does it work? What do the various options do? What is it capable of?
The point of this exploration isn’t to memorize the exact command syntax, after all, that’s what the documentation is for.
Instead, when we know what it is capable of, we can start to see how we can combine this one tool with other tools to achieve something neither do by themselves. We may never need to do this, but it might come in handy one day.
Why You Should Keep A Lab Book
I have done so many labs over the years. From training courses and self-study to exam preparation.
One of the things I regret is not keeping a lab book.
Nothing fancy, just a book of notes about the labs I’ve done, perhaps a highlight of what I learned, and observations about any odd behavior I noticed. Maybe notes about how two different protocols interacted, or interesting thoughts that might be useful for the future.
The point is, I didn’t keep one and therefore have lost a bunch of useful insights.
When I started trying CTF events, I kept notes about each task. Simple notes in a text file that I could refer back to in the future.
The broad structure of the notes looks similar to this.
- Event and Task name.
- Task description and what files were included.
- Notes on my investigation. What worked, what didn’t, and what were entirely wrong approaches to the problem.
- The solution, if I found it.
- A reference section for any new tools or techniques I found, with relevant URLs.
As I went through a few different CTF events, there were problems similar to ones I had come across before, and I could refer back to the notes I’d made from previous events to see if they were relevant to the current task.
By referring back to old notes, I could see possible approaches to the current problem. Even if they didn’t work, it gave me a starting point to expand upon, rather than starting from scratch.
In hindsight, I would have chosen a different method, rather than keeping a bunch of text files. Ideally, you want something that will collate your notes together and that has a search feature.
We Learn Via Mistakes And Failures
We learn more when things don’t work, or when we make a mistake or fail. Labs are the perfect place to do that.
It forces us to think harder about the situation. We ask ourselves why it isn’t working, we might question our assumptions, and it might force us into a different approach.
These are all good things to have happen. And if we approach this all with curiosity, it becomes interesting and even exciting. We’re discovering something, and that usually feels good.
Lab work isn’t about succeeding, it isn’t about being right, and it certainly isn’t about being first. It is about learning and discovery. Finding out new answers, even if they’re only new to you. Rediscovering things you’ve forgotten about. It’s about repeating someone else’s experiment to see if you get the same results, or if you can improve upon their method. There is no winning and losing, only adding to your knowledge.
But being human we get caught up in silly human thoughts:
- I failed.
- It didn’t work.
- I’ll look stupid if I ask for help or admit I don’t know what I’m doing.
- This is too hard, I’ll never understand it.
- What if I break the lab and everyone blames me for it?
I can’t remember where I read this, but it made a lot of sense to me at the time:
- Do you think babies give up when they’re learning to walk? Even though they fail a lot.
- Do you think they see other people walking around and decide they’ll never get it, and just give up?
No. Instead, we encourage them to keep trying, again, and again, until eventually, they learn to walk.
This is the mindset we need to encourage. That failure is OK and simply a step on the path to learning.
What Should You Do From Here?
The next time you’re working on a lab, I want you to think hard about what is happening. I want you to explore and dig deeper, to work on understanding what is happening, and why things work the way they do. In short, I want you to be curious about what is going on.
If you’re working on a routing lab that asks you to advertise a network, a successful result might be that a remote router learns the route.
But I want you to ask questions. What does the route look like, what attributes does it have, does it have the metric you expected it to, and does it follow the network path you expected? If you try a traceroute from the remote router to the network you advertised, does it take the correct path?
What do the intermediate routers see? Can you use logging, traceoptions, or debug output to see the actual advertisement? If not, could you do a packet capture to see what is happening “on the wire”?
Next, ask yourself a bunch of what-if questions. What if a link fails? What if a metric is changed? What if you turn a configuration setting on or off?
What if you configure it wrong on purpose?
In short, go beyond the bare minimum and experiment, that’s the whole point of a lab.