Firewall Wizards mailing list archives
HTTP in practice
From: Greg Haverkamp <gregh () instinctive com>
Date: Mon, 22 Sep 1997 21:29:38 -0400
Hello, all. Having watched the firewalls mailing list for the last year or so, and firewall-wizards for -- I guess -- the last week or so, I've developed a good base of the feelings on the _theory_ of what people want to see in firewall implementations and what they'd like to be using and doing. However, as my company's product begins to head out the door, and we face what appear to be firewall- (or proxy-) based problems, the questions I'm being asked have made me wonder about what's actually happening "out there." Here's some background, based on what I "can" say: - Our product, eRoom, runs in a web browser on 95 or NT using pre-installed (i.e., not run-time downloaded) ActiveX controls, JavaScript, and HTML. - Some data passes as a custom application type, sent as Content-Type: application/x-eRoom, from both POSTs and GETs. - All communications are done via HTTP, speaking to a "standard" (IIS) HTTP server. I've been trying (sometimes successfully) to convey to the powers-that-be over the last year or so that being transferred over HTTP is not a magic bullet. That we risk the following: 1) JavaScript being blocked at the firewall via removal of the <SCRIPT> tags in the HTML. 2) ActiveX controls being blocked; in our case, via removal of <OBJECT> tags. 3) Content-Type: application/x-eRoom being blocked. Now, given what I've read, I would expect 1) to be blocked fairly regularly, possibly even on intranets. I would expect ActiveX controls to regularly be blocked; but would 2) be the method? Or should I expect blocking the be done via Content-Type? Or perhaps a combination of both? And, frankly, I don't know what to think of 3). Generally, I would expect a well-configured firewall or proxy to block 3) until it's told otherwise. Is this off-base? Unfortunately, the firewall I administer is not comprised of each of the commercial packages that we may encounter. I can only guess when confronted with a new problem that appears the occur at the firewall/proxy level. Occasionally, I actually get to speak with the firewall administrators, whose ignorance frequently provides me with some great comic relief. (Me: "Well, do your logs show it being blocked?" Them: "I'm not sure where the logfile is. Can I call you back after I find it?") In short, I would love to hear some opinions on the following: A) In the "real" world, how often am I likely to encounter firewalls/proxies doing 1), 2), or 3)? B) Based on the sketchy information, could I be missing other possible sources of blockage? C) What sort of configurable options are likely be selected in A) or B) that might allow more specificity to prevent impact? (e.g., Traffic from specific servers, etc.) D) On a survivability in hell scale, where 1 represents a snowball, and 10 represents Satan himself, where do things likely stand when it comes to getting configuration changed? (Where, understandably, I am loathe to change the settings on my firewall, to be sure.) E) Expecting a decent portion of firewall administrators to be like those I mentioned above, how restrictive are most commercial firewall products out-of-the-box? (i.e., Is my feeling that 3) should be blocked by default the reality?) F) Am I safe in assuming that proxies are the most likely candidate for problems? (Over, say, Firewall-1 and its ilk? BTW, those folks above had recently purchased Firewall-1. I had an... err... interesting conversation with their folks about Stateful Inspection. But I'll save that for another time.) Sorry for this bulk of questions. And thanks for all helpful thoughts. (Or even thoughts.) Greg --- Greg Haverkamp, Network Administrator/Webmaster, Instinctive Technology See eRoom at http://www.instinctive.com "Where Teams Get Down to Business" Of my many opinions, consider only one to be that of my employer: I drink far too much Diet Coke
Current thread:
- HTTP in practice Greg Haverkamp (Sep 22)
- Re: HTTP in practice Marcus J. Ranum (Sep 22)
- Re: HTTP in practice Greg Haverkamp (Sep 23)
- Re: HTTP in practice Marcus J. Ranum (Sep 23)
- Re: HTTP in practice Greg Haverkamp (Sep 24)
- Re: HTTP in practice Bennett Todd (Sep 24)
- Re: HTTP in practice Paul D. Robertson (Sep 29)
- Re: HTTP in practice Joe Klemmer (Sep 26)
- Re: HTTP in practice Greg Haverkamp (Sep 23)
- Re: HTTP in practice Marcus J. Ranum (Sep 22)
- <Possible follow-ups>
- Re: HTTP in practice Anton J Aylward (Sep 24)