lunes, febrero 28, 2005

La web personal de gustavo. A partir de ella he llegado a su site técnico.

viernes, febrero 25, 2005

Varios comandos muy utiles en Linux. Nos serviran por ejemplo para ver que version de
drivers de la controladora de HD tenemos:

/sbin/modinf -> Nos da info de un determinado modo
/sbin/lsmod -> Nos listará los modulos que tenemos cargados
/sbin/lspci -> Nos dirá información sobre los dispositivos PCI que tenemos

Luego otro muy util es /bin/dmesg, que nos muestra mensajes del kernel.

Otro comando util para scripts es seq, que nos servirá para generar una secuencia de numeros.

Y para acabar este post: 10 razones para usar Firefox.
La web de la empresa de Gustavo Zaera, un compi de curro de Fast.
Me gusta tanto el diseño, simple, como las fotos. Chapó Gustavo.

miércoles, febrero 23, 2005

Bueno el post de hoy...

Mirando sobre para optimizar una configuracion de RAID en el curro, he aqui que tengo que comentar:

+ Este link:
http://es.tldp.org/Articulos-periodisticos/jantonio/vfs/vfs_1.html
+ Los parametros del kernel para modificar el
read-ahead estan en /proc/sys/vm (el min y el max)
+ Tb. se pueden consultar/modificar con blockdev o
hdparam (de /sbin)
+ Y otra: http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html

martes, febrero 22, 2005

Caida de Wikipedia


Es lo mas interesante de hoy de barrapunto. Y mas interesantes que los posts de barrapunto, son los de Slashdot.

viernes, febrero 18, 2005

Sobree utf-8.

Mas sobre hardware


Las bestias de mi proyecto.
Sevidores de Sun (pasado por mi hermano)

Y como no Toms Hardware sigue dando caña en lo que ha HW se regiere. Este link va de HDs.

Y para probar rendimiento de HDs, tenemos a Bonnie++. A Bonnie ya lo mencioné en un post anterior.

HDs info



www.storagereview.com

jueves, febrero 17, 2005

Tras mirar un post antiguo he echado un vistazo a Bonnie y PScan. El primero es una herramienta de Benchmarking lo cual es distinto que de monitorización, y el segundo no sirve para nada.

Sobre monitorización



Me he estado empapando de sar. Y echando un vistazo a que otras herramientas tengo instaladas.
En las maquinas en las que estoy currando (Linux) tenemos sar, mpstat (cpu), iostat (entrada y salida) y vmstat (memoria virtual).

El sar viene junto a sadc (lo usa de backend), sa1 y sa2. Los dos ultimos son para usarse con el cron.

Tb. hay otro comando, isag, que no se para que sirve.

El mas completo de todo es sar, y con el podemos ver lo que nos dan los otros.
Lo malo es que da una monitorización total, no se puede hacer por procesos.
Con la opción -x se pueden monitorizar procesos, pero sólo una información determinada.

Para monitorizar el disco iostat está bien, pero para obtener los tiempos de espera, es necesario tener parcheado el kernel (la maquina en la que estoy no lo está). ¿Afectará dicho parcheado al rendimiento?

Todos estos comandos normalmente tiene 2 parametros, que son el intervalo en segundos a monitorizar y el numero de veces a hacerlo.

Aquí hay un script para sar que le pasa los siguienes flags (y saca la salida a un fichero; y cada segundo):


    -b : ratio de transferencia de I/O
    -d : actividad en sectores de bloques (numero de sectores)
    -q : queue length and load averages
    -r : estadisticas de memoria y swap
    -u :utilización de CPU
    -W: swapping
    -n FULL: red


La opción -A de sar aparte de los anteriores mete :


    -B: swapping
    -c: creación de procesos
    -R:estadisticas de memoria
    -v: estado de inodos, ficheros y tablas del kernel
    -w: estadisticas de swapping
    -y: estadisticas de dispositivos TTY
    -I SUM: estadisticas de interrupciones
    -I PROC: estadisticas de interrupciones

miércoles, febrero 16, 2005

Una web de empleo: www.tea-cegos-seleccion.es.

Una herramienta de administracion de red

Nagios.

En TPI estan usando MRTG. Aqui mas info.

martes, febrero 15, 2005

Configuration Management Tools


Unas cuantas:

sábado, febrero 12, 2005

emule


Aqui ando mirando como mejorar el rendimiento de la mula. Que tiene su cosa. Un link bueno.
A partir de él podemos acceder a otros.
Aparte de explicar en ellos determinados parametros, me ha llamado la atención el saber que los ISPs filtran las conexiones para darte por el rasca si usas emule. para ello usan una aplicación de p-cube. Que por cierto ha sido pillada por cisco.

Para acabar este post. Una de las primeras cosas a hacer es cambiar los puertos.

viernes, febrero 11, 2005

RAID

Una consulta al respecto.
La definicion.

Este los explica muy bien.
Y otro link, que no he mirado. Solo ojeado por encima.

jueves, febrero 10, 2005

martes, febrero 08, 2005

Sobre certificados de FNMT


Esta es la url: http://www.cert.fnmt.es.
Yo lo tenia, pero ahora mismo entre reinstalaciones de ordenadores y movidas ya no. Con lo cual a pedirlo de nuevo.
Ya lo he solicitado => siguiente tramite ir a AEAT.
Una vez hecho el proceso fisico, te lo puedes descargar. El certificado se te instala en el ordenador => lo primero que hay que hacer es exportarlo. Se puede exportar con clave privada o sin ella. He aqui la diferencia:

Ud. deberá exportar el certificado con su clave privada solo para su uso personal o como copia de seguridad.
La clave privada servirá para realizar firma digital.
El certificado sin la clave privada podrá exportarlo para entregarlo a todo aquel que quiera comunicarse con Ud. de forma segura.
Importante: Haga copia de seguridad a disco de su certificado junto con la clave privada y guárdela en lugar seguro. Nunca entregue copia de su clave privada a nadie bajo ningún concepto.

Es importante exportarlo en un formato que entienda tanto Netscape como Exporer, el PKCS #12 (.PFX).
Es necesario que nuestro navegador soporte encriptación con 128 bits (si estamos actualizados a navegadores recientes, lo estará).

En la url anterior se pueden consultar muchas cosillas, ya que tienen una 'base de conocimiento', con preguntas mas frecuentes.

Para descargarse el certificado:

El certificado raíz de FNMT Clase 2 CA se obtiene en la siguiente página: http://www.cert.fnmt.es/certifi.htm. Una vez en la página, descargaremos el certificado haciendo click sobre el link: Descarga del Certificado Raíz de FNMT-RCM Certificado de Usuario, en cuyo caso se le mostrarán las instrucciones precisas dependiendo de su navegador

También puede descargar el certificado raíz directamente pinchando aquí. Ha de seleccionar la opción 'Abrir este archivo desde su ubicación actual' en el caso de Internet Explorer y siguiendo las instrucciones en todos los casos.

Y ya unas ultimas cosillas:

Si en el momento de la solicitud se aportó la dirección de correo electrónico, los certificados emitidos desde el 6 noviembre del 2000 poseen las características necesarias para que pueda ser utilizado en su correo.
Para poder utilizar su certificado este debe tener ciertas características, la principal es que tenga una dirección de correo electrónico incluida en el propio certificado según lo establecido por el protocolo S/MIME descrito en el RFC 1521 (http://www.ietf.org/).
Si el certificado no tiene ninguna dirección de correo asociada, y si Ud. desea utilizar las ventajas que ofrece este tipo de correo, deberá solicitar la revocación del antiguo y solicitar otro certificado por los procedimientos habituales, pero aportando su dirección de correo electrónico.

Como dicen, el certificado para poderse usar para firmar correos digitalmente, debe de tener la dirección de correo. El mio desde luego no lo tiene, ni lo va a tener => me va a tocar revocarlo y volverlo a pedir :(. Siempre esta la opción de pedirlo a otra entidad certificadores


lunes, febrero 07, 2005

Sobre encriptacion



Respuesta segunda del colega de Isra (sobre lo de detectar el algoritmo):

No.

Cuando cifras algo incluyes información sobre el algoritmo usado (los famosos formatos PKCS o algo similar) de forma que no mandas directamente el chorro de datos sino que va con su cabecera que dice método, etc. etc.
Pero si cifras algo a lo bestia (a lo Ibarretxe, vamos) y no dices que método de cifrado has usado, lo que tienes es un auténtico galimatias.
Podría hacerse algo para intentar acotar la familia y quizá algo más haciendo algún estudio matemático, por la longitud del bloque, y siempre que pensemos que buscamos entre los algoritmos conocidos, podriamos intentar algo, pero vamos, no lo veo factible. Con cifrados clásicos sí que sería relativamente fácil (Cesar, Vigenere, etc.) pero si te vas a los métodos modernos (Safer, DES, 3DES, Blowfish,......) vas de craneo´porque además puedes haber usado métodos para que un bloque cifrado dependa del anterior y cosas así de raras que usa esta gente. Por ganas de dar por saco y aunque no aumenta la seguridad puedes pasarlo por dos algoritmos, meter información que no aporta nada,... luego tienes que aún sabiendo el algoritmo puede estar usando longitudes de clave o de bloque diferentes,....
Vamos que ni de coña.


Sobre el certificado PKCS #12



Una FAQ al respecto.
Es el certificado que hay que usar para exportar de IE e importar con el Firefox.
Para exportar te indican: Make sure the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) check box is checked.
Para importar te indican:
  • Supply the password you used when you created the PKCS #12 file.
  • Make sure the Enable strong private key protection check box is checked.
  • Make sure the Mark this key as exportable check box is checked.




sábado, febrero 05, 2005

Post antiguos sobre encriptacion



Vaya, habia metido lo siguiente por error en otro weblog...

Sobre detección de un bloque encriptado

Del grupo scri.crypt. El thread.
Esta muy interesante el hilo.
Según dicen es posible detectarlo, pero siempre habrá errores. Se supone que la detección es automatica, mediante un programa.
El primer problema, es cuantos fallos habrá, pero más atún, cuantos megas al dia de fallos habrá.

Tambien comentan que se usa mucho el uuencode y uudecode. Esto añade la problematica de que no sabes eltipo de fichero que va.

Esta parrafada es muy interesante:

ne way to avoid encryption detection is by a variation of the old microdot

routine.

1. Digitize some old, grainy photo
2. Replace bit k*n of the photo with bit k of the encoded message; where n
is some constant ~ 60.

With even a modest computer, no need to securely transmit the constant n. The
recipient just tries them all.

Clearly, this method does not conserve bandwith.

Our photo eMicrodot (tm) can be compressed anbd viewed as a regular photo.
For a special treat for the boys from Justice, use a picture of J. Edgar in
drag.
¡Ah! Al principio del thread, mencionana a 'Eve'. No se si se tratará de una aplicación.

Y este otro:

 ...probably wasn't even the first to propose this, but I wrote

articles in sci.crypt in 1988-89 about the "LSB method," wherein
messages, presumably encrypted, are placed in the least significant
bit of a GIF or other image, or in the LSBs of digital audio tapes.
(Cf. Kevin Kelly's article in "Whole Earth Review," Summer 1993, or in
his new book, "Out of Control," for a description.)

A version of this was hacked in PhotoShop, by me.

Several "stego" (steganography, which is of course what this is)
programs now exist, notably "JSTEG" (pun on JPEG) and "Stego."

Romana Machado's "Stego" program for the Mac has gotten a fair amount
of attention. I think it's available at the sumex.stanford.edu archive
site.

Interestingly, law enforcement types are speculating that the computer
porn folks using the Lawrence Livermore Labs computers were using the
LSB method to smuggle out defense secrets. I doubt it pretty strongly.
Y...

Otro thread, sobre detección de 'ciphertext'.

Esta parrafada es buena:

"Any decent crypto software produces a perfectly uniform distribution,

i.e. totally random-looking data. Any automatic crypto-detection
software would be looking for known crypto-headers or uniformly-
distributed data after all other headers.

To increase NSA's computers workload, you may simply add layers of
encoding or compression, like uuencode .zip .arj .tar etc.

Since there's a bewildering amount of data formats and software,
trying to match a file's distribution with the typical one is a
daunting task. The file may be too small to detect a significant
difference, and many won't even be recogniced.

So it's possible to foil automatic cryptogram detection by padding
files with non-randomly distributed garbage. The garbage may be
chosen to imitate the distribution of common formats (wich may be
difficult) or simply with a different pattern each time.

The bottom line is that *detecting* a message may be as hard as
cracking a cipher. For that reason, personal-ads in papers and
even flower orders were forbidden in WWII. So what chances have"
spys against the gigantic Usenet?"



Y ya para acabr por hoy, un concepto, steganography. Es el hecho de ocultar un mensaje.

viernes, febrero 04, 2005

Y otros dos links interesantes:

  • Stirmark para audio.
  • Y 2mosaic. Para evitar crawler que buscan watermarking.
Un par de links que me ha pasado arturo:

Haciendo ya busquedas mas correctas, al final he conseguido articulos interesantes de DDJ y CUJ (he buscado por 'random' y 'statistical analysis').

De DDJ:
De CUJ:


Statistical testing of random number genrators


Llevo poniendo ultimament muchos post sobre este tema :(. Bueno ha sido un procesos de busqueda larga, pero al final la busqueda ha sido fructifera.

Un articulo al respecto.
Una pagina con links al respecto. Entre ellos esta la Testing Suite del NIST.
Aqui esta Diehard. E info al respecto.
Y aqui esta Dieharder. Que no se si es util

Buscando por 'Diehard tests' en google se obtiene bastante info.
Referencias sobre patentes de software en el Proyecto de Constitución Europea [barrapunto.com].

Randomness in the ciphertext


Un thread al respecto. Esta muy interesante ya que de él, he obtenido (al fin) lo que estaba buscando, una aplicación que haga analisis estadísco de 'ciphertext', FineCrypt. Es interesante otro programa que menciona, Yarrow. Lo usa para generar ficheros con contenido pseudo-aleatorio.
FineCrypt la verdad es que tiene muy buena pinta. Lo malo es que el analisis estadistico se hace dentro del GUI, por lo que no serviría. Necesito un comando. De todas formas si al final acabo desarrollando uno, puede servir para comparar.
La pregunta que lanza el tio (tras una introduccion):

My question is: is randomness of cyphertext a reasonable measure of  actual encryption strength, or is it just another item muddying the

water?
Voy a intentar extraer las parrafadas mas interesantes. Eso si, vete a saber si son afirmaciones ciertas todas.

+ "It is not a reasonable measure..."


+ "For messages that are much longer than the key, the ciphertext is about as random as
the corresponding plaintext."

+ "> Results are along the lines of "The file content is almost
> certainly not random" or "The file content is almost certainly random."


"The former makes sense but the latter doesn't. What "randomness" tests
determine is whether the observed data is consistent with the hypothesis
that it is generated by a random source. It is possible to attribute a
likelihood for deviation from the model, but not for conformance to it."

+ " Beware. I looked at FineCrypt about a year ago and it had many
implementation errors that do not inspire confidence. The "randomness"
tests are pretty basic compared to what is availiable... Check out the NIST
test suite, Diehard, DiehardC FIPS 140."

+ "It is becoming increasingly clear that the best way to test the
programs is with the test vectors."

+ "
The
randomness of the output depends both on the input and the cypher. No
distinction is made by the questioner. He simply took a few outputs and
measured their randomness and found some to be random, according to some
stupid test, and other not. He asked if the output's being random
according to his unknown test, could
be used to infer something about the strength of the cypher. The answer is no.

One reason is that the output also depends on the input (the whole point
of the argument) . Another is that
no small key cypher has truely random output with non-random input, since there is a
simply algorithm (the decryption) which will produce the non random
input from the output. However, no stupid randomness test will ever
discover this unless the cypher is very very very weak."

+ "
>The
> randomness of the output depends both on the input and the cypher.


Not with RC4, unless "Input" has now been changed to include the
key."


jueves, febrero 03, 2005

OSSIM es una herramienta de seguridad que integra varias de software libre.
Esta hecha por españolitos.

Aclarando conceptos



Ya para acabar con todo este tema de la criptografica, voy a aclararme unos conceptos.

Por un lado tenemos la criptografia (cryptography) y el criptoanalisis (cryptanalysis). Ambas forman la criptologia (cryptology).
Por otro lado tenemos la 'steanography' y la 'steganalysis'.

Unas cifras sobre logitudes de claves


Según he leido los algoritmo no simetricos (de llave publica) deben de tener una longitud de clave mayor que los simetricos para la misma seguridad.

En los asimetricos, se consideran seguras hasta las siguientes fechas las longitudes:


  • 1024 hasta 2010

  • 2048 hasta 2030

  • 3072 mas alla del 2030



En los simetricos creo que se considera seguro 256.
Creo que con DES se está usando 112 bits y con AES 128. El govierno de USA recomienda para AES 192 o 256.

Para acabar. De los asimétricos, la 'elliptic curve cryptography' necesita menores longitudes de clave.
Ya he llegado a un punto en que tengo tanto papers en abundancia sotre 'steganalysis', ahora necesito llegar al mimo punto sobre 'cryptoanalysis'.

En sourceforge.net, con la busqueda adecuada (cryptanalysis), ya obtengo resultados. Bien!!! No hay nada como buscar con las palabras adecuadas. Pero no veo nada de lo que me interesa, que es detectar que algo está encriptado.

He aqui, la primera busqueda exitosa. En muy informativo:

"There is an automated statistical software package (ATS) that can do an
excellent vertical differentiation and a reasonable horizontal
differentiation of about 75 different commercial cipher systems based on
analysis of ciphertext or suspected ciphertext. It also tests the random
number generation, based on standard NIST FIPS 140-1,2 standards. I have
used it in my consulting and improved it for several years ( as the various
cipher systems have grown/ changed or introduced). I have been able to
detect changes in product offerings and detect encrypted traffic in
some very sensitive assignments. ATS can be used to look at network traffic
and packetized traffic and has various options to pear down the headers to
get to the VPN or IPSec traffic.

ATS has some limitations. Steganography laced with 3DESor RC5 yields
signatures that are more difficult to interpret. I have only characterized
Rijndael (my favorite) and Twofish in the current AES 5-finalist group. ATS
is not as rigorous as the NIST tools and is not used for certification at
NIST levels.

Theoretically perfect algorithms yielding white noise signatures are
indistinguishable. However, implementations are not perfect and platforms
respond differently. The latter two permit statistical and probabilistic
analysis of the various cipher product offerings.
My "ICSA Guide To Cryptography," McGraw Hill, 1999 has a brief discussion in
Chapter 21."

Tras ella penseé que iba a encontrar algo, pero nada. De momento mis intentos han sido infructuosos. He intentado google, ddj, cuj y sourceforge.net

A ver si otro dia estoy mas inspirado buscando. Algo tiene que haber...
Ja, mi empresa ha sacado un concurso interno para sacarse las certificaciones CISA y CSIM de ISACA.
Por lo visto CSIM es un certificado de seguridad y CISA de auditoria.

Y seguimos mirando

Otra pagina sobre steganalysis.
WetStone es una empresa que tiene varios productos, de steganalysys.
Leyendo sobre la empresa veo que hay un termino que se usa para este tipo de investigacion 'digital forensics'. Bueno el producto que interesa (tienen mas) es Stego Suite. Cuesta $1.995. La suite se compone de dos productos, Stego Watch y Stego Analyst, que hacen lo que su nombre sugiere.
Aparte tienen otro producto para detectar Malware, Malicious Software; Gargoyle.

Esta también es interesante, ya que:
  • Afirman que el 'statistical stegoanalysis' ya no es eficaz para la detección.
  • Y tienen montado un framework para detectar imagenes en la web. Usan un crawler libre para ello. Luego usan stegdetect y finalmente 'stegbreak' (esto no se lo que es :( ).
Este paper puede ser interesante de leer.

Y una ultima[forensics.nl] pagina. Ya estoy un poco saturado.... y en esta hay muchisimos articulos en pdf. Y su hermana para watermarking. Este sitio parece estar muy bien, cubriendo el tema de 'Computer Forensics'.

Cambiando de tercio


Unas noticias de barrapunto:

Bien, bien, ya se como encauzar mi busqueda y es buscar por steganography. En sourceforge.net me salen casi 20 proyectos al respecto, pero ninguno de detección.

Esta[stegoarchive.com] es otra pagina que he encontrado al respecto. Tiene bastantes productos sobre para hacer 'stegoing' y algunos para hacer 'unstegoing' o detección. Como por ejemplo:

  • stirmark. Se dispone como binario y en codigo fuente (C/C++). Es una 'suite' para probar esquemas de 'watermarking'. Creo que necesita lo marcado y el original.
  • stegdetect (solo para jpeg)
Aqui, mas productos para hacer 'esteanografia'.

En la pagina de stegdetect [ourgess.org] se pueden encontrar articulos al respecto (de steanography) y links.

Buscando en google, sobre 'steganography detection' obtengo resultados, pero de todas formas sobre encryption detection, no.

Si se quiere detectar mensajes ocultos en la red, habrá que hacer:

+ En primer lugar mirar si sobre el bloque de datos se ha aplicado alguna técnica de ocultación (steganography).
+ O bien si los datos estan encriptados.

Con esto ya tendriamos detectado, contenido sospechoso.
Hay que tener en cuenta que ademas de aplicar ocultación, posiblemente los datos ocultos pueden estar cifrados.

Por cierto, un concepto relacionado con 'steganography' es watermarking.



Y otra [mycrypto.net] pagina interesante, sobre encriptación.
Y otra [philzimmermann.com] mas,. El creador de PGP.
Ummmmm, de momento no he encontrado el susodicho articulo, pero si una libreria interesante: Crypto++.

Al final no he encontrado nada en ddj, pero este articulo tiene buena pinta.
Lo que me ha resultado curioso de ddj es que ahora no te dejan ver los ultimos números, pero de los antiguos si.

Aqui hay uno del Alexandrescu sobre el Double-Checked Locking. Y la primera parte del mismo.

Mas sobre la detección de datos criptograficos


He preguntado en Kriptopolis, a ver si me responde alguien.
Ya me han respondido en scr.crypt. Me indican, que en ddj salio algo hace poco.

There was a related article in the last few months in Dr. Dobb's Journal, but I

don't have that issue right at hand...

Basically, encrypted data looks random, so testing a block for randomness will
help to find ciphertext, but it will also find compressed blocks of data which
also look random.


Habrá que buscar en ddj a ver si veo algo...

miércoles, febrero 02, 2005

Grupo sobre Criptografia



En scri.crypt hay 2 grupos, este es el adecuado: sci.crypt.research.

martes, febrero 01, 2005