On 1999.11.17, Dorian Moore <[EMAIL PROTECTED]> wrote:
> If you are thinking of letting the connection run from the internet
> through a 'hole' in your firewall to a specific server then it's a
> matter of the services that are available.

Any time a port is openend for outbound traffic through your firewall
without a proxy in between (if you allow general packet passing through
your firewall on any arbitrary port), you have potentially compromised
any security your firewall offers.

You can minimize potential damage by only allowing outbound connections
to specific hosts, but this is only as good as the security of those
hosts themselves.

> The trick is restricting what tools are available on the server the user
> is connecting to. (IE, make sure pppd isn't executable, or kermit, or
> any filetransfer facilities, if you want to stop filetransfer).

The only way to stop filetransfer is to make all your filesystems
read-only at the hardware level.  And of course, this only works
presuming people lack physical access to the box in question.

(I say this because if you have any interpreters (such as Perl or Tcl),
uudecode or metatool or anything else that decodes files, any compilers
such as Java or C/C++, or pretty much ANY combination of standard Unix
tools, there will be a way to transfer files.  Hell, I think if your
/bin/sh implements the shell built-in "echo" to allow you to use
octal \000, that's enough to "transfer" a binary file.)

The core question that Saxo <[EMAIL PROTECTED]> was asking is:

"If I allow outbound traffic unproxied, and a user decides to use
a crypto-enabled protocol on that port, what can I do as a firewall
administrator to filter/restrict activity?"

Of course, the simple answer is:  nothing.  That's the point of
encrypted traffic.  If the crypto is weak enough that your firewall
can decode it in realtime and filter it, you might as well not even
bother using the crypto.

Note:  any kind of "munging" userland tools such as SSH to "restrict"
users only defeats the "stupid" ones.  This, once again, is resorting
to "security through obscurity" (yadda, yadda, yadda).  Don't suggest
it in any serious tone of voice.  ;-)

-Dossy

-- 
Edward T. Shiobara                         voice: +1 201 236-6650
Unix Systems Administrator                   fax: +1 201 236-3530
Pearson Education, Systems & Technology     mail: [EMAIL PROTECTED]
1 Lake St., Upper Saddle River, NJ 07458     web: http://www.prenhall.com/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to