|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: RE: [fw-wiz] Web access for everyone
From: LeGrow, Matt (Matt_LeGrow
NAI.com)Date: Tue May 23 2000 - 14:39:57 CDT
- Next message: Rafael Teixeira: "Re: [fw-wiz] Stripping MIME attachments at FW-1"
- Previous message: Rogue Bolo: "Re: [fw-wiz] FW-1 throughput question"
- Maybe in reply to: Alex Lim: "[fw-wiz] Web access for everyone"
- Maybe reply: LeGrow, Matt: "RE: [fw-wiz] Web access for everyone"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Paul D. Robertson [mailto:proberts
clark.net]
> Sent: Monday, May 22, 2000 1:15 PM
> To: Alex Lim
> Cc: fw-wiz
> Subject: Re: [fw-wiz] Web access for everyone
>
>
> On Tue, 23 May 2000, Alex Lim wrote:
>
> > > You're also missing the risk of active content,
> especially ActiveX and the
> > > newer COM-over-HTTP stuff (assuming MS products).
> > >
> >
> > I am just curious about your implication of the MS products
> assumption.
> > Are you saying that MS product allows COM-over-HTTP ? :)
>
> That's what I read they were going to add in, I don't know if
> it's out yet
> though.
>
CIS (COM Information Services) is in NT 4.0 as of SP 4. For Windows
95 and 98 you will need a special OS patch.
You need to set the default transport for your DCOM object to what
Microsoft refers to as "tunneling TCP". The operation of the
protocol is very simple; if you configure your MSIE "Internet
Options" to accept a proxy, your DCOM application will attempt to
connect to the proxy server you configure and issue an SSL-style
"CONNECT" request. If you don't specify a proxy, your DCOM app will
send out an "RPC_CONNECT" command with HTTP headers, thinly-disguised
as a legitimate HTTP request, over port 80.
On the server side, you have to have IIS running, which acts as
"middleware" between the DCOM app and the requested object,
translating the HTTP-like requests into COM requests on the server
machine.
Because of the RPC_CONNECT syntax, you can pick up a non-proxied DCOM
request and control it, if you wish, but a proxied application looks
just like any other SSL traffic.
Matt LeGrow
Network Associates, Inc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Note : Opinions expressed herein are most certainly NOT that of my
employer :-)
> >
> > BTW, is COM-over-HTTP == HTTP covert channel ? I attended the
> > recent Blackhat briefing and they were referencing this concept
> > as
> HTTP covert
> > channel. I thought I should get my terminology right.
>
> *My* understanding of covert channels is that it _isn't_, since
> it's simply the malicious use of a current information channel. A
> *lot* of people are using the term these days to mean something
> other than what I understand it to be:
>
> For instance, sendnig telnet over DNS is misuse of a normal
> communication
> channel. Derriving information by the timing of DNS
> responses would be a
> covert channel because packet timing isn't normally a
> communications channel.
>
> However, popular usage has killed the technical meaning of
> "BAUD" and made
> it equivalent to "bps" despite my objections ;)
>
> > > You might have difficulties completely removing Web
> access as systems
> > > support, security information, patches, and HR functions move
> > > to Web-enabled applications.
> > >
> >
> > That was precisely one of our problems. Everyone in the
> company seems to
> > have a legitimate reason for going into the web and our
> management is
> > always on our backs asking if we are ready to release the
> floodgate. :)
> > So naturally, I am just curious how other companies achieve
> this without
> > adding too much risk to their organisations.
>
> Most companies accept the risk, IMO witout enough dilligence.
>
> > > > Your opinions or experiences pls ? Any comments will be
> appreciated.
> > >
> > > I'd look seriously at remote display for at least
> critical users, running
> > > the browser on a fairly well-protected machine and
> exporting the display
> > > to the end-user desktop gives the advantage of not
> killing functionality
> > > while still isolating external traffic to a more
> protected host. If that
> > > host is filtered pretty heavily, things can probably be
> made reasonably
> > > secure.
> > >
> >
> > I've got a similar advice from Ben Nagy (Volante IT) and am
> > giving serious thought to it. Franking speaking, that's the best
> solution I got
> > so far. Thks, you fellas are wonderful !
>
> It's that, or switch boxes to do remote display - more expensive,
> but better seperation. Some .au company was selling some sort of
> switched firewall thing in a simialr vein.
>
> At my last company, I *really* wanted to try to push WebTV access,
> but didn't seem to find a good selling point that compared well to
> the head-end costs of an in-house cable system and tuner cards for
> all the PCs. Remote display works well and is very cost-effective
> given the complete seperation it gives.
>
> Paul
> --------------------------------------------------------------
> ---------------
> Paul D. Robertson "My statements in this message are
> personal opinions
> proberts
clark.net which may have no basis whatsoever in
> fact."
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>
iQA/AwUBOSrejfbW52zw8/NBEQJMUQCeNrUDVoQR7FZ5QET1gm9ZmWojuF8AoIPi
rRrPffZMB3GQ4PIYRI6FaQm5
=Pskv
-----END PGP SIGNATURE-----
- Next message: Rafael Teixeira: "Re: [fw-wiz] Stripping MIME attachments at FW-1"
- Previous message: Rogue Bolo: "Re: [fw-wiz] FW-1 throughput question"
- Maybe in reply to: Alex Lim: "[fw-wiz] Web access for everyone"
- Maybe reply: LeGrow, Matt: "RE: [fw-wiz] Web access for everyone"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]