home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.tcp-ip
- Path: sparky!uunet!shearson.com!newshost!pmetzger
- From: pmetzger@snark.shearson.com (Perry E. Metzger)
- Subject: Re: Stopping only incoming TCP connections (was: Firewall usage)
- In-Reply-To: rh0083b@medtronic.COM's message of Fri, 31 Jul 1992 07:41:54 GMT
- Message-ID: <PMETZGER.92Jul31120203@snark.shearson.com>
- Sender: news@shearson.com (News)
- Reply-To: pmetzger@shearson.com
- Organization: Lehman Brothers
- References: <17011@ulysses.att.com> <1992Jul28.202211.14029@shearson.com>
- <chrisc.21.712446813@ramrod.lmt.mn.org>
- <1992Jul31.074154.4081@medtron.medtronic.com>
- Date: Fri, 31 Jul 1992 17:02:03 GMT
- Lines: 26
-
-
- In article <1992Jul31.074154.4081@medtron.medtronic.com> rh0083b@medtronic.COM (Roger-Hunen) writes:
-
- >From: rh0083b@medtronic.COM (Roger-Hunen)
-
- >So what you really want is application level proxies in the firewall for
- >TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
- >forbidden unless permitted' approach.
-
- Ah, but this is a real pain in the posterior, and breaks the semantics
- of many applications. By using intelligent filtering of SYN packets,
- socket numbers, etc, you can allow easy addition of new services (such
- as WAIS) without needing to write new code or break security.
-
- For extra security, I'm considering building a firewall in which
- requests to change filtering can come in on a kerberized TCP service,
- and then restricting everything. Users wanting to go through the
- gateway would have to explicitly open a "narrow hole" through the
- firewall in order to get out, thus eliminating any "random"
- connections; the holes would time out after a while if no packets of
- the appropriate kind had gone through.
- --
- Perry Metzger pmetzger@shearson.com
- --
- Just say "NO!" to death and taxes.
- Extropian and Proud.
-