From Firewalls-Owner Mon Nov 9 21:03:33 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16184; Mon, 9 Nov 92 21:03:33 PST Received: from hal.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16177; Mon, 9 Nov 92 21:03:26 PST Received: from gorn.hal.com by hal.com (4.1/SMI-4.1.1) id AA26369; Mon, 9 Nov 92 21:03:21 PST Received: by gorn.hal.com (4.1/SMI-4.1.2) id AA05002; Mon, 9 Nov 92 21:01:50 PST Date: Mon, 9 Nov 92 21:01:50 PST From: jonl@hal.com (frederick smythe, esquire) Message-Id: <9211100501.AA05002@gorn.hal.com> To: firewalls@GreatCircle.COM Subject: some details on that cisco 'established' keyword bug... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk sorry for the huge delay, but here are those details about the bug i spoke up a month ago or so. for reference, this is from a workmate of mine at a previous job, and "johnv" is someone who is no longer there, but actually works at cisco now. i can deal with answering/forwarding any specific questions folks may have. of course, talking to cisco may be the best thing to do in general. i believe the roms were 8.03 which this bug was discovered under (the latest at the time, about 6 months ago). --jon ----- Begin Included Message ----- From: Keith Reynolds Here's the description of the cisco ACL problem: There is a set of machines at Berkeley that was able to connect to any machine on our network, in spite of the access control lists on our cisco router, if and only if we had an entry in those ACL's that contained the ``established'' keyword. The established keyword is supposed to match any packet that has either the ACK or RST bits set in the TCP header. All TCP packets have one or (rarely) both of these bits set, except for the first SYN packet that is sent at the beginning of a connection. Thus, the established keyword matches any packet that is part of an established connection. The ACL configuration we wanted to use started with an entry that allowed any such packets. Since the start-of-connection packets would not match this entry, the rest of the ACL entries would be used to control which connections were allowed to be established. After that, all subsequent packets would match the first ACL entry and be allowed by the cisco very quickly. With this configuration the initial SYN packets sent from those machines at Berkeley were also being allowed through. When we changed the ACL to enforce our policies without the use of the established keyword, the connections from those machines were correctly denied. I ran some tests with a Sniffer, but wasn't able to figure out the problem. The packets that were being let through didn't have the ACK or RST bits set, so according to the doc they shouldn't have matched the established keyword. They only difference I was able to observe between packets that got through and packets that were denied is that the ones that got though were using the TCP MSS option. I don't think that's the cause, but it's the only pattern I could detect. Johnv and I talked to CERT about it a bit, but I think they were never given the final update on the problem. I wrote up a description and sent it to johnv, and he was supposed to attach copies of our cisco ACL's and send it off to CERT, but I don't think he ever did. Let me know if you need more info. Keith R. ----- End Included Message ----- From Firewalls-Owner Tue Nov 17 11:12:37 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06672; Tue, 17 Nov 92 11:12:37 PST Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06665; Tue, 17 Nov 92 11:12:28 PST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17590; Tue, 17 Nov 92 14:12:12 -0500 Message-Id: <9211171912.AA17590@relay1.UU.NET> Received: from tron.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 140813.16298; Tue, 17 Nov 1992 14:08:13 EST Date: Tue, 17 Nov 1992 12:58:58 -0500 From: tron!plaza.dnet!adkins@uunet.UU.NET (Marty Adkins, (W) ESG Distributed Systems, MS 1615, WIN 285-1479) To: "Firewalls@GreatCircle.COM"@uunet.UU.NET Cc: ADKINS@uunet.UU.NET Subject: RE: some details on that cisco 'established' keyword bug... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I haven't seen any follow-up on this so I'll pass along this info from Cisco's CIO BBS: > If extended access lists are used on an MCI, SCI or cBus interface, the IP > route cache is enabled, and the 'established' keyword is used, it can be > improperly evaluated. This can permit packets which should be filtered and > exclude packets which should be permitted. This behavior was first introduc > in 8.2. The fix is in interim patch releases 9.0(2.5) and 8.3(5.10), and will be in regular maintenance releases 9.0(3) and 8.3(6). Marty Adkins Networks & Communications Westinghouse Electronic Systems Group Internet: Adkins@plaza.wec.com ref: >sorry for the huge delay, but here are those details about the >bug i spoke up a month ago or so. for reference, this is from >a workmate of mine at a previous job, and "johnv" is someone >who is no longer there, but actually works at cisco now. > >i can deal with answering/forwarding any specific questions >folks may have. of course, talking to cisco may be the best >thing to do in general. i believe the roms were 8.03 which >this bug was discovered under (the latest at the time, about >6 months ago). > >--jon > > >----- Begin Included Message ----- > >From: Keith Reynolds > >Here's the description of the cisco ACL problem: > >There is a set of machines at Berkeley that was able to connect >to any machine on our network, in spite of the access control >lists on our cisco router, if and only if we had an entry in >those ACL's that contained the ``established'' keyword. The >established keyword is supposed to match any packet that has >either the ACK or RST bits set in the TCP header. All TCP >packets have one or (rarely) both of these bits set, except for >the first SYN packet that is sent at the beginning of a >connection. Thus, the established keyword matches any packet >that is part of an established connection. The ACL configuration >we wanted to use started with an entry that allowed any such >packets. Since the start-of-connection packets would not match >this entry, the rest of the ACL entries would be used to control >which connections were allowed to be established. After that, >all subsequent packets would match the first ACL entry and be >allowed by the cisco very quickly. With this configuration the >initial SYN packets sent from those machines at Berkeley were >also being allowed through. When we changed the ACL to enforce >our policies without the use of the established keyword, the >connections from those machines were correctly denied. > >I ran some tests with a Sniffer, but wasn't able to figure out >the problem. The packets that were being let through didn't have >the ACK or RST bits set, so according to the doc they shouldn't >have matched the established keyword. They only difference I was >able to observe between packets that got through and packets that >were denied is that the ones that got though were using the TCP >MSS option. I don't think that's the cause, but it's the only >pattern I could detect. > >Johnv and I talked to CERT about it a bit, but I think they were >never given the final update on the problem. I wrote up a >description and sent it to johnv, and he was supposed to attach >copies of our cisco ACL's and send it off to CERT, but I don't >think he ever did. > >Let me know if you need more info. > >Keith R. > > > >----- End Included Message ----- > From Firewalls-Owner Mon Nov 23 20:08:55 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02638; Mon, 23 Nov 92 20:08:55 PST Received: from dstos3.dsto.gov.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02631; Mon, 23 Nov 92 20:08:08 PST Date: Tue, 24 Nov 1992 14:36:10 +1030 (CST) From: BENNETT@dstos3.dsto.gov.au (John Bennett - Defence Science & Technology Organisation) Message-Id: <921124143610.20204050@dstos3.dsto.gov.au> Subject: trusting routers To: firewalls@GreatCircle.COM X-Vmsmail-To: SMTP%"firewalls@greatcircle.com" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, Does anyone know of research into the trustability (in a formal or any other sense) of routers - I am particularly interested in ciscos. Regards, John Bennett bennett@dstos3.dsto.gov.au Head, I.T. Services Development Phone : +61 8 259 5292 Corporate Information Systems FAX : +61 8 259 5537 DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal: Bld 73 Labs Area AUSTRALIA PO Box 1500 Salisbury South Australia 5108 AUSTRALIA From Firewalls-Owner Mon Nov 23 23:04:41 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03866; Mon, 23 Nov 92 23:04:41 PST Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03843; Mon, 23 Nov 92 23:04:33 PST Received: from sapwdf by mail.Germany.EU.net with UUCP (5.65c/EUnetD-2.2.1.c) via EUnet for greatcircle.com id SA17590; Tue, 24 Nov 1992 08:04:49 +0100 Received: from is0001.sap-ag.de (is0001) by sap-ag.de (5.52.1/SAP-1.2) id AA22467; Mon, 23 Nov 92 21:24:06 +0100 for greatcircle.com!firewalls Received: from localhost by is0001.sap-ag.de (AIX 3.2/UCB 5.64/4.03) id AA117856; Mon, 23 Nov 1992 21:26:39 +0100 Message-Id: <9211232026.AA117856@is0001.sap-ag.de> To: firewalls-digest@sap-ag.de Organization: SAP AG Walldorf, Germany Phone: +49 6227-341658 Home: +49 6221-163255 Subject: what shall thy firewall hardware be? Reply-To: Bill Wohler Date: Mon, 23 Nov 1992 21:26:38 +0100 From: Bill Wohler Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk after absorbing the information in "practical unix security" and this list, i'll be creating a firewall of my own (yes, bryan, it appears we're finally going to get an internet connection). chances are we'll use a cisco router as the choke and an hp 710 as the gate. however, i'd be interested to hear what people like as chokes and gates--and--what they don't like. just occurred to me that i might not be able to get two network interfaces in the hp 710. if this is the case, what is the danger in setting up the router so that it only passes traffic from both the external and internal networks only to the gate? is it better to get a gate that has two network interfaces? --bw From Firewalls-Owner Tue Nov 24 11:53:56 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09274; Tue, 24 Nov 92 11:53:56 PST Received: from gatekeeper.oracle.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09267; Tue, 24 Nov 92 11:53:47 PST Received: from rchilder.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA08523; Tue, 24 Nov 92 11:53:32 PST Received: by rchilder.us.oracle.com (5.59.10/37.6) id AA02766; Tue, 24 Nov 92 11:53:00 PST Message-Id: <9211241953.AA02766@rchilder.us.oracle.com> Date: Tue, 24 Nov 92 11:53:00 PST From: Richard Childers To: Firewalls@GreatCircle.COM Subject: Re: what shall thy firewall hardware be? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: Bill Wohler >Date: Mon, 23 Nov 1992 21:26:38 +0100 >Subject: what shall thy firewall hardware be? . . . just occurred to me that i might not be able to get two network interfaces in the hp 710. if this is the case, what is the danger in setting up the router so that it only passes traffic from both the external and internal networks only to the gate? is it better to get a gate that has two network interfaces? I think it would be _much_ better to use two physically separate inter- -faces. This anticipates the possibility of future methods of breakin which might bypass the filtering mechanism on the router. Consider the following possibility : a disgruntled employee writes a trapdoor routine into the assembler code in the router's kernel, so that he can reset the filtering mechanism(s), perhaps even without it being logged. Because it's assembler, or Forth, it doesn't get noticed ... Let's extrapolate a little further and say that this gets out into the grapevine, and, crackers having learned not to boast, it stays a secret, used by only a few, and never comes to the attention of CERT. Those two physically discrete interfaces may now be all that's left of your firewall, and whatever logging is in place may be all that you have by which to detect such a breakin, if they don't actually try to break in to the gateway itself ( which is, of course, being closely monitored at all times ). Also, two interfaces makes for better throughput ... -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From Firewalls-Owner Mon Nov 30 18:43:25 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09981; Mon, 30 Nov 92 18:43:25 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09972; Mon, 30 Nov 92 18:43:21 PST Message-Id: <9212010243.AA09972@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: what shall thy firewall hardware be? In-Reply-To: Your message of Mon, 23 Nov 1992 21:26:38 +0100 Date: Mon, 30 Nov 92 18:43:19 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bill Wohler writes: # after absorbing the information in "practical unix security" and # this list, i'll be creating a firewall of my own (yes, bryan, it # appears we're finally going to get an internet connection). # # chances are we'll use a cisco router as the choke and an hp 710 as # the gate. however, i'd be interested to hear what people like as # chokes and gates--and--what they don't like. # # just occurred to me that i might not be able to get two network # interfaces in the hp 710. if this is the case, what is the danger # in setting up the router so that it only passes traffic from both # the external and internal networks only to the gate? is it better # to get a gate that has two network interfaces? I've built a number of firewalls using a variety of different schemes, all variations on a theme of packet filtering. My current favorite scheme involves two Cisco routers (yeah, I know, mucho $$$$) and a UNIX box. You arrange things so that the two routers and the UNIX box are on a dedicated Ethernet (we usually call this the "exposed net" or "DMZ"), with nothing else on that net. One of the routers is also connected to the outside world. The other router is also connected to your internal net. The exterior router guards the internal net and the DMZ from the outside world. The interior router guards the internal net from the DMZ and the outside world. The host on the DMZ is what the outside world talks to when they want a SMTP, FTP, DNS, or other server for your site. You arrange the packet filters on the interior and exterior gateways so that clients on internal machines can connect to certain servers (TELNET and FTP satisfy 90-95% of user desires) in the outside world. You arrange for non-interactive services (such as SMTP, DNS, etc.) to go out via the host on the DMZ. You do not allow UDP (except for to/from port 53, for DNS) through the exterior firewall. You do not let any of the internal machines trust the DMZ host in any way (mounting filesystems, .rhosts files, hosts.equiv files, etc.). You do everything you possibly can to secure the DMZ host. You don't let users on the DMZ host routinely; this makes it easier to monitor for illicit use. Depending on how paranoid you are and what's at stake, you might impose further restrictions between the DMZ host and the internal hosts on the interior router. That, in a nutshell, is how I build firewalls today. The technology is constantly changing, though, so I may be doing something different next week. Also, I often end up modifying the plan to accomodate a site's particular constraints (i.e., they can't afford 2 Ciscos, or they already have another brand of router, or ...). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Nov 30 19:02:51 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10088; Mon, 30 Nov 92 19:02:51 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10079; Mon, 30 Nov 92 19:02:47 PST Message-Id: <9212010302.AA10079@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: what shall thy firewall hardware be? In-Reply-To: Your message of Tue, 24 Nov 92 11:53:00 PST Date: Mon, 30 Nov 92 19:02:46 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard Childers writes: # I think it would be _much_ better to use two physically separate inter- # -faces. This anticipates the possibility of future methods of breakin # which might bypass the filtering mechanism on the router. Much better than what? # Consider the following possibility : a disgruntled employee writes a # trapdoor routine into the assembler code in the router's kernel, so that # he can reset the filtering mechanism(s), perhaps even without it being # logged. Because it's assembler, or Forth, it doesn't get noticed ... # # Let's extrapolate a little further and say that this gets out into the # grapevine, and, crackers having learned not to boast, it stays a secret, # used by only a few, and never comes to the attention of CERT. # # Those two physically discrete interfaces may now be all that's left of # your firewall, and whatever logging is in place may be all that you have # by which to detect such a breakin, if they don't actually try to break in # to the gateway itself ( which is, of course, being closely monitored at # all times ). Frankly, I think what you say applies much more strongly to UNIX hosts than to most of the routers on the market. There are many more holes to poke and prod at on the UNIX hosts, and many more people with enough knowledge to do the poking. # Also, two interfaces makes for better throughput ... Better than what? The two router plus UNIX host scheme I described earlier? If so, I'd like to hear your logic. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041