Libertonia || stunnel + cvs


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

stunnel + cvs
Por ridiculum departamento nano HOW TO , Sección Diarios Puesto a las Wed Mar 5th, 2003 at 02:21:10 AM CET

Ya hemos vuelto de los examenes (bueno realmente hace casi 1 mes de eso), así que vamos a volver a contar nuestras azañas con linux, las sparcs y otras cosas raras. Primer capitulo: cvs seguro (o un intento de...)

CVS no permite el envio de contraseñas cifradas, y eso a jorginius no le hacía mucha gracia. Estuvimos buscando soluciones y las que encontramos no nos gustaban. Unas necesitaban perl, otras python y la clasica (usar ssh) necesitaba cuentas reales en el servidor. Al final decidimos tunelar cvs mediante SSL con stunnel (que ademas tiene version para windows).

El esquema, mas o menos es: cvs cliente -> stunel cliente ->stunel servidor -> cvs servidor

Empezemos por el final. El servidor cvs se configura tal y como explico Iñaki Arenaza e Ismael Olea.

Ahora vamos a poner el stunnel en el servidor. Stunnel escucha en el puerto que le digamos y redirige lo que le llega a la maquina que le digas y al puerto que le digas. Como se hace eso?.

/usr/sbin/stunnel -d 2045 -r IP_LOCAL:2401

Eso recibe por el puerto 2045 y reenvia al 2041, puerto donde tenemos el servidor de cvs.

Ahora, en el cliente debemos usar stunnel. Lancemos stunnel tal que:

stunnel -c -r IP_DONDE_ESTA_EL_CVS:2045 -d 2041

¿Esto que hace? RTFM ;))). -c indica que lanzamos el stunnel en modo cliente y el -d indica el puerto local. Elegimos 2045 por que es donde esta el stunnel en el otro lado escuchando.

Ahora ejecutamos el cliente de cvs:

export CVSROOT=":pserver:anoncvs@localhost:$DIRECTORIO_DEL_CVS" cvs login

Como se puede ver, nos conectamos en local, para que stunnel redirija todo el trafico cifrado hacia el otro lado del tunel.

Umm, y con esto y un bizcocho, nos despedimos a la espera de alguna critica sobre esta entradilla en el diario :)

< El pingüino y los cuadrúpedos (52 comments) | Teléfono Rojo (27 comments) >

Enlaces Relacionados

· More on ridiculum's Diary
· Also by ridiculum

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

stunnel + cvs | 5 comentarios (5 temáticos, editoriales, 0 ocultos)

El problema de las otras opciones (2.00 / 1) (#1)
por jorginius ("jorginius" en Google Mail) a las Wed Mar 5th, 2003 at 11:54:40 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

O de las que nosotros mismos podríamos proponer, no es que usen Python/Perl/whatever. El problema es que obligan a parchear los clientes.

Por otro lado, la solución que hemos adoptado para el CVS es muy deficiente, desde el el punto de vista de nuestra política de seguridad.

Todos nuestros servicios "privados pero accesibles desde fuera" autentican contra SASL (opcionalmente sobre TLS). Los servicios web, que van a parte por ser "públicos" precisan de certificado expedido por nosotros (con lista de revocados, fechas de caducidad no superiores a los tres meses, discriminación por fingerprint y demás parafernalia), además de autenticación "http simple" (asegurada anteriormente, como ya digo, con SSL) contra la base de datos MySQL; los passwords se almacenan cifrados con MD5.

En este contexto, es imposible encajar CVS. Es un servicio "privado y visible desde fuera" pero no está disponible autenticación vía SASL. Las claves del CVS se guardan en un sencillo archivo texto independiente, cifradas con crypt(), y los passwords se envían en claro.

El tener los passwords de todos los servicios por un lado y los del CVS por otro es una molestia a la hora de administrar el chiringuito y si por si fuera poco esto, no es imposible para un usuario con permisos de escritura, abusar del servidor de CVS, poner el archivo de claves bajo control de versiones y descargarlo (y probar suerte con el "john the ripper" o similar para sacar los passwords).

Eso por el lado de "pserver". Si utilizamos SSH como protocolo de transporte entonces sí: tenemos un CVS "seguro", pero por fuerza estamos obligados a dar cuentas con shell a todos los usuarios del CVS.

Además, el SSH no nos soluciona la papeleta de "SASL para todo, menos para el CVS" ya que no hay (no lo había la última vez que lo miré) un "pam_sasl" que nos permita combinar las cuentas de usuario con SASL y con ayuda del servidor SSH "pammificado" (nota mental: posible proyecto -> pam_sasl).

Resumiendo: CVS es un puñetero y la solución del stunnel no es definitiva. Está en estudio un sistema mejor, que:

No envíe passwords en claro.
Use el estandar SASL de autenticación.
No obligue a parchear los clientes (o de hacerlo, que sea fácil encontrar clientes adaptados en todos los sistemas).

P.D: estamos abiertos a todo tipo de sugerencias.

Subversion (3.00 / 1) (#2)
por ochoto (ochoto_@_diariolinux.com) a las Wed Mar 5th, 2003 at 12:21:03 PM CET
(Información Usuario) http://diariolinux.com

Si no os importa cambiar de SCM Subversion es una buena opción. El acceso al repositorio es mediante DAV proporcionado por Apache2, con lo que tienes solucionado el soporte HTTPS y autentificaciones basadas en LDAP, BBDD, etc.

http://subversion.tigris.org/

[ Padre ]

Lo estuvimos pensando (3.00 / 1) (#3)
por jorginius ("jorginius" en Google Mail) a las Wed Mar 5th, 2003 at 12:54:56 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero ridiculum se me rajó :-).

De todas formas, subversion plantea algunos problemillas nuevos: migrar a Apache2 (certificados, autenticación y mucho más), el tema del interfaz web que, sin ser malo el de SVN, el que ahora tenemos para CVS es mucho más chulo (además de multilenguaje, negociando los contenidos con el navegador) y supongo que alguno más.

También hay que tener en cuenta de que andamos bastante pillados de recursos, con lo que la opción de "pues corre el Apache2 en otro puerto y deja tu Apache como está" no es demasiado viable.

... Y al final me huelo que no sería fácil de integrar con SASL. Sospecho que a golpe de configuración bizarra de mod_auth_external más parche a mod_dav.

[ Padre ]

Me _GUSTA_ la idea (none / 0) (#4)
por Envite a las Wed Mar 5th, 2003 at 10:35:21 PM CET
(Información Usuario)

Mucho mas que otras que conozco. El CVS contra el que trabajo (cvs.gnupg.org) usa SSH.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire

Teclexia (none / 0) (#5)
por ridiculum a las Thu Mar 6th, 2003 at 12:51:49 AM CET
(Información Usuario)

Donde dice:

stunnel -c -r IP_DONDE_ESTA_EL_CVS:2045 -d 2041

Debe poner

stunnel -c -r IP_DONDE_ESTA_EL_CVS:2045 -d 2401

El 2401 es el puerto local, y el cliente de cvs se conecta siempre a ese puerto (supongo que a menos que se le indique lo contrario)

stunnel + cvs | 5 comentarios (5 temáticos, editoriales, 0 ocultos)

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda