Sunday, September 29, 2013

What I Wish I Knew Before Studying Computer Security in College

In twelve short weeks I am going to be graduating from college with a degree in Computer Networking with a focus in Computer Security. Over the past three and a half years, I have studied security in class, become involved in security-related extra-curriculars and in the industry, interned for a combined full year of full-time work at three different companies, and developed countless personal projects. Now that my time in college is almost over, I want to reflect on some of the things I've learned as a student of Computer Security with the hope that some incoming security students can learn from my experiences. If you are currently in the industry or have any other advice, feel free to leave a comment and start a discussion.

Update: There are some great discussions happening over at Hacker News and /r/netsec. Just to clarify some things that people have pointed out in those comments, this post is aimed primarily at new students who are considering this field. Obviously not every aspect is relevant for every person, but I tried to summarize the points most applicable to the largest number of students. Keep the comments coming, though - it's starting a great discussion about the state of security in academia.

Update 2: Thanks to Ünlü Ağyol for translating this post into Turkish. You can read it here.

1. This field is larger than you might think.

When I first started out as a freshman, I thought computer science as a general discipline was huge. There were so many sub-fields and focuses. Now that I've been studying one of those sub-fields, security, for almost four years, it seems huge in its own right. Cryptography, malware, reversing, mobile, forensics, web, mainframe, application, and networking are just a few of the topics in security (and that is barely scratching the surface).

Because of this, you will never learn everything. You will learn concepts and overarching principles along with a few details here and there. But the real experience comes from internships. Jump at internship opportunities the first chance you get. If you have no plans for the summer after freshman year, you are likely going to be behind.

2. You're not going to escape computer science.

The college that I am attending has distinct majors for Computer Security and Computer Networking that are in an entirely different department from Computer Science. Some schools have Computer Science as the major and Security as the minor or concentration. Regardless, I've heard countless peers say that the reason they chose security over computer science was to avoid all the programming. While you can certainly avoid some of the more concept-heavy principles of computer science by studying security, it's not going to do you many favors in the long-run. I haven't had a single internship that didn't require moderate to heavy amounts of programming. As a security student, I often wished that I had spent more time understanding the core elements of computer science. Additionally, many security challenges require a vast understanding of both the security and the programming concepts behind them.

3. Involvement and personal projects matter.

This is more relevant to the tech field in general, but is still extremely applicable to security. I know a number of students who are ready to graduate and don't have a single repo on GitHub, have never published a blog post, don't read any blogs online, and couldn't begin to list something on their resume that wasn't part of a class project. Getting good grades in class is not enough to sell your skills to an employer. The security field is full of conferences, challenges (Capture the Flags), and project opportunities. Getting involved in a security club (starting one if one doesn't exist), completing online challenges (there are hundreds of them), maintaining a blog, and pushing some personal projects to GitHub every once in a while are great ways to show that you actually care about the work you're studying.

4. You need to love this field to make it a career.

The rate at which technology is changing is absolutely insane. With every new program, technology, language, or feature that is developed comes a host of security challenges. New discoveries are made every day, if not every hour. A career in security is not one that can be performed at the office and separated from the rest of your life. To be successful, you need to be involved in the industry, reading blogs by security researchers, and even doing research yourself. You will never learn everything (see point number one), but at least you will be informed.

5. Learn to spell and use proper grammar.

I would often spend an extra ten or twenty minutes after every group project to go back through my peer's work and correct "then" to "than," "your" to "you're," and so on. I also repeatedly catch myself misspelling some words. Many students think that being in a tech career excuses them from the requirements of good spelling and proper grammar. However, security still requires reports, letters, emails, and other documentation along with written communication with bosses, clients, and coworkers. You are not going to be taken seriously if spelling mistakes are prevalent throughout your work.

6. Break things.

I spent the better part of my first year of college carefully completing every lab report, following the steps verbatim, and starting over when things went wrong. I relied entirely too heavily on virtual machine snapshots. What I should have been doing instead of pressing "restore" was Googling for my problem and fixing it. Thankfully, I recognized this early on and was able to start treating my labs as real-world scenarios. It's not very easy to simply hit "restore" on a production server because you accidentally deleted a set of files. So it shouldn't be possible in labs. Plus, while Googling for the problem, you just might learn a few other things as well.

To complement this point, don't be afraid to experiment on your own, either. Labs and homework are only going to teach you so much. As I mentioned in point one, it is impossible to teach every aspect of security in four years. You need to do your own work and break your own things. Virtual machines are perhaps the easiest way to do this. Want to learn how to secure a web server? Set one up and Google how to break it. Then, actually try. Download an insecure VM (De-ICE, WebGoat, etc.) and go through the challenges. As a professor of mine has said many times in class, "you're not learning unless your body is between the screen and the chair and your hands are on a keyboard."

7. Learn to use Google.

I mean really use Google. Learn how to find the most obscure problems and the most practical solutions. You will be amazed at how many other people have had the exact same problem.

8. You sometimes have to ask to find security internships.

When I first started looking for internships, the most common issue I ran into was what seemed like a lack of openings for security positions. Almost all the openings were for "Software Engineer," "IT," or "Help Desk." However, after I started sending out emails to companies, I found that many of them were extremely willing to take on an intern in their security department. All I had to do was ask.

9. Awesome security electives exist. Take them!

Obviously there is no way to fit every possible security concept into a four year degree program. Many schools offer security electives that supplement existing courses with new material. Two that I remember vividly were "Cyber Defense Techniques" (basically a team-based hack and defend course) and "Pentesting." These were very hands-on classes and required a lot of outside work. But they're also the classes in which I got the most time behind the keyboard and learned by doing. Many professors who are interested in security are willing to teach these courses because they want to learn as well. Sometimes, all it takes to get a course developed is to talk to a professor.

10. Vary your experience.

While it's certainly an option to intern at a company during your freshman year, come back every year after, get a job with them after graduation, and work for them the rest of your life, reality doesn't always pan out that way. You will never be able to predict where your career will take you in ten, twenty, or thirty years, so getting varied experience now might be the key to accepting or rejecting a future job offer. There are so many places that security experience can take you. You can work in the government, for a consulting firm, a startup, a bank, a typical business, a non-profit, and in practically almost any other environment you can imagine. If you have three summers between freshman and senior year, work in three different places. Vary your physical location (try a city vs a rural area), the size of the company (a startup may only have ten people whereas a multinational bank might have 10,000), and other factors.

11. You're still a college student.

Last, but not least, remember that you're a college student. Again, this is not solely applicable to security, but join organizations, make friends, and create experiences for yourself. Study abroad if you can. While coursework is certainly important, there is so much more to experience in college than just going to class and returning home. Take advantage of the discounts and offers you get as a college student (including many security conferences). You have just about four years to shape the rest of your life; remember to shape it evenly.

Wednesday, August 7, 2013

Running Django and Node.js on the Same Server Using Apache

I've recently started working with Node.js and have been coding a few projects that I wanted to host on my VPS. However, I already have a few sites that I've written in Django running on that server on port 80. As it turns out, it's not terribly difficult to run both Node and Django on the same server, with different domains, both utilizing port 80.

I'm going to assume that you've already installed Python, Django, and Node.js on your server and that you have working projects. There are tons of tutorials on installing these on a server, so I'm not going to use this space for that. So let's begin!

First, to create the Django site, upload your Django files to your server. I'm going to save them in the directory /user/web.

To get Django working, there is a great tutorial over at DigitalOcean here: https://www.digitalocean.com/community/articles/installing-django-on-ubuntu-12-04--4

Make sure to follow all the steps. Once you can access yourdomain.com and see your app, you are successful.

Apache is now serving your Django app via mod_wsgi. To serve the Node.js app, we're going to use a reverse proxy pointing to a running instance of the Node.js server on a different port (I'll be using 3000).

Upload all of your Node.js project files to your server. I'll be saving them in /user/web/node.

Now, enable the proxy with the following command:

sudo a2enmod proxy proxy_http

Next, create a file in /etc/apache2/sites-available for your domain such as: /etc/apache2/sites-available/sample.com

In this file, paste the following code, changing sample.com to your domain:

<VirtualHost *:80>
    ServerName sample.com
    ServerAlias www.sample.com

    ProxyRequests off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    <Location />
        ProxyPass http://localhost:3000/
        ProxyPassReverse http://localhost:3000/
    </Location>
</VirtualHost>

If you need to use another port, change both locations.

Save this file, and then start your node server on the port you specified. Add the site with the following command:

sudo a2ensite sample.com

Make sure to restart your Apache service:

sudo service apache2 restart

Now, when a user visits yourdjangoapp.com, Apache will call your Django app using mod_wsgi as described in the linked tutorial above. When you visit yournodeapp.com, Apache will use a reverse proxy to call the Node.js server running on the port you specified.

You can repeat this process to add as many Node.js projects as you want, but make sure you use a different port for each.

Additionally, I recommend using a Node tool called "forever" (npm install -g forever) to keep your service running in the background and restart it if it crashes.