RE: SORBS?!
That's just not true, we would much rather be notified of something that a reputation list finds objectionable and take it down ourselves than have Senderbase set a poor reputation on dozens of IaaS customers. -Drew -Original Message- From: goe...@anime.net [mailto:goe...@anime.net] Sent: Thursday, April 05, 2012 12:48 PM To: Drew Weaver Cc: 'Sam Oduor'; Chris Conn; nanog@nanog.org Subject: RE: SORBS?! This is often the only way to get peoples attention and get action. Providers dont care about individual /32's and will let them sit around and spew nigerian scams and pill spams without any consequences. But they will care about a /24. -Dan On Thu, 5 Apr 2012, Drew Weaver wrote: Now, if we could only teach Senderbase that if their customers receive 'questionable' smtp traffic from 1 IP address in a /24 it doesn't mean that all IP addresses in that /24 are malicious we'd really be living it up in 2012. -Original Message- From: Sam Oduor [mailto:sam.od...@gmail.com] Sent: Thursday, April 05, 2012 7:56 AM To: Chris Conn Cc: nanog@nanog.org Subject: Re: SORBS?! Some of the IP's I manage got blacklisted and its true they were spamming and Sorbs had a very valid reason for blacklisting them. I got this response response from sorbs after resolving the problem amicably. Sorbs responded well on time. *Your request appear to have been resolved. If you have any further questions or concerns, please respond to this message. Please note: If your IP address has been delisted (marked as 'Inactive'), it will take up to 2 hours to get from the database to all the SORBS DNS servers. Changes to the database are exported to the DNS zone files periodically, not immediately after every change. Furthermore, after the updated database contents have been exported to the DNS zone files, it will then take up to 48 hours for the outdated DNS information to be removed from DNS caches around the world - none of these are in SORBS' control. Please do not reply to this call with problems not related to this ticket or your request will be ignored. * *On Wed, Apr 4, 2012 at 10:53 PM, Chris Conn cc...@b2b2c.ca wrote: * *Hello, Is anyone from SORBS still listening? We have a few IP addresses here and there that are listed, one in particular that has been for a spam incident from over a year ago. The last spam date is 03/05/2011 according to their lookup tools.* * We don't have access to their Net Manager even if our ARIN POC corresponds to the account on their system we opened a while ago. We use their ISP feedback form and never get any responses back.* * Is SORBS still relevant and functional?* * Sincerely,* Chris Conn B2B2C.ca -- Samson Oduor
AUTO : Vincent FERRAN-LACOME est absent(e). (retour 16/04/2012)
Je suis absent(e) du bureau jusqu'au 16/04/2012 Je suis absent pour le moment. En cas de nécessité, merci de transmettre vos messages à l'équipe CSIRT: cs...@bnpparibas.com +33 1 40 14 26 95 (office hours UTC +1/+2) -- I am currently out of office. If necessary, please forward your messages to the CSIRT team: cs...@bnpparibas.com +33 1 40 14 26 95 (office hours UTC +1/+2) Remarque : ceci est une réponse automatique à votre message NANOG Digest, Vol 51, Issue 11 envoyé le 6/4/12 13:31:56. C'est la seule notification que vous recevrez pendant l'absence de cette personne. This message and any attachments (the message) is intended solely for the intended addressees and is confidential. If you receive this message in error,or are not the intended recipient(s), please delete it and any copies from your systems and immediately notify the sender. Any unauthorized view, use that does not comply with its purpose, dissemination or disclosure, either whole or partial, is prohibited. Since the internet cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS (and its subsidiaries) shall not be liable for the message if modified, changed or falsified. Do not print this message unless it is necessary,consider the environment. -- Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur ou s'il ne vous est pas destine, merci de le detruire ainsi que toute copie de votre systeme et d'en avertir immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de ce message qui n'est pas conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer l'integrite de ce message electronique susceptible d'alteration, BNP Paribas (et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese ou il aurait ete modifie, deforme ou falsifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: SORBS?!
On Fri, 06 Apr 2012 07:31:47 -0400, Drew Weaver said: That's just not true, we would much rather be notified of something that a reputation list finds objectionable and take it down ourselves than have Senderbase set a poor reputation on dozens of IaaS customers. If it was industry-wide standard practice that just notifying a provider resulted in something being done, we'd not need things like Senderbase, which is after all basically a list of people who don't take action when notified... pgpaIuUCK0cKG.pgp Description: PGP signature
Re: Quad-A records in Network Solutions ?
On 4/5/12 1:26 PM, George B. wrote: How long did it take them? We have had a request in for records for a domain for over a week now, and nothing in whois yet. between a couple of hours and 5 to 10 business days. The long leads times came when I no longer had direct contacts and had to go through the helpdesk.
Re: SIP Carrier Consolidation
Thanks to all who responded off list even to those that are intrested in the opportunity, I do appreciate it. - Original Message - From: Daryl G. Jurbala da...@introspect.net To: Elijah Savage esav...@digitalrage.org Cc: Robert E. Seastrom r...@seastrom.com, NANOG list nanog@nanog.org Sent: Thursday, April 5, 2012 8:51:45 PM Subject: Re: SIP Carrier Consolidation I have to respond with the sentiments of Robert: large is a very relative term. Also, are we talking about origination or termination here? How many minutes a day of each? What's your ACD? What are your top destinations? If it's bursty like a call center how many concurrent calls? You can't get any real answers without providing relevant information. On Apr 5, 2012, at 2:09 PM, Elijah Savage wrote: Thank you for the reply. Yes an aggregator, large deployment. Initially this is discovery, though price is always important it is most about understanding operations and implementation at this point.
Re: SORBS?!
On 4/4/12 3:36 PM, Landon Stewart wrote: It's best to not complain about it and just accept it as a fact of life your IPs are listed on SORBS and move on. It's not the end of the world. It turns into a customer service issue for most service providers. Eh, guess they'll just have to absorb the cost of that, like its expected that the recipients of spam have to absorb the cost of ISPs not disconnecting infected/spamming customers... And like how I have to absorb the costs of spending my time during the day answering removal requests from people who lie to me constantly and hope that I don't notice their little games. Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: SORBS?!
On Apr 6, 2012, at 10:54 , Brielle Bruns wrote: On 4/4/12 3:36 PM, Landon Stewart wrote: It's best to not complain about it and just accept it as a fact of life your IPs are listed on SORBS and move on. It's not the end of the world. It turns into a customer service issue for most service providers. Eh, guess they'll just have to absorb the cost of that, like its expected that the recipients of spam have to absorb the cost of ISPs not disconnecting infected/spamming customers... And like how I have to absorb the costs of spending my time during the day answering removal requests from people who lie to me constantly and hope that I don't notice their little games. Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). Besides, anyone who knowingly causes harm to a third party and claims it is a cost of doing business or mostly people like it or our $FOO is targeted and almost always correct, you must be an outlier and that's why it costs you sound -exactly- like spammers to me. Spammer who are up-front about it I can deal with. Don't agree with or even like them, but at least we understand each other. Hypocrisy is a different story. -- TTFN, patrick
Re: SORBS?!
On 4/6/12 9:02 AM, Patrick W. Gilmore wrote: No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). Proxy removals and automated additions are self service removals. I don't trust automated removal for stuff that we add by hand. Too many variables, too much in the way of games... If I were to let the people in spam-sources request removal and handle removal entirely on their own without one of us reviewing it by hand, there'd be no entries left in my database. Besides, anyone who knowingly causes harm to a third party and claims it is a cost of doing business or mostly people like it or our $FOO is targeted and almost always correct, you must be an outlier and that's why it costs you sound -exactly- like spammers to me. I was more pointing out to people that you expect someone else, who you've got no contractual obligation with, or relationship with, to make time and effort to handle a request you made. All I hear these days from people is that I have no right to tell them who they can have as customers, or how to run their business. Well, the reverse applies as well. I take great offense to people telling me how to run my own service, that I provide free at no charge with no obligations. When a provider actually works with me to resolve an issue, I bend over backwards to help them. Unfortunately, those kinds of providers are few and far in between. Spammer who are up-front about it I can deal with. Don't agree with or even like them, but at least we understand each other. Hypocrisy is a different story. Unfortunately, the apathy of providers, backbones, and network operators in general have created an environment that the almighty buck rules everything. Yeah, I've had offers for financial support of the AHBL. Turned them down every time, even though it would give me a chance to hire actual people to run it.But, then, I'd have someone hanging over my shoulder, pulling strings and interfering with my project. My independence goes out the window, and I can't truly say I have no financial interest in the listings. So, forgive me if my independence as a non-commercial DNSbl makes me somewhat jaded towards people who expect me to prioritize their demands over what pays the bills. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: SORBS?!
This seems like a very 1999 anti-spam attitude. I have been doing anti-spam a long long time - literally since before Canter and Siegel (who I had as customers...) and before j...@cup.portal.com. It's not 1999 anymore. Patrick is not the enemy. Your attitude is worrying. The I am not responsible for who uses the blacklist or what that means isn't good enough anymore. George William Herbert Sent from my iPhone On Apr 6, 2012, at 8:37, Brielle Bruns br...@2mbit.com wrote: On 4/6/12 9:02 AM, Patrick W. Gilmore wrote: No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). Proxy removals and automated additions are self service removals. I don't trust automated removal for stuff that we add by hand. Too many variables, too much in the way of games... If I were to let the people in spam-sources request removal and handle removal entirely on their own without one of us reviewing it by hand, there'd be no entries left in my database. Besides, anyone who knowingly causes harm to a third party and claims it is a cost of doing business or mostly people like it or our $FOO is targeted and almost always correct, you must be an outlier and that's why it costs you sound -exactly- like spammers to me. I was more pointing out to people that you expect someone else, who you've got no contractual obligation with, or relationship with, to make time and effort to handle a request you made. All I hear these days from people is that I have no right to tell them who they can have as customers, or how to run their business. Well, the reverse applies as well. I take great offense to people telling me how to run my own service, that I provide free at no charge with no obligations. When a provider actually works with me to resolve an issue, I bend over backwards to help them. Unfortunately, those kinds of providers are few and far in between. Spammer who are up-front about it I can deal with. Don't agree with or even like them, but at least we understand each other. Hypocrisy is a different story. Unfortunately, the apathy of providers, backbones, and network operators in general have created an environment that the almighty buck rules everything. Yeah, I've had offers for financial support of the AHBL. Turned them down every time, even though it would give me a chance to hire actual people to run it.But, then, I'd have someone hanging over my shoulder, pulling strings and interfering with my project. My independence goes out the window, and I can't truly say I have no financial interest in the listings. So, forgive me if my independence as a non-commercial DNSbl makes me somewhat jaded towards people who expect me to prioritize their demands over what pays the bills. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: SORBS?!
On 4/6/12 9:49 AM, George Herbert wrote: This seems like a very 1999 anti-spam attitude. I have been doing anti-spam a long long time - literally since before Canter and Siegel (who I had as customers...) and befor...@cup.portal.com. It's not 1999 anymore. Patrick is not the enemy. Your attitude is worrying. The I am not responsible for who uses the blacklist or what that means isn't good enough anymore. I know he's not the enemy. Hate the idea that he would be. The only reason why I responded the way I did, was because I sit here, watching everyone talk about how SORBS is bad this, how they are bad that, how they need to change this, and how they need to change how they operate to their guidelines, not SORBS's guidelines. Its not directed at Patrick. I just got the feeling like he was saying its okay for these people to dictate how SORBS operates. Like its been said, DNSbl's have a right to run as they see fit, and handle removals as they see fit. Just like every ISP has the right to run their network as they see fit, and refuse to remove spamming customers and deal with network abuse. I've been working on variations of the AHBL since 1998 or so under different names, so if I seem 'old school' in my beliefs how the DNSbl is run, that's probably why. Reality is, people use a DNSbl how they see fit. I can't really control that without restricting access, requiring payments or registration, etc. I gave up years ago trying to tell people how not to use it, since noone actually listens. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: SORBS?!
On 4/6/12 10:02 AM, Michael Thomas wrote: I wonder how long a popularish blacklist operator would last if they, oh say, blacklisted all of google or microsoft before they got some very threatening letters from their legal staff. An hour? A day? A week? You may have the right to list them and change your mind in your own good time, but they also have the right to defend their reputation civilly too. With great power comes great responsibility and all that. Slippery slope. For large providers who depend alot on spam filters, thats one huge door to open that could get very ugly very quick in the reverse path. Imagine every ISP suing hotmail and google for blocking messages for arbitrary reasons with no apparent justification. What's good for the goose is good for the gander. There's also USC 47,230 to contend with. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: SORBS?!
On Fri, 06 Apr 2012 09:55:35 -0400, Drew Weaver said: That is again, not true. Senderbase's listings don't correlate to any public information so it's pretty much impossible to pro-actively protect ourselves from having our IPs set to poor. You missed the point - if it was industry standard practice, reputation lists at Senderbase, Spamhaus, and SORBS would *all 3* be out of business, because the average spammer's lifespan at a provider would be less than the time it takes the average reputation list to put up an entry. pgpyOe35QJ6E1.pgp Description: PGP signature
Re: SORBS?!
On 04/06/2012 09:17 AM, Brielle Bruns wrote: On 4/6/12 10:02 AM, Michael Thomas wrote: I wonder how long a popularish blacklist operator would last if they, oh say, blacklisted all of google or microsoft before they got some very threatening letters from their legal staff. An hour? A day? A week? You may have the right to list them and change your mind in your own good time, but they also have the right to defend their reputation civilly too. With great power comes great responsibility and all that. Slippery slope. For large providers who depend alot on spam filters, thats one huge door to open that could get very ugly very quick in the reverse path. Imagine every ISP suing hotmail and google for blocking messages for arbitrary reasons with no apparent justification. What's good for the goose is good for the gander. There's also USC 47,230 to contend with. It's more of an arms race than a slippery slope, but my point is that a big enough company would absolutely respond if they felt a big enough blacklist was being capricious in a way that was affecting their making money. I sympathize with my blacklist, my donated time, my rules, but when you're affecting their business, you better get it right and better respond reasonably when the inevitable screwups happen. The one absolute right you have is to not be in the blacklist business (paid or not) at all. Beyond that, you have responsibilities too, and it would be best for everybody to not take them lightly causing the entire thing to get escalated to the legal domain where everybody most likely loses. Mike
Re: SORBS?!
On Fri, Apr 6, 2012 at 7:31 AM, Drew Weaver drew.wea...@thenap.com wrote: That's just not true, we would much rather be notified of something that a reputation list finds objectionable and take it down ourselves than have Senderbase set a poor reputation on dozens of IaaS customers. I think the idea is that you're supposed to proactively monitor your systems for abuse and generally make your network inhospitable to spammers, not just reactively move the customer to a new IP address when the unpaid anti-spammers kindly let you know you've been detected. Personally I see SORBS as the canary in the coal mine. Except for the DUHL (which identifies dynamic IPs, not spamming activity) nobody serious relies on SORBS' data. So, it doesn't much hurt when they list you. But, like the canary that dies first if the air turns bad, if you're careful to watch SORBS you know when you're headed for problems which will get you listed by a real RBL. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: SORBS?!
So you're suggesting that hosting companies do what? How many emails or port 25/587 connections a (day, week, hour) makes someone a spammer if there are no objections being lodged at the abuse department? Are we supposed to do DPI on every email that a dedicated server sends out and then decide whether it's spam? My point is if a list has a problem with a /32 they could have the courtesy to contact the ISP/host prior to causing huge problems for a /24 I'm not sure what more can be done than having an abuse department staffed up and checking all published data before accepting a customer. And I'm mostly just complaining about senderbase, because they seem to be the one that really large companies reference. Thanks, -Drew -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Friday, April 06, 2012 12:56 PM To: Drew Weaver Cc: nanog@nanog.org Subject: Re: SORBS?! On Fri, Apr 6, 2012 at 7:31 AM, Drew Weaver drew.wea...@thenap.com wrote: That's just not true, we would much rather be notified of something that a reputation list finds objectionable and take it down ourselves than have Senderbase set a poor reputation on dozens of IaaS customers. I think the idea is that you're supposed to proactively monitor your systems for abuse and generally make your network inhospitable to spammers, not just reactively move the customer to a new IP address when the unpaid anti-spammers kindly let you know you've been detected. Personally I see SORBS as the canary in the coal mine. Except for the DUHL (which identifies dynamic IPs, not spamming activity) nobody serious relies on SORBS' data. So, it doesn't much hurt when they list you. But, like the canary that dies first if the air turns bad, if you're careful to watch SORBS you know when you're headed for problems which will get you listed by a real RBL. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: SORBS?!
On 4/6/2012 12:35 PM, Michael Thomas wrote: On 04/06/2012 09:17 AM, Brielle Bruns wrote: On 4/6/12 10:02 AM, Michael Thomas wrote: I wonder how long a popularish blacklist operator would last if they, oh say, blacklisted all of google or microsoft before they got some very threatening letters from their legal staff. An hour? A day? A week? You may have the right to list them and change your mind in your own good time, but they also have the right to defend their reputation civilly too. With great power comes great responsibility and all that. Slippery slope. For large providers who depend alot on spam filters, thats one huge door to open that could get very ugly very quick in the reverse path. Imagine every ISP suing hotmail and google for blocking messages for arbitrary reasons with no apparent justification. What's good for the goose is good for the gander. There's also USC 47,230 to contend with. It's more of an arms race than a slippery slope, but my point is that a big enough company would absolutely respond if they felt a big enough blacklist was being capricious in a way that was affecting their making money. I sympathize with my blacklist, my donated time, my rules, but when you're affecting their business, you better get it right and better respond reasonably when the inevitable screwups happen. The one absolute right you have is to not be in the blacklist business (paid or not) at all. Beyond that, you have responsibilities too, and it would be best for everybody to not take them lightly causing the entire thing to get escalated to the legal domain where everybody most likely loses. What grounds would these large senders have to file any legal objections against an RBL? RBLs don't block emails. Operators of mail servers who use RBLs block emails (in part) based on information from RBLs. Noone has a right to send email to anyone else. Email is a cooperative agreement between sender and receiver. The receiver agrees to accept the email, but at any time and for any reason the receiver can stop agreeing to accept emails from a sender. It is completely legal to decide not to accept (i.e. block) emails from a sender. RBLs are not beholden to senders. RBLs are beholden to the receivers who use their RBL to preserve the quality of the RBL. RBLs are a meritocracy. If an RBL either lists too many valid senders or does not list enough bad senders, then receivers will notice and stop using the RBL on their servers. -DMM
The day SORBS goes away ...
The day SORBS goes away is the day ab...@yahoo.com starts functioning properly and yahoo starts booting spammers. The day SORBS goes away is the day BS like this stops happening: - The following addresses had permanent fatal errors - ab...@noc.privatedns.com (reason: 554 rejected due to spam content) -Dan
DNS noise
Anyone else seeing this sort of noise lately? 10:35:00.958556 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
Re: DNS noise
Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic. # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=trueshowARIN=falseext=netref2 # Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # 2012/4/6 Nathan Eisenberg nat...@atlasnetworks.us Anyone else seeing this sort of noise lately? 10:35:00.958556 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
Re: DNS noise
On 04/06/12 10:47, Keegan Holley wrote: Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic. # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=trueshowARIN=falseext=netref2 # Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63 If it's an attempt at a reflective DNS-based DDoS attack, then the source IP address making the query is likely spoofed. The IP address in question is really the target, not the source of the attack. That is, of course, if this is a standard reflective DDoS attack. michael
Re: DNS noise
It could be a DNS amplification attack, with the source IP forged. They may be hoping you reply to the forged source with a response greater than the cost of them sending the query. Of course you'd have to actually be running a poorly configured DNS server on that IP for this to work... On Fri, Apr 6, 2012 at 11:47 AM, Keegan Holley keegan.hol...@sungard.comwrote: Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic. # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=trueshowARIN=falseext=netref2 # Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # 2012/4/6 Nathan Eisenberg nat...@atlasnetworks.us Anyone else seeing this sort of noise lately? 10:35:00.958556 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
Re: DNS noise
On 06/04/2012 18:41, Nathan Eisenberg wrote: Anyone else seeing this sort of noise lately? There has been a bit of that recently for ripe.net and several other well known DNSSEC enabled domains (e.g. isc.org). It turns out that DNSSEC makes a respectable traffic amplification vector: twinkie# dig +ignore +notcp any ripe.net | grep rcvd ;; MSG SIZE rcvd: 490 twinkie# The dns request packet size was 26 bytes. Add packet overhead to both the request and the reply, and you end up with: request: 26 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 92 reply: 490 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 556 = amplification on ethernet medium == 556/92, or slightly more than 6x. Welcome back to the 1990s. Nick
Re: DNS noise
On Fri, Apr 6, 2012 at 12:52 PM, PC paul4...@gmail.com wrote: Of course you'd have to actually be running a poorly configured DNS server on that IP for this to work... Right was that IP ever running a DNS service? Picking random IPs to spoof and hope some of the random IPs happen to be DNS servers doesn't sound like a very efficient attack.It seems like the attacker would want to 'probe first' before selecting innocent servers to reflect at Perhaps 2 or 3% of the possible random IPs on the internet actually run DNS servers that could possibly respond to spoofed queries? -- -JH
Re: DNS noise
On Fri, Apr 6, 2012 at 1:04 PM, Nick Hilliard n...@foobar.org wrote: On 06/04/2012 18:41, Nathan Eisenberg wrote: Anyone else seeing this sort of noise lately? There has been a bit of that recently for ripe.net and several other well known DNSSEC enabled domains (e.g. isc.org). It turns out that DNSSEC makes a respectable traffic amplification vector: This is definitely a problem. Unfortunately, what really should happen is DNSSEC should be revised, to, either make sure that the client initiating the query has to either do more work than the server, or make a round trip before the DNSSEC data can be requested. One way of accomplishing that would be to indicate that DNSSEC data can be transmitted only over DNS when using TCP; since a reflection spoofer cannot complete a 3-way TCP handshake, the attacker cannot send spoofed requests for DNSSEC data over TCP. -- -JH
Re: DNS noise
On Apr 6, 2012, at 11:13 AM, Jimmy Hess wrote: It turns out that DNSSEC makes a respectable traffic amplification vector: This is definitely a problem. Yep. So are SNMP reflection attacks (biggest attack I've seen was one of these) and any other datagram-oriented query/response protocol. Unfortunately, what really should happen is DNSSEC should be revised, to, either make sure that the client initiating the query has to either do more work than the server, or make a round trip before the DNSSEC data can be requested. Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 One way of accomplishing that would be to indicate that DNSSEC data can be transmitted only over DNS when using TCP; I suspect the root server operators might not like this idea very much. Regards, -drc
Re: SORBS?!
On Fri, Apr 6, 2012 at 8:48 AM, valdis.kletni...@vt.edu wrote: If it was industry-wide standard practice that just notifying a provider resulted in something being done, we'd not need things like Senderbase, which is after all basically a list of people who don't take action when notified... [snip] Pot calling the kettle black.Before we talk about industry-wide practice about the providers doing something. We should talk about industry-wide practice for Black lists doing something to correct entries, instead of just building up indiscriminate or irresponsibly maintained lists of networks or scores of networks that were targetted by a spammer at one time in the past. It's just as bad for a blacklist operator to not respond and do something for a network operator legitimately trying to resolve spam problems with their network and clear the listing as it is for a network abuse contact to not respond to a network operator. We should talk about industry-wide practices for how providers should be notified, what providers are actually supposed to do to authenticate reports, because sometimes the report/notification itself is malicious or false abusive attempt to harass an innocent email user, and what exactly providers are actually expected to do with certain kinds of notification. The informal standard of just call or send an e-mail to an abuse contact is poorly specified. The informal standard of the abuse contact should investigate and take immediate action is poorly specified. Some of these things that are not specified by RFC should be specified by RFC as best practice. There should be abuse notification and response notification mechanisms other than free form e-mail. -- -JH
Re: SORBS?!
On Fri, Apr 6, 2012 at 1:01 PM, Drew Weaver drew.wea...@thenap.com wrote: So you're suggesting that hosting companies do what? I believe I'm suggesting you use SORBS as your canary in the coal mine and otherwise ignore them. But if you're asking what hosting companies could do to proactively prevent spamming and make their systems inhospitable to spammers, I might start with blocking non-local outbound TCP 25 by default. Then have the customer fill out and sign a form. Spell out your bulk email policies, have the customer specify which of their IPs will originate email and have them send the form to you signed via U.S. Mail. No proof or other major hoops, just sign and mail the form. Unless you're *trying* to run a bulletproof hosting system, you'll find the customers who intentionally spam would prefer to stay under the radar. Forcing them to out themselves by telling you they intend to send mail from every one of their addresses is often enough to encourage their voluntary departure. And it's certainly enough to tell you *which* among your thousands of customers you should watch to make sure they're not spammers. For the non-spamming customers, you've emphasized that running a well secured email server is a challenge which takes more than clicking install.exe. You haven't told them they can't, but you've spelled out be careful in big, bold letters. And I'm mostly just complaining about senderbase, because they seem to be the one that really large companies reference. Meh. If you catch them while they're still just annoying SORBS, they'll never make it in to senderbase. Canary. Coal mine. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 07 Apr, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 404580 Prefixes after maximum aggregation: 171963 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 196184 Total ASes present in the Internet Routing Table: 40624 Prefixes per ASN: 9.96 Origin-only ASes present in the Internet Routing Table: 32993 Origin ASes announcing only one prefix: 15464 Transit ASes present in the Internet Routing Table:5440 Transit-only ASes present in the Internet Routing Table:139 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 32 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 670 Unregistered ASNs in the Routing Table: 296 Number of 32-bit ASNs allocated by the RIRs: 2347 Number of 32-bit ASNs visible in the Routing Table:2191 Prefixes from 32-bit ASNs in the Routing Table:5373 Special use prefixes present in the Routing Table:2 Prefixes being announced from unallocated address space: 1411 Number of addresses announced to Internet: 2533675600 Equivalent to 151 /8s, 4 /16s and 210 /24s Percentage of available address space announced: 68.4 Percentage of allocated address space announced: 68.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 171899 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:99031 Total APNIC prefixes after maximum aggregation: 32155 APNIC Deaggregation factor:3.08 Prefixes being announced from the APNIC address blocks: 95427 Unique aggregates announced from the APNIC address blocks:39280 APNIC Region origin ASes present in the Internet Routing Table:4678 APNIC Prefixes per ASN: 20.40 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table:730 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table:172 Number of APNIC addresses announced to Internet: 642926944 Equivalent to 38 /8s, 82 /16s and 73 /24s Percentage of available APNIC address space announced: 81.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:149419 Total ARIN prefixes after maximum aggregation:75874 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120748 Unique aggregates announced from the ARIN address blocks: 50004 ARIN Region origin ASes present in the Internet Routing Table:14948 ARIN Prefixes per ASN: 8.08 ARIN Region origin ASes announcing only one prefix:
Re: SORBS?!
On Fri, 6 Apr 2012, Patrick W. Gilmore wrote: Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). This depends on the DNSBL, the type of listing, and that DNSBL's policies. Some DNSBLs, some listings, automated removal is possible and appropriate. Sometimes it's not, and a human is needed to make the decision as to whether a delisting request should be granted or refused. Even when there is a path for automated removals via a web form, not everyone will find or use that path. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SORBS?!
On Thu, 5 Apr 2012, Landon Stewart wrote: If the purpose of blacklist is to block spam for recipients using that blacklist then a /32 works. If the purpose of a blacklist is to annoy providers then a /24 works. The most reputable and useful blacklists IMHO are Spamhaus and Spamcop - they don't block /24s. Spamhaus sometimes does if your rwhois shows that a large amount of the /24 is owned by the offending party but generally they don't. Spamhaus may not default to doing /24 listings for a /32 spam emitter, but they certainly do list /24s or shorter subnets when they feel it's appropriate. They even do escalations to corporate mail servers on rare occasions when a provider appears to be complicit with spammers and ignoring their SBLs. The purpose thing is an interesting question though. Is the purpose of DNSBLs simply to help admins avoid accepting spam from spammers or to attempt to prevent spammers from operating on the internet? For most of the DNSBLs I'm familiar with, I'd say they're trying to do both. Spamhaus encourages companies to resolve all the issues while only blocking /32s by showing all the listings under your responsibility and making nice to see that list empty. Pretty simple. Incidentally SORBS usually blocks /24s and, as far as I know, provides no way for you to lookup all listings under a providers responsibility (by AS or otherwise). That's really either not true or an oversimplification. Spamhaus blocks shorter than /32 pretty frequently. You could maybe argue that Spamhaus works harder to avoid innocent collateral damage. Having not used SORBS for many years, I couldn't say if that's true or not. The vast majority of my recent years interactions with SORBS have been trying to get inappropriately listed IPs removed from their DUHL. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Question about peering
Hello everyone I am curious to know how small ISPs plan peering with other interested parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say A and C both have open peering policy and assuming the exist in same exchange or nearby. Now at this point is there is any minimum bandwidth considerations? Say if A and C have 1Gbps + of flowing traffic - very likely peering would be good idea to save transit costs to B. But if A and C have very low levels - does it still makes sense? Does peering costs anything if ISPs are in same exchange? Does at low traffic level it makes more sense to keep on reaching other ISPs via big transit provider? Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: DNS noise
On Fri, Apr 6, 2012 at 1:24 PM, David Conrad d...@virtualized.org wrote: [snip] I suspect the root server operators might not like this idea very much. If it solves other problems adequately, they might eventually just have to learn to like it. [snip] Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 No. Implementation of BCP38 does have value, but the existence of BCP38 does not solve DNS application problems; Just looking towards BCP38 as a solution is like attempting to treat a disease with a theoretically effective treatment that you can't possibly get enough of to cure the disease due to limited supplies -- but ignoring mitigation of the symptoms, despite there being more readily available options for symptom mitigation. It's similar to the idea of promoting SPF as a means of stopping e-mail forgery, and saying RBLs just treat the symptoms -- stop using RBLs, and get everyone to implement SPF. The underlying problem is that BCP38 is not really a best common practice, despite the name of the series. It's really a Best Uncommon Practice that really ought to be more common, but we can't control operators and force them to make it more common. Lots of networks don't and will not ever implement BCP38; BCP38 is not being more widely implemented, and there's no obvious action that will force it to change. -- -JH
Re: DNS noise
Jimmy commented:
#The underlying problem is that BCP38 is not really a best common practice,
#despite the name of the series.
#
#It's really a Best Uncommon Practice that really ought to be more common,
#but we can't control operators and force them to make it more common.
#
#Lots of networks don't and will not ever implement BCP38; BCP38 is not being
#more widely implemented, and there's no obvious action that will
#force it to change.
Check out the MIT Spoofer Project (http://spoofer.csail.mit.edu/summary.php)
BCP38 anti-spoofing filtering is more common than you might think (on the
order of 80% of {netblocks, IPs, ASNs} filter as of October 2011)
Regards,
Joe
Re: DNS noise
Jimmy, On Apr 6, 2012, at 1:24 PM, Jimmy Hess wrote: On Fri, Apr 6, 2012 at 1:24 PM, David Conrad d...@virtualized.org wrote: I suspect the root server operators might not like this idea very much. If it solves other problems adequately, they might eventually just have to learn to like it. I was, of course, using the root servers as a proxy for pretty much any DNS server operator. The root server operators aren't unique in the requirement to respond to an unbounded number of queries. Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 No. Implementation of BCP38 does have value, but the existence of BCP38 does not solve DNS application problems; You seemed to have missed the part where it isn't just a DNS problem. Your solution would appear to be to replace every datagram-based query/response protocol such as ICMP and SNMP. I personally think it is more feasible for ISPs to implement BCP38 than it is for the entire Internet to move away from using datagram-based query/response protocols, but that's probably just me. but ignoring mitigation of the symptoms, despite there being more readily available options for symptom mitigation. Sorry, which more readily available options are those? I don't think forcing a 3-way exchange for stuff like PMTUD is 'readily available'. The underlying problem is that BCP38 is not really a best common practice, despite the name of the series. The name of the series is Best Current Practice. Lots of networks don't and will not ever implement BCP38; It is true that lots of networks don't implement BCP38. Whether or not they will ever is more debatable. I suspect that we're about one major spoofing-based infrastructure attack away from proposed legislation that would force folks to implement something like BCP38, but I may be a bit more pessimistic than most. However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days. Regards, -drc
Re: DNS noise
On Apr 6, 2012, at 4:44 PM, David Conrad wrote: However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days. Easy: 1) hardare support varies 2) implementing bcp-38 drives customer support costs up in cases where the customer is doing something weird e.g.: using toms isdn-dial backup to source return packets. 3) customers can't be trusted to give a complete list of valid source addresses 4) asymmetric or highly kinky routing exists more than one would like to admit There are cases where it's fairly inexcusable: Fixed broadband providers (static IP address or dynamic to a customer port/pool) CGN exit points Static routed customers (They shouldn't be doing asymmetric routing) The real reason imho.. is #2 above. desire to keep unnecessary support calls from your call center. - Jared
Re: SORBS?!
On Thu, Apr 05, 2012 at 06:45:30PM +0100, Nick Hilliard wrote: On 05/04/2012 17:48, goe...@anime.net wrote: But they will care about a /24. I'm curious as to why they would want to stop at /24. If you're going to take the shotgun approach, why not blacklist the entire ASN? It's a balancing act. Too little collateral damage and the provider hosting the spammer isn't motivated to act. Too much collateral damage, and no one uses your blacklist because using it generates too many user complaints, and then your list doesn't motivate anyone to do anything because there's no real downside to being on the list. Just the right amount of collateral damage, and your list gets widely used, and causes enough pain on the other of the /24 that they clean things up. I'm not arguing for or against any particular amount of collateral damage. Just commenting on the effects of varying amounts of collateral damage. -- Brett
Re: SORBS?!
Jimmy Hess wrote: On Fri, Apr 6, 2012 at 8:48 AM, valdis.kletni...@vt.edu wrote: If it was industry-wide standard practice that just notifying a provider resulted in something being done, we'd not need things like Senderbase, which is after all basically a list of people who don't take action when notified... [snip] Pot calling the kettle black.Before we talk about industry-wide practice about the providers doing something. We should talk about industry-wide practice for Black lists doing something to correct entries, instead of just building up indiscriminate or irresponsibly maintained lists of networks or scores of networks that were targetted by a spammer at one time in the past. Sorry, but blocklists _came_into_existance_ ONLY because of large numbers of providers *ignoring* the problems their networks were causing the rest of the world. The very existance of 'widely used' blocklists is a damning indictment of the entire services provider industry. _Everybody_, including the major blocklist operators, would prefer that blocklists were _not_ needed -- that all providers would simply 'do the right thing', and insure that their users did =not= abuse other people's systems. Were that pipe-dream to come to pass, the major blocklists would *happily* shut down. They are all 'money sinks', operating at a loss, 'for the good of the community as a whole'. Before blocklists. 'policing your own network' was a pure expense item with no return. _Not_ policing one's own users *added* to profitability. There was no 'business incentive' to be a good neighbor. With the advent of blocklists, providers have an 'economic self interest' justification in remaining out of the major/widely used ones. It is still an expense item, but not doing anything costs _more_ in 'lost revenues'. It is a sad comment on the state of affairs that _all_ the major providers have repeatedly demonstrated they simply cannot be trusted to 'do the right thing' *without* a loaded gun held to their heads -- but that *is* the reality of today's marketplace. Today, for any of the major spam-based blocklists, a single entry consisting of more than a single address is indiicative of a _failure_ of a provider's self-policing. It is the height of hubris for a provider to 'demand' (or even 'expect') prompt/immediate response from a blocklist, *when* the provider 'demonstrably' couldn't be bothered to act that way themselves. (What's 'sauce for the goose' _is_ sauce for the gander. :) IF the provider had been actively self-policing, the blocklist entry would not have been escalalated to larger than the single offending address. Yes, it would be nice if everybody responded promptly; but, in the real world, that simply doesn't happen -- on either side of the fence. I once got an ack about a spam complaint *over*five*months* after sending it. (For 'some strange reason', that provider is no longer in business. Thank goodness! It's just as bad for a blacklist operator to not respond and do something for a network operator legitimately trying to resolve spam problems with their network and clear the listing as it is for a network abuse contact to not respond to a network operator. This is provably not true. There is no recourse/remedy for an unresponsive network operator. The 'network abuse' ccontinues to flow, _unabated_, from that network. A blocklist, on the other hand, tends to be self-regulating. If it is not responsive to changing conitions, especially the 'cleaning' of formerly 'bad reputation' addresses/blocks, it generates an 'unacceptably high' number -- as determined by it's USERS, not the senders -- of 'false positive' evaluations, *wherepon* increasing numbers of users =stop= using that service. Resulting in an automatic _lessening_ of the impact of being listed on that blocklist. See the APEWS list for a 'textbook' demonstration of this self-regulation in action. We should talk about industry-wide practices for how providers should be notified, what providers are actually supposed to do to authenticate reports, because sometimes the report/notification itself is malicious or false abusive attempt to harass an innocent email user, and what exactly providers are actually expected to do with certain kinds of notification. The informal standard of just call or send an e-mail to an abuse contact is poorly specified. The informal standard of the abuse contact should investigate and take immediate action is poorly specified. Some of these things that are not specified by RFC should be specified by RFC as best practice. There should be abuse notification and response notification mechanisms other than free form e-mail. It would appear that you are not familiar with RFC 5965.
BGP Update Report
BGP Update Report Interval: 29-Mar-12 -to- 05-Apr-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS840267283 3.7% 33.7 -- CORBINA-AS OJSC Vimpelcom 2 - AS10201 52074 2.9% 197.2 -- DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless 3 - AS14374 48402 2.7%1210.0 -- AGRI-VALLEY - Agri-Valley Services Inc. 4 - AS982940535 2.2% 50.7 -- BSNL-NIB National Internet Backbone 5 - AS784334206 1.9%1266.9 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 6 - AS12479 28304 1.6% 43.1 -- UNI2-AS France Telecom Espana SA 7 - AS702923655 1.3% 6.7 -- WINDSTREAM - Windstream Communications Inc 8 - AS755223336 1.3% 21.4 -- VIETEL-AS-AP Vietel Corporation 9 - AS32528 23234 1.3%3319.1 -- ABBOTT Abbot Labs 10 - AS26615 21440 1.2% 24.0 -- Tim Celular S.A. 11 - AS211819486 1.1% 13.6 -- RELCOM-AS OOO NPO Relcom 12 - AS580017725 1.0% 57.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS24560 17518 1.0% 39.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - AS597616773 0.9% 148.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS28683 16207 0.9% 274.7 -- BENINTELECOM 16 - AS28573 12874 0.7% 12.1 -- NET Servicos de Comunicao S.A. 17 - AS458999521 0.5% 29.1 -- VNPT-AS-VN VNPT Corp 18 - AS594 9181 0.5% 65.1 -- LVLT594-598 - Level 3 Communications, Inc. 19 - AS256208895 0.5% 57.4 -- COTAS LTDA. 20 - AS8452 8678 0.5% 8.2 -- TE-AS TE-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS3563 3832 0.2%3832.0 -- PILOT-ASN - Pilot Network Services, Inc 2 - AS174083365 0.2%3365.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 3 - AS32528 23234 1.3%3319.1 -- ABBOTT Abbot Labs 4 - AS784334206 1.9%1266.9 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 5 - AS14374 48402 2.7%1210.0 -- AGRI-VALLEY - Agri-Valley Services Inc. 6 - AS55665 998 0.1% 998.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 7 - AS22733 910 0.1% 910.0 -- 8 - AS11553 888 0.1% 888.0 -- MANNATECH-AS MANNATECH 9 - AS57767 871 0.1% 871.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 10 - AS44798 808 0.0% 808.0 -- PERVOMAYSK-AS PP SKS-Pervomaysk 11 - AS383641220 0.1% 610.0 -- CNNIC-LTEL-AP LONGTEL NETWORKS TECHNOLOGIES LTD. 12 - AS388571121 0.1% 560.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 13 - AS158252193 0.1% 548.2 -- UNSPECIFIED 14 - AS343691563 0.1% 521.0 -- SHATELIX SHATEL Internet Exchange 15 - AS27169 490 0.0% 490.0 -- TRIDENTAS - Trident Systems, Inc. 16 - AS52366 952 0.1% 476.0 -- Lunamen S.A. 17 - AS25600 454 0.0% 454.0 -- MATRIKON-1 - Matrikon Inc. 18 - AS37169 887 0.1% 443.5 -- SOLSI 19 - AS33377 866 0.1% 433.0 -- FHLBC - Federal Home Loan Bank of Chicago 20 - AS38455 830 0.1% 415.0 -- IPC-NETWORK-SERVICES-AS-AP IPC Network Services TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/2411607 0.6% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/2411607 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 204.234.0.0/1711054 0.6% AS7029 -- WINDSTREAM - Windstream Communications Inc 4 - 62.36.252.0/22 8750 0.5% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 205.107.121.0/24 7545 0.4% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - 122.161.0.0/16 6862 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6450 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 62.36.241.0/24 5921 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.210.0/24 5674 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 205.106.248.0/24 5466 0.3% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - 23.54.176.0/22 5267 0.3% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 12 - 194.63.9.0/24 5145 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 184.50.208.0/204913 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 14 - 205.211.136.0/24 4864 0.2% AS6407 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 15 - 173.222.100.0/22 4828 0.2% AS7843 -- TWCABLE-BACKBONE - Road
The Cidr Report
This report has been generated at Fri Apr 6 21:12:44 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
30-03-12406585 236412
31-03-12406736 236071
01-04-12406429 236409
02-04-12406722 236897
03-04-12406676 237014
04-04-12406639 237399
05-04-12406957 237397
06-04-12407232 237558
AS Summary
40739 Number of ASes in routing system
17045 Number of ASes announcing only one prefix
3432 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
111508768 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 06Apr12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 407551 237560 16999141.7% All ASes
AS6389 3432 199 323394.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3417 1822 159546.7% WINDSTREAM - Windstream
Communications Inc
AS4766 2480 1021 145958.8% KIXS-AS-KR Korea Telecom
AS22773 1568 120 144892.3% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18566 2092 705 138766.3% COVAD - Covad Communications
Co.
AS28573 1773 493 128072.2% NET Servicos de Comunicao S.A.
AS2118 1394 141 125389.9% RELCOM-AS OOO NPO Relcom
AS4323 1599 382 121776.1% TWTC - tw telecom holdings,
inc.
AS4755 1574 393 118175.0% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS1785 1896 807 108957.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS10620 1795 825 97054.0% Telmex Colombia S.A.
AS7552 1172 219 95381.3% VIETEL-AS-AP Vietel
Corporation
AS8402 1720 800 92053.5% CORBINA-AS OJSC Vimpelcom
AS7303 1353 439 91467.6% Telecom Argentina S.A.
AS26615 887 32 85596.4% Tim Celular S.A.
AS8151 1483 667 81655.0% Uninet S.A. de C.V.
AS18101 948 163 78582.8% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1105 347 75868.6% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS30036 1461 771 69047.2% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS17974 1782 1099 68338.3% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS9394 892 210 68276.5% CRNET CHINA RAILWAY
Internet(CRNET)
AS3356 1100 462 63858.0% LEVEL3 Level 3 Communications
AS17676 687 75 61289.1% GIGAINFRA Softbank BB Corp.
AS19262 997 402 59559.7% VZGNI-TRANSIT - Verizon Online
LLC
AS24560 1021 433 58857.6% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS22561 996 416 58058.2% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS3549 1012 440 57256.5% GBLX Global Crossing Ltd.
AS4804 655 95 56085.5% MPX-AS Microplex PTY LTD
AS22047 584 31 55394.7% VTR BANDA ANCHA S.A.
AS4780 808 257 55168.2% SEEDNET Digital United Inc.
Total 43683142662941767.3% Top 30 total
Possible Bogus Routes
10.86.64.32/30 AS65530 -Private Use AS-
10.86.64.36/30 AS65530 -Private Use
Re: SORBS?!
Brielle Bruns wrote: Unfortunately, the apathy of providers, backbones, and network operators in general have created an environment that the almighty buck rules everything. I totally agree with pretty much everything in this email. I also agree that blocking whole /24 or bigger when spam has been detected to come from such a block is more often than not a necessity. It's very unlikely to see 1 abuser in between an otherwise perfectly behaving network neighbourhood. Greetings, Jeroen -- Earthquake Magnitude: 5.5 Date: Friday, April 6, 2012 19:24:11 UTC Location: Kepulauan Mentawai region, Indonesia Latitude: -3.3944; Longitude: 100.4205 Depth: 1.00 km
Re: The day SORBS goes away ...
err, i dont know but yahoo hasnt yet acquired this random webhost whose abuse you're trying to mail On Friday, April 6, 2012, goe...@anime.net wrote: The day SORBS goes away is the day ab...@yahoo.com starts functioning properly and yahoo starts booting spammers. The day SORBS goes away is the day BS like this stops happening: - The following addresses had permanent fatal errors - ab...@noc.privatedns.com (reason: 554 rejected due to spam content) -Dan -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Question about peering
what does it cost you to peer, versus what does it cost you to not peer? if you are at the same ix the costs of peering are very low indeed On Saturday, April 7, 2012, Anurag Bhatia wrote: Hello everyone I am curious to know how small ISPs plan peering with other interested parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say A and C both have open peering policy and assuming the exist in same exchange or nearby. Now at this point is there is any minimum bandwidth considerations? Say if A and C have 1Gbps + of flowing traffic - very likely peering would be good idea to save transit costs to B. But if A and C have very low levels - does it still makes sense? Does peering costs anything if ISPs are in same exchange? Does at low traffic level it makes more sense to keep on reaching other ISPs via big transit provider? Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: SORBS?!
On Fri, Apr 6, 2012 at 8:13 PM, Jeroen van Aart jer...@mompl.net wrote: Brielle Bruns wrote: to come from such a block is more often than not a necessity. It's very unlikely to see 1 abuser in between an otherwise perfectly behaving network neighbourhood. That's kind of vague to say it's unlikely to see 1 abuser. What is the probability that more IPs in the same /24 are likely to harbor abusers, given that you have received abuse from one IP? And how have you discovered this? ( What is the criteria used to determine that it is unlikely, and what is your source of the information?) Are you assuming that if you've seen the abuse, that you probably weren't the first victim, that the ISP has probably already been notified by someone else, that they have likely had a reasonable amount of time to put a stop to the abuse, and that they failed to do so? There is the one good case where a single abuser has a dynamic IP address; but it's not a safe assumption that they will live in the same /24 next time the abuser dials in. So not only does listing an entire /24list innocent users' IP addresses, it also does not necessarily effectively list the one abuser. -- -JH
Re: SORBS?!
i dont think anyone would miss sorbs if it was gone, dare i say it not even a single person On Fri, Apr 6, 2012 at 9:48 PM, Jimmy Hess mysi...@gmail.com wrote: On Fri, Apr 6, 2012 at 8:13 PM, Jeroen van Aart jer...@mompl.net wrote: Brielle Bruns wrote: to come from such a block is more often than not a necessity. It's very unlikely to see 1 abuser in between an otherwise perfectly behaving network neighbourhood. That's kind of vague to say it's unlikely to see 1 abuser. What is the probability that more IPs in the same /24 are likely to harbor abusers, given that you have received abuse from one IP? And how have you discovered this? ( What is the criteria used to determine that it is unlikely, and what is your source of the information?) Are you assuming that if you've seen the abuse, that you probably weren't the first victim, that the ISP has probably already been notified by someone else, that they have likely had a reasonable amount of time to put a stop to the abuse, and that they failed to do so? There is the one good case where a single abuser has a dynamic IP address; but it's not a safe assumption that they will live in the same /24 next time the abuser dials in. So not only does listing an entire /24list innocent users' IP addresses, it also does not necessarily effectively list the one abuser. -- -JH
Re: The day SORBS goes away ...
On Sat, 07 Apr 2012 07:00:52 +0530, Suresh Ramasubramanian said: err, i dont know but yahoo hasnt yet acquired this random webhost whose abuse you're trying to mail - The following addresses had permanent fatal errors - ab...@noc.privatedns.com (reason: 554 rejected due to spam content) Right - that one is doing stupid stuff like filtering out spam reports sent to abuse@ because they contain spam all by itself, without Yahoo's assistance. Yahoo is only a hegemony among spam havens, not a monopoly. There's still freelance havens out there, and they'll go away when SORBS does. I'm not so sanguine about Yahoo's chances of lasting till then though... pgpIDBfnDaSRJ.pgp Description: PGP signature
Re: The day SORBS goes away ...
the yahoo item was a point all its own, unrelated to iweb's idiocy. yahoo no longer care to receive abuse reports from anyone at all. -Dan On Sat, 7 Apr 2012, Suresh Ramasubramanian wrote: err, i dont know but yahoo hasnt yet acquired this random webhost whose abuse you're trying to mail On Friday, April 6, 2012, goe...@anime.net wrote: The day SORBS goes away is the day ab...@yahoo.com starts functioning properly and yahoo starts booting spammers. The day SORBS goes away is the day BS like this stops happening: - The following addresses had permanent fatal errors - ab...@noc.privatedns.com (reason: 554 rejected due to spam content) -Dan -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: SORBS?!
On Fri, 06 Apr 2012 20:48:44 -0500, Jimmy Hess said: That's kind of vague to say it's unlikely to see 1 abuser. What is the probability that more IPs in the same /24 are likely to harbor abusers, given that you have received abuse from one IP? It's similar to pirhanas or cockroaches - they can't be found everywhere, but if you spot one in a location, there's a near certainty that there's plent more in the area. Or if you don't like that, you can run a simple Monte Carlo simulation. Assume 256 customer slots, and that initially, there is a 3% chance that the next customer to arrive is evil. Also add a feedback - each time you terminate an evil customer in less than the average arrival time, the chance the next customer is evil is cut by 10% of the current value. Each time an evil customer is allowed to last 3 times the average arrival time, the chance of an evil customer goes up 10%. Simulate for various termination times for evil customers. Are there any steady-state solutions where the *average* number of evil users is one? Or does it decay down towards zero or upwards towards a high number? pgpp53wzdQLtK.pgp Description: PGP signature
Re: The day SORBS goes away ...
On Sat, Apr 7, 2012 at 7:25 AM, valdis.kletni...@vt.edu wrote: Yahoo is only a hegemony among spam havens, not a monopoly. There's still freelance havens out there, and they'll go away when SORBS does. Sorbs did have a decent set of traps - and did catch a lot of spam. The problem was atrociously poor maintenance - stale entries, entries that'd reappear due to db issues, people skills of the volunteers handling the queue .. I'd have thought there'd be some improvement with their being acquired. Got to see. -- Suresh Ramasubramanian (ops.li...@gmail.com)
