--On Friday, April 18, 2008 20:30:53 +0200 Mel <[EMAIL PROTECTED]> wrote:

On Friday 18 April 2008 16:53:49 Paul Schmehl wrote:

Firewalls are for preventing access to running services.  By definition, if
you are running a service, you want it to be accessed.

That's your assumption.
First of all, firewalls are for preventing unwanted connections, this is not
necessarily the same as access to running services.
Prime examples: cable modem and windows hosts broadcast spam on an ISP's
network, ping floods. User scans [1], vulnerability scans, open relay
scanners, spammers fall into running services category.

They don't fall into the category of services that you authorized or approved of. Keep in mind, we're talking about *hosts*, individual workstations if you will, not enterprises.

For an individual host it makes a great deal more sense to only run those
services you intend to use ***and keep them up to date and properly

It is an illusion to think that the patch always comes before the exposure.

It's a worse illusion to believe the firewall is going to help. If the service is exposed and compromised, the firewall wouldn't be blocking it anyway. Furthermore, if the host is compromised, the firewall is one of the first things that will be disabled.

Secondly, pending the ammount of services you offer, this can be a full task
and especially for the "hobby" category, it is more time-efficient to shut
off any unauthorized traffic to begin with.
Say, some webapp allows uploading a file and executing it. It is then quite
easy to add a daemon to your server, that you have not configured. With a
firewall in default block mode, this daemon does not receive connections.
Even when the patch is released before exposure, you could be, say sleeping
and it can be too late. For some this is paranoia, for others common sense.

Again, the firewall is providing a false sense of security in exactly the scenario you propose. Where do you think hacker's daemons are running these days? **On the ports that you can't close on the firewall**.

[4] # grep sshd /etc/defaults/rc.conf
sshd_enable="NO"                # Enable sshd

No? Surely you're not using inetd?

I haven't used inetd in years.  I'm not sure why you think I would be.

Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to