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.]
