Re: [pgsql-fr-generale] Configuration du host en 127.0.0.1 et accès distant

Bonjour,

Nous avons pris l'habitude de lancer nos serveurs de la manière
suivante :
/usr/local/postgres/bin/postmaster '-d2' '-i' '-h' '127.0.0.1' '-p' '5444' '-N' '64' '-B' '128' '-D' '/var/datas/postgres/postgres-7.4.2'

Comme vous pouvez le voir nous avons choisi d'indiquer un host sur
localhost afin de bloquer tout accès depuis l'extérieur.

Par contre pour l'administration c'est un peu plus galère pour nous
en ce sens que l'on doit se connecter en ssh sur la machine afin de
pouvoir travailler directement sur la base.

Je me posais la question suivante : si nous n'indiquons pas de host
ou alors si nous indiquons l'ip publique de la machine, cela nous
permettrait de nous connecter à distance via par exemple pgadmin
pour nous aider dans l'administration. Par contre bien sûr il ne
faudrait autoriser des accès que pour notre propre ip dans le
pg_hba.conf.

=> Cette solution n'offre-t-elle pas des possiblités d'attaques du
serveur plus grande que dans notre configuration actuelle ?

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

Cordialement.
--
Didier BRETIN
INFORMACTIS
http://www.informactis.com/

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

Patrick,

Patrick a écrit :
> 1) bien configurer son pg_hba.conf

Qu'entendez-vous par là ? Je comptais simplement indiquer que seule
mon IP était autorisée.

=> Y aurait-il plus de chose à faire ?
=> Existe-t-il un document décrivant de manière plus complète
comment mettre en oeuvre une version sécurisée plus complète
ou plus explicite que la documentation officielle ?

> 2) mettre en place un firewall au niveau OS

Effectivement nos machines postgresql sont déjà derrière une
machine firewall indépendante.

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

Hum ... configurer une deuxième IP privée ... et la connecter
vers notre VPN ... à réfléchir avec mon administrateur ;).

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

Ah bon ? Même si mon serveur est configuré pour répondre sur du
localhost je peux rediriger via SSL le couple localhost/5432 de ma
machine postgresql vers une autre machine/port ? Je croyais que ce
genre de redirection ne fonctionnait pas pour du localhost ... Je
serais curieux de savoir comment vous faites ;).

Cordialement.
--
Didier BRETIN
INFORMACTIS
http://www.informactis.com/

Didier BRETIN <dbr(at)informactis(dot)com> 2005-01-20 16:21
> Patrick a écrit :
> >1) bien configurer son pg_hba.conf
>
> Qu'entendez-vous par là ?

Juste le fait de n'autoriser pile ce qu'il faut, pas plus !

> >2) mettre en place un firewall au niveau OS
>
> Effectivement nos machines postgresql sont déjà derrière une
> machine firewall indépendante.

Personnellement, je pense à un firewall *sur* la machine où il y a
postgresql, pour éviter à ce dernier de recevoir du trafic qui ne lui
est pas destiné au final.

> >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.
>
> Ah bon ? Même si mon serveur est configuré pour répondre sur du
> localhost je peux rediriger via SSL le couple localhost/5432 de ma

(SSH, pas SSL)

> machine postgresql vers une autre machine/port ? Je croyais que ce
> genre de redirection ne fonctionnait pas pour du localhost ... Je
> serais curieux de savoir comment vous faites ;).

Avec l'option -L, qui permet de ``rediriger'' un port distant comme
s'il était local.

Exemple:

*) sur mon serveur, je simule postgresql :-)
nc -l -p 5555 -s localhost

*) sur mon poste, je fais:
ssh -L 4444:localhost:5555 <leserveur>

(cf aussi l'option -N qui est utile dans ce cas là)

*) j'ai alors sur mon poste le port 4444 ouvert (sur localhost
uniquement, donc pas de risques), et:
telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.

TEST

me donne dans l'autre fenêtre avec le nc:
TEST

Ca passe bien :-)
Le ssh qui tourne sur le serveur (l'autre bout de ma connexion donc),
est une appli locale sur le serveur, et peut donc faire une connexion
sur localhost puisqu'elle est locale.

C'est une méthode rapide et pratique quand vous avez besoin juste de
lancer un pgaccess par exemple, quand ce dernier est sur le client et
que le serveur n'a rien de l'interface graphique, et que vous ne
voulez pas changer les autorisations d'accès.

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

>>Ah bon ? Même si mon serveur est configuré pour répondre sur du
>>localhost je peux rediriger via SSL le couple localhost/5432 de ma
>>
>>
>
>(SSH, pas SSL)
>
>
>
>>machine postgresql vers une autre machine/port ? Je croyais que ce
>>genre de redirection ne fonctionnait pas pour du localhost ... Je
>>serais curieux de savoir comment vous faites ;).
>>
>>
>
>
>

Nous utilisons aussi cette technique chez nos clients. un tunnel SSH
permet de faire plein de choses!
Nous lançons sur la machine «cliente» («cliente»!=«cible»)

ssh -C <machinecible> -L 5432:localhost:5432 -g -N -p <le port ssh
choisi> -f

Nous redirigeons également d'autres ports sur la machine cible avec un
iptables pour pouvoir accéder aux autres machines serveur postgresql
directement au travers du tunnel ssh.

Cordialement

--
Jean-Christophe Arnu
Paratronic