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
Sun Cobalt and other Linux administration by Zeffie
Zeffie's Sun Cobalt Restore CD's
A Sun Cobalt and Linux Specialist Since 1999
Sun Cobalt Repairs, Development, and Maintenance.
Home of the Worlds Largest Collection of Sun Cobalt Updates!
Sun Cobalt Spam Filter, Security, Firewall, Anti Virus Products.
734-454-9117 US Toll Free 800-231-4459
Zeffie's Sun Cobalt Restore CD's
Copyright 2009 by Electronic Consultants Inc.