Aaron's Worthless Words

I was talking to a coworker the other day about setting up his home network more securely.  “No problem,” I said, and we started listing devices on his network to see what we needed to do.  I was pretty surprised that he had so many things on his network.  I mean, I was quite amazed.  He had all sorts of stuff — from gaming consoles to guest machines to special-purpose Linux boxes to sewing machines.  A sewing machine?  Yes, a sewing machine.

We beat out a pretty good function list for his to segment everything out, but his huge list of stuff got me thinking about the things that are network-ready nowadays.  You can get refrigerators, exercise bikes, and pet feeders.  Who knows how to secure a refrigerator?  I would think that nobody really does, so what’s the best thing you can do to protect yourself from your refrigerator?  Good question.

If you step back and take another look at it, you could definitely consider those hosts to be untrusted.  You may or may not have any management on them, and they go about doing their thing without your intervention.  What else is an untrusted host?  How about your buddies who bring their laptops over?  The same thing applies to them, too, so why not?

Segmentation is a really good start with security, especially if you don’t know exactly what a box does, so let’s start there.  If you have a bunch of stuff that’s not traditionally a network device, you should first think about making a network segment for those guys.  If you have a Linux box as a firewall/router, you can simply add a NIC to it and voila!  New network segment for untrusted devices.  Lock that puppy down and you should be good.  In my setup at home, that segment has its own SSID for guests to connect to and contains my Wii.  The only thing that hosts have access to is HTTP and HTTPS and all access to my other networks is denied completely.  This protects my machine from them and doesn’t let them go running amok.

—-

My usual note:  You should probably have separate segments for untrusted devices, trusted workstations like laptops and PCs, and servers such as file servers.  If you want to be really anal about stuff, you should get a managed switch that supports private VLANs so hosts on the same network can’t get to each other.  That sounds like another article to me, though.

Separation of function is another important security concept that people often overlook.  It can mean that a single person is only responsible for one part of a process.  Or it can mean that one server only does one function.  Or it can mean that one network is used for servers of one type.  Or it can mean that a whole data center is for only one production and not development.  It depends on your scope and your point of view.

What does it give you?  Think about it for a second.

• If a server is a web server and not a database server, then you don’t have to open up any type of access from the Internet to the database server.  If you had them both on one box and the webserver was owned, guess what?  The database server is owned, too.
• If you have a network segment that’s only for web servers and one of them gets owned, then they only have access to other web servers.  If you had web servers and database servers on the same network, a compromise of a web server has direct access to the database server.
• If a developer can only write code and someone else deploys it or tests it, then he can’t deploy code without telling anyone or deploy code that emails credit card numbers to himself.
• If a data center blows up but contains only development servers, you don’t lose any production time since all those boxes are on the other side of town.

You can see there are some advantages, but everything has a downside.  In this case, you have to pay for the extra whatever — be it a new server, new firewall, new data center, new tester.  The advantages, though, can often outweigh the costs since you have a while mess more controls in in place.

NOTE:  Most or all compliance programs like PCI or SarBox can REQUIRE separation of function on a lot of areas like server function separation, and developer/tester/deployer separation.

A few months ago, a friend of mine told me about the concept of port knocking, where you send packets to a server on certain ports to authenticate access to the box. A daemon running on your server detects the sequence of packets that you send and runs a script (usually IPtables commands), waits a certain amount of time, then runs another script (usually to take the IPtables commands out). This seems like a good way to get access to your home firewall from anywhere without having to open up access to the whole Internet.

To set it up, you have to install knock, which is the daemon that listens to the port knocking. Just use yum or apt-get to install it and you’ll wind up with the configuration file in /etc/knockd.conf. This is where you set up one or more knock sequences to do what you want. I won’t go into the internals of how it works or how you should set it up but I will go into a few examples.

I use port knocking on my home network to protect administrative access to everything on the network. I wrote a custom IPtables script that, when activated, open access from my IP on the wireless network to SSH (TCP/22) on my firewall, file server, access point, and switch. After 30 seconds, another script runs, and those rules are removed. Here’s an example of a config file that opens up SSH when you hit ports 1234, 5678, 9876, and 5432. After 30 seconds, it kills the rule.

[options]
logfile = /var/log/knockd.log

[openssh]
sequence = 1234, 5678, 9876, 5432
seq_timeout = 5
tcpflags = syn
start_command = -A INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT
cmd_timeout = 30
stop_command = -D INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT

So, how do you generate these packets? On my CentOS boxes, you get the knock command which is the port knocking client. On Windows, I use KnockKnock. I have no clue about Macs, but there are lots and lots of clients out there, so just look around and I’m sure you’ll find one.

The hardest part of messing with firewall configs is knowing what is going to lock you out of the firewall itself.  It doesn’t to me very often, but I’ve been doing firewalls for 10 years now.  I was thinking about my own IPtables implementation at home and realized that I do most of my tweaking remotely.  If I were to fat-finger something, I’d have to get on the console, and everything would be down until then.  I don’t need a lot of uptime at my house, but I really can’t stand downtime, but I digress.

Since I use IPtables at home, I took a look at some of the inner workings and found the “save” option.  This writes your running configuration to a file /etc/sysconfig/iptables.  Since IPtables doesn’t write this file automatically, you can use this mechanism to keep a known-good copy on disk.  So how?  You can use this command to restore the good config.

iptables-restore < /etc/sysconfig/iptables

If you stick this command in root’s cron to run every 15 minutes, you can make any changes you want, and, if you hose it up, the known good config will be restored in a few minutes.  When you make changes and everything seems fine, you just do a “/etc/init.d/iptables save”, and your new config is saved off for later.

By the way, I use “iptables-restore” to make any changes.  I have a file that I make changes to and then use the syntax above to apply it.  The command actually flushes all the tables and puts the config in the file back, so you don’t have to remove any rules from memory if they conflict with new rules.  Remember that order is important when configuring IPtables rules.

You can use an old PC as a firewall at home (and at work, I guess). It’s not that hard to do if you have a basic knowledge of Linux, DHCP, and IPtables, but that may be saying a lot.

Why would anyone want to do this, though? If you’re like me, you like to know what’s going on in the network. One of the Linksys routers you buy at Best Buy or Circuit City just doesn’t let you monitor very well. You can’t get very good logs off of it, so you don’t really know what it’s doing or complaining about. It also doesn’t let you query the interfaces, so you really don’t know how much bandwidth you’re using.  If you have a Linux box as your router/firewall/gateway, you can get really good logs, monitor the interfaces with SNMP, and have some really great, granular control over your network.

To set up a simple network, you only need a machine with two NICs in it and a Linux distro, then follow these steps. This is a simplified procedure, but it should get you started.

1. Install Linux on the box. Make sure you have IPtables and DHCPd on it when you’re done.
2. Cable one NIC to the cable modem (WAN) and the other to your switch (LAN).
3. Hard-code the IP address of the LAN interface to your favorite IP space.
4. Set up DHCPd to serve IPs to your LAN.  Remember to set your default gateway option to the IP of the LAN interface and your DNS servers to your ISP’s servers.
5. Set up IPtables as your firewall. This is not a simple endeavor, but there are several links for help below.
6. Enjoy your newfound infrastructure.

This is how I started out, but my network has grown tremendously in the last year or so. I’ve got four NICs in my gateway to create different network segments, and my IPtables file is about 5k now with 79 rules in the system. The price you pay for being a network dude.

Another thing you may want to do is recycle the wireless router.  If everything’s working in place after you implement the new box, you can turn off DHCP on your wireless router and stick it into the LAN segment.  You can still attach to it with your notebook or whatever, but you’ll get your address from the server just like the wired hosts.

Since you’re running Linux now, you can also look at using some other tools to help monitor everything.

• Nagios — for monitoring the status of the network
• Cacti – for trending and usage graphs
• Syslog – for collecting log files
• Apache – the de facto web server
• Bind – for serving DNS locally
• NTP – for syncing all your machines’ clocks
• tcpdump – for capturing packets coming in and out of the network

Let me know if you have any problems or need any help.
—–
Some IPtables links to help you on your way:

• http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables
• http://www.sns.ias.edu/~jns/wp/iptables/
• http://www.yolinux.com/TUTORIALS/LinuxTutorialIptablesNetworkGateway.html
• http://www.faqs.org/docs/iptables/traversingoftables.html

The Principle of Least Privilege says that users or applications should only have access to the what it needs to access and that access should be as limited as possible.  This idea can be applied to any number of things, but it is a very important topic when talking about security.

The idea is that processes, users, modules, or whatever can only access what they need to in order to function.   This keeps users in check since they don’t have any access to anything outside their home directories (or whatever).  It keeps developers in check since their code can only access a small set of files or processes.  It keeps hackers in check since the Apache server they’re hacking can’t access the password file.  It even keeps administrators in check since it forces them to use sudo, which is logged to syslog.

Like everything, this is a simplistic description, but it’s very important for every administrator to adopt this idea.

You may also want to check out SELinux if you’re a Linux admin, which is a system that is used to enforce least privileges for nearly everything on a Linux box.