ÜÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÜ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÜÜÜÜÜÜÛÛÛ ÛÛÛÛÛÛÛÛÛÛÛÛ ßßßßßßßß ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ²±² ±²² ±²² ²±² ±²± ²±± °±± °±± ±°° °±° °±°°±°°±°° Alternative Lifestyles ì Anarchist Philosophies ì BBS Support ì Big Brother ì Censorship ì Conspiracies ì Datapac Support ì Drugs ì Encryption Ethics ì Fiction ì Freedom ì Hacking Tutorials ì Hacking Utilities Individualism ì Networking ì Novice Assistance ì The Occult ì Paranormal Phenomena ì Politics ì Religion ì Revolution ì Scan Results ì Social Deviancy ì Telecommunications ì Unix Support ì VMS Support ì Witchcraft ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ AúNúAúRúCúHúIúSúT PúHúIúLúOúSúOúPúHúEúRúS UúNúIúTúEúD "Where Hacker and Philosopher are One." ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 Released Monday, 20 March, 1995 For the past week or so I have had several files sitting around in my APu directory. They're files that I started, but I got bored and moved on to something else. This is one of them; the others are "Unix Shell Program- ming for the Hacker" and "The Paranoia Series, Part I: Data Protection and Encryption". They should both be released sometime in the next month. This file was originally a list of security ideas in point form which I wrote down a few days ago. Yesterday I expanded these ideas into sent- ences, and added a few new ideas (of course). If you're wondering how I managed to put out two files in two days, this is how. Before I had been too worried about the size of my files, and so I gave up on some possibilities I thought wouldn't be long enough. This file, just a bit over 10k (not including this news section, the release listing, and all that), barely qualifies as long enough for an APu release. But quality is *always* better than quantity, and I think this file is definitely worth release. Writers: We are looking for more APu writers. I've done everything for APu! I've designed the layout and appearance of the files, I've written all the files, and I've distributed all the files. If APu is going to get off the ground, we need others to help us. Distributors who will 'courier' our releases around are also needed. úSine/APu (sine@free.org) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAy9GqwgAAAEEALk/hjSprZ0bsVCHZUCn1dE+w3FKtnEVJUgY9CkEOy6IpBve hFFKeM4cSlJYrHoDKgRRLLe5NZ4jEHLqdIHbThMQH0rVI/73YaXsVN/2Msk07PkD yEzAKcqoLccSQrsNj3j/GQAUqY22tLBSbwyLb9gdFBVJfAeXh6tKuMCs+sFRAAUR tCtTaW5lIG9mIEFuYXJjaGlzdCBQaGlsb3NvcGhlcnMgVW5pdGVkIDxBUHU+ =knAI -----END PGP PUBLIC KEY BLOCK----- ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Complete APu Release Listing ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ 001: A Simple Unix Decoy by Sine. Short shell script that emulates a login prompt and records the password entered. Released 5 Feb 95, avail. as APU-DCOY.ZIP. 002: Hacker Security by Sine. Basic guidelines to follow to avoid getting busted. Released 17 Feb 95, avail. as APU-SAFE.ZIP. 003: Political Correctness by Sine. A criticism of a brochure given to students about 'hate' groups. Released 20 Feb 95, avail. as APU-RACE. ZIP. 004: The Young Hacker's Guide to X.25 Networks by Sine. An overview of the X.25 protocol, as well as general information about the major X.25 networks. Released 27 Feb 95, avail. as APU-X25.ZIP. 005: Maintaining a G-Phile Library by Sine. The importance of keeping a library, tips on organisation, and a list of the best g-philes around. Released 4 Mar 95, avail. as APU-LBRY.ZIP. 006: The Young Hacker's Guide to XMUX Systems by Sine. How to penetrate Gandalf's multiplexing system and what to do once you're inside. Released 17 Mar 95, avail. as APU-XMUX.ZIP. 007: The Young Hacker's Guide to StarMaster/PACX Systems by Sine. How to get into Gandalf's network server, with possible servers and tips on hacking the console. Released 19 Mar 95, avail. as APU-STAR.ZIP. 008: Paranoid BBS Security Techniques by Sine. How to make your private H/P board completely secure from intrusion. Released 20 Mar 95, avail. as APU-BSEC.ZIP. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Requirements: All APu submissions must be a minimum of 10k in length, with at least 8k being original text (i.e., not including quotes, captures, copied charts/tables, PGP keys, logos, etc.). I will correct spelling and simple grammar errors, but not poor style; the file should be fairly well written. The file should be organised in a logical manner with headings where appropriate. The subject matter can be anything related to the list under our logo; contact me if you're not sure. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ PARANOID BBS SECURITY TECHNIQUES by Sine Released Friday 17 March, 1995 ÚÄÄÄ ÄÄÄ ÄÄ Ä ú ³ Introduction Hacking is about breaking security, not tightening it. BUT, hacker boards require strong security, because the information on them cannot be allowed to fall in the hands of novices, or even worse, informants. Making security modifications would be easy if you could write the BBS software from scratch. But that isn't normally possible, so you'll have to make do with what you've got. The procedures described here are basic and apply to almost any BBS software. I won't go into any detail of the actual modifications. Many of these security measures are quite extreme, and only apply to boards where security is of the utmost importance. If you're operating a public board with 200 users, none of this will work, because all the secret methods of getting in will quickly become public. If you have not yet decided whether your board will be private or not, I hope this file will convice you to make it private. Private boards allow users to be more free with information, they keep out lamers and warez d00dz, and most importantly, they keep out narcs and informants. There are already enough public H/P boards out there, so freedom of information is not the issue; making your board last is. NOTE: There is one obvious security method which I will not talk about here, and that is callback verification. This may work on warez boards (pir8s use PBXes without diverters, so they're usually quite free with their numbers), but no self-respecting hacker will ever give out his phone number for CBV. It just isn't done. ÚÄÄÄÄ ÄÄÄ ÄÄ Ä ú ³ The User Base "People are the weakest link in the security chain." As clich‚d as that quote is, it is more or less correct. You could have a system with a dozen passwords, and it would stop brute forcing quite well, but if one of your users leaked the passwords the whole system would be compromised. Having a knowledgeable and trustworthy user base is probably the best way to protect your board. The problem is finding the right users. Most boards have some sort of new user test to weed out the lamers who are calling for warez or Gifs. If you do this stay away from the acronyms, which can be found in files anywhere, and questions where it's easy to lie (like "What systems are you familiar with?") Instead ask open-ended questions that require knowledge like "In 5 lines how would you hack an account on the Internet?", or "Define the X.25 protocol." A better idea is not to allow new users at all. Instead, you and your friends can call around to the best H/P boards, looking for knowledgeable users. You can then set up an account for them on your board, or, to weed out impostors, you can tell them to call you voice (since they know your board number, your voice number is hardly private anymore) or meet some- where (like on IRC or some other system with Chat functions). There you can ask them a few hacking-related questions to test their knowledge. I suppose you could do it by e-mail, but that would be a bit like being able to take a test paper home from school and filling it out while using your textbooks for reference. Keeping your user base small is probably not as important as getting rid of inactive users. Preferably you should delete users that don't call for two or three weeks, and then meet them somewhere else and ask them what happened. The same goes for users who call but don't post for a long time; it's possible that somebody else is using the account to download the files, but is afraid to post messages because it might reveal who he is. A small number of users keeps the board more private and means less busy signals. Under 100 is acceptable; under 50 is better, and under 30 is ideal. A board with a small number of active users allows strong ties between the users, with everyone knowing everyone else. This makes for more and better messages, and a more friendly atmosphere. ÚÄÄÄÄÄÄÄ ÄÄÄ ÄÄ Ä ú ³ Precious Secrecy The best way to avoid getting your system hacked is to make sure no one finds it. If no one knows about the system except the users themselves, you will not have to worry about anyone trying to break in. This is the ideal situation, but like all secrets it very difficult to maintain. You can, however, do several things to help keep the board secret. If you're contacting your potential users over another BBS or network, first ask them for their PGP encryption key, and send them your invitation encrypted. Most sysops don't peek at messages, but the small amount of work required to encrypt the message will save you a lot of trouble if he does. For further messages, create a key assigned to your BBS, and send both the public and secret keys to each of the board's members (encrypted in their personal key, of course). The public key can be extracted with pgp -kx and included. To send the secret key, encrypt it with conventional crypto- graphy (pgp -ca), and include it with the passphrase in your encrypted message. Now you can post announcements about your board in public places, and all your members can read them without worry of detection. You need to label the message somehow so your users know that it's for them, but DON'T say "Message to the users of x bbs"! Instead say something generic like "To whoever has the secret key for this, you know who you are". (Isn't PGP wonderful?) ÚÄÄÄÄÄÄÄÄ ÄÄÄ ÄÄ Ä ú ³ First Impressions No matter how secret you keep your system and its phone number, it's possible that a scanning hacker will stumble on it. A very easy way to avoid this is to set your modem to wait at least four rings before answering. The wait may annoy some users, but it is almost certainly worth it. Think about it: waiting for a few extra rings is a lot faster than waiting for a busy signal to stop when some scanning hacker is playing around with your system. Eventually, there's a good chance that someone will find your board, whether it's because of a leaked number, a *very* patient scanner, or pure accident. In this case, you want to make your system look as boring and unattractive as possible. In other words, you don't want it to look like a BBS. (You'll have to give up FrontDoor, of course.) The best way to accomplish this is to add the security of a general pass- word. The prompt should be something bland and unrevealing, preferably a single character, like !, @, #, $, %, &, *, -, +, =, :, >, ., or ?. Absolutely no information should be given before this prompt. Someone calling who is unfamiliar with your system will probably think this is some sort of strange OS, and he will try the usual commands like HELLO, LOGIN, etc. But that's not what this prompt is for. It's the prompt for general pass- word. This is a password that all your users know (given to them over the phone or through encrypted transmissions, of course). It should be at least eight characters long, preferably more, with at least one number. The call should be disconnected after 2-3 errors (allow at least one error, because it's sometimes necessary to press enter a few times when you connect at 2400 baud or less). All errors should be logged, along with the data entered. This is to see whether the entries were possible user errors (such as nothing but return, or the general password mistyped), or somebody is snooping around (things like LOGIN, SIGNON, HELP, and control characters). Ú ÄÄÄ ÄÄ Ä ú ³ Passwords There is almost no chance that anyone could guess the general password, because he would be detected by the logs a *long* time before he could brute force it. But it's possible that the intruder saw the password written down somewhere, or he overheard a user talking, or a user was sloppy and mentioned the password by accident. Whatever the reason, you must have username/password prompting, if for no other reason than to prevent your own users from impersonating each other. A major weakness in almost all BBS software is that you are always told if you enter an invalid username. It's also fairly easy to guess these user- names, by trying handles. While guessing passwords is a different matter, the intruder will still be able to find out who's on the system (or rather, who *isn't* on the system) by experimenting with different user- names. So, if at all possible, don't tell the user whether the name he entered is correct. If it isn't possible, add a few random characters to the end of the username so the intruder can't simply guess handles (e.g., SINE might become SINE KH1). A problem with many BBS programs is that they allow you to enter your user number instead of your handle for quicker access. In this case the intruder can try user #1 and start guessing passwords ... because as we all know, user #1 is almost always the sysop. Disable this option if pos- sible. Before accessing your board for the first time, users should send you their desired passwords in an encrypted message. The passwords should be a minimum of 8 characters, with at least one number, and differences in capitalisation if the software allows (i.e., not all caps or all lower case). If I had to pick a single thing that hampered brute forcing more than any- thing else, it would have to be being logged off after 1 bad attempt. For a legitimate user of your board, having to call back is a minor inconven- ience; but for an intruder, it makes brute forcing almost impossible. For additional security: after entering the password (the user won't be told if it's correct or not), the user must enter his own ten- or twelve- digit security code. The security code is a random alphanumeric sequence, impossible to guess. It can be sent to the user encrypted when he first joins the board, using the methods I described above. To slow down brute forcing (in case someone is foolish enough to attempt it), you can have a 1-2 second pause between these three prompts. Log all unsuccessful login attempts fully, with date/time and the username/ password entered. Like general password errors, you need this information to tell whether it's a user making a few typos or an intruder guessing. ÚÄÄÄÄÄ ÄÄ Ä ú ³ Conclusion With all these paranoid techniques in place, I'd say your system is more or less airtight. Remember, though, that hackers can be socially engi- neered too, and the biggest hole in your security is the manipulation of your users. Sometime soon I'll start working on a BBS program written in Unix shell (!) that includes some of these procedures. The good thing about Unix is that I don't have to interface with the serial ports myself; the Unix daemon 'getty' handles this, and then the user logs on to the Unix system as 'bbs', an account I have set up with my BBS program as the shell. In my release (which should be out in the next few months) I'll also include full sysop and user documentation. Have fun, úSine/APu (sine@free.org) ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Call these boards for the latest APu releases: Lisboa-X (416)604-7495 The Hayden Andre Project (905)513-9726 <- not available Total Mayhem (905)940-2079 <- not answering Digital Decay (714)871-2057 Nostalgia (206)747-9847 Plasma (206)565-7678 Hack-Tech (503)567-4250