On Thu, Nov 01, 2007 at 08:32:00AM -0400, Cory Snavely wrote: > It has an effect if your Postgres instance isn't blocked at the > firewall, and people are actually trying to access it. Which they will, > unless you block them. As I said, probably much safer to block at the > firewall level--better protection from DOS as well.
My custom is to always set up a firewall on a new server and only allow external access to the services the server is being installed to provide externally. Nobody outside your organization needs to talk to your Postgres. Probably very few hosts *inside* your organization need to talk to it -- possibly only localhost. A nice thing about firewalls is that you can make a port totally vanish for the miscreants: they get nothing back, not even a TCP NAK or ICMP REJECT, in response to their SYN packet. Your cost to silently absorb a packet is quite low. You can sample the rule counters periodically or log attempts if you are interested in statistics. The flip side of DROP policies is not so nice: you have to train yourself to think "firewall?" whenever a desired network flow seems to just disappear. Between firewall rules, IPsec policies, libwrap, xinetd host restrictions, listen() address scope, and application access controls (defense in depth, you know), finding a network connectivity problem can be bad for one's blood pressure. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpV9YZRsusR5.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
