Tagged with iptables …

Oct 12 2010
25 Comments

Securing your ssh server

One of the most common questions that I see in my favorite IRC channel is: “How can I secure sshd on my server?” There’s no single right answer, but most systems administrators combine multiple techniques to provide as much security as possible with the least inconvenience to the end user.

Here are my favorite techniques listed from most effective to least effective:

SSH key pairs
By disabling password-based authentication and requiring ssh key pairs, you reduce the chances of compromise via a brute force attack. This can also help you protect against weak account passwords since a valid private key is required to gain access to the server. However, a weak account password is still a big problem if you allow your users to use sudo.

If you’re new to using ssh keys, there are many great guides that can walk you through the process.

Firewall
Limiting the source IP addresses that can access your server on port 22 is simple and effective. However, if you travel on vacation often or your home IP address changes frequently, this may not be a convenient way to limit access. Acquiring a server with trusted access through your firewall would make this method easier to use, but you’d need to consider the security of that server as well.

The iptables rules would look something like this:

iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.20
iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.25
iptables -A INPUT -j DROP -p tcp --dport 22

Use a non-standard port
I’m not a big fan of security through obscurity and it doesn’t work well for ssh. If someone is simply scanning a subnet to find ssh daemons, you might not be seen the first time. However, if someone is targeting you specifically, changing the ssh port doesn’t help at all. They’ll find your ssh banner quickly and begin their attack.

If you prefer this method, simply adjust the Port configuration parameter in your sshd_config file.

Limit users and groups
If you have only certain users and groups who need ssh access to your server, setting user or group limits can help increase security. Consider a server which needs ssh access for developers and a manager. Adding this to to your sshd_config would allow only those users and groups to access your ssh daemon:

AllowGroups developers
AllowUsers jsmith pjohnson asamuels

Keep in mind that any users or groups not included in the sshd_config won’t be able to access your ssh server.

TCP wrappers
While TCP wrappers are tried and true, I consider them to be a bit old-fashioned. I’ve found that many new systems administrators may not think of TCP wrappers when they diagnose server issues and this could possibly cause delays when adjustments need to be made later.

If you’re ready to use TCP wrappers to limit ssh connections, check out Red Hat’s extensive documentation.

fail2ban and denyhosts
For those systems administrators who want to take a bit more active stance on blocking brute force attacks, there’s always fail2ban or denyhosts. Both fail2ban and denyhosts monitor your authentication logs for repeated failures, but denyhosts can only work with your ssh daemon. You can use fail2ban with other applications like web servers and FTP servers.

The only downside of using these applications is that if a valid user accidentally tries to authenticate unsuccessfully multiple times, they may be locked out for a period of time. This could be a big problem if you’re in the middle of a server emergency.

A quick search on Google will give you instructions on fail2ban configuration as well as denyhosts configuration.

Port knocking
Although port knocking is another tried and true method to prevent unauthorized access, it can be annoying to use unless you have users who are willing to jump through additional hoops. Port knocking involves a “knock” on an arbitrary port that then allows the ssh daemon to be exposed to the user who sent the original knock.

Linux Journal has a great article explaining how port knocking works and it provides some sample configurations as well.

Conclusion
The best way to secure your ssh daemon is to apply more than one of these methods to your servers. Weighing security versus convenience of access isn’t an easy task and it will be different for every environment. Regardless of the method or methods you choose, ensure that the rest of your team is comfortable with the changes and capable of adapting to them efficiently.

Tagged , , , , , , , ,
Aug 17 2010
4 Comments

A simple guide to redundant cloud hosting

Update: I’ve removed the guide as it has aged quite a bit and is not very helpful.

Today, on my 28th birthday, I’m finally delivering on a promise to my readers which I made about two months ago. I’ve written a guide on how to host a web application redundantly in a cloud environment. While it’s still a bit of a rough draft, it should be a good starting point for those who haven’t worked in virtualized environments before. Also, it may show some of the more experienced systems administrators a new way to do things.

The guide: Redundant Cloud Hosting Guide

As always, if you find anything in the guide that needs improvement, I’m all ears. :-)

Tagged , , , , , , , , , , , , , , , , , , , , , , ,
Jul 26 2010
4 Comments

Adding comments to iptables rules

After I wrote a recent post on best practices for iptables, I noticed that I forgot to mention comments for iptables rules. They can be extremely handy if you have some obscure rules for odd situations.

To make an iptables rule with a comment, simply add on the following arguments to the rule:

-m comment --comment "limit ssh access"

Depending on your distribution, you may need to load the ipt_comment or xt_comment modules into your running kernel first.

A full iptables rule to limit ssh access would look something like this:

iptables -A INPUT -j DROP -p tcp --dport 22 -m comment --comment "limit ssh access"
Tagged , , ,
Mar 01 2010
4 Comments

Private network interfaces: the forgotten security hole

Regardless of the type of hosting you’re using – dedicated or cloud – it’s important to take network interface security seriously. Most often, threats from the internet are the only ones mentioned. However, if you share a private network with other customers, you have just as much risk on that interface.

Many cloud providers allow you access to a private network environment where you can exchange data with other instances or other services offered by the provider. The convenience of this access comes with a price: other instances can access your instance on the private network just as easily as they could on the public interface.

Here are some security tips for your private interfaces:

Disable the private interface
This one is pretty simple. If you have only one instance or server, and you don’t need to communicate privately with any other instances, just disable the interface. Remember to configure your networking scripts to leave the interface disabled after reboots.

Use packet filtering
The actual mechanism will vary based on your operating system, but filtering packets is the one of the simplest ways to secure your private interface. You can take some different approaches with them, but I find the easiest method is to allow access from your other instances and reject all other traffic.

For additional security, you can limit access based on ports as well as source IP addresses. This could prevent an attacker from having easy access to your other instances if they’re able to break into one of them.

Configure your daemons to listen on the appropriate interfaces
If there are services that don’t need to be listening on the private network, don’t allow them to listen on your private interface. For example, MySQL might need to listen on the private interface so the web server can talk to it, but apache won’t need to listen on the private interface. This reduces the profile of your instance on the private network and makes it a less likely target for attack.

Use hosts.allow and hosts.deny
Many new systems administrators forget about how handy tcpwrappers can be for limiting access. If your firewall is down in error, host.allow and hosts.deny could be an extra layer of protection. It’s important to ensure that the daemons you are attempting to control are build with tcpwrappers support. Daemons like sshd support it, but apache and MySQL do not.

Encrypt all traffic on the private network
Just because it’s called a “private” network doesn’t mean that your traffic can traverse the network privately. You should always err on the side of caution and encrypt all traffic traversing the private network. You can use ssh tunnels, stunnel, or the built-in SSL features found in most daemons.

This also brings up an important point: you should know how your provider’s private network works. Are there safeguards to prevent sniffing? Could someone else possibly ARP spoof your instance’s private IP addresses? Is your private network’s subnet shared among many customers?

With all of that said, it’s also very important to have proper change control policies so that administrators working after you are fully aware of the security measures in place and why they are important. This will ensure that all of the administrators on your instances will understand the security of the system and they should be able to make sensible adjustments later for future functionality.

Tagged , , , , , , , , , ,
Nov 16 2009
10 Comments

Automatically loading iptables rules on Debian/Ubuntu

If you want your iptables rules automatically loaded every time your networking comes up on your Debian or Ubuntu server, you can follow these easy steps.

First, get your iptables rules set up the way you like them. Once you’ve verified that everything works, save the rules:

iptables-save > /etc/firewall.conf

Next, open up /etc/network/if-up.d/iptables in your favorite text editor and add the following:

#!/bin/sh
iptables-restore < /etc/firewall.conf

Once you save it, make it executable:

chmod +x /etc/network/if-up.d/iptables

Now, the rules will be restored each time your networking scripts start (or restart). If you need to save changes to your rules in the future, you can manually edit /etc/firewall.conf or you can adjust your rules live and run:

iptables-save > /etc/firewall.conf

Thanks to Ant for this handy tip.

Tagged , , , , ,
← Older posts