> And, yet, this can be accomplished without fully restricting
> outgoing packets, though granted, it takes more foreknowledge and
> dilligence then a full deny/allow some.
Unless by "foreknowledge", you mean some mystical capacity to
anticipate what new threat is going to surface next month, then I
have to disgree with your conclusion. And if you *do* mean that,
then I don't accept the premises that allow that conclusion.
As far as I can see, the argument that you don't need outbound
restrictions because you trust your users is as misplaced as the
argument that you don't need a condom because you trust your sexual
partner. It's not about whether you TRUST them, it's about whether
you CARE ABOUT them (or not, as the case might be).
This doesn't just involve trusting *your* users, but trusting
everyone who can get some code they wrote executed on an internal
machine. That's *at least* all the developers of OSes your users run
on any device that plugs (or wirelesses) into the network, all the
developers of applications your users use, all the builders of web
pages your users ever visit, all the authors of macros in documents
attached to email your users receive.
The exceptions -- that you claim can be allowed! -- would require,
as far as I can see, that ALL of these people be BOTH utterly
trustworthy and virtually omniscient. I find it difficult to believe
that there exist useful numbers of members of the intersection set.
Convincing me otherwise will require a bit more evidence than a
general dig at "point and clickers" -- it has been 20 years or more
since I last knew anyone who thoroughly knew every nuance of every
program on their favourite box.
David Gillett
On 25 May 2001, at 1:43, Ron DuFresne wrote:
> And, yet, this can be accomplished without fully restricting outgoing
> packets, though granted, it takes more foreknowledge and dilligence then a
> full deny/allow some. It all depends upon how much work the security
> admin is willing to invest, and how paranoid they are about the data and
> systems they are protecting, in addition to a very knowledgeable set of
> internal users. This latter, very knowledgeable..., is not easy or often
> found in point and clickers, in either the M$ or redhat realm, for they
> tend to have no clue about what happens under the hood, nor a clue about
> the basics, let alone the hidden toys their OS designers put under those
> hoods for their 'convienience'. so, the cautions of ome regarding
> outbound traffic should be taken to heed in many if not most environs,
> yet, is not all encompassing.
>
> Thanks,
>
> Ron DuFresne
>
> On Thu, 24 May 2001 [EMAIL PROTECTED] wrote:
>
> > I think the list goes something like:
> >
> > 1. Phone-home trojans. If nobody has built a really good one yet,
> > the existence of admins who think outbound==safe constitutes a motive
> > for someone to do it.
> >
> > 2. Compromised internal machines being used as bases for DoS attacks
> > or further compromise attempts (for which you will be blamed...).
> > Note that the advice that was widely circulated afterlast year's
> > headline-grabbing DoS attacks amounted to "block this kind of
> > outbound traffic so your machines, if compromised, at least don't
> > make things worse."
> >
> > 3. Studies invariably show that significant proportions of policy
> > violations, up to and including business-threatening security
> > breeches, originate internally. If you "generally trust all of your
> > internal users" -- and, incidentally, therefore anyone who manages to
> > get their code run on any of your internal machines... -- statistics
> > strongly suggest that you're asking to be weeded out of the meme
> > pool.
> >
> > 4. We decided that if email was going out into the outside world
> > with our company domain name on it, it had better *at least* have
> > gone through our mail gateway's virus checkers. So allowing internal
> > machines to randomly spew SMTP to any address in the world was out.
> >
> > 5. A few commercial products (pcAnywhere, HP JetDirect, almost
> > certainly others) will port-scan to locate targets if not carefully
> > configured. They have no idea what address space you're actually
> > *entitled* to do this on.
> >
> > 6. I'm sure there are environments where nobody cares if a few
> > thoughtless -- not necessarily malicious, mind you -- users tie up
> > all the bandwidth with Napster, Gnutella, or the next big bandwidth-
> > swallower your ruleset doesn't know about. But these are, I think,
> > exceptions rather than the rule.
> >
> > It was #6 that finally persuaded me that proper firewall config,
> > INCLUDING OUTBOUND, is not "block the stuff you know you don't want";
> > it's "block everything, then allow the stuff you've actually
> > determined you're willing to deal with the consequences of allowing."
> >
> > David Gillett
> >
> >
> >
> > On 24 May 2001, at 14:32, Graham, Randy (RAW) wrote:
> >
> > > I'm sure you'll get plenty of responses, and probably all will say
> > > approximately the same thing. But, here's my $0.02. By allowing anything
> > > from the inside out, you make it easier for any system that has been
> > > trojaned to communicate out. If someone stupidly runs an email attachment
> > > that includes a "phone home" capable executable, you've just given an
> > > attacker a connection to your internal network. When setting up your rules,
> > > you really should control traffic through every interface of your
> > > firewall(s) and/or router(s) that you possibly can control.
> > >
> > > Randy Graham
> > > --
> > > You're kind of trying to pick between "horible disaster" and "attrocious
> > > disaster" -- Paul D. Robertson (on VNC vs. PPTP)
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 24, 2001 11:28 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Allowing outgoing services
> > >
> > >
> > >
> > > OK, this could be a silly question, but it never hurts to ask. (I
> > > hope.) Let's say I generally trust all of our internal users. What are the
> > > downsides to allowing all services from our internal users going out to the
> > > internet? (Of course I would be limiting the incoming services.) Any major
> > > problem with this that I am missing? Thanks.
> > >
> > > Scott
> > > -
> > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > "unsubscribe firewalls" in the body of the message.]
> > >
> >
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Cutting the space budget really restores my faith in humanity. It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation." -- Johnny Hart
> ***testing, only testing, and damn good at it too!***
>
> OK, so you're a Ph.D. Just don't touch anything.
>
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
