Well, after almost a month of no attacks and a coincident month of ORBS blocking at BBN/NZ link, the block on ORBS has been lifted, and we have started getting relay attacks again. I think thats pretty conclusive evidence that they are the cause of the relay attacks. I'm hoping the removal was an oversight, but I'd like to ask people to please put the following access lists in: access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any Luckily, the FBI just called me back to begin work on last months attacks. I guess Egypt Air must be getting wrapped up. I guess I have some stuff to add to our complaints. Actually, given the cause and effect demonstrated by the block, I'm hoping that this will motivate the FBI to do something with ORBS. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any
For core routers and other not-access-list-friendly a #conf t ip route 202.36.148.0 255.255.255.0 nul0 ip route 202.36.147.0 255.255.255.0 nul0 may be a choice. It will, though, generate some SYN-flooding that would have to be dealed with at some point. Does someone know if routes to nul0 will make "ip unicast verify reverse-path" drop packets from those addresses ? Rubens Kuhl Jr.
[ On Thursday, December 16, 1999 at 16:44:19 (-0500), Dean Anderson wrote: ]
Subject: ORBS block
Well, after almost a month of no attacks and a coincident month of ORBS blocking at BBN/NZ link, the block on ORBS has been lifted, and we have started getting relay attacks again. I think thats pretty conclusive evidence that they are the cause of the relay attacks.
It's only evidence that someone thinks you're relays are viable targets. Other than that you've presented no evidence whatsoever.
I'm hoping the removal was an oversight, but I'd like to ask people to please put the following access lists in:
access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any
If I were anywhere near any network doing that I would consider it to be theft of service by the network operator. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, 16 Dec 1999, Greg A. Woods wrote:
access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any
If I were anywhere near any network doing that I would consider it to be theft of service by the network operator.
Greg, If Provider X wants to listen to Dean's loony conspiracy theories and block ORBS from going through their network, how is that thef of service? That would only be true if ORBS pays Provider X for some type of service and then they could fall back to whatever options (arbitration, etc) that their contract allows. Dean, Get off your ass and put your own damn filters on your own router. If you can't do that for a technical reason, just add a bogus route on your mail server to those IPs. If you can't do it for a lack of competency reason, which seems infinitely more plausible at this point, please hire someone with a clue to do it for you. I speak only for myself and my dog. Thanks, -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim@clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------
I can add a little. I know a lot of providers who blocked ORBS's scanning. And this always resulted to the decrease of the headache and decreasing number of relaying attempts. The blocking itself was not always done by IP filters, but on the SMTP level too. It seems ORBS itself must be placed into all black lists -:). On Fri, 17 Dec 1999, Tim Wolfe wrote:
Date: Fri, 17 Dec 1999 08:49:17 -0800 (PST) From: Tim Wolfe <tim@clipper.net> To: Greg A. Woods <woods@weird.com> Cc: nanog@merit.edu Subject: Re: ORBS block
On Thu, 16 Dec 1999, Greg A. Woods wrote:
access-list 104 deny ip 202.36.148.5 0.0.0.255 any access-list 104 deny ip 202.36.147.16 0.0.0.255 any
If I were anywhere near any network doing that I would consider it to be theft of service by the network operator.
Greg,
If Provider X wants to listen to Dean's loony conspiracy theories and block ORBS from going through their network, how is that thef of service? That would only be true if ORBS pays Provider X for some type of service and then they could fall back to whatever options (arbitration, etc) that their contract allows.
Dean,
Get off your ass and put your own damn filters on your own router. If you can't do that for a technical reason, just add a bogus route on your mail server to those IPs. If you can't do it for a lack of competency reason, which seems infinitely more plausible at this point, please hire someone with a clue to do it for you.
I speak only for myself and my dog.
Thanks,
-- Tim
-------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim@clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
[ On Friday, December 17, 1999 at 08:49:17 (-0800), Tim Wolfe wrote: ]
Subject: Re: ORBS block
If Provider X wants to listen to Dean's loony conspiracy theories and block ORBS from going through their network, how is that thef of service? That would only be true if ORBS pays Provider X for some type of service and then they could fall back to whatever options (arbitration, etc) that their contract allows.
It's simple: I find ORBS a valuable service, both for ensuring my own mail servers are secure, as well as for telling me about the issues with my neighbours servers, as well as all the rest around the world. If my provider, or an upstream provider from them, were blocking ORBS, even just their inbound tests, then they would be stealing a service I value. ORBS is not doing anything whatsoever to affect the network layer and network operators and providers should not even see them on their horizon. If e-mail operators are having some kind of trouble with ORBS then that's a different issue, but *not* one that requires network-level intervention, especially not upstream from *anyone*. It is most important that people not confuse these issues. ORBS is not a network thing -- it only affects a single service. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
"Greg A. Woods" wrote:
[ On Friday, December 17, 1999 at 08:49:17 (-0800), Tim Wolfe wrote: ]
Subject: Re: ORBS block
If Provider X wants to listen to Dean's loony conspiracy theories and block ORBS from going through their network, how is that thef of service? That would only be true if ORBS pays Provider X for some type of service and then they could fall back to whatever options (arbitration, etc) that their contract allows.
It's simple: I find ORBS a valuable service, both for ensuring my own mail servers are secure, as well as for telling me about the issues with my neighbours servers, as well as all the rest around the world.
I do suppose that says it all. You don't care to talk to large numbers of people and so you use a service which indistriminantly blocks systems out of spite when asked to stop probing (whether those systems are relays or not). Actually, since your own mail server is configured to block legit mail from my server (though you may not realize it) I wonder about your use of SMTP overall. Your server looks for an A record with the domain sending. This is bogus. I send from a system with an MX record pointing to the system which is sending, and A records for the names in the MX records. This valid config is rejected by your server. I suspect mail through ACM will get to you, though.
If my provider, or an upstream provider from them, were blocking ORBS, even just their inbound tests, then they would be stealing a service I value.
ORBS is not doing anything whatsoever to affect the network layer and network operators and providers should not even see them on their horizon.
If e-mail operators are having some kind of trouble with ORBS then that's a different issue, but *not* one that requires network-level intervention, especially not upstream from *anyone*.
It is most important that people not confuse these issues. ORBS is not a network thing -- it only affects a single service.
-- Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
-- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
[ On Friday, December 17, 1999 at 14:41:48 (-0500), Daniel Senie wrote: ]
Subject: Re: ORBS block
I do suppose that says it all. You don't care to talk to large numbers of people and so you use a service which indistriminantly blocks systems out of spite when asked to stop probing (whether those systems are relays or not).
My security policy says that I should not accept SMTP connections from insecure mailers (i.e. mailers that are susceptible to theft of service attacks). There's nothing "in-discriminant" about it -- it's very discriminating and extremely specific in its intent. If ORBS or something very much like it did not exist to share this valuable information I would be forced to implement similar checks on a dynamic per-connection basis (though hopefully with some form of result caching). I'm sure most *network* operators would agree that one shared service is highly preferred than having every mailer with a similar policy performing such checks regularly on every mailer they communicate with! Indeed most mailer operators would probably feel the same too. I'm obviously not an ISP, but even a few ISPs are using ORBS, and more are considering blocking mail from open relays (either with ORBS or with similar lists). I can't say anything further about these ISPs, of course. Meanwhile those of you who do not choose to, or do not understand how to, work with ORBS (and others like them), will just have to suffer and learn to live with the fact that there are at least two sides to every issue.
Your server looks for an A record with the domain sending. This is bogus. I send from a system with an MX record pointing to the system which is sending, and A records for the names in the MX records. This valid config is rejected by your server.
Perhaps you should re-read RFC 1123 #5.2.5, keeping in mind that it is within my right as the owner of the system in question to ignore any given part of an RFC where I deem it necessary to do so. (i.e. I require your server to adhere to the requirement in RFC 1123 #5.2.5 regardless of the fact that the RFC advises I should not directly refuse connections when it is not met.)
I suspect mail through ACM will get to you, though.
Yes, of course -- their mailer and DNS are correctly configured (though surprisingly little spam gets through -- they've got very effective filters!). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
At 04:22 PM 12/17/99 -0500, Greg A. Woods wrote:
Perhaps you should re-read RFC 1123 #5.2.5, keeping in mind that it is within my right as the owner of the system in question to ignore any given part of an RFC where I deem it necessary to do so.
I find it amusing Mr. Woods believes he can do as he pleases with his mail server, but network operators are not allowed to do as they please with their networks.
Greg A. Woods
TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (OhMyGod - Watch out 'Net, I got enable again! ;-)
At 11:47 AM 12/18/99 -0800, I Am Not An Isp wrote:
Perhaps you should re-read RFC 1123 #5.2.5, keeping in mind that it is within my right as the owner of the system in question to ignore any given part of an RFC where I deem it necessary to do so.
I find it amusing Mr. Woods believes he can do as he pleases with his mail server, but network operators are not allowed to do as they please with their networks.
I think (as I interpret the discussion) it is this way: Anyone can do whatever he wants with his/her mail server. The Network Operator can do whatever he wants with his network, BUT if the network provider has downstream customers, paying for internet connectivity, and the operator filters out part of that connectivity, then the operator has voided the contract (by filtering out a portion of the network the downstream may consider "important") in a manner that allows the downstream to bail out of any such contract. (I think such a filter could be considered "materially altering the service provided" although IANAL). I think that's the gist of things from what I've seen... D
On 12/18/99, Derek Balling <dredd@megacity.org> wrote:
Anyone can do whatever he wants with his/her mail server.
The Network Operator can do whatever he wants with his network, BUT if the network provider has downstream customers, paying for internet connectivity, and the operator filters out part of that connectivity, then the operator has voided the contract (by filtering out a portion of the network the downstream may consider "important") in a manner that allows the downstream to bail out of any such contract. (I think such a filter could be considered "materially altering the service provided" although IANAL).
I think that's the gist of things from what I've seen...
Yup, we've seen those arguments before. It seems common for the operator of said network or server to say "I can do any damned thing I please," and users or customers to whine "no you can't!" without reading the contract. Truth is, in most contracts, the folks who own and operate the equipment can do whatever they please, and if their down- stream users/customers/wankers/whatever don't like it they can find another provider. Personally, as long as policies are clearly spelled out, I have no problem with that. ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "Well, you don't have to worship Cthulhu very long, | | but I'm told it's an interesting experience." | | -- Scott K. Stafford | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
On Fri, 17 Dec 1999, Greg A. Woods wrote:
[ On Friday, December 17, 1999 at 08:49:17 (-0800), Tim Wolfe wrote: ]
Subject: Re: ORBS block
If Provider X wants to listen to Dean's loony conspiracy theories and block ORBS from going through their network, how is that thef of service? That would only be true if ORBS pays Provider X for some type of service and then they could fall back to whatever options (arbitration, etc) that their contract allows.
It's simple: I find ORBS a valuable service, both for ensuring my own mail servers are secure, as well as for telling me about the issues with my neighbours servers, as well as all the rest around the world. If my provider, or an upstream provider from them, were blocking ORBS, even just their inbound tests, then they would be stealing a service I value.
ORBS is not doing anything whatsoever to affect the network layer and network operators and providers should not even see them on their horizon.
If e-mail operators are having some kind of trouble with ORBS then that's a different issue, but *not* one that requires network-level intervention, especially not upstream from *anyone*.
It is most important that people not confuse these issues. ORBS is not a network thing -- it only affects a single service.
-- Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
-- Alex Kamantauskas alexk@tugger.net
On Fri, 17 Dec 1999, Greg A. Woods wrote:
If e-mail operators are having some kind of trouble with ORBS then that's a different issue, but *not* one that requires network-level intervention, especially not upstream from *anyone*.
It is most important that people not confuse these issues. ORBS is not a network thing -- it only affects a single service.
My point, which you so adroitly ignored, was that the "upstream" is under no obligation of any kind NOT to block ORBS from reaching you if they so choose. Your ONLY recourse is if you happen to be a customer of "upstream" in which case you may be able to use your contract to embroil them in a legal battle or you may choose just to take your business elsewhere. If I decide to block Random Company's network from access to mine, and you aren't my customer, tough luck pal. You can dictate my network policies when you pry the keyboard from my cold dead fingers. I speak only for myself and my dog. -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim@clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------
[ On Friday, December 17, 1999 at 14:26:53 (-0800), Tim Wolfe wrote: ]
Subject: Re: ORBS block
My point, which you so adroitly ignored, was that the "upstream" is under no obligation of any kind NOT to block ORBS from reaching you if they so choose. Your ONLY recourse is if you happen to be a customer of "upstream" in which case you may be able to use your contract to embroil them in a legal battle or you may choose just to take your business elsewhere.
Exactly. (though first off I'd make a big stink about it to the service department and see if they wouldn't reconsider on their own accord)
If I decide to block Random Company's network from access to mine, and you aren't my customer, tough luck pal. You can dictate my network policies when you pry the keyboard from my cold dead fingers.
I don't disagree. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (10)
-
Alex Kamantauskas -
Alex P. Rudnev -
Daniel Senie -
Dean Anderson -
Derek Balling -
I Am Not An Isp -
J.D. Falk -
Rubens Kuhl Jr. -
Tim Wolfe -
woods＠most.weird.com