Archive for the ‘security’ Category

A post about backing up your data.

Posted on October 29th, 2013 in security | No Comments »

Death of my Macbook Air

A few weeks ago my Macbook air died. It’s SSD drive went out (and coincidentally Apple issued a notice that they are replacing SSD’s on all new Macbook Air’s a few weeks later.) The main reason for this post is to tell you to BACK UP YOUR DATA. Luckily, I had all my important data backed up in Dropbox and larger files that I don’t want replicated to all machines to Amazon S3/Glacier via the amazing Arq software.

A warning on local backups

To save money, one might find it most cost effective to plunker down $99 for a 1TB USB hard drive and just run Time Machine (on Mac) or Carbon Copy Cloner but really that’s not good enough as an only backup. A fire in your home or theft would wipe out all your precious files and memories.

Dropbox to save the day?

Above, I mentioned I used both Dropbox and Arq. Dropbox is just convenient, drag files to the DB folder—it’s backed up. One might even tell me that now you can store files on Dropbox and choose not to replicate them across all machines (an annoyance in the past) but still, at $40+ a month for 500GB of storage, that’s ridiculously expensive — almost 500 bucks a year!) If you were to put that data on Amazon S3 it’d cost you roughly $8.34 a month.

Amazon S3 and Arq

Amazon S3 is big, fast, and cheap. The problem with Amazon S3 though is that it’s not user friendly. It’s really for developers writing apps to store large amount of data—but Amazon has no restriction on use cases so it’s perfectly fine to use for personal data storage.

I really dig Arq because its a one time fee of $40 and then after that you simply connect it up to Amazon S3 or Glacier and pay for only what you use, forever. Amazon however charges per download and upload of your files and every time you access the files (but we’re talking fractions of a penny, so though it probably does end up being a lot cheaper we really can’t compare the two products.) Here’s Amazon’s S3 pricing chart. The other two great things about Arq is that it can do progressive backups, meaning it only backs up changes over time, reducing your costs and time to upload, and Arq also encrypts your data before placing it on Amazon so even if someone were to break into Amazon’s servers or illegally access your account there, your data is still encrypted from the outside and only Arc (with your password) can decrypt it.

Enter Bitcasa

Saying the above, Arq is probably still too complicated for the average computer user. Simply signing up for Amazon S3 alone and generating an access key is above most people’s heads. I’m sure there’s a lot of alternatives out there but I’m looking for one I can recommend to friends and family. I discovered Bitcasa, a hot local startup with big names behind it offering unlimited storage. I honestly haven’t used it enough to recommend it—nor is the company old enough to gain my trust yet, who knows if it will flounder. But U did ask their support team some questions:

Davita: Hello! Do you have any questions I can help answer for you?
You: hi
i don’t get how this can be infinite
what if I have 100TB to transfer
also do i have immediate access to download it
Davita: Hi there :) How are you today?
I get it, you’re thinking “what’s the catch”
no catch
You: this is not financially viable as a company
Davita: we’re able to do this because of our deduplication process
You: oh ok
do you throttle upload after a certain amount?
Davita: Nope, we do not throttle
You: and where do you store this data?
on amazon s3 or an internal data center?
Davita: Amazon s3
You: what about Amazon Glacier
do you use that or no?
Davita: Currently, no
Awesome
You: If i upload 1TB to S3 that’s the equiv of paying Amazon $100 a year. So bitcasa is betting that my content will be similar to others so they can make somewhat of a profit
by reducing the upload size on s3
Davita: That’s one way to think about it :)
You: Cool. Thanks for the info!

If this company does go under, they will certianly give you enough time (weeks) to download all your data before hand. If someone actually wants to give it a try let me know how it is.

Conclusion

Start with Dropbox for your small stuff which is a no-brainer (free 2GB on signup) and then find a way to backup your larger data offsite. Try Arq (feel free to comment if you need help with it) or follow other suggestions in the comments.

Securing your SSH on Centos, especially on EC2.

Posted on December 6th, 2012 in AWS, security, ssh | No Comments »

The popular port.

Example brute force attempt on an EC2 server.

By default SSH runs on port 22 on your server. Though I’m not a proponent of security by obscurity, moving your SSHd to a high-number port (like 3293) will reduce the number of brute force attempts on your SSH by nearly 100% (Stats given by reviewing /var/log/secure on servers I have or have had access to for years.) This used to be pretty important but even more so with cloud services like Amazon EC2 where hackers and script kiddies can ping sweep whole subnets of Amazon’s elastic IP ranges. (On a related note, Stackoverflow blocked all EC2 instances from accessing their site using the same approach.)

DenyHosts

If for some reason though, you cannot move SSH ports—for example, you’re working in a legacy system where dozens or hundreds of people are already connecting to, the next best thing is to install DenyHosts, a free tool written in Python that reviews and bans IP addresses that make too many failed attempts.

Installing DenyHosts

Centos doesn’t have direct access to installing it. But you can install it by running the following:

sudo rpm -Uvh http://mirror.metrocast.net/fedora/epel/6/i386/epel-release-6-7.noarch.rpm
sudo yum install denyhosts

After that, add your IP address to /etc/hosts.allow in the format of sshd: 12.34.45.678 so that it will never blacklist your IP, tweak /etc/denyhosts.conf to your liking, and restart denyhosts with sudo service denyhost restart. It started analyzing your /var/log/secure and banning ips pretty instantly as you can see from this screenshot. After a few weeks it can optionally purge them so the ban list doesn’t get super big.

DenyHosts auto blocking IP addresses.

The folks at Digital Ocean have a great entry that can walk you through the rest.

Note: The one downside of switching SSH ports is that you can no longer use git in it’s common syntax since git uses SSH as it’s secure transport. See my article on using git on non-standart ports to solve that easily.

Hardening your /etc/ssh/sshd_config

There are a few adjustments you should make to your SSHd config so that it’s harder for the wrong person to gain access. This includes disabling password-based logins (everyone should be using SSH keys), disabling root user login, and throwing in a welcome message that this SSH session is being logged:

# Disable password based login. Only SSH keys are allowed.
PasswordAuthentication no
# Add a message banner notifying this server is logged.
Banner /etc/ssh.go.txt
# Do not allow root to login
PermitRootLogin no
# Deny root user login
DenyUsers root

Following the above steps should make your SSH more secure. Happy SSHing!