Re: SMTP problems from *.ipt.aol.com
Suresh Ramasubramanian wrote: Sean Donelan [1/17/2004 9:20 AM] : True, but it appears AOL has cranked something up in the last couple of weeks or something is choking more often. If you look at various places where users like to gripe, you'll notice an uptick of queries and complaints on the subject. Maybe they finally rolled this out across the board? AOL has a lot of dialup IP space (two /10s I think). The ipt.* blocking dates back many years, I think the intercepter stuff does too. The recommendation from AOL to rDNS block ipt.* dates back several years, and is mentioned in the current postmaster's guide at AOL. Over the past several months I noticed we were getting a lot of ipt.* hits, and Hutzler later said that some of their blocks in (IIRC) Europe were apparently not working. Obviously, they just fixed it. We get virtually nothing but spam from rly.* too, so, we're blocking it now. Hutzler remarked you won't miss much, but I wouldn't take that as an official pronouncement. We get a handful of FPs on it per month, and we tell them to use the proper smarthosting.
Re: Extreme spam testing
Robin Lynn Frank wrote: This is not the only list where this is occurring. It has been happening on the spamtools list, as well. We've now dropped them at the firewall. No loss to us. It's worth commenting: Triggering relay testing can occur in a number of different ways. Some simply scan all IPs. Some scan particular ranges. Some scan an IP when they receive email from it. RR and AOL do this amongst biggies. Some scan an IP when they receive suspicious/spam email from a given IP. We've done this from time to time. MANY other sites do this. Many consider scanning to be abusive in and of itself, however, there is a considerable amount of agreement that scanning with email in hand, or, more stringently, scanning with spam in hand is perfectly justified, as in sending me email gives implicit permission to check that you're secure, or, sending me spam gives permission to check that you're secure respectively. [Some people say if they've sent you spam, why test? Simply blacklist!. Which is silly, because you end up blacklisting everyone sooner or later. By testing and not listing on a negative result, you have less chance of blocking a legitimate site.] As another dimension, some people prefer to do very aggressive scanning - they'll test every combination of tricks that has been known to bypass anti-relay. Others try to avoid tricks that are likely to cause grief to the testee (eg: avoiding double bounces). Don't assume that the testers are specifically targeting mailing lists. Chances are that a NJABL person is on the lists, and is doing a test if email or spam in hand. [I don't know what NJABL's testing criteria are.] In the scheme of things, such testing is relatively minor, even of the obnoxious bounce to postmaster variety. Tune your alarm system to ignore them. If you consider a dozen or two relay tests to be extreme, I'd hate to think of what you'd think of _some_ other forms of vulnerability testing... By blackholing the tester, you run a _significant_ risk of getting blacklisted, even if you don't relay or proxy. Some blacklists do that. [I don't think NJABL does, but others do.] Secondly, some of them use highly distributed testing. Like SORBS. You'll never get them all. The spamming problem really has gotten so bad that many reputable organizations feel they have no choice do test. It's a sign of the times. It's best to not get bent out of shape over it and adjust your processes to suit. NJABL is reasonably well regarded. It's best not to play games with it, otherwise, you may end up getting blocked by all of its users. We're not using NJABL, but it is one of the ones we'd consider if some of our current ones went down. Some medium to large sites _do_ use it. And don't expect a we want to be blocked so we can discourage the use of blacklists attitude to work anymore. From us, at best you'd get a whitelist entry. The spamming problem really _is_ that bad.
Re: Need Contact at RoadRunner
Tom (UnitedLayer) wrote: Frankly, I think that its pretty poor practice to block someone and not tell them, especially when contact information is clearly available everywhere. We've got e-mail, various phones, and INOC-DBA, so its not that hard to get ahold of us :) When you're introducing thousands of IP blocks per day, it's pretty hard to notify them all.
Re: Need Contact at RoadRunner
james wrote: : When you're introducing thousands of IP blocks per day, it's pretty hard : to notify them all. I may be reaching here but I think perl scripting can do this. I wish. I've been experimenting with doing exactly that for years. Problems: - WHOIS data is often incomplete, wrong, or deliberately misleading. Heck, I see legitimate IP space which simply isn't registered _anywhere_. - there is no standard way to indicate notification addresses - some use comments, many different potential field names. Why couldn't this have been standardized? - Inadequate delegation - Notifying too far down the chain The experiments I've done got to about 10% accuracy. But it's the 90% that are completely erroneous and potentially cause mailing entirely the wrong person. There's no way you can let one of these things run unattended. I have something running doing this - but the IP - email address database is compiled by hand. Coverage is abysmal - maybe 20% on good days for spam reports. Probably be 0% on reasonably clean IP ranges. abuse.net maintains a domain - abuse address database. It's the best data, _if_ the domain owner has registered. There is nothing analogous for IP addresses. Or even AS's. Man it would be nice if there was an IP or AS - notification address service out there (ie: by DNS, ala DNSBL TXT records).
Re: SPAM from own customers
Michel Renfer wrote: Hi All The topic Spam sent over infected or malconfigured enduser pc's will become an big issue. We saw Virus' sending Spam directly from the users pc, downloading the recipient list and the payload trough HTTP from the web. How will you deal with the problem, that one user can flood your SMTP Server with tousends of emails within 10-20 minutes? In addition to the other suggestions, scanning the CBL (cbl.abuseat.org) for your own IPs is useful from an operational standpoint to find open proxies and trojans. On a similar vein, detecting customer IPs trying to connect to 47.129.25.87 on port 25 (no legitimate email goes there) will give you similar intelligence, tho, it's not quite as definitive as a CBL listing. Most reliable if you exclude legitimate customer mail servers (bounced forged spam and virii) or correlate to the CBL. Couple either or both with an autodisconnect script like what Suresh suggested.
Re: RBLs in use
Suresh Ramasubramanian wrote: You need a fairly wide coverage of BLs. # Open proxies - http://opm.blitzed.org and http://proxies.blackholes.easynet.nl I would add the SORBS http and SORBS socks lists to this. # Open relays - http://www.ordb.org I'd add VISI to that too. # Dialup and DSL/cable dynamic IPs - http://dynablock.easynet.nl # Current spam sources - http://cbl.abuseat.org [strongly recommended] CBL tends to list only open proxies and spam trojans, but there's a few classic viri emitters (ie: Yaha) and a _very_ small number of grossly misconfigured mail servers in it too. All of which you want to know about anyway. What you can do is do zone downloads of the open relay/proxy/CBL lists above and correlate them to your own netblocks. _Very_ helpful in finding compromised systems. With dynablock, you may want to audit it for accuracy against your IP allocations. They're responsive to update requests. SBL/SPEWS identifies your spammers. But as Suresh says, be careful to interpret the SPEWS listings correctly, so you nail the spammer, not the collateral damage. There are a lot more DNSBLs, but the above ones are the most respected, important and useful for your purposes. XBL Spambag, for example, are too rabid to worry about. Anybody who uses them gets what they deserve.
Re: cooling systems
Peter Galbavy wrote: You foreigners are scary. As a UK resident, born in Oz many many years ago, I consider -10C to be very very cold. You know it's cold when you have to deal with diesel fuel in chunk form by shovel. (Well, actually, with a fork. It solidifies into a rather waxy/oozy gunk. In a previous life, I worked in a refinery lab, testing for fuel freezing points down to -100F/-80F amongst other fun things.).
Re: cooling systems
Eric Kuhnke wrote: For those who have never visited Fairbanks, there is a phenomena observed at -15C and lower known as square tire. The rubber in tires of parked vehicles will become stiff and freeze into position, making the vehicle impossible to move without destroying the tires. In Ottawa, there's usually a week's worth of -25C as a _high_ temperature for the day during the winter, and occasional dips below -40C. Square tire just means it goes thumpity for a few hundred yards. Rubber embrittlement is more a phenomena for the -70Cs (near -100F) and below. But if you have a tire get frozen into ice, that may be a different story... More intriguing is what has to be done at high arctic places (like little Ellesmere island, the northernmost mine in the world). Most of the vehicles are Toyota diesel pickups (winter weight fuel, you betcha!). They never shut the engines down. Except when they're indoors for an oil change.
Re: Hijacked IP space.
Ray Wong wrote: On Mon, Nov 03, 2003 at 04:47:44PM -0500, Chris Lewis wrote: The .224/24, on the other hand, it a real sewer. I'm starting to figure that, given the delays, there's been enough damage done that 204.89.224/24 will never be able to get off the blocking lists anyway, so perhaps I'll turn it back in afterall. *sigh* That's what I get for trying to find low-cost ISPs willing to announce portable space. As strange as this may seem, I still think there's hope since it's thoroughly covered by existing DNSBLs. A few POCs, and you should be able to get it delisted. Yes, there's local listings such as ours, but the number of local BLs that identify specific blocks in _advance_ of, say, SBL, should be relatively small. And we're quick to delist once we find out. But _first_, you have to get it disconnected from whose hijacking it now. There's no way you can get it delisted given it's _current_ metrics, not a chance.
Re: Hijacked IP space.
James Cowie wrote: On Mon, Nov 03, 2003 at 09:17:38PM +, Andrew - Supernews wrote: No announcement for that block has been visible here at any time in the past couple of weeks (specifically, since Oct 13). We might have missed it if it was never announced for more than a few minutes at a time, but it's _much_ more likely that the block was never announced and was merely forged into headers of a spam. Our system reports that neither that prefix, nor any of its more-specifics, has been seen in the global routing tables at any moment since January 1st, 2002. [ http://www.renesys.com ] We haven't seen anything from that block in our spamtrap either for at least a week. The .224/24, on the other hand, it a real sewer.
Re: more on VeriSign to revive redirect service
[EMAIL PROTECTED] wrote: On Thu, 16 Oct 2003 10:16:53 CDT, Andrew D Kirch [EMAIL PROTECTED] said: I would certainly say there's an elitism, or perhaps a higher level of credibility given to a .com or .net site, due to the fact that they've probably existed for quite a bit longer than a .biz or .info. Most of my spam points back to .com addresses. Not much credibility generated there... There's sufficient churn on the bottom-feeding .com's that it's not a reliable indicator. Now you want *stability*, look for a site that's got a .arpa other than in-addr.arpa :) On the other hand, in our spam filters, we have a content filter block on the string .biz followed by a slash (I'm spelling it out because I don't think I've whitelisted this list). It works surprisingly well. Out of several tens of thousands of blocks per week on that rule, we get, perhaps, 3 FP reports. Which is an acceptable level of FPs given the overall effectiveness. Most of them are resolved by advising the sender to not end http://foo.bar.biz site-level URLs with a slash.
Re: DDOS Today?
Hi, I hadn't noticed that this has something to do with us, until Dave Lugo pointed it out. I really don't know who has anything to do with IPV6 here, I suspect very much it's a product group's test block. Or something. I had forwarded a previous note about an IPV6 block with no longer valid WHOIS contact info to our people who interact with the registries for DNS and IP, but I don't know if it's the same block. Chances are that they're having almost as much trouble as you tracking down who is responsible for this block. I've forwarded a copy of this to some of the people I know in networking who may know about this or what to do with it. In the meantime, I strongly suggest that you call 1-800-684-4357 (our 7x24 support line) and enter a ticket. I'd do it for you, but I don't have your contact information, nor understand this issue well enough to describe it. That help line normally gets support calls from employees, and they'll expect an employee number. I'll email you my employee number directly, so you can give them an ID to tie it to if they insist. Greg Valente wrote: I just got on today. Was there any large DDOS attacks today. Any specific networks impacted? -Original Message- From: Jeroen Massar [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 8:16 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Reserved ASN 64702, 6to4, 2 ghosts, other oddities and still no working contacts... -BEGIN PGP SIGNED MESSAGE- Checking http://www.sixxs.net/tools/grh/lg/?show=bogonsfind=::/0 People might want to filter on private ASN's also when that ASN is being used as transit... 2001:a40::/32 AS64702 is reserved (path: 15516 3257 2497 4697 2914 10109 4538 4787 64702 20646 8763 5539 1930 9186) Ghost Route (14/12) 3ffe:3500::/24 3ffe:4005:fefe:: 25396 1752 10109 4538 4787 64702 20646 8319 We still have these 6to4 specifics btw: 2002:c2b1:d06e::/48 More specific 6to4 prefix (194.177.208.110/32) from AS5408 2002:c8a2::/33 More specific 6to4 prefix (200.162.0.0/17) from AS15180 2002:c8c6:4000::/34 More specific 6to4 prefix (200.198.64.0/18) from AS15180 2002:c8ca:7000::/36 More specific 6to4 prefix (200.202.112.0/20) from AS15180 And nopes, no contact has been made yet, apparently having your email address listed in the registry frees you of any obligations... Another funny one: 3ffe:3::/32 Subnet of 3ffe::/24 Mismatching origin ASN, should be 4555 (now: 29216) While there also is an announcement for: 2001:7fe::/32I-rootserver-net-20030916 The ghosts of this month: 3ffe:1f00::/24 3ffe:2400::/24 Both with 10318 5623 common in their paths, obvious isn't it ? Oh and yes, still no contact from anybody at nortel, apparently that company doesn't know what IPv6 is. AS10318 (check above also) is still announcing *their* block and still haven't made any comment or reply back whatsoever. AS10318 have their own pTLA but apparently are not contactable for that pTLA either. If anybody knows someone alive for 3ffe:1300::/24 or AS762 or AS10318 please notify them. Maybe posting to nanog raises some people from sleep. Mailing the whois contacts directly doesn't help apparently. Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP4dLximqKFIzPnwjEQKluACglQJ+2QtJZ6O2fJZShwxLe0Z6Fz8AnRym p0Clq/HyC9EoC/RsaYudqZey =XBo4 -END PGP SIGNATURE-
Re: Another DNS blacklist is taken down
Jack Bates wrote: Mark Segal wrote: I think some RBLs might get better responses from the ISPs when they stop taking collateral damage gets the abuse department's attention attitudes.. Some RBLs cause many providers a LOT of headaches, so it is not surprising that when it is their turn to complain, the ISPs will just say: post to abuse.ddos.isp.net and we might get around to fixing it. :). It's useful to be careful in how we define collateral damage here. Collateral damage can include, for example, non-spam email coming from a spammer's site. In this context, we're talking about _escalation_ of listings outside of the demonstrated spamming/abusive/insecure IPs. monkey's had no collateral damage issues until PHL was released due to non-response from ISP's. The PHL is the escalation. openrbl.org does not host a blacklist and thus cannot have collateral damage. SBL is famous for it's lack of collateral damage. SBL does escalation, but rarely. (WCG, Chinanet for example). ordb is specialized and has had no collateral damage issues. ORDB does not escalate. Has it been DDOS'd? Pointless, open relay blacklists are virtually useless these days. SPEWS escalates (obviously). The DDOS's have been against SPEWS, SBL and Monkeys. Most of the other targets were re-publishers/distributors of SPEWS (ie: SORBS, Osirus, openrbl.org). Each of the three are _very_ public targets and generate lots of chatter/discussion on NANAE. Monkeys of course has RFG behind it and all that denotes.
Re: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
Lewis, Chris [CAR:W669:EXCH] wrote: See cbl.abuseat.org. It's effectively a proxy DNSBL, and is more effective than any of the others. More effective than many of the more reasonable combo DNSBLs too. I should also mention that OPM and PSS (originally osirus's open socks proxy BL) are also quite good.
Re: 157.112.0.0/16 ARIN info updated, ATT still announcing /16
Richard Cox wrote: The other good news is that all those blocks have now been either returned to Aker Kvaerner Group (successors-in-title to Trafalgar House Group) or returned to ARIN for reuse, as appropriate. Any filters you routing people may have put in place to prevent abuse from those blocks can be - and, please, SHOULD be, removed as soon as practicable. The DNSBL entries for them at Spamhaus and SORBS have already been removed. As a FYI, that class B appears to have gone totally silent on the spamming front on the 9th of Sept or thereabouts. We were getting ~40 attempts per day from it. If anybody needs samples, contact me - quickly. We only retain it for about two weeks. Spams all referencing www.dnt.opt.listaudit.biz (resolves to 141.152.34.207, apparently Verizon, also blacklisted as being part of Empire Towers) It's still listed on SPEWS. I killed our manual blacklisting.
Re: dns.exe virus?
Christopher J. Wolff wrote: After tracking down what I believed was an attempted DOS attack, it turns out that two Windows 2000 servers, fully updated, were spewing out hundreds of port 53 requests. Upon further investigation dns.exe was hogging 99% of the CPU. I haven't found any reference to this at CERT so I thought I would drop the occurrence into the nanog funnel to see what comes out. The attack started around 8AM MST. Thank you for your consideration. I wonder if this is the tool used to attack Spamhaus, SPEWS and SORBS. Do you know what the requests were for?
Re: dns.exe virus?
Christopher J. Wolff wrote: Chris, It was really odd. Here is an example of what the two hosts .3 and .4 were up to. For grins, I ran that through our blacklist tool to see what it coughed up. Nothing was on our blacklists. Had rDNS's like *.google.com, *.akamai.com, sprintbbsd, ns2.granitecanyon.com, DNS root servers and a few non-resolving IPs. DNS resolution loop perchance?
Re: Automatic shutdown of infected network connections
Sean Donelan wrote: How many ISPs disconnect infected computers from the network? Do you leave them connected because they are paying customers, and how else could they download the patch from microsoft? As an aside: As a corporation (no customers per-se), we disconnect infected computers _completely_ (via remote router/switch control tools). We can do it automatically (via various detectors), but usually do it manually. This is primarily to maintain service levels with non-infected stuff. Fixing the computer is usually done by support staff. Via CD if it's unsafe to reconnect the machine to the net. If we get infested bad enough, we block the attack ports subnet-by-subnet as necessary until we've sterilized the subnet.
Re: East Coast outage?
[EMAIL PROTECTED] wrote: I am a little rusty on this one, but I seem to remember that AC travels only on the outside skin of the wire but DC uses all the wire. Skin effect is only significant at high frequencies (lots of megahertz and up). At 60hz it can be ignored.
Re: East Coast outage?
David Lesher wrote: True, and it's done. There are two very large DC lines in use: The Pacific Intertie, from Washington State down to Califunny A line from the Great Frozen North down to Minnesota. IIUC, after the ice storm's enormous damage Hydro Quebec replaced their interconnects with the rest of the grid (primarily New York and Ontario) with a DC buffer. Made it much easier for them to disconnect without harm from the melt-down. They're already exporting power to both New York and Ontario to help them get back up.
Re: East Coast outage?
Chris Adams wrote: Basic physics. To run DC at the power levels required, the wire would have to be over 100 feet in diameter IIRC. Look up the Edison vs. Tesla power arguments for all kinds of information on AC vs. DC. This was under the assumption that the transmission line was at the same voltage as the end-user, because there were no good DC-DC voltage converters in that day. And a few bazillion amps at 120V needs a really fat wire. There's no significant wire size difference between a DC and AC line at the same ampacity. Voltage conversion is the key. _If_ you can do it, then transmission isn't a problem.
Re: Potential downside to using (very) old domain as spam trap.
Paul Vixie wrote: therefore before you use whole-domain spamtrapping, i recommend looking VERY carefully at the flows so that you can be sure that i isn't adjacent to o on the qwerty keyboard, or some other such problem. Agreed. But I'll mention a situation where it's very valuable and show some of the pitfalls found thru intimate experience with doing it. We decommissioned some of our domains about 3 years ago, as we transitioned to our current one. At the time that these domains were decommissioned (de-MX'd), we were catching and tossing 60,000-70,000 spams per day. 18 months later, as an experiment, I re-enabled the domains. First day: 600,000 spams per day. In the months since then it has grown to 2.5 million per day. We use this as a spamtrap. The immediate temptation is to directly feed blacklists of some sort. But: 1) A significant fraction (varies from 5-30%) is NDRs from innocent sites for spam forged with return addresses in our spamtrap. [If [EMAIL PROTECTED] is being spammed, chances are that it's being forged in spam too.] 2) A significant fraction is virus/worm attacks from people with very old addresses in their address books. 3) A significant fraction is email from otherwise legitimate sites who have a spam problem (so at least you have to ratio traffic levels between spamtrap and non-spamtrap). Case in point: MSN's DAV servers while they were scriptable (the ratios were absurdly bad (like 5000:1), we did end up blacklisting the DAV sites on-and-off over the past 3 months or so). 4) There is a growing fraction that turn out to be RCPT TO verifications from sendmail configurations (of spam forged with spamtrap domain names). I think this is dangerous (tripping harvesting detectors for example), but, it's a fairly effective heuristic in its own right. 5) There are a significant fraction of autoresponders responding to forged spam. While much of this is detectable and you can remove it from the analysis, you generally need to apply additional heuristics beyond just the spamtrap. We try to filter out bounces/viri, compute ratios of bad:good and look for verifications via other third party blacklists that we're unwilling or unable to use directly. It's also fodder for additional analysis that detects open relays, proxies and trojaned boxes.
Re: Cisco vulnerability and dangerous filtering techniques
Austad, Jay wrote: I was thinking about this the other day. The most efficient way to make this work would be to spread using some vulnerability (like the Microsoft DCOM vulnerability released last week), and then at a predetermined time, start DoS'ing routers in the IP space of major providers, and then work your way towards the edges. You can pretty much safely assume that most of your infected machines are going to basically be on the edges of the internet, so if you start with major providers, you won't kill all of your connectivity. Even more destructive would be p2p built into it, so all of the infected hosts could coordinate before the attack on what networks each one would handle. Imagine generalizing that to phases - build a virus that uses several different modes of propagation to different platforms - virulent, but not too violent (ie: not like SQL slammer), then phase it to DOS various services, including the routers. You might come in one morning to find your entire network infested with a multi-phasic virus which has destroyed whatever it could, DDOS'd everything it couldn't, and big chunks of your network are dead. On multiple platforms simultaneously. You're in a mode where everything has to be unplugged, and scrubbed before reconnecting. Ugh. SQL slammer was inadvertently almost there. We're not an SQL shop, but a few machines here and there had it enabled for one reason or another. The propagation flood itself was so violent it took out non-Windows services.
