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

["Jeff Newman" <mjeffn@xxxxxxxx>]

Do not ignore the knowledge passed on in this thread.  Jeff Lassman and
Malcolm McLeary are absolutely right.  Cobalt's statement seems more meant
to cover their own backside with a disclaimer then to provide useful
guidance to their customers.

A small inaccuracy in Malcolm's description should be clearified.  The cube
uses ipfwadm as it's firewall.  ipfwadm only determines if a packet destined
to a particular port is to be allowed, rejected or denied.  It does not make
any attempt to determine the validity of the requesting host other than to
give you the ability to specifiy particular networks or hosts as having
access to the port or not.  Malcolm's description is of a stateful
inspection packet filter.  These filters look at the header of an incoming
packet to determine if it matches a corresponding request and is therefor a
legitimate response to a request from a trusted host.  Ipfwadm is not
capable of doing this and therefor neither is the cube.

Having said that, ipfwadm (the firewall in the cube) other then being very
obsolete, should be used to block unused ports if for no other reason then
to make it invisible to the outside world on that port.  For example, if you
are not using FTP, there is a big differance between denying access to port
21 with ipfwadm and just not starting the service but not dropping the
packets, from an information gathering point of view.

As far as really firewalling your public servers, packet filtering is one of
three key ingredients.  You need NAT, packet filtering and service proxys.
With regard to the packet filter, a statefull inspection rather than
stateless filter is required to help prevent modern attacks.

If security is a concern, do not ever run a complex protocol on the firewall
and use at minimum a hardend ip protocol stack.  (I guess I disagree a
little here.)  There are volumes of exploites against the sendmail and
appache deamons and it is well known that sendmail uses linux user accounts
for logon and authentication.  Many protocol logins for linux servers are
clear text and capturing usernames and passwords is rather trivial.
Definately, never logon to a remote telnet session from the internet as
root.  If you are going to remote access the machine from the internet, use
SSL.  I don't know how the GUI on port 81 handles loggons.  It would be
interesting to sniff it and find out how secure/insecure that process is.

ADDITIONAL ADVICE:

If you are using the cube alone with a full-period high-speed connection to
the internet then it would be wise to periodically scan from the outside,
the known trojan ports to make sure that nothing is hiding up high in a
listening mode.

Use a long..... complex password to root including caps, numerals, and
unprintable characters and change the root password regularly.

Check the logon logs regularly.  Be aware that an intruder has most likely
spoofed their address anyway and, the more sophisticated ones now are able
to spoof the hidden address space behind the firewall.  (See the recent
thread on hacker logons that speak about an IP that resolves to some domain
in Italy.  If it truely is a hack job, it's 95% certain that the address is
spoofed and would lead you down a long convulted trail that would eventually
lead nowhere, anyway.)

Absolutely, don't let your users connect via DUN to a W9x machine behind the
firewall and then NAT to the internet.  If you do this (without at least
PPTP) you might as well not bother with the firewall at all as sniffing the
logon is trivial if the machine is W98 1st edition or earlier as the user
name and password are either clear text or very poorly encripted.  (Your
just wasting your time achieving a false sense of security.)

Get a resonably priced firewall from sonic systems, or better yet,
watchguard.  They are relatively easy to configure and understand.  It's
worth the expense and effort and you'll rest better too.


Jeff Newman


-----Original Message-----
From: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Jeff Lasman
Sent: Saturday, March 18, 2000 12:16 AM
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] Qube2 Firewall "feature"


Malcolm McLeary wrote:

> >The Qube2 features IP firewalling, which is a simple form of a firewall,
> >whereby the Qube2 begins to process a packet and determine whether or not
> >it came from an acceptable IP address. This is not a fully functional
> >firewall, and should not be considered such.
> >
> >A firewall is a group of related programs that protects a network's
> >resources from users from other networks. This is usually accomplished by
> >running such software on a dedicated machine, separate from the other
> >machines in an organization's intranet. Using the Qube 2 as a firewall
> >could compromise your security, as it is your server. Such a situation
> >would expose your network resources to outside users.
>
> So if I read this right, although the feature is called a firewall, its
> isn't and Cobalt recommend NOT to use it.

Cobalt is pointing out that a firewall should really be on a separate
machine.  You shouldn't be connected to your firewall machine by any
method other than one data stream that does nothing except go through
the firewall.

By running firwall software on a box on which you're running something
else you've seriously compromised it's ability to use it as a firewall.

> So why include it at all?

Because you could use the system as just a firewall if you want to.
Personally, I think it's okay to use a firewall box as a mailserver, and
also as a webserver, but only for insecure sites.

> Can it serve any purpose?

Just stated above.

> I am looking at a situation where NAT is being used so the only "visible"
> host will be the Qube2.  It appears to me that it can only filter packets
> destined to itself, hence you could restrict external access to Qube2
> based services while still permitting internal access to the same
> services.

Until someone finds a hole.

--
Jeff Lasman <jblists@xxxxxxxxxxxxx>
nobaloney.net
P. O. Box 52672
Riverside, CA  92517
voice: (909) 787-8589  *  fax: (909) 782-0205

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