Estas aquíBlogs / Blog de calel

Blog de calel


OpenVPN en Debian

Una red privada virtual (VPN) es usada para establecer una conexión encriptada, punto-a-punto, entre dos computadores. El uso más común de una VPN es para exportar en forma remota aplicaciones X, o incluso el escritorio completo del servidor. Por ejemplo, podemos correr en el computador de casa aplicaciones o el escritorio del servidor del trabajo.

El escritorio se puede levantar en forma remota con XDMCP, de hecho es la manera de usarlo dentro de una red interna, pero cuando la conexión viaja por Internet, en donde no se puede suponer que existe privacidad alguna, una VPN es la manera de asegurarlo.

En la configuración a continuación, el servidor remoto y computador local (cliente) pueden ser intercambiados sin mayores consideraciones.

Instalando y configurando OpenVPN

Instala el paquete openvpn en servidor y cliente,

# apt-get install openvpn

Genera una llave secreta,

# openvpn --genkey --secret /etc/openvpn/static.key

en uno y copiala en forma segura al segundo, por ejemplo, con Secure Copy,

# scp -p /etc/openvpn/static.key root@servidor.debian:/etc/openvpn/

En el servidor remoto (el que va a servir el escritorio), crea el archivo /etc/openvpn/tun0.conf y agrega,

dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret static.key

Los números IP 10.x.x.x pueden modificarse a gusto. Lo importante es asignarle, dentro de una misma subred (10.x.x), un IP a cada computador. La llave secreta se encarga que solo aquellos computadores que tienen la llave puedan crear el túnel. Por eso es importante proteger la llave bien (como cualquier otra llave encriptada). En este caso, 10.9.8.1 es el IP del servidor remoto, 10.9.8.2 el IP del cliente.

En el computador cliente (local), crea también el archivo /etc/openvpn/tun0.conf y agrega,

remote 100.10.2.10
dev tun0
ifconfig 10.9.8.2 10.9.8.1
secret static.key

en donde "remote" es el IP público del servidor remoto. En la configuración del cliente, los IPs asignados van revertidos.

Inicia el servidor OpenVPN en servidor remoto y cliente,

# /etc/init.d/openvpn start

El servidor OpenVPN va a crear en ambos una interfase de red llamada tun0,

# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.9.8.2  P-t-P:10.9.8.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

que hay que tratar igual que una interfase de red normal. En particular, hay que incluirla en el cortafuegos. Usa como guía la versión servidor de http://man-es.debianchile.org/cortafuego.html.

Edita /etc/network/if-pre-up.d/firewall y agrega en la cadena INPUT,

  # VPN
  $IPTABLES -A INPUT -i tun0 -s 10.9.8.1 -j ACCEPT

en el cliente y,

  # VPN
  $IPTABLES -A INPUT -i tun0 -s 10.9.8.2 -j ACCEPT

en el servidor.

Es también necesario abrir el puerto 1194 UDP en la interfase externa. Edita /etc/network/if-up.d/firewall y agrega,

  # VPN
  $IPTABLES -A pqtes-udp-permitidos -p UDP -m state --state NEW --dport 1194 -j ACCEPT

El cortafuegos se puede reiniciar con,

# export IFACE=lo ; /etc/network/if-pre-up.d/firewall ; export IFACE=eth0 ; /etc/network/if-up.d/firewall

Eso es todo. Ahora prueba conexiones desde el cliente hacia el servidor remoto, por ejemplo,

$ ping -c3 10.9.8.1
PING 10.9.8.1 (10.9.8.1) 56(84) bytes of data.
64 bytes from 10.9.8.1: icmp_seq=1 ttl=64 time=25.2 ms
64 bytes from 10.9.8.1: icmp_seq=2 ttl=64 time=28.2 ms
64 bytes from 10.9.8.1: icmp_seq=3 ttl=64 time=27.0 ms

--- 10.9.8.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 25.274/26.834/28.206/1.204 ms

De aquí en adelante establece cualquier conexión privada con el IP 10.9.8.1.

El wiki OpenVPN muestra como exportar el escritorio del servidor remoto.

El uso de demoras en Exim4 para combatir SPAM

Recientemente hice una modificación pequeña a la configuración de Exim4 para eliminar ataques de diccionario. La modificación fue tan exitosa que la publiqué en el Blog,

http://www.debianchile.org/?q=node/135

La configuración descrita impone una demora de dos minutos si el IP intenta repartir más de un correo a un receptor inexistente, dentro de ese lapso. En un periodo menor a una semana habían cesado todos los ataques de diccionario.

Quedé sorprendido que una simple demora de dos minutos hiciera desistir a spameros de atacar mi sitio. Esta demora debe ser costosa. ¿Por que? Este es mi razonamiento: Los spameros basan su éxito en la teoría de probabilidades. Si bien la probabilidad de éxito (lograr que un SPAM pase todos los escrutinios de Exim y Spamassassin) es bastante baja, la cantidad de pruebas, número bien grande, hace que al fin se cuelen uno que otro SPAM. En eso consiste el éxito de un spamero. El número importante es entonces el máximo de conexiones posible que el servidor del spamero puede establecer. Ese número es grande, pero no infinito. Si Exim mantiene por dos minutos la conexión abierta, a la espera, para después responder que deniega la conexión, el costo de la demora se torna inaceptable para el spamero si dentro de esos dos minutos puede en vez hacer miles de otros intentos. Ese es el motivo por el cual una pequeña demora se torna tan costosa.

He encontrado varios puntos en la configuración de Exim en donde insertar una leve demora hace desistir otros ataques recurrentes, o al menos disminuirlos.

Edita el archivo /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt y modifica según descrito.

  1. DNSBL

    # DNS blacklist
    drop
       log_message = listed by $dnslist_domain
       dnslists = bl.spamcop.net : b.barracudacentral.org : zen.spamhaus.org : dnsbl.sorbs.net
       delay = 2m

    Esta modificación impone una demora de dos minutos si el sitio ya está marcado por una lista negra DNS y puede aplicarse en cualquier punto a partir de aceptar una conexión autenticada,

    accept
       authenticated = *
       control = submission/sender_retain

    Aplicarla antes de la autenticación puede bloquear a usuarios locales que envían correo desde redes dinámicas (que generalmente están todas en listas negras DNS).

  2. Intentos de relay.

    Modifica,

    require
       message = relay not permitted
       domains = +local_domains : +relay_to_domains

    por,

    drop
       message = relay not permitted
       !domains = +local_domains : +relay_to_domains
       delay = 2m

    Es en el fondo la misma regla, excepto a que bota inmediatamente el mensaje, imponiéndole la demora a quien intente usarnos ilegalmente como relay.

  3. Verificación de dirección.

    # .ifdef CHECK_RCPT_VERIFY_SENDER
       deny
         message = Sender verification failed
         !acl = acl_local_deny_exceptions
         !verify = sender
         delay = 2m
    # .endif

    Eficiente para aquellos intentos que usan emisor con dominio falso, inexistente o inventado.

  4. Receptor verificable.

    Modifica,

    require
       verify = recipient

    por,

    drop
       !verify = recipient
       delay = 2m

    Es en el fondo la misma regla, excepto a que bota inmediatamente el mensaje si el receptor no existe, imponiéndole además la demora.

Todas estas modificaciones hay que usarlas con cuidado, porque Exim tiene un máximo de 25 conexiones simultaneas. Si el sitio es atacado a una tasa alta, las demoras pueden fácilmente agotar las conexiones y botar no solo SPAM, sino también correo legítimo. Una buena práctica es ir insertando las modificaciones una a la vez e ir monitoriando el efecto, porque la tasa de ataques irá disminuyendo con cada una de ellas, pero a medida que transcurra el tiempo.

Hecha cualquier modificación, actualiza la configuración y reinicia el servidor,

# update-exim4.conf
# /etc/init.d/exim4 restart

Nuevo depósito Debian Unofficial

Un nuevo depósito ha surgido a partir del otrora Debian Unofficial. Este nuevo depósito, llamado "Unofficial Maintainers", distribuye como antes paquetes no oficiales que, por motivo de licencia o restricciones varias, no se encuentran en el depósito oficial de Debian. Incluye software como,

lame
libdvdcss
xvidcore
mplayer-codecs
ttf-microsoft
flash-player
opera
skype

entre otros. Muchos de estos son también parte de Debian Multimedia, aunque no todos.

La manera de usarlo es como de costumbre. Inserta en /etc/apt/sources.list,

deb http://unofficial.debian-maintainers.org/ lenny main contrib non-free restricted

También se puede usar la versión sid o unstable. Está anunciada una estructura para Squeeze (testing), pero ésta vendrá más adelante.

Instalando Debian en un Dell Mini 9

El Dell Mini 9 tiene el CPU Intel Atom de bajo consumo, con 1 GB de RAM, 8 GB de disco de estado solido y Ubuntu 8.04 pre-instalado.

Ubuntu configura la red con Network Manager, que no funciona para definir una conexión de red inalámbrica encriptada con WPA. Intenté desactivar Network Manager, desinstalarlo incluso, pero no hay caso. A pesar de definir la red en /etc/network/interfaces, levantando la interfaz al arranque con auto eth1, Ubuntu simplemente no la levanta. Quedé sorprendido de lo malo que es Ubuntu, pero claro, vengo del mundo Debian.

La experiencia con Ubuntu y Network Manager parece ser algo recurrente, porque leí muchos foros describiendo el mismo síntoma, pero ninguno dando la solución. Alguien por ahí dijo que lo que pasa es que Ubuntu levanta la red cuando aun hay ciertos dispositivos que no se cargan y que por eso falla. Pero Debian no tiene este problema, que además parece demasiado trivial de resolver.

Mi percepción es que Ubuntu trata de hacer con Network Manager algo similar a Windows - ¿Quiere configurar la red automáticamente? (sí/no)... relájese, reclínese confortablemente en su silla y observe como bochornosamente falla.

En fin, hice un script que corre 20 segundos después del arranque que en una línea dice "ifup eth1". Quedé muy insatisfecho con esta solución, que aunque funciona, es tan burda e innecesaria y deja por un buen rato varios servicios marcando ocupado (como ntp y skype).

Buscando una solución Debian, descubrí que el CPU Intel Atom es de la misma arquitectura que los ASUS Eee PC. Me embarqué en una instalación Debian con un memory stick USB según descrito en,

http://wiki.debian.org/DebianEeePC/HowTo/Install

Funcionó a la primera. Existe además un depósito APT específico para esta arquitectura,

deb http://eeepc.debian.net/debian lenny main contrib non-free

Contiene algunos módulos para el núcleo y script para que ACPI maneje los botones y otras cosas. Me imagino que con el tiempo estos paquetes van a pasar al depósito Debian Main.

Mi Dell Mini 9 funciona ahora como debe, con GNOME (core), OpenOffice, Acroreader e incluso Skype. Todas las interfaces de red se levantan al arranque con Guessnet sin necesidad de marullos ni malabares especiales. Qué gran distribución es Debian!

Solución de problemas

1) La tarjeta de red inalámbrica Broadcom BCM4312 (14E4:4315), variante de bajo consumo, no está soportada por el dispositivo b43. Hay que instalar uno híbrido hecho por Broadcom.

Instala los paquetes module-assistant, debhelper, make , wireless-tools y quilt. Descarga la fuente del dispositivo versión squeeze,

http://packages.debian.org/squeeze/all/broadcom-sta-source/download
http://packages.debian.org/squeeze/all/broadcom-sta-common/download

e instala los sendos paquetes.

Corre,

# module-assistant auto-install broadcom-sta

Previamente a cargar el módulo en el núcleo, es necesario instalar el firmware Broadcom con el paquete b43-fwcutter. Instala este paquete, luego carga el módulo,

# modprobe wl

y corre iwconfig. Eso es todo. Configura la red inalámbrica como de costumbre.

2) El segundo y último escollo que encontré fue que si bien el módulo de la tarjeta de sonido estaba cargado, el servidor ALSA corriendo y alsamixer mostrando los niveles de volumen como de costumbre, los parlantes no emitían sonido alguno. Esto sucede porque la tarjeta de sonido se carga como la segunda en el orden, la primera siendo la tarjeta de sonido asociada a la camara web. Para cambiar el orden edita /etc/modporobe.d/sound y agrega,

alias snd-card-0 snd-hda-intel
options snd-hda-intel index=0 model=dell

Esto hace que el módulo snd-hda-intel se cargue como snd-card-0, un alias para indicar la primera tarjeta de sonido. Reinicia el computador.

Google Dashboard y la privacidad del navegador

Desde el lanzamiento de Google Dashboard he leído artículos elogiando a Google por su transparencia, otros haciendo hincapié en el servicio que presta y los más haciendo comentarios espeluznantes sobre la privacidad en Internet. Lo cierto es que Google ha venido haciendo algo que dijo no hacer - asociar búsquedas con personas. Lo hace mediante la cuenta Google, a la cual ingresamos, por ejemplo, cuando leemos el correo GMail. En este caso Google hace una asociación directa entre persona y uso de productos Google, incluyendo YouTube. El lanzamiento de Google Dashboard corresponde justamente a un intento de acallar voces criticas sobre esta práctica.

Pero, siendo justos, no es solo Google el interesado en conocernos mejor, en querer hacer un dossier personal sobre cada uno, los casi siete mil millones de individuos que habitan el planeta Tierra. Existe espacio de almacenamiento suficiente para ello. Cada empresa, independiente de su propósito, le gustaría usar información personalizada para dirigir las ofertas de sus productos, cualesquiera estos sean. La "empresa" podría ser una entidad comercial, pública o gubernamental. El "producto" podría ser una simple afeitadora, las próximas elecciones o seguridad nacional, concebida a la manera particular de cada interés. El uso de información personalizada en Internet no tiene límites, no conoce fronteras. Es más, no existen limites ni fronteras legales. Debemos entonces suponer, a priori, que cualquier movimiento que hagamos en Internet es sujeto a intervención, partiendo del proveedor, pasando por cualquier ruta que nuestra señal decida hacer hasta la pagina web final que estamos visitando. Debemos también suponer que el sistema operativo que usamos puede posibilitar, facilitar, incluso practicar la intervención. Me refiero obviamente a sistemas operativos de código cerrado, ajenos al escrutinio público; Windows, Mac OS X y (¿por qué no?) Google OS.

Parece existir una suerte de ceguera con respecto a las potenciales infracciones a la privacidad que Internet ofrece. En Europa se debate sobre la petición que hacen las empresas mediáticas que sienten violados sus derechos de autor. Mediante la intervención de las señales de cada individuo quieren obligar a cada proveedor de Internet a entregar información sobre el uso de P2P para poder perseguir legalmente a los infractores. Una simple estimación indica que se requerirían recursos especiales para perseguir legalmente a los millones que usamos P2P. Las empresas mediáticas contraatacan diciendo que basta perseguir a unos pocos casos "emblemáticos" para asustar y hacer desistir a la población pirata, no siendo necesario perseguir cada caso en particular (sic). El uso de Internet para compartir archivos, sujetos a copyright o no, es una de las tantas aplicaciones de Internet. Sin embargo, las empresas mencionadas parecen tener un oído preferencial en ciertos gobiernos y parlamentarios europeos. Algunos parecen incluso dispuestos a proveer los recursos públicos necesarios para satisfacer las demandas de estas empresas. ¿Por qué tanto trato preferencial, se preguntan muchos? Los proveedores de Internet, por otra parte, se oponen a la medida porque dicen sería tecnológicamente difícil asociar conexión con individuo, que aumentarían sus costos, los que inevitablemente serían traspasados a sus clientes, nosotros. Este argumento es, sin embargo, también débil, porque no es tecnológicamente difícil. Es moralmente dudoso, al igual que lo es intervenir las llamadas telefónicas, el correo, nuestras conversaciones, nuestros pensamientos. La verdad es que los proveedores de Internet ven como un peligro el hecho de que tengan que admitir las practicas de intervención no regulada que desde hace mucho tiempo practican. Una nota cómica con respecto a esto la puso Elton John, quien en entrevista dijo que desearía que cerraran Internet por unos años para poder combatir las descargas ilegales de música, como si el propósito de Internet fuera solo descargar su música para perjudicarlo personalmente.

¿Cuanto sabe Google sobre nosotros? Sobre mi poco, aparentemente. Porque si bien tengo una cuenta GMail, la uso muy poco. La información almacenada sobre mi en Google Dashboard era limitada. Correspondía a búsquedas que en pocas ocasiones efectué mientras descuidadamente me encontraba conectado a Google Account. ¿Cuanto sabe de ti? Si tienes una cuenta con Google, métete a Dashboard y ve. Es posible borrar la información y deshabilitar la creación de un historial. Esto en principio, porque "borrar" puede significar no más accesible a ti, no que efectivamente Google la borre de sus servidores. Porque desde hace mucho existe el rumor popular que Google guarda todos los correos electrónicos, incluso aquellos que borraste, para después, con tiempo, ser escaneados por servicios secretos. Rumores nada más.

¿Hace AOL, Yahoo, Bing y potencialmente todo sitio web que visitamos lo mismo que Google? Solo ellos lo saben. Con Dashboard, Google ha sido infinitamente más transparente que el resto. Se merece entonces un elogio. O mejor dicho, se merecen un elogio todas aquellas voces críticas que obligaron a Google a transparentar algo sus potenciales violaciones a la privacidad.

¿Como nos espían? Muchos sitios depositan un "cookie" cada vez que los visitamos, un pequeño archivo guardado en nuestro disco duro con información predefinida. Muchos de estos cookies son honestos. Sirven, por ejemplo, para guardar el nombre de usuario u otra información que puede facilitar la navegación después de la primera visita. Pero, un cookie es potencialmente también un pequeño espía. Todo depende de qué información es guardada y como es usada posteriormente. Algunos navegadores permiten bloquearlos, pero muchos sitios no "funcionan" o, mejor dicho, no permiten visitarlos si no pueden depositar su cookie.

Google reconoce con Dashboard que asocia información sobre nuestras búsquedas y visitas a YouTube mientras estamos conectados a Google Account. Pero Google es también de aquellos sitios que simplemente no funciona si no habilitamos los cookies, según dicen para poder ofrecernos alternativas mientras escribimos el texto que deseamos buscar. Y sí, parece ser bastante útil, a veces. Pero, ¿Quién podría desmentir el hecho que el cookie también puede ser utilizado para personalizar la información mientras no estamos conectados a Google?

No es recomendable bloquear la deposición de cookies, porque muchos sitios nos bloquearían de vuelta. El navegador de código abierto Firefox (iceweasel en Debian) permite, en vez, borrar los cookies cada vez que finalizamos la sesión. Esta es potencialmente la única manera disponible que tenemos que protegernos de los cookies. Se hace así: anda a "Editar/Preferencias/Privacidad". En la sección "Datos privados" marca "Limpiar siempre los datos privados cuando cierre Firefox".

Marca "Configuración" y marca "Cookies".

Cada vez que cerramos el navegador, los cookies depositados durante la sesión son borrados. Así no queda rastro de lo que hicimos en la sesión anterior y el sitio no puede usar el cookie para recoger información pasada. En principio evitaría el potencial espionaje. Digo bien, en principio.

Eliminando ataques de diccionario con Exim

Recientemente empecé a experimentar ataques al puerto SMTP con miles de correos con nombres generados al azar, los así llamados ataques de diccionario. Encontré una solución que fue milagrosa. Los ataques cesaron prácticamente de inmediato. Reproduzco la configuración hecha en exim4.

Edita /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt y agrega,

# Drop the recipient if the previous attempt failed
drop
   condition = ${if = {${eval:$rcpt_fail_count}}{1}{yes}{no}}
   message = too many bad recipients
   delay = 2m

justo después de aceptar una conexión autenticada. Actualiza y reinicia exim4,

# update-exim4.conf
# /etc/init.d/exim4 restart

La condición es igual a "yes" después del primer fallo. Aparentemente la demora impuesta por la condición (2 minutos) es muy costosa para el emisor del mensaje fallido. Tanto así, que los ataques cesan rápidamente.

Instalando Debian en un SUN UltraSparc 10

Heredé un SUN UltraSparc 10 de 64 bits. Naturalmente mi primer instinto fue instalarle Debian.

El cargador de arranque se llama OpenBoot, al cual se accede oprimiendo Stop+A. El prompt es ok. Para arrancar el CD-ROM con el CD de instalación de Debian simplemente corre,

ok boot cdrom

El primer obstáculo que encontré es que la máquina tiene dos tarjetas gráficas, una integrada a la placa madre y otra PCI. El instalador de Debian parte en VGA, pero luego cambia a frame buffers. Al hacer el cambio, también cambia de tarjeta gráfica, por lo que la instalación se detiene y la pantalla muestra,

console handover: boot [earlyprom0] -> real [tty0]

Existen varias maneras de sobrepasar este obstáculo, incluyendo el remover la tarjeta PCI, pero la mejor opción es deshabilitar la tarjeta gráfica integrada. En OpenBoot simplemente se da el comando,

ok setenv pcib-probe-list 1,3

(para volver a habilitarla: setenv pcib-probe-list 1,2,3)

Un nuevo obstáculo apareció. Al ser el CD-ROM SCSI, el instalador no lo monta como tal, sino que intenta montarlo como IDE, lo que naturalmente falla. La instalación no puede continuar sin medio de instalación.

Decidí explorar el arranque del instalador por red. Esto requiere tener un segundo computador, al que llamaremos remoto.

Instala en el computador remoto los paquetes rarpd y tftpd. Edita /etc/ethers (no existe) y agrega en una línea la dirección MAC y número IP del computador SUN,

xx:xx:xx:xx:xx:xx 192.168.2.2

Descarga la imagen,

$ wget http://ftp.cl.debian.org/debian/dists/stable/main/installer-sparc/current/images/netboot/boot.img

En el computador SUN, arranca por red,

ok boot net

En el computador remoto observa los registros de tftpd en /var/log/syslog. El arranque por red intenta recoger una imagen con un nombre único que identifica a la máquina,

tftpd: trying to get file: 80C1529D

Mueve la imagen con el nombre indicado a /srv/tftp/,

# mv boot.img /srv/tftp/80C1529D

Voilá!

Chile cuenta nuevamente con réplica oficial ftp.cl.debian.org

Chile cuenta nuevamente con réplica oficial ftp.cl.debian.org. Esta vez es el patrocinador de debian.netlinux.cl (Netlinux) quien se ha adjudicado el honor.

Si bien la otrora réplica oficial (debian.ciencias.uchile.cl) cumplió un rol importante en la distribución de Debian en Chile desde su fundación en 1999, el continuo estrangulamiento del acceso por parte del patrocinador decidió, al final, la perdida del gran honor que significa ser réplica oficial. Esta experiencia ojalá sirva de lección.

Esperamos que Netlinux patrocine ftp.cl.debian.org por muchos años venideros. Le deseamos la mejor de las suertes.

chkrootkit informa de una falsa infección en el puerto 1008

# chkrootkit
...
Checking `bindshell'... INFECTED (PORTS: 1008)
...

sucede porque rpc.statd utiliza el puerto 1008, lo que confunde a chkrootkit. Edita /etc/default/nfs-common y modifica el puerto a 1023,

STATDOPTS="--port 1023"

luego reinicia el servidor NFS,

# /etc/init.d/nfs-kernel-server restart

Corre chkrootkit y verás que el falso-positivo desaparece.

Debian decide adoptar un nuevo ciclo de desarrollo, basado en un intervalo temporal de dos años

Fuente: esDebian (http://www.esdebian.org/)

El Proyecto Debian ha decidido adoptar una nueva política de congelación para futuros lanzamientos, basada en un ciclo temporal de dos años. A partir de ahora las congelaciones se producirán en diciembre de cada año impar, lo que conlleva a que cada lanzamiento se producirá en la primera mitad de cada año par. A consecuancia de esto, la siguiente congelación de Debian se llevará a cabo en diciembre de 2009, y la nueva versión se espera para la primavera de 2010. El Proyecto eligió diciembre como fecha para la congelación porque se muestran satisfechos con los antecedentes de las versiones publicadas en primavera (Debian 4.0 y Debian 5.0).

El ciclo temporal de congelación de dos años, permitirá al Proyecto Debian combinar la previsibilidad de los lanzamientos basados en ciclos temporales con su ya bien establecida política de lanzamientos basados en funcionalidades y características. El nuevo ciclo de desarrollo proporcionará a los usuarios de Debian una mejor previsibilidad de lanzamientos, y también permitirá a los desarrolladores llevar a cabo mejores planificaciones a largo plazo. Un ciclo de lanzamento de dos años, dará más tiempo para los grandes cambios que se pudieran realizar, reduciendo así los posibles inconvenientes que se causaría a los usuarios. Tener un ciclo de congelación conocido, contribuirá además a reducir el periodo total de congelación.

Debido a que el último lanzamiento de Debian fue el 14 de febrero de 2009, habrá aproximadamente un periodo de un año hasta su nueva publicación: Debian GNU/Linux 6.0 (nombre en clave "squeeze"). Habrá pues una única excepción en la política de dos años para ajustarse al nuevo periodo de lanzamiento. Para falicitarle las cosas a las grandes organizaciones y otros usuarios que prefieren un periodo de actualización largo, el Proyecto Debian planea la posibilidad de poder saltarse la próxima versión (la 6.0 "squeeze") y preparar un método para poder actualizar directamente desde la versión 5.0 "lenny" a la versión 7.0 (aun sin nombre).

Aunque la próxima congelación no está ya muy lejana, el Proyecto Debian espera poder conseguir ciertos objetivos destacados hasta entonces. Los que se han considerado como más importantes son, soporte para multiarquitectura, que mejorará la instalación de paquetes de 32 bits en sistemas de 64 bits, y un proceso de arranque optimizado con mejor rendimiento y fiabilidad.

La nueva política de congelación ha sido propuesta y aceptada durante la Conferencia Anual del Proyecto Debian, DebConf, la cual está teniendo lugar en Cáceres (España). La idea ha sido bien recibida entre los miembros del proyecto asistentes.