|
|
 Fable Of Contents
ISP Tech Talk by Avi Freedman
Also, thanks to all who came by our booth at ISPCON for newsread.com. I'm sorry if we were out of T-shirts. Our "My ISP sucks less" T-shirts were the hit T-shirt of the show, apparently, and we blasted through two batches of T-shirts (500 in all) in 4 hours on the first day and 4 hours on the last day. Anyone who signs up for a newsread.com trial gets one now, or if you really wanted one, just send us money for shipping and we'll send you one (see http://ww w.newsread.com for details). Of course, the back says "with newsread.com" - the T- shirt is a promotion, of course. Also, we've printed up some hats that were pretty popular. The three Cisco-related ones were "conf t"; "write erase"; and "sho ip bgp". We'll try to have pictures of them up on the isp-sat web page (URL below) for those interested in wearing "Cisco Chic."
IP SPACE UPDATEGood news, ISPs: The new ARIN rules have kicked in. It is now MUCH easier to get your own address space than ever before. It'll cost you $2,500 to do so, but the benefits are well worth it. Why is it important to have your own address space? Well, if you are using address space that's part of a larger "aggregate" block (we went over this a year ago in this column), some parts of the Internet won't see a "smaller" announcement unless it's at least of size "/19" - a /19 is 32 contiguous Class C-sized blocks. So if you announced a /22 that you had from provider A to provider B, and your connection to provider A went down, some parts of the Internet (say, Sprint and DIGEX) won't hear that /22 announced from provider B. In fact, they never hear that /22, even from provider A - it's just that since that /22 is part of a /16 or so (a Class B- sized block or larger), the packets from Sprint and DIGEX find their way to your network based on that larger "aggregate" route. So what are the new rules? If you have *well-utilized* a /21 of space, you can get a /20 allocated to you, and announce it as a /19. A /21 is 8 contiguous /24s (a /24 is the CIDR notation for a Class C-sized block); a /20 is 16 contiguous /24s; and a /19 is the magic 32 contiguous /24s that "bypass" the route filters imposed by the some, such as Sprint and DIGEX. You'll have to agree to renumber your old space quickly into the new space. What does "well-utilized" mean? It means, roughly speaking, that you've: a) sub-netted and sub-allocated your address space efficiently (thus, only giving people the address space they need, + or - 16 or 32 addresses); and b) have filed SWIPs (this process was covered by a previous column as well) in a timely fashion, informing the ARIN (and the world), who you've allocated or assinged that IP space to. See www.arin.net for more info about filing SWIPs. As a rough rule, being able to ping 50 to 70 percent of your address space is a pretty good sign. You DO need to file SWIPs for "subnet" allocations (allocations of less than 256 IP addresses), and you do NOT need to file SWIPs for "internal use" allocations - you just need to keep track of them and submit a list of how you're using space internally with your application for new IP space. This is very good news for the ISP community - many ISPs will become eligible for their own IP space at least a year or so before they would have under the old rules, which will cut down on the heartache of renumbering all of your IPs if you have to switch providers
FREE NEWS FEEDSWe at Net Access are embarking on a new project, isp-sat (http://www.isp-sat.com). We're offering free 2-4 Mbps news feeds to any ISP east of the Rockies - all that ISPs have to pay is the one-time setup cost. We're also offering a free 6-month trial of web cache pre-population feeds (throwing HTTP objects into your local cache boxes in an attempt to have your cache boxes pull less terrestrial bandwidth), and the ability to back up your Internet connections via a combination of ISDN dial-out and Satellite return path. All of the details are on the web site. We've already had this cut into our newsread.com business, but that's a risk we take... This will work with any non-"sucking" news server you have locally.
MORE ON NEWSMore good news: (As it were.) Highwind.com has finally finished their news reading software, a mate for their industrial- strength (pardons, DIGEX) news transfer software called Cyclone. Their new reader products are called Typhoon (priced at $3k) and Breeze priced at $5k. They are designed to run under Solaris. Though there's a Linux port, it doesn't really work (they claim there are some issues about whether Linux really works, but that's another issue). Breeze and Typhoon have the same core, but Typhoon allows you to simulate multiple virtual news servers on one machine (to offer a newsread.com-type service). The software and docs are available for demo at http://www.highwind.com. Typhoon (I'll refer to both as Typhoon from now on) stores articles and overviews very intelligently (cyclically on disk, actually), and has the same intelligent object caching engine that Cyclone has, but tuned for news reading rather than feeding. Typhoon can support about 4,000 simultaneous news readers on a high-end multi- processor Solaris box; on a base Ultra one can expect one reader per 256k of memory, or 1,000-2,000 simultaneous news readers per 512mb Ultra 1/170. We're just testing the software now, but hope to report shortly on in-the-field results. newsread.com has two news reading boxes now - one is a Sparc 10 with a Sun "Model 81" CPU - 85mhz, 1mb cache; 256mb of ram; and 10 disks. It runs a modified INN 1.4unoff4 build with security and some performance patches, but it has a load of 2 when just receiving a full feed. In comparison, a Sparc 10 with a base Model 41 CPU (40mhz, 1mb cache) and 8 disks can receive a full feed with a load average of less than .25 - due entirely to the more efficient news storage on disk. There are other (mostly free) news reading products that'll be available soon (from the diablo and nntprelay crowds), and there's one that's been out for over six months from the cyclic-inn development team/worker - though that's not really ready for novice use. The diablo work looks interesting and follows a more distributed/caching model, with the concept of "header-only feeds", but if you want to reduce News to almost no work at all, I strongly encourage you to grab an evaluation copy of Typhoon or Breeze and play. Your disks will kiss you for it. (Cyclic storage means much less disk seeking. You'll hardly know the news box is alive.) If you're interested in following the developments of the new news reading software packages, subscribe to the news.software.nntp group - but please, read the archives and follow the group for a bit before posting, as it's important to keep the signal-to-noise ratio good on that group.
BASIC IP FILTERINGMost of you are probably running unsafe networks. Unsafe for you and unsafe for the Internet community. What defines safe? Letting in only those packets that you should (that's "safe for you"), and sending out only those packets that you should (that's "safe for the community"). What kind of packets should you accept? Only packets destined to your own IP blocks, and only packets with source addresses outside your IP blocks. Why? There's never a time that you want to accept a packet from the outside world that says it came from inside your network. (Unless you're connecting multiple POPs via the Internet, which is a pretty bad idea. In which case your filtering job is much harder. Please consult an expert.) What kind of packets should you send out? Only packets with source addresses inside your network. Why? If you send a packet out with a source address of www.whitehouse.gov, it's a pain in the ass for someone out on the Net to try to track down and when they do track it down they're going to be unhappy with you for allowing a "bogon packet" out of your network. How do these packets with bogus source IPs get created? Well, long ago on a Net far away, all boxes connected and speaking IP were pretty expensive and were run by "professional" or at least "knowledgeable" sysadmins. However, on today's Net, every hacker d00d with a Linux box has root access on his own machine, and can generate any sort of nasty packet they want and send it down their dial-up SLIP or PPP line and into your network. With the well-known (by now) smurf attack, they can send one little packet with the source address of some other ISP's terminal server port (typically they'll do this because of some little baby fight on some little baby hacker d00dz IRC channel). Anyway, they'll send a packet with a bogus source address to the broadcast address of a huge network. On an improperly configured network, this'll cause tens or hundreds of ping-responses to go flooding at the IP of some other ISP's terminal server port - all because you let that bogon packet get out. As a network provider, we at netaxs.com have clocked over 200 Mbps of extra inbound traffic to our network at the peak of a smurf attack. All of that traffic was destined to one IP on a terminal server on a 56K customer of one of our T-1 customers. Not fun. So be a good Net citizen and filter crud from exiting your network.
HOW TO DO IP FILTERINGStep 1: Gather thy routes. Get a list of all of the IP addresses you use inside your network. A good starting point is "sho ip route" on your Internet-looking router. Let's say you gather:
207.106.50.0/23 (/23 = a mask of 255.255.254.0) 207.106.96.0/22 (/22 = a mask of 255.255.252.0) Now, you need to create your inbound and outbound filters. Step 2: Type "sho ip access" (from here on in we assume you have a Cisco router - if you don't, please buy one). Make sure you have no access-lists numbered 110 and 111. If you do, use different numbers as you follow along below. A note: Cisco ip access-lists have the format: ip access-list NNN [permit|deny] ip SOURCE DEST The [permit|deny] means that you can put permit or deny at that point in the line. SOURCE and DEST can both be any of: "host a.b.c.d"; "a.b.c.d m.n.q.0" (an ip and a netmask, describing an IP block, as we do below); or "any". access-lists start with access-list 1 and go to at least 199 on most Cisco routers. Step 3: The inbound list. We want to permit all packets unless they have a source address inside one of our routes. For the routes above, the list will be: ip access-list 110 deny ip 207.106.20.0 0.0.0.255 any ip access-list 110 deny ip 207.106.50.0 0.0.1.255 any ip access-list 110 deny ip 207.106.96.0 0.0.3.255 any ip access-list 110 permit ip any any So, what did we do? Well, first, notice the "0.0.0.255"; "0.0.1.255"; and "0.0.2.255". Those are what Cisco calls "inverse masks," which are used in describing "ip" filter lists, both "packet filters" like we're creating here and "route filters" like we'll go over in a column shortly. To compute them, take the "netmask" and subtract it from 255.255.255.0. So, notice for the three routes that 255.255.255.255-255.255.255.0 = 0.0.0.255; 255.255.255.255- 255.254.0 = 0.0.1.255; etc. Then, some more details: By making the "ip access-list"s have numbers above 100, when you type "sho ip access 110" you'll get packet counts at the end of each line showing you how many times each line was hit. You'll probably be surprised at the results. With the list above, *the first three lines should get NO hits* Why? Because they say "for packets going through this list, don't allow any packets that say they came from 207.106.20/24, 207.106.50/23, or 207.106.96/22." The fourth line says "permit any other packets." Since you should never get any packets from the outside that say they came from the inside, you should never get any hits on the first three lines. But you probably will. Sigh. Step 4: The outbound list. We want to permit all packets unless they have a source address NOT inside one of our routes. For the routes above, the list will be: ip access-list 111 permit ip 207.106.20.0 0.0.0.255 any ip access-list 111 permit ip 207.106.50.0 0.0.1.255 any ip access-list 111 permit ip 207.106.96.0 0.0.3.255 any ip access-list 111 deny ip any any So, what did we do? We permit any packets that have a source address within one of our network blocks. We deny all other packets. Again, you should see no "hits" on the fourth line of the access-list 111, but you probably will Step 5: Apply the lists to interfaces. Do a `sho conf' and make sure that on your external interfaces, you have no existing access-lists (`ip access- group NNN [in|out]'). If you do, consult with the person who put them there... If not, identify the serial (or other) interfaces you use to talk to your provider. If you talk to your provider via ethernet, ignore this column; you need more advanced lists. You CANNOT put these lists on your internal ethernet interfaces or you will kill your network traffic. But, let's say that you have on upstream link out Serial0. You'd enable and type `conf term'; then enter: int Serial0 ip access 110 in ip access 111 out end You'd do the same thing for Serial1 if you were using that to talk to an upstream provider. Then, you can type `sho ip access-list' or `sho ip access-list 110' or `sho ip access-list 111' to see how many `hits' you get on each line of each access list. If you have any questions before implementing this, I'd encourage you to ask on the inet-access list so others can learn from the answers. Note: We'll talk in the future about other things you'll want to put into your inbound and outbound filters (things like rejecting RPC, X windows, and other kinds of traffic), but these filters are a good first start. Thanks for being a safe net citizen.
|
