Re: Con

Didier BRETIN <dbr(at)informactis(dot)com> 2005-01-20 10:54
> => Cette solution n'offre-t-elle pas des possiblités d'attaques du
> serveur plus grande que dans notre configuration actuelle ?

Oui, puisqu'il va recevoir des paquets de ``n'importe où'' et devra
vérifier via pg_hba.conf s'il doit les traiter ou non.
Donc:
1) bien configurer son pg_hba.conf
2) mettre en place un firewall au niveau OS, afin de ne remonter sur
postgresql que ce qui le concerne vraiment. Bref c'est la même chose
que dans le pg_hba.conf, donc c'est embêtant pour la maintenance,
mais deux filets de sécurité valent mieux qu'un.
Et pour tous ceux non permis, ils verront un port fermé, comme si
postgresql n'écoutait pas.

> => Quelle solution utilisez-vous de votre côté ?

Personnellement, pour les cas où mon serveur écoute sur l'extérieur
et j'ai besoin d'y accéder, soit je fais comme précédemment, soit
j'utilise IPSEC et un bloc d'IP privées avec des filtrages et
postgresql qui écoute sur une IP privée et n'accepte donc que les
connexions venant d'une interface chiffrée. Plus complexe à mettre en
oeuvre mais ``plus'' sûr.

Parce que, outre l'accès, les données sont transmises en clair après
(y compris le mot de passe), sauf si vous utilisez SSL au niveau
postgresql. Le VPN me permet donc de filtrer les accès et d'assurer
le chiffrage de bout en bout, indépendamment de postgresql (je me sers
du VPN pour d'autres choses que juste postgresql).

Pour un besoin ponctuel, vous pouvez aussi faire une redirection de
port avec ssh, ce qui vous permet de garder postgresql sur localhost,
de vous connecter à distance, et de chiffrer le trafic de bout en
bout.

--
Patrick Mevzek
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw