RE: RBL-type BGP service for known rogue networks?

["Roeland M.J. Meyer" <rmeyer () mhsc com>]

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.