Re: RADB down?
At 01:52 PM 3/5/2008, John van Oppen wrote: Anyone else seeing the radb whois server as being down? Simple whois seems to work ok for me from one IP address, but not from another on the same subnet... % ping -S 199.212.134.1 whois.ra.net PING whois.radb.net (198.108.0.18) from 199.212.134.1: 56 data bytes ^C --- whois.radb.net ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ping -S 199.212.134.2 whois.ra.net PING whois.radb.net (198.108.0.18) from 199.212.134.2: 56 data bytes 64 bytes from 198.108.0.18: icmp_seq=0 ttl=56 time=25.556 ms 64 bytes from 198.108.0.18: icmp_seq=1 ttl=56 time=25.886 ms ^C --- whois.radb.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 25.556/25.721/25.886/0.165 ms # whois -h whois.ra.net AS11404 aut-num:AS11404 as-name:VOBIZ descr: vanoppen.biz LLC / Spectrum Networks LLC member-of: AS-VOBIZ import: from AS2914 accept ANY import: from AS3491 accept ANY import: from AS3356 accept ANY export: to AS2914 announce AS-VOBIZ export: to AS3491 announce AS-VOBIZ export: to AS3356 announce AS-VOBIZ admin-c:John van Oppen tech-c: John van Oppen mnt-by: MAINT-AS11404 changed:[EMAIL PROTECTED] 20070401 #16:20:39(UTC) changed:[EMAIL PROTECTED] 20070903 #17:42:34(UTC) changed:[EMAIL PROTECTED] 20080125 #07:55:53(UTC) source: RADB # traceroute -s 199.212.134.2 -q1 198.108.0.18 traceroute to 198.108.0.18 (198.108.0.18), 64 hops max, 44 byte packets 1 iolite4-fxp2 (199.212.134.10) 0.126 ms 2 cogent-vl108 (67.43.129.246) 2.950 ms 3 gi8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 2.975 ms 4 vl3492.mpd01.yyz01.atlas.cogentco.com (154.54.5.81) 3.355 ms 5 te8-2.mpd01.ord01.atlas.cogentco.com (154.54.7.73) 18.345 ms 6 vl3489.mpd01.ord03.atlas.cogentco.com (154.54.5.18) 17.938 ms 7 Merit.demarc.cogentco.com (66.28.21.234) 18.053 ms 8 ge-0-2-0x43.aa1.mich.net (198.108.22.241) 27.641 ms 9 rpsl-p.merit.edu (198.108.0.18) 31.018 ms % traceroute -n -q1 198.108.0.18 traceroute to 198.108.0.18 (198.108.0.18), 64 hops max, 40 byte packets 1 199.212.134.10 0.180 ms 2 67.43.129.246 3.220 ms 3 38.104.158.77 3.977 ms 4 154.54.5.85 7.361 ms 5 154.54.2.161 18.714 ms 6 154.54.25.66 18.852 ms 7 38.112.7.10 20.107 ms 8 198.108.22.241 30.215 ms 9 * 10 * Bad Load balancer or busted MPLS silliness or firewall issue ? ---Mike
Re: Does anyone multihome anymore? (was: Re: Cogent latency / congestion)
At 03:49 AM 8/22/2007, Security Admin (NetSec) wrote: Pardon my forwardness, but don't people just multi-home these days? If your Multihoming is great for when there is a total outage. In the case of Cogent on Monday, it wasnt down... In this case, there is only so much you can do to influence how packets come back at you as BGP doesnt know anything about a lossy or slow connections. ---Mike
Re: Does anyone multihome anymore?
At 10:11 AM 8/22/2007, Paul Kelly :: Blacknight Solutions wrote: Mike Tancsa wrote: At 03:49 AM 8/22/2007, Security Admin (NetSec) wrote: Pardon my forwardness, but don't people just multi-home these days? If your Multihoming is great for when there is a total outage. In the case of Cogent on Monday, it wasnt down... In this case, there is only so much you can do to influence how packets come back at you as BGP doesnt know anything about a lossy or slow connections. ---Mike Take the carrier that is causing you issues out of your eBGP setup and all's well Hi, In my case, I have 6453 and 174 for transit. I want to get to 577 which is directly connected to 6453 and 174. 577 has a higher local pref on paths via 174. Short of shutting my 174 session (or some deaggregation), I dont have a way to influence how 577 gets back to me. I can easily exit out 6453, but it does nothing for the return packets. I have enough capacity on 6453 to handle all my traffic, but its a Draconian step to take and some traffic via 174 is fine and would be worse if I fully shut the session. (ie. peers of 174 in Toronto) ---Mike
RE: Does anyone multihome anymore?
At 10:31 AM 8/22/2007, David Hubbard wrote: That's because Cogent has chosen to not give us the BGP communities Actually, in my case I dont think it would help because 577 has some sort of paid agreement with teleglobe and probably a very cheap (or even zero $$$) agreement with Cogent. So I dont think they would let me influence their exit path to make them pay Teleglobe more money :) But yes, community tickery can be quite helpful, but it wont always do the trick. ---Mike
Re: Does anyone multihome anymore?
At 02:12 PM 8/22/2007, Deepak Jain wrote: Actually, in my case I dont think it would help because 577 has some sort of paid agreement with teleglobe and probably a very cheap (or even zero $$$) agreement with Cogent. So I dont think they would let me influence their exit path to make them pay Teleglobe more money :) Since AS577 keeps coming up in this discussion. They certainly could have adjusted their routing during this event if they felt their customers/business were being negatively impacted. If it didn't meet that threshold, who are we to judge what is good for their customers/business?? Hi, I am not judging them at all. Its all from my perspective--- me me me me!!! :) I am just trying to do the best for my customers and make a decent ROI for the business with the resources I have-- just like they are. From Bell's perspective, getting to relatively small networks like mine dont even register on their radar. I am just trying to do the best I can within the constraints of how routing works, and the tools I have available to me. ---Mike
Re: Does anyone multihome anymore?
At 03:26 PM 8/22/2007, Steve Gibbard wrote: Thought about that way, there's nothing Draconian about turning off a connection (or a switch, or a router, or any other redundant component) that's not doing what you want it to. While I agree in general with what you are getting at, one point to add is cost. All these goals are constrained within a business case to make. In my case, I could turn off my Cogent connection, but I would have ended up punishing connectivity to other networks that are off Cogent in Toronto only. This would have forced them to get to me via Cogent's pop in Chicago, which was overloaded. So to fix my connectivity into AS577, I would have to hose another group of users in Toronto. Now I could of course add more diversity by adding another connection in Toronto. But, I have to justify the business case to do that. Is it worth the extra money for the few times this particular type of outage happens ? In my case probably not. The cost to privately peer with 577 is quite high and there are no good transit providers at 151 Front that have good connectivity to Bell other than via Chicago. Instead, you're taking advantage of a main feature of your design. If your other providers are doing 95th percentile billing, you even have a day and a half per month that you can leave a connection down at no financial cost. The alternative, as you seem to have noticed, is to spend your day stressing out about your network not working properly, and complaining about being helpless. You don't need redundancy for that. I didnt mean to sound complaintive. My original post to NANOG was more of trying to get details as to what was going on beyond the rather basic info 1st level support and the cogent status page was saying. After the original post, various questions / comments came up as to what could and could not be done in this situation. ---Mike
Cogent latency / congestion
Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Cogent latency / congestion
At 03:54 PM 8/20/2007, Dan Armstrong wrote: We're going crazy up here, I'm trying to nail down where exactly the problem is - We don't use Cogent anywhere, but we're having terrible problems with Bell and many sites in Europe... Bell uses Cogent in a large way. The second traceroute was from an IP in their AS (577) out. I am prepending out Cogent, but Bell does everything it can not to use Teleglobe so I am having problems influencing their routes to come back that way. They also have a very odd path out of Chicago. This is from a site in Toronto (source IP in AS577) back to me peering with Cogent's router in Toronto... Toronto, Chicago, Kansas, Texas, Washington, Boston, Albany, Toronto. Thats quite the milk run. Usually its Toronto, Chicago, Toronto. % traceroute -f 6 -q1 199.212.134.3 traceroute to 199.212.134.3 (199.212.134.3), 64 hops max, 40 byte packets 6 64.230.229.5 (64.230.229.5) 4.846 ms 7 64.230.242.97 (64.230.242.97) 4.030 ms 8 64.230.147.14 (64.230.147.14) 14.213 ms 9 206.108.103.142 (206.108.103.142) 14.216 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 101.348 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 102.507 ms 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 108.993 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 108.496 ms 14 t2-2.mpd01.dca01.atlas.cogentco.com (154.54.2.145) 110.221 ms 15 t8-2.mpd01.bos01.atlas.cogentco.com (154.54.1.105) 129.529 ms 16 g2-0-0.core01.bos01.atlas.cogentco.com (154.54.2.213) 108.507 ms 17 p13-0.core01.alb02.atlas.cogentco.com (154.54.7.41) 116.526 ms 18 p14-0.core01.yyz01.atlas.cogentco.com (66.28.4.218) 118.463 ms 19 v3491.mpd01.yyz01.atlas.cogentco.com (154.54.5.78) 217.912 ms 20 v3492.mpd01.yyz02.atlas.cogentco.com (154.54.5.82) 225.491 ms 21 sentex.demarc.cogentco.com (38.104.158.78) 217.134 ms 22 i3-vl-814 (67.43.129.242) 65.576 ms 23 shell1 (199.212.134.3) 66.221 ms ---Mike Mike Tancsa wrote: Does anyone have any details about the Cogent outage that started this morning (9am GMT-400) and is still continuing ? If its a fibre cut between Montville (NJ?) and Cleveland OH (http://status.cogentco.com/) why is it so bad in Chicago and Albany locations ? Is there really that little excess capacity ? My connection out of Toronto is pretty bad via Albany 3 g8-22.mpd01.yyz02.atlas.cogentco.com (38.104.158.77) 7.470 ms 6.754 ms 6.481 ms 4 v3493.mpd01.yyz01.atlas.cogentco.com (154.54.5.85) 6.981 ms 6.730 ms 6.984 ms 5 g2-0-0-3490.core01.yyz01.atlas.cogentco.com (154.54.5.73) 6.482 ms 7.175 ms 5.974 ms 6 p4-0.core01.alb02.atlas.cogentco.com (66.28.4.217) 105.954 ms 112.055 ms 111.426 ms 7 p6-0.core01.bos01.atlas.cogentco.com (154.54.7.42) 115.413 ms 117.090 ms 113.816 ms and Bell's through Chicago is even worse 6 64.230.229.5 (64.230.229.5) 12.572 ms 36.983 ms 200.187 ms 7 64.230.242.97 (64.230.242.97) 4.685 ms 5.439 ms 3.645 ms 8 64.230.147.14 (64.230.147.14) 14.351 ms 15.344 ms 14.387 ms 9 206.108.103.142 (206.108.103.142) 14.374 ms 14.280 ms 14.255 ms 10 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 156.616 ms * 142.150 ms 11 te3-1.mpd01.ord01.atlas.cogentco.com (154.54.1.206) 135.199 ms 138.900 ms * 12 t2-4.mpd01.mci01.atlas.cogentco.com (154.54.2.233) 152.292 ms 149.956 ms 148.095 ms 13 t4-2.mpd01.iah01.atlas.cogentco.com (154.54.5.221) 149.047 ms 150.556 ms 151.232 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Cogent latency / congestion
At 05:43 PM 8/20/2007, Steve Gibbard wrote: On Mon, 20 Aug 2007, Mike Tancsa wrote: Bell uses Cogent in a large way. The second traceroute was from an IP in their AS (577) out. I am prepending out Cogent, but Bell does everything it can not to use Teleglobe so I am having problems influencing their routes to come back that way. They also have a very odd path out of Chicago. This is Bear in mind that doing everything they can not to use Teleglobe probably involves local preference. Local preference comes before AS path length in the BGP selection order, so nothing you can do with prepending is going to help. Yes, I realize that. I think its because they (Bell) pay Teleglobe for transit, so they dont want to use it where possible. Back when I signed up with Teleglobe, I was hoping there were some community tricks I could use to influence bell's local pref, but because they buy transit from Teleglobe, this was not implemented. I think the only thing I could do would be to withdraw the prefixes from Cogent or resort to deaggregation so that they would follow a more specific prefix. ---Mike You'll need to either keep them from seeing the undesirable path at all (drop the announcement, ask your upstreams to limit its propagation, etc.) or convince Bell not to use it. Depending on the setup, you may be able to limit route propagation with communities, or it may require some phone calls. -Steve
Re: IP Block 99/8 (DHS insanity - offtopic)
At 04:52 PM 4/23/2007, Patrick W. Gilmore wrote: I do not want any particular gov't (US or otherwise) to be in charge of the Internet any more than the next person. And good thing too, because it simply cannot happen, political pipe-dreams not withstanding. But what has that got to do with the DHS promoting an idea to sign IP space allocations and/or annoucements? The idea in-and-of-itself doesn't sound wholly unreasonable. (I am not advocating this, just saying the idea shouldn't be rejected without consideration simply because the DHS said it.) The question is who would do the signing and revocations. Whoever does that would indeed have a great amount of control over the internet. A single government agency should not have that sort of power to make a (for lack of better term), no surf list of IP space... ---Mike
Re: 96.2.x.x Issues to websites
At 11:43 AM 3/2/2007, John Lubeck wrote: Sorry for the long list but we are still having issues to following sites. Looking for someone at American Express and Yahoo (*most complaints with those two sites). Also it appears a we are getting stopped on ATT networks. ATT has some nice route servers to use / test from 12.0.1.28 Trying 12.0.1.28... Connected to route-server.cbbtier3.att.net. Escape character is '^]'. ## route-server.ip.att.net ### # ATT IP Services Route Monitor ### The information available through route-server.ip.att.net is offered by ATT's Internet engineering organization to the Internet community. This router has the global routing table view from each of the above routers, providing a glimpse to the Internet routing table from the ATT network's perspective. This router maintains eBGP peerings with customer-facing routers throughout the ATT IP Services Backbone: 12.123.21.243 Atlanta, GA 12.123.133.124 Austin, TX 12.123.41.250 Cambridge, MA 12.123.5.240Chicago,IL 12.123.17.244 Dallas, TX 12.123.139.124 Detroit, MI 12.123.37.250 Denver, CO 12.123.134.124 Houston, TX 12.123.29.249 Los Angeles, CA 12.123.1.236New York, NY 12.123.33.249 Orlando,FL 12.123.137.124 Philadelphia, PA 12.123.142.124 Phoenix, AZ 12.123.145.124 San Diego, CA 12.123.13.241 San Francisco, CA 12.123.25.245 St. Louis, MO 12.123.45.252 Seattle, WA 12.123.9.241Washington, DC
AS577 (Bell Canada)
Anyone around from AS577 ? Can you contact me offlist please ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: http://cisco.com 403 Forbidden
At 11:24 AM 1/3/2007, James Baldwin wrote: Anyone else getting a 403 Forbidden when trying to access http:// cisco.com? Yes. Resolves to 198.133.219.25 for me. ---Mike
RE: http://cisco.com 403 Forbidden
At 11:53 AM 1/3/2007, Scott Morris wrote: Works fine for me. Works for me now too. ---Mike And a 403 Forbidden is a web server error, not a resolution error if I remember right. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Wednesday, January 03, 2007 11:35 AM To: James Baldwin; [EMAIL PROTECTED] Subject: Re: http://cisco.com 403 Forbidden At 11:24 AM 1/3/2007, James Baldwin wrote: Anyone else getting a 403 Forbidden when trying to access http:// cisco.com? Yes. Resolves to 198.133.219.25 for me. ---Mike
Re: http://cisco.com 403 Forbidden
At 12:07 PM 1/3/2007, D'Arcy J.M. Cain wrote: On Wed, 3 Jan 2007 16:39:40 + Simon Waters [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 16:29, you wrote: On Wed, 3 Jan 2007, James Baldwin wrote: Anyone else getting a 403 Forbidden when trying to access http://cisco.com? [...] Working fine here. Resolves to 198.133.219.25 What does DNS resolution have to do with 403 web errors? Because it might resolve to several different IP addresses or is in the process of changing to a different IP and only one host might have been impacted by whatever was going on at the time. e.g. if someone says www.microsoft.com is not working, it might help to know what IP they were talking to at the time... [smtp1]# host www.microsoft.com www.microsoft.com is an alias for toggle.www.ms.akadns.net. toggle.www.ms.akadns.net is an alias for g.www.ms.akadns.net. g.www.ms.akadns.net is an alias for lb1.www.ms.akadns.net. lb1.www.ms.akadns.net has address 207.46.199.30 lb1.www.ms.akadns.net has address 207.46.225.60 lb1.www.ms.akadns.net has address 207.46.18.30 lb1.www.ms.akadns.net has address 207.46.19.30 lb1.www.ms.akadns.net has address 207.46.19.60 lb1.www.ms.akadns.net has address 207.46.20.30 lb1.www.ms.akadns.net has address 207.46.20.60 lb1.www.ms.akadns.net has address 207.46.198.60 [smtp1]# ---Mike
Re: AS 701 problems in Chicago ?
At 03:39 AM 10/17/2006, Simon Waters wrote: On Tuesday 17 Oct 2006 03:32, Mike Tancsa wrote: Anyone know whats up ? I have seen some strange routing depending on the payload's protocol to a site in one of their colos in Toronto. Don't know if it is related, but we can't route email to bellsouth.net -- no Hi, Thanks for replying, it doesnt seem to be related based on the traceroute you provided. I am still seeing the issue this morning, but its not so wide spread across protocols. I worked around the issue by dumping out my traffic to them via Teleglobe instead of MTSAllstream. Teleglobe seems to talk to them on a different router in Chicago which doesnt seem to be showing the behaviour as much as the other router or at least its not on the source IP addresses I am using. However, its stil blocking IPSEC packets I got an email from the datacenter early this AM saying the problem was fixed according to UUnet, but it still there when I just tried now. Is this the result of some protocol prioritizing config gone bad ? Or busted software ? e.g as of this morning, icmp,tcp, and udp packets make it to the other side but not IPSEC traceroute -s 67.43.129.246 -Pudp 209.167.35 traceroute to 209.167.35.xx (209.167.35.xx) from 67.43.129.246, 64 hops max, 40 byte packets 1 216.191.68.65 (216.191.68.65) 0.877 ms 0.708 ms 0.786 ms 2 65.195.241.149 (65.195.241.149) 12.225 ms 12.262 ms 12.239 ms 3 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 12.524 ms 12.424 ms 12.443 ms 4 0.so-0-0-0.TL1.CHI2.ALTER.NET (152.63.68.82) 12.870 ms 12.832 ms 12.940 ms 5 0.so-3-0-0.TL1.TOR2.ALTER.NET (152.63.2.85) 28.846 ms 28.633 ms 28.739 ms 6 0.so-1-0-0.XL1.TOR2.ALTER.NET (152.63.3.82) 28.886 ms 74.966 ms 28.789 ms 7 POS6-1.GW4.TOR2.ALTER.NET (152.63.131.129) 28.888 ms 28.691 ms 28.605 ms 8 enoo3-gw.customer.alter.net (205.150.100.214) 34.739 ms 34.998 ms 34.395 ms traceroute -s 67.43.129.246 -Pesp 209.167.35.xx traceroute to 209.167.35.xx (209.167.35.xx) from 67.43.129.246, 64 hops max, 36 byte packets 1 216.191.68.65 (216.191.68.65) 0.918 ms 0.724 ms 0.712 ms 2 65.195.241.149 (65.195.241.149) 12.244 ms 12.311 ms 12.297 ms 3 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 12.361 ms 12.456 ms 12.404 ms 4 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 12.792 ms 12.784 ms 12.751 ms 5 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 13.356 ms 13.405 ms 13.489 ms 6 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 13.208 ms 13.113 ms 13.131 ms 7 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 13.820 ms 13.833 ms 13.903 ms 8 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 13.666 ms 13.567 ms 13.733 ms 9 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 14.308 ms 14.316 ms 14.345 ms 10 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 14.018 ms 14.113 ms 14.073 ms 11 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 14.807 ms 14.824 ms 14.943 ms 12 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 14.558 ms 14.611 ms 14.595 ms 13 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 15.327 ms 15.335 ms 15.174 ms 14 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.031 ms 14.948 ms 15.148 ms 15 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 15.680 ms 15.678 ms 15.688 ms 16 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.510 ms 15.498 ms 15.534 ms 17 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 16.189 ms 16.239 ms 16.167 ms 18 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.964 ms 15.855 ms 15.924 ms 19 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 16.688 ms 16.629 ms 16.753 ms 20 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 16.385 ms 16.464 ms 16.473 ms 21 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 17.099 ms 17.034 ms 17.134 ms 22 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 77.096 ms 16.821 ms 16.875 ms 23 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 17.488 ms 17.474 ms 17.474 ms 24 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 17.310 ms 17.348 ms 17.323 ms 25 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 18.018 ms 18.137 ms 17.953 ms 26 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 17.838 ms 17.740 ms 17.820 ms 27 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 18.595 ms 18.466 ms 18.484 ms 28 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 18.220 ms 18.256 ms 18.349 ms 29 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 48.198 ms 18.987 ms 18.877 ms 30 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 18.669 ms 18.709 ms 18.769 ms 31 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 19.361 ms 19.565 ms 19.442 ms 32 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 19.121 ms 19.158 ms 19.114 ms 33 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 19.780 ms 20.010 ms 19.907 ms 34 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 19.610 ms 19.614 ms 19.587 ms 35 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 20.329 ms 20.239 ms 20.269 ms 36 0.so-0-0-0
AS 701 problems in Chicago ?
Anyone know whats up ? I have seen some strange routing depending on the payload's protocol to a site in one of their colos in Toronto. e.g. all tcp packets are making to the host marble# traceroute -s 199.212.134.2 -Ptcp ITMsite.sentex.ca traceroute to ITMsite.sentex.ca (209.167.35.xx), 64 hops max, 56 byte packets 1 iolite4-fxp2 (199.212.134.10) 0.124 ms 0.101 ms 0.097 ms 2 allstream-vl108 (67.43.129.246) 5.663 ms 5.443 ms 5.580 ms 3 216.191.68.65 (216.191.68.65) 6.997 ms 6.050 ms 6.667 ms 4 65.195.241.149 (65.195.241.149) 17.438 ms 17.448 ms 18.513 ms 5 0.so-1-0-0.XL2.CHI1.ALTER.NET (152.63.70.70) 18.040 ms 17.950 ms 18.198 ms 6 0.so-0-0-0.TL2.CHI2.ALTER.NET (152.63.68.89) 18.476 ms 18.442 ms 20.224 ms 7 0.so-6-0-0.TL2.TOR2.ALTER.NET (152.63.0.201) 38.112 ms 34.369 ms 34.827 ms 8 0.so-1-0-0.XL2.TOR2.ALTER.NET (152.63.3.90) 37.353 ms 37.305 ms 36.856 ms 9 POS7-0.GW4.TOR2.ALTER.NET (152.63.131.141) 40.099 ms 36.807 ms 35.595 ms 10 enoo3-gw.customer.alter.net (205.150.100.214) 43.112 ms 41.565 ms 41.931 ms ^C But other protocols (UDP, ICMP and most importantly for us, ESP) are hosed. marble# traceroute -s 199.212.134.2 -Pesp ITMsite.sentex.ca traceroute to ITMsite.sentex.ca (209.167.35.xx), 64 hops max, 40 byte packets 1 iolite4-fxp2 (199.212.134.10) 0.120 ms 0.097 ms 0.093 ms 2 allstream-vl108 (67.43.129.246) 5.460 ms 5.303 ms 5.524 ms 3 216.191.68.65 (216.191.68.65) 6.563 ms 6.289 ms 6.211 ms 4 65.195.241.149 (65.195.241.149) 18.219 ms 17.612 ms 17.991 ms 5 0.so-1-0-0.XL2.CHI1.ALTER.NET (152.63.70.70) 17.587 ms 17.629 ms 18.492 ms 6 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 26.075 ms 18.130 ms 18.879 ms 7 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 17.981 ms 18.160 ms 18.516 ms 8 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 19.138 ms 18.356 ms 18.593 ms 9 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 18.677 ms 18.477 ms 17.973 ms 10 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 19.088 ms 18.936 ms 18.692 ms 11 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 18.841 ms 18.308 ms 18.996 ms 12 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 18.362 ms 18.645 ms 18.584 ms 13 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 18.329 ms 18.125 ms 18.890 ms 14 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 18.583 ms 18.635 ms 18.933 ms 15 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 46.420 ms 19.088 ms 18.217 ms 16 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 62.137 ms 18.515 ms 18.349 ms 17 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 18.243 ms 18.558 ms 18.404 ms 18 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 18.506 ms 18.568 ms 19.341 ms 19 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 18.724 ms 19.178 ms 18.367 ms 20 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 18.644 ms 18.321 ms 18.545 ms 21 0.so-0-0-0.XL2.CHI4.ALTER.NET (152.63.13.33) 19.225 ms 18.410 ms 18.596 ms 22 0.so-0-0-0.TL2.CHI4.ALTER.NET (152.63.13.34) 18.758 ms 20.040 ms 18.488 ms ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: BCP Question: Handling trouble reports from non-customers
At 12:26 PM 9/1/2006, Owen DeLong wrote: I think my previous post may have touched on a more global issue. Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non-customer needing to report a problem with the ability to reach one of their customers. I think its more of an issue of being able to get through to the right people as opposed to customers or non customers reporting problems. We had an issue with one large ILEC here in Canada recently (but similar problems in the past with others) where they did some upgrades to their radius servers that busted non PAP logins. Some of our older VPN devices used scripted logins so these all broke. We only were regular customers, so we tried our best to work through the front line tech support. Basically we got stuff like we dont support UNIX. You need to call UNIX for help we dont have terminal servers, there is nothing wrong with R-A-Y-D-E-E-U-S or even the circumference, and other crap that was an obvious 'jettison customer' leaf in the decision tree. It was an incredibly frustrating situation for 3 days despite asking to escalate etc. Ultimately, we discovered the issue had security issues, so we used that as a pretext to use a net-sec contact to pass on the info and it was acted on almost right away. In general, the dilemma seems to be this-- customer calls up saying stuff that makes no sense to the front line tech. Does front line tech pass each and every, the customer is saying our ION-Dilithium deflector array is misalligned and needs to be refilled with dark neutrino particles and You have a bogus next hop route in your IGP... Pass it up the food chain ? Or just dismiss it. The answer seems to be, if there is a bogus next hop issue, our second line will catch it on their own so dont bother second line if you cant figure it out. Whether its a good business decision or not, dont know but that seems to be the popular thing to do in my experience. ---Mike
Re: Fanless x86 Server Recommendations
At 01:29 PM 30/06/2006, Florian Weimer wrote: * Mike Tancsa: Many mini-itx boxes dont have 2 PCI slots. You might be better going with a mini-itx solution and then use a small switch and trunk the NIC to act as a VLAN router. Are there any fanless routers with proper 802.1Q support (with ingress VLAN tag filtering, for instance)? Not sure exactly what you mean by vlan tag filtering and if you mean OSes based on i386 mini-itx boxes or all fanless routers in general. But If you mean filtering based on interface or IP that is associated with a particular VLAN, as well as things like ip verify unicast reverse-path then yes you can do that in BSD land quite easily. ---Mike
Re: Fanless x86 Server Recommendations
At 02:25 PM 29/06/2006, Ray Van Dolson wrote: We're looking to acquire a couple small servers that can act as routers for us at remote locations. To minimize hardware issues, I'd love to get something that has no fans, can still run a fairly decent processor and preferably no hard drive (easy with an IDE CF adapter). It would need a couple PCI slots for quad port ethernet cards and a fairly robust tolerance to temperature variations. Many mini-itx boxes dont have 2 PCI slots. You might be better going with a mini-itx solution and then use a small switch and trunk the NIC to act as a VLAN router. We have been using various embedded devices from Commell (http://www.commell.com.tw/Product/SBC/LV-667.HTM). They seem to work well and can deal with 45C operating temps and have decent hardware watchdog support (FreeBSD version at http://www.tancsa.com/watchdog/). ---Mike
Re: Open Letter to D-Link about their NTP vandalism
At 08:36 PM 10/04/2006, Simon Lyall wrote: I've said in other forums the only solution for this sort of software is to return the wrong time (by several months). The owner might actually notice then and fix the problem. Of our customers who have such routers, I would say 90% would not know the unit even kept time, let alone the correct or incorrect time. ---Mike
Re: Cogent
At 11:53 AM 08/02/2006, Joseph Nuara wrote: Can anyone shed some light on the current Cogent latency issues? The scoreboard is lit up like a Tree ... Thanks. http://status.cogentco.com Cogent Network Status/DNS Server Status Description: Welcome to Cogent Communications' Network Status Message. Today is Wednesday Feb 8th at 10:30am EST. Cogent is currently experiencing an outage in the Chicago area. Some customers may experience latency on the Cogent backbone due to the Chicago outage. The outage is caused by break within our fiber providers network. The provider's techs are onsite where they believe the break is located as well as splice crews on the way. No estimate time of repair at this time. Please use HD376421 as a reference for this outage. We appreciate your patience in this matter. Joe
Re: Akamai server reliability
At 01:39 PM 28/11/2005, Roy wrote: Is anyone else seeing high failure rates of Akamai servers at their facilities? Nope, just one bad box in many years. ---Mike
Re: multi homing pressure
At 11:59 AM 19/10/2005, Elmar K. Bins wrote: [EMAIL PROTECTED] (Todd Vierling) wrote: Tier-2s should be given much more credit than they typically are in write-ups like this. When a customer is single homed to a tier-2 that has multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's aggregations, that means one less ASN and one or more less routes in the global table. That's the operators' view, but not the customer's. The customer wants redundancy. The customer wants reliability and BGP is not necessarily the way for them to do it. Telling a typical corporate IT department with generalized IT skills (read no large Internetworking experience) to now become BGP masters will only open up a news ways to disrupt their network connectivity. There are better ways to do it as you describe below. So we should try to find a way to tell them Hey, it's mostly Tier-1's (or wannabes) that play such games, stick to a trustworthy Tier-2. And, hey, btw., connect redundantly to them, so you have line failure resiliency and also a competent partner that cares for everything else. Agreed! ---Mike
Re: Cogent/Level 3 depeering
At 11:50 AM 05/10/2005, Matthew Crocker wrote: I opened a billing/support ticket with Cogent. I'm not planning on paying my bill or continuing the contract if they cannot provide full BGP tables and full Internet transport (barring outages). Luckily I have 2 other providers so I can still reach Level 3. Maybe I can buy the new 'Cogent - it is almost the Internet' service for less money. Perhaps they took the 3 in level3 to mean 3 routes ? ;-) cogent-gate# show ip bgp regex 174 .* 3356$ Network Next HopMetric LocPrf Weight Path * 63.135.164.0/24 38.112.9.13 15001100110 174 701 18905 14745 1239 3356 i * 194.32.125.0 38.112.9.13 18000100110 174 1273 9121 3549 3356 i * 194.32.127.0 38.112.9.13 18000100110 174 1273 9121 3549 3356 i Rather than swamping their desk with the same ticket, can you report back to NANOG what they tell you ? ---Mike
Re: Cogent/Level 3 depeering
At 01:43 PM 05/10/2005, Jeff Shultz wrote: And why isn't this apparently happening automatically? Pardon the density of my brain matter here, but I thought that was what BGP was all about? The assumption you are making is that Cogent has a full view from someone of all prefixes outside AS174 and that someone is providing a full view of AS174 to their downstreams/peers etc. My guess is this is not the case. ---Mike
Re: Cogent/Level 3 depeering
At 02:47 PM 05/10/2005, Douglas Dever wrote: fact remains that Cogent is not providing the service I'm paying them for and they need to get it fixed. Really? As you already pointed out, your packets are reaching their destination. So, they don't need to get anything fixed. I think what people are upset about is that you now have less redundancy now if you are a cogent transit customer. If I tell my customers, I have 3 full transit links, I now have to put an * there. If my 2 non cogent links go down, I dont have a full visibility of the Internet. I see everything, except Level3. It becomes more acute if you have just 2 transit links-- Cogent and one other. What if your other provider has a lossy path to Level 3 ? You cant work around it by preferencing 174 3356 ---Mike
Re: Computer systems blamed for feeble hurricane response?
At 07:28 AM 14/09/2005, Suresh Ramasubramanian wrote: On 9/14/05, Mike Tancsa [EMAIL PROTECTED] wrote: Port 587? Not everyone implements that. You would make a large part of the internet unreachable via email vinyl# telnet mx2.mail.yahoo.com 587 Trying 67.28.114.36... telnet: connect to address 67.28.114.36: Connection refused Trying 4.79.181.13... Wrong host. 587 / msa is for outbound email Sorry, my point was that you could not just assume the sending host was a mail server by connecting back to the host on the submission port as it might not be listening on that port or that because the host sending is not in the MX list, that its not a mail server. ---Mike
Re: Computer systems blamed for feeble hurricane response?
At 09:31 AM 13/09/2005, Steven Champeon wrote: Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... No MX record, and the A record for fema.gov does not accept smtp traffic. # telnet fema.gov smtp Trying 205.128.1.44... telnet: connect to address 205.128.1.44: Operation timed out telnet: Unable to connect to remote host # Then again, it might be that they use different email addresses ? @dhs.gov ? set type=soa fema.gov Server: ns.fema.gov Address: 166.112.200.142 fema.gov origin = ns.fema.gov mail addr = root.ns2.fema.gov serial = 2005090901 refresh = 10800 (3H) retry = 3600 (1H) expire = 604800 (1W) minimum ttl = 1800 (30M) fema.govnameserver = ns.fema.gov fema.govnameserver = ns2.fema.gov ns.fema.gov internet address = 166.112.200.142 ns2.fema.govinternet address = 162.83.67.144 Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) ---Mike
Re: Computer systems blamed for feeble hurricane response?
At 10:29 AM 13/09/2005, Steven Champeon wrote: on Tue, Sep 13, 2005 at 09:54:42AM -0400, Mike Tancsa wrote: Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) Well, how is any automated system supposed to find it? Sheesh. Apparently, that host accepts mail to postmaster; we'll see if it is actually delivered/read/responded to. SOA said root.ns2.fema.gov. It might be someone actually read's roots mail ? I will cc that addr so if its read, they can see the thread at http://www.merit.edu/mail.archives/nanog/msg11505.html and perhaps comment. ---Mike -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
At 03:50 PM 13/09/2005, Joseph S D Yao wrote: Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet. While I mourn the simplicity of manual debugging of such sites, it remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean that there's no mail service there. Making a network connection using the application telnet vs the application sendmail (or whatever MTA one uses) seems to be the same when doing a tcpdump on the data. I am not sure how a firewall would know -- purely at the network layer -- what the other side's application was/is that initiated the connection. Yes, the other end could try and connect back to the host, but there is no 2 way traffic as the 3way handshake is not completing and I dont see any other traffic coming back from that host attempting to discern any info. ---Mike
Re: OT: Cisco.com password reset.
Same here. I didnt get a notice that it was reset, but I cannot login ---Mike At 09:30 AM 03/08/2005, Dan Armstrong wrote: My PW to CCO did not work this morning either. I am on hold with the TAC right now Joe Blanchard wrote: FYI I got an email that my CCO account's password was reset last night. Not sure how widespread this issue was, but I called my account contact and verified that this is a valid email, and that my password needed to be reset. Just a heads up. -Joe Blanchard
DDoS attacks, spoofed source addresses and adjusted TTLs
I had a DDoS this morning (~ 130Mb) against one of my hosts. Packets were coming in all 3 of my transit links from a handful of source IP addresses that sort of make sense in terms of the path they would take to get to me. They were all large UDP packets of the form 09:08:58.981781 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy 0800 1514: 82.165.244.204 ta.rg.et.IP: udp (frag 47080:[EMAIL PROTECTED]) (ttl 54, len 1 500) 0x0010 4242 4242 4242 4242 4242 4242 0x0020 4242 4242 4242 4242 4242 4242 4242 4242 0x0030 4242 4242 4242 4242 4242 4242 4242 4242 0x0040 4242 4242 4242 4242 4242 4242 4242 4242 0x0050 4242 4242 4242 4242 4242 4242 4242 4242 0x0060 4242 4242 4242 4242 4242 4242 4242 4242 The TTLs all kind of make sense and are consistent (e.g. if the host is 8 hops away, the TTL of the packet when it got to me was 56). Yes, I know those could be adjusted in theory to mask multiple sources, but in practice has anyone seen that ? I seem to recall reading the majority of DDoS attacks do not come from spoofed source IP addresses. Of the traffic snapshot I took, the break down seems to jive as well with the PTR records. i.e. PTR records that indicate a home broadband connection were less than PTR records suggesting a server in a datacentre somewhere. A few of the IPs involved capturing 1000 packets on one of my links at the time. 210 207.58.177.151 - server.creditprofits.com 287 65.39.230.20 - server4.xlservers.com 11 67.52.82.118 - rrcs-67-52-82-118.west.biz.rr.com 492 82.165.244.204 - u15178515.onlinehome-server.com It was pretty short lived as well -- about 8 min total. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Transit politics (Telus blocking sites it does not like)
http://www.edmontonsun.com/News/Canada/2005/07/24/1145417-sun.html As the slashdot headline quotes, Canadian telephone company and ISP Telus has admitted that they are http://www.edmontonsun.com/News/Canada/2005/07/24/1145417-sun.htmlblocking all attempts to access a website set up by the employee's union (who is currently on-strike or locked-out, depending on your point of view). Currently no customers of the Telco's ADSL service (or any other ADSL service provider who leases lines) can access the http://www.voices-for-change.com/union's webpage. Is it reasonable for an ISP to censor webpages they don't agree with during contract negotiations? As Telus is one of my transit providers, they are still advertising the path to me, but are blackholing the /32s in question. Kind of sets a bad precedent for a common carrier argument :( I like BGP blackholing to protect internet infrastructure, but what exactly is this protecting ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Transit politics (Telus blocking sites it does not like)
At 10:05 AM 25/07/2005, Patrick W. Gilmore wrote: ISPs are not common carriers. Look at your contract, I think you will find they are allowed to filter specific things if they feel necessary for a wide variety of reasons. Infrastructure reasons yes. This is not an infrastructure issue. As to whether or not an ISP is or is not a common carrier is still up for debate especially here in Canada. (I have not read the Telus contract, but such language is pretty standard.) Put another way: If the /32 in question was a spam source, would you feel the same? Yes. I dont want them deciding that for me at the network layer. Besides, SPAM is more on the fence as to whether or not its an infrastructure issue. A spambot/zombie, yes thats infrastructure. If they want to drop the advertisement, thats fine. If they want to put in their contract that they will filter content they do not like politically, OK, I will vote with my feet. If the material on those websites are illegal, there are established laws for dealing with it. ---Mike
Re: Transit politics (Telus blocking sites it does not like)
A nice succinct analysis (by an actual lawyer (law prof) who specializes in Canadian Internet law) can be found at http://www.michaelgeist.ca/ start of quote Telus Blocks Subscriber Access to Union Website Reports today indicate that Telus is currently blocking access to Voices for Change, a website run by the Telecommunications Workers Union. The company has confirmed that its nearly one million subscribers are blocked from accessing the site, though it is obviously available to just about everyone else (and presumably to Telus subscribers that engage in some creative Internet surfing). The company argues that the site contains confidential proprietary information and that photographs on the site raise privacy and security issues for certain of its employees. I can't comment on the contents of the site. Unless the site features content that is unlawful (as found by a Canadian court), however, Telus should not be coming anywhere near blocking access. Internet service providers have long argued (Telus being among the most vocal) that they should be treated much like common carriers with no discrimination or distinction between the bits transferred on their networks. I've previously argued that packet preferencing for VoIP is a growing concern. Content specific blocking is an entirely different and even more troubling matter. ISPs have persuaded the Supreme Court of Canada, Canadian policy makers, and government officials that the content blocking, whether copyright or child pornography related, is out of their control and bad policy. To block a specific website that leaves the company uncomfortable is more than just bad policy as well as completely ineffective. It is dangerous. Dangerous for free speech in this country, dangerous for those who believe that the law, not private parties, should determine what remains accessible on ISP networks, and dangerous for the ISPs themselves, who risk seeing this blow up in their face as part of the ongoing telecommunications policy review that is considering the appropriate regulatory framework for those same ISPs. end of quote
Re: Microsoft broke MTU discovery by last security pathces??
There is discussion on ntbugtraq http://www.ntbugtraq.com/default.aspx?pid=36sid=1A2=ind0505L=ntbugtraqT=0O=DF=NP=192 ---Mike At 04:43 PM 17/05/2005, Alexei Roudnev wrote: Do you have amny information about last Microsoft problems with security patches? We can see, how one of last updates broke MTU discovery (not totally, but it restricts number of discovered pathes so servers tsop working in a few days). And, amazingly, no one published this problem.
Re: ATT.net Security Contact
At 04:39 PM 17/04/2005, Joseph W. Breu wrote: Can someone from ATT.net security contact me offlist RE: our network in their RBL? Try [EMAIL PROTECTED] Humans do seem to read it. During the week they responded within a few hrs. However, when I asked why they blacklisted us in the first place, I never got an answer-- Only a few dozen auto ticket responses for some reason. Not sure if that was a hint that was lost on me, or something broken. ---Mike
Sympatico / Nexxia (as577) smtp issues ?
Anyone know whats up with Sympatico / Bell's mail servers ? My customers are asking me why their mail is not getting there nor mail from sympatico is not getting to us. Most mail does not seem to be going through although network connectivity seems fine. I tried from 2 other networks and the issue seems to be the same. host -tmx sympatico.ca sympatico.ca mail is handled by 5 toip6.bellnexxia.net. sympatico.ca mail is handled by 5 toip7.bellnexxia.net. sympatico.ca mail is handled by 5 toip8.bellnexxia.net. sympatico.ca mail is handled by 5 toip1.bellnexxia.net. sympatico.ca mail is handled by 5 toip2.bellnexxia.net. sympatico.ca mail is handled by 5 toip3.bellnexxia.net. sympatico.ca mail is handled by 5 toip4.bellnexxia.net. sympatico.ca mail is handled by 5 toip5.bellnexxia.net. telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip1.bellnexxia.net smtp Trying 209.226.175.84... telnet: Unable to connect to remote host: Connection refused telnet toip2.bellnexxia.net smtp Trying 209.226.175.85... telnet: Unable to connect to remote host: Connection refused telnet toip3.bellnexxia.net smtp Trying 209.226.175.86... telnet: Unable to connect to remote host: Connection refused telnet toip4.bellnexxia.net smtp Trying 209.226.175.87... Connected to toip4.bellnexxia.net. Escape character is '^]'. 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. telnet toip5.bellnexxia.net smtp Trying 209.226.175.88... telnet: Unable to connect to remote host: Connection timed out telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip7.bellnexxia.net smtp Trying 209.226.175.175... telnet: Unable to connect to remote host: Connection refused Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: RADB anon ftp server stoned or deprecated?
Works for me. Are you sure you are not coming from a PTR/A record mismatch ? smarthost1# host 66.235.194.37 37.194.235.66.IN-ADDR.ARPA domain name pointer ds194-37.ipowerweb.com smarthost1# host ds194-37.ipowerweb.com Host not found. smarthost1# smarthost1# host -tns ipowerweb.com ipowerweb.com name server ns2.ipowerweb.net ipowerweb.com name server ns1.ipowerweb.net smarthost1# host ds194-37.ipowerweb.com ns1.ipowerweb.net Using domain server: Name: ns1.ipowerweb.net Addresses: 64.70.61.130 smarthost1# host ds194-37.ipowerweb.com ns2.ipowerweb.net Using domain server: Name: ns2.ipowerweb.net Addresses: 66.235.217.200 smarthost1# At 10:05 PM 14/02/2005, Bill Nash wrote: $ ftp ftp.radb.net Connected to ftp.radb.net (198.108.1.48). 421 Service not available, remote server has closed connection $ ftp ftp.merit.edu Connected to ftp.merit.edu (198.108.1.48). 421 Service not available, remote server has closed connection - billn
no whois info ?
While doing a quick sample of my spam to see where spamvertized web sites were hosted and registered, I came across the domain vestigial3had.com shell1% whois vestigial3had.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for VESTIGIAL3HAD.COM. yet, shell1% host -tns vestigial3had.com vestigial3had.com name server ns1.kronuna.biz vestigial3had.com name server ns2.kronuna.biz shell1% What gives ? How can their be no whois info anywhere ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: no whois info ?
At 11:17 AM 09/12/2004, william(at)elan.net wrote: Read NANOG archives - Verisign now allows immediate (well, within about 10 minutes) updates of .com/.net zones (also same for .biz) Yes, I was aware of that. while whois data is still updated once or twice a day. I (wrongly) assumed that the initial whois data would be immediately there to be seen at registration time That means if spammer registers new domain he'll be able to use it immediatly and it'll not yet show up in whois (and so not be immediatly identifiable to spam reporting tools) - and spammers are in fact using this feature more and more! What a lovely well thought out feature ---Mike
Re: no whois info ?
At 01:50 PM 09/12/2004, Jeff Rosowski wrote: shell1% whois vestigial3had.com ... No match for VESTIGIAL3HAD.COM. What gives ? How can there be no whois info anywhere ? You can also make whois information private, usually for an additional fee. I wonder what % of domains that have their whois info hidden or private are throwaway spam domains... Some number approaching 100% I would bet. It would be nice to somehow incorporate this into a SpamAssassin check somehow. ---Mike
RE: no whois info ?
At 02:44 PM 09/12/2004, Hannigan, Martin wrote: Perhaps 100% of spammers hide their registration data when possible, but I wouldn't say that 100% of hidden registrations are spammers. An RBL option of this type of data would probably mean forced elimination of a benefit to the public - privacy. There has to be a balance between expectations to privacy when participating in a public space (the internet). Putting your name and address behind a domain is not unreasonable in my mind. You are afterall publishing DNS info, so its not a case of total privacy. I use RBLs to score messages, not reject them. ---Mike
Re: no whois info ?
At 03:10 PM 09/12/2004, Daniel Senie wrote: The WHOIS data is there to ensure there's someone to contact. As long as the data listed can be used to reach the domain holder for legitimate purposes (technical problems, etc.), why should you care if the listed address is a Care Of address, the email address goes through a redirect or is handled by an agent trusted by the domain holder? Yes, I agree. I am talking about not having *ANY* whois info. I dont see how any of your arguments justify % whois vestigial3had.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for VESTIGIAL3HAD.COM. Hopefully this is just a case of the whois info not catching up with the registration There should always be some way to contact the domain holder, or registrar. Right now, there is none for this domain which is wrong IMO. ---Mike
Re: no whois info ?
At 07:49 PM 09/12/2004, Peter John Hill wrote: Jeff Rosowski wrote: shell1% whois vestigial3had.com ... No match for VESTIGIAL3HAD.COM. What gives ? How can their be no whois info anywhere ? How about the following... (note that just because someone is using someone as their authoritative name server doesn't mean that the other people (in this case kronuna.biz) have anything to do with it... [EMAIL PROTECTED] ~]$ dig ns vestigial3had.com snip ;; ANSWER SECTION: vestigial3had.com. 172800 IN NS ns1.kronuna.biz. vestigial3had.com. 172800 IN NS ns2.kronuna.biz. I dont follow ? It seems to me they do answer for the domain. granite# dig vestigial3had.com ;; ANSWER SECTION: vestigial3had.com. 1M IN A 200.124.75.12 ;; AUTHORITY SECTION: vestigial3had.com. 1M IN NSns1.kronuna.biz. vestigial3had.com. 1M IN NSns2.kronuna.biz. ;; ADDITIONAL SECTION: ns1.kronuna.biz.27S IN A200.124.75.9 ns2.kronuna.biz.27S IN A219.154.96.29 granite# dig axfr vestigial3had.com @200.124.75.9 ; DiG 8.3 axfr vestigial3had.com @200.124.75.9 ; (1 server found) $ORIGIN vestigial3had.com. @ 1M IN SOA @ root ( 240420115 ; serial 8H ; refresh 1M ; retry 1W ; expiry 1H ); minimum 1M IN NSns1.kronuna.biz. 1M IN NSns2.kronuna.biz. 1M IN MX10 www 1M IN A 200.124.75.12 * 1M IN A 200.124.75.12 a 1M IN A 221.5.250.122 *.a 1M IN A 221.5.250.122 a6 1M IN A 221.5.250.122 *.a61M IN A 221.5.250.122 e 1M IN A 221.5.250.122 *.e 1M IN A 221.5.250.122 g 1M IN A 221.5.250.122 *.g 1M IN A 221.5.250.122 i 1M IN A 221.5.250.122 *.i 1M IN A 221.5.250.122 m 1M IN A 221.5.250.122 *.m 1M IN A 221.5.250.122 mail1M IN CNAME @ www 1M IN CNAME @ @ 1M IN SOA @ root ( 240420115 ; serial 8H ; refresh 1M ; retry 1W ; expiry 1H ); minimum ;; Received 1 answer (21 records). ;; FROM: granite.sentex.ca to SERVER: 200.124.75.9 ;; WHEN: Thu Dec 9 20:00:30 2004
Re: no whois info ?
At 10:32 PM 09/12/2004, Janet Sullivan wrote: I wonder what % of domains that have their whois info hidden or private are throwaway spam domains... Some number approaching 100% I would bet. It would be nice to somehow incorporate this into a SpamAssassin check somehow. Please don't, there are legitimate reasons to have private domain names. One of the main reasons my domains are private is I got tired of the spam and direct snail mail I got to the contact addresses. The internet is a public space. If your domain is being abused / misused, how are people supposed to contact the domain holder or registrar if there is no whois record for the domain OR the registrar ?Remember, I am talking about domains that whois servers says does not exist, but for whose DNS is active in the root name servers. In this case, I was talking about the domain vestigial3had.com which was registered this AM, and by the time it shows up in the whois records 24hrs later, is thrown away by the spammer after blasting out their spam Anyways, its there now Domain Name: VESTIGIAL3HAD.COM Registrar: BIZCN.COM, INC. Whois Server: whois.bizcn.com Referral URL: http://www.bizcn.com Name Server: NS1.KRONUNA.BIZ Name Server: NS2.KRONUNA.BIZ Status: REGISTRAR-LOCK Updated Date: 09-dec-2004 Creation Date: 09-dec-2004 Expiration Date: 09-dec-2005 Registrant Contact: Uno More haun nito [EMAIL PROTECTED] 371-6352202 fax: 371-6352202 Briezha 5-6 Riga Riga LV 1021 lv Yeah, one more throwaway spam domain Also, some people, like incest survivors, feel better not having their name out there as an owner of a related support site. ... Roll account/PO Box ---Mike
Re: Make love, not spam....
At 09:39 AM 29/11/2004, Suresh Ramasubramanian wrote: Fergie (Paul Ferguson) wrote: I'd be curious to hear what NANOG readers thoughts are on this. It would be interesting to see how this fares when faced with a whole lot of router acls that got put in to filter out nachi Although I generally like spamcop (one of the sources for determining spamvertised websites) for use with SpamAssassin in scoring, its not the most conservative list e.g. http://www.spamcop.net/w3m?action=blcheckip=198.108.1.41 list Merit as a spam source...) and the accidental listing or potential for abuse could be nasty. What about the case where the spammer gets black listed, traffic starts pounding the rouge site and then the spammer changes the A record to be www.example.com instead. Now all of a sudden www.example.com is being pounded by all those screen savers. ---Mike
Re: short Botnet list and Cashing in on DoS
At 01:10 AM 07/10/2004, J. Oquendo wrote:
I've been slowly compiling a list of known botnets should
A lot of the IP addresses you have listed seem like they would change with
some frequency based on the host names. The problem with using such a list
is that it can quickly become out of date unless the entries are
automatically aged. Think of a dialup zombie assigned a dynamic IP out of
the netblock 192.168.0.0/24. Over time, 192.168.0.1 through .255 will
become black listed as the user comes and goes. A quick
cat list | sort | uniq | awk '{print host $1}' | sh
shows
0.102.218.12.IN-ADDR.ARPA domain name pointer 12-218-102-0.client.mchsi.com
197.26.119.128.IN-ADDR.ARPA domain name pointer jqa-197.res.umass.edu
227.8.119.128.IN-ADDR.ARPA domain name pointer ja2-227.res.umass.edu
Host not found.
76.84.36.128.IN-ADDR.ARPA domain name pointer yale128036084076.student.yale.edu
144.150.2.129.IN-ADDR.ARPA domain name pointer rkraft.student.umd.edu
205.153.64.130.IN-ADDR.ARPA domain name pointer resnet153-205.medford.tufts.edu
154.221.49.137.IN-ADDR.ARPA domain name pointer uhartford221154.hartford.edu
58.229.166.141.IN-ADDR.ARPA domain name pointer smh229058.richmond.edu
57.230.166.141.IN-ADDR.ARPA domain name pointer smh230057.richmond.edu
2.233.166.141.IN-ADDR.ARPA domain name pointer sfa233002.richmond.edu
87.236.166.141.IN-ADDR.ARPA domain name pointer sfa236087.richmond.edu
247.237.166.141.IN-ADDR.ARPA domain name pointer sfa237247.richmond.edu
168.130.216.150.IN-ADDR.ARPA domain name pointer tfk1116.students.ecu.edu
82.187.1.152.IN-ADDR.ARPA domain name pointer fahrmpc32.cvm.ncsu.edu
Host not found.
222.128.112.195.IN-ADDR.ARPA domain name pointer proxy02.ada.net.tr
131.11.66.200.IN-ADDR.ARPA domain name pointer
customer-MZT-11-131.megared.net.mx
102.214.253.206.IN-ADDR.ARPA domain name pointer construct.enic.cc
205.147.234.207.IN-ADDR.ARPA domain name pointer
207-234-147-205.ptr.primarydns.com
Host not found.
198.173.54.213.IN-ADDR.ARPA domain name pointer
p213.54.173.198.tisdip.tiscali.de
58.114.254.216.IN-ADDR.ARPA domain name pointer
dsl254-114-058.nyc1.dsl.speakeasy.net
114.8.195.24.IN-ADDR.ARPA domain name pointer alb-24-195-8-114.nycap.rr.com
Host not found.
Host not found.
Host not found.
163.26.167.62.IN-ADDR.ARPA domain name pointer adsl-62-167-26-163.adslplus.ch
248.180.65.62.IN-ADDR.ARPA domain name pointer irc-out.antik.sk
179.55.23.64.IN-ADDR.ARPA domain name pointer 64-23-55-179.ptr.skynetweb.com
7.156.37.64.IN-ADDR.ARPA domain name pointer patch-virt7.station.sony.com
156.238.110.65.IN-ADDR.ARPA domain name pointer coy.student.iastate.edu
163.75.210.66.IN-ADDR.ARPA domain name pointer wsip-66-210-75-163.lu.dl.cox.net
20.188.250.66.IN-ADDR.ARPA domain name pointer 66.250.188.20.chaincast.com
200.234.45.66.IN-ADDR.ARPA domain name pointer irc.ashenworlds.net
Host not found, try again.
56.87.90.66.IN-ADDR.ARPA domain name pointer .
36.53.149.68.IN-ADDR.ARPA domain name pointer
S0106000103a72199.ed.shawcable.net
146.173.41.69.IN-ADDR.ARPA domain name pointer unused.800hosting.com
60.89.42.69.IN-ADDR.ARPA domain name pointer irc.afraid.org
1.212.247.80.IN-ADDR.ARPA domain name pointer servicez.org
Have you sent email to those edu abuse contacts ? Most of the universities
I have worked with for abuse resolution are generally responsive.
---Mike
Re: Are AOL's MXs mass rejecting anyone else's emails?
At 07:27 AM 07/09/2004, Thornton wrote: Only thing you can do is try to call them but that probably wont get you anywhere. If you have enough customers on AOL they can complain and if you really have a lot could get it removed. But for the most part your just SOL Thats not been our experience at all. On the 2 times we have had to talk to them we didnt have much trouble getting through to someone clueful and useful. Compared to the other big providers I have dealt with in the past they were by far the most amenable to working to fix the problem. ---Mike
Re: Seeking abuse contact for 142.177.73.59
Try @aliant.ca (note the one L). Bell.ca (BCE) is a majority owner in Aliant which is an amalgamation of the various old provincial incumbent telcos and they are just finishing up a nasty protracted strike as well. ---Mike At 01:52 PM 07/09/2004, Dave Dennis wrote: Greetings, Attempting to locate someone in authority for ip 142.177.73.59. Was referred to [EMAIL PROTECTED], but mail to that address bounces after rattling around inside Exchange for a bit.
Re: Senator Diane Feinstein Wants to know about the Benefits of P2P
At 04:12 PM 30/08/2004, Dan Hollis wrote: yep md5 made the news recently because it's been cracked: http://techrepublic.com.com/5100-22-5314533.html http://www.rtfm.com/movabletype/archives/2004_08.html#001055 Thats a misleading over simplification. A collision being found implies something different than its cracked. A weakness that was theorized sometime ago has been demonstrated in practice. Finding collisions and altering files in a useful way to produce a duplicate hash are different things. There are FAR bigger security concerns than this one right now IMHO. I recall even seeing posts about people claiming this meant original data being reconstructed from the checksum! That would be truly amazing since I could reconstruct a 680MB ISO from just 61d38fad42b4037970338636b5e72e5a. Wow! ---Mike ---Mike
Re: Senator Diane Feinstein Wants to know about the Benefits of P2P
At 05:10 PM 30/08/2004, Scott Call wrote: On Mon, 30 Aug 2004, Mike Tancsa wrote: I recall even seeing posts about people claiming this meant original data being reconstructed from the checksum! That would be truly amazing since I could reconstruct a 680MB ISO from just 61d38fad42b4037970338636b5e72e5a. Wow! Technically, using an Infinate Monkeys approach, you could rebuild the ISO by generating the expentially huge quantity of all possible data and check them and find the one that matches the ISO. Reminds me of Wyle E. Coyote. Instead of getting a damn shotgun and just shooting the road runner, he gets the ACME MD5 hash-collision-o-tron to concoct some possible but improbable scheme involving RR' ---Mike
Next hop issues inside AS577 to AS852?
Unfortunately, I am not a direct customer of AS577 otherwise I would open a ticket with them, but we have a lot of sites inside Bell Canada that need to reach us. Starting suspiciously at maintenance window time, we were seeing sporadic reachability issues coming at us from Bell. I am pretty sure its to us, and not the other way around as exiting out, I always prefer my GT/360 link and depending on the source IP it always works. The path back to me was via AS852 (telus) but I had to massively prepend to force it via someone else to get things working. But here are 2 traceroutes from inside AS577 (Bell) back to me Traceroute a) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.1 (64.7.153.1), 64 hops max, 44 byte packets 1 209.226.183.241 266.863 ms 219.712 ms 199.588 ms 2 206.172.130.250 219.408 ms 219.700 ms 209.619 ms 3 206.47.229.8 239.433 ms 195.376 ms 193.984 ms 4 64.230.241.125 229.460 ms 199.675 ms 209.669 ms 5 64.230.242.150 209.415 ms 189.707 ms 199.627 ms 6 154.11.3.25 239.440 ms 219.684 ms 208.091 ms 7 154.11.6.17 241.001 ms 217.379 ms 231.976 ms 8 64.7.143.44 229.456 ms 199.648 ms 189.635 ms 9 64.7.143.45 224.784 ms 194.333 ms 189.678 ms 10 64.7.153.1 229.431 ms 209.654 ms 209.672 ms traceroute b) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.56 (64.7.153.56), 64 hops max, 44 byte packets 1 209.226.183.241 278.871 ms 221.986 ms 189.687 ms 2 206.172.130.250 219.433 ms 229.680 ms 339.650 ms 3 206.47.229.19 239.447 ms 189.621 ms 195.621 ms 4 64.230.241.121 223.483 ms 209.663 ms 199.695 ms 5 64.230.242.97 329.445 ms 209.667 ms 229.666 ms 6 64.230.242.181 239.463 ms 196.798 ms 192.568 ms 7 * * * 8 * * * Every 60 seconds or so the path back to me inside AS577 would change back and forth between a) and b). I dont know what Hop 7 on b) is. It could be another peer to AS852 (Telus) or just another internal router at Bell (AS577). Suffice to say, when taking path b) packets never get back to me. To work around it, I had to prepend out my AS852 link so that Bell comes back at me via GT/360 or Cogent. Anyone from Bell or Telus around to clarify where the problem is? Sadly, this is a holiday long weekend here in Canada :( The wheels fell off around 4:30 AM EST. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
RE: Next hop issues inside AS577 to AS852?
At 08:27 AM 31/07/2004, Krichbaum, Eric wrote: If it's every 60 seconds, I'd suspect the BGP timer is the root. They probably forgot to use next-hop self or a static route to a peer. The end result being that the route to the bgp peer is learned via bgp itself... Maybe. Hard to say if thats what their default hold time is. I am still seeing the odd hit in their network. For the sites we connect with inside Bell, the tunnel LQR expire is 10 seconds and we have seen 2 big bounces since routing around this morning. I emailed their noc, but no response. The Bell looking glass doesnt seem to have any flap statistics so I dont know if things are bouncing inside :( It is looking different once again. Via Cogent to me, 194# traceroute 199.212.134.1 traceroute to 199.212.134.1 (199.212.134.1), 64 hops max, 44 byte packets 1 HSE-MTL-ppp12931.qc.sympatico.ca (209.226.183.241) 266.986 ms 229.511 ms 209.679 ms 2 Hamilton-ppp278329.sympatico.ca (206.172.130.250) 419.439 ms 219.614 ms 199.657 ms 3 kitcorr01-fe0-0-0.15.in.bellnexxia.net (206.47.229.8) 219.461 ms 239.605 ms 187.514 ms 4 badBellDNS (64.230.241.125) 221.605 ms 209.597 ms 199.655 ms 5 badBellDNS (64.230.242.194) 219.439 ms 227.155 ms 202.135 ms 6 core2-chicago23-pos10-0.in.bellnexxia.net (206.108.103.118) 229.386 ms 249.620 ms 346.174 ms 7 bx1-chicago23-pos11-0.in.bellnexxia.net (206.108.103.125) 228.434 ms 234.041 ms 219.645 ms 8 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 249.438 ms 239.589 ms 199.658 ms 9 p15-0.core02.ord01.atlas.cogentco.com (66.28.4.62) 239.441 ms 249.618 ms 229.679 ms 10 p5-0.core01.yyz01.atlas.cogentco.com (66.28.4.214) 249.409 ms 237.480 ms 231.808 ms 11 g0-1.na01.b011027-0.yyz01.atlas.cogentco.com (66.250.14.230) 251.504 ms 259.618 ms 219.669 ms 12 1572534Ontario.demarc.cogentco.com (38.112.5.166) 239.467 ms 249.593 ms 219.660 ms 13 tor-hespler-360-dslgate.sentex.ca (64.7.143.43) 229.489 ms 249.606 ms 214.908 ms 14 hespler-tor-360-i4.sentex.ca (64.7.143.46) 241.707 ms 229.615 ms 219.680 ms 15 ns.sentex.ca (199.212.134.1) 259.436 ms 239.613 ms 215.514 ms Hops 6 and 8 were coming back as * * * on the traceroute a few hrs ago, but packets were getting to and from me. Hopefully someone from Bell will pipe up on or offlist as to what the problem was / is and if its resolved. Telus is my main transit, and I dont like having to use such a blunt approach to working around this issue :( ---Mike Eric Krichbaum, Chief Engineer MCSE, CCNP, CCDP, CCSP, CCIP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Saturday, July 31, 2004 7:52 AM To: [EMAIL PROTECTED] Subject: Next hop issues inside AS577 to AS852? Unfortunately, I am not a direct customer of AS577 otherwise I would open a ticket with them, but we have a lot of sites inside Bell Canada that need to reach us. Starting suspiciously at maintenance window time, we were seeing sporadic reachability issues coming at us from Bell. I am pretty sure its to us, and not the other way around as exiting out, I always prefer my GT/360 link and depending on the source IP it always works. The path back to me was via AS852 (telus) but I had to massively prepend to force it via someone else to get things working. But here are 2 traceroutes from inside AS577 (Bell) back to me Traceroute a) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.1 (64.7.153.1), 64 hops max, 44 byte packets 1 209.226.183.241 266.863 ms 219.712 ms 199.588 ms 2 206.172.130.250 219.408 ms 219.700 ms 209.619 ms 3 206.47.229.8 239.433 ms 195.376 ms 193.984 ms 4 64.230.241.125 229.460 ms 199.675 ms 209.669 ms 5 64.230.242.150 209.415 ms 189.707 ms 199.627 ms 6 154.11.3.25 239.440 ms 219.684 ms 208.091 ms 7 154.11.6.17 241.001 ms 217.379 ms 231.976 ms 8 64.7.143.44 229.456 ms 199.648 ms 189.635 ms 9 64.7.143.45 224.784 ms 194.333 ms 189.678 ms 10 64.7.153.1 229.431 ms 209.654 ms 209.672 ms traceroute b) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.56 (64.7.153.56), 64 hops max, 44 byte packets 1 209.226.183.241 278.871 ms 221.986 ms 189.687 ms 2 206.172.130.250 219.433 ms 229.680 ms 339.650 ms 3 206.47.229.19 239.447 ms 189.621 ms 195.621 ms 4 64.230.241.121 223.483 ms 209.663 ms 199.695 ms 5 64.230.242.97 329.445 ms 209.667 ms 229.666 ms 6 64.230.242.181 239.463 ms 196.798 ms 192.568 ms 7 * * * 8 * * * Every 60 seconds or so the path back to me inside AS577 would change back and forth between a) and b). I dont know what Hop 7 on b) is. It could be another peer to AS852 (Telus) or just another internal router at Bell (AS577). Suffice to say, when taking path b) packets never get back to me. To work around it, I had to prepend out my AS852 link so that Bell comes back at me via GT/360 or Cogent. Anyone from Bell or Telus around to clarify where
Re: Interesting Occurrence
Not the best place to ask (full-discloure or the incidents list perhaps), but there are numerous phishing scams going of late (I get 3 or 4 a day) that exploit an unpatched IE bug e.g. the spam reads You Have a VoiceMessage Waiting Priority :Urgent From:xxx xxx http://www.ONEvoicemailbox.net/voicemail/ (replace ONE with 1 in the host)-- I strongly suggest NOT going to this site with IE This particular site crams in a keylogger into your PC by use of http://221.4.203.78/bestadult/shellscript_loader.js http://221.4.203.78/bestadult/shellscript.js ---Mike At 01:44 PM 21/06/2004, [EMAIL PROTECTED] wrote: Okay... Here is a new one for me. Got a call from my dad saying he left his PC on last night connected to his broadband. He went to log in this morning and noticed a new ID in his user list - IWAP_WWW. He immediately deleted is and called me. I had him ensure his critical updates we all applied - they were. I had him ensure his antivirus was up to date - it was (Norton Antivirus 2004). He is running XP Home. I searched the antivirus sites and elsewhere for references. Any idea if there is a new vulnerability that has not been publicly released? Any clues? Regards, Brent
ARIN whois server offline ?
Reachability to the network seems OK, but the server seems to time out. marble% whois -h whois.arin.net 220.175.8.27 whois: connect(): Operation timed out marble% marble% traceroute whois.arin.net traceroute to whois.arin.net (192.149.252.43), 64 hops max, 44 byte packets 1 iolite4-fxp2 (199.212.134.10) 0.114 ms 0.105 ms 0.090 ms 2 tor-hespler-360-mica (64.7.143.42) 3.105 ms 3.365 ms 3.691 ms 3 h66-59-189-97.gtconnect.net (66.59.189.97) 4.509 ms 4.644 ms 3.871 ms 4 216.18.63.93 (216.18.63.93) 15.021 ms 14.774 ms 15.044 ms 5 POS4-0.PEERA-CHCGIL.IP.GROUPTELECOM.NET (66.59.191.86) 14.175 ms 14.009 ms 14.556 ms 6 p4-6-2-0.r01.chcgil01.us.bb.verio.net (129.250.10.97) 14.892 ms 14.477 ms 14.667 ms 7 p16-2-0-0.r01.chcgil06.us.bb.verio.net (129.250.5.70) 14.680 ms 14.497 ms 14.477 ms 8 POS5-2.BR3.CHI2.ALTER.NET (204.255.174.233) 15.266 ms 15.298 ms 14.956 ms 9 0.so-5-2-0.XL2.CHI2.ALTER.NET (152.63.68.6) 15.469 ms 14.989 ms 15.546 ms 10 0.so-0-0-0.TL2.CHI2.ALTER.NET (152.63.68.89) 15.618 ms 15.804 ms 16.736 ms 11 0.so-3-0-0.TL2.DCA6.ALTER.NET (152.63.19.170) 34.436 ms 34.240 ms 34.352 ms 12 0.so-7-0-0.CL2.DCA1.ALTER.NET (152.63.32.181) 34.680 ms 35.498 ms 35.267 ms 13 194.ATM5-0.GW4.DCA1.ALTER.NET (152.63.37.65) 35.113 ms 35.455 ms 35.452 ms 14 arin-gw2.customer.alter.net (65.207.88.74) 110.848 ms 37.177 ms 38.229 ms 15 *^C marble% Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Yahoo mail public notice of problems ?
Is there a notice I can point non Yahoo Mail customers to explaining why there are delivery delays? We are seeing a lot of stalled deliveries again, and it would be nice to point to an explanation by yahoo as to whats up Stalls are both at the banner not coming up marble% time telnet mx1.mail.yahoo.com smtp Trying 64.156.215.19... Connected to mx1.mail.yahoo.com. Escape character is '^]'. ^] telnet close Connection closed. 0.006u 0.000s 12:07.77 0.0% 0+0k 0+0io 0pf+0w marble% Or at the application layer with temp failures mta103.mail.sc5.yahoo.com Resources temporarily unavailable. Please try again later [#4.16.3]. I checked from another network totally independent of mine and they too are seeing similar problems. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Akamai DNS Issue?
We are unable to make new resolutions from their servers granite# host -t ns akadns.net akadns.net name server zh.akadns.net akadns.net name server eur3.akam.net akadns.net name server zf.akadns.net akadns.net name server zc.akadns.net akadns.net name server asia3.akam.net akadns.net name server usw5.akam.net akadns.net name server zd.akadns.net akadns.net name server zb.akadns.net None seem to respond. ---Mike At 09:08 AM 15/06/2004, Leo Bicknell wrote: From here neither www.google.com, nor www.apple.com work. Both seem to return CNAMES to akadns.net addresses (eg, www.google.akadns.net, www.apple.com.akadns.net), and from here all of the akadns.net servers listed in whois are failing to respond. Can someone confirm from another location? Comments from Akamai? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Akamai DNS Issue?
So anyone know what was the cause ? ---Mike At 09:08 AM 15/06/2004, Leo Bicknell wrote: From here neither www.google.com, nor www.apple.com work. Both seem to return CNAMES to akadns.net addresses (eg, www.google.akadns.net, www.apple.com.akadns.net), and from here all of the akadns.net servers listed in whois are failing to respond. Can someone confirm from another location? Comments from Akamai? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
RE: Akamai DNS Issue?
Interesting At one point I did a quick sniff of my outbound traffic to one of their name server IP addressees and all looked like normal DNS queries But then again I didnt look that closely. ---Mike At 04:07 PM 15/06/2004, Brian Conant wrote: Looks like DoS http://www.theregister.co.uk/2004/06/15/akamai_goes_postal/ Brian Conant Lead Security Engineer ADESA Corp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Tuesday, June 15, 2004 2:53 PM To: Leo Bicknell; [EMAIL PROTECTED] Subject: Re: Akamai DNS Issue? So anyone know what was the cause ? ---Mike At 09:08 AM 15/06/2004, Leo Bicknell wrote: From here neither www.google.com, nor www.apple.com work. Both seem to return CNAMES to akadns.net addresses (eg, www.google.akadns.net, www.apple.com.akadns.net), and from here all of the akadns.net servers listed in whois are failing to respond. Can someone confirm from another location? Comments from Akamai? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Tracking the bad guys
At 09:58 PM 30/05/2004, Sean Donelan wrote: Initially you start to work backwards from the e-mail and find that to be a very frustrating route, said Daniel Larkin, chief of the FBI's Internet Crime Complaint Center, the unit that is coordinating Project Slam Spam. that doesn't lead to a live body. We have collectively realized you have to go the other way and follow the money trail. No doubt it is easier to follow the money... Although not impossible I find it frustrating that when I do find who is controlling the spam proxies, there is no one really to report it to. I feel sorry for the FTC as they no doubt get deluged with useless spam complaints, just like we do. (My fav's are one of your users is abusing us. Stop them!... No IP, no date, nothing!)... So how do you separate the useless complaints from the ones that are actually actionable. On a number of occasions, I watched in real time as a spammer nailed up a connection to one of our infected users and started spamming out via them. I reported the info complete with tcpdumps of the entire session to the large colo provider in the US with no response / results. Yes, it could just be yet another compromised computer, but somehow I doubt it was. The rwhois info did look rather suspicious (PO box, phone # bogus, email contact bounced) and no public services what so ever on the /28 allocated to the group of servers. This was back in the deep dark days of 2000-2001 when times were tough for many such hosting companies and the temptation no doubt great to make a quick buck. ---Mike
Re: Barracuda Networks Spam Firewall
At 05:00 PM 17/05/2004, Joe Boyce wrote: Not to thread jack or anything, but when I first moved our cluster to Spam Assassin, I was disappointed at the amount of messages that would get past Spam Assassin at even a low threshold of 2. I Googled around and found a bunch of rulesets that once installed, started tagging those hard to get messages. Also, use the various RBLs in the scoring. e.g. add 50% of the threshold score if its on spamcop and 25% for some of the other more aggressive RBLs. We have a very high and correct hit rate as a result. Our users can then add white lists for the handful of their contacts that get tagged as spam since they are using spam friendly ISPs. ---Mike
Re: Yahoo Mail problems ? (queue issues in general)
At 01:26 PM 05/05/2004, [EMAIL PROTECTED] wrote: On Wed, 05 May 2004 10:59:55 EDT, Mike Tancsa [EMAIL PROTECTED] said: Anyone else seeing Yahoo mail queue up today ?Some of their servers respond in about 10secs with the HELO banner, most others take more than 2m. Because of the recent increase in SPAM, I was looking to reduce the wait time for the initial HELO to 2m from 5m. However, the RFC calls for 5m on the HELO and another 5m for the MAIL command. Do you have a handle on whether the delay is between the first SYN packet and finally completing the 3-packet handshake, or is it between that and when the 220 banner actually arrives? Or are both phases an issue? Both, depending on which A record I get Also mixed in are things like 421 mta174.mail.scd.yahoo.com Resources temporarily unavailable. Please try again later. Here is an example of one which took quite a long time to respond to the S and then the HELO banner never came up 14:03:10.653498 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 198626121 0 (DF) [tos 0x10] (ttl 64, id 21505, len 60) 14:03:13.649303 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 198626421 0 (DF) [tos 0x10] (ttl 64, id 21521, len 60) 14:03:16.849310 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 198626741 0 (DF) [tos 0x10] (ttl 64, id 21531, len 60) 14:03:20.049332 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460 (DF) [tos 0x10] (ttl 64, id 21536, len 44) 14:03:23.249367 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460 (DF) [tos 0x10] (ttl 64, id 21543, len 44) 14:03:26.449416 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460 (DF) [tos 0x10] (ttl 64, id 21547, len 44) 14:03:32.649436 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 mss 1460 (DF) [tos 0x10] (ttl 64, id 21576, len 44) 14:03:32.728687 0:90:27:5d:4e:ee 0:1:29:2c:b6:30 0800 60: 64.156.215.5.25 205.211.164.51.2013: S [tcp sum ok] 4275443659:4275443659(0) ack 944590798 win 65535 mss 1460 (ttl 55, id 11594, len 44) 14:03:32.728717 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 64.156.215.5.25: . [tcp sum ok] 1:1(0) ack 1 win 58400 (DF) [tos 0x10] (ttl 64, id 21579, len 40) So in the above case, the process just blocks (with sendmail, it does eat a lot of RAM) waiting to hit the HELO timeout. Having a process block like that for up to 10m seems a bit excessive to deliver one email (and its probably a bounce to boot!). What are others doing? This problem seems to becoming more and more acute. What I do is the *first* attemt to deliver the mail has a highly-non-compliant Yes, this is sort of what I have as well. 9 seconds on the initial connect in my case. That gets the lion's share through. The subsequent deliverys are much more patient. In this day and age, you would think define(`confTO_HELO', `1m') define(`confTO_MAIL', `2m') would be safe ---Mike
Teleglobe / Bell Nexxia nexthop problems ?
I am not a direct customer of either of them, but have a lot of endpont sites in Quebec which go through 6543 and 577. Anyone from either of those networks know whats up ? Since we usually go through Chicago to reach them, this is the only reason we noticed. There are other prefixes involved, not just the /16 From the teleglobe LG in Chicago, Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-2-0.core2.Chicago3.teleglobe.net (66.110.14.166) [MPLS: Label 21 Exp 0] 12 msec 12 msec 12 msec 2 if-9-0.core2.Scarborough.Teleglobe.net (207.45.222.181) 12 msec 12 msec 8 msec 3 ix-7-0.core2.Scarborough.Teleglobe.net (207.45.198.2) 28 msec 24 msec 24 msec 4 * * * 5 * * * 6 * * * 7 * * * vs out of newyork, its fine Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-8-0.core3.NewYork.Teleglobe.net (64.86.83.154) [MPLS: Label 74 Exp 0] 204 msec 204 msec 200 msec 2 if-9-0.core2.Montreal.Teleglobe.net (207.45.222.110) 204 msec 208 msec 8 msec 3 ix-8-0.core2.Montreal.Teleglobe.net (207.45.204.46) 204 msec 204 msec 216 msec 4 core4-montreal02-pos6-2.in.bellnexxia.net (206.108.107.61) 200 msec 200 msec 204 msec 5 64.230.243.238 204 msec 12 msec 12 msec 6 64.230.242.94 16 msec 16 msec 16 msec 7 64.230.242.86 56 msec 52 msec 56 msec 8 64.230.248.178 64 msec 60 msec 60 msec 9 64.230.251.18 464 msec 200 msec 200 msec 10 199.243.35.3 [AS 577] 488 msec 320 msec 444 msec The lg from Chicago says, BGP routing table entry for 199.243.0.0/16, version 4127369 Paths: (2 available, best #2) Advertised to peer-groups: reflector-client Advertised to non peer-group peers: 66.110.14.2 204.255.169.17 206.223.119.39 206.223.138.254 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.223.231 (207.45.223.231) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.223.231 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.222.246 (207.45.222.246) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.222.246 Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
TCP RST attack (the cause of all that MD5-o-rama)
http://www.uniras.gov.uk/vuls/2004/236929/index.htm Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Massive stupidity (Was: Re: TCP vulnerability)
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote: party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. snip I dont understand why the large differences in claims http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier. Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed. ---Mike
Re: Compromised Hosts?
At 07:26 PM 21/03/2004, Deepak Jain wrote: Nanogers - Would any broadband providers that received automated, detailed (time/date stamp, IP information) with hosts that are being used to attack (say as part of a DDOS attack) actually do anything about it? From my experiences, some are much better than others. The main thing I think is to make it as clear and as easy to for the provider to act on the issue. So include things like, source IP,port, dest IP,port, time stamps in GMT. Note that the time is actually accurate--i.e. your clocks are NTP sync'd and make that clear in the report. Would the letter have to include information like x.x.x.x/32 has been blackholed until further notice or contact with you to be effective? No. ---Mike
RE: Strange message possibly through nanog mail server
At 04:58 PM 17/03/2004, Alon Tirosh wrote: I *think* I loaded the page in lynx before it got rate-limited, and lynx flashed through a whole mess of fast redirects before faulting out. No logs, unfortunately. A safe way I find to examine potentially trojaned pages is via fetch (or wget) fetch -o questionable.html url Then you can examine the page with appropriate tools. ---Mike
Re: Cisco website www.cisco.com 403 forbidden?
At 03:53 PM 15/03/2004, Tom (UnitedLayer) wrote: On Mon, 15 Mar 2004, Laurence F. Sheldon, Jr. wrote: Jay Hennigan wrote: Is it just me that they don't like? I've seen one or two other reports. Seems like a good opportunity for a round of Wild Speculation. Cisco is under spam attack Cisco has closed their website because Vendor J made fun of it Cisco just lost all of their data! Call DataSafe! An intern unplugged the website Cisco decided to use SPEWS to control access to their website Its obviously the Monsters on Maple street. * * http://www.tvtome.com/TwilightZone/season1.html#ep22 Oh no! Wait, we are the ... Ahhh!!! ---Mike
Re: BellNexxia to CW problems in NY ? (AS577 - AS3561)
Hi Mark, Thanks for responding / confirming. My transits that are CW peers are Telus and 306/GT. I contacted them to contact you as I am not a direct CW customer. I am just in the middle so to speak trying to understand and work around the problem. ---Mike At 06:38 PM 09/03/2004, Mark Kasten wrote: Mike, It does appear that this interconnect is running a bit hot. If there is anyone from Bell Nexxia/AS577 listening, feel free to ping me offline and I'll see what I can do to help out. But, to be honest, this is an issue that could/should be handled your upstream and [EMAIL PROTECTED] I don't see any emails from you sent to [EMAIL PROTECTED] Regards, Mark Kasten Mike Tancsa wrote: I have a few users exchanging data with sites inside Bell Canada call in to complain today with various symptoms (eg. VPNs timing out, transfers taking a long time). After a bit of narrowing down, it would seem that when the traffic comes at me via CW from Bell (2 of my 3 transit providers 852 and 6539 talk to parts of Bell this way) the problems are acute. Looking at traceroutes between CW and Bell IP space, there does indeed seem to be some issue between their exchange point in NY The 2 snippets being From bell to cw 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec From cw to bell 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec At one point in the day, it was adding about 400 to 500ms of latency Type escape sequence to abort. Tracing the route to route-server.cw.net (209.1.220.234) 1 dis40-toronto63-fe5-0-0.in.bellnexxia.net (205.207.238.210) 32 msec 0 msec 232 msec 2 core2-toronto63-pos11-5.in.bellnexxia.net (206.108.98.141) 0 msec 0 msec 0 msec 3 core3-toronto63-pos6-0.in.bellnexxia.net (64.230.242.101) 0 msec 0 msec 0 msec 4 core4-montreal02-pos13-1.in.bellnexxia.net (64.230.243.237) 28 msec 204 msec 208 msec 5 core1-newyork83-pos0-0.in.bellnexxia.net (206.108.99.190) 20 msec 20 msec 16 msec 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec 8 agr2-loopback.NewYork.cw.net (206.24.194.102) [AS 3561] 184 msec 176 msec 180 msec 9 dcr1-so-6-1-0.NewYork.cw.net (206.24.207.53) [AS 3561] 184 msec 180 msec 184 msec 10 dcr2-loopback.SantaClara.cw.net (208.172.146.100) [AS 3561] 248 msec 248 msec 248 msec 11 bhr1-pos-0-0.SantaClarasc8.cw.net (208.172.156.198) [AS 3561] 256 msec 244 msec 244 msec 12 bhr2-ge-2-0.SantaClarasc8.cw.net (208.172.147.54) [AS 3561] 252 msec 248 msec 248 msec 13 209.1.169.177 [AS 3561] 172 msec 184 msec * route-server.cw.nettraceroute looking-glass.in.bellnexxia.net Translating looking-glass.in.bellnexxia.net...domain server (64.41.189.214) [OK] Type escape sequence to abort. Tracing the route to looking-glass.in.bellnexxia.net (205.207.237.50) 1 209.1.169.178 0 msec 0 msec 0 msec 2 bhr1-ge-2-0.SantaClarasc8.cw.net (208.172.147.53) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) 0 msec 4 msec 0 msec 4 dcr1-loopback.NewYork.cw.net (206.24.194.99) 76 msec dcr2-loopback.NewYork.cw.net (206.24.194.100) 72 msec dcr1-loopback.NewYork.cw.net (206.24.194.99) 68 msec 5 agr1-so-0-0-0.NewYork.cw.net (206.24.207.50) 68 msec 72 msec 68 msec 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec 8 core1-newyork83-pos1-1.in.bellnexxia.net (206.108.103.193) 260 msec 332 msec 216 msec 9 core4-montreal02-pos6-3.in.bellnexxia.net (206.108.99.189) 196 msec 204 msec 200 msec 10 64.230.243.238 208 msec 296 msec 460 msec 11 core2-torontodc-pos3-1.in.bellnexxia.net (206.108.104.2) [AS 577] 432 msec 404 msec 404 msec 12 dis4-torontodc-Vlan82.in.bellnexxia.net (206.108.104.30) [AS 577] 400 msec 240 msec 440 msec 13 looking-glass.in.bellnexxia.net (205.207.237.50) [AS 577] 452 msec 236 msec 244 msec route-server.cw.net Anyone know whats up ? ---Mike Mike Tancsa,tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
BellNexxia to CW problems in NY ? (AS577 - AS3561)
I have a few users exchanging data with sites inside Bell Canada call in to complain today with various symptoms (eg. VPNs timing out, transfers taking a long time). After a bit of narrowing down, it would seem that when the traffic comes at me via CW from Bell (2 of my 3 transit providers 852 and 6539 talk to parts of Bell this way) the problems are acute. Looking at traceroutes between CW and Bell IP space, there does indeed seem to be some issue between their exchange point in NY The 2 snippets being From bell to cw 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec From cw to bell 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec At one point in the day, it was adding about 400 to 500ms of latency Type escape sequence to abort. Tracing the route to route-server.cw.net (209.1.220.234) 1 dis40-toronto63-fe5-0-0.in.bellnexxia.net (205.207.238.210) 32 msec 0 msec 232 msec 2 core2-toronto63-pos11-5.in.bellnexxia.net (206.108.98.141) 0 msec 0 msec 0 msec 3 core3-toronto63-pos6-0.in.bellnexxia.net (64.230.242.101) 0 msec 0 msec 0 msec 4 core4-montreal02-pos13-1.in.bellnexxia.net (64.230.243.237) 28 msec 204 msec 208 msec 5 core1-newyork83-pos0-0.in.bellnexxia.net (206.108.99.190) 20 msec 20 msec 16 msec 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec 8 agr2-loopback.NewYork.cw.net (206.24.194.102) [AS 3561] 184 msec 176 msec 180 msec 9 dcr1-so-6-1-0.NewYork.cw.net (206.24.207.53) [AS 3561] 184 msec 180 msec 184 msec 10 dcr2-loopback.SantaClara.cw.net (208.172.146.100) [AS 3561] 248 msec 248 msec 248 msec 11 bhr1-pos-0-0.SantaClarasc8.cw.net (208.172.156.198) [AS 3561] 256 msec 244 msec 244 msec 12 bhr2-ge-2-0.SantaClarasc8.cw.net (208.172.147.54) [AS 3561] 252 msec 248 msec 248 msec 13 209.1.169.177 [AS 3561] 172 msec 184 msec * route-server.cw.nettraceroute looking-glass.in.bellnexxia.net Translating looking-glass.in.bellnexxia.net...domain server (64.41.189.214) [OK] Type escape sequence to abort. Tracing the route to looking-glass.in.bellnexxia.net (205.207.237.50) 1 209.1.169.178 0 msec 0 msec 0 msec 2 bhr1-ge-2-0.SantaClarasc8.cw.net (208.172.147.53) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) 0 msec 4 msec 0 msec 4 dcr1-loopback.NewYork.cw.net (206.24.194.99) 76 msec dcr2-loopback.NewYork.cw.net (206.24.194.100) 72 msec dcr1-loopback.NewYork.cw.net (206.24.194.99) 68 msec 5 agr1-so-0-0-0.NewYork.cw.net (206.24.207.50) 68 msec 72 msec 68 msec 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec 8 core1-newyork83-pos1-1.in.bellnexxia.net (206.108.103.193) 260 msec 332 msec 216 msec 9 core4-montreal02-pos6-3.in.bellnexxia.net (206.108.99.189) 196 msec 204 msec 200 msec 10 64.230.243.238 208 msec 296 msec 460 msec 11 core2-torontodc-pos3-1.in.bellnexxia.net (206.108.104.2) [AS 577] 432 msec 404 msec 404 msec 12 dis4-torontodc-Vlan82.in.bellnexxia.net (206.108.104.30) [AS 577] 400 msec 240 msec 440 msec 13 looking-glass.in.bellnexxia.net (205.207.237.50) [AS 577] 452 msec 236 msec 244 msec route-server.cw.net Anyone know whats up ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
other virus damages/costs.....(hello skynet.be ?)
], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] is infected with virus: Win32/[EMAIL PROTECTED] The mail was not delivered because it contained dangerous code. this is a copy of the e-mail header: RAV AntiVirus for Linux i386 version: 8.4.2 (snapshot-20030212) Scan engine 8.11 for i386. Last update: Mon, 02 Feb 2004 04:36:04 +01 Scanning for 89407 malwares (viruses, trojans and worms). Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Did Wanadoo, French ISP, block access to SCO?
At 03:52 PM 01/02/2004, Sean Donelan wrote: EWeek is reporting an anonymous source that Wanadoo, a major French ISP, has stopped all traffic to SCO's web site? Is this true? Dont know Have any other ISPs taken similar action? Not here. The only thing different I did was ndc querylog tail -f /var/log/daemon | grep www.sco.com on my recursive servers and I have been underwhelmed by the output ---Mike
Re: Impending (mydoom) DOS attack
Are there any reliable estimates as to the amount of infected hosts out there? Looking at my stats for email sent this week, I am seeing a 70:1 ratio for mydoom.a as compared to Swen.a (the next most prevalent virus). Perhaps if we had some rough #s to work with we could start to approximate the range of traffic volumes we might see. ---Mike At 07:17 PM 30/01/2004, Leo Bicknell wrote: Having looked for some information to educate myself and my employer, I will say a weakness right now is that there is limited info about this worm. I have yet to see any good information on how effective the attack might be, or what some basic prevention steps (eg filtering) might do to the worm. Backbones don't often have people that disassemble worms. It would be nice to find some way for the anti-virus companies to share more details quicker with various backbones in order to effectively combat the DDOS portion of worms. If anyone has any good analysis on the current worm (other than it attacks www.sco.com), that would be welcome. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: in case nobody else noticed it, there was a mail worm released today
We are seeing 2 wide spread worms right now, mydoom and dumaru.* NAI has info at http://vil.nai.com/vil/content/v_100983.htm and http://vil.nai.com/vil/content/v_100980.htm They rate of it is quite surprising. By the description, the trick / method of infection does not seem all that different than past worms viri. Makes me wonder how many people in a room would reach into their purse/pocket on hearing, Wallet inspector ---Mike At 08:52 PM 26/01/2004, Paul Vixie wrote: my copies (500 or so, before i filtered) are in a ~7MB gzip'd mailbox file called http://sa.vix.com/~vixie/mailworm.mbox.gz (plz don't fetch that unless you need it for comparison or analysis). there's a high degree of splay in the smtp/tcp peer address, and the sender is prepared to try backup MX's if the primary rejects it, though it appears to try the MX's in priority order.
Anyone from AS 577 (BellNexxia) around ?
I asked through regular channels, but no one knew the answer. You used to have a looking glass at http://looking-glass.in.bellnexxia.net:8080/ but its been offline for a while. Did it move ? Is it gone for good ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Anyone from AS 577 (BellNexxia) around ?
Having dealt with them for some time, the public interfaces to the Bell object have not really changed one way or another. This is from my perspective as a consumer of Bell wholesale services... The same main help desks are there-- AOC, INOC, DSSC. Despite the host name being bell nexxia it is/was for AS577 which is Bell Canada proper. ---Mike At 10:42 PM 19/12/2003, Gordon Cook wrote: the mirror may be gone because, according to Francois menard, bell nexxia was disbanded by bell canada in april or may 2003 and absorbed back into bell canada's operations I asked through regular channels, but no one knew the answer. You used to have a looking glass at http://looking-glass.in.bellnexxia.net:8080/ but its been offline for a while. Did it move ? Is it gone for good ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike -- = The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info prices at http://cookreport.com/subscriptions.shtml Googin on real time global corp. http://cookreport.com/12.11.shtml Purchase 10 years of back issues at http://www.cafeshops.com/cookreportinter.6936314 E-mail [EMAIL PROTECTED] or use [EMAIL PROTECTED] Free World Dial up 17318 =
new nasty email virus trick to bypass scanners
OK, here is a nasty virus trick. The message gets sent in a password protected zip file. The text of the messages says here are my pics and enter in the passwd to view the archive. The big problem is that normal avscanners cannot open the zip file to scan the contents since it is password protected. However, the user can be easily socially engineered to open the file and blam. The text of the message is nice and enticing making it look like private email with dirty pictures accidentally sent to the user... ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: new nasty email virus trick to bypass scanners
At 05:52 PM 03/12/2003, J. Oquendoy wrote: Hell it would have been nice for MS to invest in creating safer products as opposed to paying `bounty hunters'. This is a total social engineering issue... Not much different than the wallet inspector asking to check your wallet. More clever, but the same thing in the end. ---Mike
Re: new nasty email virus trick to bypass scanners
At 09:53 PM 03/12/2003, Jamie Reid wrote: If an attacker can convince a user to do anything, all bets are off. It is conceptually similar to using SSL to evade a network IDS. This is also an intrusion test trick. As system owners, there is only so much we can do to prevent and detect compromises. What matters is how we respond. True enough. However, we also have to protect naive and vulnerable users to some degree. Think about elderly folk. They are not necessarily as quick to spot the scam. The ability to stop the virus before it gets to them is important. The other thing that worries me is that those who rely on their ISP to scan for viruses, a false sense of security can come into play. In the case of these types of email viruses, the user might think the file is OK because it was scanned. ---Mike
Re: new nasty email virus trick to bypass scanners
NAI has it as well now http://vil.nai.com/vil/content/v_100856.htm ---Mike At 10:20 PM 03/12/2003, Damian Gerow wrote: On Wed, 3 Dec 2003, Steven M. Bellovin wrote: Is this in the wild yet? Any other details worth looking for? Symantec's AV site apparently has nothing on it. I would say so - I got it in my inbox earlier this afternoon, and I traditionally get about three viruses a month. The virus itself is *exactly* like Mmimail.M, as reported by Symantec. Except that wendy.zip was definitely password protected. - Damian
Re: Check your AS: Renesys Blackout Report Released
On page 9, table 1 you list Allstream as being was Bell Canada. They were the network formerly known as ATT Canada. ---Mike At 02:16 PM 24/11/2003, [EMAIL PROTECTED] wrote: Folx, Hot off the presses, from the people who brought you the excellent (and fun!) reports on the effects of worms on routing instabilities, how the Internet fared on Sept 11, 2001, and other fine topics of interest to the operator community, comes a new report: Impact of the 2003 Blackouts on Internet Communications available now at: http://www.renesys.com/news/index.html a href=http://www.renesys.com/news/index.html;here/a It is an attempt to do a thorough, retrospective analysis of the impact of the power outages from a purely routing perspective. We tried to be quite rigorous in our methodology and careful in our inferences. However, we came to what may be an unpopular conclusion: the Internet fared worse than others have previously reported. The main difference in our conclusions lies in different measurement strategies (core to core layer 3-4 monitoring versus global BGP routing monitoring). Read the paper for more information. We also hoped to produce a definitive analysis of the network (routing, BGP) impact of the power outages so that others can compare future events. We're particularly interested in feedback from operators with assets in the affected regions of the US, Canada and Italy (see Appendix B for a good comparison of the Sept 28 Italy Blackout with the Aug 14 US Blackout). A few specific ASes are mentioned in the report. We would love to hear feedback from those ASes or others who were affected to learn more about the backstory behind the outage. If your prefixes stayed up, why? If some went down and some didn't, what caused that? Did your upstreams and peers stay up? Were local power outages at routers the primary cause of outages, or did other factors enter into the equation? We saw one AS with nine (9!) upstream ASes lose all of it's prefixes. Could it be that someone with 9 upstream adjacencies didn't have reliable power? These questions, plus a general discussion of Internet edge reliability (power and interconnectedness) seem on-topic for the list. Of course, we read nanog :-), so we'd love to see those stories discussed here in a context that would help all of us understand the causes and mitigation strategies better, but private mail will also be gratefully accepted. If you don't ever want us to mention your name in public, be sure to let us know. Todd Underwood [EMAIL PROTECTED]
Re: Increase in traffic to/from DSL subs since August?
At 04:28 PM 20/11/2003, Steven M. Bellovin wrote: At the IETF Plenary, Bernard Aboba showed a graph of spam, with a marked uptick since SoBig.F in August. My guess is worm-deposited spam relays, though Joel's guess of Nachi or Welchia can't be ruled out, either, without flow data. I would say all of the above, plus the normal back from summer holidays, weather is getting worse, lets go on-line instead phenomena, and there is now more to do online including cool higher bandwidth net content all add to higher usage. But I would certainly say worm traffic is a big one. ---Mike
cooling systems
Faced with the prospect once again of significantly higher energy prices coming to our region, we want to start to look at better and more efficient ways to cool our colocation facility. Right now we have several ton of traditional air conditioning units sucking up electricity like its free. As winter is approaching, surely there must be some computer safe way to take advantage of all that cold outside to help contain our energy costs, not to mention be a little more environmentally friendly. We were thinking we could circulate the air up to the roof and cool it there inside some aluminum ducts and then bring it back down. We dont want to just bring in cold air as it is quite dirty outside since we are next to a major highway. Anyone done anything like this before in a computer room setting ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Next hop issues inside AS852 ?
Anyone seeing any problems getting to AS852 ? I think the problem is coming back, as I can throw packets out to them and they seem to come back fine via 6539. However, going out and coming back via 852 seems to be hosed for me. (AS11647) From their routeserver, route-views.onshow ip bgp 64.236.16.52 BGP routing table entry for 64.236.16.0/20, version 1861266639 Paths: (2 available, best #2) Advertised to non peer-group peers: 198.32.162.100 198.32.162.102 1668 5662 154.11.0.195 from 154.11.0.151 (154.11.0.151) Origin IGP, metric 1119, localpref 180, valid, internal Originator: 154.11.0.195, Cluster list: 154.11.0.151, 154.11.0.222 1668 5662 154.11.0.195 from 154.11.0.150 (154.11.0.150) Origin IGP, metric 1119, localpref 180, valid, internal, best Originator: 154.11.0.195, Cluster list: 154.11.0.150, 154.11.0.222 route-views.on route-views.ontraceroute www.cnn.com Translating www.cnn.com...domain server (209.115.142.1) [OK] Type escape sequence to abort. Tracing the route to cnn.com (64.236.16.52) 1 toroonxngr00.bb.telus.com (154.11.63.85) 4 msec 0 msec 0 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Next hop issues inside AS852 ? (resolved)
Thanks to those who replied with info. The Telus folks contacted me not too long ago and corrected an ACL inside their network. ---Mike At 10:46 AM 21/10/2003, Mike Tancsa wrote: Anyone seeing any problems getting to AS852 ? I think the problem is coming back, as I can throw packets out to them and they seem to come back fine via 6539. However, going out and coming back via 852 seems to be hosed for me. (AS11647) From their routeserver, route-views.onshow ip bgp 64.236.16.52 BGP routing table entry for 64.236.16.0/20, version 1861266639 Paths: (2 available, best #2) Advertised to non peer-group peers: 198.32.162.100 198.32.162.102 1668 5662 154.11.0.195 from 154.11.0.151 (154.11.0.151) Origin IGP, metric 1119, localpref 180, valid, internal Originator: 154.11.0.195, Cluster list: 154.11.0.151, 154.11.0.222 1668 5662 154.11.0.195 from 154.11.0.150 (154.11.0.150) Origin IGP, metric 1119, localpref 180, valid, internal, best Originator: 154.11.0.195, Cluster list: 154.11.0.150, 154.11.0.222 route-views.on route-views.ontraceroute www.cnn.com Translating www.cnn.com...domain server (209.115.142.1) [OK] Type escape sequence to abort. Tracing the route to cnn.com (64.236.16.52) 1 toroonxngr00.bb.telus.com (154.11.63.85) 4 msec 0 msec 0 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
Wow, this sounds like a pretty extreme shotgun approach. (or is it April 1st somewhere). Is ATT going to make this whitelist publicly available ? Perhaps if there was some global white list that everyone could consult against, it might be a little more useable. Still, what do you do about multi-stage relays ? ---Mike At 05:24 PM 21/10/2003, Jeff Wasilko wrote: - Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message -
Re: New mail blocks result of Ralsky's latest attacks?
Cant speak for others, but the server that was blocked for us by Yahoo! is ACL'd by IP address. It would be very helpful if the Yahoo! folk could post an official explanation as to what happened so we can pass it on to our customers. e.g. a URL somewhere on Yahoo! ? ---Mike At 10:59 AM 10/10/2003, Bob German wrote: A colleague informed me this morning that Alan Ralsky is doing widespread bruteforce attacks on SMTP AUTH, and they are succeeding, mainly because it's quick, painless (for him), and servers and IDS signatures don't generally offer protection against them. Could this be why everyone's locking up their mail servers all of a sudden? Does anyone know of a way to stop them? Bob
Re: New attack against port 135?
Yes, we saw this yesterday and posted to full-disclosure. Here is a sample packet. 13:43:38.511675 xx:xx:xx:xx:xx:xx xx:xx:xx:xx:xx:xx 0800 62: 64.7.nn.yy.3512 16.181.zz.aa.135: S [tcp sum ok] 3772716186:3772716186(0) win 65340 mss 1452,nop,nop,sackOK (DF) (ttl 127, id 63248, len 48) 0x 4500 0030 f710 4000 7f06 e5d6 4007 975b[EMAIL PROTECTED]@..[ 0x0010 10b5 36c9 0db8 0087 e0df 149a ..6. 0x0020 7002 ff3c 6151 0204 05ac 0101 0402p..aQ.. ---Mike At 01:26 PM 10/10/2003, Peter John Hill wrote: I am seeing lots of scanning of port 135 on my network. 66 byte long packets. Anyone have a name for this? It is less aggressive than the welchia scans I have seen. Seems to scan at about 3000 or so flows per 5 minutes. Thanks Peter Hill Network Engineer Carnegie Mellon
Re: Wired mag article on spammers playing traceroute games with trojaned boxes
Looks like attachments wont go through, so I will repost without the attachment. If anyone wants a copy, let me know ---Mike At 01:28 PM 09/10/2003, Andy Ellifson wrote: Oops... Try this again... And as soon as you call law enforcement what happends? The spammer is located offshore. Then what? Actually, in the case of the wired article (removeform.com), it seems to be connected to a site in Florida. I asked my programmer ([EMAIL PROTECTED]) to decode the obfuscated java script/page that is served up by one of the zombies (On FreeBSD fetch -B 18192 -o danger.html http://www.removeform.com/d - I got it from 207.5.215.72 at the time). I have attached it as a zip file with its contents. You will note that the form post goes back to form action=http://207.36.47.68/cgi-bin/addinfo.cgi; OrgName:CyberGate, Inc. OrgID: CYBG Address:3250 W. Commercial Blvd. Suite 200 City: Ft. Lauderdale StateProv: FL PostalCode: 33309 Country:US ---Mike --- Hank Nussbacher [EMAIL PROTECTED] wrote: On Thu, 9 Oct 2003, Suresh Ramasubramanian wrote: * Follow the money - find out the spammer / the guy who he spams for, from payment information etc.Sic law enforcement on them. srs I think we can all safely assume that the people behind this are most probably on NANOG or reading the archives and are now aware of your idea :-) -Hank
Re: Wired mag article on spammers playing traceroute games with trojaned boxes
At 03:42 PM 09/10/2003, [EMAIL PROTECTED] wrote: On Thu, 09 Oct 2003 12:01:35 EDT, McBurnett, Jim [EMAIL PROTECTED] said: Can Broadband ISP's require a Linksys, dlink or other broadband router without too many problems? So now instead of a misconfigured PC, you're going to have a misconfigured router front-ending a misconfigured PC? PCs of the MS variety by default are misconfigured and dangerous out of the box. (i.e. they dont have their patches installed and have questionable defaults). Routers of the soho variety generally are not. No its NOT perfect, but I would gladly take b) over a) any day of the week. ---Mike
Re: Sitefinder fan - this guy needs a clue.
Amazing what different context the commentary would be placed in if ZDNET changed By Mark McLaughlin CNET News.com October 7, 2003, 7:10 AM PT to By Mark McLaughlin Senior VP, VeriSign October 7, 2003, 7:10 AM PT Because thats who he is. I realize its marked commentary but it should be more clear that the commentary is coming from the company in question. ---Mike At 10:52 AM 08/10/2003, Robert Boyle wrote: Wow. This guy is completely delusional. http://zdnet.com.com/2100-1107_2-5087746.html I have been up for 24 hours working on a router upgrade and a simultaneous DS3 problem so I'm in no frame of mind to respond. Perhaps one of the more eloquent (and less tired) folks here can politely beat this guy with a clue stick. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Good will, like a good name, is got by many actions, and lost by one. - Francis Jeffrey
Re: Sitefinder fan - this guy needs a clue.
At 01:52 PM 08/10/2003, Patrick W. Gilmore wrote: -- On Wednesday, October 8, 2003 11:07 -0400 -- Mike Tancsa [EMAIL PROTECTED] supposedly wrote: Amazing what different context the commentary would be placed in if ZDNET changed By Mark McLaughlin CNET News.com October 7, 2003, 7:10 AM PT to By Mark McLaughlin Senior VP, VeriSign October 7, 2003, 7:10 AM PT Because that's who he is. I realize its marked commentary but it should be more clear that the commentary is coming from the company in question. True, and I completely agree. However, the bottom of the article says: This was added by ZDNET later in the day after someone complained. Originally, it was not there. ---Mike
Re: News coverage, Verisign etc.
At 03:06 PM 08/10/2003, [EMAIL PROTECTED] wrote: In these days of corporate malfeasance scandal coverage, you'd think that Verisign's tactics would have whetted the appetite of some bright investigative reporter for one of the major publications. Too difficult and obscure a topic to make interesting. Its even worse than the SL scandal of the 80s. Things like ice statues pissing vodka at private million dollar parties are easy to cover in that a picture says it all There is no easy way to convey this issue to the general public in just a few words and at the same time not put them to sleep ---Mike On Wed, 8 Oct 2003, Howard C. Berkowitz wrote: I have gotten a reasoned response from the technology editor of the Washington Post, and we are discussing things. While I wouldn't have done it that way, he had a rational explanation of why the story was written the way it was, and definitely indicating there will be continuing coverage of the issue. He believes there's always room for improving coverage. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Verisign's public opinion play
At 05:55 PM 07/10/2003, Declan McCullagh wrote: On Mon, Oct 06, 2003 at 11:41:14PM -0400, Mike Tancsa wrote: http://news.com.com/2100-1038_3-5087139.html?tag=nefd_top The article makes me wonder if CNET is the press, or an outlet for press releases. The Internet community is almost uniform in expressing outrage for numerous REAL reasons, yet CNET says its from the Internet's technical old guard Sorry, so where is the new guard calling for Verisign to come back with sitefinder ? Also CNET leaves un challenged the 'excuse of the day' that Verisign without site finder will not be able to protect the Net's critical infrastructure... We've been covering the impact of SiteFinder since September 16. I didn't write that article (I was in transit from a conference in Canada) but I've written about five articles on SiteFinder so far, and I'll probably write another today based on the ICANN committee meeting. Hi, I think *your* articles are well done and are researched. However, I stand by my original criticism that this particular article was merely reporting one perspective on the issue in such as way as to make it appear as if it were a conduit for Verisign PR IMHO. The old guard label is a loaded term and smacks of judgement by your writer. Not quite calling it a fringe group or special interest group yet old guard vs the network operators who run the Internet certainly have different connotations. Similarly, this repeating of Verisign claim as fact that its a minority of people who disagree with sitefinder and how it was launched is particularly maddening. Sorry, is there some alt NANOG group out there secretly saying that gee, this site finder is great! Why didnt they do it before? Or perhaps on a-slashdot, or a-IAB ? I hope you continue to read News.com. I will continue to read your articles but in general my estimate of news.com has dropped significantly. ---Mike
Re: Verisign's public opinion play
The one that pisses me off more is http://news.com.com/2100-1038_3-5087139.html?tag=nefd_top The article makes me wonder if CNET is the press, or an outlet for press releases. The Internet community is almost uniform in expressing outrage for numerous REAL reasons, yet CNET says its from the Internet's technical old guard Sorry, so where is the new guard calling for Verisign to come back with sitefinder ? Also CNET leaves un challenged the 'excuse of the day' that Verisign without site finder will not be able to protect the Net's critical infrastructure... ---Mike At 11:12 PM 06/10/2003, Kee Hinckley wrote: Take your blood pressure medicine before reading this one. http://news.com.com/2010-1071-5086769.html Apparently our objections stem from our lingering resentment over the commercial use of the internet. In case you're wondering who the author is, since neither the bio on the page or Verisign's site is helpful. Mark McLaughlin is a former lawyer who moved into Marketing and Biz Development (Caere, Gemplus, Signio and then Verisign payments). -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Does anyone think it was a good thing ? (was Re: VeriSign Capitulates
OK, so was ANYONE on NANOG happy with a) Verisign's site finder b) How they launched it Speak up on or off list. ---Mike At 04:14 PM 03/10/2003, George Bakos wrote: On Fri, 3 Oct 2003 09:59:49 -1000 (HST) Scott Weeks [EMAIL PROTECTED] wrote: VeriSign also angered the close-knit group of engineers and scientists who are familiar with the technology underpinning the Internet. They say that Site Finder undermines the worldwide Domain Name System, causing e-mail systems, spam-blocking technology and other applications to malfunction. VeriSign said the claims are overblown. There is no data to indicate the core operation of the domain name system or the stability of the Internet has been adversely affected, VeriSign's Galvin said. watta bunch of goobers! Would those goobers be Versign, or the close-knit group of engineers and scientists? g scott
Re: Another DNS blacklist is taken down
At 01:49 PM 29/09/2003, Jared Mauch wrote: On Mon, Sep 29, 2003 at 01:11:08PM -0400, Dan Armstrong wrote: Isn't that collateral damage issue enough to have angered hundreds of ISPs end users to the point of not necessarily organizing a DDoS, but ignoring it? I think it is far _more_ likely that the DDoS came from the innocent victims fighting back rather than the spammers. Presently I beg to differ. (I do encourage you to prove me wrong :) Especially in the case of SPAMHAUS, they were no XRBL. What networks were really listed as collateral damage ? I dont see how willtel was an innocent bystander either in the previous case. ---Mike
Re: Don't like it, order the ISPs to block it
I would be happy just to see ISPs live up to their own published AUP. The Internet would be a MUCH nicer place if this were the case. Why does the topic of AUP enforcement gravitate towards straw man discussions of totalitarian governments? Yeah, I am sure the North Korean ISP scene is no fun. But this is North America. If a company wines about the fact that they dont have a business plan that allows for the enforcement of their published rules (oh, it just costs too much money), they should not BS the public that they have such rules in the first place. If we want our industry to be self policing, and not policed by the public sector, we better start policing ourselves. ---Mike At 02:47 PM 29/09/2003, Sean Donelan wrote: Continuing the trend of holding ISPs morally responsible for all things, India's Computer Emergency Response Team ordered all ISPs in India to block a Yahoo bulletin board for promoting anti-national news and containing material against the government. http://www.wired.com/news/politics/0,1283,60628,00.html ISPs are not very good at fine grain control. In India the ISPs initially blocked access to all Yahoo discussion group servers. But I'm sure they will improve monitoring of the actions of their subscribers, to adapt the blocks. What's interesting is in order to block less, the ISPs will have to invade the privacy of their users' traffic more. Making the ISP the personal firewall for every user or country is an growing concept. Talk about cost shifting. Some countries are willing to pay for it (e.g. China), increasing the costs. The Internet may end up costing more than private point-to-point lines after ISPs install all the firewalls to implement all the personal controls desired by governments.
