Agreed that's a valid concern. Just gotta what who you let in, I guess.
To take this concern a step further, consider that once someone has been
authenticated from the firewall to an internal host, what is to stop
them from hopping from there to another internal host. For example, if
I'm allowed to get to "HOSTA" on your net and do so, I can then TELNET
(or SET HOST, or even rlogin, etc.) to any of your other internal hosts,
since as far as the other interal hosts are concened, I am connecting
from HOSTA, not from an external system. A way to protect from that
would be to have all connections to all internal hosts require
authentication (ex: SecurID, etc), but that's pretty lame from the user
perspective.
So, if you are going to allow external access to internal resources, I
guess your options are to use the firewall to it's max. capabilities to
specify who can get in, with what protocol, at what times of the day,
from what IP address and to what IP address. Over and above that, the
basic good security practices (password complexities and expiries, etc.)
would be about all you've got, other than the trust (signed agreement?)
of the person you've allowed in.
Bob Miller
millerrc @
zen .
com
>----------
>From: lists @
lina .
inka .
de[SMTP:lists @
lina .
inka .
de]
>Sent: Wednesday, July 24, 1996 5:34 AM
>To: firewalls @
GreatCircle .
COM
>Subject: trusting the firewall
>
>Hello,
>
>on our firewall we want to accept any incoming telnet connection (to an
>internal host) and do some authentification (based on S/KEY or any
>other
>'secure' way). This is done by an transparent telnet proxy (just like
>TIS
>Gauntlet is doing I think). The problem is, that after the connection
>is
>authenticated we can dodifferent connections to the inside:
>
>[externA]------->[firewall]--->[router]--->[intern]
>telnet e->i e->i on the internal host
>connections
> seem to come from the
>outside.
>
>telnet e->i f->i on the internal host
>connections
> seem to come from the
>firewall.
>
>telnet e->f f->i after specifying a host, the
> connections comes from the
>firewall
>
>The problem with this is, that the internal host always asks for
>additional
>username and password, AND authentificated user A on the fireweall can
>still
>login as user B on the internal host. One solution would be to start a
>rlogin or ssh connection from the firewall to the internal host. The
>advantage of this solution is, that you have the secure authorization
>of the
>firewall available at the internal host for external connections, the
>biggest disadvantage of this is, that the internal host hast to trust
>the
>username the firewall delivers.
>
>Are there any solution for this problem? One way would be to use an
>authentification server. The firewall authentificates the user against
>the
>authentification server and passes the ticket from the server to the
>internalhost. The internal host asks the authentification server to
>validate
>the ticket. The problem with this approach is, that the login of the
>internal host needs to be changed (or ssh needs to run a login
>replacement
>which is rather easy). The advantage is, that anyone on the firewall
>who
>wants to log into a internal host needs to present a valid
>authentification
>to the authentification server and is unable to spoof users.
>
>I am sure the solution with the authentification server is the most
>secure,
>but I realy would prefer to have a self-contained firewall (which means
>there has tobe some trust and even user-authorization data) on the
>firewall.
>The System should be for small busiess no high-grade military security.
>Am I
>missing a solution?
>
>Greetings
>Bernd
>--
> (OO) -- Bernd_Eckenfels @
Wittumstrasse13 .
76646Bruchsal .
de --
> ( .. ) ecki @
lina .
{inka .
de,ka.sub.org} http://home.pages.de/~eckes/
> o--o *plush* 2048/A2C51749 eckes @
irc +4972573817 *plush*
>(O____O) If privacy is outlawed only Outlaws have privacy
>
>
|
|
