Subject: RE: squid, http-gw and squid-gw

From: Tony Gale <[email-masked]>
Date: Fri, 29 Sep 2000 09:43:32 +0100 (BST)

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

On 29-Sep-2000 Luis Fernando Barrera wrote:
> 
> I recently asked whether squid versus http-gw versus squid-gw....
> Somebody
> "gracefully" sent me to the list archive... So I did it...
> 
> However some questions still bother me, maybe the guys who already
> passed for this info nightmare can give me a hand...
> 
> 1) http-gw is the same as squid-gw?
>       
>       I read that they are almost the same with a little advantage
of
>       squid-gw above http-gw?

http-gw and squid-gw are designed to be used as a component of
a firewall system - i.e. their goal is to enforce a security
policy.

What they have in common is that they both act as an http proxy.

So, which one you use will depend largely on your security policy -
which you have already written, right?

Security professionals would probably give a higher confidence score
to http-gw, but that is not to say that squid-gw is not secure.

> 
> 2) It is not recommended to put squid in the firewall box, right?
>       I saw several messages that squid alone and squid-gw (http-gw)
>             are the same in terms of security...

It is never recommended to have a firewall with a "mix" of software
systems. And, no two pieces of software are the same in terms of
security - functionality maybe.

> 
> 3) You can put the squid software in an internal host and then all
> the http
>     requests from the internal users, go "relayed" to the squid-gw?

Yes.

> 
> 4) If you want to put a public web server, it is not a good idea to
> put it 
>    behind the firewall, even with the "accelerated options" of
> squid
>    or another trick from squid-gw, right? 

Correct.

> 
> 5) You can put the web server in a third network segment, using a 3
> nic in the
>    firewall, and configure the squid-gw to ONLY permite http
> traffic from
>    the web server to the internet and viceversa?

You have to be *really* careful here. The FWTK is not designed to
operate in this way. I would not recommend it.

It would be better to have a separate parallel box to handle incoming
connections and have the internet web server behind that (not
connected to your internal network).

For example, ou have to pay attention to CONNECT handling on incoming
connections.

It would be better to buy a commercial firewall that is designed to
do what you want.

>       
> How am I doing?  My head is a little mixed up, maybe some
> definitions
> of the products and their intentions could help... Anybody know
> these definitions?

For some good text try:

http://cs-www.ncsl.nist.gov/nistpubs/800-10/main.html

-tony

---
E-Mail: Tony Gale <[email-masked]>
There are only two kinds of tequila.  Good and better.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

---

From: "C. Regis Wilson" <[email-masked]>
Date: Mon, 2 Oct 2000 10:39:59 -0700

> http://cs-www.ncsl.nist.gov/nistpubs/800-10/main.html
I like the link, but the graphic on the top of the page shows a
castle with walls, a moat, and guards, but the drawbridge is down!!

:)

--Regis

---

From: Joseph S D Yao <[email-masked]>
Date: Mon, 2 Oct 2000 16:05:24 -0400

On Fri, Sep 29, 2000 at 09:43:32AM +0100, Tony Gale wrote:
...
> operate in this way. I would not recommend it.

Odd.  ISTM that it is quite usable in this way, and that many people
are doing so.  So, if it was not designed in, that was pretty lucky.

Can you tell me on what basis you say this?

Thanks.

-- 
Joe Yao				[email-masked] - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.

---

From: Tony Gale <[email-masked]>
Date: Tue, 03 Oct 2000 09:56:14 +0100 (BST)

> Can you tell me on what basis you say this?

The FWTK is designed to provide proxy services for internal users to
access an external network.

It is not designed to handle systems with lots of interfaces. You'll
note the lack of interface binding facilities.

squid-gw can bind to a specific interface (though it's not fully
documented). But now you have software that does, and software that
doesn't. Have you considered all possible interactions?

As usual, you have to pay special attention to CONNECT handling. The
squid-gw documentation isn't even consistent in it's description of
it's CONNECT handling.

What if someone breaks into the web-server on the third segment. Is
your internal network still protected?

Have you inspected the squid-gw code? It certainly hasn't had as much
review as the FWTK components.

As I said, you have to be *really* careful. I didn't say it wasn't
possible.

-tony

---
E-Mail: Tony Gale <[email-masked]>
"And remember: Evil will always prevail, because Good is dumb."
-- Spaceballs

---

From: [email-masked]
Date: Tue, 3 Oct 2000 14:40:05 +0400

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

It is definitrly not designed to operate that way. fwtk proxies are
targeted on preventing client side from being attacked and can do little
to prevent data-driven attacks to _servers_. (nearly all firewalls
including commercial ones suffer from the same problem, though)

Just get a buch of recent bugtaq server exploits and see if fwtk can help
with it any way.

I'd be happy to see a set of patches to solve^H^H^H^H^Hworkaround that issue.
Looking into what zorp does can provide a good start.

Joseph S D Yao <[email-masked]> said :

> ..

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

---

From: [email-masked]
Date: Tue, 3 Oct 2000 16:26:41 +0400

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

> doesn't. Have you considered all possible interactions?

You can achieve that by using ipbind patch and inetd binding features.
The problem lies in another place.
 
> squid-gw documentation isn't even consistent in it's description of

Where? it is documented quite well.
 
> your internal network still protected?

It depends on your setup. In general - if you do not grant additional
rights to your third segment, the answer is yes.
 
> review as the FWTK components.

I did, and my general impression was that it is one of the safest part
of code except maybe some mjr written by his own ;)

Though it is not designed to pass requests to the service network.
Hope http-in will get some development.
 
> As I said, you have to be *really* careful. I didn't say it wasn't

You always have to. There is no such thing as paranoia, that's all true ;).

                                     _     _  _  _  _      _  _

---

From: Tony Gale <[email-masked]>
Date: Tue, 03 Oct 2000 14:02:20 +0100 (BST)

> The problem lies in another place.

Merely pointing out potential problems, not giving a definitive list.

> Where? it is documented quite well.

----------------------------------

Bad request: unknown method

        squid-gw currently supports only the GET, HEAD, and POST
        request methods.  Unsupported request methods include PUT and
        CONNECT.

----------------------------------

  connect <HOSTNAME-PATTERN>[:<PORT>]... [ -ipaddr <IP-ADDRESS>... ]
      [ -delay <SECONDS> ] [ -message <MESSAGE> ]
      [ -hosts <EXTENDED-HOST-PATTERN>... ]

     Specify access permissions for https (SSL) based on the
     destination, that is, on the destination host....

----------------------------------
> rights to your third segment, the answer is yes.

Again, I wasn't trying to point out every potential problem area,
just some as examples.

> Hope http-in will get some development.

Yes - the standard of coding in the FWTK can be, err... variable.

<STATEMENT TYPE=sweeping>
But really, servers shouldn't require a "http-in" if the network
design is right, with appropriate packet filtering and separation.
Server software should be security hardened anyway. If it isn't then
you've probably lost the battle already.

I don't think an "http-in" would save you from most (any) of the
server related bugs which have been reported. Most are due to bad cgi
programming.
</STATEMENT>

> You always have to. There is no such thing as paranoia, that's all

Just because you're being paranoid doesn't mean people aren't
out to get you.

-tony

---
E-Mail: Tony Gale <[email-masked]>
The Kennedy Constant:
	Don't get mad -- get even.