Tools and tales from the days of dialup Internet
Yesterday, I mentioned some friends who had rigged up a program to let them download stuff over a badly-configured serial connection. I forgot one key piece of the puzzle: they were uuencoding the data first, so that their terminal program's "log to file" would be able to catch it without any funny stuff happening. Then they'd just uudecode it and use their file.
In the same theme of weird hacks rigged up by friends, here's another one of a similar vintage. This particular person was working at an ISP and they had a problem with dialup abuse. Basically, their accounts were simple enough: you pay for one account, and you get one login session. People were nailing up two or three calls and were abusing that policy. Something had to be done.
This ISP's dialup terminal servers were already pushing details of connections and disconnections to syslog, so it was just a matter of watching those logs to see what was going on. My friend wound up writing something which basically did a "tail -f" on one of those files and kept track of what it had seen.
The logic was simple enough: when you see a login, remember it. When you see a logout, clear it. If you see a second login, then spring into action and kick it off. This was a good first cut, but it would occasionally misfire. A small adjustment added time-of-login tracking, and would then boot off the oldest connection. That way, if your session got stuck and you redialed, you'd just sail on through without a care in the world.
However, if you were abusing your account and had multiple people trying to use it at the same time, they would keep kicking each other off. It was a great scheme. After doing that a few times, they'd have to figure it out sooner or later. Finally, it was smart enough to know that ISDN customers are allowed to have two channels for bonding purposes, and it would not trigger on them. It was pretty clever.
I also ran a dialup pool at one point, but my users were different. Most of them were teachers and few of them were the sort of technical ninjas you'd get on an ISP's dialups. I only had to do spot checks to look for signs of insanity: multiple logins, logins lasting more than a couple of hours, logins on the dialups when they're also at the office, and so on. Mostly, I was looking for compromised accounts.
One time, I caught someone who had two simultaneous connections nailed up with Kazaa/Morpheus running full-tilt. While we had a whole bunch of lines and a decent amount of bandwidth to the world (as compared to the tiny dialup pipes they had), it was still inappropriate use of our resources. There couldn't be any educational value in using the system this way. Also, the use pattern made no sense. Users who only check mail from a school computer biweekly are not the same people who bond lines and run warezing programs.
I decided to have a little fun. First, I set this account up to get a static IP address... a non-routable one, that is. Upon dialing up, this user got 192.168.1.1. This was completely useless on our network, since I had it filtered as the bogon it was. I also ran egress filters, so they couldn't spew garbage to the outside world, either. Doing this broke the dialup access while leaving my user's POP access alone.
Whoever was using the dialups just kept redialing over and over, so finally I just locked the account. I figured eventually the real user would get in touch with us through her local tech support channels, and we'd figure out what had happened.
Later, I found out that our actual user had been out of town for two weeks. Apparently there were "a couple of teenagers who dial in". I assume there was a lecture about appropriate use of public school district facilities, and things went back to normal thereafter.
After all, they could always get a "real" commercial dialup account and do whatever they liked without involving taxpayer-funded systems. It's not exactly rocket science.