On Mon, 7 Jan 2008, Joshua D. Drake wrote:
Certainly and iptables gives you some flexibility in connection availability "before" it hits the actual database but without having to jimmy the production firewall.
It's worth emphasizing that in many environments, it's far more likely one will have root access to configure the local firewall on a database server than access to the main company firewall. It's not unusual for DBAs to have root on their servers, but nobody wants a DBA making Cisco IOS changes. If you've got a recipe cookbook of common firewall requirements it's reasonable for a DBA to handle some of that maintenance without having to go to another department or otherwise call something else in.
There are a bunch of other reasons why you might use a local firewall like iptables on top of both a firewall and the PostgreSQL security:
1) Securing against other sections of the internal LAN, which may not be completely trusted for your database application even though they're on your company's network. Anybody who gets a system plugged in behind the firewall is a potential attacker, and you can't expect the firewall to do all the securing for you.
2) Providing some homogenous connection security to what's done on other systems instead of or addition to the restrictions you can put into pg_hba.conf. If you've got a security auditer who knows iptables because it's used on all the Linux machines, but not PostgreSQL, they're much more likely to give you a thumbs-up if it's obvious the system is secured on the network level before they even consider the database security.
3) The OS kernel will be more efficient in blocking unwanted packets than the database server can be, making it less like you'll be victim to a denial of service against the database from a host that shouldn't be allowed to connect anyway.
4) Funky tricks with things like port forwarding and filtering that you can't do with PostgreSQL alone, and that need to be active for people in the internal LAN. I recall this one time where I needed the database port to be different based on which of the local subnets the connection was coming through (it was a version migration thing). Those were some fun ipchains rules (yeah, that long ago) and I'd have been hard pressed to do that on the firewall instead without a major contortion to the network.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
