RE: RBL-type BGP service for known rogue networks?
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing. The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of dynamic addresses) all over the world who have domains hosted with us; they also have email aliases for the domains they host here. And while we encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP. POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well. Our NOC staff act -immediately- upon any complaints of spam or forged mail - no one has ever acused us of being a spam-house or anything other than spammer-*unfriendly*. And yet, due to the current well-known limitations of SMTP as currently defined in the standard, their blatant adoption of RFC-violating spammer tactics, and their unwillingness to acknowledge that not every provider offers transport to his userbase (thereby rendering address-based validation unworkable), the ORBS folks decide to tar my organization with the same brush as, say, rr.com. No discussion, no examination of our track record and response-times, nada. Where's the equity in that, I ask you? ----------------------------------------------------------- Roland Dobbins <rdobbins@netmore.net> // 818.535.5024 voice -----Original Message----- From: Peter van Dijk [mailto:petervd@vuurwerk.nl] Sent: Saturday, July 08, 2000 10:15 AM To: nanog@merit.edu Subject: Re: RBL-type BGP service for known rogue networks? On Sat, Jul 08, 2000 at 12:35:14PM -0400, Greg A. Woods wrote:
[ On Saturday, July 8, 2000 at 08:42:41 (-0700), Randy Bush wrote: ]
Subject: Re: RBL-type BGP service for known rogue networks?
ORBS lists open relay by policy. As simple as that. If ORBS is aware
that
you are an open relay, you get listed. ORBS is 100% objective.
as we all know, this is utter horsepucky. orbs goes vigilante crazy and blackholes entire isp blocks over political poweplay nonsense.
Listing a net-block that has several proven open relays within it but which will not allow testing, is not "going vigilante crazy" -- it's a very very reasonable and well thought out reaction (i.e. there is no lesser action possible since the originally tested open relays have been moved to new address space within the block).
Let me explain some things: - ORBS does not blackhole. It lists hosts and sometimes complete netblocks. $administrator can then choose to take any action (or not!) based on these listings. - ORBS lists hosts in several categories. One is 'open relay inputs'. Another is 'open relay outputs' (most open relays will be both). Yet another is 'untested/untestable'. Hosts/netblocks can end up in this last category in two ways: - by request from the admin of that host/netblock - when ORBS finds out that they are being blocked specifically. It is therefore incorrect to state 'ORBS blackholes whole netblocks'. These netblocks are listed *different* from open relays. The admin that decides to use ORBS has a choice to block *only* open relays, or also block hosts that do not want to be tested by ORBS. I hope this clears things up.
It is critically important to also realise that "ORBS" itself doesn't "go crazy" and do these things -- such "rogue net-block" listings are directly a result of pressure from ORBS users. Such users who continue to get spam from relays they've reported to ORBS for testing will complain and put pressure on the ORBS administrators until there is no other choice but to list the entire offending net-block.
Nope. ORBS doesn't do 'user pressure'. Such net-block listings (as 'untestable', not as 'open relay') are only done based on actions/requests by admins responsible for these netblocks.
Use of the term "blackhole" in this context is not only wrong but also misleading. It is very important to understand that ORBS users are free to programmatically ignore, in real time, that section of the ORBS database which lists the so-called "rogue" net-blocks and only use the section of the database which contains actually verified relay results.
Correct, this is what I explained above.
In my humble opinion any admin who permits their mailer to receive any e-mail from a known open relay (even so-called legitimate e-mail, since there's absolutely no way to identify legitimacy at the protocol level) is an accessory to any theft-of-service attack perpetrated on the relay, and is furthermore "guilty" in part of allowing known spam to reach their end users (assuming of course that they are willing to do anything at all in the first place to protect their users from unsolicited junk e-mail). To this end an impartial and independent testing service such as ORBS is critical to the success of such efforts. The other services you mention are valuable, but nowhere near as powerful, and they are far more susceptible to unnecessary delays (time is critical in spam fighting!), and by definition they are more susceptible to human error.
Yes. On the other hand, one might say that you as an admin do not have the right to block *any* mail for your users. This is solved by for example just inserting headers based on ORBS-listing and not outright rejecting mail, and then leaving the choice to your users thru procmail or other per-user filtering means.
Finally it cannot be pointed out enough times that the administrators of the so-called "rogue" blocks need only change their attitudes and co-operate with ORBS in order to make this issue completely go away.
Correct.
Any SMTP service administrator who believes that SMTP port is totally private property is sadly mistaken and should firewall it if they really want it to be private. Being irrational about public testing of public services is, frankly, insane. Public testing by a known independent non-profit agency should be vigorously welcomed by all network admins!
Correct again. AboveNet blackholing ORBS is therefore an action I do not understand, especially since they host MAPS. I see 2 possibilities: - MAPS doesn't test if a reported spamhouse is really an open relay, and is therefore susceptible to forgery. - MAPS does do open relay testing and therefore performs the same 'unsolicited traffic' as ORBS, which would mean they're hypocritic. Greetz, Peter. -- petervd@vuurwerk.nl - Peter van Dijk [student:developer:ircoper]
On Sat, Jul 08, 2000 at 11:16:41AM -0700, Randy Bush wrote:
ORBS forge headers ...
but who cares? responsible admins don't pay attention to orbs.
Randy, why is everything binary with you? Anybody who disagrees with you is either "stupid" or "irresponsible". ORBS is a bad idea in mine and lots of other people's opinions, but that doesn't mean every responsible administrator ignores them. I know very responsible administrators who take ORBS seriously because their customers want to email users of ORBS subscribers. If your customers can't send mail to someone, it would be irresponsible to just not care why at all. Responsible admins don't let ORBS dictate to them, but also don't pretend they don't exist. They're another datum, with the significance varying for each admin.
On Sat, Jul 08, 2000 at 11:02:30AM -0700, rdobbins@netmore.net wrote:
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
They do send notices. Go to www.orbs.org for details. [snip rant about unfairness]
[snip rant about ORBS not being reasonable]
Where's the equity in that, I ask you?
Do you run open relays? If yes, and ORBS lists you, they are correct in what they're doing. Of no, ORBS should not be listing you. If you can say 'no' to 'Do you have open relays?' and 'yes' to 'Does ORBS list you as having open relays?', then something is wrong. I doubt there is. Greetz, Peter. -- petervd@vuurwerk.nl - Peter van Dijk [student:developer:ircoper]
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
The last part of that statement is simply untrue. I got ORBS'd once and they notified me via postmaster@domain. If you don't get notified then you don't have a postmaster account for the domain, and it is you who are in violation of the RFCs. As for the "forge headers in violation" part, they have to test the common variations. Who cares if they do that as a one-off probe. If they were doing it all the time it would be a problem, but once is nothing. Of course, the spammers who are using your server as an open relay are certainly violating that and much more, so if it really bothers you close your freaking relay. ;) I for one was happy for the free and comprehensive testing. It pointed out a whole I had missed in my config. Once patched, I was out of the ORBS database in less than 24 hourse, and was able to get out on my own just by filling out a form on their web site that kicked off an automated retesting. I think ORBS provides an excellent service, and I say that because my experience says that they rely entirely upon factual evidence before they block, and it is easy to get out of the database once you provide evidence that you have fixed your server. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Sat, 8 Jul 2000 rdobbins@netmore.net wrote: Hi, [big 8<]
substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well.
You state that your organization is a hosting toko only. Well, join the club; Peter van Dijk and I both work for the same organization which is also a hosting-only isp. We do not have open relay's in our network. Whenever a colocated server turns out to be an open relay I block port 25 on our border router. Being a hosting-only-party means that all our customers dial in through a dialup-isp. If you would name me one big dialup isp that does not have a relaying smtp server for their customers I might consider your argument a legitimate one. Please do not this is not a flame to you specific. I just feel that the single point of being "just a hosting provider" justifies open relays in a network. -- Sabri Berisha (This is my personal opinion, not that of my employer)
On Sat, 8 Jul 2000, Sabri Berisha wrote:
Please do not this is not a flame to you specific. I just feel that the single point of being "just a hosting provider" justifies open relays in a network.
*g* must have slept not enough If course I ment that the single point of being a hosting toko does *not* justify open relays :) -- Sabri Berisha
Roland (first off, you're missing an 'e' <g>), I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model. Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from. A single ORBS forged header, with the right source info in it, will pass right through our mail system, like it was greased. The whole anti-relay jihad is a fallacious rat-hole populated by rabid self-righteous rats who don't have a clue. If they don't need it then it must not be a valid feature <humph!>. ORBS itself should be RBL'd, IMHO. Using the same sort of mind-set to subjectively BL script-kiddee networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight? That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree that something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution. --- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer
rdobbins@netmore.net: Saturday, July 08, 2000 11:03 AM
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of
encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP.
POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well.
On Sat, Jul 08, 2000 at 09:41:45PM -0700, Rodney Joffe wrote:
Roeland (wth an "e") :-)
"Roeland M.J. Meyer" wrote:
ORBS itself should be RBL'd, IMHO.
It is. Hence the references to Abovenet.
Its not MAPS RBL'd... its Abovenet blocked. There's a difference :-) -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 340% tax? http://www.boycott-the-pumps.com/
The solution is not to open relays but to use an IPSEC tunnel into the internal network. Or you could use SSH port forwarding to accomplish the same thing. If you open relays, the spammers will find and abuse them. IPSEC clients and servers are available commercially. Nortel Networks Contivity Extranet Gateway is one, and Nortel use it themselves. Shiva have a similar product. ----- Original Message ----- From: "Roeland M.J. Meyer" <rmeyer@mhsc.com> To: <rdobbins@netmore.net>; <petervd@vuurwerk.nl>; <nanog@merit.edu> Sent: Sunday, July 09, 2000 12:24 AM Subject: RE: RBL-type BGP service for known rogue networks?
Roland (first off, you're missing an 'e' <g>),
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model. Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
A single ORBS forged header, with the right source info in it, will pass right through our mail system, like it was greased. The whole anti-relay jihad is a fallacious rat-hole populated by rabid self-righteous rats who don't have a clue. If they don't need it then it must not be a valid feature <humph!>. ORBS itself should be RBL'd, IMHO.
Using the same sort of mind-set to subjectively BL script-kiddee networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight?
That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree that something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution.
--- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer
rdobbins@netmore.net: Saturday, July 08, 2000 11:03 AM
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of
encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP.
POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well.
I could list a number of sites, (northgrumm.com et al AeroSpace/DOD clients) where the first step, in security, is to block port 22. In fact, to block ALL encrypted traffic. Those guys see that as a National Security and contract requirements issue <grin>. Those same outfits ban radio xmit/rcv at the guard shack<g>. For other, more civilian organizations, we frequently work with groups that have SA staff that considers that the first step in security is to cut the connection altogether. Failing that, blocking all ports, on all hosts, is the next reflexive step. Eventually, we get down to required ports and proxy servers. The bottom-line is that we've had to go as far as running a VPN on port 80 and that only works if there is a direct path (no proxy). In many organizations, a system isn't considered secure unless port 22 is blocked, at the firewall. It is, after all, the secure port, that must mean that you have to block it to be secure, right? In this sort of environment, we don't usually get assigned internal email accounts, we have to use our own. However, they usually allow proxied port 25 and 110 access but the source address is still theirs. Yes, I already use F-Secure when I can.
From: Dana Hudes: Saturday, July 08, 2000 9:55 PM
The solution is not to open relays but to use an IPSEC tunnel into the internal network. Or you could use SSH port forwarding to accomplish the same thing. If you open relays, the spammers will find and abuse them. IPSEC clients and servers are available commercially. Nortel Networks Contivity Extranet Gateway is one, and Nortel use it themselves. Shiva have a similar product.
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com> Sent: Sunday, July 09, 2000 12:24 AM
Roland (first off, you're missing an 'e' <g>),
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model. Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
A single ORBS forged header, with the right source info in it, will pass right through our mail system, like it was greased. The whole anti-relay jihad is a fallacious rat-hole populated by rabid self-righteous rats who don't have a clue. If they don't need it then it must not be a valid feature <humph!>. ORBS itself should be RBL'd, IMHO.
Using the same sort of mind-set to subjectively BL script-kiddee networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight?
That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree that something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution.
--- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer
rdobbins@netmore.net: Saturday, July 08, 2000 11:03 AM
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of
encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP.
POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well.
[ On Sunday, July 9, 2000 at 08:22:46 (-0700), Roeland M.J. Meyer wrote: ]
Subject: RE: RBL-type BGP service for known rogue networks?
In many organizations, a system isn't considered secure unless port 22 is blocked, at the firewall. It is, after all, the secure port, that must mean that you have to block it to be secure, right?
Yes, that's exactly right, but not for the reasons you imply. If the primary concern of a security policy is that covert channels must be prevented then it is absolutely mandatory that port-22 be blocked since it is by definition a covert channel. However having any kind of Internet connection, proxied or not, into a site where sensitive information must not be allowed to be leaked is in effect a violation of the policy. Unfortunately we're rapidly approaching (if we're not already there) a state of affairs where it is impossible to technically prevent inbound and outbound covert channels wherever people are required to interact in a privileged way with security sensitive systems. A paper given at last year's ACM New Security Paradigms Workshop by Dean Povey ("Optomistic Security: A New Access Control Paradigm") suggests that it might be better to adopt the view that security officers should "Make the users ask forgivness not permission." Whether this paradigm can successfully be delployed in top secret (or higher) environments or not is yet to be discussed. I suspect it can but then I'm not an expert in traditional forms of high security. -- 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>
woods@weird.com said:
Unfortunately we're rapidly approaching (if we're not already there) a state of affairs where it is impossible to technically prevent inbound and outbound covert channels
No. We are just rapidly approaching the point where people realize it has always been the case that this is impossible. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)
Blocking SSH is a weak solution. Many places I know allow telnet through their firewalls and block ssh. Since I never allow telnet on any of my servers I run SSH on both ports 22 and 23 so that these people can still reach our servers. Unless you are running an application firewall that explicitly checks the telnet protocol then you are not safe. The same ideas have been around for years on port 80. MS DCOM Tunneling is one of the worst allowing full application client to server communication in packets wrapeed by http headers so that they can traverse your proxy or firewall's on port 80. I am still waiting for the trojan that makes use of these features and the intrinsic MS Dcom security model. Derrick
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alex Bligh Sent: Sunday, July 09, 2000 3:43 PM To: Greg A. Woods Cc: rmeyer@mhsc.com; nanog@merit.edu Subject: Re: "top secret" security does require blocking SSH
woods@weird.com said:
Unfortunately we're rapidly approaching (if we're not already there) a state of affairs where it is impossible to technically prevent inbound and outbound covert channels
No. We are just rapidly approaching the point where people realize it has always been the case that this is impossible.
-- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)
"Derrick" <Derrick@anei.com>
Blocking SSH is a weak solution.
I wrote:
No. We are just rapidly approaching the point where people realize it has always been the case that this is impossible.
I meant it has always been the case that blocking covert channels of communication was technically impossible. You can tunnel ssh or equivalent through email wordcounts if you really feel the need. I'm not an expert, but there is good information theory that says once you allow more than trivial bit rates in/out of an organization, blocking covert communication encapsulated one way or another becomes extremely hard. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)
Actually, it isn't so hard. Northgrum.com has firewall, moat, alligators, and free-fire kill-zone <g>. I will also never take them on as a client again because of it. I just can't be disconnected from my business in chunks of time that large. Oh yeah, they also don't allow off-site work. Aerospace/DOD is feeling the pinch though. But, this latest LLNL thing has really caused them to think long and hard about some serious issues. Yes, if there is any way to bypass the wall, including Xircom CardBus (LAN port plugged into the LAN and modem port connected to a Nokia 6185, via DLR3 datacable, dialed into an external Internet server.) then covert ops are assured, as well as almost undetectible. The only way to stop that is a mil-grade PCS jammer. The Nokia uses spread-spectrum so intercepts are very difficult. I wonder if anyone has suggested this to the investigators of the Nat labs?
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alex Bligh Sent: Sunday, July 09, 2000 1:12 PM To: Derrick Cc: nanog@merit.edu Subject: Re: "top secret" security does require blocking SSH
"Derrick" <Derrick@anei.com>
Blocking SSH is a weak solution.
I wrote:
No. We are just rapidly approaching the point where people realize it has always been the case that this is impossible.
I meant it has always been the case that blocking covert channels of communication was technically impossible. You can tunnel ssh or equivalent through email wordcounts if you really feel the need. I'm not an expert, but there is good information theory that says once you allow more than trivial bit rates in/out of an organization, blocking covert communication encapsulated one way or another becomes extremely hard.
-- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)
Alex Bligh said:
need. I'm not an expert, but there is good information theory that says once you allow more than trivial bit rates in/out of an organization, blocking covert communication encapsulated one way or another becomes extremely hard.
On Sun, 9 Jul 2000, Roeland M.J. Meyer wrote:
Actually, it isn't so hard. Northgrum.com has firewall, moat, alligators, and free-fire kill-zone <g>.
Are you referring to what Alex said when you say `it isn't so hard'? If so, I'm confused; could you elaborate (what good would a firewall, moat or other do)? If not, ignore this. :) -- Christopher Palmer : Random Coding Guy : bitstream.net (my other car is a cdr)
[ On Sunday, July 9, 2000 at 15:59:51 (-0400), Derrick wrote: ]
Subject: RE: "top secret" security does require blocking SSH
Blocking SSH is a weak solution. Many places I know allow telnet through their firewalls and block ssh.
Now that's truly insane. I can't even begin to imagine how a security policy could be worded such that this would be the outcome in implementation!
Since I never allow telnet on any of my servers I run SSH on both ports 22 and 23 so that these people can still reach our servers. Unless you are running an application firewall that explicitly checks the telnet protocol then you are not safe.
Hmmm.... as much as I do like to force protocols to run on their registered ports, running sshd on port 23 in some situations might indeed be better than nothing....
The same ideas have been around for years on port 80. MS DCOM Tunneling is one of the worst allowing full application client to server communication in packets wrapeed by http headers so that they can traverse your proxy or firewall's on port 80. I am still waiting for the trojan that makes use of these features and the intrinsic MS Dcom security model.
As I mentioned to a friend just yesterday, I have seen IP-over-email demonstrated and I've even heard tell of someone doing it with UUCP as the mail transport.... ;-) Now that the Church Of Instantaneous Propogation has almost won its final battle I'd even bet IP-over-email is faster than bare telnet over some dialups! ;-) -- 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 Sunday, July 9, 2000 at 20:43:13 (+0100), Alex Bligh wrote: ]
Subject: Re: "top secret" security does require blocking SSH No. We are just rapidly approaching the point where people realize it has always been the case that this is impossible.
Yeah, that too.... sigh.... -- 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>
In the last couple of days I have gone though the Smurf Amplifier Registry at http://www.powertech.no/smurf/ and checked which ASNs are currently advertising the networks listed there. My listing by ASN is on my web page at: http://www.darkmere.gen.nz/2000/0712.txt Please check this list for your own (and your peers/downstreams/friends) ASN and fix. You should then goto the Powertech site and check from there, if there is no problem then the Smurf Amplifier Registry will delete you from their list. I have already emailed the top 10 ASNs but I don't have a nice easy way to email the other 1000 so I have decided here would be the best start. Depending on how things go I might check again in about a month. Disclaimer 1: There are a few bugs in the data, ( I know /159s don't exist) Disclaimer 2: I didn't scan the networks, I just took the existing list and looked them up. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz System/Network Admin. | | Home: simon@darkmere.gen.nz Ihug Limited, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Thus spake "Greg A. Woods" <woods@weird.com>
If the primary concern of a security policy is that covert channels must be prevented then it is absolutely mandatory that port-22 be blocked since it is by definition a covert channel.
Blocking that specific port won't prevent covert communication; it just makes it harder to discover. I'd rather let the "hackers" self-identify so I know who to watch. It is common practice to use SSH on port 23 to bypass typical corporate firewalls or port 443 (with appropriate scripts) for the more thorough ones. Other methods are commonly discussed on SSH users' mailing lists; intentionally defeating typical corporate security (from the inside) is frighteningly easy. More esoteric methods require tunneling of IP packets via ICMP errors, lone fragments, DNS requests/reponses, and the padding at the end of legitimate HTTP TCP segments. If you look hard enough, you can find people doing it.
However having any kind of Internet connection, proxied or not, into a site where sensitive information must not be allowed to be leaked is in effect a violation of the policy.
Most of the "secure" sites I'm aware of require physical separation of "secure" and "insecure" networks. Even email requires SneakerNet.
A paper given at last year's ACM New Security Paradigms Workshop by Dean Povey ("Optomistic Security: A New Access Control Paradigm") suggests that it might be better to adopt the view that security officers should "Make the users ask forgivness not permission." Whether this paradigm can successfully be delployed in top secret (or higher) environments or not is yet to be discussed. I suspect it can but then I'm not an expert in traditional forms of high security.
We have enough preventable leaks as it is; letting well-intentioned but naive users devise their own policies doesn't give me a warm fuzzy feeling. Any system, no matter how "secure", can be broken into with sufficient determination and resources; the sensitivity of a break-in usually determines how difficult one can afford to make that task. I'd be happy if the folks in the "security industry" would recognize that principle, as most I've met are under the impression they can mandate perfect security. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, HCOE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com
On Sat, 8 Jul 2000, Roeland M.J. Meyer wrote:
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model.
I can understand your grief. However, I expect you to have the same commen sense most of us have and you will probably know who to blame for this. Do you wish to blame the spammers or the volunteers who fight spam?
Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
I know of an isp in the netherlands that has it's relay open for their users from all over the world. They built this system that checks if you have logged on using pop3 at least 1 time in the lasts 5 minutes. If you did; you can relay. If you did not; your mail will be rejected. http://www.dds.nl is the project; their admins can tell you more.
A single ORBS forged header, with the right source info in it, will pass right through our mail system, like it was greased. The whole anti-relay jihad is a fallacious rat-hole populated by rabid self-righteous rats who don't have a clue. If they don't need it then it must not be a valid feature <humph!>. ORBS itself should be RBL'd, IMHO.
Well now, I think we can have a discussion without calling each other bad names, can't we?
Using the same sort of mind-set to subjectively BL script-kiddee networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight?
You can find the criteria on http://www.orbs.org
That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree that something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution.
You are free to come with a proposal? -- Sabri Berisha
Sabri Berisha: Sunday, July 09, 2000 8:27 AM
On Sat, 8 Jul 2000, Roeland M.J. Meyer wrote:
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model.
I can understand your grief. However, I expect you to have the same commen sense most of us have and you will probably know who to blame for this. Do you wish to blame the spammers or the volunteers who fight spam?
Now that you mention it, yes I do. Spammers don't block access. The RBL, which my systems subscribe to, only lists systems that are PROVEN to originate or relay spam. ORBS simply is on the "close all relays" jihad even if the system never saw spam. This is very Napoleanic, not something that I can condone. Also, as I said, there are valid reasons to allow third-party relays. In fact, they are even required, depending on circumstances. The ORBS effort, at forcing closure of ALL relays, and their faulty testing (see prior message), actually creates a security problem. If you don't see requireing internal confidential email to go through an untrusted IAP mail hub as a security issue then we have nothing more to talk about.
Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
I know of an isp in the netherlands that has it's relay open for their users from all over the world. They built this system that checks if you have logged on using pop3 at least 1 time in the lasts 5 minutes. If you did; you can relay. If you did not; your mail will be rejected. http://www.dds.nl is the project; their admins can tell you more.
Using the same sort of mind-set to subjectively BL
SMTP AUTH is more useful. We are looking into POP/SSL. POP before SMTP is consiidered a non-starter. script-kiddee
networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight?
You can find the criteria on http://www.orbs.org
That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree
The criteria is arguable, but more importantly, where is the oversight? that
something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution.
You are free to come with a proposal?
How about setting up a REAL organization for once, rather than these ad hoc hanging committees? You know, incorporate a non-profit, feed it $$$ and watch it grow? Require membership approval, oversight, etc.? You know, legitimate operations.
How about setting up a REAL organization for once, rather than these ad hoc hanging committees? You know, incorporate a non-profit, feed it $$$ and watch it grow? Require membership approval, oversight, etc.? You know, legitimate operations.
Nahhhh... "Holy Jihad" is -way- more fun. ROFL ;)
Also, as I said, there are valid reasons to allow third-party relays. In fact, they are even required, depending on circumstances.
Sorry... don't buy it. Upgrade your MTA to sendmail 8.10 or above and have your customers use current versions of their MUA's if they wish to travel. SMTP-AUTH is your friend and it appears to be fairly well supported now within the various consumer MUA's. (Admittedly, this time last year that wasn't necessarily the case) I fail to see an occurrence where an open relay is "necessary". Can you describe one for me? D
From: Derek J. Balling [mailto:dredd@megacity.org] Sent: Sunday, July 09, 2000 10:15 AM
Also, as I said, there are valid reasons to allow third-party relays. In fact, they are even required, depending on circumstances.
Sorry... don't buy it. Upgrade your MTA to sendmail 8.10 or above and have your customers use current versions of their MUA's if they wish to travel. SMTP-AUTH is your friend and it appears to be fairly well supported now within the various consumer MUA's. (Admittedly,
Can you explain to my how we made the transition from third-party relays to open-relays? Or is it that ORBS considers the "third-party relay == open-relay" to hold true? I don't agree with the latter and this is the source of my dislike for ORBS. ORBS doesn't properly consider that case, nor does it test for that case. That is the prime fallacy behind ORBS operations. Every case that I've made is for controlled third-party relaying in both SMTP and POP. this
time last year that wasn't necessarily the case)
I fail to see an occurrence where an open relay is "necessary". Can you describe one for me?
I've already done this, bring counter examples or clearly refute the examples given. BTW, sendmail 8.10 is still in beta. Also, even when one uses POP/SSL one still hits the anti-relay blocks if you are calling in from a foriegn network (XTND XMIT case). In addition, direct SMTP, from many popular dialup blocks, hits many anti-spam filters, regardless of content (ie ix.netcom.com, juno.com, aol.com).
On Sun, 09 Jul 2000 10:36:44 PDT, "Roeland M.J. Meyer" said:
I've already done this, bring counter examples or clearly refute the examples given. BTW, sendmail 8.10 is still in beta. Also,
A clarification: Sendmail 8.10 is out (and at release 8.10.2 - I found an AIX problem that caused 8.10.1, and the Linux kernel capabilities bug caused 8.10.2). Sendmail 8.10 provides minimal SMTP AUTH support - it allows for authentication, but does not support the encryption layer stuff. Sendmail 8.11 is currently in very late beta. Sendmail 8.11 will include further crypto support - most noteably the support for STARTTLS (RFC2487) and the encryption layer of SMTP AUTH. This was originally intended to be part of 8.10, but the US regulations on the export of crypto code were changed too late in the 8.10 beta cycle. I don't work for Sendmail Inc, I'm just an alpha/beta tester for them.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
On the ORBS Jihad The biggest problem with ORBS is the ASSUMPTION that we are all running sendmail. MANY corporate sites use SMTP gateways which do not exhibit the same behavior as sendmail for instance Notes 5.0.x will accept a UCE message and quietly drop it once it realizes that this is a UCE message if the UCE filters are enabled. This behavior will get you on the ORBS list and until Lotus creates a Notes/Domino gateway which fully emulates sendmail you cannot get off the ORBS list. or create a RELAY server which is based on current revisions of sendmail it is not an open relay but it is a relay nonetheless. Talk of IPsec tunnels is a good idea except does the infrastructure support it and is it LEGAL in some countries in the EU encryption by private citizens/organizations is illegal so we are back to needing to allow relay from defined netblocks. "Derek J. Balling" wrote:
Also, as I said, there are valid reasons to allow third-party relays. In fact, they are even required, depending on circumstances.
Sorry... don't buy it. Upgrade your MTA to sendmail 8.10 or above and have your customers use current versions of their MUA's if they wish to travel. SMTP-AUTH is your friend and it appears to be fairly well supported now within the various consumer MUA's. (Admittedly, this time last year that wasn't necessarily the case)
I fail to see an occurrence where an open relay is "necessary". Can you describe one for me?
D
----- Original Message ----- From: Scott McGrath <s_mcgrath@bexair.com>
The biggest problem with ORBS is the ASSUMPTION that we are all
running
sendmail. MANY corporate sites use SMTP gateways which do not exhibit the same behavior as sendmail for instance Notes 5.0.x will accept a UCE message and quietly drop it once it realizes that this is a UCE message if the UCE filters are enabled. This behavior will get you on the ORBS list and until Lotus creates a Notes/Domino gateway which fully emulates sendmail you cannot get off the ORBS list.
I am not an ORBS fan. However, in the interest of factual accuracy, I have not noticed this to be true (and there are Notes SMTP gateways on the network I run). Thre are some obscure relay syntaxes that can cause Notes to relay even if you have relaying disabled. If you don't take steps to eliminate those, ORBS will consider you a relay. But if you configure it to block all relaying, you will not get on ORBS, even though the Notes SMTP gateway will gladly accept a relay message, and then drop it later. You don't get on the ORBS relay list unless and until the test message actually gets relayed. -- Brett
Looking for a C&W USA engineer with "enable" authority. (Or at least supervises people with "enable" authority) I have some questions about the N3 nodes in Georgia and Texas. Please contact me off list. -brad (Rural CNE) bwalters@inet-direct.com
On Sun, 9 Jul 2000, Roeland M.J. Meyer wrote:
Sabri Berisha: Sunday, July 09, 2000 8:27 AM
I can understand your grief. However, I expect you to have the same commen sense most of us have and you will probably know who to blame for this. Do you wish to blame the spammers or the volunteers who fight spam?
Now that you mention it, yes I do. Spammers don't block access. The RBL, which my systems subscribe to, only lists systems that are PROVEN to originate or relay spam. ORBS simply is on the "close all relays" jihad even if the system never saw spam.
It is not about a war against open relays. It's about giving a network admin the *choice* to accept mail from open relays.
This is very Napoleanic, not something that I can condone. Also, as I said, there are valid reasons to allow third-party relays.
Allowing third-party relays may affect more than your own users...
If you don't see requireing internal confidential email to go through an untrusted IAP mail hub as a security issue then we have nothing more to talk about.
Ever heared of pgp?
You can find the criteria on http://www.orbs.org
The criteria is arguable, but more importantly, where is the oversight?
What do you mean by oversight?
You are free to come with a proposal?
How about setting up a REAL organization for once, rather than these ad hoc hanging committees? You know, incorporate a non-profit, feed it $$$ and watch it grow? Require membership approval, oversight, etc.? You know, legitimate operations.
Like I said; come with a proposal and we can all see if we can agree on it? -- Sabri Berisha
Sabri Berisha: Sunday, July 09, 2000 10:15 AM
On Sun, 9 Jul 2000, Roeland M.J. Meyer wrote:
Sabri Berisha: Sunday, July 09, 2000 8:27 AM
I can understand your grief. However, I expect you to have the same commen sense most of us have and you will probably know who to blame for this. Do you wish to blame the spammers or the volunteers who fight spam?
Now that you mention it, yes I do. Spammers don't block access. The RBL, which my systems subscribe to, only lists systems
that
are PROVEN to originate or relay spam. ORBS simply is on the "close all relays" jihad even if the system never saw spam.
It is not about a war against open relays. It's about giving a network admin the *choice* to accept mail from open relays.
The problem is that what ORBS calls an open relay may, in fact, only be a third-party relay to limited net-blocks.
This is very Napoleanic, not something that I can condone. Also, as I said, there are valid reasons to allow third-party relays.
Allowing third-party relays may affect more than your own users...
If you don't see requireing internal confidential email to go through an untrusted IAP mail hub as a security issue then we have nothing more to talk about.
Ever heared of pgp?
Yep ... and that dog don't hunt well ... Lottsa reasons. We have X.509 mail certs but I don't want to predict what our marketing types wind up setting their Outlook2K to after the third mail hub address change. Not all of us have little beanies with propellers on them.
You can find the criteria on http://www.orbs.org
The criteria is arguable, but more importantly, where is the oversight?
What do you mean by oversight?
You are free to come with a proposal?
How about setting up a REAL organization for once, rather
Who watches the watchers? than
these ad hoc hanging committees? You know, incorporate a non-profit, feed it $$$ and watch it grow? Require membership approval, oversight, etc.? You know, legitimate operations.
Like I said; come with a proposal and we can all see if we can agree on it?
I think I just did <g>. Look faster as it comes by again... Volunteers tend to join these things because they are true believers. It's about time we had some objective paid professional help on these sorts of things.
[ On Sunday, July 9, 2000 at 09:04:51 (-0700), Roeland M.J. Meyer wrote: ]
Subject: RE: RBL-type BGP service for known rogue networks?
Now that you mention it, yes I do. Spammers don't block access. The RBL, which my systems subscribe to, only lists systems that are PROVEN to originate or relay spam. ORBS simply is on the "close all relays" jihad even if the system never saw spam. This is very Napoleanic, not something that I can condone.
I'm sorry but any open relay, exploited or not, presents a very real risk not only to itself but to the entire Internet (or at least to those parts of the Internet that are not willing to accept unsolicited junk e-mail and other forms of e-mail-based abuse, such as viruses/trojans and so on). Indeed it are those that have not yet been exploited which are now the larger risk since those that have been exploited are either shut down or listed in other more widely used blocking lists. As such I cannot condone allowing any open relay to function without question especially if it has not yet been exploited, because eventually it will be exploited (even if only to relay one single unwanted message). Refusing all e-mail from all known open relays is the only way I know to at least try to ensure that the operators of such a relays learn that they are operating insecure systems that present very real risks to the rest of the Internet community. If they are unwilling to fix their open relay after being notified of it then that's even more reason to continue to refuse all e-mail originating from it. The more people who use ORBS the fewer open relays we will have to endure. If you can show me a more effective way of forcing admins who run open relays to either shut them down or secure them *before* they are ever exploited then I will gladly champion it (and of course use it too!). This isn't just about spam any more! I'm willing to bet that the next wave of actual e-mail delivered exploits will be initiated through open relays that have not yet been used to deliver spam and which are not yet even listed in ORBS. Now that IMRSS is gone we can only thank the spammers for discovering open relays and causing them to be listed in ORBS before they are used for even more nefarious purposes (not that I'm condoning spam in any way whatsoever, of course!). -- 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 Sun, Jul 09, 2000 at 03:29:44PM -0400, Greg A. Woods wrote:
As such I cannot condone allowing any open relay to function without question especially if it has not yet been exploited, because eventually it will be exploited (even if only to relay one single unwanted message).
Yes, but you're so paranoid that you don't accept email from boxes that HELO themselves as a CNAME.
[ On Sunday, July 9, 2000 at 15:45:27 (-0400), Shawn McMahon wrote: ]
Subject: Re: RBL-type BGP service for known rogue networks?
Yes, but you're so paranoid that you don't accept email from boxes that HELO themselves as a CNAME.
actually that's for a different reason -- and no I don't believe in allowing for contradictions in the RFCs! ;-) -- 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 Sun, Jul 09, 2000 at 08:24:23PM -0400, Greg A. Woods wrote:
Yes, but you're so paranoid that you don't accept email from boxes that HELO themselves as a CNAME.
actually that's for a different reason -- and no I don't believe in allowing for contradictions in the RFCs! ;-)
Unfortunately, it allows for contradictions in this discussion. At least one pro-ORBS person has stated that individuals should make direct SMTP connections instead of using their provider's server, and they could thus avoid being subject to ORBS testing of their provider. Oh, but sorry; if I do that, I can't send Greg A. Woods email, because his system doesn't recognize the value in my system having the name "oa.eiv.com" all the time, instead of me hacking together sed scripts to change my sendmail config to read something like "user1432.fl.sprint-hsd.net" every time I get a new dynamic IP. My SMTP server doesn't relay, PLUS it's firewalled to block inbound connections entirely except for where I want them to come from. But I still can't email various ORBS people because they're a bunch of paranoids. If I switch to using my provider's SMTP server, now I have a security issue because it's going through a server I don't control and which could conceivably screw up and get itself ORBS-listed at any moment, completely outside my control. So, one way I risk not being able to email people, and the other way I risk the same thing. Screw it; I will run my systems the way I see fit. ORBS can go wall themselves off from the Internet as much as they like. Hell, be like Fidonet if you want and try to pretend the Internet doesn't exist or is just a fad. Maybe I'll open my server up to relay; since it jumps around, you won't be able to lock it off without cutting off the entirety of Sprint's DSL lines.
[ On Sunday, July 9, 2000 at 20:51:23 (-0400), Shawn McMahon wrote: ]
Subject: Re: RBL-type BGP service for known rogue networks?
Unfortunately, it allows for contradictions in this discussion.
No, it doesn't, at least not so long as everyone understands the differences in different policy requirements. I happen to have several separate and distinct policy requirements for my SMTP server(s): - don't ever accept e-mail from any known open relay or any network block which has known open relays but won't allow finer testing. - don't ever accept e-mail from any known dial-up address. - don't ever accept e-mail from any known spammer. - don't ever allow a remote SMTP server to forge its hostname. - don't ever allow the sender address domain to be invalid.
At least one pro-ORBS person has stated that individuals should make direct SMTP connections instead of using their provider's server, and they could thus avoid being subject to ORBS testing of their provider.
Oh, but sorry; if I do that, I can't send Greg A. Woods email, because his system doesn't recognize the value in my system having the name "oa.eiv.com" all the time, instead of me hacking together sed scripts to change my sendmail config to read something like "user1432.fl.sprint-hsd.net" every time I get a new dynamic IP.
You've confused my policy requirements. Please see above.
If I switch to using my provider's SMTP server, now I have a security issue because it's going through a server I don't control and which could conceivably screw up and get itself ORBS-listed at any moment, completely outside my control.
Use PGP and encrypt your e-mail if you want security and control. Either that or buy yourself a real Internet connection with a static address and run your own *real* SMTP server. -- 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 Sun, Jul 09, 2000 at 10:30:56PM -0400, Greg A. Woods wrote:
I happen to have several separate and distinct policy requirements for my SMTP server(s):
- don't ever accept e-mail from any known open relay or any network block which has known open relays but won't allow finer testing.
- don't ever accept e-mail from any known dial-up address.
- don't ever accept e-mail from any known spammer.
- don't ever allow a remote SMTP server to forge its hostname.
- don't ever allow the sender address domain to be invalid.
None of which are the case here. The case here is that eiv.com is under my control, but the reverse lookup for the address is not. My hostname is not forged, it's legitimate and it resolves to my proper IP address via RFC-compliant means. If you lookup oa.eiv.com you'll resolve the IP unless your DNS is seriously broken.
Either that or buy yourself a real Internet connection with a static address and run your own *real* SMTP server.
Hence the discrepency in what you folks say in one conversation versus another. Sorry, I'm not spending an extra couple of hundred dollars a month on my connection for my home boxes just so I can send email to a few nuts. To even suggest that ADSL through the only available provider isn't enough of a "real" connection for a home user, and that they should instead get a T1 or something, is beyond ridiculous. Or what, am I supposed to switch to a 56k dialup that charges more for a static IP than my ADSL costs, just so I can email you? Get over yourself, Greg. I'm doing it the right way. You're paranoid. Them's the facts, like 'em or not.
[ On Monday, July 10, 2000 at 09:26:28 (-0400), Shawn McMahon wrote: ]
Subject: Re: RBL-type BGP service for known rogue networks?
None of which are the case here.
Agreed. However I should have listed the other requirement that I thought was self-obvious since we're talking about SMTP here. I.e. I don't ever accept e-mail from anything less than the most strictly conforming SMTP implementations. You're violating part one of RFC 1123 section #5.2.5. The name given by your SMTP server in the HELO "MUST" be a canonical hostname. It must not be a CNAME. To bend the meaning a bit, as Postfix says, "503 polite people say hello first".
The case here is that eiv.com is under my control, but the reverse lookup for the address is not.
No problem.
My hostname is not forged, it's legitimate and it resolves to my proper IP address via RFC-compliant means. If you lookup oa.eiv.com you'll resolve the IP unless your DNS is seriously broken.
Indeed it does. $ host -t a oa.eiv.com oa.eiv.com CNAME eiv.myip.org eiv.myip.org A 209.26.240.172 Unfortunately as you can see it goes through a CNAME first and that means it's illegal to use in an SMTP HELO greeting (or as an NS target). Why you do this nonsensical mapping in the first place is beyond me. Either do your own dynamic DNS yourself and declare a proper A record and be done with it, or just announce as eiv.myip.org and forget it. The name will only appear in a Received header and it'll usually be accompanied by the name given in the in-addr zone anyway so I really don't understand why you're trying to break SMTP for this reason.
To even suggest that ADSL through the only available provider isn't enough of a "real" connection for a home user, and that they should instead get a T1 or something, is beyond ridiculous.
Boy do you ever read the wrong things into other peoples words a lot! Since when does "real connection" equal ADSL, T1 or whatever!?!?!?!? I had a *real* connection over 28.8Kbps for several years! A real Internet connection has nothing to do with bandwidth and everything to do with network numbers and routing. My cable modem is much faster but it is not a real Internet connection (even though it does have a static IP#!). The tunnel through it is "real" though.... :-) -- 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 Mon, Jul 10, 2000 at 11:10:35AM -0400, Greg A. Woods wrote:
However I should have listed the other requirement that I thought was self-obvious since we're talking about SMTP here. I.e. I don't ever accept e-mail from anything less than the most strictly conforming SMTP implementations. You're violating part one of RFC 1123 section #5.2.5. The name given by your SMTP server in the HELO "MUST" be a canonical hostname. It must not be a CNAME.
Oh, you wanna go there? 5.2.5 HELO Command: RFC-821 Section 3.5 The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter. The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. Hmm. MUST NOT refuse. Who's violating the RFC here, again? *ANYBODY* using sendmail from a dynamic IP is either going to do this, or worse. RFC 1123 requires you to live with it. If you choose not to, don't wave the damn RFC around like a magic shield. CNAMEs are "valid principal host domain name[s]". Nothing in the RFC says it can't be a CNAME, but something in the RFC says you have to accept it even if it's flat-out wrong or a lie. Your thin ice just cracked, Greg. Admit you're wrong and get on with your life. You're not running an RFC 1123-compliant mail setup at present.
[ On Monday, July 10, 2000 at 11:38:23 (-0400), Shawn McMahon wrote: ]
Subject: Re: RBL-type BGP service for known rogue networks?
Oh, you wanna go there?
Yes. (Been there, done it, wrote the book! ;-)
Hmm. MUST NOT refuse. Who's violating the RFC here, again?
Well, since I'm free to implement policies that affect my own system(s), you loose, not me. Fix your DNS or your mailer and we both win.
*ANYBODY* using sendmail from a dynamic IP is either going to do this, or worse. RFC 1123 requires you to live with it.
Wrong. On both counts. (though for different reasons)
If you choose not to, don't wave the damn RFC around like a magic shield.
Since I was using the Internet at the time that RFC was written, though unfortunately not directly involved in its writing, unfortunately, I can fully understand the meaning of that apparent self-contradiction. Nerarly a dozen years ago there were different pressures on RFC writers. Most every sane person I know now understands that the so-called robustness principle defined in RFC 1123 MUST not be used to ignore security issues. Although forging a HELO name isn't exactly fraud, it's very close, and therefore it's definitely a security issue (the risks are relatively low, but there's more than ample evidence that people continue to use it for illicit purposes in an ongoing basis).
CNAMEs are "valid principal host domain name[s]".
No, bzzt, wrong! CNAMEs can point at host domain names, but they are definitely not anything like host domain names! Host domain names are only those that return A RRs.
Nothing in the RFC says it can't be a CNAME, but something in the RFC says you have to accept it even if it's flat-out wrong or a lie.
Sorry, but you've leapt over a set with your misunderstanding above and therefore the remainder of your logic falls to pieces completely. -- 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 Saturday, July 8, 2000 at 21:24:28 (-0700), Roeland M.J. Meyer wrote: ]
Subject: RE: RBL-type BGP service for known rogue networks?
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful).
Too bad for them -- they could easily have implemented any one of a half dozen available solutions that would have allowed success. SMTP AUTH is only one of the possibilities and even if it's the best one it's not worth worrying over if it's not viable. Use one of the other viable solutions and you can be in business today!
The anti-relay bunch are killing a valid business model.
That's completely untrue. Those are very poor excuses to use when they result in presenting very real risks to the entire Internet as a whole.
Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block.
VPNs are child's play now, and inexpensive to deploy. Please use them!
Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
That's idiotic. Please use the tools at your disposal instead of increasing the risk you present to the entire Internet as a whole! -- 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 (22)
-
Alex Bligh -
Bradly Walters -
Brett Frankenberger -
Christopher Palmer -
Dana Hudes -
Derek J. Balling -
Derrick -
Eric A. Hall -
John Payne -
Peter van Dijk -
Randy Bush -
rdobbins＠netmore.net -
Richard Irving -
Rodney Joffe -
Roeland M.J. Meyer -
Sabri Berisha -
Scott McGrath -
Shawn McMahon -
Simon Lyall -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu -
woods＠weird.com