neil@stl.stc.co.uk (11/23/90)
We are starting the planning process to connect our large internal network to an internet. We wish to reduce the risk of unwanted external vistors as far as possible, whilst allowing our internal users access to other hosts. One possibility is to acquire a device to sit between our backbone and the outside world. This device would be programmable so that I could authorise connections on a per host, per port, per direction basis. So, for example I have network 128.199, I could have an authorisation file like:- # Source Dest Comment # host.port host.port *.smtp mymailgw.smtp Mail service inbound mymailgw.smtp *.smtp Mail service outbound 128.199.200.*.ftp *.ftp FTP 128.199.200.*.telnet *.telnet Telnet So, from the above, my mail gateway could send out to anybody, and anybody can send to my mail gateway (and no where else). Any machine on my local 200 subnet can ftp or telnet to anywhere, but no inbound conenctions are allowed. Is this possible, or are we thinking in completely the wrong way ? At this stage it isn't necessary that the device exists in the UK, we can import if necessary. The device probably needs to understand name servers as well. We also have an eye on the future, so the Vendor would need to offer support for OSI protocols. Neil Todd | ..In general, it is best to assume that the PSI%234237100122::neil | network is filled with malevolent entities neil@stl.stc.co.uk | that will send in packets designed to have STC Technology Ltd | the worst possible effect...
barmar@think.com (Barry Margolin) (11/25/90)
In article <3768@stl.stc.co.uk> neil@stl.stc.co.uk () writes: >So, for example I have network 128.199, I could have an authorisation >file like:- > ># Source Dest Comment ># host.port host.port > >*.smtp mymailgw.smtp Mail service inbound >mymailgw.smtp *.smtp Mail service outbound >128.199.200.*.ftp *.ftp FTP >128.199.200.*.telnet *.telnet Telnet The source port for connections is generally *not* the protocol's well-known port. The well-known port is normally only used as the destination port. The source port is usually a random port above 1024. >Is this possible, or are we thinking in completely the wrong way ? >At this stage it isn't necessary that the device exists in the UK, >we can import if necessary. cisco Gateway Servers can do packet filtering based on addresses and port numbers. >We also have an eye on the future, so the Vendor would need to offer >support for OSI protocols. cisco supports OSI protocols, although it doesn't yet seem to support them in its filtering specifications. It will probably come at some time, thoug. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
kmeyer@jerico.usc.edu (Kraig R. Meyer) (11/25/90)
In article <3768@stl.stc.co.uk>, neil@stl.stc.co.uk writes: |>...We wish to reduce the risk of unwanted external vistors |>as far as possible, whilst allowing our internal users access to other |>hosts. |> |>One possibility is to acquire a device to sit between our backbone and |>the outside world. This device would be programmable so that I could |>authorise connections on a per host, per port, per direction basis. Depending on how much isolation you want from the outside world, another option (besides using filtering at the TCP/IP level in a router) is to use a unix box as an application level gateway. This is definitely an inconvenience to your users, which may or may not be a good thing depending on what your isolation goals are and how paranoid you are. For example, you can configure sendmail to forward mail in both directions and then only give accounts on the gateway unix machine to those people who you want to allow ftp/telnet/etc access to the outside network. That makes access on a per-person basis, rather than on a per-IP-address basis. Filtering in the way you've described would not, for example, prevent an internal user from spoofing IP addresses (if that is an issue). --------------------------------------------------------------------------- | Kraig R. Meyer kmeyer@usc.edu | | University of Southern California Los Angeles | ---------------------------------------------------------------------------