Tuesday, April 8, 2014

How to Fix OpenSSL Heart Bleed Bug on Amazon ELBs

The recently discovered "Heart Bleed" bug in OpenSSL is an extremely critical security issue. Amazon has been working to get all of their environments patched to the latest version of OpenSSL that remedies the issue.

If you have Elastic Load Balancers currently using an SSL certificate that was generated via OpenSSL version 1.1.0a-f, you need to follow these streps to revoke the current certificate on your load balancer and upload a new one.

First, update OpenSSL on the machine you are going to use to generate your private key and sign your certificate. I have written another post on how to do that here: http://blog.matthewdfuller.com/2014/04/how-to-fix-openssl-heart-bleed-bug-on.html

Once you have regenerated your keys and resigned your certificate, you can upload them to your load balancers.

Within the AWS console, click "EC2" in the Services menu.

Now, click on "Load Balancers" on the left-hand side and select your load balancer instance.

Click on the "Listeners" tab and notice the existing cert:

Click "Change" and then click "Upload a new cert."

Give your cert a name, paste in the private key and cert you created earlier, and provide any chain information if needed.

Hit save and your load balancer will push the changes.

If you want to do this via the command line or API, check out the official AWS documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_UpdatingLoadBalancerSSL.html

How to Fix OpenSSL Heart Bleed Bug on Ubuntu

If you're looking for how to update your Amazon Elastic Load Balancer, click here instead.

The recently discovered "Heart Bleed" bug in OpenSSL is an extremely critical security issue. Fixing it is relatively simple now that Ubuntu has pushed out changes to their repositories containing a fixed version of OpenSSL.

The following steps need to be run on each server that you generated a certificate or private key on. If you are using one certificate on multiple servers, then the cert needs to be revoked and regenerated on one of them and then pushed to each of the other servers.

UPDATE: Thanks to anonymous commenter for pointing out that relying solely on the build information is not completely accurate. Versions earlier than 1.0.1 are not vulnerable (although you should upgrade now that a fix is live for the latest version).

First, to make sure you (for some reason) don't have the latest version, run the following commands:

openssl version -b

openssl version -a

The response will look like:

OpenSSL 1.0.1 14 Mar 2012

built on: Wed Jan  8 20:45:51 UTC 2014

If the date is not more recent than older than "Mon Apr  7 20:33:29 UTC 2014" and the version is 1.0.1, then you are vulnerable to the Heart Bleed bug.

UPDATE: Reworded the above to make it clearer that the vulnerable versions were built before April 7th.

UPDATE: As James points out in the comments, different versions may have been built at different times, thus you should rely only on the date, not the time. Anything before Apr 7 is considered vulnerable.

Next, update your repositories:

sudo apt-get update

Once this finishes, upgrade openssl:

sudo apt-get upgrade openssl

sudo apt-get install openssl libssl1.0.0

UPDATE: use the install command to upgrade only openssl and libssl rather than upgrading everything on the server.

Once the upgrade finishes, check the version again. It should now read "Apr 7" or later.

Now, you need to regenerate your certificate using a new private key. This process is the same as it as always been, but I am including the link here for posterity's sake:

(Use step 3 and replace the key and cert names with your existing ones to overwrite them).

Once finished, you need to restart your Apache server and any services using SSL.

Update: Now with video:

Thursday, March 6, 2014

Find the Public Hostname of an Amazon EC2 Instance

If you need to find the public hostname of an Amazon EC2 instance, there is a simple URL which, when cURL'ed will return the hostname:

This URL only works inside the AWS infrastructure (so you must be on an instance to run it properly), but you could easily run:


This will return the hostname in the standard format:


Wednesday, March 5, 2014

Custom Opsview NRPE Client Agent Service Checks

To install custom checks on Opsview Agents, there are a number of steps that need to be taken. I will assume that the OpsView daemon has already been installed and is running (if not, you can download it here: http://www.opsview.com/technology/downloads/extras/opsview-agents).

First, log into the client on which you want to install a custom check. Then, navigate to the /usr/local/nagios/libexec folder. This is where we will place the actual custom check script you have written. In this case, I will call it "check_test" (it must begin with "check_" to follow the naming conventions. Additionally, the check must return an exit code indicating its status ("0" for "Success", "1" for "Down", etc.).

Now, that you have saved the check_test file in this directory, make it executable and change the owner and group to "nagios".

sudo chmod +x check_test
sudo chown nagios check_test
sudo chgrp nagios check_test

Now, your check is ready to execute, but it must be made available to the NRPE configuration. To do this, navigate to /usr/local/nagios/etc and create a folder called "nrpe_local" if it does not exist already. Then navigate into the folder.

sudo mkdir nrpe_local
cd nrpe_local

Here, create a file called "override.cfg" and change the owner and group to "nagios" just as you did with the script before.

sudo touch override.cfg
sudo chown nagios override.cfg
sudo chgrp nagios override.cfg

Now, open the file in your favorite text editor and add the following line:


Where "check_test" is the name of your check that you saved earlier.

Save the file, exit, and restart the opsview agent.

sudo service opsview-agent restart

Now, head over to the Opsview web interface on the Opsview server side. Go to Settings > Service Checks and click the + to add a new check. Give it a name "Test Check" and a description of what it does. Then put it into a Service Group or create a new one. It shouldn't need any dependencies, and you can add it to a Host Template as needed. The check type should be "Active Check" and the period, interval, max check attempts, and retry interval can be whatever tou like.

Under "plugin" select "check_nrpe" (not the name of your plugin, which likely won't be in that list).

Under "Arguments" enter the following:

-H $HOSTADDRESS$ -c check_test

Where "check_test is the name of your check. Submit the changes and you should be complete. Reload the configuration and you will see the check show up and it can be added to your host.

Friday, February 28, 2014

How to Change the Default Timezone on Amazon Ubuntu EC2 Server

After setting up a Ubuntu Server on Amazon EC2, it's annoying that the default timezone is UTC. Here is how to change it:

sudo dpkg-reconfigure tzdata

Then restart your cron service. Otherwise, the timezone should be changed. This will allow the correct times to show up in any applications you have running.

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

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

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.