GBLX contact?
If there's anyone high level at GBLX on list at the moment could they please contact me urgently regarding a major security incident. thanks, Ray -- Ray Bellis, MA(Oxon) - Technical Director community internet plc - ts.com Ltd Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ tel: +44 1865 856000 email: [EMAIL PROTECTED] fax: +44 1865 856001 web: http://www.community.net.uk/
Re: GBLX contact?
> If there's anyone high level at GBLX on list at the > moment could they please contact me urgently regarding > a major security incident. Thanks guys, I have enough contacts at GLBX now :) Ray
Re: Cisco IOS Failure due to Virus
Stephen J. Wilcox wrote: Hi, we've seen this.. yuo need to make sure you filter the nachi worm 92 byte icmp echo's on your interfaces and it will be fine. The problem seems to be input buffers which use all the memory up for some reason. This sounds vaguely similar to the recent IOS buffers stuck issue. Pete
The Cidr Report
This report has been generated at Fri Sep 12 21:48:00 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
05-09-03124403 88573
06-09-03124437 88448
07-09-03124343 88533
08-09-03124412 88539
09-09-03124411 88684
10-09-03124489 88653
11-09-03124436 88752
12-09-03124543 88716
AS Summary
15758 Number of ASes in routing system
6223 Number of ASes announcing only one prefix
1470 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73289728 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 12Sep03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 124557887403581728.8% All ASes
AS4323 633 183 45071.1% TW-COMM Time Warner
Communications, Inc.
AS701 1470 1026 44430.2% ALTERNET-AS UUNET
Technologies, Inc.
AS7018 1390 979 41129.6% ATT-INTERNET4 AT&T WorldNet
Services
AS7843 536 148 38872.4% ADELPHIA-AS Adelphia Corp.
AS3908 909 535 37441.1% SUPERNETASBLK SuperNet, Inc.
AS6197 613 283 33053.8% BATI-ATL BellSouth Network
Solutions, Inc
AS6198 493 207 28658.0% BATI-MIA BellSouth Network
Solutions, Inc
AS4355 392 109 28372.2% ERMS-EARTHLNK EARTHLINK, INC
AS1221 979 698 28128.7% ASN-TELSTRA Telstra Pty Ltd
AS6347 349 92 25773.6% DIAMOND SAVVIS Communications
Corporation
AS1239 913 659 25427.8% SPRINTLINK Sprint
AS27364 318 68 25078.6% ACS-INTERNET Armstrong Cable
Services
AS17676 259 28 23189.2% GIGAINFRA Softbank BB Corp.
AS22773 257 26 23189.9% CCINET-2 Cox Communications
Inc. Atlanta
AS25844 241 14 22794.2% SKADDEN1 Skadden, Arps, Slate,
Meagher & Flom LLP
AS209509 296 21341.8% ASN-QWEST Qwest
AS6140 336 136 20059.5% IMPSAT-USA ImpSat
AS4134 317 119 19862.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS11305 230 38 19283.5% INTERLAND-NET1 Interland
Incorporated
AS4519 1784 17497.8% MAAS Maas Communications
AS6327 200 26 17487.0% SHAW Shaw Communications Inc.
AS2386 374 202 17246.0% INS-AS AT&T Data
Communications Services
AS2048 255 87 16865.9% LANET-1 State of Louisiana
AS17557 305 137 16855.1% PKTELECOM-AS-AP Pakistan
Telecom
AS14654 1672 16598.8% WAYPORT Wayport
AS705416 253 16339.2% ALTERNET-AS UUNET
Technologies, Inc.
AS5786 1655 16097.0% UPRENET University of Puerto
Rico
AS9800 202 51 15174.8% UNICOM CHINA UNICOM
AS3602 234 85 14963.7% SPRINT-CA-AS Sprint Canada
Inc.
AS20115 484 336 14830.6% CHARTER-NET-HKY-NC Charter
Communications
Total 14124 6832 729251.6% Top 30 total
Possible Bogus Routes
24.119.0.0/16AS11492 CABLEONE CABLE ONE
61.12.32.0/24AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd
61.12.34.0/24AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd
64.30.64.0/19AS14900 USLEC-CORP-1 USLEC Corp.
66.41.192.0/18 AS13367 ATT-BBND-B AT&T Broadband
132.0.0.0/10 AS568
Re: Cisco IOS Failure due to Virus
On Fri, 12 Sep 2003, Petri Helenius wrote: > > Stephen J. Wilcox wrote: > > >Hi, > > we've seen this.. yuo need to make sure you filter the nachi worm 92 byte icmp > >echo's on your interfaces and it will be fine. The problem seems to be input > >buffers which use all the memory up for some reason. > > > > > This sounds vaguely similar to the recent IOS buffers stuck issue. No, its quite different 1: On the vuln. the buffer filled up and could not be emptied without a reboot On nachi the buffer doesnt seem to fill and an acl or shutting the interface will solve the problem whilst the router stays up 2: On the vuln. the outcome was that the particular interface stopped forwarding traffic On nachi the router runs out of main memory and starts dropping processes because of malloc failure FYI I have only encountered the nachi problem on a few PE routers which were old and had little memory anyway eg Cisco 2500.. presumably the buffer filling isnt a memory leak and providnig there is enough spare memory the router wont be affected in this way. Steve
Re: Alert to Phone/Pager System
Vytek makes a product called Telalert that works for us. Been around for quite a while and runs on Linux. www.vytek.com -- Todd Christell Network Manager SpringNet www.springnet.net 417.831.8688 > > > I am looking for a hardware/software solution to a problem and I am > hoping someone has implemented something similar: > > A monitoring system notices an error and sends an alert to a system (the > alert can be sent over POTS or SMTP). The system recevies the alert > and sends out a message (Pager/POTS/SMTP/SMS) to a group of people in a > pager rotation. The 1st person is paged, if no response is received > the second person is paged and so on down the line until someone > responds. > > I looked at the Dialogic's The Communicator: > > http://www.dccusa.com/products.html > > But, it is a little pricey. I also looked at VOCP System: > > http://www.vocpsystem.com/ > > But, the desision maker is a little skittish about open source projects. > > Does anyone know of a happy medium between these two systems that will > fill the requirements outlined above? > > > Thanks! > > > allan > -- > Allan Liska > [EMAIL PROTECTED] > http://www.allan.org
New prefix
Collegues, We've just been allocated a new RIPE block in the 82/8 range. This block has only been removed from the bogon list since november last year. It has been advertised from our AS a couple of hours now, but I still lack reachability through some networks. I can be wrong, but do some networks still filter on this range? It looks like either a bogonfilter, or a specific AS/prefix filter, but that seems a bit unlikely. Regards, Stefan -- Stefan Baltus <[EMAIL PROTECTED]>XB Networks B.V. Manager Engineering Televisieweg 2 telefoon: +31 36 54624001322 AC Almere fax: +31 36 5462424 The Netherlands
Re: New prefix
At 10:56 AM 12/09/2003, Stefan Baltus wrote: I can be wrong, but do some networks still filter on this range? It looks like either a bogonfilter, or a specific AS/prefix filter, but that seems a bit unlikely. I see lots of longer 82.0.0.0/8 prefixes, but not yours. Are you sure your immediate upstreams have adjusted their filters to propagate ? You are to be announcing out of 8608 right ? ---Mike
Re: New prefix
On Fri, Sep 12, 2003 at 04:56:24PM +0200, Stefan Baltus wrote: > We've just been allocated a new RIPE block in the 82/8 range. > This block has only been removed from the bogon list since > november last year. > > It has been advertised from our AS a couple of hours now, but > I still lack reachability through some networks. > > I can be wrong, but do some networks still filter on this > range? It looks like either a bogonfilter, or a specific > AS/prefix filter, but that seems a bit unlikely. I do get the prefix from AMS-IX peerings, but from my upstream NTT/Verio I do not receive it. -- Cliff Albert| RIPE: CA3348-RIPE | https://oisec.net/ [EMAIL PROTECTED] | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A
92 Byte ICMP Blocking Problem
We started blocking 92 Byte ICMP packets on our ingress points on our core backbone routers. This was a recommendation from Cisco to help mitigate the effects of the Nachi worm. Since then, we have been hammered with customer complaints concerning the inability to talk to mail servers and ssh to their servers, as well as other weird network issues, all centering around the time we started blocking 92 Byte ICMP packets. Has anyone else seen this, and if so, is the only resolution to stop the blockage of 92 Byte ICMP Packets..? Thanks Richard
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Richard J.Sears <[EMAIL PROTECTED]> said: > Since then, we have been hammered with customer complaints concerning > the inability to talk to mail servers and ssh to their servers, as well > as other weird network issues, all centering around the time we started > blocking 92 Byte ICMP packets. > > Has anyone else seen this, and if so, is the only resolution to stop the > blockage of 92 Byte ICMP Packets..? Yes. As soon as we put the policy route map in place, we had some people unable to talk via SSH, SMTP, or POP3. It was random: one person here in the office couldn't SSH to a particular server. He could SSH to other servers, and the rest of us could SSH to the server he could not. We had similar experiences with SMTP and POP3. When we took the policy route map back out, the problems went away. This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy route map on the FE interface linking this router to the POP core router; this router has MC-T3 interfaces and ethernets to Ascend TNTs and such. The intent was to stop the 92 byte ICMP echos from reaching the Ascend TNTs, since several of them were rebooting constantly. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
In message <[EMAIL PROTECTED]>, Chris Adams writes: > >Once upon a time, Richard J.Sears <[EMAIL PROTECTED]> said: >> Since then, we have been hammered with customer complaints concerning >> the inability to talk to mail servers and ssh to their servers, as well >> as other weird network issues, all centering around the time we started >> blocking 92 Byte ICMP packets. >> >> Has anyone else seen this, and if so, is the only resolution to stop the >> blockage of 92 Byte ICMP Packets..? > >Yes. As soon as we put the policy route map in place, we had some >people unable to talk via SSH, SMTP, or POP3. It was random: one person >here in the office couldn't SSH to a particular server. He could SSH to >other servers, and the rest of us could SSH to the server he could not. >We had similar experiences with SMTP and POP3. When we took the policy >route map back out, the problems went away. > >This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy >route map on the FE interface linking this router to the POP core >router; this router has MC-T3 interfaces and ethernets to Ascend TNTs >and such. The intent was to stop the 92 byte ICMP echos from reaching >the Ascend TNTs, since several of them were rebooting constantly. I wonder if it's a Path MTU problem. Can you turn off Path MTU on some of the affected hosts and see if it solves the problem? --Steve Bellovin, http://www.research.att.com/~smb
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Steven M. Bellovin <[EMAIL PROTECTED]> said: > In message <[EMAIL PROTECTED]>, Chris Adams writes: > >Yes. As soon as we put the policy route map in place, we had some > >people unable to talk via SSH, SMTP, or POP3. It was random: one person > >here in the office couldn't SSH to a particular server. He could SSH to > >other servers, and the rest of us could SSH to the server he could not. > >We had similar experiences with SMTP and POP3. When we took the policy > >route map back out, the problems went away. > > > >This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy > >route map on the FE interface linking this router to the POP core > >router; this router has MC-T3 interfaces and ethernets to Ascend TNTs > >and such. The intent was to stop the 92 byte ICMP echos from reaching > >the Ascend TNTs, since several of them were rebooting constantly. > > I wonder if it's a Path MTU problem. Can you turn off Path MTU on some > of the affected hosts and see if it solves the problem? I don't have it in place anymore (because it caused more problems than it fixed), so I can't test this. In any case, the route map only matched 92 byte ICMP echo and ICMP echo-reply packets, which is not what PMTU uses, so it shouldn't have had a problem. Also, I know that the MTU along the path for the person in the office is the same all the way, so PMTU shouldn't come into play there. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
I had the exact same problem. As soon as I turned it on, within minutes I had customers calling that could no longer FTP into Win2k servers and some that couldn't SSH into their Linux servers. I've since turned it off as well. Are there any other known ways to block this? william - Original Message - From: "Chris Adams" <[EMAIL PROTECTED]> To: "Steven M. Bellovin" <[EMAIL PROTECTED]> Cc: "Nanog" <[EMAIL PROTECTED]> Sent: Friday, September 12, 2003 1:32 PM Subject: Re: 92 Byte ICMP Blocking Problem > > Once upon a time, Steven M. Bellovin <[EMAIL PROTECTED]> said: > > In message <[EMAIL PROTECTED]>, Chris Adams writes: > > >Yes. As soon as we put the policy route map in place, we had some > > >people unable to talk via SSH, SMTP, or POP3. It was random: one person > > >here in the office couldn't SSH to a particular server. He could SSH to > > >other servers, and the rest of us could SSH to the server he could not. > > >We had similar experiences with SMTP and POP3. When we took the policy > > >route map back out, the problems went away. > > > > > >This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy > > >route map on the FE interface linking this router to the POP core > > >router; this router has MC-T3 interfaces and ethernets to Ascend TNTs > > >and such. The intent was to stop the 92 byte ICMP echos from reaching > > >the Ascend TNTs, since several of them were rebooting constantly. > > > > I wonder if it's a Path MTU problem. Can you turn off Path MTU on some > > of the affected hosts and see if it solves the problem? > > I don't have it in place anymore (because it caused more problems than > it fixed), so I can't test this. In any case, the route map only > matched 92 byte ICMP echo and ICMP echo-reply packets, which is not what > PMTU uses, so it shouldn't have had a problem. Also, I know that the > MTU along the path for the person in the office is the same all the way, > so PMTU shouldn't come into play there. > -- > Chris Adams <[EMAIL PROTECTED]> > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. >
Re: 92 Byte ICMP Blocking Problem
Hi Chris, We were having the same exact problem with 4 TNTs that we have. In the end, we shut off ip-route-cache on the TNTs and that fixed the problem with them. Richard On Fri, 12 Sep 2003 12:52:58 -0500 Chris Adams <[EMAIL PROTECTED]> wrote: > > Once upon a time, Richard J.Sears <[EMAIL PROTECTED]> said: > > Since then, we have been hammered with customer complaints concerning > > the inability to talk to mail servers and ssh to their servers, as well > > as other weird network issues, all centering around the time we started > > blocking 92 Byte ICMP packets. > > > > Has anyone else seen this, and if so, is the only resolution to stop the > > blockage of 92 Byte ICMP Packets..? > > Yes. As soon as we put the policy route map in place, we had some > people unable to talk via SSH, SMTP, or POP3. It was random: one person > here in the office couldn't SSH to a particular server. He could SSH to > other servers, and the rest of us could SSH to the server he could not. > We had similar experiences with SMTP and POP3. When we took the policy > route map back out, the problems went away. > > This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy > route map on the FE interface linking this router to the POP core > router; this router has MC-T3 interfaces and ethernets to Ascend TNTs > and such. The intent was to stop the 92 byte ICMP echos from reaching > the Ascend TNTs, since several of them were rebooting constantly. > > -- > Chris Adams <[EMAIL PROTECTED]> > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble.
Re: New prefix
I'm picking up 82.0.0.0/11 both our upstreams, AT&T and UUNet/MCI. > > Collegues, > > We've just been allocated a new RIPE block in the 82/8 range. > This block has only been removed from the bogon list since > november last year. > [snip]
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Richard J.Sears <[EMAIL PROTECTED]> said: > We were having the same exact problem with 4 TNTs that we have. In the > end, we shut off ip-route-cache on the TNTs and that fixed the problem > with them. We were only seeing it on some of our TNTs for some reason. I didn't turn the route cache completely off, but I did limit the size, and that solved it for us. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
There were some posts to this list last week about 75xx's dropping packets outside what was specified in the ip policy route map. -- James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday Phone support 365 days till 10 pm via the Santa Fe office: 505-988-9200 or Toll Free: 888-988-2700
Re: 92 Byte ICMP Blocking Problem
So, the choice is to go from dCEF to CEF or to not block the 92 byte packets at allanyone have an idea as to which is the better route to take..? - Richard On Fri, 12 Sep 2003 10:59:54 -0700 "Matt Ploessel" <[EMAIL PROTECTED]> wrote: > > >See http://www.cisco.com/warp/public/707/cisco-sn-20030820-nachi.shtml > >> > >>The policy-routing solutions works great in small routers (26xx, 17xx) > > >>and in 7200s. In 7500s it seems OK *UNLESS* dCEF is enabled, then it > >>does what you saw. I'm assuming it's dropping 92-byte TCP packets as > >>well as the ICMP echoes. You can see 1-packet flows of mail getting > >>dropped. > >> > >>Notice that the workaround cannot be used on GSRs because it causes > >>packets to be punted to the CPU... this is as bad a news as that it > >>doesn't work right on dCEF because we use GSRs or 7500s with dCEF > >>where the network is really busy. > > - Matt Ploessel > > > -Original Message- > > From: Richard J.Sears [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 12, 2003 10:43 AM > > To: Nanog > > Subject: 92 Byte ICMP Blocking Problem > > > > > > > > We started blocking 92 Byte ICMP packets on our ingress points on our > > core backbone routers. > > > > This was a recommendation from Cisco to help mitigate the > > effects of the > > Nachi worm. > > > > Since then, we have been hammered with customer complaints concerning > > the inability to talk to mail servers and ssh to their > > servers, as well > > as other weird network issues, all centering around the time > > we started > > blocking 92 Byte ICMP packets. > > > > Has anyone else seen this, and if so, is the only resolution > > to stop the > > blockage of 92 Byte ICMP Packets..? > > > > Thanks > > > > Richard > > > > > > > > ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."
Re: 92 Byte ICMP Blocking Problem
I believe it to be true that all policy route traffic is processor switched rather than CEF on the 75xx platform. If so, the 75xx might not be handling all it's being asked to and dropping stuff in a non-deterministic way. * james said: > > There were some posts to this list last week about 75xx's dropping > packets outside what was specified in the ip policy route map. > > -- > James Edwards > Routing and Security > [EMAIL PROTECTED] > At the Santa Fe Office: Internet at Cyber Mesa > Store hours: 9-6 Monday through Friday > Phone support 365 days till 10 pm via the Santa Fe office: > 505-988-9200 or Toll Free: 888-988-2700 >
Cyber World Internet Services
I need a contact inside Cyber World Internet Services to report a security issue. The WHOIS reported phone number is an answering machine... NetRange: 66.206.0.0 - 66.206.31.255 TechHandle: AS1239-ARIN TechName: Slocombe, Alvin TechPhone: +1-509-343-2100 TechEmail: [EMAIL PROTECTED] TIA
Re: What were we saying about edge filtering?
> Don't confuse the source and destination. This traffic is packets with an > unused DESTINATION address. Ok, you got me there. I do wonder, however, how much is responses to traffic that began life as an unused source. There is still the point that the catch-all route is causing more hauling of traffic than is necessary, and would prevent uRPF from being able to do its job (presumably so that back-scatter based backtracking could work, which would be unnecessary, if RPF were implemented.) > loose uRPF has *NO* effect on the destination address. True enough, it has no direct effect. It might have indirect effect, however. > Which is greater in a typical backbone? Traffic with a bogon source, or > traffic with a bogon destination entering the backbone? This is probably a function of how many customers are default routed and how much the backbone filters. If we make the assumptions that the larger backbones have primarily BGP-speaking customers, and do relatively little filtering, then I'ld say it would be primarily bogus sources. As either the filtering or customers pointing default goes up, I'ld expect the weighting to even out or swing towards more bogus destinations. Thankfully, bogus destinations die when they reach the default-free zone. The same is not true of bogus sources.
Cisco IOS 12.3(2)T1 and warm-reload
Is it just me or is the warm-reload feature not includet in 12.3(2)T1? As seen on Cisco CCO 12.3T Release Notes: Warm-Reload 12.3(2)T This feature was introduced. ^--- !!! 12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S. Some Output: ip6.of#sh ver Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-JK9O3S-M), Version 12.3(2)T1, RELEASE SOFTWARE (fc2) ^--- ! ip6.of#conf t Enter configuration commands, one per line. End with CNTL/Z. ip6.of(config)#w? % Unrecognized command Cisco CCO Release Notes: SUMMARY STEPS 1. enable 2. configure terminal 3. warm-reboot [count number] [uptime minutes] ^ !!! 4. exit 5. show warm-reboot Kind Regards, Timo -- Timo Mohre / Network Engineer / Tiscali Germany Business Division / Robert-Bosch-Strasse 32 / D-63303 Dreieich Fon: +49(0)6103-916 930 / Fax: +49(0)6103-916 099 www.tiscali.de / www.tiscali-business.de / [EMAIL PROTECTED]
Re: More on the DDoS Attack
Hello, Ok - I know I said I'd have something for the list on Monday. Unforunately, work kept getting in the way :( Yesterday, I sent our this URL to the people who replied to me privately. It is a general overview (with a few details) of how various schools have been dealing with the recent RPC vulnerabilities and the associated Blaster/Welchia worms. http://www.roxanne.org/~eric/blaster.html Take a look and let me know what you think. Any question or comments - editorial or otherwise - would be greatly appreciated. Eric :)
