RE: [cobalt-security] Qube2 Firewall "feature"

["Jeff Newman" <mjeffn@xxxxxxxx>]

I think that the next time I'm in Souix City, Iowa I'll just have to stop in
and talk to them because I really like the product.  After doing exchange
server in small businesses for the last four or five years, the cobalt
product is definately a relief.

"Given the constraint that the customer has been sold a Gateway Micro Server
because it can do everything ... can the "firewall" feature be configured
such that it provides adequate protection?"

It depends.  No matter how sophisticated the firewall is, if the services
are running on the same machine, many ways exist to get around the firewall.
The firewall used in the Cobalt is ipfwadm that was distributed with RedHat
5 and earlier.  Currently Redhat distributes ipchains which is the new and
improved ipfwadm.  It doesn't change how the firewall filtering capability
other than to give it more configuration frexability for the most part.
These firewalls are stateless in that they can not determine if an indound
packet (ACK) is a lagitimate response to a request from a host behind your
firewall or an illegitamate attempt to connect to a service.  A statefull
inspection firewall maitains a database of connections that originate from
the trusted network and resolve the inbound packets agianst the outbound
requests.  If an inbound packet can't be proven to be a ligitamate response,
it is dropped.  This is what a sonic will do.  Statefull inspection packet
filtering along with Masquerading (Dynamic NAT) is sufficient for
connections to the internet where servers are not run locally and open to
the world.

If public servers are run locally then transparent proxies are needed to
complete the firewall.  Basically, the proxies dissasemble and reassemble
the packets themselves checking to make sure that the payload meets the
specifications of the service to which it is meant.  A famous exploite was
to send huge packets to port 25 to bring down sendmail.  An SMTP proxy will
prevent this.  Each service has its own proxy so, before watchguard for
example, proxying was a real pain.  This is the step that watchguard takes
beyond sonic.

The big advantage of a DMZ is that if the public server is compromized or
DOSed, it is not on the trusted network and therefor will have no direct
effect on the users computers.

Another inportant thing that you want a firewall to do is to temporarily
block address and ports when it recognizes address and port space probing.
I know the watchguard is pretty effective at this but I don't recall sonics
capabilities in this regard.  The watchguard is very good at recognizing
relatively sophisticated attempts at spoofing attacks and out of band ip
options.  The logging on the watchguard is equal to the best i've seen. (i'm
not a watchguard salesman:)

One of the biggest vulnerabilities that I see with the cube is that the
email name is the linux OS username as well.  Send an email and the hacker
is just a password dictionary away from whatever access that user has.  The
hacker then may try password guessing SU or use some other means to get root
access.  One thing that I like about MS Exchange is that the Exchange
usernames are independent from the network usernames.

Don't allow people to access sendmail from outside your network especially
if you are running the SMB service.  Don't use the cube to authenticate your
windows users.  Deny port 139 on the external interface.  Use strong
passwords and disable telnet (it and POP3 use clear text logon) to prevent a
sniffer from getting the username and password.  All it takes is you logging
into root from a remote telnet session while someone is sniffing your
packets (sounds lewd I know) for you to loose control of the system in less
then a minute.  (Now you'll sleep easier!)

As far as the farewall upgrade to sonic that you mentioned, for the few
extra bucks it would be wise to look into the watchguard for its proxy
capabilities in addition to the statefull inpection.  It all depends though
on the budget contraints and what makes the most sense.

Double cheers, Jeff




-----Original Message-----
From: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Malcolm
McLeary
Sent: Monday, March 20, 2000 11:06 PM
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] Qube2 Firewall "feature"


Hi Jeff,

on 21/3/00 3:09 PM, Jeff Newman at mjeffn@xxxxxxxx wrote:

> I didn't know that.  I don't know about adding a modem.  No telling what
> might break in the GUI though.

The Gateway GUI handles it ... I have no idea what they do with the serial
port because the "modem" is in the PCI slot, not connected to the serial
port.

> I went to my local Heffer store (gateway) and inquired about the rebadged
> cube.  They didn't know what I was talking about.  I asked if they ever
> checked out their own web site - and got a 'you talk'n to me' kind of look
> before I was informed that gateway did windows not linux.  That's great
> considering their headquarters is only a two hour drive from me.

Its featured on the front page in Australia ... <http://www.gw2k.com.au/>

> I'd really like to experience the product.  It sounds better then the
> original and Cobalt's MIA support is making me too nervous to keep
> recommending their products to my clients.  What's up with that?  Nine
> months ago I could get a tech support call back within 30 minutes.  Now I
> can't even get a reply to an email.

I had one for a week to play with ... it worked great, only minor changes to
the GUI, a bigger disk, PCI modem, fixed version of netatalk, and it is
better configured straight out of the box ... just turn it on.  It comes
with a Companion CD to install IE5 and OE5 so a client workstation is
immediately able to talk to it.

It solves many of the "I just bought a Qube" questions you see on the list.

Living in Aust I don't phone Cobalt Tech Support, and they don't phone me.
Email support was acceptable as I could send off a "problem" and have a
response the next morning, now ... its days, if at all!

Only time will tell if Gateway can support end users and VARs any better.  I
think they will as they have the infrastructure to support consumer level
and corporate level PCs and servers.  However, from what I can gather the R
& D and bug fixes is still done by Cobalt ... but Gateway may carry more
weight and that may be a contributing factor in the "Cobalt's MIA support".

> I'm about fed up with them and seeing all of the issues floating around on
> the list makes me more nervous.  Seems like people are spending a lot of
> time trying to fix a lot of broken units out there without cobalt's help.
> Like many of us, I do this stuff for a living and bill only for my time,
and
> get paid for my time only if my customers are resonably satisfied with
their
> results.  When I recommend a product, I need access to answeres quickly,
not
> problems.  I am not a, nor are my clients, beta site.  Cobalt has really
> been giving me cause to rethink how I am doing things.
>
> What do you think?

That about sums it up.  :-(

Gateway Aust are pushing the Micro Server as a "one stop shop" for internet
connectivity for a small to medium enterprises ... hence my questioning as
to the suitability of the "firewall" feature.

If Gateway do as you were told "gateway do windows not linux", then they may
have the same Microsoft marketing attitude ... "it doesn't have to work, it
just has to sell.  Hence, down here at least, there could be quite a few of
these little boxes being connected to the internet via their built-in modems
and providing businesses not only with internet connectivity but also user
authentication and storage for the office LAN.

Given the constraint that the customer has been sold a Gateway Micro Server
because it can do everything ... can the "firewall" feature be configured
such that it provides adequate protection?

If the customer eventually upgrades to a faster connection (i.e. moves to
the 2nd ethernet port instead of the built-in modem), then the obvious
addition is a SonicWall because the higher access speed increase the threat
and hence additional protection measures need to be deployed.

Cheers,  Malcolm

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

                       Information Alchemy Pty Ltd
                             ACN 089 239 305
                           Canberra, Australia

Malcolm McLeary                                  Mobile:   0412 636 086
Managing Director                                Email:  mim@xxxxxxxxxx

     This message was sent using Outlook Express 5.0 for Macintosh.



_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security