On Friday 18 April 2008 20:53:37 Paul Schmehl wrote: > --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 , 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.
Well, I don't particularly like someone using my bandwidth to find out if I changed my mailserver config to such that I would now be an open relay, every 10-20 minutes for weeks on end, so I want it to be over with at the TCP level, not at the daemon level. Individual hosts are exactly the target for these scans. Same with the webserver, there are a great number of requests that seperate a scan from a legitimate user. > >> 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. > > 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. In a targetted scenario, this is correct. However, scans precede the attack and one example I gave with grok, you can limit the chances that the attacker gets the information he needs to exploit the bug he's looking for. > Furthermore, if the host is compromised, the firewall is one of the > first things that will be disabled. That would require root. So there's something else wrong in the chain, or it is one of those unfortunate services that run as root. > > 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**. I'm curious which those are. > > >>  # 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. Well, since sshd_enable is set to no, I assumed inetd would be where you've started it. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"