- NANOG - lists.nanog.org

Re: RBL quandry - opinions hereby solicited
by Dan Maus 17 Nov '98

17 Nov '98

> From errors-nohumans(a)merit.edu Mon Nov 16 03:34 MST 1998 > To: nanog(a)merit.edu > Subject: RBL quandry - opinions hereby solicited > Date: Mon, 16 Nov 1998 02:17:36 -0800 > From: Paul A Vixie <paul(a)vix.com> I fully support you if you decide to blackhole Network Solutions. I also support the revocation of their NSF contract for improper use of the domain contact information entrusted to them. This is another round from them, we got several copies of a hostmaster $1000 seminar spam from them a couple of months ago. I despise all spam, especially the scum eminating from Network Solutions, It's time for somebody to take out the trash. NSI needs to be fired for abusing our resources, in my opinion. If they don't have enough bandwidth to handle whois requests and TLD zone transfers to root-servers.net then they sure as hell don't have enough bandwidth to be spamming us at our expense. Off with their head. Dan > The RBL team and I are kind of wondering what to do about some spam we got. > Because blackholing NSI would be of operational concern to a lot of you, I've > decided to ponder this question out loud: > > ------- Forwarded Message > > Date: Wed, 11 Nov 1998 08:50:26 PST > To: rbl(a)maps.vix.com > Subject: Paul - value call on this > > Technically, this is an opt-out customer-relationship spam. > > I think it is a special case, because _there is no where else to go_. > > 208.226.58.70 should be RBL'ed, IMHO. Help me. > > > Return-Path: owner-admin1(a)LISTS.NETSOL.COM > > Received: from pasteur.netsol.com ([208.226.58.70]) by ns2.galaxy-net.net > > (8.8.7/8.6.9) with ESMTP id QAA00585; Tue, 10 Nov 1998 16:50:06 -0800 (PST) > > Received: from pasteur (pasteur [208.226.58.70]) > > by pasteur.netsol.com (8.9.1/8.9.1) with ESMTP id TAA23788; > > Tue, 10 Nov 1998 19:40:31 -0500 (EST) > > Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release > > 1.8c) with spool id 0342 for ADMIN1(a)LISTS.NETSOL.COM; Tue, 10 Nov > > 1998 15:01:15 -0500 > > Received: (from listmngr@localhost) by pasteur.netsol.com (8.9.1/8.9.1) id > > PAA18548 for admin1(a)lists.netsol.com; Tue, 10 Nov 1998 15:01:14 > > -0500 > > (EST) > > X-Mailer: ELM [version 2.4 PL25] > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Message-ID: <199811102001.PAA18548(a)pasteur.netsol.com> > > Date: Tue, 10 Nov 1998 15:01:14 -0500 > > Reply-To: admin-remove(a)LISTS.NETSOL.COM > > Sender: Owner-Admin <owner-admin(a)LISTS.NETSOL.COM> > > From: List Manager Account <listmngr(a)LISTS.NETSOL.COM> > > Subject: Network Solutions' E-Commerce Update > > To: ADMIN1(a)LISTS.NETSOL.COM > > Content-Type: text/plain; charset=US-ASCII > > > > ########################### > > > > Dear Customer, > > > > You are a valued customer and we want to help increase and > > protect the value of your domain name. As a free added benefit of > > your domain name registration, we would like to send you our > > "E-Commerce Update" from time to time. In these updates, we will > > try to identify helpful information and news that you can use to > > enhance the value of your Web address. If you do not wish to > > receive this newsletter in the future, simply respond to this > > e-mail with the word "remove" in the first line of the message. > > If you have any questions or comments, please send them to > > hostmaster(a)internic.net. > > > > Network Solutions - the world's leading provider of domain name > > services -- together with VeriSign -- the world's leading Web > > security provider -- has published a new informative guide to > > on-line security, "Securing Your Web Site for Business." > > > > "Securing Your Web Site for Business" outlines the options you > > have to secure and protect your Web site. By downloading your > > free copy (http://www.verisign.com/nsi/whitepaper) you will be > > able to learn how easy it is to secure your site in order to > > protect yourself and your customers. > > > > Issues covered in "Securing Your Web Site for Business" include: > > > > * Why on-line security problems could slow the growth of your > > business > > * How to maximize your on-line security at a low cost > > * How to accept credit cards and sell products on-line---securely > > * What a Digital ID is > > * Why you need a Digital ID > > * How to obtain a Digital ID for your Web site > > > > As an additional service to our customers, Network Solutions and > > VeriSign bring you a special free trial version Secure Server ID. > > VeriSign Secure Server IDs are the security solution currently > > used by over 90 percent of Web sites conducting secure online > > commerce and this free trial will allow you to experience how > > easy Web site security can be. Please visit us at > > http://www.verisign.com/nsi/trial to start experiencing the > > benefits of on-line security today. > > > > We would also like to take this opportunity to remind you of the > > importance of keeping your Network Solutions domain name records > > up to date. Incorrect data can result in your next invoice being > > delivered to the wrong location, and may cause delays when you > > request other services such as a Secure Server Digital ID. To > > review your domain name records and the associated information go > > to http://www.internic.net/verisign/update.html. > > > > Thank you for being a Network Solutions customer. We look forward > > to serving your future domain name needs. > > > > Sincerely, > > > > Doug Wolford > > Senior Vice President > > ------- End of Forwarded Message >

3 2

clue phone
by Janis Purl 17 Nov '98

17 Nov '98

TTSG and nanog: Excuse our non response to the hacking problems over the weekend. We have just gone to a central response system and have had a bunch of completely new people staffing it over the weekend. We will take steps to have the clue phone installed in that center and also have encouraged the staff to not just give random answers when called. They will now respond that they don't know if they really don't know the answer and will find someone who can answer the question. Now to respond to the attack issue. Exodus leases IP space to various customers, many of whom in turn have customers. One of our customers had their name server hacked and that machine was attacking everything else in sight. When one of the engineering staff found out the attack was in progress, we took the name server off the network and contacted the Sys. Adm. That took place Sunday evening. The system has been cleaned up and is now back in operation. We are looking to see if anything else comes from that customer. An aside: We don't filter in the routers as a rule because our Backbone engineering group is concerned about router performance. We go to the source to attempt to stop problems and not just filter the packets. Sincerely, Janis Purl, Abuse Manager and Leroy Lacy, Director of Security Exodus Communications

1 0

Re: National Infrastructure Protection Center
by Bill Woodcock 17 Nov '98

17 Nov '98

Ah, but at least they're kind enough to warn you, right next to their mailto link, that they don't respond to email. :-) -Bill

1 0

Another origin IP
by Richard Irving 17 Nov '98

17 Nov '98

209.119.115.65 telnetd a mile a minute....... to our DNS. Check yours !

2 1

Re: RBL quandry - opinions hereby solicited
by Dean Anderson 16 Nov '98

16 Nov '98

>>> Technically, this is an opt-out customer-relationship spam. >>> >>> I think it is a special case, because _there is no where else to go_. Uhh, aside from the other issues, there are actually other registries you can use. You don't _have to_ use NSI. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

RE: Exodus / Clue problems
by John Fraizer 16 Nov '98

16 Nov '98

Why on earth would anyone let any of the following networks in to their network at the border? 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Hell, for that matter, I block anything claiming to be from our networks as well. There's no way they'll be originating from the outside unless it's spoofed. Nothing and I mean NOTHING claiming to be from any of them at your border is valid. At 09:36 PM 11/15/98 -0500, Adam Rothschild wrote: >On Sun, 15 Nov 1998, Dave Van Allen wrote: > >> Same here, dozens of times in a few seconds just now, to all listed >> nameservers... I can't imagine what "process" could do this >> unintentionally. Exodus??? You home? > >Interesting you mention this. I've noticed the following on a FreeBSD >2.2.6 box, running BIND 8.1.2... > >server# netstat >Active Internet connections >Proto Recv-Q Send-Q Local Address Foreign Address (state) >tcp 0 0 server.4375 172.16.1.1.1984 >SYN_SENT >tcp 0 0 server.ftp server.4374 >TIME_WAIT > >Internal addr space... port 1984.. cute. > > > ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

5 4

Re: Hold on to your news servers
by Scott Gifford 16 Nov '98

16 Nov '98

>> I think a lot of people hope you are reconsidering your plans to do this. >> It's a nice idea, and your motivation is good. It just won't work in >> practice. So, in my nicest and most appreciative tone, I would like to ask >> you on behalf of myself and many people who are also appreciative of your >> efforts and your motives to reconsider and abandon this plan. > >I'd be happy to abandon it if something that accomplishes the same job, or >substantially the same job, shows up before it goes online. Have you considered using NoCeM's to do this? This would be much more opt-in, as somebody would have to specifically configure NoCeM to accept your key. It is also much more efficient than cancels, at least propogation-wise. Just a thought from a news administrator who doesn't want to be processing 300,000+ cancels a day all of a sudden, -------Scott.

1 0

Exodus / Clue problems
by TTSG 16 Nov '98

16 Nov '98

Hi, Sorry to cross post, but is there anyone monitoring this list from Exodus with 1/2 a clue who might be able to help me? I called the NOC with an in-progress abuse and was told : 1) We don't know who owns that IP 2) We can't get into our own routers 3) We don't have a ticket system 4) The abuse people have a ticket system, but only if we can associate it to a customer (See #1) 5) We don't know how often the "abuse@" is checked 6) Email us the logs, and thanks for calling. AAAAAAAAARRRRRRRRRRGGGGGGGGGGGHHHHHHHHHHHHH!!!!!!!!!!!!!!! Tuc/TTSG

20 32

Re: Exodus / Clue problems
by John Fraizer 16 Nov '98

16 Nov '98

At 05:18 PM 11/16/98 -0500, Daniel Senie wrote: >Actually, the blocks are mine, not theirs. If you use a traceroute on a >system which uses ICMP ECHO packets to do the trace, instead of the >older Unix implementations which use random UDP ports, your traceroute >will get to my site without trouble. The traceroute I am running is current as it gets, for the unix world that is. I have found that most sites won't block UDP near as often as they block ICMP and this, I have much more success with this traceroute than say, the tracert program on winblows boxes. > >I hadn't thought about the PMTU failure this causes. Not nice at all. Most people don't think about it. It can cause you problems though. Especially when in most cases, when PMTU can't be determined, it is defaulted to 1500. >The problem with this is I can't do traceroutes out, then, because all >the responses from the 10.x.x.x/8 and 172.16.0.0/16 machines get caught >in the filters. Sure you can. Any decent NAT or MASQ system will take care of that for you. Case in point: root> ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:C9:06:7C:82 inet addr:192.168.101.250 Bcast:192.168.101.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5427402 errors:0 dropped:0 overruns:0 TX packets:4912650 errors:0 dropped:0 overruns:0 Interrupt:9 Base address:0xff40 root> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 62 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 19 lo 0.0.0.0 192.168.101.48 0.0.0.0 UG 0 0 412 eth0 root> traceroute mae-east.psi.net traceroute to mae-east.psi.net (192.41.177.245), 30 hops max, 40 byte packets 1 barrister (192.168.101.48) 0.467 ms 0.363 ms 0.346 ms 2 38.1.1.1 (38.1.1.1) 154.795 ms 139.175 ms 139.722 ms 3 38.17.10.1 (38.17.10.1) 139.654 ms 139.077 ms 139.712 ms 4 leaf2.nc.us.psi.net (38.1.46.2) 179.613 ms 179.044 ms 159.642 ms 5 rc1.nc.us.psi.net (38.1.26.1) 299.494 ms 188.930 ms 169.680 ms 6 core.net223.psi.net (38.1.2.6) 209.555 ms 178.857 ms * Note: I am quite amazed to only see ONE "*" in that trace considering the network that box is attached to. >> than your own. I Hope nothing happens that would require your PERSONAL >> attention while you're at some convention, on vacation, etc. > >Fortunately I have enough of an operation to have a direct dial-in to my >network so that I can get in even if the ISP link is down, but I agree >with your assessment. I think most of us can do that. The difference is that I use the dialin for security to get devices that I can NOT install SSH on. For everything else, it is a backup link. It would be quite costly for me to dial into the box from the Philippines while I'm over there, even if I could find a decent phone line to do so. The satellite link while slower than I would like, works quite well though. I suppose that you could also telnet/ssh to a "real" IP address behind your router and then telnet to the router though. >> ...and one last point... >> >> - Have someone loan them a clue about why they should NOT use RFC1918 space >> in the way your isp is doing so. > >Agree. Unfortunately, when selecting ISPs, this was not an aspect I >expected I'd have to worry about, and so I didn't ask. It certainly goes >on my list for the next negotiation, though. I never asked FNSI either. I guess that considering how many providers actually do this, I was lucky to find one that actually knows better. ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

RE: Exodus: this is bad
by Chris Mauritz 16 Nov '98

16 Nov '98

The jerkoff is trying from 207.104.58.91 too. I've just filtered it as well. Check out /var/log/secure on oven. C Chris Mauritz Director, Systems Administration Rare Medium, Inc. chrism(a)raremedium.com -----Original Message----- From: Adam Rothschild [mailto:asr@millburn.net] Sent: Monday, November 16, 1998 5:31 PM To: nanog(a)merit.edu; list(a)inet-access.net Subject: Exodus: this is bad Hrrrm, I'm seeing 38.29.63.195 trying to telnet to every IP addr in one of my Exodus /24's... (around 4.30p EST) Anyone notice any similar behaviour?

2 1