Internet Relay Chat (IRC) has been around for a long time now. It’s a protocol for group chat on a client/server network model. What’s important is that it’s the de facto standard for communication among the Grey Hat Group, the cybersecurity interest group I’m in at school.
In my Army days, I actually spent a large portion of my deployment on IRC. I communicated with different units and coordinated missions using mIRC, a proprietary Windows-only client. mIRC is responsible for creating the infamous “trout slap.” At home I was using XChat for a while. It’s cross-platform, it’s (kinda) free, and it was bundled with at least one of my Ubuntu installs. It worked well enough, but it’s become abandonware over the past few years. I then moved to HexChat, a truly free and actively maintained fork of XChat.
All of these clients are functional. I can connect to a server, join a channel with any of the above, and start chatting without a hiccup with any one of them. The problem arises when I invariably shutdown my laptop or it loses network connectivity. We use IRC because we want to be able to talk to each other in real time, and I don’t want to miss a thing. If my IRC client goes offline, then I miss out on the conversation. I also lose operator status on the channels I help maintain. (We don’t have services, not my fault.)
Nowadays I’ve moved my IRC client to a remote server from Amazon Web Services. AWS is a collection of remote computing resources. Since my server is always running, my client is always running. I just connect to the server from wherever I am to jump back into chat. I’m going to run through how to get a free EC2 instance, install a good IRC client, and access it remotely. Read More…
Last weekend I participated in my first Pacific Rim Collegiate Cyber Defense Competition. PRCCDC is an annual two-day event held at Highline Community College. Competing teams representing colleges from Washington, Oregon, and Idaho are charged with maintaining a notional company’s network. The winning team from this regional competition moves on the the National CCDC. University of Washington has won the past six years in a row.
While these student “blue teams” are administrating their networks, various other teams are at work. These teams simulate what can generally be thought of as the worst two days work ever for them. White team is made up of the judges and event coordinators. They created the networks, keep score, and track our performance throughout the weekend. This year saw an orange team who make phone calls to blue teams with variously ridiculous commentary and requests. Most notoriously, red team are the “hackers” who spend the weekend trying to compromise the teams’ systems as best they can.
Scoring was based on five main factors: attacks, incident response, injects, phone calls, and uptime. Successful attacks made by the red team deducted points from a team’s score. Submitting incident responses regained some of these points. Throughout the weekend, tasks and deadlines were delivered to teams as injects. Successful completion of injects earned more points. Team responses to orange team’s phone calls were rated and scored. Finally, the percentage of uptime was weighed into scoring.
A mix of students from our Information Technology and Systems program and from the Grey Hat Group made up our team. Though UWT has traditionally participated in PRCCDC, we did not have a team last year. Thus, only one member of our team had ever been to a CCDC event and most of us had little idea of what to expect. Here is a breakdown of each area of the competition and how the team and myself personally succeeded and failed. Read More…
So I’m starting a blog. This is where I hope to start writing about my experiences as a student and aspiring computer engineer. I have only recently stepped into the world of making and this blog will serve as an outlet for my future (mis)adventures. Here goes.