From firewalls-owner Thu Aug 1 00:33:19 1996 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id AAA07855 for firewalls-outgoing; Thu, 1 Aug 1996 00:24:40 -0700 (PDT) Received: from sic.se (mailbox.sic.se [194.236.7.200]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with ESMTP id AAA07848 for ; Thu, 1 Aug 1996 00:24:32 -0700 (PDT) Received: from pamela.sic.se (pamela.sic.se [194.236.7.44]) by sic.se (8.7.5/8.7.2) with SMTP id JAA00523 for ; Thu, 1 Aug 1996 09:21:28 +0200 (MET DST) X-Mailer: InterCon TCP/Connect II 2.3.1 MIME-Version: 1.0 Message-Id: <9608010921.AA54441@pamela.sic.se> Date: Thu, 1 Aug 1996 09:21:54 +0100 From: "Stefan Berg" To: firewalls@GreatCircle.com Subject: SSL, port 442, https Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi there, was just wondering if the W3 Httpd(A) (aka CERN httpd) supports SSL, or do I have to patch it somehow? Want to use it for proxy. /Stefan -- _______________________________________________________ Stefan Berg ISDN Group of Sweden / Swedish InternetCentral Phone: +46-8-6677010 E-mail: stefan@sic.se WWW: http://www.sic.se/ http://www.isdn.se/ _______________________________________________________ Recursive; adj. see Recursive From firewalls-owner Thu Aug 1 01:05:14 1996 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id AAA08707 for firewalls-outgoing; Thu, 1 Aug 1996 00:47:53 -0700 (PDT) Received: from inetsrv1.biss.co.uk (inetsrv1.biss.co.uk [193.115.8.97]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with SMTP id AAA08700 for ; Thu, 1 Aug 1996 00:47:44 -0700 (PDT) Received: from ccmailgw.biss.co.uk by inetsrv1.biss.co.uk with SMTP Received: from cc:Mail by ccmailgw.biss.co.uk Date: Thu, 01 Aug 96 08:29:38 GMT From: "Steve Betts" Message-Id: <9607018389.AA838914258@ccmailgw.biss.co.uk> To: firewalls@GreatCircle.COM, "James Croall" Cc: jcroall@mitre.org Subject: Re: Firewall Java blocking Sender: firewalls-owner@GreatCircle.COM Precedence: bulk James Croall wrote: >TIS has announced and is shipping their Java Guard system with Gauntlet >3.2, and Raptor has announced support for Java blocking in the next >release of their Eagle firewall product. I understand how a firewall might be configured to block Java or ActiveX executable files, by looking at the file extension. How does a firewall understand what is JavaScript or VBScript when that code is simply part of a comment in an HTML document? Does it now have to be an HTML interpreter as well? Regards. ,-. / ) / <, ) / / NB Opinions are my own and may (__ -/--- /_,/ -/--/- not be the same as my employers / ) / /7 /7 /7 /7 / `> /7 / / _/7 tel: +44 (0) 1 442 233 366 \___//(_(/_/ (/ (_(/_/\__ /(_(/_/(_/(_/,_7 fax: +44 (0) 1 442 236 623 From firewalls-owner Thu Aug 1 01:33:41 1996 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id BAA11364 for firewalls-outgoing; Thu, 1 Aug 1996 01:18:46 -0700 (PDT) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with ESMTP id BAA11341 for ; Thu, 1 Aug 1996 01:18:30 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id BAA22451; Thu, 1 Aug 1996 01:15:20 -0700 (PDT) From: Don Lewis Message-Id: <199608010815.BAA22451@salsa.gv.ssi1.com> Date: Thu, 1 Aug 1996 01:15:20 -0700 In-Reply-To: Zachary Roger Amsden X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Zachary Roger Amsden , gaarder@actech.com Subject: Re: How secure is xinetd's binding to specific interfaces Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Jul 30, 5:52pm, Zachary Roger Amsden wrote: } Subject: Re: How secure is xinetd's binding to specific interfaces } Well, I have looked a little at xinetd's code, but I think it's pretty } secure. Basically, it probably does a getsockname() on incoming } connections to find out what interface they are coming in on. It then } would compare the result to an IP address or interface name and make } sure they match. I haven't looked in full at the code here, but I would } place high faith on this part because it is not that tricky to do. What } I wouldn't place faith on is the kernel's IP forwarding mechanism. On } many BSD based systems, it is possible to ping an inside interface from } the outside, even with IP forwarding turned off (so I have been told). I've seen patches to the BSD networking code that fix this. --- Forwarded mail from hue@island.com (Pond Scum) >From firewalls-relay@tus.ssi1.COM Thu Jan 26 15:27:48 1995 Date: Wed, 25 Jan 1995 17:48:56 +0800 From: hue@island.com (Pond Scum) Message-Id: <9501260148.AA06263@coney.island.com> To: firewalls@GreatCircle.COM Subject: Re: IP spoofing vs tcp wrappers and netacl Sender: firewalls-owner@GreatCircle.COM Apologies if you are seeing this twice, but I think it didn't make it out: > > Doesn't help at all. The packets are forged to be from the internal > >network, and this is what getsockname()/getpeername() will say. It you > >use netacl, to protect telnetd to the firewall. (So the the admin can > >login from the internal network), then the attacker can get to > >telnetd. > > Actually, if the destination is the firewall, it does help, because the > getsockname tells you the ip-address of the interface that is holding > up your end of the connection. You know which ip-address you assign Right, but you can just as easily send to address of the interface on the internal network from the outside, even with IP forwarding disabled. To your netacl or tcp wrapper, it looks like a connection to the internal interface from an internal net. It was pointed out to me in private email that the only check in ipintr() (BSD derived systems) is whether the address matches any of the host's interfaces, there is no check for which interface the packet came in on (I chopped out some code here, these are just the relevant parts): /* * Check our list of addresses, to see if the packet is for us. */ for (ia = in_ifaddr; ia; ia = ia->ia_next) { if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) goto ours; But what if you made a small change, making sure the interface with the address which matches the one in the packet is the interface the packet was received on: if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) if (ia->ia_ifp == ifp) goto ours; else it came in on the wrong interface, log it and drop it In that case you could trust getsockname(), because packets sent to the inside interface from the outside would get dropped. If your proxies don't allow access to the internal net from the internal net, it really doesn't matter if someone spoofs the IP address of an inside machine from the outside. The proxy would just turn them around and they could only go back out. This is probably the easiest way to combat the problem, but it means you can't "bounce" stuff off the firewall from the inside anymore. I've gotten into the lazy habit of doing this with Anarchie on the Macintosh. -Jonathan hue@island.com --- End of forwarded message from hue@island.com (Pond Scum) --- Forwarded mail from hue@island.com (Pond Scum) >From firewalls-relay@tus.ssi1.COM Fri Jan 27 00:48:32 1995 Date: Fri, 27 Jan 1995 00:22:51 +0800 From: hue@island.com (Pond Scum) Message-Id: <9501270822.AA08991@coney.island.com> To: firewalls@GreatCircle.COM, patrick@oes.amdahl.com Subject: Re: IP spoofing vs tcp wrappers and netacl Sender: firewalls-owner@GreatCircle.COM > ARGH!!!!! Is this true? With IP forwarding a packet shouldn't be accepted > if it's not to the "reachable" interface. I just tried this out on a > Sun running Solaris, and an Amdahl machine running UTS, and neither of > them had this bug. Is it really true that BSD machines will accept a > packet addressed to one interface on the other? Well, it's true on my machine, which is SunOS 4.1.3. ip_input.c is the one sent to this list by Brad.Powell@Ebay.sun.com, containing the patch to block source routed packets. I think it's safe to assume that the code in question is the same in 4.1.3 as in his patched version. I have received email that says this is the behavior in any BSD distribution. I ended up trying out that simple change I posted. The only thing you need to add is code to make sure you don't drop packets coming back up the loopback interface. Once I did that it did what I expected. -Jonathan hue@island.com --- End of forwarded message from hue@island.com (Pond Scum) --- Truck From firewalls-owner Thu Aug 1 01:48:47 1996 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id BAA12913 for firewalls-outgoing; Thu, 1 Aug 1996 01:34:28 -0700 (PDT) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with ESMTP id BAA12823 for ; Thu, 1 Aug 1996 01:34:00 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id BAA22459; Thu, 1 Aug 1996 01:30:30 -0700 (PDT) From: Don Lewis Message-Id: <199608010830.BAA22459@salsa.gv.ssi1.com> Date: Thu, 1 Aug 1996 01:30:29 -0700 In-Reply-To: "Sean Fuller" X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Sean Fuller" , firewalls@GreatCircle.COM Subject: Re: How secure is xinetd's binding to specific interfaces Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Jul 31, 9:13am, "Sean Fuller" wrote: } Subject: Re: How secure is xinetd's binding to specific interfaces } On Jul 30, 6:37pm, wrote: } } getsockname! Thanks so much for pointing out this wonderful routine. } I don't know why I never saw it before. I guess I learned firewall } programming from the TIS Firewall Toolkit and I never saw this routine } used to detect the incoming interface. Except that with most network stacks you can't count on this to detect the interface that the packet was received on. If interface A receives a packet with the destination address that matches interface B, getsockname() will report interface B's address. With most networking stacks, this will happen even if IP forwarding is turned off. If the routing table on the host shows that the route to packet's source address should use interface A (or if there is a source route), I bet it's still possible to set up a TCP connection even without IP forwarding, but in this case (lacking the source route) your getpeername() check should be effective. --- Truck From firewalls-owner Thu Aug 1 04:48:18 1996 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id EAA24060 for firewalls-outgoing; Thu, 1 Aug 1996 04:39:31 -0700 (PDT) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with SMTP id EAA24044 for ; Thu, 1 Aug 1996 04:39:13 -0700 (PDT) Received: from smiley.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id HAA02686; Thu, 1 Aug 1996 07:36:06 -0400 Received: from loghost.mitre.org by smiley.sit (4.1/SMI-4.1) Message-Id: <9608011134.AA06553@smiley.sit> To: "Steve Betts" Cc: firewalls@greatcircle.com Subject: Re: Firewall Java blocking In-Reply-To: Your message of "Thu, 01 Aug 1996 08:29:38 GMT." Date: Thu, 01 Aug 1996 07:34:23 -0400 From: "James Croall" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <9607018389.AA838914258@ccmailgw.biss.co.uk>, "Steve Betts" writes: >I understand how a firewall might be configured to block Java or ActiveX >executable files, by looking at the file extension. How does a firewall >understand what is JavaScript or VBScript when that code is simply part >of a comment in an HTML document? Does it now have to be an HTML >interpreter as well? Yes, it has to parse the HTML as well. JavaScript and VBScript aren't merely inside comments, they also have a