- Student Experience
Our Student Stories are a special collection of experiences and thoughts from the students themselves. Check out what our student employees find exciting and worth taking some time to tell you about.
On April 28th, 2018, the OSL participated in the Corvallis Maker Fair for the second year in a row. We hosted 2 booths, the first had demos of programs in Python and Scratch, and the second had a HAProxy cluster with diskless nodes, which was built and deployed by OSL student JJ Frederick.
Attendees learned about the basics of programming by modifying the source code of the demoed programs to see how it changed the programs, learned about DevOps basics and saw how easy it was to add their laptops to the cluster as a diskless node, and also gained an appreciation of open source software.
I took part in a Cyber Defense Competition hosted by the Department of Energy, and it was a fantastic experience! Our team worked hard to ensure that we had a fighting chance at the competition, and we had much needed help from our mentor.
The competition took place in a control center. One wall covered in flat screen TVs to create a huge monitor and the other was lined with windows into the room where the Red Team worked. There was a table for each of the 6 teams, and on each table was a small model of a natural gas extractor with two little houses around it. This little model simulated a power plant -- the thing we would be defending against cyber attacks.
A team of normal users, known as the Green Team, needed to access the interface for this system and we had to stop any malicious actors from accessing it.
The competition simulated a power plant defense scenario where a team of hackers would try to disrupt a town's power supply. We were given three Linux virtual machines to use that were laden with backdoors and vulnerabilities. I was responsible for removing the backdoors on those virtual machines as well as setting up LDAP logins for those hosts. Unfortunately our LDAP users were in an Active Directory instance, so I needed to interface Kerberos with Active directory to allow logins through LDAP. Despite my many attempts at configuring Kerberos I kept running into the enigmatic "su: system error". In hindsight I should have investigated "su", but I had my blinders on trying to get LDAP to work. Besides configuring LDAP, I removed a couple webservers that were running backdoor services and locked down some service accounts that had way too many permissions.
The final network layout consisted of 8 virtual machines: one web server, one MySQL/FTP server, one HMI access server, two Windows DNS/Active Directory servers, two honey pots, and one access server. Ssh access to the first three servers was limited so that only the access server could connect to them via ssh.
The most exciting thing happened when our teammate Aiden had to literally fight off a Red Team member through the user interface for our extractor. Red Team kept turning off the extractor, so Aiden turned it back on. Once Red Team knew we were watching, they opened up a bunch of windows to keep us from turning the machine back on. We frantically threw a firewall into place to block them while we reconfigured the controller for our extractor.
When we were nearing the end of the competition the Red Team taunted all the Blue Teams by playing Disco Inferno and burning out the motors of all the extractors that were compromised.
By the end we were in 2nd or 3rd place nationally before the final scoring. Once the final score had been released we were surprised to see that other school had risen so much that we were in fourth nationally, but we were definitely pleased to see that we had won first at our location. All in all it was a rewarding experience that I wish I could do again this coming fall, but that is another story all to itself.
At the OSL we use Packer to build our images, because of the reproducible and easy work-flow it allows. We can create an entire operating system image based off a Linux distribution without any interaction! With this we are looking to add much more complete and automated testing.
To help with this we have decided to create a Github repository called Packer Templates. This is what the OSL will be using to generate OpenStack operating system images that many of our hosted projects use. We have been hard at work making this a reality for around 2 months and counting, and we still have a lot of work to do!
In order to get any Linux distribution to install automatically, you have to use their version of automated installation. They all have different names and syntax, but generally all follow the same pattern:
Because we are using packer with QEMU (Virtual Machine software), even step #1 can be automated through VNC, meaning you just run the program and it does everything for you! One of the major reasons we made this into a Github repository is so we can take this a step further: automated testing. Each time we make a pull request with some changes to the installation scripts, we have Jenkins build the system images, then test them to make sure they work. We don't have to worry about some change in a script breaking an unrelated system, and we don't introduce bugs through adding features!
Programming languages are a touchy topic in Computer Science. In certain crowds even mentioning a language will elicit groans and eye-rolling. Conversely, there are crowds that will only use certain languages for all projects.
These people have lost sight of the fact that programming languages are tools. Languages have certain problem sets that they're really good at and some not so much. If you were to ask me to do some complex math or signal processing, I would point you to MATLAB. Would I use MATLAB for developing a GUI? Not in a million years. So why do we choose C? Well, C is efficient since it's practically one step above assembly and with a modern compiler it compiles down to a small executable. Plus modern compilers have extremely good optimization algorithms that can optimize your program better than if you wrote it by hand in Assembly. This makes C a great tool for embedded programming and systems level programming, which is why we have been using it for so long in these fields! However, a downside (and upside!) of C is that it's like assembly. It will let you do whatever you want, even if that means shooting yourself in the foot. There is no type safety, there is no memory protection, and no thread safety built into the language. You have to do all of that yourself with mutexes, semaphores, and checks. It's good to know about these concepts and be able to design a system that puts these protections in place, but every project should not be an exercise in memory management and complex concurrency. We should move on to tools that help you rather than give you enough rope to hang yourself with. With computers being as important as they are, security should be our number one priority when writing software. If you're writing an application that does an unbounded copy from input (ex. heartbleed) in your final release, you just added another vector of attack to someone's computer.
We should be writing code that is safe and avoids all sorts of memory issues that can be solved by using the right tools. Writing C is cool because it's freeing, but I think we should move to bigger and better tools that save us from our own stupid mistakes and hit us over the head with them.
As for embedded programming, there are other options out there that maybe won't be as small as C, but will make your device more secure. (Insert plug for Rust here)
As of September 8th, my time here at OSU will officially come to an end. As sad as I'll be to leave my life here in Corvallis and as nervewracking it is to enter the real world, I realized recently I've spent the last seventeen years of my life in school and I'm ready to break free!
I'll be leaving with both a degree in English and in music performance, both of which have taught me so much not just about their respective fields, but about growing up and how to work with what you've got.
While I did not have the skills or the privilage to be a student developer or systems administrator, I feel that my time here at the OSL has been incredibly valuable. I've learned so much here that I would never have gained from a class. The challenges I've faced and the experiences I've had taught me diligence, patience, and flexibility. I firmly believe that my time here at the OSL has shaped me into a person who is unafraid and excited to leave college.
I'm more than ready to start my new life, but I will miss the friends I've made and the life I've created here at OSU. The best of luck to my peers and go beavs!
OSU Open Source Lab
224 Milne Computer Center
1800 SW Campus Way
Corvallis, OR 97331