Manifiesto “En defensa de los derechos fundamentales en internet”

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial – un organismo dependiente del ministerio de Cultura – , la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Primero necesitaremos descargar el script que te permite leer las estadísticas del kernel. Para ello ejecutamos en una consola:

# wget http://maatkit.googlecode.com/svn/trunk/util/iodump

A continuación tenemos que decirle al kernel que muestre los mensajes de Entrada/Salida para cada proceso ejecutando este comando:

# echo 1 > /proc/sys/vm/block_dump

A continuación con el script que nos hemos descargado en el paso 1, capturamos los mensajes sobre Entrada/Salida que esta emitiendo el kernel.

# while true; do sleep 1; dmesg -c; done | perl iodump

Este script debemos ejecutarlo durante tanto tiempo como queramos, y tras terminarlo con Ctrl+C, se nos mostraran las estadísticas de entrada salida para cada proceso en ejecución. En mi caso estos son los datos devueltos:

TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
pdflush                 31        643          0        643          0 sda4
kjournald2             769        277          0        277          0 sda4
firefox-bin           9490         17          1         16          0 sda4
gconfd-2              4063          4          0          4          0 sda4
firefox-bin           9505          1          1          0          0 sda4

Como podéis ver obtenemos el Pid del proceso, el número de operaciones de escritura y el número de operaciones de lectura para cada uno, así como el dispositivo sobre el que se ejecutan dichas operaciones.

Y así de sencillo, espero que esta operación os sea tan utíl como lo ha sido para mí en incotables ocasiones.

Actualización: En servidores en producción con una alta carga de entrada salida, tened mucho cuidado con el espacio en disco, ya que los mensajes se iran guardando en /tmp/ y si son demasiados puede dejaros sin espacio en unas horas.

En este “Ejercicio” intervienen 2 máquinas, un equipo personal o un servidor A, y un equipo remoto o servidor B contra el que queremos autentificarnos. Esto suele utilizarse tanto para acceder a un servidor desde tu equipo local, como para autentificar un servidor contra otro para una transferencia que use ssh, como por ejemplo un scp, o un rsync.

Lo primero que tenemos que hacer es crear el par de claves para el usuario que queremos autentificar, esto lo haremos en nuestro equipo personal, o en el servidor que lanza la autentificación.

# ssh-keygen -t dsa

Cuando nos pida contraseña no debemos ponerle ninguna, si no estaremos en las mismas.

Una vez completado el proceso, tendremos dos ficheros nuevos en nuestro directorio home, por ejemplo:

/home/ajerez/.ssh/id_dsa.pub

/home/ajerez/.ssh/id_dsa

id_dsa.pub es la clave pública, la cual se copiara en el servidor remoto al que queremos acceder, y se contrastara contra la privada del equipo origen en cada conexión.

Ahora vamos a poner la clave pública en su sitio, dentro del servidor remoto.

Supongamos que nuestro usuario del equipo local es “ajerez”, y el usuario del equipo remoto contra el que queremos acceder es “remoteuser”, pues bién, debemos crear en el servidor (si no existe ya), el fichero /home/remoteuser/.ssh/authorized_keys, y dentro del fichero authorized_keys, meter el contenido del fichero id_dsa.pub para el usuario “ajerez” de nuestra máquina local o servidor A.

Si queremos hacerlo todo del tirón,  y tenemos habilitado el acceso ssh en la máquina local, podemos ejecutar el siguiente comando en el servidor remoto:

ssh maquinalocal -l ajerez “cat /home/ajerez/.ssh/id_dsa.pub” » /home/remoteuser/.ssh/authorized_keys

Una vez echo esto, desde nuestro equipo local podremos ejecutar:

localhost# ssh remoteuser@maquinaremota

y deberíamos acceder del tirón al equipo remoto, sin pedirnos contraseña ni nada.

Y esto es todo, esta es una práctica bastantes extendida, sencilla y que nos ahorrara mucho tiempo, pero tampoco debemos abusar de ella, sobre todo en entornos de red, ya que si tuviéramos una máquina con acceso ssh sin contraseña a todas los equipos de nuestra red, puede convertirse en un objetivo muy jugoso para usuarios malintencionados. Y recordad, tened siempre controlado el fichero id_dsa, ya que cualquiera con ese fichero, podrá acceder a vuestro server sin necesidad de usar contraseña.

Nota: Para usuarios de windows no se como esta la cosa, así que os recomendaría crear las claves con un equipo linux y luego instalarlas en nuestro cliente ssh de windows.

]]> http://www.syslogblog.es/2009/08/ssh-sin-contrasena/feed/ 0 http://www.syslogblog.es/2009/08/redireccionamiento-de-puertos-privados-tunel-ssh/ http://www.syslogblog.es/2009/08/redireccionamiento-de-puertos-privados-tunel-ssh/#comments Sat, 22 Aug 2009 12:00:19 +0000 ajerez http://www.syslogblog.es/?p=29 Este post, a diferencia del anterior, va a ser bastante corto, y así va a ser porque lo que os voy a relatar ahora es una operación bastante sencilla. A pesar de ello yo tarde un tiempo en empezar a utilizarla asiduamente en mi día a día como Administrador de sistemas.

Bueno vayamos al grano, lo que vamos a ver hoy es como crear un túnel desde nuestro servidor o servidores, que nos permita acceder a servicios que de otra manera serian inaccesibles.

Por ejemplo, supongamos que tenemos una red con N servidores, y solo uno de ellos, tiene acceso shell público habilitado, y es el que usamos como punto de entrada para todos los servidores. Ahora, supongamos que en al menos una de las N-1  máquinas que nos quedan, tenemos instalado un servidor de bases de datos mysql, este servidor de base de datos mysql será visible para todas las máquinas dentro de la subred, en el datacenter, pero no lo será desde nuestra oficina o casa por ejemplo, al menos de manera directa.

Con este escenario en mente, supongamos que queremos acceder con una aplicación como mysql workbench al servidor de base de datos que tenemos en la máquina “inaccesible”, en principio seria imposible si no abriéramos el puerto 3306 (o el que este usando mysql), a todo internet, ni que decir tiene que esto no es muy buena idea.

Gracias al tuneling por ssh podemos solventar este problema abriendo una conexión por shell con nuestro servidor, que haga corresponder un puerto de tu máquina local, con el puerto del servicio en cuestión, es decir

ssh -fNg -L 10000:localhost:3306 usuario@ipremota

Con esta instrucción redireccionaremos el puerto 3306 de la maquina remota, al puerto 10000 de nuestra máquina local.

Ahora bien, en el escenario que yo he planteado, el servicio mysql esta en otra máquina que no es la que tiene acceso shell, por lo tanto, en la que si tenemos acceso, debemos ejecutar otro tunel, que redirija el puerto de mysql del server en cuestion, a alguno de la máquina con acceso, y luego este puerto resultante, direccionarlo a tu máquina local. Parece un poco lío, pero no es más que concatenar redireccionamientos de puertos de una máquina a otra.
Ejemplo.

1. ssh -fNg -L 3307:server1:3306 usuario@ip-privada-server2-mysql. Con esto estariamos sirviendo en el puerto 3307 de la máquina con acceso shell público, el mysql de la máuina privada.

2. ssh -fNg -L 10000:localhost:3307 usuario@ipremota. Con este otro comando, redireccionamos a nuestra máquina local el puerto 3307 del server, que a su vez es un tunel del 3306 de la máquina privada.

Espero que os sirva de ayuda este post, y que no os hayáis perdido en el N-1

Esto, como lado bueno, te permitirá ahorrar tiempo en la administración del servicio, y pondrá a tu disposición uno de los filtros anti-SPAM más potentes del momento, pero por supuesto, también tiene un lado oscuro, como por ejemplo que los correos de tu “empresa” serán “procesados” para ofrecer publicidad a medida, además para el envío de correo desde el servidor (mediante la función mail por ejemplo), si que vendría mejor tener un servidor de correo ligero instalado en la máquina, en los sistemas linux, con sendmail o el exim por defecto nos vale.

Pues bien, para configurar gmail para nuestro dominio, necesitamos varias cosas: un dominio de nuestra propiedad con acceso a la configuración DNS, y una cuenta de google apps standard. Opcionalmente necesitaremos acceso físico al hosting del dominio, ya sea por ftp, ssh, smb…

1º paso Crear cuenta de google apps

Pues vamos manos a la obra, la herramienta de google que nos permite usar gmail para nuestro dominio se encuentra en el siguiente enlace:

http://www.google.com/apps/intl/es/group/index.html

Pinchamos en introducción, y si no tenemos una cuenta gmail, a estas alturas ya estará el sistema ofreciéndote una.

Una vez dentro del formulario, seleccionamos “Soy administrador de este dominio” e introducimos el dominio que queremos configurar con Gmail, en este caso tudominio.com

Utilizar un dominio existente para gmail

En los siguientes pasos introducimos nuestros datos personales, y por último se nos pide el nombre de una cuenta de correo @tudominio.com, esta cuenta es muy importante ya que es a través de ella, con la que modificaremos y añadiremos nuevas cuentas de correo.

Aceptamos las condiciones legales una vez más, y ya estamos dentro del panel de configuración de google apps para tu dominio.

Panel de control de google apps - syslogblog.es

2º Verificar la propiedad del dominio.

Lo primero que nos sale es que necesitamos verificar que somos propietarios del dominio, para ello podemos proceder de dos maneras:

Una subiendo un fichero por ftp (o crearlo por acceso shell) al raiz del dominio

Y otra manera es crear una entrada CNAME para nuestro dominio.

En ambos casos, las instrucciones que ofrece el panel son bastante claras. Por ejemplo, en el caso de que elijamos el método por ftp, esto es lo que nos indica.

1.- Crea un archivo de verificación HTML llamado googlehostedservice.html , copia el texto que se especifica a continuación y súbelo a http://tudominio.com/ .

2.- googleffffffffxxx7×7xx

En cuanto hayas realizado los cambios, asegúrate de que ves el archivo en http://tudominio.com/googlehostedservice.html.

Por el método del CNAME, también debemos seguir sin mayor problema las instrucciones en pantalla, lo que pretendemos es tener un subdominio del tipo: googleffffffffxxx7×7xx.tudominio.com que apunte a google.com.

48 horas maximo para comprobar la propiedad del dominio

El metodo por ftp suele ser más rapido que le de CNAME ya que no tiene que esperar a propagaciones DNS ni nada, en cualquier caso, pasadas 48 horas máximo, google ya sabrá que somos administradores o propietarios del dominio.

3º Añadir entradas MX al dominio.

Ahora entramos en el meollo de la cuestión, vamos a añadir varias entradas MX para el dominio. Las entradas MX le dicen a los servidores SMTP que red esta configurada como servidor de correo para el dominio en cuestión. Veámoslo con un ejemplo.

1. Cuenta@hotmail.com quiere enviar un correo a cuenta@tudominio.com
2. Cuando el servidor de correo hotmail.com va a realizar el envio, hace una consulta DNS contra tudominio.com, buscando su registro MX
3. El SMTP de hotmail.com recibe la entrada mx para tudominio.com, pongamos, mail.tudominio.com, y a partir de este momento inicia el protocolo de envio SMTP contra mail.tudominio.com.

Todo esto muy por encima, pero para que sepamos por donde nos estamos moviendo.

Pues bien, para que el uso de gmail en nuestro dominio vaya como se espera, es necesario indicarle a todo el mundo, que gmail esta controlando nuestro correo, o lo que es lo mismo, añadirle entradas MX al dominio.

Una vez más las instrucciones del panel de google apps, son magnificas, nos vamos a la pestaña de Configuración del servicio, y entramos en Correo electrónico. Una vez aquí le damos a activación del correo, y dentro de este menú, buscamos añadir entradas MX.

A continuación voy a pegar aquí las entradas MX que a mi me ha sugerido, pero recomiendo que las consultéis en el panel  de google apps, ya que según la situación geográfica del dominio, puede que os indique otras diferentes.

Dirección del servidor MX    Prioridad

ASPMX.L.GOOGLE.COM.                 10

ALT1.ASPMX.L.GOOGLE.COM.    20

ALT2.ASPMX.L.GOOGLE.COM.    20

ASPMX2.GOOGLEMAIL.COM.    30

ASPMX3.GOOGLEMAIL.COM.    30

ASPMX4.GOOGLEMAIL.COM.    30

ASPMX5.GOOGLEMAIL.COM.    30

En el panel recomiendan poner el TTL(time-to-live) de las entradas MX a lo máximo permitido, y justo debajo de las entradas MX sugiere crear un registro SPF para combatir el SPAM, pero este tema ya lo trataremos en otro post de este blog.

Y esto es todo, una vez que se verifica la propiedad del dominio por parte de google ya podréis añadir cuentas desde el panel de google apps, y gestionar vuestras cuentas de correo desde: http://mail.google.com/a/tudominio.com

Soló por citar algunos de los temas a tratar:

• Configuración y optimización del sistema operativo.
• Instalación, configuración, mantenimiento y optimización de distintas aplicaciones como: servidores de correo smtp, pop3, imap, servidores de bases de datos sql, servidores DNS, vpn, servidor nfs, sistemas de cacheo, CVS…
• Monitorización y bechmarking de sistemas hardware y software, aplicando el resultado a la identificación de cuellos de botella en nuestra red.
• Como conseguir alta disponibilidad, alto rendimiento y alta capacidad de proceso a la medida de nuestras posibilidades.
• Recolección y análisis de logs.

Por último, siempre he querido pegar una definición de wikipedia en un artículo, así que allá voy:

Definición de Administrador de Sistemas según wikipedia.
“Un Administrador de sistemas, o sysadmin, es aquella persona que se dedica a mantener y operar un sistema de cómputo o una red.“

Por lo tanto, si se dedican a mantener y operar sistemas de cómputo, pasen, vean, y siéntanse libres de comentar, rebatir y criticar (siempre constructivamente) todo lo que consideren necesario.

Un saludo.
@ajerezguillen