Las entidades certificadoras actuales cobrán por el servicio de firma de llaves y no suele ser precisamente asequible. Por otro lado, montar una entidad certificadora oficial también resulta muy costoso ya que se demandan unas ciertas garantias que destrás del negocio hay una cierta seguridad. Por tanto, es habitual que los administradores de pequeñas redes se creen su propios certificados para firmar sus claves. De esta forma podremos disponer de comunicaciones encriptadas sin necesidad de entidades certificadoras.

Estas entidades oficiales pagan para que aparezcan por defecto sus certificados en navegadores como Mozilla Firefox o Internet Explorer. De esta forma el propio navegador puede comprobar automáticamente que cuando se conecta a un sitio seguro, el certificado que recibe ha sido realmente firmado por una entidad oficial. Eso implica que nuestros certificados no serán reconocidos automáticamente por los navegadores a no ser que los añadamos manualmente, el único inconveniente que aporta esto es que el navegador mostrará un aviso extra al usuario (dependiendo de la configuración) advirtiendo que no reconoce la entidad certificadora.

Vamos a ver como configurar OpenSSL para montar nuestro servicio de certificación personal. Lo primero es tener OpenSSL instalado en el sistema (aptitude install openssl), la configuración la encontraremos en “/etc/ssl” y será allí donde editemos el fichero “openssl.cnf”. Os pongo un extracto del archivo con lo más importante:

...

[ ca ]
default_ca  = CA_default

[ CA_default ]
dir     = /etc/ssl/marblestationCA  # Where everything is kept
certs       = $dir/certs  # Where the issued certs are kept
crl_dir     = $dir/crl  # Where the issued crl are kept
database    = $dir/index.txt  # database index file.
new_certs_dir   = $dir/newcerts     # default place for new certs

certificate = $dir/MSca.crt     # The CA certificate
serial      = $dir/serial       # The current serial number
crl     = $dir/crl.pem      # The current CR

private_key = $dir/private/MSca.key # The private key

default_days    = 3650

...

En esta sección del fichero se define donde se va a almacenar toda la información, en mi caso lo guardaré todo en “/etc/ssl/marblestationCA”. Dentro de ese directorio creare toda una serie de subdirectorios que guardaran la información necesaria e imprescindible como por ejemplo el certificado o clave de la entidad (tanto privada como pública). También he puesto que por defecto se generen claves con un periodo de caducidad de 10 años ya que quiero olvidarme de renovar por una buena temporada.

Tendremos que crear la estructura de directorios y ficheros:

mkdir /etc/ssl/marblestationCA/
mkdir /etc/ssl/marblestationCA/certs
mkdir /etc/ssl/marblestationCA/private
mkdir /etc/ssl/marblestationCA/newcerts
mkdir /etc/ssl/marblestationCA/crl
echo "01" > /etc/ssl/marblestationCA/serial
touch /etc/ssl/marblestationCA/index.txt

A continuación crearemos la clave pública/privada de nuestra entidad certificadora:

cd /etc/ssl/marblestationCA/
openssl req -nodes -new -x509 -keyout private/MSca.key -out MSca.crt -days 3650

Es importante especificar el mismo nombre para la clave privada (MSca.key) y pública (MSca.crt) que pusimos en nuestra configuración de OpenSSL. En cuanto a las preguntas que nos haga para generar la clave:

Country Name (2 letter code) [ES]:
State or Province Name (full name) [Catalunya]:
Locality Name (eg, city) []:Tarragona
Organization Name (eg, company) [Marble Station]:
Organizational Unit Name (eg, section) []:Ejemplo
Common Name (eg, YOUR name) []:midominio.com
Email Address []:admin@midominio.com

Cabe destacar que en “Common Name” debemos poner el nombre de dominio correspondiente a la máquina donde estará la entidad certificadora.

Ahora ya tenemos nuestro servicio de certificaciones montado, las claves que hemos generado nos serviran para firmar terceras claves que serán utilizadas por ejemplo por los diferentes ordenadores de nuestra red.

Imaginemos que en el mismo servidor donde hemos montado nuestros certificados para firmar, tenemos un servidor web Apache seguro (SSL) y necesitamos un certificado firmado por nuestra entidad personal. Lo primero que tendremos que hacer será crear una petición de certificado junto a una clave privada:

openssl req -nodes -new -keyout midominio.key -out midominio.csr

Nos volverá a realizar las respectivas preguntas, debemos responder acorde para la máquina donde se va a utilizar la clave. En “midominio.key” tendremos la clave privada generada y en “midominio.csr” la petición de certificado. La entidad certificadora solo necesita acceso al segundo, vamos a generar ahora el certificado firmado por nuestra entidad personal:

openssl ca -out midominio.crt -in midominio.csr

Esto generará el archivo “midominio.crt” con el certificado firmado listo para ser usado por el solicitante. Además se guardará información referente al certificado firmado en “/etc/ssl/marblestationCA/” de forma que siempre tendremos un listado de todo lo que hemos firmado, también podremos revocar firmas (man openssl) en caso de que sea necesario.

Como comenté, ibamos a utilizarlo para nuestro servidor Apache pero también podria ser compartido por otros servicios en la misma máquina, como por ejemplo un servicio de POP3/IMAP (recomiendo dovecot) y SMTP (recomiendo exim). Es importante asegurarnos que estas aplicaciones tengan acceso de lectura al certificado y que el resto de usuarios del sistema no puedan leerlo (sobretodo la llave privada .key).

Habitualmente suelo ubicar los certificados de servicios en /etc/ssl/certs y /etc/ssl/private de la máquina que los vaya a usar:

mv midominio.crt /etc/ssl/certs
mv midominio.key /etc/ssl/private

La petición de certificado midominio.csr no lo vamos a necesitar más puesto que ya hemos generado el certificado.

Ahora podriamos seguir generando nuevos certificados para después firmarlos y repartirlos entre las máquinas de nuestra red que dispongan de servicios con conexión segura.

En resumen, hemos llevado a cabo dos acciones:

1. Generación de los certificados de nuestra entidad certificadora no oficial (clave pública “MSca.crt” y clave privada “MSca.key”), se guardará toda la información en “/etc/ssl/marblestationCA/”
2. Generación de certificados firmados para los servicios o máquinas de nuestra red, se guardará automáticamente la información necesaria en “/etc/ssl/marblestationCA/” y la clave pública/certificado firmado se guardarán en la máquina que los vaya a usar (“/etc/ssl/certs”, “/etc/ssl/private” respectivamente):
   1. Generación de una clave privada (midominio.key) con peticion de certificado (midominio.csr).
   2. Firma de la petición con nuestro certificado de entidad.
   3. El solicitante recibirá su certificado firmado (midominio.crt) que usará en conjunto con su clave privada para su servicio (podremos eliminar la petición midominio.csr).

Autor: marble

Podriamos definir SILC como un híbrido entre IRC y la mensajería instantanea ya que hereda funcionalidades de ambas ramas, sin embargo ha sido diseñado desde el inicio pensando en la seguridad. SILC proporciona seguridad a unos niveles superiores a la seguridad que puede ofrecer la combinación de cualquier protocolo no seguro (e.g. IRC, Jabber, MSN Messenger…) junto con tecnologías como TLS/SSL y GnuPG/PGP. El principal motivo que dan en su web es que es muy difícil hacer seguro un protocolo inseguro utilizando un añadido (e.g. SSL) por encima, sin embargo se puede conseguir una seguridad superior si diseñamos desde 0 un protocolo con esas características. Por ejemplo, SSL es ideal para comunicaciones entre 2 máquinas, pero cuando han de intervenir más nodos como por ejemplo ocurriria en un canal (como los del IRC) su funcionamiento no es tan bueno (por ejemplo nadie te asegura que todas las personas han conectado con SSL al servidor).

En todo caso no me puedo considerar un experto en el funcionamiento de SILC y por tanto donde mejor os podeis informar sobre el funcionamiento interno de los protocolos de seguridad es en su web, tienen bastante documentación y FAQs útiles.

La red principal en la que se puede utilizar clientes SILC es silcnet, también es posible montar nuestros propios servidores para uso privado (e.g. Empresas). Como clientes disponemos de uno de consola basado en irssi (“emerge silc-client” en Gentoo), uno gráfico llamado Silky (emerge silky) y el mismisimo cliente de mensajería instantanea multi-protocolo Gaim. En el momento de escribir este artículo utilizo la versión 0.81 de Gaim.

He testeado los 3, el de consola va muy bien cuando no disponemos de entorno gráfico, pero si no es ese nuestro caso el que más me ha gustado ha sido el propio Gaim. Para hacer que Gaim tenga soporte SILC en Gentoo solo teneis que activar la variable USE “silc” (podeis utilizar el programa “ufed” para ello) y recompilar Gaim.

Para poder entrar en la red silcnet tendremos que crear una nueva cuenta en Gaim de tipo SILC, introducimos nuestro nick… con SILC los nicks no tienen porque ser únicos, pueden haber varias personas conectadas con el mismo nick, las diferenciaremos haciendoles un /whois (o mediante menus de Gaim) lo que mostrará información extra como su clave pública. Establecemos una contraseña, esto no me ha quedado muy claro pero creo que esta se utiliza para proteger la clave privada que se generará automáticamente cuando creemos la cuenta.

Si damos a “Mas opciones” vemos que por defecto se conecta a la red silcnet (silc.silcnet.org), SILC utiliza el puerto 706 ya que este es un puerto privilegiado y solo lo puede abrir root. Esto da una cierta garantia a la hora de acceder a otros servidores, sabes que el que lo ha creado es el administrador del sistema y no cualquier usuario malicioso. Por supuesto una vez se inicia el servidor SILC sus permisos se bajan a nivel de un usuario normal. En la web de SILC recomiendan no confiar nunca en servidores SILC que utilicen un puerto no privilegiado (superior a 1024).

Tenemos diferentes opciones más, la primera de ellas (Autentificación de clave pública) no he conseguido averiguar para que sirve.

La segunda opción, “Impedir que otros usuarios miren” sirve para evitar que otros usuarios nos introduzcan en su lista WATCH. Como he dicho antes, SILC tiene características de IM… por ejemplo es posible añadir un usuario a nuestra lista WATCH, que seria el equivalente a una lista de contactos. Si no queremos que nadie pueda ver que hemos entrado en silcnet hay que marcar esta opción, no es posible “bloquear” a personas individuales de la red tal y como sucede en Jabber o MSN Messenger, o se bloquea a todos o a nadie.

La tercera opción, “Bloquear invitaciones” se utiliza para evitar que terceros puedan invitarnos a canales.

La cuarta opción, “Bloquear MIs que no hagan intercambio de claves” esta relacionado con la forma de tener conversaciones privadas (entre 2 personas) en SILC.

• Es posible realizar una comunicación normal entre 2 personas de forma que el texto viaja encriptado pero el servidor conoce las claves (llamadas claves de sesión), si el servidor fuese comprometido y el servicio SILC fuese reemplazado por otro malicioso, nuestra conversación podria ser vista por los atacantes (es una situación extrema, poco probable pero posible).
• Como alternativa al punto anterior se pueden realizar conversaciones entre 2 personas que utilicen sus claves privadas, es decir, cada usuario encripta con su clave privada que solo él conoce y no con la clave de sesión que es conocida también por el servidor.

  Para que esto sea posible estos 2 usuarios deben realizar el intercambio de sus claves públicas, si este intercambio se realizase utilizando como intermediario el servidor, este (en caso de estar comprometido) podria efectuar el ataque man-in-the-middle y por tanto la seguridad de la comunicación queda de la mano de los usuarios que deben comprobar el finger-print de las llaves públicas antes de confiar. Para evitar esta situación, el intercambio de claves se realiza de forma directa entre las 2 personas que quieren realizar la comunicación. Esto implica que si ambas (si solo es 1 de los 2 o ninguno no pasa nada) se encuentran en redes locales distintas y utilizan NAT para acceder a internet, no van a poder realizar el intercambio de claves públicas a no ser que redirijan el puerto necesario.

  Personalmente encuentro que el tener que establecer una conexión directa esto es una pega importante, de todas formas siempre es posible utilizar Gaim-Encryption que funciona sobre cualquier protocolo y realiza el intercambio de claves sin tener que establecer una conexión directa, por supuesto usa sus propias claves públicas/privada independientes de las de SILC y es necesario que ambas personas tengan el plugin para gaim.

La cuestión es que, la cuarta opción del Gaim de la que hablabamos… “Bloquear MIs que no hagan un intercambio de claves” impide que podamos hacer conversaciones privadas tal y como explico en el primer punto.

Finalmente tenemos la opción “Rechazar solicitudes de los atributos del estado en línea”, cada usuario tiene un conjunto de información extensible por ejemplo que indiquen su estado actual (ausente, ocupado…). Es posible ocultar esta información para mostrar solo lo estrictamente necesario. Con todo y eso, en silcnet se mostrará el dominio o IP desde la que nos conectamos y por tanto, aunque se consigue seguridad, no somos anónimos para el resto de usuarios. Por lo que he leido en su web, es posible configurar el servidor para que no se muestren las IPs pero en el caso de silcnet no es asi

Una vez conectados podemos listar los canales disponibles en la red, vamos a Herramientas -> Lista de salas, seleccionamos nuestra cuenta SILC y pulsamos “obtener la lista”. Podemos unirnos a cualquiera o incluso añadirla a nuestra lista de contactos para facilitar el acceso futuro, Amigos -> Añadir un chat, seleccionamos nuestra cuenta SILC y rellenamos los datos. Si indicamos un canal que no existe, este sera creado al entrar en el y seremos los fundadores del mismo. Si queremos que el canal sea persistente deberemos establecer el modo +f (fundado) al canal con el comando /cmode canal +f, seria algo similar a registrar un canal (por ejemplo yo he creado el canal gpltarragona). Es importante no perder nuestra clave publica/privada ya que es con esta con la que el servidor nos identificará como fundadores de los canales que tengamos. El canal silc es el principal de la red, allí podemos realizar consultas. Cabe destacar que aquí los canales no tienen que empezar con # como en el IRC, por tanto gpltarragona es diferente a #gpltarragona.

Cuando estamos dentro de un canal que tenemos en la lista de contactos también y somos operadores, si hacemos click con el botón derecho sobre dicho canal en la lista de contactos, se mostrará una pequeña lista de opciones que nos ayudará a manejarlo… por ejemplo para establecer passwords, hacerlo privado (solo se puede entrar por invitación), secreto (no se muestra en el listado de canales), etc… También es posible crear un grupo privado asociado al canal y con un password, a este grupo se pueden unir cualquiera pero solo podrá leer/escribir mensajes si sabe el password. De esta forma pueden haber diversos sub-grupos dentro de un mismo canal y solo los de un grupo pueden ver el texto de ese grupo ya que solo ellos saben el password.

En un canal normal es posible que un servidor comprometido pueda realizar el ataque man-in-the-middle al igual que ocurria en las conversaciones privadas, por eso es posible poner el canal en modo clave privada (+k) donde todos los usuarios podran establecer una clave privada que no conocerá el servidor, de esta forma se evita el posible ataque nombrado. No he conseguido hacer esto con Gaim (le faltan comandos como el /key), pero con el cliente de consola seguro que se puede. Cabe remarcar que SILC no implementa ningun sistema para el intercambio de claves en grupo, solo entre 2 personas, asi que en el caso de los grupos privados queda de la mano de los usuarios el método para pasarse la clave privada.

Aseguraros de tener activado la posibilidad de poner comandos mediante /, Herramientas -> Preferencias -> Interfaz -> Conversaciones, marcar “Activar órdenes barra”. De esta forma podremos ejecutar comandos desde el mismo canal, poned /help para ver un listado de los mismos (el comando /help del cliente de consola es mucho mas completo, os lo recomiendo cuando tengais dudas puntuales). Por ejemplo, si poneis un password al canal utilizando las opciones de Gaim vereis que despues no hay forma de quitar dicho password. Si vemos los modos del canal ejectuando “/cmode canal” saldra [passphrase auth], para quitarlo debemos poner “/cmode canal -a”.

En Gaim también podremos enviar archivos usando SILC, esto implica que el fichero se enviará utilizando SFTP, es decir, la transmisión será encriptada. Esta característica no es posible conseguirla con ningun otro protocolo/plugin, por tanto se perfila como una de las funcionalidades más llamativas.

Finalmente quisiera destacar la posibilidad de utilizar SILC para la transmisión de información multimedia gracias al soporte de MIME. Es posible que en el futuro veamos clientes que implementen la posibilidad de realizar conexiónes seguras de voz o imágen utilizando SILC.

Respecto al cliente SILC de Gaim su funcionamiento es bastante correcto, salvo algun fallo temporal y la falta de opciones/comandos. Lo que maś fastidia es que no consigo hacer funcionar correctamente la posibilidad de añadir gente a la lista de contactos procedentes de SILC, cuando reinicio la aplicación falla pidiendome la clave pública de los usuarios que añadi… cuando esto deberia haberlo hecho el automáticamente. De todas formas es muy usable (sobretodo al estilo IRC con los canales) teniendo en cuenta que no hace mucho que ha sido incorporado a Gaim.
Autor: marble

Hoy en dia la seguridad es imprescindible, sobretodo si tenemos una
conexión 24/7. Usar un cortafuegos es una de las primeras
medidas que deberíamos tomar con tal de hacer un poco más
segura nuestra maquina/red.

En este pequeño artículo veremos como se ponen en marcha
las Iptables a fin de cerrar i abrir los puertos según nuestras
necesidades.

Por suerte para nosotros, y a diferencia de algunos sistemas operativos
propietarios (o privativos como dirían algunos), casi todos (al
menos los principales) sistemas operativos href="http://www.gnu.org/philosophy/free-sw.es.html">libres
incorporan de serie algún mecanismo de cortafuegos. Nosotros nos
limitaremos a explicar las Iptables, que es el mecanismo “oficial”
desde la rama 2.4 del kernel de gnu/linux.

La instalación por la parte que respecta al kernel no la
comentaremos en detalle, puesto que todas las distribuciones actuales
las llevan activadas de serie en el nuclio (y si hay alguien que gusta
de compilar sus propios nuclios, seguramente ya sabrá las
opciones a activar. A modo de pista diré: Networking
Options–>IP:
Netfilter Configuration). Por la parte de usuario hay que instalar el
paquete “iptables” (apt-get, emerge, …). Nada más.

Hay gente a la que le gusta hacer servir scripts i aplicaciones
extrañas y esotéricas para configurar Iptables. Nosotros
lo haremos a mano, así de paso veremos como funciona y podremos
comprobar que no es para nada difícil.

Antes de meternos de lleno, daré un enlace sobre los
conocimientos mínimos que hay que tener de Iptables: que es,
lógica de funcionamiento y una base.

href="http://www.netfilter.org/documentation/HOWTO/es/packet-filtering-HOWTO.html">HOWTO
de filtrado de paquetes

Bien, como queremos que las Iptables se pongan en marcha ellas solas al
encender el sistema y que podamos parar y volver a poner en marcha
rapida y sencillamente, usaremos los scripts de init.d. Normalmente
estos se instalan solos al instalar el paquete “iptables” (el script
debería estar en /etc/init.d/iptables, o dondequiera que
tengáis el directorio init.d en vuestra distribución). En
caso de no existir dicho script, podéis encontrar uno de ejemplo
aquí.

Ahora hay que asegurarse de que el script se lanzará al encender
el sistema de la siguiente forma (si es que no lo había hecho
vuestro instalador de paquetes al instalar el paquete “iptables”):

En Debian sería un cosa así:update-rc.d iptables defaults

Mientras que en Gentoo sería:rc-update add iptables default

Si no tenéis ninguna de estas dos utilidades, simepre lo podéis hacer a mano de la forma tradicional:

  1) mirar que runlevel es el que ejecutamos con el siguiente comando:    runlevel

  2) ir al directorio del runlevel en cuestión:    cd /etc/rcX.d    o en algunas distribuciones:    cd /etc/init.d/rcX.d    substituyendo la  "X" de "rcX.d" por el número de runlevel que nos ha dado el comando del punto 1

  3) crear el enlace sombólico apropiado:    ln -s /etc/init.d/iptables S20iptables

Una vez instalado, configurado y listo para usar, nos aseguraremos que
no hay ninguna regla de Iptables cargada:

iptables -F

Y procederemos a añadir nuestras reglas (aquí pongo un
ejemplo básico):

iptables -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPTiptables -A INPUT -i eth0 -p TCP --dport 22 -m state --state NEW -j ACCEPTiptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -A INPUT -p icmp -j ACCEPTiptables -A INPUT -j DROP

La primera línea sirve para que se permitan las conexiones de la máquina consigo misma mediante la interfaz de red de loopback.La segunda línea, indica que queremos abrir el puerto 22. Esto es a modo de ejemplo. Deberíamos substituir el "22" por el número del puerto que queramos abrir. Repetir esta línea con todos los puertos que se desee abrir. Hay que tener en cuenta, que es posible indicar rangos de puertos en el siguiente formato: inicio-fin. Por ejemplo, si indicaramos 22-80 en el número de puerto, estaríamos diciendo que queremos abrir todos los puertos entre el 22 y el 80, ambos incluídos. Hay que cambiar eth0 por el dispositivo adecuado

La tercera línea permite que las conexiones que establezcamos hacia el exterior puedan entrar. Hay que cambiar eth0 por eldispositivo adecuado. Sin esta línea no nos volvería ningún paquete (no lo dejaríamos entrar).

La cuarta línea permite que entren los paquetes ICMP (principalmente pings).

La última línea impide que entre cualquier otra cosa.

Si tenéis reglas propias (prerouting, postrouting, …) metedlas
donde convenga en el orden adecuado, teniendo presente que primero
permitimos y con la última línea impedimos el resto de
conexiones. Al hacerlo de esta manera nos aseguramos de no dejarnos
nada abierto; lo que no hayamos permitido explicitamente no
podrá entrar.

Finalmente, para conseguir que estas reglas se activen automaticamente
al encender el sistema, haremos lo siguiente:

Primero nos aseguraremos de tener el directorio de destino /var/lib/iptables, y si hiciera falta lo crearíamos:
mkdir /var/lib/iptables

Y a continuación hacemos un:
/etc/init.d/iptables save active

Y para cuando queramos pararlas hay dos opciones a saber:

a) Que al parar las Iptables via “/etc/init.d/iptables stop” dejemos el
cortafuegos sin ninguna regla (todo abierto):

iptables -F/etc/init.d/iptables save inactive

b) O que dejemos solo la regla que impide todas las conexiones
entrantes (todo cerrado):

iptables -Fiptables -A INPUT -j DROP/etc/init.d/iptables save inactive

Una vez hecho esto, encontraremos en /var/lib/iptables dos
ficheros: “active” y “inactive”, que podremos modificar posteriormente
para modificar/quitar/añadir reglas a cualquiera de los dos
estados (active
cuando hacemos el start e inactive cuando hacemos el stop).

Para finalizar haremos un:

iptables -F/etc/init.d/iptables restart

Y ya las tendremos funcionando. Convendría asegurar-nos de su
funcionamiento con herramientas tales como el href="http://www.insecure.org/nmap/">nmap (si no las sabeis hacer
funcionar siempre podéis preguntar a vuestro man o a google.
Autor: sergi

A Debian seria un cosa així:
update-rc.d iptables defaults

Mentre que a Gentoo seria:
rc-update add iptables default

Si no teniu cap d'aquestes dos utilitats, sempre ho podeu fer a mà a la manera tradicional:
  1) mirar quin runlevel és el que executem amb la següent comanda:
    runlevel

  2) anar al directori del runlevel:
    cd /etc/rcX.d
    o a algunes altres distribucions:
    cd /etc/init.d/rcX.d
    substituint la  "X" de "rcX.d" el número de runlevel que ens ha dit la comanda del punt 1

  3) crear l'enllaç simbòlic adequat:
    ln -s /etc/init.d/iptables S20iptables

Un cop instalat, configurat i a punt, ens assegurarem que no hi ha cap regla d’iptables molestant:

iptables -F

I procedirem a afegir les nostres regles (aquí dono un exemple bàsic):

iptables -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 22 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -j DROP

La primera línia ens indica que volem que es puguin establir connexions amb un mateix, via l'interfície de loopback.

La línia de --dport 22, indica que el port 22 en aquest cas volem que estigui obert. Justament desprès de la primera línia haurem d'afegir tantes com vulguem amb la mateixa forma i canviant el 22 pel port que vulguem deixar obert. També es poden enumerar rangs amb el format inici-fi (exemple: el rang "22-80" serien tots els ports entre el 22 i el 80, ambdós inclosos).Cal canviar eth0 pel dispositiu adequat.

La tercera línia permet que les connexions que nosaltres establim cap a l'exterior tinguin permís per entrar. Cal canviar eth0 pel dispositiu adequat. Sense aquesta línia no ens retornaria cap paquet (no el deixaríem entrar).

La quarta línia permet que entrin els paquets ICMP (principalment pings).

La darrera línia impedeix que entri qualsevol altra cosa.

Si teniu regles pròpies (prerouting, postrouting, …), fiqueu-les on convingui en l’ordre adequat, tenint en compte que primer permetem unes quantes coses i amb la darrera línia impedim tota la resta. Així permetent explícitament ens estalviem maldecaps per haver-nos deixat quelcom obert.



Finalment, per tal d’aconseguir que aquestes regles s’activin automàticament a l’engegar el sistema, farem el següent:

Primer ens assegurarem que tenim el directori destí /var/lib/iptables, i si fes falta el crearíem:
mkdir /var/lib/iptables

I a continuació fem un:
/etc/init.d/iptables save active

I per a quan vulguem parar-les hi ha dues possibilitats a saver:

a) Que al parar les iptables via “/etc/init.d/iptables stop” deixem el tallafocs sense cap regla:

iptables -F
/etc/init.d/iptables save inactive

b) O que deixem només la regla que impedeix totes les connexions entrants:

iptables -F
iptables -A INPUT -j DROP
/etc/init.d/iptables save inactive

Un cop fet això, trobarem a /var/lib/iptables dos fitxers: “active” i “inactive”, que podrem modificar posteriorment per a modificar/treure/afegir regles a qualsevol dels dos estats (active quan fem un start i inactive al fer l’stop).



Per finalitzar fem un:

iptables -F
/etc/init.d/iptables start

I ja les tindrem funcionant.
Convindria assegurar-nos del seu funcionament amb eines tals com l’nmap (si no les sabeu fer anar, sempre us podeu passar pel servidor irc.freenode.org, canal #gplurv i demanar que us facin un escaneig).
Autor: sergi

Aquest software moltes vegades s’utilitza també per rescatar el /etc/shadow i un cop té el fitxer a un diskette, amb calma (i segurament a casa seva) aplicar un mecanisme de força bruta per coneixer la password de root o d’un altra usuari (John The Ripper). La técnica més habitual és executar-lo des de un diskette amb un arranc des de cd-live de Win32, o sigui que pareu compte amb la seguretat física, moltes vegades descuidada a canvi de la seguretat remota.

GNU/Linux

Autor: cdelphi96

Com diu el titular, en aquest article explicaré com configurar qualsevol carpeta perque estigui encriptada.


Requeriments:

• L’últim kernel estable

Baixeu-lo de kernel.org si no el teniu ja a /usr/src. En el moment d’escriure aquest article és el 2.4.22. No em liaré a explicar ara com configurar un kernel, hi han milers d’articles i HOWTOs que ho expliquen i no és el propòsit d’aquest document (buscant al google facilment en trobeu molts, com per exemple aquest).

• El cryptoapi

Baixeu-lo d’aqui. L’arxiu és el patch-int-2.4.21.0.gz (no us preocupeu si no trobeu la versió per el vostre kernel, funciona igual).

• El cryptoloop

De la mateixa pàgina, i l’ultima versió que he vist és la patch-cryptoloop-jari-2.4.22.0.

Comencem!

Bueno, tenim les fonts del kernel a /usr/src/linux i tenim els pegats a /usr/src. Ara entreu a /usr/src/linux i executeu:

# patch -p1 <../patch-int-2.4.20.0 (i us sortiran els arxius que canvia)
# patch -p1 <../patch-cryptoloop-jari-2.4.22.0 (aqui també)

Si tot ha anat bé, ja podeu fer un make menuconfig (o lo que sigui que feu per configurar el kernel) i veureu que teniu una nova entrada al kernel: “Cryptographic options”. Alli dintre teniu que seleccionar Cryptographic API i una xifra, per exemple Twofish. Torneu al menu principal i escolliu Block devices, i dintre “loopback device support” i us apareixerà “cryptoloop support”, que també heu de marcar. Depenent de si ho compileu al kernel o com a moduls heu d’afegir els moduls que voleu carregar a l’arrancar l’ordinador a l’arxiu corresponent. Jo ho tinc compilat al kernel.

Compileu el kernel i tota aquesta pesca i arranqueu i ja teniu soport per directoris encriptats!

Com preparar-ho:

Posem per exemple que voleu encriptar les vostres imatges secretes. Cada directori encriptat estarà guardat en un arxiu que guardarem on més ens convingui. Crearem l’arxiu d’aquesta manera:

$ dd if=/dev/urandom of=/home/edgar/arxiuencriptat bs=1M count=50

canviant els paràmetres que s’hagin de canviar, com per exemple la direcció de l’arxiu encriptat i el numero de megues que ocuparà el directori (bs ens indica el tamany de cada bloc (pot ser 1K, 1M, 1G…) count ens indica el numero de sectors. 500 sectors de 1M cada un, fan 500 megues). Aquesta és una cosa que heu de decidir ara, ja que un cop fet, no es pot canviar el tamany de l’arxiu i si alguna vegada arribeu a ocupar tot l’espai del directori, n’haureu de fer un altre de més gran i moure les dades alli. Fixeu-vos que dd agafa les dades de /dev/urandom, un generador de numeros aleatoris del kernel. Això només és per més paranoia encara (mireu el document que he fet servir per escriure aixo per entendre per què)

Un cop tenim l’arxiu creat (no desespereu, trigarà depenent del tamany de l’arxiu , heu de “montar” l’arxiu a un dispositiu especial del kernel, el loop, com si fos un dispositiu més del sistema (per exemple /dev/hda). I això ho fem amb el comand “losetup”:

$ losetup -e twofish /dev/loop0 /home/edgar/arxiuencriptat

Fixeu-vos que hem seleccionat la xifra que haviem compilat al kernel, twofish, però si havieu seleccionat alguna altre, només ho heu de canviar aqui.

Ens sortirà això:

Available keysizes (bits): 128 192 256
Keysize: 128
Password :

Seleccionarem el tamany de la clau introduïnt el numero corresponent. Seleccioneu el que volgueu depenent de la vostra paranoia… jeje. Un cop fet aixo, ens preguntarà per la contrasenya que voleu per poder accedir al disc. Per més seguretat, escolliu una frase bastant llarga, i numeros i lletres a l’atzar (però recordeu que poseu perque si no no hi podreu accedir…).

Ara el que hem de fer és donar format al dispositiu com si d’un disc dur es tractés. Podeu escollir el sistema d’arxius que més us agradi. Per exemple:

$ mkfs -t ext2 /dev/loop0

Ja tenim preparat el nou dispositiu per ser montat. Ho fem amb el mount de tota la vida. Escolliu el directori que voleu montar, com per exemple /home/edgar/imatges (el directori ha d’existir i estar buit) i executeu:

# mount -t ext2 /dev/loop0 /home/edgar/imatges

I ja esta! Copieu el que volgueu, però jo us recomano una cosa abans de fer-lo servir definitivament: comproveu que la contrasenya que heu escollit per el dispositiu funciona de veritat, perquè quan la creeu no hi ha confirmació. Per fer-ho, creeu un directori o un arxiu al directori encriptat, i després desmonteu el dispositiu:

# umount /home/edgar/imatges

i també desmonteu el dispositiu amb:

# losetup -d /dev/loop0

Després torneu a montar el dispositiu amb les comandes anteriors (pero sense la de $ mkfs -t ext2 /dev/loop0, evidentment) i comproveu que podeu accedir al directori o arxiu. Si podeu, enhorabona, teniu una mica més de seguretat en les vostres vides

Com fer-ho servir en el dia a dia:

Haver d’executar tants comandos per montar un directori és una mica rollo, perque heu de entrar com a root i executar totes les comandes des d’alli. Podeu agilitzar la cosa creant un petit script que ho executi tot, com a root, o també podeu afegir una linea a /etc/fstab com per exemple:

/home/edgar/arxiuencriptat /home/edgar/imatges ext2
loop=/dev/loop0,encryption=twofish,noauto,user 0 0

canviant les coses que siguin necessaries (per exemple, el sistema d’arxius o la xifra). Aixi que per poder accedir a les meves imatges, només he d’executar com a usuari normal:

$ mount /home/edgar/imatges

I em demanarà la contrasenya. La poso i tots contents

Espero que us hagueu divertit amb aquest article, i que us ajudi a ser més paranoics si cal en el dia a dia, si és possible! Ara només he posat com obtenir un directori encriptat, però és molt similar a obtenir una partició sencera encriptada. El rendiment general del sistema baixa si es fa aixi… però si algú ho fa, que ho expliqui per aqui!

P.D. Aquest article l’he de revisar perque ara mateix no puc comprovar que seguint pas a pas el que he posat funcioni, ja que ho he fet més o menys de memòria i mirant els documents que vaig fer servir. Però em sembla que ja està tot…

Ale, a passar-ho be!
Autor: mengor

Vols més informació sobre el tema de la signatura de claus i la quedada? Cap problema! Visita aquesta pàgina.

Hem de fer una consulta popular sobre el lloc, el dia i l’hora de la quedada. El tema es discutirà a través de la llista de correu del GPLURV. Aixi que… si no estas apuntat a la llista… a què esperes? Anima’t!

Autor: mengor

Per què no ens animem? Com s’organitza això? A veure si conseguim fer-nos un anell de confiança de claus!

Que vagi bé!

.

Autor: mengor