When Does a Tab Save You Money?

Posted on August 30th, 2007 in InterNetworking by Aaron Conaway

I was talking to some guys at work today about [tag]scalability[/tag] and data [tag]efficiency[/tag], and an example came up that I had to think about for a second. One of the guys, a lead developer, started talking about the difference between 5 spaces and a tab. He said that the programming standard says that everyone should use spaces to standardize formatting of source code, but, if we want to [tag]conserve[/tag] some [tag]bandwidth[/tag], we should look at using a tab instead. That sounds boring, doesn’t it? Well, it is until you do the math.

I downloaded the index page for one of our largest customers, which turned out to be 48kB. I opened it up in a text editor and replaced the spaces at the beginning of lines to tabs and checked out the size again — 44.1kB. The difference is 3.9kB…big deal. That’s not a very big savings at all, is it? Is it worth changing a programming standard for 3.9kB? It is if you finish up the math.

This website happens to be pretty big. It gets about 60 million page impressions every month, so, if we say that we’ll average a 3.9kB savings for each page, that translates to about 234GB of data per month. That’s 2.8TB of data per year. Since we pay for bandwidth based on [tag]usage[/tag], this could possibly save us several thousands of dollars per month. I don’t know the exact dollar amount, but it’ll be significant.

The moral of the story is that all data transfers should be as efficient as possible. Something that is seemingly insignificant can translate into a behemoth when you think about the scope properly.

Using a Linux Box as a File Server

Posted on August 29th, 2007 in Linux, InterNetworking by Aaron Conaway

Ever heard of Samba? You should.

Samba is an open-source project “that provides seamless file and print services to SMB/CIFS clients.” That’s from the project’s website, but what the hell does it mean? In a nutshell, it’s an open-source application that lets non-Windows machines share files and printers with Windows machines. In most cases, people use Samba to share files on a Linux box in a really simple setup. I’ve read about several cases, though, where superhuman admins have used Samba machines to set up a Windows domain. I’m talking full-scale domain login, domain machine registration, and everything. I tried that once and all my Windows machines stopped working. It sucked.

I’m going to be lazy again and not tell you how to configure it. Or am I smart and efficient and saving it for another article? Either way, I wanted to talk about what Samba can get you. Samba lets you provide a way to store files on a network share. If you set up a share for everyone to use, everyone can edit an address spreadsheet or view a home inventory sheet. You can set up Samba to share your home directories to every machine on the network. Everything’s on the same machine. Think about that for a second. If everyone’s files are on the same box, it’s easy as pie to back everything up, and, since everything’s on the network, you can have access to your stuff from everywhere.

I use Samba for file sharing. Home directories for me and the wife are shared out to local drives on our laptops. If I log in to hers and I see my home drive. I also took some time and put in a Highpoint Tech 1740 with a set of 4 300G SATA drives attached to it (hot-swappable and full fault-tolerant, by the way). These guys are put into a RAID5 array to provide about 900G of space to the operating system. I used Logical Volume Manager to split this beast up into a bunch of different volumes — images, music, videos, and a share. Samba shares all these guys out, and our machines have each of these mapped to a drive. When the wife has new images to share, she just drops them on the images drive. When I finish a new video, I drop them in the videos drive.

Samba works well and is easy to set up. Give it a try. It doesn’t really scale very well, though, so using it in an enterprise may cause problems. There’s a whole new article brewing in there about file locking and sharing, but I won’t go there yet.

—-

Remember that I mentioned backing stuff up if everything’s on the same box? It’s not related to Samba technically, but I wrote a quick and dirty bash script that takes a list of directories and tars them all up to a 400G external drive I have attached to the file server. If I didn’t implement Samba, I’d really have no easy way to back it all up in one fell swoop.

Make Your Own Ethernet Cables

Posted on August 28th, 2007 in InterNetworking by Aaron Conaway

If you need to buy an Ethernet cable, you’ll pay quite a premium for it at your local CompUSA or Circuit City. $22.99 for a 7′ Ethernet cable is terrible. For just a few dollars more, you can buy a 250′ roll of cable and make 35 of them yourself. You’ll need to invest in a good crimper and some RJ45 heads as well, but that cost is quite small compared to how much you can save by making your own.

Your data center will look better if you make your own cables. If you buy a bunch of 10-footers and 50-footers and need to run 12 feet, what happens? You’re stuck running a 50-footer to the next rack. Do that a few times and you’ve got one of these. If you make your own, you can have custom lengths just the right length that look like this.

Being able to make your own Ethernet cables also lets you customize your cables. You can make straight-through cables for connecting to a switch, crossovers for creating uplinks, rollovers for making Cisco console cables, or null modem cables for connecting modems to serial ports. I haven’t made any other cables, but I’m sure there are dozens more types out there.

So, save money, clean up the data center, and make whatever you need. I won’t go into how to make them, but here’s a list of some places to show you how.

—-

Security for Unmanned Devices

Posted on August 22nd, 2007 in Security, InterNetworking by Aaron Conaway

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.

Running HSRP for Availability

Posted on August 21st, 2007 in HSRP, Cisco, InterNetworking by Aaron Conaway

In the article describing a router-on-a-stick, I mentioned that I would use two routers that run HSRP for availability, so I figured that I would write up a short post on what it is and how it works.

HSRP (Hot Standby Router Protocol) is a Cisco-proprietary protocol for establishing two or more layer-3 devices as a fault-tolerant gateway. Please note that it is not a routing protocol like OSPF or BGP. HSRP provides availability and fault-tolerance…it does not advertise routes. I actually found several Google results that said it was a routing protocol. Those were on the first page of the results, so be careful when searching! Webopedia.com is terrible.

I’m sure you would like to know how it works, so let’s walk through the process. Each router (we’ll just assume its a router, but you can run HSPR on any Cisco layer-3 device) is configured with a standby group, priority, and standby address. Each advertises its configuration to the others, and, after everyone knows what the other routers’ settings are, each looks at the list of priorities and figures out which one is the lowest. If a router thinks that it’s the lowest priority, it becomes the active router and will start answering for the standby address. If a router isn’t configured with the lowest priority, it becomes the standby router and just chills. Every few seconds, everyone sends hello packets to let everyone know that they’re still alive. If the active router doesn’t answer in a certain amount of time, another internal election occurs, and the router with the lowest priority becomes the new active router. This whole process takes less than 10 seconds and is automatic. As long as at least one router is configured for the standby group, the standby ip is available.

That was awfully technical, so let’s look at an example. Here’s another terrible diagram to show what I’m talking about. I can’t afford Visio. :( Anyway, both routers have their FastEthernet0/0 on the same network, and we want to configure them as HSRP pairs.

HSRP Diagram

Let’s do the configuring. We’ll use standby group 75 for our configuration. It’s just a number so you can use multiple HSPR configurations on the same interface, so it doesn’t really matter. Router 1 and Router 2 have IP addresses of 10.1.1.11 and 10.1.1.12, respectively. We’ll use 10.1.1.1 as the standby IP. We’ll also say that the priority of Router 1 should be lower just so we can get an example going.

Router 1

interface FastEthernet 0/0
ip address 10.1.1.11 255.255.255.0
standby 75 ip 10.1.1.1
standby 75 priority 50
standby 75 preempt

Router 2

interface FastEthernet 0/0
ip address 10.1.1.12 255.255.255.0
standby 75 ip 10.1.1.1
standby 75 priority 100
standby 75 preempt

The only thing I haven’t noted yet is the preempt command. This tells the router that it can take over the standby IP if its priority says so. Everything else is pretty straightforward and should work like a champ. If you’re using a router-on-a-stick setup, you configure the sub-interfaces instead of the physical interfaces (like F0/0.1 instead of F0/0).

Have fun and let me know if you have any questions.

A note as usual: These are just the basics of HSRP. It can do all sorts of stuff like interface tracking, object tracking, load sharing (it’s a workaround, really), and authentication.

Router-on-a-Stick

Posted on August 20th, 2007 in Cisco, InterNetworking by Aaron Conaway

Ever heard of a router-on-a-stick? Go ahead and laugh…everyone does. It’s a funny name for a very serious topic, though. A router-on-a-stick is a network configuration that uses a single router interface as a gateway for more than one network segment. You literally take a single Ethernet interface, put it on multiple VLANs, and set up the IP address stuff.

Here’s how it works: The router is plugged into a port on a switch that is configured as a trunk that carries all the important VLANs. The router is configured with Ethernet sub-interfaces (just as you do frame-relay or ATM sub-interfaces) — one for each VLAN. Piece of cake.

Using a router-on-a-stick gives you a few things. First, it can save you a lot of cash since you don’t need an expensive layer-3 switch or additional routers for all the VLANs. It also centralizes the network into a single point, so every network is directly attached, and no routing protocols are really needed. Since it segments your network, you can also apply inbound or outbound ACLs to control traffic. Savings, ease of managment, and security? Wow!

Setting your network up this way may set you up for disaster, though. You have two single-points-of-failure in the router and switch. If either one goes down, you’re whole network is gone. If I were to implement a setup like this, I would have two switches with at least 2 trunks between them. I would also have two routers that are each configured as a router-on-a-stick and run HSRP or something similar for redundancy and availability.

Here’s a terrible diagram to show what we’re doing. In our example, we have two works stations connected to a switch on VLANs 2 and 3.

Router-on-a-stick Diagram

How about some sample configurations to bring it all together? Of course, I’m assuming you’re using a Cisco router and Cisco switch. I can’t speak for any other platforms. I’m also assuming that you are doing to use 802.1q trunks.

Configure the switch for a trunk.

interface FastEthernet0/1
description TRUNK
switchport mode trunk
switchport trunk allowed vlan 2-3

Configure the router sub-interfaces for each network.  I picked F0/0.2 and F0/0.3 because we’re using VLANs 2 and 3, but it doesn’t matter what the sub-interface names are at all.  It’s just logical to use the same sub-interface number as the VLAN ID.

interface FastEthernet 0/0
description The Stick
!
interface FastEthernet 0/0.2
description Leg into VLAN2
encapsulation dot1q 2
ip address 10.0.2.1 255.255.255.0
!
interface Fastethernet 0/0.3
description Leg into VLAN3
encapsulation dot1q 3
ip address 10.0.3.1 255.255.255.0

Pretty easy stuff. Let me know if you have any questions.

—–

Let me make a note here. When looking around for a good page to reference for this article, I read a lot of pages that said that this is a definite CCNA or CCDA test topic. I’ve taken the CCNA twice now (I passed both — the first one expired) and didn’ t see anything like this on either.

Common Cisco IOS Commands

Posted on August 17th, 2007 in Cisco by Aaron Conaway

Here’s a list of IOS commands that I use all the time that aren’t a part of the basics. I obviously use more than just these, and you do, too, but I hope there’s at least one eye-opener in there.

show env all: Shows the environment status, including fan, power supplies, etc. Good for making sure the environment is alright.
show history: Shows your command history since you logged onto the device. Good for remembering what command you put into get those stats the boss needs. Configuration changes don’t show up here.
show inventory: Shows a nice list of what the device has hardware-wise. It’s good for a router with a bunch of modules or a switch with a bunch of cards.
show interface trunk: Shows all the trunks on a switch along with pruning information. Good for making sure all VLANs are propagating around the network.
show interface capabilities: Shows what the interface is capable of doing — not just what’s its configured to do.
show interface counters: Shows byte and packet information for every interface. Good for quickly showing statistics without having to look at all the show interface garbage.
show mac-address-table: Shows the CAM table on a switch. Good for tracking down where a host is plugged into.
show tcp brief: Shows all TCP connections associated with the device like SSH sessions or BGP.
show users: Shows who’s logged onto the device. Good for finding a line to clear to kick everyone off the box.

Separation of Function

Posted on August 14th, 2007 in Security by Aaron Conaway

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.

Port Knocking

Posted on August 11th, 2007 in Tools, Security, Linux by Aaron Conaway

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.

Fallback IPtables

Posted on August 10th, 2007 in Security by Aaron Conaway

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.

Next Page »afs