Re: why IPv6 isn't ready for prime time, SMTP edition
Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Mon, Mar 31, 2014 at 12:17:19AM -0400 Quoting Patrick W. Gilmore (patr...@ianai.net): On Mar 30, 2014, at 16:40 , Måns Nilsson mansa...@besserwisser.org wrote: Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Sat, Mar 29, 2014 at 11:06:11AM -0400 Quoting Patrick W. Gilmore (patr...@ianai.net): On Mar 29, 2014, at 3:15, Måns Nilsson mansa...@besserwisser.org wrote: Quoting John R. Levine (jo...@iecc.com): Ergo, ad hominem. Please quit doing that. As a side note I happen to run my own mail server without spam filters -- it works for me. I might not be the norm, but then again, is there really a norm? (A norm that transcends SMTP RFC reach, that is -- I know a lot of people who run a lot of mail systems, and let's just say you're so far out in the long tail we need a telescope to see you. I will not debate with people who resort to humiliation techniques when questioned. I will not argue whether you were humiliated as that is something only you can decide. The puny attempt at master suppression technique[0] was identified as such and countermeasures were launched. No damage done. I was serious. Your reaction .. well, I shouldn't say anything more lest you call me puny again. (What were you saying about humiliation techniques? Glad to see you would never be hypocritical.) My apologies. I was not refering to your statement -- if that was not clear I should most certainly have written more clearly. However, John was still factually correct. No big deal, lots of people are humiliated by facts. Although I admit I didn't find the quote above terribly humiliating myself. You have a point. Further, I do not debate the truth in the statement. My personal email system IS small -- I did even state that -- but that does not mean I do not run larger systems for others, nor does it mean that the general public should dismiss my ideas and only listen to people who brag about their acquaintances. There are other much more compelling reasons not to do as I say. You misunderstand. Or perhaps I did? I read John's statement to be in reference to your stance, i.e. running without spam filters. Not that your server is small. I read you handle no big amount of e-mail and I know people who do and therefore you should STFU and not bother us with your silly ideas about following standards in Johns message, and while that might seen like one of many interpretations of what was written, it is an interpretation I hope to be not so far out on the insulted fringe so as to be silly. John can clarify if he likes. But either way, running without spam filters is beyond unusual these days. Indeed. My personal server is run with very few filters, all of which REJECT or accept and send to a box I read. I have no spam folder. So while I am not as far down the tail as you are, I am definitely out of the mainstream. The only reason I mention that is so you don't go researching for another reason to identify my comments as anything except exactly what they say. Oh, I'm not hoping to pick a fight. Bad move to pick fights with people that function as mediators. Also, realize that John has already done more to stop spam in his career then you and your thousand closest friends ever will. (E.g. Look up abuse.net.) Again not humiliation, just a fact. Feel free to plonk me as well. I won't be humiliated. :-) I won't. There is a clear divide between politely pointing out facts and abusing facts to tell people that their opinion does not matter. And, for the record, I do not support spamming in any form. But the mitigation techniques MUST NOT impose undue constraints on the legitimate use of e-mail, even when it is not vetted by passing it through big insecure monitored US webmail providers. I like your use of MUST. However, I think you'll find your definition of undue and most of the rest of the Internet's is vastly different. I'm fully aware of that. The clear separation between network and application that is at the core of IP is easily compromised by the best intentions. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I selected E5 ... but I didn't hear Sam the Sham and the Pharoahs! signature.asc Description: Digital signature
RE: Outgoing traffic problem on Citrix Netscaler Load Balancer
Hi Paul, Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? Thanks -Original Message- From: Paul Bertain [mailto:p...@bertain.net] Sent: Tuesday, March 25, 2014 10:47 PM To: Anil KARADAG Cc: nanog@nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. Paul On Mar 24, 2014, at 11:46 PM, Anil KARADAG akara...@netas.com.tr wrote: Hi, I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. thanks Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesajı ve ekleri gönderildiği kişi ya da kuruma özeldir ve gizlidir. Ayrıca hukuken de gizli olabilir. Hiçbir şekilde üçüncü kişilere açıklanamaz ve yayınlanamaz. Eğer mesajın gönderildiği alıcı değilseniz bu elektronik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır ve bu elektronik postayı ve eklerini derhal silmeniz gerekmektedir. NETAŞ TELEKOMÜNİKASYON A.Ş. bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından, saklanmasından ve kullanılmasından sorumlu değildir. Bu mesajdaki görüşler gönderen kişiye ait olup, NETAŞ TELEKOMÜNİKASYON A.Ş.’nin görüşlerini yansıtmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETAŞ TELEKOMÜNİKASYON A.Ş. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETAŞ TELEKOMÜNİKASYON A.Ş.
Re: Outgoing traffic problem on Citrix Netscaler Load Balancer
On Mar 31, 2014, at 7:17 PM, Anil KARADAG akara...@netas.com.tr wrote: However, we need the source port to be the same on the destination servers. Out of curiosity, why? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Outgoing traffic problem on Citrix Netscaler Load Balancer
Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: Hi Paul, Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? Thanks -Original Message- From: Paul Bertain [mailto:p...@bertain.net] Sent: Tuesday, March 25, 2014 10:47 PM To: Anil KARADAG Cc: nanog@nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. Paul On Mar 24, 2014, at 11:46 PM, Anil KARADAG akara...@netas.com.tr wrote: Hi, I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. thanks Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesajı ve ekleri gönderildiği kişi ya da kuruma özeldir ve gizlidir. Ayrıca hukuken de gizli olabilir. Hiçbir şekilde üçüncü kişilere açıklanamaz ve yayınlanamaz. Eğer mesajın gönderildiği alıcı değilseniz bu elektronik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır ve bu elektronik postayı ve eklerini derhal silmeniz gerekmektedir. NETAŞ TELEKOMÜNİKASYON A.Ş. bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından, saklanmasından ve kullanılmasından sorumlu değildir. Bu mesajdaki görüşler gönderen kişiye ait olup, NETAŞ TELEKOMÜNİKASYON A.Ş.’nin görüşlerini yansıtmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETAŞ TELEKOMÜNİKASYON A.Ş. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETAŞ
RE: Outgoing traffic problem on Citrix Netscaler Load Balancer
Hi, Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. -Original Message- From: Pui Edylie [mailto:em...@edylie.net] Sent: Monday, March 31, 2014 3:23 PM To: Anil KARADAG; Paul Bertain Cc: nanog@nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: Hi Paul, Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? Thanks -Original Message- From: Paul Bertain [mailto:p...@bertain.net] Sent: Tuesday, March 25, 2014 10:47 PM To: Anil KARADAG Cc: nanog@nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. Paul On Mar 24, 2014, at 11:46 PM, Anil KARADAG akara...@netas.com.tr wrote: Hi, I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. thanks Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesajı ve ekleri gönderildiği kişi ya da kuruma özeldir ve gizlidir. Ayrıca hukuken de gizli olabilir. Hiçbir şekilde üçüncü kişilere açıklanamaz ve yayınlanamaz. Eğer mesajın gönderildiği alıcı değilseniz bu elektronik postanın içeriğini açıklamanız, kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır ve bu elektronik postayı ve eklerini derhal silmeniz gerekmektedir. NETAŞ TELEKOMÜNİKASYON A.Ş. bu mesajın içerdiği bilgilerin doğruluğu veya eksiksiz olduğu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından, saklanmasından ve kullanılmasından sorumlu değildir. Bu mesajdaki görüşler gönderen kişiye ait olup, NETAŞ TELEKOMÜNİKASYON A.Ş.’nin görüşlerini yansıtmayabilir. --- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and
RE: 3356 leaking routes out 3549 lately?
There shouldn't be any reason for this happening. Our network integration work generally involves moving a customer ASN from behind 3549 to be behind 3356, and once moved is generally permanent. In some cases, 3356 provides transit for 3549 to get to some peers that have been consolidated onto 3356, which would create a 3356 3549 yourasn path, but not the one you outline in your note, which implies 3549 providing transit for 3356. To my knowledge, and the guy I check with in engineering, we are not intentionally doing that anywhere. So, if you see this problem continue, please open a ticket and escalate it if you don't get a good response. Dave -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Friday, March 28, 2014 2:32 PM To: c...@2bithacker.net Cc: nanog@nanog.org Subject: Re: 3356 leaking routes out 3549 lately? On Mar 28, 2014, at 3:42 PM, Chip Marshall c...@2bithacker.net wrote: On 2014-03-28, David Hubbard dhubb...@dino.hostasaurus.com sent: Has anyone had issues with Level 3 leaking advertisements out their Global Crossing AS3356 for customers of 3549, but not accepting the traffic back? We've been encountering this more and more recently, bgpmon always detects it, and all we ever get from them is there's nothing wrong. Today it affected CloudFlare's ability to talk to us. It seems to happen mostly with Europe and Asian peering points. Typically lasts five to ten minutes which makes me think someone working on merging the two networks is doing some 'no one will notice this' changes in the middle of the night. I'm not sure if it's the same thing, but I've had a few alerts from Renesys lately seeing a path to my AS via GLBX 3549 that shouldn't exist, as we only have connections with Level 3 3356. For example, Renesys reports x 3549 33517 where it should only be able to see x 3356 33517 or maybe x 3549 3356 33517. (Due to Renesys policy, I can't know what x is) It's been a few years i think now since the level-crossing merger so I'm certainly not surprised to see them doing work on this front. This often happens during integration work, and networks of that scale I would imagine tools that detect routing leaks need to account for this merger activity. I can see I need to update my tools :) http://puck.nether.net/bgp/leakinfo.cgi?search=dosearch_prefix=search_aspath=3549_3356search_asn=recent=1000 http://puck.nether.net/bgp/leakinfo.cgi?search=dosearch_prefix=search_aspath=3356_3549search_asn=recent=1000
Just wondering
Pardon for the ignorance regarding this. If folks can point me to something I may have missed as a participant for over 14 years, to powering this Alzheimers. I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. Regards, -Joe
Re: Just wondering
On Mar 31, 2014, at 10:51 PM, Joe jbfixu...@gmail.com wrote: Pardon for the ignorance regarding this. If folks can point me to something I may have missed as a participant for over 14 years, to powering this Alzheimers. I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. There are lots of people who think they need to monitor and respond to every packet that they didn't expect. Sadly we are in a state of the world where these surveys have become necessary both as part of people getting their PHD, but also to provide operational data to network first responders in closing down Open Resolvers, NTP amplifiers and many other resources that can be abused. Many folks have automated tools that complain when these packets come at them but aren't actually accurate in their complaints, like claiming the UDP packets are an attempt to log-in to their service, or saying that UDP is TCP or something else. There are a few people (Cymru, Shadowserver, myself via Open*Project) that are doing work to enumerate and provide data on the problem to the community. For each person that complains there's about 100 thank-yous for the data they received. The RE community have a number of criteria for their collection which is to have rDNS and a website on a name matching that rDNS so people can visit it. There are also lists of do not probe that exist: https://www.dns-oarc.net/oarc/services/dontprobe If your security posture can't accept unsolicited packets you perhaps need to move to a whitelist model vs blacklist one for traffic. (Or your policies about this need to be reviewed... I see every IP address I have control over either home or work get scanned by all sorts of malware and evil stuff, if you have to respond to each of them, that's an impractical task). Without S.A.V.E. (BCP-38/84) one can't tell if that origin IP is accurate in any event. - Jared
Re: Just wondering
On 3/31/2014 10:51 PM, Joe wrote: I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. If I was paying per bit I would probably want my ISP to rate limit and firewall lots of traffic before it ever reached my pay-per-bit line. Otherwise I would be paying for huge amounts of unsolicited traffic from everywhere. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. Regards, -Joe If you're comfortable that your internal audits are accurate and what these people are doing won't provide you any value, I don't see what harm it would do to block them. Since they also have to worry about botnet authors blocking their traffic, I imagine they might change IP ranges after a while. You might complain to them directly and see if they can add you to a do not poll list. It looks like they have a couple of emails for issues listed here: https://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwork
RE: Just wondering
At the bottom of one of their pages it says this: If you would like us to not scan your network, please let us know and we will remove your networks from the scan. Likewise, if you have anymore questions please feel free to send us an email at: dnsscan [at] shadowserver [dot] org. They are quite responsive to questions. Frank -Original Message- From: Joe [mailto:jbfixu...@gmail.com] Sent: Monday, March 31, 2014 9:51 PM To: NANOG Subject: Just wondering Pardon for the ignorance regarding this. If folks can point me to something I may have missed as a participant for over 14 years, to powering this Alzheimers. I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. Regards, -Joe
