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

> I see this statement all the time, and I wonder why.  What does a firewall
> on an individual host accomplish?

...

> 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.

> So firewalls are 
> self-defeating or completely useless at the host level **unless** you don't
> know what you're doing.

Or, when you do know what you're doing and don't see the firewall as a single 
entity but as a node in the security tree, where tools like grok come in as 
well.

> 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
> configured***.

It is an illusion to think that the patch always comes before the exposure. 
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.

> Firewalls are too often crutches for people that don't want to learn how to
> properly maintain a host.

Or save time, till it can be properly done. You're also assuming that you have 
full control over installed software. The "hobby" case you mention or a 
hosting environment this isn't always reality.

> # sockstat | grep cupsd
> root     cupsd      6208  3  stream /var/run/cups.sock
> root     cupsd      6208  4  udp4   *:631                 *:*

Sure,
block in proto udp from any to any port 631

Works for nfs and rpc as well :)

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

No? Surely you're not using inetd? sshd has tcp wrapper support built in, so 
you can set everything from /etc/ssh/sshd_config, including the port and 
using tcp wrappers. So in the event, inetd is vulnerable, sshd won't be.

[1]
# cat /etc/pf/grok-ssh.conf
file "/var/log/auth.log" {
        type "ssh-illegal-user" {
                match = "Invalid user %USERNAME% from %IP%";
                threshold = 5;   # 5 hits ...
                key = "%IP%";    # from a single ip ...
                interval = 60;   # in 1 minutes
                reaction = "/sbin/pfctl -t scans -Tadd %IP%";
        };

        type "ssh-scan-possible" {
                match = "Did not receive identification string from %IP%";
                threshold = 3;
                interval = 60;
                reaction = "/sbin/pfctl -t scans -Tadd %IP%";
        };
};

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to