The one time I got locked out of the university's computers, around 01994, it was for doing this. Someone, I think ncftp's Mike Gleason, had written a program

The one time I got locked out of the university's computers, around 01994, it was for doing this. Someone, I think ncftp's Mike Gleason, had written a program called `ison` which would run in the background, fingering a given user@host every minute; once the response indicated that the user was logged on ("was on", thus the name), it would print a message to your terminal and exit. If you logged off first, it would exit automatically. There were three girls I would regularly chat with on IRC, so I put `ison` invocations into my .tcshrc (or maybe my .profile, I forget), so that I could hop on IRC whenever one of them logged on, or `talk` to them if they weren't on IRC. But I thought a minute was unreasonable latency, so I reduced the interval to 15 seconds; I forget if this was a command-line flag or a modification to the source code. So, when I would dial in from home, running a single Unix shell, I would spawn three `ison` processes, which would each finger every 15 seconds. Unbeknownst to me, `inetd` forking and execing `fingerd` on the remote hosts in question, followed by `fingerd` checking all the relevant information, took on the order of a whole second of computation — one of the remote hosts was a VAX, one was a Sun workstation (probably a Sun-4, but maybe a decrepit old Sun-3), and I forget what the third one was; each was serving between ten and sixty concurrent interactive users, as I could see by fingering @host. So, at this point, I was unintentionally making these machines noticeably slower for their everyday users. However, the university also had computer labs full of X-Terminals running X-Windows. And the way you use X-Windows (then and to some extent even today) is that you open terminal-emulator windows with shells in them so you can run your commands. And my university had actually about a dozen compute servers for use by any of the students, which were mostly DECStation 3000s, but later on also included some RS/6000s. Typically some of these machines would be more overloaded than others, so you would open shells on several of them — either by opening xterm windows on them, or by telnetting or rlogining from one to another, this being before the adoption of SSH. So it was not terribly uncommon for me to have 5–15 shells open on various computers in the computer center. Each of these shells had its own associated `ison` process, and when one of my friends would log on, over the next 15 seconds, all of those `ison` processes would exit; so, too, if I logged out of my session. But, when they weren't logged in, I would be launching as much as one `finger` request per second split across many different hosts, a quantity which amounted to a distributed denial of service attack on the remote host. My first clue that something was wrong was that, one day, I attempted to log in, only to be confronted with a notice that my account had been locked, and to please contact the security officer at the computer center. I just about wet my pants. The system administrators at the other universities had apparently tracked down the sporadic unusability of their public Unix hosts to high load from many concurrent `fingerd` processes, logged the sources of the `finger` requests, discovered that they were coming from a variety of hosts at my university, and contacted the system administration staff there, who I believe then added logging to `finger`. But `ison` didn't invoke `finger`; it made the `finger` requests directly, and there wasn't a straightforward way to add logging to the `connect()` system call (both Ultrix and AIX were proprietary, and I believe source code was unavailable — and recompiling libc might have seemed like an extreme and risky measure). So, as I understand it, the way they figured out what was going on was incident response — when their machines became unusably slow, the sysadmins at the other universities would telephone the sysadmins on my university, hopefully telling them which hosts were DoSing them, and the sysadmins at my university would then log into those hosts and try to figure out which process was responsible. Often, though, by the time they looked, I would have already logged out. This combination of using a C program I'd compiled myself to launch the "attack", distributing it across various hosts, and running the "attack" at unpredictable times of day and stopping after apparently random intervals, added up to the profile of a sophisticated, malicious computer-security threat actor, in their minds — although I found out later that using `bash` as your login shell was also sufficient for that. In a long, heartfelt conversation, I was apparently able to convince the security officer that my "sophisticated attack" was entirely unintentional and that, indeed, I had no idea that it was causing any sort of problem, and he unlocked my account. But thereafter I had the reputation among the sysadmins of being a "hacker". A few years later, one of the computer center staff from that time was working as a sysadmin in Silicon Valley, and he recommended me for my first sysadmin job at a time when I was washing dishes in a Midwestern café for a living. Genuinely changed my life for the better. So I guess that reputation wasn't an entirely bad thing.