August 1996 - Test - lists.nanog.org

Re: *** MAKE SPAM@INTERRAMP.COM DIE FAST!!! *** (fwd)
by Robert Sanders 24 Aug '96

24 Aug '96

lists(a)reflections.mindspring.com writes: > The transition has not yet occurred; we will start transferring customers > come the beginning of September. In addition, we will not be offering free demo accounts. The ease with which spammers can acquire throwaway PSI accounts, coupled with PSI's inability to trace a given post back to its source, has made PSI a spammer's dream. It's not a matter of apathy, but of impotence. Those in charge of curtailing net abuse had few of the facilities necessary to do so. We will require NNTP authentication for news posting, and will immediately take action against accounts whose postings violate our terms of service (http://www.mindspring.com/aboutms/policy.html) -- Robert

3 2

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Curtis wrote: >I've said many times that if security in your network is weak enough >that you need to worry about LSRR packets you need to worry about >security in your network. Not at all. LSRR is a nice tool to mount practically untraceable flooding attack (hint -- just forge source address and spread intermediate points evenly across the network). Shutting you down may be exactly what the attacker wants. (LSRR attacks against service providers are particlularly bad -- just imagine somebody flooding you at T-1 speed and bouncing packets back and forth two dozen times. Poof -- here goes the T-3 :) There are particularly nasty man-in-the-middle attacks (which defeat one-time-password login authentication, like that) if you can combine LSRR with bogus routing. >The minute someone unpacks a Sun workstation, configures an IP address >and sticks it on the ethernet without installing the security patches >and doing the administrative work needed to secure the machine, if you >had a small hole in your security with LSRR, you now have a gaping >hole in your security. If you are relying on blocking LSRR, your >security is a weak as the most peerly administered machine on your >network. A real bad thing if you are constantly hiring. I never argued that blocking LSRR plugs all security holes. However it is one thing _not_ used in normal operations; and everything not used _must_ be shut down by a prudent security. And, again, there are several LSRR-based attacks. >Even so, if anywhere, where you want LSRR turned off is the border >router(s) in front of the machines used for operations, network >management, etc. >Obviously you want your network to be secure even if >LSRR was enabled for the reason I cited above. Security Rule #1: You're never secure. Turning LSRR off doesn't particularly hurt connectivity, and is cheap. It's a way to _improve_ security. --vadim

3 3

new rtty released (V3.2) -- console server software for UNIX systems
by Paul A Vixie 23 Aug '96

23 Aug '96

------- Blind-Carbon-Copy to: nobody(a)vix.com reply-to: paul(a)vix.com Subject: new rtty released (V3.2) -- console server software for UNIX systems Date: Fri, 23 Aug 1996 15:29:41 -0700 From: Paul A Vixie <vixie(a)wisdom.home.vix.com> FTP Path <URL:ftp://ftp.vix.com/pub/vixie/rtty-3.2.tar.gz> (24940 bytes) Credits This work has been paid for by Digital Equipment Corporation, Vixie Enterprises, and the Internet Software Consortium. /* Copyright (c) 1996 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ Introduction Rtty is "remote tty" (not radioteletype). You run a server per port and then connect to that server from any number of "tip"/"cu"-like clients. I wrote it for our console concentrator, but there's no reason other than performance why you couldn't use it to drive modems, printers, prom programmers, and so on. When you connect to the server from more than one client, all clients will see the same session and all clients can type at and see output from whatever device is attached to the tty port. Typing at a device when someone else is also typing at that device is confusing and more than a little bit creepy. You will need a BSD-derived UNIX to use this, and you will need "termios" (the POSIX terminal interface). (If "man termios" doesn't say something informative and useful, you are probably hosed.) Ultrix and SunOS and AT&T V.4 all have what you need. AT&T V.3 and non-Tahoe/Reno BSD are both lacking one thing or another. Details The server can be told to keep a log file. This log file will record all data in or out of the tty port; that is, data that comes from the tty port will be logged, and data that is typed at (and therefore sent to) the tty port from any client will be logged. There are no special markers in the log file to tell you which data came from which source; the data is all just interleaved in the order it was received by the server. Note that line terminators in the log file will be "physical" meaning probably \r\n rather than the normal UNIX \n. It depends on the device on the other end of the tty port, but \r\n is pretty common. We watch our log files with daemons that do roughly what "tail -f" does except they scan for things like "file table full" or "out of inodes" or "panic" -- you know, things that computers say when they are unhappy. None of our scanning software is included in this release of rtty, but you can write your own. Note that the protocol used between the server and client is mostly implemented in a separate module of this source directory; if you want to connect to the server in real time and scan the output direcly instead of tailing the log file, that's an option. (You would most especially want to do it this way if you aren't using any log files.) UNIX-domain sockets are the normal way that clients connect to the server. Both client and server support internet-domain sockets (we'll let you figure out "how" by reading the sources), there is absolutely no security in rtty, and opening up our tty ports to the local internet with no access control has seemed like a bad idea (especially since they are the main consoles of our Internet gateway computers). So we don't use this feature. (Win promised to Kerberize this stuff for me but then he got busy.) Other Notes Since there's no documentation, there's no harm in telling you that the "console" script just runs "rtty" with some obscure arguments to grease its skids. While in "rtty", a "~" after a carriage return (\r or 0x0D) is magic; "~?" will explain the magic to you somewhat tersely. The source code will explain it in more detail. Have fun. Drop me a note if you find this useful. Definitely drop me a note if you find a bug or add a feature. Paul Vixie <paul(a)vix.com> ------- End of Blind-Carbon-Copy

1 0

Re: NANOG Registration
by Brett D. Watson 23 Aug '96

23 Aug '96

ok, so the only confusion is with me reading mail out of order. sorry folks. -brett > On Fri, 23 Aug 1996, Brett D. Watson wrote: > > > i just went back to redo the web form (since i was one that tried using a > > non-visa/mastercard) and note that the button for credit card selection lists > > american express as an option. you should probably remove that to avoid any > > more confusion. > > As Pam stated in her last message American Express is now a option. > > Nathan Stratton CEO, NetRail, Inc. Tracking the future today! > --------------------------------------------------------------------------- > Phone (703)524-4800 NetRail, Inc. > Fax (703)534-5033 2007 N. 15 St. Suite 5 > Email sales(a)netrail.net Arlington, Va. 22201 > WWW http://www.netrail.net/ Access: (703) 524-4802 guest > --------------------------------------------------------------------------- > "Therefore do not worry about tomorrow, for tomorrow will worry about > itself. Each day has enough trouble of its own." Matthew 6:34 > >

1 0

Re: Customer AS
by matthew＠scruz.net 23 Aug '96

23 Aug '96

Original message <m0uscvd-000F25C(a)roam.psg.com> From: randy(a)psg.com (Randy Bush) Date: Aug 19, 15:36 Subject: Re: Customer AS > > >> just what i always wanted, two connections to a broken provider. you > >> must be kidding. > > I guess this brings to mind the question: Why would you want *any* > > connections to a broken provider? > > all providers break. >-- End of excerpt from Randy Bush Agreed. That can't be stressed enough. *ALL* providers break. Many of them choose different days and times to do so, and multihoming to different providers causes a huge increase in total reliability as a result. Speaking of broken providers, AGIS just mailed me and said that Sprint is "broken" today, and so they've decided to filter out Sprint routes until it gets fixed. Anyone know the _real_ story? -matthew kaufman

4 3

Re: NANOG Registration
by Brett D. Watson 23 Aug '96

23 Aug '96

i just went back to redo the web form (since i was one that tried using a non-visa/mastercard) and note that the button for credit card selection lists american express as an option. you should probably remove that to avoid any more confusion. -brett > > Please NOTE the only credit cards that we are accepting for NANOG are > VISA & MasterCard. We also are accepting checks made out to the > Universtiy of Michigan. See the registration form on the Merit Web Page. > Pam Ciesla

2 1

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Curtis Villamizar <curtis(a)ans.net> wrote: >We have traced back such "clever" denial of service attacks before. >Within the last 6 months even. >Have you forgotten that we log and keep track of source/destination >pairs. I sincerely wish you good luck doing that at OC-12. If you know a magic technology which can do that please let me know. Doing that at 10 kpps is not going to be a solution any time soon. I would also wish you luck with logging SA/DA pairs at places like .ICP.NET. where source/destination matrix is about 1-2 millon entries long. >It is really easy for us to spot in incoming path with a set >of sources that were never coming from that direction and start >working backwards. Yeah? Over six backbones? >Other respectable providers cooperate. Nearnet >for example flew out a person and workstation to track an attack >coming through them. Cool. Now, if such a bogon generator becomes someting easily accessible to every newbie (as it is bound to become, sooner or later), that certainly will help. >We have Unix boxes deployed in every POP, even >with our new backbone. These watch over the FDDI rings. That certainly helps to people who already have to use FDDI switches. >Half the time the people doing this hacking are coming in from dialup >lines. Sometimes they break into somewhere better connected. Quote from one friendly sysadmin at very large and prestigeous u here in Bay Area: "Security? We don't have any. We have that special wide-open box so hackers can play with it and leave other machines alone". >An attack capable of any noticable load on a backbone is quite remote. I had two instances where unintentional flooding was saturating the backbone links (both cases with T-3 connected customers, one caused by fautly software, another by broken FDDI adapter). > Ok, with only one intermediate point allowed. _That_ should > take care of all diagnostic needs. >That would be useful. It could still be UDP. Sending something to ports which can be used by applications is not kosher. If anything, traceroute should at least attempt to use UDP "discard" service, not some random high ports. > Should i write a backbone-crasher and post it to USENET just to > make a point about LSRRs? Note that a provider which won't > shut LSRR will be the threat to others... >If we find out you did we would prosectute. I know for sure that the code doing nasty things with TCP resets exists and works. (As for "finding out" -- sorry, there is no concievable way of tracing origins of code if minimal precautions are taken, as any virus writer can attest). In any case, i don't care to do it. I have much more straightforward ways to achieve the same effect, in the very unlikely case that i ever wish or need to do that, ok? >We can very easily detect probes because we don't run any telnet, >rsh/rcp, or RCP services and these are commonly attacked. Any >activity destined to these ports is logged. Of course we log LSRR >to lower port numbers too. Sure. The real security is proactive, not retroactive. Logging only helps you to find out idiots who don't know better than to send sufficient quantities of probes to attract attention. A serious attacker would find a throw-away staging point (about five minutes worth of searching, realistically) and do probes from there. It is _much_ better to eliminate the unnecessary door, than to post guard at it. --vadim

1 0

Credit Cards for NANOG
by Pam Ciesla 23 Aug '96

23 Aug '96

We have added American Express to the accepted credit cards for the NANOG Meeting. If you have already sent your registration with your American Express info DO NOT resend it I will add you to the list of attendees. Thanks Pam Ciesla

1 0

Gaol...nee blacklist
by bmanning＠isi.edu 23 Aug '96

23 Aug '96

Well, AltaVista found a dead pointer... Not sure what happended here. Blacklist of Internet Advertisers Blacklist of Internet Advertisers. ========================================================================= Canter and Siegel acknowledge Blacklist's... http://www.ip.net/BL/blacklist.html - size 48K - 15 Jun 96 -- --bill

2 1

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Curtis Villamizar wrote: > Not at all. LSRR is a nice tool to mount practically untraceable > flooding attack (hint -- just forge source address and spread > intermediate points evenly across the network). Shutting you > down may be exactly what the attacker wants. >Oh come on. Like they're not going to get caught stuffing an entire >T1 with LSRR packets. Face it. You're grabbing at straws. Ugh. To kill multiple DS-3s you don't even need a full T-1 (you need one LS address for every loop), and you can kill multiple DS-3s and an IXP to boot, with the single stream of bogons routed in a loop with many hops. And there's a lot of big name Us with DS-3 connectivity and no security whatsoever. Now, throw in randomized first hop and forged source address, and i'll wish you good luck catching the perpetrator. A careful attacker would also randomize destinations and make it to look like regular TCP traffic. (And did anybody think of IP stacks which reverse the source routes, just to make things funnier). >Besides the fact that with your suggestion of traceroute using ICMP >echo requests they'd just send a T1s worth of ICMP echo requests with >LSRR and accomplish the same thing. Ok, with only one intermediate point allowed. _That_ should take care of all diagnostic needs. >LSRR is just too useful for diagnosing network problems to shut down >on a backbone. I sometimes wonder if the threat of hackers is exaggregated. They certainly missed a nice opportunity to crash the Internet with TCP resets on iBGPs. Now nobody cares about the creative potential of LSRR-anonymized denial of service attacks. They must be stupid or something. Should i write a backbone-crasher and post it to USENET just to make a point about LSRRs? Note that a provider which won't shut LSRR will be the threat to others... --vadim

3 2