[PLUG] VNC, SSH, and iptables [was: Transfering mozilla mail and newsgroup settings fromlinux to windows]

Cameron Patrick cameron at patrick.wattle.id.au
Sun May 9 23:26:16 WST 2004


James Devenish wrote:

| I usually find it immature when people attempt to refute almost every
| individual sentence in someone else's post, yet the opportunity seems
| to have presented itself to me.

Right.  And I'm afraid that I disagree with your assessment below, and
am going to be equally immature in dissecting it point by point.

| As an example: a lot of users will want to use chat programmes or
| streaming media applications that require "ports to be open" (if I
| can be so loose in my terminology). This means either forcing users
| to configure their firewalls themselves, or consent to
| autonomic/template-based changes, or apply some security-defeating
| strategy like "allow all connections that are initiated from inside
| the firewall".

Why is "allow all connections from inside the firewall" a particularly
security-defeating approach?  It's certainly better that t'other way
around :-)  While it doesn't offer any kind of protection from trojans
on the local machine initiating connections to the outside world, it
does provide real protection against outsiders accessing insecure or
poorly configured servers running on the local machine.

For example, it's quite likely that a stock Debian system used as a
desktop will be running a portmap daemon (for fam, which is used by
GNOME or KDE or some such).  A good case could be made for portmap
listening to localhost by default, but this is not the case (because
then people using portmap for NFS would be upset).  Running a firewall
on the local machine will decrease likelihood of being compromised,
should a vulnerability in portmap be discovered.  The same applies to
whatever other server processes may happen to be running on a machine
which is not used as a network server.

Running a firewall is a simple way of achieving a policy of, "no
services listening to the outside world except for the ones I
specifically allow".  This is a sensible thing to do on most
internet-connected client machines.

| That is, they trust their software vendor to configure their
| firewall properly. Yet, it would seem to be the lack of vendor
| trustworthiness that leads to the perceived need for firewalls in
| the first place.

That's a valid point, and indeed I believe that one of the recent MS
Windows worms propagated (amongst other ways) through a flaw in a
Windows firewall product.

| > never use xhost+ when fault finding,
| 
| I fail to see why you would consider it superior to have people
| disabling both xhost control /and/ their firewall compared to
| merely disabling xhost control.

I think the point was that running "xhost +" on a machine with a
firewall would have the effect of allowing arbitrary local connections
to the X server but not allowing connections from arbitrary hosts on
the Internet (unless the firewall was also disabled), and that this
would is desirable behaviour.

| > never install a webserver (I am thinking of zope, cups,
| 
| There should not be any problem installing these programmes. A problem
| /might/ arise if these apps have security flaws and are exposed to the
| Internet, but content-inspecting stateful firewalls are themselves
| susceptible to these flaws.

Agreed, but in the recent past there have been a heck of a lot more
security flaws discovered in apache and zope than in iptables.  (Since
October 2001, when I first subscribed to debian-security-announce,
there has been one announcement mentioning iptables, five distinct
flaws found in apache, and one in zope.  The zope hole and two of the
apache ones allowed attackers to execute arbitrary code; the iptables
exploit did not.)

| In the case of zope, you might want either to expose it to the
| Internet or to other computers on your local network. In the former
| case, you are not protected against protocol flaws and in the latter
| case, you would need to configure your firewall in an expert manner.

"In an expert manner" !?  Firewalls with a graphical configuration
interface (e.g. Zone Alarm on Windows) generally make it easy to allow
connections only to the local network.  Those like me who set up their
firewall "by hand" using e.g. iptables are doing things the "expert"
way anyway :-) and can set up whatever firewall policies they feel like.

| About the only worthwhile excuse for a personal firewall that springs to
| my mind is to protect against programming errors in file sharing
| services.

I'm afraid I can't really see where you're coming from here; your
mention of "file sharing services" is rather vague and I can't see how
is related to firewalls.

The main reason for having a personal firewall is that you are running
network services on your local machine that really shouldn't be
accessible to the outside world.  (Whether these services should be
running at all, or configured by default to bind to all interfaces
rather than just loopback is another issue entirely.)  With a firewall
you are safe by default, whereas without one, whatever network
services you start are exposed to the internet by default.

| > never use a browser (i.e., the recent posts about wine running a doze
| > trojan),
| 
| A packet filter does not protect your web browser, and even a
| content-inspecting firewall cannot protect against malicious
| scripts or encrypted payloads. Client-side access control can
| assist, but that's physically beyond the scope of a "firewall".

Agreed.

| [more stuff that I agree with, and then...]
| > It is also worth mentioning the logging capabilities of a firewall which
| > is a powerful tool for security and monitoring as well.
| 
| Okay, I agree with you on that one (although, on the flip side, it's
| also a way to cause a denial-of-service situation that works against
| yourself, albeit marginal).

This is why your firewall's logging should be rate-limited :-)

Regards,

Cameron.




More information about the plug mailing list