Hacking RESNET
by jk
The Residence Hall Network (RESNET) isn't a single entity, it is a cookie-cutter approach to networking dorm rooms at universities.
The people responsible at each campus basically get together on a self-help listserv, tell success and horror stories, and sort of come up with a plan for what they want to do and how they want to do it. It is an environment that is full of possibilities for exploration.
To learn why it is so disorganized, you have to understand the politics. RESNET isn't a unified network at all and there are a lot of egos and posturing involved. Universities tend to do their own thing and have a hard time holding onto good people (who can leave and get a lot more money elsewhere in industry once they get good).
In addition, the people who pay for the equipment (housing) are usually a separate entity from the university itself, both in mentality (real-estate) and financing. The financing issue creates most of the disorganization, along with the initial power-plays involved when RESNET first gets installed.
If the (experienced) network people had their way, things would be locked down pretty tight. That costs money, but it is the housing group's money. This is usually the first power struggle since the housing people want something that is cheap and inexpensive and the networking people want something that is secure and (more) expensive. After much infighting, this basically boils down to having a network infrastructure that can be made secure, but currently isn't.
If you're in a RESNET that wasn't recently established, chances are excellent that cost would have prohibited some of the more secure solutions (switched vs. shared network ports, for example).
The RESNET goal is to make the user use DHCP to configure their IP and force them to register themselves on a web page. When someone sends off fan-mail to the president, the people responsible want to be able to say that they've made a best-effort to be able to hold their RESNET subscribers accountable (someone's head on a platter). One important aspect is that they want to totally automate it as much as possible so they don't have to have that much man-power to provide reasonable service.
Basically, they want to be able to hunt you down if they find you doing something you shouldn't, they don't want you to set up a local server, and they don't want to give you any reasonable expectation of a service they may want to take away later (even if they can't really enforce it at that point in time).
Using DHCP has a number of good points for them. It is slightly biased against non-desktop operating systems (if they have to help you, they want you to have something they understand and good *NIX hackers are scarce), it randomly assigns you an IP address and can be configured to assign you a new one at sometimes unpredictable intervals, and you get a generic unpersonalized hostname. They can do very little (DHCP does most of that by default) and pretend they're offering a service of convenience. They don't want someone setting up another Yahoo! in their dorm room.
If they could think of a good reason, they would probably write up an AUP that would find some way to say that you can't have incoming connections. Most of them aren't too worried about it but they should probably be with server apps appearing for Windows 98 and Macs. They don't want to spend the money to enforce it, which would mean a high-performance NAT device between the dorms and the backbone with a random IP setup.
DHCP also provides the side-effect that they get your Ethernet address from your NIC (which is supposed to be a unique number) tied to an IP address for a time interval, and when you register it gets tied to the "resident." They only want one device/person, both for security (typically unused) and cost (they want you to buy their service; if someone sets up a hub in their room and networks the general area, they don't get the money). They would also like to make people responsible for their port, so what comes through their port is their fault.
The usual setup is to have a slightly modified DHCP server that will serve crippled and non-crippled IP addresses. If you're registered, you end up with a static entry that points to working DNS servers, routers, whatever. The dynamic addresses that get served to unregistered NICs point to the registration server. The trick is to get it so your average person will boot up, bring up their web browser, and find themselves aimed at their registration server if they haven't signed up.
That is often accomplished by sabotaging Apache, setting up a fake root DNS server, and adding a few virtual hosts on a *NIX box so that any remote HTTP page gets directed to the server, where Apache drops you into the registration page for anything it isn't serving.
Know thy enemy! Many of the RESNET sites are using a slightly modified version of one package. Visit www.rit.edu/~mrcsys/dhcp and look.
Problem (for them) #1: You don't have to use DHCP. Other than by written policy and obscurity, they can't crawl onto your desktop and force you to use DHCP. You can statically configure your box to whatever works, usually by shoulder-surfing one of your friends when they have their TCP/IP control panel open. Most of the RESNET solutions are running on something cheap like Linux and using the ISC DHCP daemon.
One of the newer features that later versions have is to check and see if an IP address it is about to assign is in use. If it is, it marks it "abandoned" until 2038/01/19 (at least for DHCP v2.0b1p11). Chances are that if you grab someone's address, the server will work around you, quietly assign the victim a new address and leave you alone for 40 years. You ought to be graduated by then. The administrator has a list of addresses to hunt down, but it is probably a low priority if you're not being a squeaky wheel.
If the network folks had their way, you'd be connected to a VLAN-ready hub that can assign addresses dynamically that had lock-out security features. Plug in with the wrong NIC or more than one NIC, you get dropped and your port locked down (perhaps requiring human intervention to fix). Based on what NIC you use, you get put into a crippled VLAN or a working VLAN (depending on if you're registered). This is a much more secure scenario but it requires some additional help for the network folks.
In particular, they have to interface with whatever protocol the switch is using to assign a particular NIC to a particular VLAN (if their switch can do it at all - another equipment cost issue). Those are often proprietary protocols, with the vendor wanting to sell you their security solution. The housing folks tend to nix that extra expense since nobody has proven that their little resident inmates are criminals yet. If nobody has abused it, chances are that they won't have this type of security in place yet.
Problem (for them) #2: If you're using *NIX on a PC, can get a valid IP address once with DHCP, hard-code it and set up NAT, you can hook up a bunch of machines behind yours with nobody being the wiser. They may try to change it from time to time, but with the way the DHCP spec is written you are perfectly well within your (DHCP protocol) rights to try to use the same IP address all the way up until your DHCP lease expires. I don't know what the ISC DHCP client does on a *NIX box if it has to change the IP address mid-session, but you can probably live up to the letter of almost all their rules without any problems.
When you have a working connection (registered or not), it is time to see what you can see. The networking guys aren't giving you switched ports for performance, they're giving them to you for anti-eavesdropping security. A switched port will pretty much stop you from seeing anything that isn't a broadcast or multicast, and almost nothing of interest is contained in them although they may reveal interesting bits of information (IP addresses on that segment via ARP, other machines via SAP IPX etc.). Those switched ports cost money and some people won't pay for that. They used to cost a lot of money, so older installations are probably lacking. If you're not on a switched port, grab your favorite packet sniffer and see what there is to see. You average fellow student probably isn't using SSH.
If you're on a shared hub, you should be able to see all the local traffic from your neighbors. If it doesn't have a bridged uplink port (unlikely), then you might be able to see the RESNET back-bone traffic as well (all your neighbors). Any site that doesn't offer switched ports is at risk for all kinds of sniffing/insertion attacks.
One of the benefits of RESNET is that you're typically on the campus and can have high-speed access to the backbone. This is traditionally something that the network folks aren't really keen on. Right now, their main worry is off-site hackers since they tend to have the local machines locked down. Off-site links are a lot easier to deal with since you can drop a filter on a T1 with no real speed hit. 10 MB and above can cause a serious loss of throughput, although some newer flow-based algorithms can reduce that a lot.
With RESNET, they now have a bunch of unknown kids with root access to their (own, local) machine on a LAN who know all about their security by obscurity. That is usually a pretty big mental shift for them and they don't want to consider (budget!) costly consequences until someone holds a gun to their head. If the RESNET hacker doesn't become the squeaky wheel then they can get away with a lot.
Unlike slow WAN situations, high-speed LAN access can cause some problems for security. Any firewall or other bottleneck is going to stick out like a sore thumb when you have 500+ switched 10 MB connections trying to go through it. If you get a high-performance firewall or a lot of low-performance firewalls working in tandem, you're going to add cost which the housing folks aren't going to like. The network folks will have wanted to keep their options open, but they're probably not going to have a filter in place when people start hyping about all the cool things they're doing for the students. Bandwidth, much like disk space, tends to get filled to capacity very quickly. If they don't put a firewall in place quickly, people aren't going to want it for the added expense or the bottleneck.
You may think these non-decisions are obvious, but paper-pushers are a different breed, especially when their money is involved. They seem perfectly happy to be reactive and fix a problem after they get hit. Up-front cost is everything, and long-term savings don't mean a whole lot when you're living year-to-year on a budget. The obvious analogy of standing on the train-track and getting off before or after the train goes by is totally lost on them.
What tools do they have to track you down? Potentially lots. It really depends on the hardware they're using, their competence, and the tools they have available to them. The easiest bit of information they'll have is your IP address, since anyone who noticed will log that these days. If it is on the other side of a router, your MAC will be unavailable. If you registered with DHCP, they'll quickly track you down and turn off your port. They may be able to blacklist your NIC so you can't use it in any port.
That would be inconvenient. Depending on their router setup, they'll typically know what network segment you're on (host routes and source routes don't work too well in the modern LAN, but you never know). In your average RESNET, those tend to start out big (a building) and narrow down as required. If you haven't left a permanent record (registered) or they're not strict about what MACs are used on any given port, they pretty much have to catch you real-time by looking at ARP entries on the nearest router and bridging tables on the switches (to find out what port a MAC address is behind).
One of the security options some switches have is the ability to lock a port to one MAC address. If you're hacking with a fixed MAC on a locked port, the hunt is going to be pretty short. In your favor are convenience (public access areas, that they can't lock to one MAC) and laziness (if they have to unlock a port every time it locks, some human is going to be bored out of their mind). A few late night calls saying your port got locked for no good reason might convince an RA that it is more trouble than it is worth.
Routers are a small problem since they are passive learners and will hold onto ARP addresses long after they're out of use (10+ minutes). Switches are a little easier since they tend to clear their MAC tables when the port loses link. Do the dirty deed and drop the link. They're going to have a hard time finding out what port the MAC was behind.
Some SNMP-ready switches can send a "Trap" to an SNMP management station when a port comes up and down. This is usually disabled by default since it generates a lot of traffic and notifications managers normally don't care about. Some of the clever RESNET sites look for the link-up Trap and then start probing for MAC addresses periodically on that port. This is a pretty good proactive way of doing it. The ways they might probe are pretty custom since it usually requires someone fairly competent to set it up, so a little inside knowledge will work wonders. If they only probe once at some interval after the link comes up, you only have to wait it out and then send your traffic. If they probe periodically, you have to use your unregistered MAC in between probes and drop the link before the next probe (clearing the MAC table entries for your port).
If you can find someone foolish enough to leave some IP-relaying software turned on, by all means bounce it off their PC and use their MAC. The average fool won't be able to track you down and probably won't notice until someone tracks him down.
Switches make it very hard for network administrators to sniff your traffic even if they wanted to. Beware that some switches do have the capability to echo everything on one port out another where a sniffer can be attached. If you can take over a switch, you could use that to your advantage. Beware that some switches also have authentication traps and some keep track of various failed attempts, so someone might notice and wonder what is going on.
If the network folks got their wish and you're doing MAC-based VLANs, you're probably hosed. A good one will nuke the port when it sees a foreign MAC trying to pass traffic. They're also a lot more likely to log and timestamp MAC-to-port associations, leaving an unwanted trail of breadcrumbs to your door.
If you're not on a switch, things are going to be much harder on anybody trying to track you down, although they have different options. The bridge tables only say which side of the bridge the MAC is on. Usually you have repeated ports on multiples of 12 (often 24, depending on the age of the hardware) and a given MAC might be behind any one of them. They'd have to go door to door or eliminate everyone else and catch you in the act. If they stick their own sniffer out there, they'll be able to see everyone's traffic. Depending on your network folks, that may or may not be permitted. Many of them have some kind of privacy policy, although they can pull all the stops out if you're being a serious pain in the butt.
If you end up behind a Layer-4 switch, you have all kinds of possibilities. Layer-4 switches are usually made by vendors that wanted to get into the routing hype (and markup) but couldn't make it work. They usually only work for IP, but they make router-like decisions based on what IP address you're using. Where they usually fail is with broadcasts and the domain they're supposed to be in. You can get a lot of information leaking from network to network that you wouldn't get in a properly routed environment. DHCP causes many vendors to have fits, so it is debatable if you will find them in a RESNET environment.
One last thing to consider is using multiple MACs and/or IPs on the same machine. Once of the reasons the RESNET folks want to restrict you to DHCP and a registered MAC is to make it easy to make draconian decisions (and use MAC-based VLANs and other MAC-based security at some point in the future). One of the reasons they'd like you to use Windows or MACs is to make you use an operating system that doesn't make it too convenient to break what they consider "natural laws" (but are instead merely average and typical behavior).
If they lock out a MAC without tracking you down, they're counting on you having to spend $50 to get a new one as a significant deterrent. If you make one up (or use someone else's), that deterrent goes out the window. Most switches aren't aware of the higher layers and will lock on MACs but not IPs. Doing virtual IP addresses on a *NIX box so you have multiple IPs attached to a single MAC might exploit some fundamental flaws in their thinking and planning.
Most NICs can handle several different MAC addresses easily without bothering the CPU (mostly for multicast support). Given the right device driver, you might be able to add a randomly generated MAC to your card (so it will recognize it as itself and process its traffic) and bind your "special" applications to it. Anybody looking at your setup will see nothing unusual (no extra hubs, etc.). They'd probably have to track you down real-time and catch you in the act.
It would tweak the most minds if you use a firewall-type setup for your abducted address and only allow traffic on the ports that you are using. If someone is trying to track you down, they may try to ping you (ICMP) or use some other well-known ports. This may be the first thing they do if they're trying to decide if they can catch you red-handed online, rather than trying to pick up stale breadcrumbs. If they Telnet to your assumed IP address and it tells them your PC's name in a banner line you're not going to feel too clever. If it totally filters and ignores traffic you're not expecting, it should make it nearly impossible for them to make you reveal yourself beyond your MAC entry(s) in the bridge table.