-------- From academic-firewalls-owner@net.tamu.edu Mon Feb 20 04:01:11 1995 X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 8464 Date: Mon, 20 Feb 1995 10:54:48 +0100 (MET) From: greulich@math-stat.unibe.ch (Andreas Greulich) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: security in FW-topology, load-balance Hello all! I got some considerations and questions concerning advantages and disadvantages of certain firewall topologies. In my eyes, a dual-homed gateway with an additional screening filter on each side (at least on the internet site!) is still the most secure configuration. Screened host gateways offer more flexibility and provide a certain load balance as it's possible using more than one firewall machine, but to the price of less security (actually I'm not aware of any commercial product using a screened host approach), whereas screened subnet approaches claim to offer flexibility/bandwidth and security. Though, in a screened subnet it's still possible to configure the routers (I call them routers now even if they eventually are screening hosts) such that traffic flows around the firewall(s) (also calles "flexibility"). But doubtlessly, it's a good idea offering certain public services on the DMZ. But, can't it be combined with the feature that makes dual-homed gateways so secure, namely the fact that no flow PHYSICALLY can flow around the firewall(s) (so giving up a certian flexibility), while still keeping the advantage of load balance (several firewall(s), serving different protocols)? A possible topology (I'm not aware of any name of it still), could look like this: Internet | ++-+ +--+ +--+ +--+ +--+ |R1| |I1| |I2| |I3|... |In| ++-+ +-++ +-++ +-++ +-++ | | | | | "red" --+-----+-------+--------+-+------+-------+------+-------+-- | | | | +-++ +-++ +-++ +-++ |F1| |F2| |F3| ... |Fn| +-++ +-++ +-++ +-++ | | | | "violet"--+-----+-------+---+----+---- | ++-+ |R2| ++-+ | "blue" --------------------+---------- internal network (I'm using the words "blue" and "red" - similar to Dec's Seal-names - to differ the external untrustd and the internal trusted network; additionally a segment exists in the middle... sorry the pun, but I couldn't resist calling it "violet" :-) - - "blue" is the trusted network, "red" and "violet" are the screened DMZ's (there actually exist two of them). - - Fx are the firewalls (eventually one for each service, so offering a certain load balance) - - Ix are public information servers (anonymous ftp, www, etc), so offering a certain flexibility - - R1 and R2 are two routers (or screening workstations offering logging features), screening the violet and red networks). R2 wouldn't be really needed, then we give up a little bit of trust and make already "violet" the "blue" network. I didn't really think about the consequences of this yet. - - If we'd however interconnect "red" and "violet" by a wire, so make "violet" red (making one segment out of it), we'd get the Seal topology (screened subnet actually). Of course we'd also remove the no longer needed second ethernet connections of the Fx. R2 would take the role of gate. As it can be seen, all traffic still HAS to flow thru one of the gateways, but we can use several gateways, thus improving bandwidth, and offer public servers on the red network, as we do in screened subnets. We give up the (anyway questionable) feature to set up rules of R1 and R2 such that certain trusted traffic can flow around the Fx. We even improve security; it's still true that two barriers have to be taken by an attacker, but one of those two has to be an Fx (in a screened subnet, it's possible to compromise the two routers and none of the Fx to break in). What are the feelings about this topology, what would speak against it, except of course an additional complexity? Are such or similar configurations considered already? A second considerations concerns load balancing. Screened host/subnet (and the above) topology offer a feature that bandwidth can be increased because there are several Fx (firewalls) available. Standard routers (R1, R2) just allow rules to "distribute" traffic with a low granularity to the Fx. It could be possible to direct all telnet traffic to F1 and all ftp traffic to F2 (source addresses might also be used, but it's surely non-trivial to find a good load balance scheme). Such load balancing suffers by following drawbacks (maybe more): - - not an equal distribution; probably there's more ftp-traffic than telnet-traffic, but less ftp-connections than telnet-connections. The machine serving ftp would probably be more loaded than the one serving telnet. - - this distribution might even be non-stationary, ie change over time - - So it might well be possible one service is blocked whereas another Fx would still have free ressources - - Even if those drawbacks wouldn't exist, it's a non-trivial and error-prone process setting up the rules for R1 and R2 Now I wonder if it wouldn't be better using a dynamic instead of a static distribution scheme. For this, an additional protocol would be needed (let's call it FIP for the moment, like firewall-information-protocol? *grin*). It might look like this (just a very first and rough idea) for the above topology: - - Each Fx keeps a table in the kernel containing following entries: src-ip, src-port, dst-ip, dst-port, udp/tcp-flag, F the first 5 entries define each connection, the F is an int saying which firewall is treating it (each Fx has a unique identifier). This table says which Fx is actually runnign which proxy-instances (dynamically). - - When a packet on R2 (blue side) arrives, it broadcasts it to violet - - Each Fx looks the entry up; if one exists and its F doesn't correspond to its own identifier, the packet is discarded. If an entry exists and does correspond to its identifier, it's received. If no entry exists and the actual firewall has a "token" (at one moment one Fx has the "token"), it's received, an additional entry created in the table and this entry immediately spread to the other Fx's by a special FIP-broadcast packet, so all tables are kept consistent. So, this firewall from now on treats this "connection". - - After each such action, or anyway from time to time, the Fx send out FIP-broadcasts to inform about what free ressources they have and then by some machanism the "token" is re-assigned. Maybe it's done by a distributed algorithm, maybe one host is a token-administrator and calculates which Fx gets the token (and informs it about it). - - Same machanism for R1 when packets arrive from internet - - The FIP-traffic between the firewalls should be on the violet network of course (possibly also on a separated segment or better serial line to protect it; This line could also be used to transmit logs to an own machine that also is token-administrator and thus not accessible over the network at all if a serial line is used; this machine could also play the role of an authentication server for the Fx, like in Raptors firewall-scheme the A-box). - - Naturally, instead of broadcasts, R1 and R2 can also use multicasts. - - Possible extension: not one token exists, but one token for each supported protocol (an FTP-token, a Telnet-token, etc), thus allowing to assign the tokens on different ressource-metrics (number of free sockets, CPU-time, memory, etc) depending on the ressource-requirements of the different protocols. Of course it would be a complex task to design such a protocol and probably it finally would require a special "Firewall-OS" instead of standard Unix on the Fx. Again, what are the feelings about such a load balancing scheme? Is it worth the effort? Are people already researching in that area? Andy - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Andreas Greulich University of Berne, Switzerland - ---------------- Email: greulich@math-stat.unibe.ch, greulich@iam.unibe.ch http://iamwww.unibe.ch/~greulich CIS: 100014,1033 Phone home: (+41 31) 961 7031 Phone office: (+41 31) 631 8809, (+41 31) 631 4497 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------- From academic-firewalls-owner@net.tamu.edu Mon Feb 20 13:06:56 1995 In-reply-to: "Your message dated Mon, 20 Feb 1995 10:54:48 +0100 (MET)" Cc: firewalls@greatcircle.com, academic-firewalls@net.tamu.edu, Organization: Arnold Consulting, Inc. X-PS-Qualifiers: /CALCULATE/LEFT_MARGIN=36/LINES=100 MIME-version: 1.0 Content-type: text/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Date: Mon, 20 Feb 1995 12:44:17 -0600 (CST) From: Stephen.L.Arnold@Arnold.Com Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: security in FW-topology, load-balance [description and diagram omitted] > (I'm using the words "blue" and "red" - similar to Dec's Seal-names - to > differ the external untrustd and the internal trusted network; additionally > a segment exists in the middle... sorry the pun, but I couldn't resist > calling it "violet" :-) > ... > to compromise the two routers and none of the Fx to break in). What are > the feelings about this topology, what would speak against it, except of > course an additional complexity? Are such or similar configurations considered > already? This is my preferred configuration. I recommend it to all of my clients that have a chance of affording it (that is, that have something very valuable to protect!). > A second considerations concerns load balancing. > ... > Of course it would be a complex task to design such a protocol and probably > it finally would require a special "Firewall-OS" instead of standard Unix > on the Fx. Again, what are the feelings about such a load balancing scheme? > Is it worth the effort? Are people already researching in that area? > > Andy A clever idea, your FIP. However, it's not needed, and I have another method of load balancing that I much prefer. I am a time-sharing bigot. Within the minimalist approach of firewall design (application relays must be simple enough to proven safe by direct observation of the code), I want to put as many applications as possible on one host, except if user logins to a bastion are required. Then I put all the applications requiring user logins (interactive applications) on one host, all those that don't (application relays) on a second host. Now replicate the hosts for fault tolerance and load sharing. Now if one system supporting mail, web, DNS, and NTP goes down, the other one(s) go(es) on, straining under its (their) share of the load of the dead host. This gives you 7x24 availablity and the ability to take a host down for repair, software upgrades, or to introduce new services. Run this configuration with a split DNS. Each application has Address records in the DNS (e.g., WWW.Yoyodyne.Com) for the "red" interface of every bastion running the application. Either the application is stateless and probably uses UDP, so every packet can go to a different host, or it requires circuits and uses TCP, so each session goes to a different host. (If host is lost, the application must reinitiate the session, this time through a different host.) Without going into how to implement every detail, this configuration scales well, can be highly fault tolerant (even geographically diverse!), and the uniformity of the configurations of the two types of bastion hosts allows for much easier management than if each application had a dedicated (and uniquely configured) host. > Andreas Greulich University of Berne, Switzerland > ---------------- Email: greulich@math-stat.unibe.ch, greulich@iam.unibe.ch > http://iamwww.unibe.ch/~greulich > CIS: 100014,1033 > Phone home: (+41 31) 961 7031 > Phone office: (+41 31) 631 8809, (+41 31) 631 4497 Regards, "Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc. Address 2530 Targhee Street, Madison, Wisconsin 53711-5491 U.S.A. Telephone +1 608 278 7700 Facsimile +1 608 278 7701 Internet Stephen.L.Arnold@Arnold.Com Pager (800) 351 8927 -------- From academic-firewalls-owner@net.tamu.edu Mon Feb 20 20:08:41 1995 In-Reply-To: <9502091351.aa20618@salmon.maths.tcd.ie> from "Alan Judge" at Feb 9, 95 01:51:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2433 Date: Mon, 20 Feb 1995 21:03:02 -0500 (EST) From: maf@net.ohio-state.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: User authentication and restriction in proxy/application gateways Alan Judge writes: >What they would like is a firewall/proxy/gateway that would >authenticate users before allowing them remote access to things such >as FTP, telnet, WWW, and so on. At the very least, they would like >full logging of the amount of traffic and users involved, so that they >can do stats and understand where the network load is coming from. >These logs would probably also be useful for security and help us >prevent our users from causing security problems at other sites. Version 2.08 of the KarlBridge software has support for this. In a nutshell authentication server | labnetwork---|kbridge|---world A user opens a telnet connection to the authentication server, gives their username and password. The auth server sends a message to the bridge allowing that single IP address through for a configurable idle timeout. In the not so far short term, Version 2.1 will have duplicate IP address detection to prevent someone from borrowing an authenticated address and control over what filters the remote authentication feature bypasses. Longer term SNMP V2 or some other way of allowing the auth server to talk to the bridge without the security problems inherent in SNMP V1. Depending on your level of paranoia, the labnetwork should us using secure hubs with each station locked to a single Ethernet address. logging looks like: (auth server, the first being a logout the second a login) Feb 20 20:41:37 spider kbauth[10145]: CONNECT: srcIP=164.107.4.213 Feb 20 20:41:50 spider kbauth[10145]: DEL: bridgeIP=164.107.4.252 Feb 20 20:43:13 spider kbauth[10147]: CONNECT: srcIP=164.107.4.229 Feb 20 20:43:21 spider kbauth[10147]: LOGIN: userName=xxxxx, service=Network Connection Feb 20 20:43:23 spider kbauth[10147]: ADD: bridgeIP=164.107.4.252 (bridge) Feb 20 20:53:02 164.107.4.252 KarlBridge Detected a TCP Establish 128.146.214.20:63631 <-> 164.107.4.219:113 (this will look different in version 2.1. Ethernet address, protocol type, serialized logs, and optional MD5 checksum. Logging is not in the "free" version either) We currently have 1 dorm (our recent, first Ethernet ready dorm) and 4 public labs using this. It will be phased in to the rest of the labs over the next 6 months or so. ftp.net.ohio-state.edu:/pub/kbridge The auth server is not in the .zip file, but I can send it to anyone who asks. - -- mark maf+@osu.edu