Posts Tagged 'Protect'

March 5, 2012

iptables Tips and Tricks - Not Locking Yourself Out

The iptables tool is one of the simplest, most powerful tools you can use to protect your server. We've covered port redirection, rule processing and troubleshooting in previous installments to this "Tips and Tricks" series, but what happens when iptables turns against you and locks you out of your own system?

Getting locked out of a production server can cost both time and money, so it's worth your time to avoid this. If you follow the correct procedures, you can safeguard yourself from being firewalled off of your server. Here are seven helpful tips to help you keep your sanity and prevent you from locking yourself out.

Tip 1: Keep a safe ruleset handy.

If you are starting with a working ruleset, or even if you are trying to troubleshoot an existing ruleset, take a backup of your iptables configuration before you ever start working on it.

iptables-save > /root/iptables-safe

Then if you do something that prevents your website from working, you can quickly restore it.

iptables-restore

Tip 2: Create a cron script that will reload to your safe ruleset every minute during testing.

This was pointed out to my by a friend who swears by this method. Just write a quick bash script and set a cron entry that will reload it back to the safe set every minute. You'll have to test quickly, but it will keep you from getting locked out.

Tip 3: Have the IPMI KVM ready.

SoftLayer-pod servers* are equipped with some sort of remote access device. Most of them have a KVM console. You will want to have your VPN connection set up, connected and the KVM window up. You can't paste to and from the KVM, so SSH is typically easier to work with, but it will definitely cut down on the downtime if something does go wrong.

*This may not apply to servers that were originally provisioned under another company name.

Tip 4: Try to avoid generic rules.

The more criteria you specify in the rule, the less chance you will have of locking yourself out. I would liken this to a pie. A specific rule is a very thin slice of the pie.

iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -d 123.123.123.123 -j DROP

But if you block port 22 from any to any, it's a very large slice.

iptables -A INPUT -p tcp --dport 22 -j DROP

There are plenty of ways that you can be more specific. For example, using "-i eth0" will limit the processing to a single NIC in your server. This way, it will not apply the rule to eth1.

Tip 5: Whitelist your IP address at the top of your ruleset.

This may make testing more difficult unless you have a secondary offsite test server, but this is a very effective method of not getting locked out.

iptables -I INPUT -s <your IP> -j ACCEPT

You need to put this as the FIRST rule in order for it to work properly ("-I" inserts it as the first rule, whereas "-A" appends it to the end of the list).

Tip 6: Know and understand all of the rules in your current configuration.

Not making the mistake in the first place is half the battle. If you understand the inner workings behind your iptables ruleset, it will make your life easier. Draw a flow chart if you must.

Tip 7: Understand the way that iptables processes rules.

Remember, the rules start at the top of the chain and go down, unless specified otherwise. Crack open the iptables man page and learn about the options you are using.

-Mark

May 13, 2009

The Data Center is Full of Surprises

After having been in the IT industry in some form or fashion for the last decade or so, I’ve learned that no matter how well you prepare yourself for disaster, you never seem to be surprised by certain issues that present themselves. Yes, ladies and gentlemen, I’m talking about the many surprises our friend Mr. Murphy can throw at us. I’m sure many a tech will anecdotally speak of the time where their server borked on them, their backups failed despite numerous backup audits, and they were up the infamous creek (I’m only assuming at least a few readers are nodding right now). Sometimes painful lessons are the best times to learn, but it’s a bad day when it happens on a production server.

Working in the SoftLayer data center, we take incredible measures to protect our customer’s servers. In a sense, we try to keep Mr. Murphy away. From the biggies (like redundant power and MASSIVE cooling units) to the routine (such as the data center walkthroughs, and proactive RAID alerts), we do our best to keep the servers in the data center running smoothly, and free of surprises.

Beyond the punches our friend Mr. Murphy can throw at us now and again, it’s nice to know there are a few good surprises in store for you, too. You might be surprised at the great deals our SLales team can provide. You might also be surprised at not only the amazing features such as the new Cloudlayer™ Storage, but the incredible rate we keep bringing new features to the table. I’ve also seen customer’s surprise when we rescue their server from the brink of disaster, or when we are able to provide a few tweaks to give THEIR business the edge it needs.

Furthermore, our people keep the data center interesting. SoftLayer sees no shortage of antics. There’s John’s fully automatic Nerf gun. There’s also plenty of jokes played at the expense of someone unfortunate enough to leave their workstation unlocked (call it “security training” – favorite backgrounds include the Care Bears and My Little Pony). We also have that one hardware tech who likes to hide around corners or sneak up behind you, and scare the life out of you while you’re focused on the task at hand.

With so many surprises, SoftLayer continues to be a very interesting place to work, and most certainly a place where one would never get bored!

Subscribe to protect