Hackers Information Report Issue Number Ten Introduction ----------------------------------------------------------------------------- Hackers Information Report is an electronic magazine that's distributed free of charge over the Internet and bulletin board systems. It is produced by a group of real hackers and phone phreaks, and only discusses ethical hacking and phone phreaking techniques and information. We never cover steaking, blowing things up, or system cracking directly. Some of the information that we publish might be able to be used in a negative fashion, but we provide it to be used in an educational, ethical manner. We may publish some "Walk Through" hacks and tricks, but we really attempt to describe a given system in enough detail for the reader to gain their own information on the topic, rather than just spoon-feeding the masses. Think of it as "Priming the Intellectual Pump". ----------------------------------------------------------------------------- HiR #10 Release notes. We've really fallen behind. We aren't dead, nor will we be for some time. Due to a very unfortunate turn of events, we've had some major problems producing good articles and getting them out in any sort of timely manner. First, Axon has been moved around to a position of higher responsibility, as well as taking 10 Credit hours of college classes and holding down a second job. This leaves very little time for writing. Next, he was also asked to remove the HiR Distro site from his place of employment. It was thought that the material that was presented may result in legal problems. (I really doubt it would have but that's the breaks.) We've had a few other website offers, and we're trying to get the site up as fast as possible. This involves copying archives and unpacking them, as well as some other evil stuff. ============================================================================= Article Title Author ------- ------------------------------------------------- ------------- 1 HiR 10 Intro/Table of Contentz HiR Crew 2 HiR 10 Informative Resources Axon/Frogman 3 Defcon 7 in a nutshell Asmodian X 4 Flying Below The Radar: Avoiding IDS Systems Axon 5 BeOS Revealed (Yes, another OS Overview) Axon 6 RISC, CISC and The concept of the Power-PC Asmodian X 7 Setting up your Home-Net Axon 8 The Official HiR FAQ, Version 0 Axon 9 HiR 10 Hacker Newz HiR Crew HiR 10 Informative Resources Books Worth Reading: ------------------------------------------------------------------------ TCP/IP Illustrated, Volume 2 (by Gary R. Wright & W. Richard Stevens) Publisher: Addison-Wesley Publising Company ISBN: 0-201-63354-X Reading Level: Advanced, or able to learn quickly Cost: Unknown. This book may be out of print. I Borrowed this book from a local library system. Overall Rating: ### (Three Roots. Lots of info, but kind of confusing) TCP/IP Illustrated, Volume 2 is a down-and-dirty look at the BSD UNIX TCP/IP stack. It covers the source code, and adds illustrations, and clearly defined explanations of how the different parts interact. After reading this book, I had a very thorough understanding of the TCP/IP Protocol Suite (Including TCP/UDP and ICMP). This book is a MUST read for anyone who is serious about programming Internetworking Tool in the C language. After playing with *BSD, I now realize why this book is written around the BSD TCP/IP stack, as it has to be one of the most solid implementations of TCP/IP that I've ever seen. It's very rare for bugs to occur in the BSD TCP/IP Stack, unlike some other company that has recently been releasing overpriced operating systems... with *BROKEN* TCP/IP Stacks. =] ------------------------------------------------------------------------ The Complete FreeBSD (Revision 3, Covers FreeBSD 3.2) by Greg Lehey Publisher: Walnut Creek CDROM ISBN: 1-57176-246-9 Reading Level: Beginner to Veteran Cost: About $70 US Dollars (See below) Overall Rating: #### (4 Roots! Completely packed guide to getting started, and getting used to using UNIX every day, Lacks information about Laptop/Portable Computers) The Complete FreeBSD Revision 3, comes with the entire 4 CD-ROM FreeBSD 3.2 set. This retails for around $50 US Dollars if you buy the Boxed set from Walnut Creek CDROM. The First CD alone is available for a lot cheaper elsewhere, but having all 4 CDROMS is a useful thing, as you don't need Internet Connectivity to install Ported software. The Book itself is enough to get a UNIX Newbie going strong with FreeBSD, or a Veteran Linux (or other UNIX) user Comfortable with FreeBSD. As you've seen in past Articles in HiR, FreeBSD is one of the most stable and fast Server-Oriented Operating Systems out there. This book is one of the best I've seen, as far as getting going with FreeBSD. It teaches you the fundamentals of getting your UNIX server up and running, how to use it as an every-day Operating System, and how to establish Internet Connectivity Via Serial, Modem, or LAN. It also has a VERY organized and well-written guide to compiling a custom kernel for your machine, as well as entire chapters outlining Network Troubleshooting and Network Firewalling. *** Late breaking news! *** The cost of this book can be dramatically reduced. It seems that CompUSA has gotten ahold of it, and is selling a product called "The FreeBSD Power Pak", which contains this book, "The Complete FreeBSD", plus the Four FreeBSD 3.2 CD's, ***AND*** A Six-CD set that i386/Intel Release Snapshots, Complete CVS Tree, more than 1,500 Pre-Compiled packages, and more than 2,200 Ports (Source code that's been patched to compile on FreeBSD). The total cost at CompUSA last I checked was only $49.99. The Walnut Creek CD-ROM Catalog inside listed the same package for Almost $100! Buying each one of these items alone (The Book, The FreeBSD OS and The FreeBSD Toolkit) would total $130, so Either way, it's a good deal. *************************** ------------------------------------------------------------------------ CGI Programming for the World Wide Web (Examples in Perl) Publisher: O'Reilly & Associates ISBN: Reading Level: Moderately Programmer Minded (Too hard for Newbies and not advanced enough for coding Gurus) Cost: Overall Rating: ### (Three Roots). This book is one of the most well structured CGI Programming books I've read to date. They tell you everything you need to know to do CGI programming in a variety of languages, with some killer examples in perl. You'll be introduced to setting up Forms in HTML, making it reference a CGI backend written in whatever language you choose. They show all their examples in perl. This isn't really a good book if you've already got a lot of programming experience. I would advise skimming it if you know how to program but don't know how CGI works yet. Total coding newbies should stay away from this book unless they have a lot of Advil, because, well... perl just doesn't make sense to someone who just learned VB. ------------------------------------------------------------------------ The Ultimate Internet Terrorist: How Hackers, Geeks, and Phreaks Can Ruin Your Trip on the Information Superhighway . . . and What You Can Do To Protect Yourself Merkle, Robert 1998 Paladin Press ISBN 0-87364-970-2 141p Well, not quite the U.I.T. that you get at the Blackhat meetings at DefCon, but you get an idea of how script kiddies work, and some authorative tips on working the net to your advantage. Merkle teaches people ideas from the Hackers Manifesto, and he was a part of a hacking group, VCA, under the handle 141.187. Rather than getting into the meat of the book, I'll just say I liked it and the open, conversational tone in it. To give you and idea of what it is about, here are some chapter titles: Terror Mail in Cyberspace: The Anatomy of the E-Mail Address The Wonderful Art, Life, and Science of Downloading There are other, more menacing chapters in the book, but I would still call it reccomended reading for anyone who has not spent the past year or two working on learning the kinks of the net. One thing that stood out in this book though, is the last page: All hail Bob! ------------------------------------------------------------------------ Atanasoff: forgotten father of the computer. Mollenhoff, Clark R. 1988 Iowa State University Press ISBN 0-8138-0032-3 274p This is good for history buffs, and those who never quite believed the story of ENIAC. Mollenhoff relates the story of the Atanasoff-Berry Computer at Iowa State University, and how Mauchly visited and studied the machine, eventually turning the ideas into the ENIAC and EDVAC. It also provides transcripts from the federal investigation and case over the patents held by Sperry Rand based on the ideas Mauchly took from Atanasoff, including base 2 (binary) counting system, condenser (capacitor) memory with "jogging" or regeneration or refreshing cicuits, use direct logical action for computation, and electronic instead of mechanical operation. It's kinda dry in that history book genre, but it makes alot of history clearer that they never quite told you in Intro to Computer Science. ------------------------------------------------------------------------ ANARCHY ONLINE net sex/net crime Platt, Charles 1997 HarperPrism ISBN unavailable net crime 156p net sex 211p This is an unusual setup for a book, the two sections are back to back, each rotated 180 degrees so you can read the book from each cover to the center. Other than that it is a compedium of events and people in each of the sections, basically a modern history for the past two decades. I liked it, but thats because I like histories and the like. This one is a much more enjoyable read than the Atanasoff book. TCP/IP: Running a Successful Network Washburn, K. and Evans, J.T. 1993 Addison-Wesley ISBN 0-201-62765-5 537p I didn't finish this one, but it is basically a text book on IPv4. It covers every layer of the TCP/IP and ISO OSI models. It gets down to the bit level structure of the datagrams and explains the use of TCP and IP over many network platforms, esp. Ethernet, X.25, and Token Ring. It gets a little technical, but hey, it's a textbook. This is great if you want to know how TCP/IP as a standard works. ------------------------------------------------------------------------ ---- Defcon 7.0 In a Nutshell. By Asmodian X Defcon is a convention held yearly in las Vegas usually in July. It is promoted by Dark Tangent and his Defcon Goons. For more information about Defcon consult: http://www.defcon.org In concept, Defcon is a gathering of computer enthusiasts, paranoid people, and people who just want to be in the lime light. Ironically the majority of these people call themselves "Hackers." Weather any of these people can create furniture with an axe I do not know. (See Dictionary definition) The Ride to Las Vegas My commerads and I boarded the airplane around 11 or 12pm and plopped down in our seats. Axon and Frogman plopped out their new(er) laptops, and proceeded to poke around with articles and other projects. Meanwhilst I was playing around with Twiggy (a Cassiopia E-10 Palm-PC). Twiggy was a new acquisition of mine, and I was playing solitaire and setting up a profile for myself in the case some one wanted to exchange electronic business cards. Frogman had a similar device which was made by Everex. Needless to say, the ride was un eventful. -=- Arrival -=- We arrived at Las Vegas and walked to the luggage area. After picking out our luggage pieces, we walked over to the Taxi area and picked up a Taxi over to Alexis Park. Where we were surprised to find that we had to pay a 400$ deposit. After scrimping up enough cash we waddled over to our room. It was a two bed room with a quasi kitchen. It had an empty refrigerator and cabinent with a convenient empty 6 pack of bottles. We all hoped into one of the Whirl-pools, and relaxed for a bit before heading back to the room. I crashed on one of the beds, and axon and frog man poked around on laptops until about 7ish in the morning when we picked our selves up and walked over to the convention center. Alexis Park was really nice, it had rained a few inches a day or so back, so of course everything flooded out. The fountains looked rather polluted, and some of the pools were shut down. After getting some over priced breakfast we waited in line until 10am when they actually opened the doors. During that time, it began to rain, which was a serious problem to those who chose to haul their laptop with them. Las Vegas was rather muddy from the floods which had pre-ceded the Defcon crowd. The ran had made the fountains polluted. The hotel staff scurried around dumping a cleaning compound into the murky fountains. By night fall the fountains were clean again. The kick off was pretty cool, everybody got metal tags and lanyards, which beat the hell out of the lame plastic tags during DC6. Hordes of Tshirt sales tables were there. If I had any cash left I would have gotten the Shell oil spoof shirt (e.g. Shell -> /bin/sh) We probably would have gotten more stuff if it were not for the hotel rapeing us for the deposit. 400$ is not worth the P.O.S rooms we got, but we were happy enough to be there not to complain. -=- The Speakers -=- This time it was a bit more compartimentalised than it was a year or so back. It had three tracks, newbie, intermediate and advanced. My only regret was that we could not compete in the Capture the flag contest, primarily because everybody wanted to see the speakers. Not surprisingly the ghetto hackers won, purely because of numbers. (No disrespect of course.) Now a few words on the widely disliked Caraloyn Minel, which I can attest that Mrs. Minel is in fact, the closest thing to a true bitch that I've ever met. I could theorize possible causes for MBD (Massive Bitchness Disorder), but you probably all know about that. In-case you don't, I suggest you consult "http://www.attrition.org". (BTW. Carolyn got thrown out of defcon due to refusal to provide any services on her CTF box, she was under the impression a brick on a rope was an acceptable CTF target boxen.) I found the Identity theft speaker the most interesting. His speech made me glad my credit rating sucks. Professor Feedlebom, made his speech about pirate radio amidst a hangover. It was un-interesting, and would have been better sans booze. The how to use nmap similar was boring as hell, it didn't get interesting until fydor showed up and answered some questions. The Oracle stuff was power pointed, and thus boring as hell. I noticed a trend. "Professionals" used lame power point presentations, the developers and grey hats were the MOST interesting because they could answer anything about the software you wanted to know. The newbies generally were hard to follow, due to lack of planning and shuddering. As a note to future speakers who read this, be considerate of your audience, I don't use Microsoft products, thus ppt presentations are pointless, it would be more convenient to me to have something like a text, or some Unix friendlier document. -=- Food and stuff -=- Because of the hotel raping us, we could not afford to eat out. So we made do with some instant Mac&cheese, and some PB&J we bought from a grocery store. Of course the hotel practically required a down payment for the food. We ended up living at a convenience store down the street. -=- Transit Hell -=- 30 hours + bus + psycho-driver = hell. nuff said. -=- Epoch -=- It was an enlightening experience, I want to go again, next time I am bringing more cash, better laptop, and more people. And food that requires less preparation. Aegis, my laptop, made it, but it was dwarfed. With luck,By the time DC8 is going on, I will have my new(er) laptop, (deacon) and/or something newer. Axon talked about bringing an IBM rs/6000 work station to the con for some extra muscle for crunching passwords. The frogman, will be bringing on his new(er) laptop an IBM thinkpad to join in to the fray. I'm expecting another friend of mine to come along and check out some of the speakers. HiR10 Flying Below The Radar By: Axon An introduction to not setting off IDS Alarms So, you've done your hacking homework, and you're seeing that it's getting harder and harder to find a good place to poke around and play, because everyone and their CEO has hopped on the "Intrusion Detection System (IDS)" Bandwagon. These systems look for odd activity, or "anomalies", as they are often called. "IDS"'s have been around for a dreadfully long time, it's just that they were never categorized as such until recently (Just like there have been chevy blazers for a long time, but the category "Sport Utility Vehicle" didn't exist until very recently, so they just called it a truck until some better title came along). Intrusion Detection Systems go back to the days of portscan loggers, and scripts that administrators would set up to look at system logs for remote and local anomalies. This could be anything from excessive amounts of incorrect password guesses using "su", to having pre-compiled software in their directories, or set-uid binaries laying around where they shouldn't be. Basically, any tool that looks for bizarre patterns in system useage or network traffic can be called an IDS. At this time, I will only be discussing the type that watches for network traffic. Intrusion Detection Systems may or may not mean that there is a firewall in place. Some system administrators rely only on IDS methods, whereas the smarter portion of them still use some method of a firewall. If a firewall is in place, the IDS also may communicate with the firewall, telling the firewall the attacker's IP Address and letting the firewall take care of business. (Please note that I'm speaking of "firewall" as a concept, not a piece of hardware. It's fully possible that IDS software runs on a machine with packet filtering capability as well, and therefore only interacts with control structures for the packet filtering subsystem) There are a few free Intrusion Detection System programs available for UNIX, and plenty of rather inexpensive (but not free) ones as well, for UNIX and Windows NT. There are also plenty of VERY expensive Intrusion Detection systems, too. When you decide to "explore" a network that doesn't belong to you, you have to do your homework. This is a major thing! Remember that hacking is not a hobby, it is a way of life that requires hard work, long hours, patience, perserverence, and a healthy dose of reading up on your potential target. The problem is this: most IDS's will set off alarms if it sees typical "script kiddie research", where most people go for tracerouting, portscans, and TCP OS Fingerprinting. This is not suitable when trying to keep the IDS from immediately flagging you. The first thing you want to know is what OS they are running. This narrows down the choices of IDS they could be running. We are going to operate under the assumption that you have no clue if they have an IDS setup, yet you are trying to remain as stealthy as possible, for safety's sake. Once you know what IDS software they are likely running, you will have a better idea of what you can and cannot do. TCP Fingerprinting (using things such an NMAP's OS Fingerprinter, or "QueSO") sometimes works without seting off any alarms, but it requires that you know an open port (NMAP doesn't require an open port, but it DOES perform a portscan that WILL set off most IDS's). Usually a TCP fingerprint test sends 6 STRANGE packets to an open port. Certain loggers can detect these bizarre patterns of packets, and some IDS's will pick up a quick burst of packets as a Denial Of Service Attack, and you're nailed. That's Bad. Don't risk it. If all else fails, try to setup as many IDS's as possible, and see if QueSO sets it off. More on this later... Even if a lot of the target's stuff is behind a firewall, the Web creates an iris of opportunity, where you, the creative hacker, may be able to get a little more info. No normally configured IDS will pick up normal web surfing as an "Intrusion" unless you try to access restricted pages. This means to feel free to surf around and look for stuff. Abuse their "Search" website feature, if available, and look for a brag session where the company CEO puts a page up explaining how he's proud tha they just bought some new X brand server running , and how it's un-hackable. If you're lucky and they are stupid, they will even tell you what IDS they use, right there on the webpage. If this doesn't work, you may want to attempt coaxing a version response out of their web server. This is a chunk of BASH Shell Script (originally called "httpdquery" that my pal Razathorn Threw together for me, it picks out HTTPD Server Version numbers from error messages. Running this once against a system with a web server running would normally not set off any alarms: it's syntax is: httpdquery hostname.com (port 80 is hardcoded into the script) __________________________CUT HERE_________________________________ #!/bin/sh NOTE=/tmp/.httpdquery-$$-$RANDOM export NOTE touch $NOTE (echo -e "http / 1.1\n";while [ -f $NOTE ]; do sleep 1;done) | (telnet $* 80 2> /dev/null| grep '^Server:';rm $NOTE) __________________________CUT HERE_________________________________ My Fairly basic RedHat 5.2 Workstation gives this response: Server: Apache/1.2.6 Red Hat That's kinda bad, Really. You just got a close look at what OS is most likely being run, just by using a standard http get. This means that it's most likely a linux system, or there's someone on the other end that wants you to THINK it's a Linux system, and is rather intelligent about changing Server Version Responses. There are other ways of trying to figure out what OS they are using on the server you wish to play with. These can range from Social Engineering techniques to "Dumpster Diving", or any other method you can think of. Please note that not all web server daemons will barf out a version response like this. If all that fails, you may want to Social Engineer some info out of employees or other people. Once you find out what OS they are most likely using, go to your favorite massive search engine (I prefer Dogpile.com and metacrawler.com, myself. These two search tons of different search engines at once), and look for IDS software for that OS. You need a test machine. Try to set up a machine with a similar configuration. Obviousely it will be hard to know exactly what IDS they chose, or the coniguration that was used. If you can disconver this information, your job just got easier. Like I said before, you need to set up a test machine for your own evil purposes. Give all the IDS software packages a try, and see what features it offers. Your goal is to see exactly how far you can push the IDS without setting off any alarms. Don't worry about logs yet. Most admins that use IDS software won't look at the logs unless the IDS pinpoints an IP address as one that was attacking, and then they use system logs to see exactly what was going on, a little closer. You need to try portscanning it, using QueSO and NMAP OS Detectors, Try different stealth portscanning techniques, and anything else you can think of. See how long of a delay you can use between ports on a portscan, and randomize what ports you use. Many people will scan just one port every 3 hours or so, in random order. By the end of a day. you could have a difinitive answer about 4 or more different services. With a really paranoid sysadmin and the right IDS, even this kind of scan can lead to being scrutinized. All things considered, once you know what OS they are running, a check on just a few services will tell you an awful lot if you know what you're doing. If you know it's solaris, then you look only for "buggy" solaris services to try to exploit. You don't go searching a solaris server for a linux-specific exploit, do you? This process is known in the Info-Sec business as a "slow scan", where a would-be hacker is really taking their time. This kind of scan is becoming more and more popular, and the IDS industry probably is not far behind. I know some IDS systems can be set to look for slow scans, but they only detect a slow scan if it can find a pattern (for instance every 2 hours and 42 minutes (roughly) it picks up a connection to a different port from the same IP Address, and this happens for almost a whole day... some IDS can be told to red-flag this type of activity) There was just a CERT Advisiory released no long ago, about "Distributed Scans". These are relatively new. Check out SecurityFocus.com, and CERT.org for information regarding this type of scanning. I do believe that SecurityFocus's tool archive contains some cool programs for doing a Distributed Scan. Another Variation that sometimes throws off an IDS is using the proof-of-concept scan and sniff approach, where you portscan someone with a spoofed IP Address of a machine on your local segment. if you are sniffing, you will see the results of the portscan, even though they were not destined back to you. This shows up in system logs and to IDS systems as if it were not your machine portscanning, but someone else's... sometimes. If executed properly, it's possible to spoof several machines on your network, doing a slow scan, with (apparently to the IDS) different IP Addresses. This approach would normally be inconspicuous enough to fly below the IDS' radar. There is a tool out there that does this, but I cannot remember the name. I think I found it on packetstorm some time ago (http://packetstorm.securify.com). Another option, similar to the aforementioned one, is to use different internet access methods. If you have internet at work, scan one port from work. Once, that's all. Go home, use your dialup account to do it again, just one port. Go to a friend's house if they use a different ISP, and do it there, too. If you take your time and execute this part very carefully, there will be no (or very little) cause for alarm as far as your target is concerned. This can also be executed if you have friends on the phone or in IRC, you can say "hey...check to see if port 25 is open on yourmomma.com!" Some things to look out for: Sysadmins can be real bastards (trust me, I'm one of them!). At times, they do something so unheard-of and unbelieveable that you can't accept the fact that you've been had. One of these many things is setting up a hacker trap, where a "trophy" is just laying there, waiting to be taken. There are various names for such a setup, but one of the more popular jargon terms is "Honey Pots", christened because of their likeness to pots of honey that hikers would place far away from their sleeping area (but close enough together that a bear would run into one of the honey pots before it ran into the weary campers). It would distract dangerous bears from the camp area. Sysadmins (being sometimes the sadists that they are), will plop a 486 on the network, and make it appear to be running buggy versions of certain services. While these may or may not really be running the services, the would-be hacker sees this supposedly "easy rooting" and spends a fair amount of time messing with this system, and while this is happening, alarms are going off, and people are being e-mailed and paged. The system might be putting firewall rules into place to make sure you are denied access to anything more important than the one lowly decoy, too. Basically, There are only a few types of IDS systems: Type of IDS Functionality Software that does this: ----------- --------------------------------- --------------------- Loggers (just keep track of scans, etc) tcplogger, scanlogd Reactors (takes action upon scanning, etc) portsentry, NSW Dragon Integrity (checks integrity of system files) tripwire We're really looking at loggers and reactors here. Once you've obtained any access to the machine, the Integrity checkers and system logging facilities will have you. You must determine if these exist and how to make sure your tracks aren't seen again. That is outside the scope of this document. On many UNIX systems, things like tcplogger and scanlogd are used rather often. These are capable of detecting and logging any portscans (including stealth scans). Their sensitivity can be easily modified, but by default, these tools are both rather strict. These tools might also pick up certain types of scans that reactors such as Portsentry might miss. Portsentry is another UNIX portscanning detector, but it is meant to not only log the scan, but it can be programmed to deny access to the local machine by means of firewall utilities, or by dropping the route to the offending IP Address. It can also run a script that the sysadmin configures. This could be anything from a script that pages the admin, to emailing information about the offender to an email address, or even creating an automatic retaliation attack against the offender. Portsentry is written in perl and is very configurable. Chances are with some hacking, it would run on Windows NT, but I'm not sure. All three above utilities are provided under the GNU General Public License, so you're more than happy to pick up a free copy and look at or modify it to your needs. As a hacker, I would recommend that you use this to your advantange and study these programs to the best of your ability, and if you find a way to increase functionality in them, submit the changes to the author. Other IDS tools exist, that don't quite fit into any of these categories. These are ground-breaking programs such as L0pht's AntiSniff. Currently, this only works on Windows NT, but they are working on a command-line driven one for UNIX that will be open-source. AntiSniff is commercialware, and needs to be licensed after a trial period. What AntiSniff does, is looks for machines on it's local network that are sniffing. Sometimes if a machine is sniffing, it responds a little differently to certain packets. This is the theory behind A tool called "Neped" (which encapsulates a broadcast tcp packet inside a deformed Ethernet packet). The L0pht went a different direction, however. AntiSniff places the machine it resides on in "promiscuous mode" as well, turning the machine into a sniffer of sorts. It then makes false requests and phoney IP packets. Normally, any computer that's not sniffing would ignore it, but many sniffers try to resolve IP Addresses, or do other things that make reference to the false packet that was sent out. AntiSniff quickly determines that something fishy's going on, and flags the IP and MAC Address of the sniffing machine. There are only three reasons that a machine on the local network would be sniffing, and two of them are malevolent: * Someone has compromised or otherwise obtained access to a port on the local network and is using their own hardware as a sniffer. * Someone has "rooted", "0wn3d", or otherwise compromised security on a machine on the local network. This could be a windows 95 machine with buttsniffer, a compromised UNIX server, or anything. This is not restriced to being a server. Anyone with point and click skills can setup a sniffer on almost any network-aware OS you can think of. * Someone is doing legitimate network analysis. This usually doesn't happen very often unless the network is in shambles. On BUGTRAQ, shortly after L0pht's AntiSniff Announcement, people were already coming up with sniffers that sould make an attempt to foil AntiSniff's efforts. These sniffers were VERY minimalistic. Check out the archives, as there was some nice code exchanged. The thread name was something to the effect of: "The Anti AntiSniff Sniffer", and you thought Recursive Acronyms (GNU's Not Unix, PINE is not Elm, etc) were bad... This exchange took place quite a while ago, and the latest AntiSniff may be a bit better at picking up the stealthier sniffers, but who knows. That's up to you to figure out. Just remember, when you know what your target's defenses are, you have a better chance at being able to set up similar defenses for yourself and play with it. On the flip side, any system administrator that leaves something as important as an IDS with the default values shouldn't be a sysadmin. Unfortunately, there are way too many of these around. Just a heads up. If you stray away from the defaults when setting up an IDS system, you are likely to catch more of the activity. Your modified rule sets will more than likely be stricter than default, and the people who think that they're undercutting your mechanisms will succumb to the same fate as the guy who portscanned you 20 times yesterday. =] If that alone isn't enough of a reason to modify your IDS, just consider the rest of your machine. Would you leave everything default? I'd doubt it. You never leave things stock, so why give your IDS anything less? ----------------------------------------------------------------------------- - HiR Issue #10 - - Yet Another Operating System Review - - A look inside The Be Operating System (BeOS 4.5) - ----------------------------------------------------------------------------- So, towards the beginning of Novenber I was walking around Best Buy (drooling over the Rio, and looking for some Linux stuff and audio equipment) when something takes me by surprise: a BeOS Bundle (The OS and a really great book called "The BeOS Bible"). I'd actually been trying to get a copy of BeOS from an acquaintance of mine who had a "Warez" copy of it, just to try it out. (It's $99 from BeDepot.com, and up until recently, it was never carried in stores). I was willing to cough up $100 for an OS that I like, but I wasn't about to cough up $100 just to try something... The bundle pack was going for $54.99... A Winner in my book. So I picked it up, but I had *NO* idea what was I was getting into... Part I, The Bad News: BeOS is NOT Unix. It is not Unix based, and it is NOT built to be secure, or to be a massive web/ftp server OS. It is VERY picky about what hardware it supports, and it didn't install on a single one of my computers at home. It is single-user, and offers no form of password protection at the console aside from a screen saver password. Period. There is no full screen text mode. Part II, The good news: That wasn't a lot of bad news, but those are the ONLY drawbacks I saw. You may be thinking "Why would I want to go back to a single user system again?" And I can agree... but consider the following: BeOS ships with a telnet and ftp server. When you telnet in (or open a "Terminal" window), you use the bash shell to communicate to the kernel. Lots of unix commands work on BeOS, because it's striving for POSIX compliance, and many UNIX programs compile on BeOS. Technically though, it's not unix. The fact that it allows you to compile UNIX software and use unix commands makes it UNIX based about the same way learning to speak spanish makes you a Spaniard. (I.E. it doesn't.) In network settings, you can specify a username and password for ftp and telnet, but only one username and password. There are several third party FTP servers out there for BeOS, and many of them support multiple user profiles, and that allows you to toss different users into different parts of the system, and keep them from seeing anything else. Processing SCREAMS on Be. Period. On my lowly Bitch Box (TM) (which, if you will recall, is a Pentium 120 with 64 Megs of RAM, and a swappable hard drive rack), I was able to run multitudes of number-crunching graphical demonstrations at once. While sometimes things slowed down a little, nothing got lagged or choppy. The BeOS is VERY scaleable from what I see. BeOS also integrates into the Internet rather nicely for the end user, and it makes beautiful use of mime-types for files. The file navigator equivalent to MS's "Explorer" (Called "The Tracker"), will open pretty much any file on your system. You can set view preferences on a folder-by-folder basis. When you look at your E-Mail inbox, it's actually the Tracker, and it will let you show E-mail attributes of the cached files, such as date of arrival, Subject, Who it's from, etc... NetPositive is the default internet content browser that comes with Be. As far as I know, Netscape hasn't been ported to Be yet, but mozilla might compile. NetPositive has no java functions whatsoever, but it usually does the job. The Guys at Be, Inc. have done a lot of hard work on the OS, and they are more worried about keeping the Operating system feature-rich than they are about making sure it comes with the best toys available. This is to urge the industry to write software for BeOS, and it's worked so far. There are already hundreds, if not thousands of BeOS applications. Many of them are commercial (must be bought), or crippleware (demo versions that get un-crippled when you register). The packaging program, SoftwareValet, contains a mechanism for online registration of software (if the author of the software chooses to make the registration compatible with it). BeOS does have some major advantages over many other OS's though. For instance, it integrates very well with the Internet, as UNIX, but on the users' level. It doesn't start up loads of services that the user has to figure out and set-up correctly. It also uses the "Be FileSystem" or BFS, which is a true 64 bit journaled file system. (Journalling means that it don't gotta fsck or scandisk if it suddenly gets shut off. This is because it "journals" all disk transactions as they are made). Being a 64 bit filesystem, it also is very unlikely that drives sizes will exceed the filesystem capabilities. 64 bits equals an 18,000 petabyte limit. that's about 180 times the estimated used hard drive space on ALL THE DRIVES in the world right now... shudder... I will be honest: I don't see BeOS becoming the next Linux or *BSD (as far as being a majority player in the non MS/MacOS market). It's almost a project that I'd like to see eventually become freely available or even Open Source (Through a BSD or GPL license), but who knows. Who SHOULD try this OS? Anyone who's an OS psycho like me Anyone who wants a user-friendly, yet very quick and scaleable OS Anyone who's tired of MacOS and MS, but not nerdy enough for UNIX Anyone who likes to sample the cutting edge Anyone who's prepared to pay small amounts of money for well- written software (BeOS IS commercialware, but in the scheme of things, inexpesive. Most of the apps written for it are the same way. Unlike M$, you don't spend hundreds of bucks to get the software you need) Who should NOT try this OS? Anyone who adores one OS, and doesn't like dual-booting (not enough software yet...) Anyone that's wanting to keep their parents/roomies out of their files Anyone who wants to run lots of services Anyone who can't live without full-screen textmode Anyone that expects to have thousands of full-fledged apps ready to run. More and more programs are being written for BeOS. It even has it's own site on Tucows.-=- HiR 10 -=- RISC, CISC and The concept of the Power-PC By. Asmodian X In this article I plan to outline the Power-PC series processors, and their origins. I also intend to draw out the differences of RISC chips and CISC chips. This article is intended for intermediate audiences who Know the basics on how a computer works, and are wondering what the big deal with these expensive Workstations and servers that are non-Intel. ............oooooooooOOOOOOOOooooooooooooooo..............ooooooooooOOOOOoo. Section 1 ........................ Why. Section 2 ........................ IBM, Apple, and other large faceless corporations. Section 3 ........................ Intended uses Section 4 ........................ RISC Vs. CISC Section 5 ........................ Fact Vs. Fiction (seeing through marketing ploys) Section 6 ........................ Summary Section 7 ........................ Resources ........ooooOOOOOooooooo.............oooooooooooooooOOOOOOOOOoooooooo....... -=- Section 1 -=- Why? Why am I writing this article, Intel based designs are cleaning up in the PC market, MAC's are still the under dog, what's the point? Well, if you have ever argued with a Mac enthusiast about who's better, and walked away victorious, but secretly wondered what really lies underneath the hood of one of the new(er) power Mac's. Or if you are wondering what the real difference between a Desktop and a workstation, then this article might be able to shed some light on the subject at hand. I am primarily focusing on Mac's because they are the more popular source of PPC machines. As a company, apple sucks, their OS suck only if you don't want to conform to their standards. Mac OS's primary attributes is that is has a very small learning curve. The hardware is cool if you don't mind the proprietary shit that apple pulls. -=- Section 2 -=- IBM, Apple and other large faceless corporations. xx IBM xx IBM is the leader in High end, workstations, and super computers. IBM started out with a processor line called the Power processor which was featured in its RS/6000 series of workstations. The Power processor was a Full RISC processor. The modern Power-PC processor is a direct derivative of IBM's Power processor. IBM has its own chip manufacturing capability's. xx Apple xx Apple specializes in consumer grade graphics personal computer. Apples designs have generally featured RISC processors manufactured by Motorola. Apple chose RISC because it is less complex and faster than the CISC architecture. Apple markets to people who are not technically literate. Hence why a great percentage of Mac users are scoffed at by their PC counterparts. Typically most Mac users tend to gravitate around graphic design, and journalism. xx Intel xx Intel originally started out like IBM, catering to the upper end Server market. Then a couple of engineers designed a processor based on the 4004 series calculator chip. The processor series eventually lead to the advent of the 8086 chip, which was featured in IBM's new Personal computer. IBM PC's were introduced into an office environment which caused growth in business application development, and Engineering. Because of this, IBM computers were slow to adopt a graphical user interface. Also because of the business nature, new computers needed to be backward compatible to allow integration with existing PC's. Because of this, Intel's chips grew into CISC chips or (Complex Instruction Set Computing) Because Intel and IBM did not take the market seriously, competitors flourished, and proprietary architectures withered away due to the advent of open standards, and industry standards. -=- Section 3 -=- Intended Uses Of the Power-PC IBM and several competitors saw that RISC was the technology of the future. The problem was who's version of RISC to go with. So rather than Re-inventing RISC, They built the standard on top of the existing IBM Power Processor. Power-PC 60x Chips can run IBM power code natively with one or two hicups when it tries to run some Buffer Clearing Instructions. IBM compensated for this shortcoming with some emulation code in their AIX operating system. IBM Implemented the Power-PC on their RS/6000 Workstations in place of the Power Processor. Apple entered the game wanting to compete with the new Intel Pentium chip. In the Power-PC Apple saw Superior performance and Lower production costs. One little problem, The M68000 series instructions did not work on the Power-PC chip. To compensate for this problem, Apple, included emulation for the Motorola based applications and operating system code. Apple (like all of the other attendees) was very proprietary, and on the first few batches (Like the Power-Mac 7100) utilized the old NuBus Peripheral Bus. Because of this, and other proprietary problems, the early PowerMACs were unable to boot alternative operating systems with out at least some form of MacOS assisting it. I believe Mac OS will continue to emulate the old M68k chips, but for the most part the Operating system has slowly been ported over to the PPC platform. -=- Section 4 -=- RISC Versus CISC In concept RISC Provides More speed for less price. RISC chips use less logic circuits to attain the same raw performance of a CISC processor. A CISC chip provides backwards compatibility which eats into performance, and cost. Simply speaking it is more efficient than the CISC platforms. However, RISC has some down falls. Apples choice to emulate its older Motorola Processor pointed out its own need for backwards compatibility. Emulating a processor logically is slower than adding that functionality to the chip itself. maintaining software that will work on older processors but will not work on newer ones is much more difficult than just dropping a new system into an office and have it work seamlessly with existing machines. So CISC computers are much more versatile than their RISC counterparts in that they can be implemented with out requiring special emulation software, it can run the older programs with out a problem, and faster than the older computers can. The early advent of open standards allowed for the porting of Operating system software and Applications to the PC platform much easier than most RISC systems which were and in some respects are still proprietary in nature. Simply put CISC is more versatile in use, and easier to develop for, and produce, there for it is more popular. To compare CISC versus RISC, one might compare a VHS to a Beta. (Note: a while back there was a battle of standards, and industry standard called VHS, and Sony's Beta standard VCR. VHS won because of popularity, SONY was a better technology, but was proprietary, and inflexible) -=- Section 5 -=- Fact Vs. Fiction Fiction: Power-PC's can run PC code natively Fact: Power-PC's must use emulation software, and some times hardware. Fiction: Mac application software can be run on any kind of macintosh. Fact: Power Mac's emulate their older m68k counterparts otherwise running older software would be impossible. Fiction: A power Mac G4 is over three times as fast as a Pentium. Fact: Thats true from the perspective that a Pentium II 300 is over three times as fast as a 486 DX4 100. ( Point being that CISC will always be slower, especially if you testing a 64 bit processor, versus a 128 bit processor. That statement is called a "Red Herring"; A true statement that has nothing to do with the subject at hand. ) -=- Section 6 -=- Summary Indeed, the RISC architecture is better at raw power. Yet CISC is more versatile, and easier to implement. CISC generally is also easier to develop for, because you don't have to re-invent the wheel all over again. The extra instructions you can use save a bit of time in compiling . Its kind of a trade off. -=- Section 7 -=- Sources: White Papers: http://www.ibm.com (searched for "Power-PC 601" and browsed info from their RS/6000 section) Sales literature: http://www.apple.com/ (searched for "Power PC", "Power PC 601" and "Power Mac 7100") Operating system(s): http://www.mklinux.org/ http://www.netbsd.org/ http://www.apple.com/ (searched in their tech library on "Power PC 601", "Emulation", "ROM", "7100") ------------------------------------------------------------------------------- HiR Issue #10 Setting up your home-net by Axon ------------------------------------------------------------------------------- I. Introduction II. Hardware Requirements III. Software Requirements IV. Intra-Net host setup (getting your server onto the 'net securely) V. Intra-Net workstations setup (getting your computers to talk) VI. Testing VII. Advanced Firewalling IIX. Closing ------------------------------------------------------------------------------- I. Introduction: This is going to be a general tutorial on how to be *REALLY* connected at home. This article is mostly geared toward the people with 2-10 (or more) computers at home, or for small businesses with a relatively tiny private network. This isn't guaranteed to work, and is based totally from my experience setting this system up in my own home. This includes cross-platform ability (We have Win95/98/Linux at my house). ---------------------------------------------------------------------------- II. Hardware Requirements: You'll need: * At least 2 computers * A network card for each computer to be connected together (try to make them the same brand, and make sure they're all the same media. I prefer 10BaseT, but choose your own here) * Cables to hook the computers together, and a hub (or a crossover cable if just using 2 computers) * Maybe a crimping tool and hardware to crimp your own cables * The Host Machine should be a 486/33 or faster with at least 32 megs of RAM. It should probably have at least 200 megs of hard drive space, but since it can also be used as the Intra-Net server and a workstation at the same time, it would be to your benefit to make this a more powerful machine. This will be running Linux. (This example will be done using Red Hat 5.2, but I've successfully done this with Other UNIX-like OS's such as FreeBSD, which is what I am currently using.) * The workstations need to be able to run an OS capable of recognizing the network card and using a TCP/IP stack (Windows/Linux/MAC-OS all work) ---------------------------------------------------------------------------- III. Software Requirements * The Workstations need an OS that can get a tcp/IP stack over a Network Card. * The Host machine must be using some version of Linux (Redhat 5.2 works, and I'll be making reference to some tools that only RedHat has, but an experienced Linux user should be able to figure out how to get any other Linux Distro to get this to work. RedHat was chosen for this article because of it's ease of setup (with GUI tools) and the fact that the kernel was built with the proper options for masquerading. This would just be the "friendliest" way to set things up. I do not support any one distribution over the other as far as which one is "best", as it's all personal preference. I'm actually using FreeBSD right now (I know, it's not Linux), but it is a little more difficult to configure for this purpose, and requires a kernel recompile among starting and configuring natd (Network Address Translation) services. It's a different approach, but the results are even better. E-mail me if you want a copy of my FreeBSD kernel Configuration file. ---------------------------------------------------------------------------- IV. Intra-net host setup. The goals of our intra-net host will be the following: * Act as a network management workstation * Act as a network print server (if desired) * Act as a network file server (if desired/needed) * Access the Internet (through a modem/ppp in this example. Doing this through a cable-modem or DSL can be done, as well, but almost always requires a second Network Card) * Act as a packet-filtering firewall to isolate intranet from the Internet. * Act as a gateway, so that all intra-net computers have shared, secure Internet access when the Host system is online. Workstations should reside behind this machine as a firewall to prevent network attacks. * Be as secure as possible, as the Host system will be your only line of defense. Once someone's compromised your Host, that's pretty much it, and they can do more damage once inside your intra-net. In order to act as a network management workstation, the Host needs to have a few programs installed: * ipfwadm (if you're using kernel 2.0.x. This comes with RedHat 5.x and most other kernel 2.0.x based linux distributions) * ipchains (if you're using kernel 2.2.x. This comes with RedHat 6.0, and most other 2.2.x based linux distributions. As a side note, I would strongly recommend compiling a fairly new version of kernel 2.2.x, even on your RedHat 5.2 installation. If you don't know how to do this, just stick with RedHat's default kernel.) * tcp-wrappers (also known as inetd. This allows us to restrict incoming access from remote networks). Comes with most distributions. You may take a serious look at a package called xinetd, as well. It has quite a few very tasty features (ident lookups on all connections, etc) * Secure Shell 2.x, which will allow you to make secure connections to the host system from outside, if you must do so. If you're somewhere else on the Internet (I.E. at work) and you want access to to your home network, You will have to make a connection to the host system before you have access to any other system on your network. * Some sniffers and analysis tools are nice to have, for troubleshooting the network. I recommend tcpdump (comes with many distributions) and iptraf (available all over the web, check around) * Kernel must be compiled with IP Forwarding enabled, masquerade enabled, etc. I'm not going to quite get into setting up masquerading in the kernel. Read the IP-Masquerade mini-HOWTO, which is flawless at describing the basics of setting up masquerade stuff. We'll get around to some changes you'll make to the examples in a bit. * "setip" is optional. It will upload a file called ".ip" to the ftp location of your choice. This is good if you want to be able to remotely access your network at home from a remote location, but have dynamic IP or DHCP,and therefore have no clue what IP you might have at any given moment. * I also use the "Deception Finger Daemon" on my firewall/host at home. it can generate false user reports to people who attempt to use finger to determine what users are logged on or exist on your network. "dfingerd" also can make syslog entries, so that you know when you're someone's taking a peek at you. It's fairly easy to install, and the documentation that it comes with is very detailed. The first thing we want to do is to get the host machine to be able to connect to the Internet. This can be done with RedHat's "netcfg" utility, used in the X-Window environment, or by manually setting up the chat script and ppp options for your ppp interface (these files are located differently between distributions) You will need to supply a phone number, user name, password, and you will probably want to make it so "Any user can control this interface", which is a checkbox in netcfg. This will be so that anyone on your network will be able to get the host system onto the Internet (and when we're done, this fact will mean that your entire network has 'Net access). Test out your Internet Connection. Telnet to something, or type "lynx hir.chewies.net" and surf the HiR Distro Site. =] Once that's working, you may want to add a user account for all people to use the home-server, or just a single account for the users, that is shared and can bring up and take down the I-Net connection. After that, you should be ready for the next step: Setting up your ethernet card... Hopefully it's already installed, but if it isn't, halt your Host machine, install it, and power back up. We need to go back into X and use netcfg again (or whatever it is your distribution uses for setting up Network Cards). Add an "ethernet" interface (eth0), and set it up like this: IP-Address: 192.168.1.1 (fake IP used for Intra-Nets) Netmask: 255.255.255.0 gateway: (leave blank) In netcfg's "routing" tab, select "Network Packet Forwarding" and don't worry about a route, as the ppp interface will become the default route once it's connected. You should now have created a class C intranet. Now to secure the server... The server is your golden goose. The rest of your machines are hidden from view from the outside world, and your server is the only machine that can be seen both by your side of the network and the rest of the world (Via the Internet connection). Once your server has been compromised, anyone who knows what they are doing, will see all your other machines, and potentially attack them, using your own server's recources! Potentially, they could figure out all the passwords that your users use, they could possibly erase all the files on open file shares, and maybe even abuse your paper and toner/ink supply on connected network printers. That's an insult. The first thing we're going to do is lock down your open ports with tcp-wrappers. inetd is the tcp-wrapper program that checks for authorization to use a service. Not all of your services run through inetd (mostly sendmail, httpd, and secure shell). Inetd protects services such as telnet, finger, shell, login, auth, etc. When someone attempts to use any of these services, inetd checks /etc/hosts.allow and /etc/hosts.deny (respectively) for a line containing an inclusion for the service name (either the daemon executable name such as "in.telnetd", or "in.fingerd". "ALL" includes all service names). My home server's hosts.allow file allows all the workstations behind the masquerade to access my hosts full potential, but locks the rest of the internet out, except for dfingerd, that fake finger daemon I was talking about earlier. ALL : 192.168.1.0/255.255.255.0 dfingerd : ALL As soon as anyone connects to my machine, say with telnet, it checks hosts.allow to see if they have been granted access. If they're on the Internet (not on my intra-net), they aren't on this list, so it checks to see if they have been disallowed in hosts.deny. My hosts.deny file is simple: ALL : ALL This makes sure that only things granted in hosts.allow will make it to my system. Note that the deny ALL doesn't cover ssh, so I can still get back in over an encrypted connection if I know my IP address and have a user/password. Also notice if any remote machine tries to use dfingerd, they will be allowed, because inetd doesn't check hosts.deny if there is a rule in hosts.allow that applies to that connection. If you're really in for security, I would advise trying to setup xinetd, which will attempt to find the username of the person who is connecting to the port my making use of their local machine's ident service (if available, which it is on most UNIXes and if they have mIRC running at the time, too). It's a little more difficult to set up, but it still uses the hosts.[allow|deny] convention. Remember, anything that starts up outside of "inetd" is not protected by this modification, so don't rely specifically on it. Some daemons will try to read the hosts.allow/deny files as well, so there are a few exceptions. In general, you will want to keep things as closed up as possible, allowing telnet and ftp from machines on your private Intra-Net. Also, TCP-Wrappers are all considerably more open to attacks involving spoofed packets, and it may be possible for someone to make a packet with a source address of one of your trusted machines, but coming from the outside world. Since TCP Wrappers only has support for IP Address restrictions, they can't tell if the traffic is coming in from your network card on the trusted side of the firewall, or from a machine on the other end of the ppp connection through the modem link. This is where packet filters (such as ipfwadm and ipchains) come in. Ipchains and ipfwadm are not the actual filters; but they are programs that control parts of the running kernel. They tell the kernel what kinds of packets you wish to let through, and what kinds of packets you wish to deny. Since filtering takes place at the kernel level, the filtering can potentially use any aspect of the networking structure to describe what packets to look for. This means that you can specify not only what addresses to allow or deny, but also what individual protocols, network interfaces, and many more things. This also means that you can manipulate the kernel into "repeating" or "routing" traffic between interfaces, allowing you to force the kernel into being a makeshift router for your home or small business' network. It looks for traffic that's not meant for any of the local machines, and tries to push it out over the modem link. If the connection is successful, one of your networked machines suddenly can access stuff THROUGH the server. Then, even more machines can do it at the same time, too. You could have as many connections as you wanted over one modem link (of course after 3 or 4 connections going at once, the link would become very slow). The Linux community calls this routing procedure "Masquerading". The *BSD community calls this "Network Address Translation", but like I said before, NAT is a little more than just kernel work. Now, we need to use either ipfwadm or ipchains (Depending on your kernel) to add masqerade rules. Some people say to add a general policy to masquerade, and that's bad, because it would allow all sorts of evil stuff to happen, including maybe someone being able to hide themselves behind your masqerade and access all of your network resources without authorization. This is also known as "The Bad Thing". Also, I prefer to add masqerade rules on a per-machine basis (as in, one ipfwadm/ipchains line that tells the kernel to forward packets from workstation 1, workstation 2, etc... instead of telling it to forward from all hosts in 192.168.1.x. That's kind of my personal preference, but it's how I would suggest doing things. Ipfwadm or IPChains rules may be typed in at any time, but I would suggest putting the commands into your /etc/rc.d/rc.local file, which is the closest equivalent to an "autoexec.bat" for Linux. If you're using IPChains on your Host Machine (with RedHat 6 or any other kernel 2.2.x based Linux system), this example should give your machines with IP Addresses 192.168.1.2 and 192.168.1.8 access to the internet when you're connected. Just add more "ipchains -A forward -s ..." lines to /etc/rc.d/rc.local and change the IP Addresses for each machine you need on the Internet. (These examples taken right from the IP-Masquerade mini HOWTO, by Ambrose Au and David Ranch) ipchains -P forward DENY ipchains -A forward -s 192.168.1.2/32 -j MASQ ipchains -A forward -s 192.168.1.8/32 -j MASQ If using ipfwadm (as in with RedHat 5.x, or any kernel 2.0.x based linux), the equivalent to the above ipchains commands, using ipfwadm is: ipfwadm -F -p deny ipfwadm -F -a m -S 192.168.1.2/32 -D 0.0.0.0/0 ipfwadm -F -a m -S 192.168.1.8/32 -D 0.0.0.0/0 Again, these should just go at the end of /etc/rc.d/rc.local, and you can just add another "ipfwadm -F -a m -S ..." line for each ip you want to forward. You'll also want to add modules for forwarding "interesting" traffic, where applicable. Strange protocols such as irc, cuseeme, and ftp do not like masquerading very much. A few kernel modules make the masquerade a little more friendly for these protocols. I just placed lines in rc.local again, using modprobe for the various modules. These are masq modules from the 2.2.5 kernel. I did not actually insert all of these modules. The title of them is fairly self-explanatory: modprobe ip_masq_autofw.o modprobe ip_masq_cuseeme.o modprobe ip_masq_ftp.o modprobe ip_masq_irc.o modprobe ip_masq_mfw.o modprobe ip_masq_portfw.o modprobe ip_masq_quake.o modprobe ip_masq_raudio.o modprobe ip_masq_user.o modprobe ip_masq_vdolive.o I'll go over advanced packet filtering toward the end of this article. There, I'll cover some real firewalling stuff. Setting up a File Server using Session Message Block (SMB) Protocol. SMB is the file sharing method used by Windows NT and the old LAN Manager. It is a fairly resilient protocol, and some advances have taken place in the recent past, that make it a little better (Specifically, the ability to go over TCP/IP instead of NetBEUI). If you use samba on your host, and configure it properly, you will have a nice framework for cross platform file sharing with Windows and many UNIXes. Also, using some third party software from Thursby software (www.thursby.com) called "DAVE", you can even use SMB shares from MacOS. There's a lot of help docs out there that can help you set up Samba for print/file sharing. The default /etc/smb.conf file is so bloated and unnecessary, that I can't believe it got put in as an example of what it should look like. I'm actually running printer sharing off of the Windows 95/Linux dual boot workstation, for the rest of the family's convenience. This is what the smb.conf file looks like for my laptop (which shares all users' home dirs, a "public" world-writeable share, and the CD-ROM Drive): [global] workgroup = WORKGROUP netbios name = ESCAPE_POD server string = NEC Versa 4050C (Red Hat 6.0) log file = /var/log/samba/log.%I max log size = 50 security = share socket options = TCP_NODELAY dns proxy = no local master = no lm announce = yes lm interval = 60 [homes] comment = Home Directories browseable = yes public = no writable = yes create mask = 0755 follow symlinks = no wide links = no preserve case = yes [public] path = /usr/public public = yes only guest = yes writable = yes printable = no available = yes guest only = no browseable = yes only user = no [cdrom] path = /mnt/cdrom public = yes only guest = yes writable = no printable = no available = yes guest only = no browseable = yes only user = no From this, you should be able to see how shares are made up. Refer to the manpage for "smb.conf", and it will help a lot from here, specifically with setting up a printer, if desired. Now would be a great time to install the Ethernet Hub somewhere and plug the cable from your server into it. IV. Intra-net workstation setup. The goals are simple: Use the resources of your home-server, and use it as a gateway to the 'net when it's connected. Also, you may want a something that makes it connect. If you used masqdial on the host machine, then you will need the masqdial client for the workstations. There's a Java one, one specifically for UNIXes, one for mac, Windows, and whatever else, pretty much. This is a good solution, in my opinion. It's difficult to set up though. Otherwise, you may want a script that telnets over, and launches the ppp connection. Make sure that the Ethernet card is installed properly and that you have the drivers installed if necessary. We need to set up IP connectivity first. This is platform dependant, and I don't have the time to tell you how to do it on every platform. Under RedHat, use netcfg, and Windows, use the "network" item in the control panel. I sequentially numbered my machines. The Windows/Linux dual boot machine is 192.168.1.2, my laptop is 192.168.1.3, and the list goes on and on. While you're setting up the IP over the ethernet card, make sure to include the IP of your host machine (in the example above, Setting up the host machine, we called it 192.168.1.1) as the "Gateway" or "default route", as our server will be functioning as the Internet connection point for all the workstations. If you have any additional file sharing needs from the workstations, set them up, as well. Again, as the workstations can be almost any platform, I can't really help a lot here. Network security on each of the workstations Now run Ethernet cable from the network cards of each workstation back to the hub, as well. VI. Testing. Now it's time to test everything. First, go to your home-server and try to ping the IP addresses of the workstations. You should see a response listed in "milliseconds". IF you see no response, make sure your IP's are correct, and you have solid cable connections. Also, make sure the hub and the remote computer are turned on. Next, go to each workstation and ping another workstation (if available) and the server's IP address. Then try to telnet to your home-server. IF you can do this, you're good so far. Start the Internet connection (usually "/sbin/ifup ppp0"). Wait for the home-server to connect. IF it does not, re-check your dialup settings. If it DOES connect, try pinging the outside world from the workstation. ping www.yahoo.com, or some other server out there. If you get a response, then your home-net works great for sharing an internet connection! If you can't ping the outside world from a workstation, try it from your home-server. If you can't, then re-check the internet dialup settings. If you can see the outside world from the home-server, but you can't see it from workstations, then it's a problem with your forwading rules. Make sure you're using ipchains if you're running kernels 2.2.x, and make sure you're using ipfwadm for kernels 2.0.xx. VII. Advanced firewalling Sometimes hosts.allow and hosts.deny just don't cut it. For instance, you already know it usually only covers stuff that runs through tcp-wrappers. Also, if someone port-scans your home server, or any linux machine you're running, even though hosts.deny says not to allow them a connection, they still see an open port. ipchains and ipfwadm can eliminate the "look" of open ports on your machine, as well as locking it down even further, as it just blocks ports. This means that any other ports left un-protected by tcp-wrappers (such as SSH and Sendmail), can be protected as well. Here is a little quick-help guide to ipchains and ipfwadm I put together a while back. While yer messin with these rules, I suggest you port-scan the machine you're enforcing the rules on, to see how they would look from an outside attacker. The example that describes denying port to all hosts except the local network will probably be the most useful for you, just put multiple instances of ipchains or ipfwadm into rc.local, and change "23" to some other port that you want to lock down. My laptop is protected with ipchains. This is how I did it: First I portscanned my box with nmap (from my other workstation) and I saw that ports 21, 22, 23, 79, 113, and 139 were open. Then I went to my laptop, logged in, su'd to root, and began... These are the ipchains rules I entered: ipchains -A input -p tcp -d 0/0 21 -s ! 192.168.1.0/255.255.255.0 -j DENY ipchains -A input -p tcp -d 0/0 23 -s ! 192.168.1.0/255.255.255.0 -j DENY ipchains -A input -p tcp -d 0/0 79 -s ! 192.168.1.0/255.255.255.0 -j DENY ipchains -A input -p tcp -d 0/0 113 -s ! 192.168.1.0/255.255.255.0 -j DENY ipchains -A input -p tcp -d 0/0 139 -s ! 192.168.1.0/255.255.255.0 -j DENY ----------------------------------------------------------------------- Add firewall rules: ipchains -A -p -i [!] -s [!] [!] <(low)port:highport> -d [!] [!] <(low)port:highport> -j * Note: when using icmp protocol, ports are replaced with icmp types. If no port or icmp type is specified, it assumes that you meant "All ports or icmp types". If no source is specified, it assumes "all", and if no destination is specified, it assumes "all". Also, if ! is used before an ip or port rule, it means "anything except" the given port/ip. ipfwadm -A -P -W [!] -S [!] [!] -D [!] [!] -a Examples: Deny port 23 (telnet) from all hosts not on the 192.168.1.xxx network: ipchains -A input -p tcp -d 0/0 23 -s ! 192.168.1.0/255.255.255.0 -j DENY ipfwadm -A in -P tcp -D 0/0 23 -S ! 192.168.1.0/255.255.255.0 -a deny Make machine stop responding to ping packets: ipchains -A input -p icmp -s 0/0 echo-request -j DENY ipchains -A input -P icmp -S 0/0 echo-request -a deny Deny ports 19-23 from the entire 198.248.53.xxx subnet: ipchains -A input -p tcp -s 198.248.53.0/255.255.255.0 -d 0/0 19:23 -j DENY ipfwadm -A in -P tcp -S 198.248.53.0/255.255.255.0 -D 0/0 19:23 -a deny Deny any outgoing icmp packets from your machine (I don't know why, it's just an example): ipchains -A input -p icmp -d 0/0 -j DENY ipfwadm -A in -P icmp -D 0/0 -a deny Deny all incoming tcp to port 23 if it's coming over interface "ppp0" ipchains -A input -p tcp -D 0/0 23 -I ppp0 -j DENY ipfwadm -A in -P tcp -D 0/0 23 -W ppp0 -a deny Delete firewall rules: ipchains -D [rulenum] (deletes one rule) ipchains -F (flushes all rules) ipfwadm -A -d [policy] (deletes the matching policy) ipfwadm -A -f (flushes all rules) ------------------------------------------------------------------------------ IIX. Closing Well, I guess that about covers it, as far as I can tell. If nothing else, a quickie lesson about firewall rules for ya all. Having a home network for myself has been a great experience, and has allowed me to play with hacking in a new way: in my own home, as much as I want. I control the environment, and I don't have to worry about messing other people's connections up when doing it. I've done a lot of experimentation with firewalling rules since I've gotten my home-net up. Once mastered, these skills will aid you in being a very valuable asset to major corporations, and will help you understand network security a little more. This was by no means a "full attempt" to make people understand networking, but is only a primer, to get you guys thinking. I've found that very few things can be as rewarding to a hacker as having their own network to play around on as much as they like. I'd hope that many of you will take this information and use it to help you learn a little more. Then you might be able to help people with their own security problems. These are just some basic networking implementations, and they're more than enough for the average person, but then again, most hackers aren't average... There's plenty more info on this topic, all out there on the 'net. If you're interested in this sort of thing, then go out and do it! --Axon The Official HiR FAQ - Version 0 0x00. Introduction/Thesis 0x01. How Did HiR Start? 0x02. Who are/were the HiR members? 0x03. What do HiR members do? 0x04. I Want to be an HiR member! How can I do this? 0x05. What all does an article go through before being published? 0x06. General Article Information. 0x07. What about distributing & copying HiR Articles? 0x08. What's with the "Affiliates"? 0x09. How popular is HiR? 0x0A. Where can HiR Be Found? 0x0B. Is there a mailing list to announce new Issues? ___________________________________________________________________________ 0x00. Introduction/Thesis This is just a general FAQ about the HiR Crew and the events that formed what HiR has become today. This is being put together almost soley from the Editor's (Axon's) point of view. This FAQ is being created so that our readers and the general public can know exactly who we are (to an extent), and what it is that we actually do. For a lot of our readers, this will probably clear up some misconceptions that are usually assumed on their part. We also feel that it is good for the people to know what goes into a group such as ours. This is not going to be a hacking FAQ. If you want that kind of information, read our articles, and read all sorts of other stuff. This is for those who want to know our background, and how things all got started... 0x01. How Did HiR Start? HiR (Hackers Information Resource, as it was originally called) was started in May of 1997. It was written entirely by Axon. Most of the writing took place on a road trip. The entire issue was assembled on Axon's laptop at the time. He created HiR as almost an "apology" of sorts. For the previous 2 years, Axon had been a system cracker who had taken what he had learned and used it to benefit himself alone. He was learning, but he was not sharing much of his knowledge with the outside world. He teamed up with several other system crackers, and would often help them do things hat weren't very nice. It was a thrill, at the time. It was also very, very stupid. After several of Axon's system cracker buddies got busted, he felt the heat and danger. It was just enough to scare him into "being good". Axon felt that he owed his part to the true computer underground: The ones who strive for knowledge and understanding, not the greedy people that want power to destroy other people's things. So he wrote... and wrote... and came out with HiR Issue #1. Halfway through HiR 1 Axon decided that "Hackers Information Report" would sound better, and so it was changed to that instead, but keeping the HiR initials. Axon's main purpose for creating HiR was to share information, but he also knew that having to write articles would force him to pick up new things to write about, and thus, pick up new skills. 0x02. Who are/were the HiR Members? After the release of HiR 1, a handle-juggling fellow who called himself tgsnoop (or kminor), decided to join up. He put together some interesting stuff here and there, but some of his writing topics were getting into the dark areas we didn't want to get into. He was also having other problems by the time HiR 4 came out. Also, right before HiR 2 was released, we accepted another writer: Dr. Freeze. Dr. Freeze wrote 3 pretty nice rough cuts that could have been turned into decent articles in a short matter of time, but his computer was destroyed. We lost him for a few months, and we had no clue what had happened. Both tgsnoop and Dr. Freeze were dormant for a few issues and they were dropped. When HiR 3 came around, we aquired another writer, Asmodian X, who was a good friend of tgsnoop, and also was in an Information Technology class with Axon. He saw Axon writing an HiR article on his laptop before class, and approached Axon, saying he knew someone who wrote in HiR. Confused, I told him "yah, you're looking at him.", and he said "which one are you?". "Axon" I replied, and we talked. It was only a matter of time, and Asmodian X was writing some juicy bits for HiR, as well as helping Axon take care of the Distro Site. The Man In Black is a long-time, very close friend of Axon's, and is not really into hacking in the sense of the word. He does provide a well-kept-up mirror of the site back in New Mexico, while he's at school. The mirror goes down when he comes back to the midwest with his computer. In HiR 6, we had another writer, Frogman. Frogman was an aquaintance of Axon's for quite some time, as they frequented some of the same local BBS's in town. At a 2600 meeting one time, Frogman was there, and got to talking with Axon & Asmodian X, and told us about some cool cryptography books he was reading. His articles have carried a mostly mathematical and cryptography-based topic. With the release of HiR 9, another writer was introduced to the world. Ixl joined HiR, and is thousands of miles away from the rest of the HiR Crowd. He's situated somewhere in Canada. Ixl went through the typical phase of playing with Windows and the like, and graduated to FreeBSD and Linux quite a while ago. Ixl's hoping to not only learn more from writing for HiR, but to help teach others what he picks up along the way. Memeber Membership Span ---------- ---------------- Axon HiR #1 - Present tgsnoop HiR #2 - HiR #6 Dr. Freeze HiR #2 - HiR #6 Asmodian X HiR #3 - Present TMIB HiR #4 - Present Frogman HiR #6 - Present Ixl HiR #9 - Present 0x03. What Do HiR Members Do? HiR Members, for the most part, function all on their own. Each one of us learns stuff our own way, and we use it in our own ways. We have our own writing styles, and that's about it. A Common misconception about the HiR Crew is that we are an active "hacking group" and that is totally wrong. We are basically just journalists. Not once have all the HiR Members gotten together to "go hack something", and we probably never will, either. I know of two times that 2 HiR members worked together on a hack, and it wasn't the same 2 both times. Axon's mother is an English instructor, so he's picked up some halfway decent writing and editing skills. All HiR articles are usually read and fixed up by Axon before hitting the shelf. Major changes that need to be done are referred back to the author. In short: HiR Members just write HiR Articles. Each one of them has their own pasttimes and hobbies. 0x04. I want to be an HiR Member! How can I do this? Easy. If you're knowledgeable about things in the Hack/Phreak scene, and a good writer, then send us some of your writings. We'll determine if we need that kind of material, and if we approve, then you're a member! You can't hack stuff in our name, or anything of the sort. You're just a journalist, remember? The HiR Crew is very proud of their ethical standpoint, however. We only publish articles about hacking and phreaking, and we really strive to keep the published material as ethical as possible. We explain systems, not how to break into them. Examples of article titles we would publish: "A Closer Look at NTFS"; "Crossbar Switching, up close and personal"; "The inner workings of sendmail" and "examining your system for exploits: is YOUR box secure?" Things you would NOT see in HiR: "H0w t3w h4x0r w00t 1n t3n 34zy st3pz"; "Using Teardrop to nuke a class C"; "Mercury Fulminate: The explosive of champions" or "Obtaining lots of credit card numbers". If you want to write for us, make sure the article is educational. If the reader is a real hacker, and they want to use your information for evil things, they will find it out all on their own after putting some thought into your article. You don't need to feed the 12-year-old "I wanna hack" rebel script kiddies. Note: I know some *REALLY* Good hackers that are 11-14, not all 12-year-old "hackers" are script kiddies, but a lot of 'em are... 0x05. What All does an article go through before being published? All HiR Members have accounts on the web server that runs the main HiR Distro site. HiR Writers e-mail the other HiR members with what they plan on writing on, and usually get some sort of opinion from the group, or a few people on the group. When they write the articles, they pretty much do most of the work on their articles on their own computers, and upload them to a directory where the Editor can read them. Usually if they need to be touched up, through secure shell, they edit it on the web server machine. The Editor then checks the work, and touches up any minor typos he sees. After re-numbering the articles, The Editor creates the ToC file. Different HiR members send in things for HiR Hacker Newz and HiR Informative Resources. Axon & Asmodian X throw together the web work for the new release, including the new HiR Graphic for the new release (Axon and Asmo take turns creating these). 0x06. General Article Information. HiR Articles are supposed to be no wider than 78 columns, and is distributed in text-only format. This is to accomodate all types of file viewers. (78 column limitation is for MS-DOS EDIT). Older HiR Articles were basically written totally in MS-DOS EDIT, and are in MS-DOS's native CR+LF Text format. The more recent ones have been written mostly on some sort of UNIX platform, and are in CR Format. If you use the DOS print command on some of the newer articles, it will stair-step the text, which is annoying. If you print it from MS-DOS Edit, Microsoft Notepad, or a few other Dos/Win editors, this will be fixed. Also, running "UNIX2DOS.EXE" on the text files changes them to CR+LF format. Netscape on the UNIX/Mac/Windows platforms prints the articles just fine, and so does Internet Explorer on all available platforms. Anyone who is using UNIX (or a derivitive) should be able to print via "lpr" without any problems, so long as the printer is configured properly. HiR Authors are required to put their handle on any of their work, and they are strongly urged to place "HiR" in some way, shape, or form in the article. 0x07 What about disributing and copying HiR? HiR Articles ARE Copyrighted material, but due to our beliefs, you are free to distribute it at no cost to the recipients in whole electronic form, or as one un-modified article. If you wish to reference an article of ours, say for an essay, use the same process you would use for any magazine. We have no problem with other people using our information, just give credit to the article's author where it is due. We would rather you not place HiR content in your own E-Zine. Place links to our site, or something, and recommend reading the article. The Editor of an E-Zine published in Brazil (Brazil's main language is Portugese) wanted to know if he could translate some of our articles and place them in his freely-available E-Zine. Because he asked, we allowed him to do so, while giving HiR and the Authors of the Articles credit. This is about the only way we will let HiR be placed in another Zine, as the content will be able to reach across a language barrier in this manner. If you have any doubts that we would approve of how you are copying HiR, contact our E-Mail account (H_i_R@Hotmail.com), and we'll talk. Basically, if you post an unmodified article, or a whole HiR Issue, you're going to be safe, as the author's name is in it, and usually so is "HiR", somewhere, as well. We would hate to see what would happen to someone that tried to pass off our hard-written words as their own. Hard-Copy distribution: As far as distributing hard-copies of HiR, you really must contact us. If distributing one of our articles hard-copy, we require you to distribute all articles in that issue as well, in the original order, with credit given to the HiR Crew (credit to individual writers is already at the beginning of each article). Depending on if the hard-copies will be distributed (especially for a fee), we may, at our option, deny you the right to distribute our material, or request royalties. Printing a copy out for yourself for archival purposes or to take with you to sociology class to read while the teacher drones on and on and on,.. You can do that without permission. That's fine. =] 0x08. What's with the "Affiliates"? HiR is affiliated with a few pretty good sites. Hacker News Network and Packet Storm Security are the 2 heavy hitters. These 2 news sites are devoted completely to NEW hacking information, and hacking/network related programs. The guys at HNN constantly weed through newsfeeds and web sites, looking for news that's pertainent to hacking, and all the guys at Packet Storm sift through massive amounts of hot-off-the-press files and programs for almost all platforms. We have a mild affiliation with Hack Factor X. HiR Forms affiliations with groups or websites that uphold similar ethics and virtues as we do. With the news sites that we are affiliated with, we give back a tiny piece by giving them someting to post on their site every 2 or 3 months. =] Packet Storm Security also mirrors just the E-Zine text files that we produce. 0x09. How popular is HiR? HiR really started to pick up a massive reader base with the affiliation of the Hacker News Network (http://www.hackernews.com), who have been more than kind to our needs. Before the affiliation, HiR was a fairly small-spread Zine, mostly found on some BBS's, and not very many people knew about us. Later, we also joined up with Packet Storm Security (http://packetstorm.securify.com), which also increased readers by quite a bit. Typically, the main HiR Distro Site alone gets around 2000 hits per week. While this isn't much, it's a lot more than we used to get. Within the first week of HiR 9's release, we got over 20,000 web hits. With each release we seem to get a few more hits per week average, and the first week or 2 after a new Issue is just phenomenal. We really wouldn't be where we are today if places like Hacker News Network and Packet Storm Security weren't around. 0x0A. Where can HiR be Found? HiR's current main distro site is currently at: --> http://hir.chewies.net <-- This URL has changed many times, and it's subject to change again. This distro site contains all sorts of stuff other than the 'Zine, as well. We have a library of cool Windows 95/98/NT and UNIX/Linux programs. These programs are usually kept up to date, but not always. If you cannot find our new URL (for instance if we had to abandon that server for some reason or another), then check out our "HNN Affiliate link" at hackernews.com. Other places you can find HiR: Official Southwestern U.S. Distro Site Mirror: --> http://azure.rcn.nmt.edu:2007/hir/ <-- This site is up only when The Man in Black is away at school. Usually it's down in the summer. This site tries to be an exact replica of the HiR Distro Site. Packet Storm Security --> http://packetstorm.securify.com <-- You'll need to search for "HiR" or E-Zine to find us, because they don't let you type in the whole URL, you have to link direct from their site. This is to prevent bandwidth theft, so you can't just link directly to images or files on their box. 0x0B. Is there a mailing list to announce new Issues? Althogh it's crossed our minds a few times, none of us can justify maintaining a mailing list. We're just not popular enough to need one. We believe that our readers probably keep up on the news sites, and Packet Storm + Hacker News Network publish release announcements for us. Visit the HiR Distro Site often. If you don't find a new Issue of HiR, you'll probably find several new files every week or 2. Hacker Information Report Issue #10 Hacker Newz: A Look into the goings-on of the HiR Crew Well, we obviousely had some major productional slow-downs this time around. It's been months and months since the last issue, but at least we're not trying to release garbage and pass it off as a high-quality Text E-Zine. Defcon 7 was a complete and total blast, and much was learned there, both educationally and practically. There was a great amount to be absorbed this year, and we didn't have time to take in all aspects of the convention. This year, unlike last, all of the HiR Writers that attended Defcon were able to bring full-fledged laptops. Axon purchased a fairly nice Pentium 90 with 40 megs of ram and 810 megs of hard drive just before the convention. He took two other laptop hard drives along for the ride. (The three drives had different OS's on them). Frogman bought a newer laptop for defcon (a 486/75). We got quite a bit done at the convention. Each of us made some new contacts, picked up some vital information, and purchased all sorts of sordid goodies. We bought one copy each of NetBSD, FreeBSD, and OpenBSD. As a whole, It'd be safe to say that the HiR Crew really loves the work that all these guys are doing. The mentality behind the BSD's is quite a bit different from the driving force behind Linux (Availability of source code and the ability to obtain the OS for free are some similarity), but the BSD's are really a tad less glamourous, but usually more stable, and more secure. (The OpenBSD Project, for instance, is proactively focused on security, and produces what many people, myself included, would call one of the most scure OS's available) New on the hardware list for DefCon 8: o Axon picked up an RS/6000 for cheap. It's a pizza-box style case. Perfect for number crunching. We'll probably run John the Ripper Under AIX 4.3.2. o Asmodian's almost got his hands on a new(er) 200 MHz Laptop. This will replace the one he's currently using (Pentium 120?), which he got shortly after returning from Defcon 7. He took a 486 to DC6&7. =] o Frogman's Parting out his ThinkPad 720. He'll probably have something better for DC8. On other notes, we changed URL's again. Changed Servers and everything. Mega-Shouts to Razathorn for gracioucely providing the space and bandwidth we need. "Even if you're not in the scene, you rox0r. (inside joke)" Hopefully, we'll be able to pump out s'more goods here in the near future. We have some more stuff lined up. Oh yah. I didn't have a really cool hands on project in this issue... What to do? hrm... Ah, well... Maybe next time, guys. --HiR Crew