Planet ResTek

Gordon Stratton: IPv6-enabled home network with OpenBSD

Thu, 03 Jul 2008 05:25:26 +0000

My goal is to make my home network as simple as possible, but not to use IPv6 exclusively. That said, wherever possible I have enabled and preferred IPv6 to shake out any issues and to see where things can be improved. I try to mimic a “realistic” dual stack environment because that is the most useful balance to me so that I can continue to get things done while automatically preferring IPv6 wherever possible.

Here is a simple ASCII diagram of my physical network:

[ LAN ] — [ WAP/switch ] — [ OpenBSD 4.3 ] — { Internet }

The end result for those that don’t want to read the whole thing is an extremely stable and functional LAN that supports IPv6-enabled devices easily and automatically without denying anything to IPv4-only hosts. Windows Vista clients, for example, can simply plug in or associate with my WAP and have IPv6 connectivity with zero configuration. I realize this is relatively trivial (and hopefully my explanation is as trivial) but I feel like this is important: I commonly hear that IPv6 is very difficult to use or difficult to set up. While there are some things you need to know to set up an IPv6 network (as with IPv4), there is (or rather, should be) absolutely nothing you need to know as a client in a properly configured dual-stack environment. When a user decides to go to freebsd.org they should need to do a little sleuthing to figure out that most, if not all, of their network communication just took place over IPv6 ;)

I will go through the steps I took (neatly sidestepping the mistakes I made…) to set this up as well as posting any relevant configuration files I have. I’ll try to keep this segmented into easily visible sections, because I don’t like splitting this kind of thing up into multiple blog posts. Additionally, before I begin, I am going to use example IPv6 addresses within the RFC 3849 documentation-use-only IPv6 prefix, and example IPv4 addresses from TEST-NET described in RFC 3330 instead of my own. The IPv6 documentation prefix is 2001:db8::/32 and IPv4 TEST-NET is 192.0.2.0/24. I will use my private addresses (in 10.0.0.0/8 address space) as they actually are configured on my home network. What does this mean for you? Quoting from RFC 3849, “[a]ddresses within this block should not appear on the public Internet,” so don’t expect any of these addresses to work for you without altering them!

Step 1: Check configuration

Since this post is about OpenBSD, I’m using OpenBSD as an example. First of all, there are some sysctl options to be sure you have set to allow you to forward packets and be a well-behaved router.

/etc/sysctl.conf

# 1=Permit forwarding (routing) of IPv4 packets
net.inet.ip.forwarding=1

# 1=Permit forwarding (routing) of IPv6 packets
net.inet6.ip6.forwarding=1

# 1=Permit IPv6 autoconf (forwarding must be 0)
net.inet6.ip6.accept_rtadv=0

Next, make sure you have a pf.conf that you are content with, because in a minute you will (hopefully) become connected via IPv6. Here is a barebones pf.conf which is a literal copy and paste from the pf.conf currently on my OpenBSD box. If you’re thinking about copying and pasting this, please make sure it matches your security policies. I like my pf.conf to be more liberal than many people, so if you don’t understand what this does I would recommend man 5 pf.conf.

/etc/pf.conf

# Macros
ext_if="rl0"
int_if="xl0"

# Tables

# Options
set block-policy return
set skip on lo

# Normalization
scrub in
scrub out

# Queuing

# Translation
nat on $ext_if inet from ! ($ext_if) -> ($ext_if)

# Filtering
pass in
pass out

Make sure pf is enabled:

pfctl -e

and that your ruleset is loaded:

pfctl -f /etc/pf.conf

where /etc/pf.conf is the location of your pf.conf (this is default).

Step 2: Get connected

If you’re in the USA, statistically you probably do not have native IPv6 connectivity. This is a little unfortunate, but thankfully there are organizations who are willing to allow us to use their services to tunnel IPv6 over the existing IPv4 network to get to their point of presence, and from there the traffic can travel over the IPv6 internet. While this is not ideal, this will have to do for most of us. If you have native IPv6 connectivity, you’re probably laughing at me :)

I used Hurricane Electric as my tunnel broker. Once I was signed up, I asked for a /64. One nice thing about Hurricane Electric (and this might be true for other tunnel brokers as well, I have no idea) is that they provide customized configurations for nearly any operating system.

I’ll explain more about this later, but I’d like to show the information Hurricane Electric gave me here (using the example prefixes instead of mine) so you can tell how to apply this to your own tunnel (and I’m sure other tunnel brokers do it similarly). Hopefully the explanation afterward will give these values some meaning if they don’t already make sense to you:

Server IPv4 address:    192.0.2.74
Server IPv6 address:    2001:db8:1f04:4c9::1/64
Client IPv4 address:    192.0.2.44
Client IPv6 address:    2001:db8:1f04:4c9::2/64

Server marks Hurricane Electric’s IPv4 and IPv6 tunnel endpoints, and Client marks my IPv4 and IPv6 tunnel endpoints.

Since I’m setting up my OpenBSD 4.3 box as one of the endpoints of the tunnel, I selected OpenBSD and had them generate a configuration based on the assigned addresses. Here was the configuration generated for me (note the line continuation):

ifconfig gif0 tunnel 192.0.2.44 192.0.2.74
ifconfig gif0 inet6 alias 2001:db8:1f04:4c9::2 \
                          2001:db8:1f04:4c9::1 prefixlen 128
route -n add -inet6 default 2001:db8:1f04:4c9::1

You could happily copy and paste this, but chances are if you’ve read this far you’re going to want to know what exactly this is doing. I know I did, as I don’t like to simply copy and paste configuration from other people without knowing what it does first. The following is kind of verbose, but it might help some people to understand better what the above commands mean.

The first line says “ifconfig, I want to operate on a generic tunneling interface (gif0, man 4 gif for more information) to create a tunnel from my IPv4 address assigned to me by my ISP (192.0.2.44) to another IPv4 address somewhere else on the internet (192.0.2.74).” The tunnel concept is no more complex than thinking of a virtual tube that connects two points. While the internet may route the physical packets between the two endpoints 30 hops around the world, as far as the logic is concerned, the tunnels are directly connected. You can think of this tunnel as the underlying “road” or transport on top of which our IPv6 packets will travel to get to a place where they can be routed natively, as we (I) do not yet have native IPv6 connectivity to the internet.

The next line says “ifconfig, I want to operate on gif0 again, this time specifying things about IPv6 (inet6). I would like to create a new address for this interface as opposed to altering any existing addresses (alias), and I would like this address to be 2001:db8:1f04:4c9::2. Since we’re talking about a tunnel, I want the other end (Hurricane Electric’s end) of my tunnel to be 2001:db8:1f04:4c9::1. Finally, since I’m dealing with just a single host address on a point-to-point link, I will use prefixlen 128.”

Dead simple so far, right? The last line says “I’d like to adjust my routing tables (route -n, don’t worry about the -n for now but you can read the man page for route(8) if you’re curious) to add an IPv6 (-inet6) route which will be my default route (if my machine doesn’t know exactly where to send packets, they go here), and I want them to head toward the “far end” of my tunnel which is 2001:db8:1f04:4c9::1, where hopefully they’ll eventually be routed and arrive at their destination.” Note here that we specify the “far end” of the tunnel. We want our packets to go through the tunnel to the other end where they’ll be picked up by Hurricane Electric, not simply go to our end of the tunnel and stop short of their destination.

gif(4) is a neat little pseudo-interface that can encapsulate any combination of IPv6 or IPv4 packets based on how it is configured. Now that we’ve set up a gif(4) interface (gif0 above), it will see that since the tunnel is set up via IPv4 (the first line above) that IPv6 packets traveling through it need to get encapsulated inside IPv4 packets so they can be routed through the IPv4 internet. Once they reach Hurricane Electric at the other end, Hurricane Electric’s endpoint is set up to unpack (decapsulate) the packets and route them over the native IPv6 internet to their destination. The reverse happens exactly as you’d expect; IPv6 packets encapsulated in IPv4 packets coming in from the Hurricane Electric tunnel to our gif(4) interface get decapsulated and shuffled across our LAN to their destination as IPv6 packets.

At this point, you’ll want to assign your own IPv6 addresses to your interfaces so that you can access them via IPv6. You must assign these addresses out of the available allocated space. Working from our examples so far, these are some example valid addresses:

2001:db8:1f04:4c9::10
2001:db8:1f04:4c9::dead:beef
2001:db8:1f04:4c9::420

You can use ifconfig inet6 alias to do such configuration and an example, for completeness, of assigning an address to one of your interfaces might be

ifconfig xl0 inet6 alias 2001:db8:1f04:4c9::10 prefixlen 64

Step 3: Advertise

Now that we’re ready to go and you’ve verified that you can do something like:

ping6 ipv6.google.com

and you get replies, you can move on to telling other IPv6 capable hosts on your network about your connectivity, and how they can get some. OpenBSD ships with rtadvd (router advertisement daemon) which we will use for exactly this purpose.

Again, the configuration file first:

/etc/rtadvd.conf

xl0:\
        :addr="2001:db8:1f04:4c9::":prefixlen#64:raflags#64:

It might look like noise at first, so I’ll break it down. man 5 rtadvd.conf will be useful for more details.

Each field in this configuration file is separated by a : character. The first line starts off with an interface that rtadvd is going to advertise on. You may notice that xl0 is my internal interface from my pf.conf. This is because I want rtadvd to advertise the information that follows on my LAN. The backslash and whitespace that follows is simply to make it easy to track things in a large file; they are completely optional. The next section is addr="2001:db8:1f04:4c9::". This gives the address prefix to advertise to hosts. With IPv6, you advertise a prefix of some length and the hosts then fill in the rest themselves. Therefore I am advertising the prefix for the network you saw above. The next section is prefixlen#64. You may notice that string values are distinguished from their corresponding identifiers with = and numeric values are distinguished with #. This prefixlen section tells hosts how long the prefix that I’m advertising is. As the address 2001:db8:1f04:4c9:: expands to 2001:db8:1f04:4c9:0000:0000:0000:0000, I have to say which part of that I’m advertising, and which part is left up to the host to choose for itself. This says I’m advertising the first 64 bits of the address (The first 4 colon-delimited sections), leaving the host receiving this advertisement to deduce that it can pick the other 64 bits for itself. The last section is perhaps the least well-understood. This field raflags#64 stands for router advertisement flags, and they carry, you guessed it, flags about the nature of the router advertisement. There are two flags we are interested in. They are documented in rtadvd.conf with the following:

raflags
        (num) Flags field in router advertisement message header.  Bit 7
        (0x80) means Managed address configuration flag bit, and Bit 6
        (0x40) means Other stateful configuration flag bit.  The default
        value is 0.

I will simplify this slightly to make it as easy as possible to understand at first (hopefully) so if you want details or the authoritative source, refer to RFC 4861, page 19 for more information.

The M flag says that the host will need to get addresses via DHCPv6. In other words, it tells the host that it shouldn’t pick its own identifier (remember those last 64 bits above?), because the network policy is to ask a central location (Managed, see?) for an address first. This will likely trigger DHCPv6 in hosts that support it.

The O flag says that the host may obtain Other information from a central location as appropriate, also using DHCPv6. In other words, if you’d like to make available DNS servers, time servers, etc via DHCP, you’ll want this flag turned on so that hosts ask you about them. Note that this is separate from the address configuration. You may have (and I do indeed do it this way) the O flag set while the M flag is not set, indicating that hosts can pick their own addresses but if they want other neat information they should ask. Note that this is a little more flexible than DHCP available for IPv4, and allows for better separation of network management if you don’t want the “all-or-nothing” approach that DHCP for IPv4 offers.

The value is 64 for raflags, which is the decimal value (and I personally think the man page is confusing in this regard) of the hexadecimal value 0x40, meaning that I have the O flag set, but the M flag remains unset. This is because, in order for users to feel like they have connectivity out of the box, they will need DNS services, and I will provide them with a DNS server address to use (via DHCPv6) as I will show in a moment, so the host needs to know that it can ask for it.

Once you’ve got everything set up like you want it, start the server with

/usr/sbin/rtadvd xl0

where xl0 is the interface you want rtadvd to operate on. xl0 is my internal interface.

Step 4: DNS

I’d like to be able to resolve DNS over IPv6 for machines that support it, and it required a little tweaking on my part to get it working like I wanted it to.

First, I ran rndc-confgen to generate a key to use to communicate with the running DNS server, and did the appropriate things with it. Take a look at the man page for rndc-confgen; I won’t go into the details, but you’ll need to substitute yours below (for YOUR_OWN_SECRET_HERE if you choose to use my configuration file.

/var/named/etc/named.conf (partial)

key "rndc-key" {
        algorithm hmac-md5;
        secret "YOUR_OWN_SECRET_HERE";
};

acl clients {
        10.1.1.0/24;
        2001:db8:1f04:4c9::/64;
        127.0.0.0/8;
        ::1/128;
};

controls {
        inet 127.0.0.1 port 953
                allow { 127.0.0.1; } keys { "rndc-key"; };
};

options {
        listen-on    { any; };
        listen-on-v6 { any; };

        empty-zones-enable yes;

        allow-recursion { clients; };
};

logging {
        category lame-servers { null; };
};

This tells BIND to listen on all of my interfaces but only recursively resolve queries from my local IPv4 and IPv6 networks, which I’ve gone over above. I’ve also done some other things to the default shipped configuration like allowed version queries. If you’re unhappy with my security policies, you’ll need to make sure you modify this file to match yours before putting it into production. With this in place, I simply started the server by executing

/usr/sbin/named

Check /var/log/daemon to make sure everything started properly.

Step 5: DHCPv6 extras

This part isn’t quite as standard on OpenBSD, yet. I decided to go with WIDE-DHCPv6 for no particular technical reason, but it is simple to build and configure.

Once I unpacked the software, I changed into its directory and did

./configure && make && sudo make install

which builds it and installs the software to /usr/local. If you need/want it somewhere else, you can use the standard configure options to alter the prefixes and some other things. My OpenBSD box is a Pentium III running at 1GHz, and it takes a very small amount of time (2 minutes, if that) to configure, build, and install.

Even easier than installing this software is configuring it (in my case at least). I created a file called /usr/local/etc/dhcp6s.conf to configure the server, and the file looks like this:

/usr/local/etc/dhcp6s.conf

option domain-name-servers 2001:db8:1f04:4c9::10;

which simply tells the DHCPv6 server to hand out the IPv6 address 2001:db8:1f04:4c9::10 as the primary IPv6-accessible DNS server. Windows Vista clients, for example, if given one or more IPv6 DNS servers, prefer the IPv6 DNS servers over the IPv4 DNS servers.

You can now start the daemon with

/usr/local/sbin/dhcp6s xl0

substituting xl0 for the interface you would like it to listen on (xl0 is my internal interface) and the path to the server for the path you used if you installed it to a different location.

Step 6: Finalize

Now that we’ve set it all up, let’s make our configuration persistent across reboots.

I used /etc/rc.local to start WIDE-DHCPv6’s dhcp6s on boot.

/etc/rc.local

echo -n 'starting local daemons:'

# Add your local startup actions here.

echo -n ' dhcp6s'

/usr/local/sbin/dhcp6s xl0

echo '.'

My /etc/rc.conf.local looks like this:

/etc/rc.conf.local

dhcpd_flags="xl0"
named_flags=""
ntpd_flags="-s"
rtadvd_flags="xl0"

pf=YES

and I have three hostname.if files:

/etc/hostname.gif0

tunnel 192.0.2.44 192.0.2.74
inet6 alias 2001:db8:1f04:4c9::2 2001:db8:1f04:4c9::1 prefixlen 128

!route -n add -inet6 default 2001:db8:1f04:4c9::1

/etc/hostname.xl0

inet 10.1.1.1 255.255.255.0 10.1.1.255
inet6 alias 2001:db8:1f04:4c9::10 prefixlen 64
up

/etc/hostname.rl0

dhcp NONE NONE NONE
inet6 alias 2001:db8:1f04:4c9::20 prefixlen 64
up

You may need to change some things, for example I obtain my rl0 IPv4 address via DHCP, so my first line of hostname.rl0 contains the right incantation to obtain the address that way.

Conclusion

I hope this at least gives you a headstart when it comes to setting up a home network on OpenBSD. This isn’t necessarily intended as a guide, more as a way for me to document my thought process as I set up my network. That said, I have written it with people reading as a way to get ideas for themselves in mind, so I would appreciate comments about places where you think this can be improved. Chances are I’ve made a mistake in my thinking or have given out bad information, and I’d appreciate corrections to that effect even more.

Jenn Pritchard: Ghost 11 (suite 2.0)

Wed, 25 Jun 2008 22:40:03 +0000

The migration from 7.5 to 11 was not as smooth as I had hoped. We used to netboot and ghostcast that way but with this new version I would have had to edit all the config files and I am not willing to put in the time to figure ...

David Symons: Cygwin & Windows

Sun, 22 Jun 2008 03:04:26 +0000

To all those that read beware: Toshiba Satellite M35X-S109 does not like the power settings most linux distributions come with. Several attempts to install linux all ended with the computer turning off and random times and google doesn’t seem to help. After many sighs I finally reinstalled windows on the poor thing.

Despite the above I went ahead and installed Apache with PHP on the thing. I then wanted a way to ssh into it so I could work my pages remotely. OpenSSH worked but the problem was that I had to use windows dos commands and I was too use to typing ‘ls’ instead of ‘dir’. Enter Cygwin. I’ve known about Cygwin for quit sometime but I didn’t quite understand the full capabilities of it until today. It turns out that Cygwin can be used for a whole bunch of stuff including setting up ssh servers. Not only does it allow you to ssh into your windows machine and use linux commands, you can do other things you never thought windows was capably of. I created several symlinks and they seemed to work just fine; Apache seems to have no trouble following the links either.

I also set up a webcam and installed a VNC server on the box. Now I can just throw the computer in some corner of the apartment and control everything from my normal computer. Yey!

Side-note: I know that using Windows XP on a laptop as a server is probably not the best thing in the world but I am a poor college student. Until I can afford a real server, the situation is not likely to change.

Gordon Stratton: Are the RIAA’s DMCA takedown notices legitimate?

Fri, 06 Jun 2008 00:43:53 +0000

By now, many people are aware that the RIAA has been going after people (specifically university students) they believe are violating the copyrights of their member companies. Other people have written articles on specifically how the RIAA (or more realistically, companies the RIAA hire) do this, so if you haven’t done so, I’d recommend reading about it.

Many universities have policies, whether written or unwritten, that dictate some sort of action against students when emails are received requesting that infringing content be removed from the computers serving that content.

In most cases, universities do a variation of the following:

Look up the student’s information based on the IP address(es) listed in the email
Disable the student’s internet access
Follow up with the student in some way (require that some document be signed before internet access is restored, ask that they meet with a university employee or judicial officer, etc.)
Restore the student’s internet access

One of the many issues that I have with this process is that in almost all cases the email is never verified, nor is it verifiable. Most of the time there is a persona certificate sent along with this email, but the email itself is not digitally signed. Two different emails sent to two separate institutions contained such persona certificates that hashed to the same value. Therefore, if somebody were to spoof such an email, attaching that certificate to the email would make that email as authentic as any emails supposedly sent from the RIAA.

The problem here is that institutions are taking action against students without even attempting to verify the authenticity of the emails they receive. Universities claim that they want to avoid potential problems, and so they are complying with the text of these emails. What happens, then, when students realize their university is taking action against them from what is essentially an anonymous threat? What happens when spoofed emails result in action taken against students?

Who’s to say this isn’t happening now?

Kian Mohageri: Border Firewalling at ResTek

Sat, 31 May 2008 21:11:31 +0000

For those of you that weren’t aware, ResTek has a pair of machines acting as a border firewall. Both of the machines, hardware-wise, are the same and their configurations are close to identical as well. In this brief entry I will describe how they work, assuming the reader has zero understanding already.

First, a picture: http://www.flickr.com/photos/muskrat/2389614285/

A close look will reveal that the two 1U boxes sporting the OpenBSD and Puffy stickers are labeled “Firewall A” (top) and “Firewall B” (bottom).

Each of the firewalls has 4 Ethernet ports. Two of these are separate devices (fxp0 and em0 below), and the third and fourth are a dual-port PCI-X card. All of them are Intel-based cards. The interfaces associated with the devices are named as follows:

fxp0 – 100 mbps, connected directly to other firewall with crossover cable

em0 – currently unused

em1 – gigabit, “outside” (CARP)

em2 – gigabit, “inside” (CARP)

Because these two firewalls are on a critical path (between students and their internet), it’s very important that they are redundant. If we only had one, and it failed, there would be no internet connection for students until someone manually reconfigured the routes on the main router – this would mean hours of downtime at the very least every time something happened (including upgrades when the system needs to be rebooted)!

Common Address Redundancy Protocol (CARP)

CARP is a protocol written by the OpenBSD team (the firewalls are on the OpenBSD operating system, partly because of this incredibly useful protocol) to address this issue. From the official documentation:

CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared amongst the group members. Within the group, one host is designated the “master” and the rest as “backups”. The master host is the one that currently “holds” the shared IP; it responds to any traffic or ARP requests directed towards it.

In a simple setup like ours, one of the firewalls will be processing traffic passing between students and their internet at any given moment – whichever one doing that is referred to as the “master.” It advertises itself as master by sending out advertisements that the “backup” can see at a configurable interval. If ever the backup stops seeing these advertisements, thinking the master has failed or been shut down, it will “immediately” step in and take over.

Hopefully you noticed above that there were two interfaces (em2 and em1) referred to as “inside” and “outside”, respectively. This is just a way to describe which part of the path that network interface is facing. Consider the diagram below:

student --- (inside) em2 [firewall] em1 (outside) --- internet

A simple CARP firewall configuration will allow both firewalls to share one address on the inside, and another on the outside. The main router (to which the residence halls and firewalls are connected) will route traffic to these shared (CARP) addresses, rather than the unique addresses of either firewall. This way, the routes don’t have to change in the event of failure—the address is usually a fine route because usually at least one firewall will be up and running.

Up until now in the description, the firewalls probably don’t seem much like firewalls…

PF - The OpenBSD Packet Filter

PF is the OpenBSD packet filter (arguably the best packet filter/firewall software available today). It is part of the operating system itself, and it is responsible for deciding how to handle packets that it is configured to process. Like most packet filters, PF is configured through a configuration file (named pf.conf) that defines certain rules for how to handle different types of traffic. The rules are collectively known as a “ruleset.”

When a packet enters (or exits) the firewall, pf processes it. First, PF checks the packet against a list of existing connections—referred to as “states”. This is called a state table lookup. A “state” consists of: source address/port, destination address/port, and direction. If the packet is found to match an existing connection (and it is valid in the context of that connections current state, hence the name) it is passed. If no state match is found, the packet must be checked against the ruleset.

Most rules are very easy to read. Here are a few examples:

pass out quick from <firewalls>
block quick from any to <firewalls>
pass in on $ext_if from any to $servers

The packet is compared to the list of rules, and the last rule that matches (unless a special “quick” keyword is used in a rule), will determine how PF handles the packet. If it is “block”, it will be blocked. If it is “pass”, it will be passed. If no rule matches, the default action is to pass. The ruleset lookup is much slower than a state table lookup.

It is also important to note that, in our environment, traffic passing through the firewall is processed twice by PF (once on the “inside”, and again on the “outside”).

A primary way the firewalls are used at ResTek is to maintain a list of registered students on our network and pass their traffic, but not pass the traffic of a machine that has not been registered with us. Another way is to minimize incoming spam destined to our mail server, using OpenBSD’s spamd.

Obviously I won’t attempt to describe everything about PF, but I encourage curious readers to visit the OpenBSD documentation and learn about it.

Failover

Because state lookups are much faster (and we process a huge number of packets per second), we like to make use of them where possible. It’s possible to never create states by specifying “no state” in rules, but then the ruleset has to be checked for every single packet, and that’s much slower. In our environment, a state table lookup occurs around 40,000 times per second on average.

However, you might notice there is a possible problem with states. If the master is maintaining a list of all current states as connections pass through it, and then it fails, the backup will have no idea which packets are part of states and which aren’t. Obviously this would lead to interrupted connections where stateful filtering is in place.

OpenBSD developed “pfsync” to address this. Pfsync runs on both firewalls, and allows them to update each other on current states. So, the backup firewall, formerly blind about what connections are going through the master, would now be sent a list of updates to states. In other words, their state tables are synced at all times. If the master fails, the backup knows exactly how to handle existing connections. This is where the “fxp0” interface comes in. As said above, the two fxp0 interfaces are connected directly to each other using a crossover cable. Pfsync traffic is sent across this dedicated link.

Conclusions

The redundancy created by OpenBSD on the firewalls is extremely valuable and also extremely easy to configure. You can literally unplug the master and streaming audio/video won’t miss a beat as the backup takes over.

A few things to be aware of about our firewalls:

As for our policy, ResTek does not block ports. We recently removed the ones that used to be blocked. The main router still blocks a few ports, but we are working with the department that manages it to get that cleaned up. We do not feel that blocking ports is a worthwhile security practice in the majority of cases, and our role as an Internet Service Provider is not to police traffic in such a useless/potentially damaging way.

When traffic is denied by the firewall, it is not simply discarded. The firewall will send back the appropriate response. This is known as a “block policy” in PF. You can define “drop” (discard) or “return”. It is good practice to “return” (send back a response indicating that the connection was denied) to avoid confusion for people that are trying to troubleshoot. Our philosophy is that it is better to “return” than to “drop”.

Inbound connections to resident machines are not blocked. Now that most operating systems (Windows) ship with firewalls enabled by default, we don’t want to hinder your internet experience by trying to “protect” you. We find that usually it causes more problems than it solves, specifically for people trying to host games or whatever else. Some providers allow outbound connections, and inbound traffic associated with those connections, but drop inbound connections. We feel this practice causes more problems than it solves.

We do not use the firewalls to monitor what you do. We monitor how much traffic IP addresses are using to make sure nobody is taking up our limited bandwidth and making things slow for everyone else. We also keep an eye out for suspiciously high numbers of outbound e-mails (almost always an indication of a virus-infected machine spamming), but we do not monitor the e-mails themselves at all and look down on people that do.

Hope that clarifies some things!

Have a look at our graphs, specifically the “pf” layout, for some visuals.

David Symons: The RIAA Explains How It Catches Alleged Music Pirates

Thu, 22 May 2008 03:53:00 +0000

The other day Slashdot linked to an article where an anonymous RIAA employee explained how it caught alleged music pirates. One thing I found particularly interesting was they specifically singled out LimeWire in their demo. Maybe this was for the sake of keeping it simple but one can’t help but wonder why they didn’t say “P2P client”. The other thing they said was the word “college”. I’ll let readers make up their own mind based on these two things.

In other news, I was having problems with the sound in Amarok. The sound would just randomly stop working, the program would freeze forcing me to exit and when I would try to restart the program nothing would happen forcing me to log out and log back in. Solution? Apparently Amarok allows you to specify the sound drivers in the program itself instead of using the sound you specify in the OS settings. I just set the driver to use Alsa and all is well again.

David Symons: Flash in Hardy Heron

Mon, 05 May 2008 04:30:22 +0000

A fresh install of Ubuntu 8.03 Hardy Heron (like most linux distributions) does not come with flash pre-installed. When you use Firefox to navigate to a site that has flash, in true Ubuntu fashion, a message will be displayed asking you if you want to install it. The problem is that there are 3 different options to choose from and nothing that really tells you which is what. The choices are:

- Swfdec player for Adobe/Macromedia Flash
- Adobe Flash Player (Installer)
- Gnash SWF Player

Swfdec player is the default player, so I decided to install it without thought. As it turns out, Swfdec is an open source alternative to Adobe’s Flash Player. It installed fine, but has some interesting things to it. For one, it blocks all flash content on a web page and replaces it with a gray box. You must click the gray box before the flash object will load. Youtube videos seem to play just fine, but the volume control doesn’t work. Most other flash objects on the web, aside from basic menus, do not load properly.

Adobe Flash Player is what should be default in my opinion. It is not open source which is probably what kept it out of the number 1 spot but is probably what novice users want. When I uninstalled Swfdec and installed this, everything seemed to load and work as I’ve come to expect.

Gnash is another open source flash player but doesn’t seem as good as Swfdec. I would wait on installing this until the development matures more.

I really wish Ubuntu included some thing that told the user about each option instead of making them research it on their own. So if you are like I was and sitting there wondering what the difference is, I hope this helps.

Jenn Pritchard: Update: Comcast or Me?

Wed, 30 Apr 2008 00:40:02 +0000

Original post So the tech just left my house and guess what? Yeah, not my gateway. He had to add an amplifier because the signal isn't coming into the house strong enough. Here's a screen shot of my status page again. Notice how the Downstream power is now perfect. ...

Jenn Pritchard: Ubuntu 8.04, ATI, & Big Desktop

Mon, 28 Apr 2008 01:10:03 +0000

First off, we got some new computers at work that have the ATI Radeon 2400 HD Pro video cards. I wish I would have done some research when I had the specs for the new machines because I would have found out that ATI cards don't get along with ...

Kian Mohageri: LDAP group-based access in Apache 2 … and some other stuff

Thu, 24 Apr 2008 20:22:08 +0000

Because I am currently managing both Housing and ResTek servers (separate entities, similar needs), I’ve been trying to find a few ways to share resources between them. My manager also requested that the staff over at Housing be able to access the ResTek wiki (and maybe vise versa).

Thanks to former administrator Gordon, Housing servers were switched from SLES to FreeBSD, which is what most of our ResTek servers are. The setups now are really similar, with one exception being the fact that ResTek uses LDAP (PAM+NSS) for authentication and other things. Housing is still using local accounts because there hasn’t been a need to move to LDAP.

The goal was to add accounts for Housing employees into our ResTek LDAP directory, and then eventually share things like our wiki, Nagios, etc.

To accomplish this, I simply created another group (posixGroup) in our directory: cn=webteam. All of our ResTek employees have a primary group of cn=restek. All Housing “web team” members would have a primary group of ‘webteam.’

This seems simple enough, but there was one problem, and that was for special cases like myself, that needed to be in both groups (to access both resources). In other words, I needed a way to make myself a member of ‘webteam’ without it being a primary group. That is as simple as adding my short user name to the group’s entry as a memberUid attribute. So, we end up with something like the following (abbreviated):

Groups:

cn=restek,ou=Group,dc=restek,dc=wwu,dc=edu
gidNumber: 5000
memberUid: jonny

cn=webteam,ou=Group,dc=restek,dc=wwu,dc=edu
gidNumber: 4000
memberUid: kian

People:

uid=kian,ou=People,dc=restek,dc=wwu,dc=edu
gidNumber: 5000

uid=jonny,ou=People,dc=restek,dc=wwu,dc=edu
gidNumber: 4000

What does this result in? Kian’s primary group will be ‘restek’, and he will also be a member of ‘webteam’. Jonny’s primary group will be ‘webteam’, but he’ll be a member of the ‘restek’ group too.

Now, to allow Webteam Jonny into our Nagios page, the following can be added to Apache’s httpd.conf:

<directory "/usr/local/www/nagios/">
    Options All

    Order allow,deny
    Allow from all

    Include etc/apache22/ldap-auth-base.conf
    require valid-user
</directory>

ldap-auth-base.conf:

# Don't want people to be allowed to authenticate insecurely
SSLRequireSSL

AuthType Basic
AuthBasicProvider ldap
AuthName "ResTek Login"
AuthLDAPURL "ldap://ldap.restek.wwu.edu/ou=People,dc=restek,dc=wwu,dc=edu?uid??" TLS
AuthLDAPBindDN "cn=BINDUSER,dc=restek,dc=wwu,dc=edu"
AuthLDAPBindPassword SUPERSECRETPASSWORD
# group members are short names (uid), not full distinguished names
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid

In other words, any valid user will be allowed to log in. If we want to restrict it to members of the ‘restek’ group (primary OR secondary, we would do the following instead:

Include etc/apache22/ldap-auth-base.conf
require ldap-attribute gidNumber=5000
require ldap-group cn=restek,ou=Group

In other news, we’ve moved our IDS/monitoring tools off of our firewalls and onto a separate OpenBSD server. All of our WAN traffic is mirrored from the router onto the second interface of that server, where the monitoring tools listen. It’s helping reduce the CPU load on our firewalls a bit, and is also probably a better practice security-wise.

Jenn Pritchard: Comcast or me?

Wed, 23 Apr 2008 19:40:03 +0000

I've been arguing with comcast for months and months now because my connection at home drops multiple times a day for anywhere from a few seconds to 30 minutes to an hour. They have not once sent a tech out to take a look at things, they just immediately ...

David Symons: University research projects

Wed, 23 Apr 2008 07:07:27 +0000

As I get further into my major, I find it interesting to see what research is being done by others in the same department. Networkworld recently had a post about 25 leading-edge IT research projects from universities across the nation. Here are some of my personal favorites:

Real Bandwidth Management
Computer Scientists at the University of California at San Diego are looking at ways to have a TCP-based bandwidth management system that works across global networks.

With our system, an organization with mirrored Web sites or other services across the globe could dynamically shift its bandwidth allocations between sites based on demand.

Universities could benefit from this technology greatly as they could have main campuses unused bandwidth of the evenings be shifted over to their residence halls and then reallocated in the morning. This would give students living on campus an extra boost of bandwidth and it wouldn’t cost a thing.

Finding pictures of needles in haystacks
Researchers at Penn State have created software that tags your images for you as you upload them to Yahoo’s flickr. These automatically generated tags change depending on how users interact with your photos.

“Tagging itself is challenging as it involves converting an image’s pixels to descriptive words,” said James Wang, lead researcher and associate professor of information sciences and technology, in a statement. “But what is novel with the ‘Tagging over Time’ or T/T technology is that the system adapts as people’s preferences for images and words change.”

People have a lot of photos online and I think this would be a really neat solution to tagging all those photos. Uploading photos wouldn’t be such a pain and searching for the photos you have uploaded would be even easier. Plus it would be interesting to see how people interact with your photos.

David Symons: AT&T Pogo

Fri, 18 Apr 2008 01:28:42 +0000

No its not another cellphone, it’s a new web browser. Thats right, AT&T has decided to enter the world of web browsers throwing a very 3Dish feel to the experience. The name is Pogo and while the Beta release is currently closed from the public, they have an interesting flash preview on their site. From the looks of it, it seems very resource intensive but depending now how its implemented it should be very exciting. The demo shows it running on Windows XP, no word about other operating systems though. Speaking of no word, their site has no system requirements listed either. It is still in Beta though so we shall see. Something to keep an eye on anyway.

David Symons: Finding Firefox plug-ins

Wed, 16 Apr 2008 01:30:37 +0000

I find it interesting how most operating systems (read: Windows/Mac) try to hide files. For example, when you install a new program, do you really know what is going on? Sure you can specify a path for the main components but the shared DLL (Dynamic Link Library) files are thrown all over the place, registry keys are added, and in the end you are just amazed the program actually works. Sometimes this is good as the novice computer user probably shouldn’t be modifing these files, but if you are like me then it bugs you to not know where stuff is on your own computer.

The good folks over on the Defensive Computing blog recently made an interesting post about how to find Firefox plug-ins. This is definitely good information when you are trying to uninstall a plug-in and it leaves files behind. I would also suggest taking a look at it even if you don’t really need to modify these files. Knowing how to access key components in Firefox can only help your understanding of the browser.

David Symons: Vim

Tue, 15 Apr 2008 02:07:19 +0000

I’ve had several people ask me what my favorite text editor is. For those that are new to the field, there is some what of an incessant war over “the best text editor” between those in the IT field. The two main contenders are Vim and Emacs. This post isn’t meant to be a comparison between the two editors as there are plenty of those pages already on the internet. Instead I’d like to take a minute and explain why I choose Vim, and hopefully enlighten those that are new to the topic.

First of all, I’m sure there are those that are wondering who cares. It’s just a text editor after all. It’s not like you are writing a paper or editing full blown documents right? To most people this may be very true but to a programmer it’s not “just a text editor”. I do all my programming (no matter what language it is) in my text editor. This means almost all school work, ResTek work, and leisure programming. So for a program that is so often used, you might start to see how there could be some debate about which is better than the other.

For me, I choose Vim. Vim does take a little getting use to, I wont lie. You move the cursor around by the H, J, K, and L buttons. There are editing modes, and more options than anyone could possibly memorize. I’ve been using the program for over a year now and I probably know less than half the commands. The main thing I do like about it is that its terminal based (there is a GUI (Graphical User Interface) version if you are interested though). This means that I can open it and work when in SSH (Secure Shell) sessions. Vim also has syntax highlighting for most programming languages and a built in spell checker.

Vim may not be the editor with the most friendly learning curve but if you are looking for a lightweight, powerful editor then you should give Vim a try.