Marcus Ranum wrote:
"...lots of folks are hooking up [HTTP] with little
or no security, getting burned badly..."
Could you give more information on these "burn" cases? It would really help
me in assessing the threat if I knew:
Which types of attack are being used? I know about problems with telnet,
PostScript, and shell scripts. Have any of these been used; how often and
how successfully? Are there other types of attack I haven't heard about yet?
While history isn't necessarily a good predictor of future attacks, it can
be used as a sanity check to see if one's risk analysis is way off base.
Any hard data you have could reduce speculation and improve the quality of
this discussion.
Ken Shores wrote:
"The only way a firewall could protect you against those problems
[mapping document types to viewer applications] would be if
you used a relay which could selectively pass/deny document transfers based
on type. [...more stuff about limitations of this approach...]"
Depending on your analysis of the risks and your site-specific security
policy, filtering based on Content-Type may be a useful tool for some.
This is easily done if you use the CERN httpd as a proxy. You can override
the default mappings from filename extensions to MIME Content-Types by
placing lines like the following in your httpd.conf:
AddType .ps application/octet-stream binary 0.8
AddType .rtf application/octet-stream binary 1.0
AddType .csh application/octet-stream binary 0.5
To find all the defaults (there are about 150 in cern_httpd_3.0pre6),
look in the source at:
Daemon/Implementation/HTSInit.c
When your client (e.g., Mosaic) sees Content-Type "application/octet-stream",
it will ask where you want to save it on your disk, instead of trying to
run a viewing application. This will give your users a chance to look at
it, think about it, move it some place safer, or do whatever your policy
requires for files brought in using FTP, tape, or floppy.
This makes it easy for you to decide which Content-Types you are willing
to accept the risk for. For example, you may initially allow only
text/html, text/plain, image/gif, image/jpeg, video/mpeg, and audio/basic.
Later, when you understand others better, or believe all your users have
upgraded their versions of ghostscript, you can enable other Content-Types.
Please don't flame me if this isn't enough protection for you. I just
suggest it as one way to get finer control over how things come through
your firewall, if it makes sense given your security policy. It would
be nice if future versions of CERN httpd and other proxies made it easier
to configure this kind of allow/deny option. Perhaps configuration
commands like the following could be supported:
deny application/*
deny image/*
allow image/gif
allow image/jpeg
allow text/*
with rules for combining options similar to those in tcp_wrappers. This
would avoid having to look at the source to find all the defaults.
Randy Simons
Computer Security Department
Sandia National Laboratories
|
|
