Re: Webmail
Yo uso Horde y es bastante parecido a zimbra. 2009/9/1 Nerd - Ethall vodoomasterg...@gmail.com: [...] He usado RoundCubeMail alguna vez, y dejame decirte que me gusto muchisimo. Quiza puedes verle por ahi: http://www.roundcube.net/ Salu2. -- GCC.
Re: Seguridad en bancos (era Re: HA)
2009/9/1 Leo Soto M. leo.s...@gmail.com: 2009/9/1 Ivan Altamirano ivangelio...@gmail.com: [...] No pues. El numerito del aparato electronico cambia cada X segundos (60 o 30). Para poder saber el proximo numero tienes que conocer la semilla de la secuencia, que ni el dueño del aparato sabe (pero que está almacenada adentro, naturalmente). cuando me ofrecieron el dispositivo.., tenia la duda de como funcionaria.. pensaba que cada vez que realizaba una transacción el banco enviaría un nuevo código al aparato (algo parecido al bip/busca personas) y me preguntaba que pasaría se estuviera fuera del país o en alguna parte sin cobertura. entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Cómo saber cuándo un proceso se ha caído
Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Saludos -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera
Re: Cómo saber cuándo un proceso se ha caído
Hola, Hace tiempo hice uno con mldonkey, quizá te sirva: #!/bin/bash proceso=/archivos/mldonkey-debian/mlnet pid=`ps auxw | grep $proceso | grep -v grep` if [ -z $pid ]; then echo ejecutando mlnet /etc/init.d/mldonkey start else echo el proceso esta corriendo en este momento fi Le puedes agregar un envío de correo si quieres que te avise. Saludos. El 2 de septiembre de 2009 10:47, Franco Gaudino franco.gaud...@slackware.cl escribió: Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Saludos -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Juan Esteban Pulgar Howes Técnico en Sistemas Informáticos. (E) Ingeniería Informática.
Re: Cómo saber cuándo un proceso se ha caído
Hola Juan. Gracias, al parecer por ahí va el tema, le doy una vuelta y lo comento. Saludos El 2 de septiembre de 2009 11:07, Juan Esteban Pulgar Howesjpulg...@gmail.com escribió: Hola, Hace tiempo hice uno con mldonkey, quizá te sirva: #!/bin/bash proceso=/archivos/mldonkey-debian/mlnet pid=`ps auxw | grep $proceso | grep -v grep` if [ -z $pid ]; then echo ejecutando mlnet /etc/init.d/mldonkey start else echo el proceso esta corriendo en este momento fi Le puedes agregar un envío de correo si quieres que te avise. Saludos. El 2 de septiembre de 2009 10:47, Franco Gaudino franco.gaud...@slackware.cl escribió: Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Saludos -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Juan Esteban Pulgar Howes Técnico en Sistemas Informáticos. (E) Ingeniería Informática. -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera
Re: Seguridad en bancos (era Re: HA)
On Miércoles 02 Septiembre 2009 10:10:14 Victor Hugo dos Santos escribió: o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. Son pseudoaleatorios, solo que el banco sabe la semilla con la que fueron generados, y pueden reconstruir la secuencia completa generada. Y ademas, se basa en un algoritmo cerrado que hace la generacion de numeros, yo por ese lado dudaria de su seguridad.
Re: Cómo saber cuándo un proceso se ha caído
El mié, 02-09-2009 a las 10:47 -0400, Franco Gaudino escribió: Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Acá utilizo monit para un servicio muy particular, hace lo que tu pides y más... probablemente hayan otros, pero este me funciona OK. saludos. $ apt-cache show monit ... ... Description: A utility for monitoring and managing daemons or similar programs monit is a utility for monitoring and managing daemons or similar programs running on a Unix system. It will start specified programs if they are not running and restart programs not responding. . monit supports: * Daemon mode - poll programs at a specified interval * Monitoring modes - active, passive or manual * Start, stop and restart of programs * Group and manage groups of programs * Process dependency definition * Logging to syslog or own logfile * Configuration - comprehensive controlfile * Runtime and TCP/IP port checking (tcp and udp) * SSL support for port checking * Unix domain socket checking * Process status and process timeout * Process cpu usage * Process memory usage * Process zombie check * Check the systems load average * Check a file or directory timestamp * Alert, stop or restart a process based on its characteristics * MD5 checksum for programs started and stopped by monit * Alert notification for program timeout, restart, checksum, stop resource and timestamp error * Flexible and customizable email alert messages * Protocol verification. HTTP, FTP, SMTP, POP, IMAP, NNTP, SSH, DWP, LDAPv2 and LDAPv3 * An http interface with optional SSL support to make monit accessible from a webbrowser -- Marcelo Espinosa Alliende, mailto:marc...@ubiobio.cl Jefe Depto de Servicios Computacionales Dirección de Informática - Universidad del Bío-Bio fono: +56 (41) 2731531, http://marcelo.ubb.cl
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 10:10, Victor Hugo dos Santos listas@gmail.com escribió: 2009/9/1 Leo Soto M. leo.s...@gmail.com: 2009/9/1 Ivan Altamirano ivangelio...@gmail.com: [...] No pues. El numerito del aparato electronico cambia cada X segundos (60 o 30). Para poder saber el proximo numero tienes que conocer la semilla de la secuencia, que ni el dueño del aparato sabe (pero que está almacenada adentro, naturalmente). cuando me ofrecieron el dispositivo.., tenia la duda de como funcionaria.. pensaba que cada vez que realizaba una transacción el banco enviaría un nuevo código al aparato (algo parecido al bip/busca personas) y me preguntaba que pasaría se estuviera fuera del país o en alguna parte sin cobertura. entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. entonces los codigos no se pueden repetir? lo otro, si por ejemplo dejo pasar 3 numeros, los anoto y luego uso el 2do que me aparecio, el sistema lo acepta? o debe ser siempre el ultimo, es decir, el que estoy viendo en pantalla en el mismo instante que lo ingreso al sistema? -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
2009/9/2 Matias Valdenegro T. huntsma...@vtr.net On Miércoles 02 Septiembre 2009 10:10:14 Victor Hugo dos Santos escribió: o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. Son pseudoaleatorios, solo que el banco sabe la semilla con la que fueron generados, y pueden reconstruir la secuencia completa generada. Y ademas, se basa en un algoritmo cerrado que hace la generacion de numeros, yo por ese lado dudaria de su seguridad. Dependiendo del nivel de seguridad, está el costo asociado. En Chile se que se han implementado dos tipos de 4 existentes... Los más vulnerables, son los de password conocida (tarjeta matricial), después vienen los digipass de password asincrona, donde el banco chequea el pin ingresado en función del part-number ubicado en la parte trasera de cada token y calcula el match. Hay otros que no los he visto masivamente a público, que son los de password sincronizada, a través de internet o bluetooth, gsm, gprs (cliente-servidor) Slds -- Herman Vega Jara hvegax[a]gmail.com
Re: Seguridad en bancos (era Re: HA)
Ivan Altamirano escribió: La tarjeta de coordenadas entregada por el Banco Santander y Banco Estado, no tiene mucho que envidiar a los Digipass de otros bancos. Esto es porque la calidad de los Digipass (Material de fabricación) es pésima, igual de pésima que las tarjetas de coordenadas, salvo que a estas últimas no dejan de funcionar por falta de batería ;) . ¿Y eso qué tiene que ver con la seguridad que otorga el aparatito? Si se trata de de tomar fotos al momento de la transacción, pasaría exactamente lo mismo que con los Digipass (Obvio, si fué capaz de ver la clave de la tarjeta de coordenadas, también debiera tener la clave de acceso al Banco). Además, ¿que es mas fácil?, ¿que se te pierda el llavero (lugar donde generalmente las personas almacenan el Digipass) o que se te pierda la billetera (lugar donde generalmente las personas almacenan las tarjetas de coordenadas)?... No, no. Estás confundiendo qué problema ataca cada parte del sistema de seguridad. Primero que nada está la clave común y corriente. La gente es idiota (como ya nos recordaron Alejandro Fuentes y Germán Poo) así que la clave se le olvida, o la mete en un sitio de phishing, o la mete en un PC con un keylogger en un ciber, o la deja anotada en un papel que alguien obtiene. Si este fuera el único mecanismo de seguridad, las cuentas pasarían vacías. Segundo está la clave que entrega el pinpass. Esta clave no permite ataques de replay, así que el keylogger no sirve. No se puede anotar en ninguna parte. No hay modo que un phisher obtenga la clave (a menos que el phisher haga de man-in-the-middle, pero esto es muchísimo más complicado que un phishing común y corriente). ¿Se te perdió el artefacto de números aleatorios? No es tan grave, porque aún existe la otra clave. En el intertanto es posible que te des cuenta que se perdió y pidas uno nuevo y que se anule el anterior, antes que el atacante pueda obtener tu otra clave. Si se te pierde el llavero, normalmente lo sabes de inmediato (sobre todo si tiene el pinpass). El atacante no puede atacarte hasta que no haya conseguido tu segunda clave; y tú lo invalidarás lo antes posible. Si te copian la tarjeta, y no te das cuenta, el atacante sólo tiene que esperar hasta poder conseguir la clave, pero tú no te has dado cuenta del hurto así que no te preocuparás de cambiarla. -- Alvaro Herrera http://planet.postgresql.org/ Y dijo Dios: Que sea Satanás, para que la gente no me culpe de todo a mí. Y que hayan abogados, para que la gente no culpe de todo a Satanás
Re: Seguridad en bancos (era Re: HA)
Victor Hugo dos Santos escribió: entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. El banco y el aparato están sincronizados con la semilla de generación de números aleatorios y con el reloj. El aparato genera un número distinto dependiendo de esos dos factores. Un atacante puede obtener la hora exacta (puesto que es un dato público), pero no tiene cómo obtener la semilla a menos que se la robe al banco o la obtenga de tu aparatito. -- Alvaro Herrera http://planet.postgresql.org/ La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos... (Yo, hablando de sueños eróticos)
Re: Seguridad en bancos (era Re: HA)
Sebastián Veloso Varas escribió: Conozco gente que tiene estos tokens de seguridad hace mas de 3 años y nada de nada...Es mas, ellos detectan (si alguno sabe como!) si tu lo echas a perder o no directamente Suena tan cercano a un chamullo que me cuesta mucho distinguirlo. Seguramente tú llevas el aparato al banco cuando detectas que no funciona bien, y ahí ellos detectan que se echó a perder (o, mucho más probablemente, te dan uno nuevo sin más trámite). -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC Uno puede defenderse de los ataques; contra los elogios se esta indefenso
Re: Webmail
El 1 de septiembre de 2009 19:02, Vida Luz Arista v...@ideay.net.niescribió: Ok, no explique bien el caso, no tengo Zimbra como MTA, tengo virtual box con postfix+Mysql+Cyrus+amavisd+clamav, tengo acceso a IMAP, pero quiero un webmail que se parezca al de zimbra, es que vi el de zimbra y me pareció super liviano y sencillo, pero entiendo que no lo puedo usar solo como webmail, y la verdad pasarme a zimbra esta cañon, solo quiero un buen webmail, el squeremail nome gusto mucho. si lo que buscas no es solo un buen webmail, podrias tambien revisar OpenGoo. -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
2009/9/2 Alvaro Herrera alvhe...@alvh.no-ip.org: Victor Hugo dos Santos escribió: entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. El banco y el aparato están sincronizados con la semilla de generación de números aleatorios y con el reloj. El aparato genera un número distinto dependiendo de esos dos factores. Un atacante puede obtener la hora exacta (puesto que es un dato público), pero no tiene cómo obtener la semilla a menos que se la robe al banco o la obtenga de tu aparatito. Como confirmación, entiendo que si no usas el sistema durante un tiempo, el reloj del aparatito se atrasa o adelanta y puedes tener problemas de descoordinación. A mi la duda que tengo cada vez que uso el aparato es que si alguien tiene mi clave de memoria y tiene la posibilidad de mirar la llave generada por el aparatito, puede generar transacciones durante el intervalo que es válida la llave También me late que dado que la coordinación de los relojes no es exacta, se validan al menos dos o tres llaves o sea la duración de una clave del aparato es el doble o el triple... -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 12:32, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ivan Altamirano escribió: La tarjeta de coordenadas entregada por el Banco Santander y Banco Estado, no tiene mucho que envidiar a los Digipass de otros bancos. Esto es porque la calidad de los Digipass (Material de fabricación) es pésima, igual de pésima que las tarjetas de coordenadas, salvo que a estas últimas no dejan de funcionar por falta de batería ;) . ¿Y eso qué tiene que ver con la seguridad que otorga el aparatito? Si se trata de de tomar fotos al momento de la transacción, pasaría exactamente lo mismo que con los Digipass (Obvio, si fué capaz de ver la clave de la tarjeta de coordenadas, también debiera tener la clave de acceso al Banco). Además, ¿que es mas fácil?, ¿que se te pierda el llavero (lugar donde generalmente las personas almacenan el Digipass) o que se te pierda la billetera (lugar donde generalmente las personas almacenan las tarjetas de coordenadas)?... No, no. Estás confundiendo qué problema ataca cada parte del sistema de seguridad. Primero que nada está la clave común y corriente. La gente es idiota (como ya nos recordaron Alejandro Fuentes y Germán Poo) así que la clave se le olvida, o la mete en un sitio de phishing, o la mete en un PC con un keylogger en un ciber, o la deja anotada en un papel que alguien obtiene. Si este fuera el único mecanismo de seguridad, las cuentas pasarían vacías. Segundo está la clave que entrega el pinpass. Esta clave no permite ataques de replay, así que el keylogger no sirve. No se puede anotar en ninguna parte. No hay modo que un phisher obtenga la clave (a menos que el phisher haga de man-in-the-middle, pero esto es muchísimo más complicado que un phishing común y corriente). ¿Se te perdió el artefacto de números aleatorios? No es tan grave, porque aún existe la otra clave. En el intertanto es posible que te des cuenta que se perdió y pidas uno nuevo y que se anule el anterior, antes que el atacante pueda obtener tu otra clave. Si se te pierde el llavero, normalmente lo sabes de inmediato (sobre todo si tiene el pinpass). El atacante no puede atacarte hasta que no haya conseguido tu segunda clave; y tú lo invalidarás lo antes posible. Si te copian la tarjeta, y no te das cuenta, el atacante sólo tiene que esperar hasta poder conseguir la clave, pero tú no te has dado cuenta del hurto así que no te preocuparás de cambiarla. Que mejor explicacion que esa. Tecnicas de keylogger, phishing, no sirven mucho aca... Tecnicas avanzadas y complejas podrian hacer algo. Es mas, como dato, las llaves RSA no ha sido quebrado aun, imaginate alguien logra conseguirlo. Hace un tiempo, el Dr. Scolnik postulo que estuvo trabajando en esto, y que pronto sera capaz de quebrar estas llavecitas... http://www.criticadigital.com/impresa/index.php?secc=notanid=7572 Aca hay PDF con mas info respecto al funcionamiento de SecureID (para los tecnicistas!) http://eprint.iacr.org/2003/162.pdf Un emulador de SecureID simplecito... http://seclists.org/bugtraq/2000/Dec/0459.html -- Alvaro Herrera http://planet.postgresql.org/ Y dijo Dios: Que sea Satanás, para que la gente no me culpe de todo a mí. Y que hayan abogados, para que la gente no culpe de todo a Satanás
Access Point y música wireless
Cuento casi corto: mi viejo notebook dell d810 está medio tuerto (la pantalla/tarjeta de video no funciona); pero lo tengo hace un par de meses funcionando como servidor con los discos de respaldo. Lo que necesito: 1.- Que funcione como access point. El módulo es ipw2200 (8086:4223 (rev 05) Intel Corporation PRO/Wireless 2915ABG [Calexico2]) Estuve averiguando y existe el proyecto ipw2200-ap en sourceforge, pero me gustaría saber si alguien tiene otra experiencia o solución similar. El router que tengo ahora lo quiero dar de baja, porque es muy inestable y malo (típico problema con DNS, mala señal y se cuelga principalmente; además que quiero openvpn y mas funcionalidad)... 2.- Que sea un servidor DAAP y/o un tocadiscos mp3. El primero, para redirigir la música de itunes/rythmbox/etc a al subwoofer. El segundo, para que desde la misma media que tiene en los discos de respaldos toque música, segun un playlist o algo similar, con alguna interfaz web por ejemplo. He intentado un par de soluciones, pero ninguna funcionó lo bien que esperaba. Además que hay tantas, que prefiero una recomendación. No me digan ESD o similares, pues quiero DAAP para transmitir solo lo que toca el reproductor ;) ¿Alguna recomendación de un servidor que hayan usado? Gracias! -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Seguridad en bancos (era Re: HA)
El mié, 02-09-2009 a las 13:15 -0400, Aldrin Martoq escribió: [...] También me late que dado que la coordinación de los relojes no es exacta, se validan al menos dos o tres llaves o sea la duración de una clave del aparato es el doble o el triple... Acabo de hacer esa prueba con mi aparatito del T-Banc: escribí el número y, en cuanto cambió, presioné Enter. No me aceptó la clave y tuve que reingresar por la actual. Al menos en mi caso, los relojes andan como reloj :).
Re: Cómo saber cuándo u n proceso se ha caído
On Wed, Sep 02, 2009 at 11:38:07AM -0400, Franco Gaudino wrote: Hola Juan. Gracias, al parecer por ahí va el tema, le doy una vuelta y lo comento. Otra alternativa es simplemente mirar en /proc/pid. Si existe el directorio, el proceso esta vigente. Ahi tambien puedes ver mas detalles sobre cada proceso corriendo en el sistema. Davidlohr. Saludos El 2 de septiembre de 2009 11:07, Juan Esteban Pulgar Howesjpulg...@gmail.com escribió: Hola, Hace tiempo hice uno con mldonkey, quizá te sirva: #!/bin/bash proceso=/archivos/mldonkey-debian/mlnet pid=`ps auxw | grep $proceso | grep -v grep` if [ -z $pid ]; then echo ejecutando mlnet /etc/init.d/mldonkey start else echo el proceso esta corriendo en este momento fi Le puedes agregar un envío de correo si quieres que te avise. Saludos. El 2 de septiembre de 2009 10:47, Franco Gaudino franco.gaud...@slackware.cl escribió: Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Saludos -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Juan Esteban Pulgar Howes Técnico en Sistemas Informáticos. (E) Ingeniería Informática. -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Davidlohr
Re: Seguridad en bancos (era Re: HA)
2009/9/2 Rodrigo Gutiérrez Torres rodrigogutierreztor...@gmail.com El mié, 02-09-2009 a las 13:15 -0400, Aldrin Martoq escribió: [...] También me late que dado que la coordinación de los relojes no es exacta, se validan al menos dos o tres llaves o sea la duración de una clave del aparato es el doble o el triple... Acabo de hacer esa prueba con mi aparatito del T-Banc: escribí el número y, en cuanto cambió, presioné Enter. No me aceptó la clave y tuve que reingresar por la actual. Al menos en mi caso, los relojes andan como reloj :). Con la tecnología de hoy día, un reloj electrónico no se atrasa/adelanta fácilmente. Deben pasar unos cuantos miles de años para obtener milésimas de segundos de desfase, ergo era de esperar el resultado de tu prueba. Ahora bien, pensando en la solución de RSA, se me ocurre que al otro lado (en el banco) poseen un reloj basado en la misma tecnología(electrónica) del token, por lo que el desfase debiese ser idéntico o mUy similar: usuario(token) - sitio web banco (usuario, numero pseudoaleatorio y password) - Base de datos(cuenta de usuario y password) y appliance RSA (numero pseudoaleatorio). -- Saludos, Leonardo San Martín. Existen 10 tipos de personas: los que entienden binarios y los que no
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 12:32, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ivan Altamirano escribió: La tarjeta de coordenadas entregada por el Banco Santander y Banco Estado, no tiene mucho que envidiar a los Digipass de otros bancos. Esto es porque la calidad de los Digipass (Material de fabricación) es pésima, igual de pésima que las tarjetas de coordenadas, salvo que a estas últimas no dejan de funcionar por falta de batería ;) . ¿Y eso qué tiene que ver con la seguridad que otorga el aparatito? Si se trata de de tomar fotos al momento de la transacción, pasaría exactamente lo mismo que con los Digipass (Obvio, si fué capaz de ver la clave de la tarjeta de coordenadas, también debiera tener la clave de acceso al Banco). Además, ¿que es mas fácil?, ¿que se te pierda el llavero (lugar donde generalmente las personas almacenan el Digipass) o que se te pierda la billetera (lugar donde generalmente las personas almacenan las tarjetas de coordenadas)?... No, no. Estás confundiendo qué problema ataca cada parte del sistema de seguridad. Primero que nada está la clave común y corriente. La gente es idiota (como ya nos recordaron Alejandro Fuentes y Germán Poo) así que la clave se le olvida, o la mete en un sitio de phishing, o la mete en un PC con un keylogger en un ciber, o la deja anotada en un papel que alguien obtiene. Si este fuera el único mecanismo de seguridad, las cuentas pasarían vacías. claro que no. cuando alguien obtiene tu numero de tarjeta de credito nunca hara una compra grande, sino solo de unos pocos dolares para que no te des cuenta. lo mismo ocurre con tu clave comun y corriente. si te confias en que con el digipass estas asegurado contra cualquier tipo de robo estas muy equivocado... con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. lo del digipass es solo una ilusion para hacerte creer que tu banco se preocupa por ti... ;) -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
On Miércoles 02 Septiembre 2009 15:05:32 Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. Solo con la clave (Y el RUT me imagino)? Como? Al menos en el BCI, te pide digipass para loguearte en la pagina. Si no lo tienes como servicio, entra derechito solo con RUT/Clave.
Re: Cómo saber cuándo un proceso se ha caído
Otra alternativa es simplemente mirar en /proc/pid. Si existe el directorio, el proceso esta vigente. Ahi tambien puedes ver mas detalles sobre cada proceso corriendo en el sistema. Davidlohr. eso es lo que buscaba, gracias Saludos El 2 de septiembre de 2009 14:03, Davidlohr Buesod...@gnu.org escribió: On Wed, Sep 02, 2009 at 11:38:07AM -0400, Franco Gaudino wrote: Hola Juan. Gracias, al parecer por ahí va el tema, le doy una vuelta y lo comento. Otra alternativa es simplemente mirar en /proc/pid. Si existe el directorio, el proceso esta vigente. Ahi tambien puedes ver mas detalles sobre cada proceso corriendo en el sistema. Davidlohr. Saludos El 2 de septiembre de 2009 11:07, Juan Esteban Pulgar Howesjpulg...@gmail.com escribió: Hola, Hace tiempo hice uno con mldonkey, quizá te sirva: #!/bin/bash proceso=/archivos/mldonkey-debian/mlnet pid=`ps auxw | grep $proceso | grep -v grep` if [ -z $pid ]; then echo ejecutando mlnet /etc/init.d/mldonkey start else echo el proceso esta corriendo en este momento fi Le puedes agregar un envío de correo si quieres que te avise. Saludos. El 2 de septiembre de 2009 10:47, Franco Gaudino franco.gaud...@slackware.cl escribió: Hola a todos. Tengo que automatizar un programa que corre en un servidor Debian. Al consultar por el estado con ps aux siempre me aparece durmiendo, poco conozco de los estados de procesos. Cuándo me doy cuenta de que se ha caído un proceso lo reinicio y ya, pero, al hacer un seguimiento no logro darme cuenta cuándo se ha caído. Mi necesidad, es, después de haberlo acotado hacer un pequeño script para reinicio automático. Saludos -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Juan Esteban Pulgar Howes Técnico en Sistemas Informáticos. (E) Ingeniería Informática. -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera -- Davidlohr -- Atte Franco Gaudino franco.gaud...@slackware.cl 85989065 Scentless Apprentice GNU/Linux No para cualquiera No para cualquiera
Re: Seguridad en bancos (era Re: HA)
Ricardo Munoz escribió: El 2 de septiembre de 2009 12:32, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Primero que nada está la clave común y corriente. La gente es idiota (como ya nos recordaron Alejandro Fuentes y Germán Poo) así que la clave se le olvida, o la mete en un sitio de phishing, o la mete en un PC con un keylogger en un ciber, o la deja anotada en un papel que alguien obtiene. Si este fuera el único mecanismo de seguridad, las cuentas pasarían vacías. claro que no. cuando alguien obtiene tu numero de tarjeta de credito nunca hara una compra grande, sino solo de unos pocos dolares para que no te des cuenta. lo mismo ocurre con tu clave comun y corriente. si te confias en que con el digipass estas asegurado contra cualquier tipo de robo estas muy equivocado... Hmm. con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. Bueno, este es otro tipo de ataque, totalmente diferente de los anteriores, y para el cual el tipo de solución será obviamente distinto. Eso no quiere decir que los otros mecanismos no sean válidos para cubrir los otros problemas. Para el caso que planteas, creo que una posible solución sería que el sitio web del banco desplegara un cierto número de recientes ingresos en el sitio. Así el usuario puede ver si las fechas/horas corresponden o no. Si el banco fuera más sofisticado podría ver si hay patrones en las direcciones IP del usuario dependiendo de la hora y día de la semana (por ej. entre las 9 y las 7 te conectas de la oficina y siempre vienes de la misma IP, en cambio de las 8 en adelante y los fines de semana te conectas de tal bloque que pertenece al ISP de tu casa); o incluso, si te conectas a horas en que normalmente no lo haces. Por otra parte, robarte dinero es un ataque simple y razonablemente efectivo. Usar la información obtenida a partir del sitio del banco para montar otro tipo de ataque es mucho más complicado (¿has tratado de organizar un secuestro?) En todo caso, si una persona tiene o no mucho dinero es algo que puede extrapolarse a partir de datos mucho más directos que robarte las claves del banco. lo del digipass es solo una ilusion para hacerte creer que tu banco se preocupa por ti... ;) Discrepo :-) -- Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. (L. Torvalds)
Re: Seguridad en bancos (era Re: HA)
Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC God is real, unless declared as int
Re: Access Point y música wireless
El Wed, 2 Sep 2009 13:33:00 -0400 Aldrin Martoq amar...@dcc.uchile.cl escribió: Cuento casi corto: mi viejo notebook dell d810 está medio tuerto (la pantalla/tarjeta de video no funciona); pero lo tengo hace un par de meses funcionando como servidor con los discos de respaldo. Tal vez te sirva de ayuda este link. http://www.electrolinux.cl/doku.php/servtecnico/dellc600.txt Es lo que te puedo decir respecto a la maquina, claro que eso fue antes de que me la robaran :-( [] Saludos --- Atentamente. +---+-+ | Ricardo Albarracin B. | email: ral...@gmail.com | +---+-+
Re: Cómo saber cuándo un proceso se ha caído
2009/9/2 Franco Gaudino franco.gaud...@slackware.cl: Otra alternativa es simplemente mirar en /proc/pid. Si existe el directorio, el proceso esta vigente. Ahi tambien puedes ver mas detalles sobre cada proceso corriendo en el sistema. Davidlohr. eso es lo que buscaba, gracias Una llamada a pidof quizás te sea de utilidad: VAL=$(pidof init) if [ $? -eq 0 ]; then echo Esta el proceso fi -- http://www.mgonzalez.cl/
Re: Seguridad en bancos (era Re: HA)
2009/9/2 Victor Hugo dos Santos listas@gmail.com: [...] entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. Para los curiosos, en http://en.wikipedia.org/wiki/SecurID hay mas informacion (y link a criptoanálisis del algoritmo supuestamente usado) sobre el aparato que distribute BCI/TBanc como Multipass. Probablemente el Digipass del Chile es el mismo, pero no tengo a ninguno de sus clientes a mano para confirmarlo... -- Leo Soto M. http://blog.leosoto.com
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 15:28, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. exacto. por lo mismo dije que lo del Digipass, Multipass, etc. es solo una ilusion para hacerte sentir mas seguro... ;) lo mismo que una alarma o cerradura de seguridad. por mas alarmas, cerraduras, guardias, etc. que tengas si quieren robarte algo te van a robar igual. -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 16:05, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 15:28, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. exacto. por lo mismo dije que lo del Digipass, Multipass, etc. es solo una ilusion para hacerte sentir mas seguro... ;) lo mismo que una alarma o cerradura de seguridad. por mas alarmas, cerraduras, guardias, etc. que tengas si quieren robarte algo te van a robar igual. Discrepo en esto. Los tokens de seguridad efectivamente nos dan una seguridad adicional en nuestras transacciones bancarias. De hecho, no puedes ni ver tu cartola sin la famosa token, ni mucho menos generar un pago. Estas amarrado a una 2° validacion robusta. Y siendo honestos, para el comun es complicadisimo quebrar este mecanismo, a no ser que se destape un agujero de seguridad de la aplicacion bancaria. Obviamente, si obtengo el RUT del cliente, puedo hacer muuuchas cosas, con los contactos o movidas correspondientes (Dicom, SII, Registro Civil) como ejemplo. Eso nos remonta a tecnicas de espionaje, ingenieria social y otras morbosidades mas, que no irian al caso. -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
Leo Soto M. escribió: 2009/9/2 Victor Hugo dos Santos listas@gmail.com: [...] entonces, en el banco me explicaron que el dispositivo funcionaba de manera independiente.. o sea, el propio dispositivo generaba sus códigos y en el banco ya sabían con antelación que códigos serian generados en cada momento. o sea.. son códigos preconfigurados, cuando yo acredito que deberían de ser pseudos-aleatorios.. Para los curiosos, en http://en.wikipedia.org/wiki/SecurID hay mas informacion (y link a criptoanálisis del algoritmo supuestamente usado) sobre el aparato que distribute BCI/TBanc como Multipass. Probablemente el Digipass del Chile es el mismo, pero no tengo a ninguno de sus clientes a mano para confirmarlo... El mío es un IdentityGuard de Entrust, entrega números según un estándar supuestamente abierto, HAMC OTP de la OATH. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ Saca el libro que tu religión considere como el indicado para encontrar la oración que traiga paz a tu alma. Luego rebootea el computador y ve si funciona (Carlos Duclós)
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 16:41, Sebastián Veloso Varas svel...@sevelv.clescribió: El 2 de septiembre de 2009 16:05, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 15:28, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. exacto. por lo mismo dije que lo del Digipass, Multipass, etc. es solo una ilusion para hacerte sentir mas seguro... ;) lo mismo que una alarma o cerradura de seguridad. por mas alarmas, cerraduras, guardias, etc. que tengas si quieren robarte algo te van a robar igual. Discrepo en esto. Los tokens de seguridad efectivamente nos dan una seguridad adicional en nuestras transacciones bancarias. De hecho, no puedes ni ver tu cartola sin la famosa token, por lo que entiendo, solo el BCI funciona asi. ni mucho menos generar un pago. Estas amarrado a una 2° validacion robusta. Y siendo honestos, para el comun es complicadisimo quebrar este mecanismo, a no ser que se destape un agujero de seguridad de la aplicacion bancaria. el comun no va andar robando dinero ajeno por internet (estas diciendo que todos somos delincuentes? jajaja)... el punto no es que sea mas dificil o no romper el mecanismo para un comun. en el link de Wikipedia que entregaron [1] bajo Theoretical vulnerabilities dice Hard tokens on the other hand can be physically stolen (or acquired via social engineering) from end users. The small form factor makes hard token theft much more viable than laptop/desktop scanning. A user will typically wait more than one day before reporting the device as missing, giving the attacker plenty of time to breach the protected system. Obviamente, si obtengo el RUT del cliente, puedo hacer muuuchas cosas, con los contactos o movidas correspondientes (Dicom, SII, Registro Civil) como ejemplo. Eso nos remonta a tecnicas de espionaje, ingenieria social y otras morbosidades mas, que no irian al caso. porque no irian al caso? de que te sirve tener el famoso digipass si por otro lado te pueden robar igual? conoces de algun caso de transacciones realizadas por tereceros (via web) *antes* de implementado lo del digipass? conoces de casos despues de implementado el digipass? han bajado los casos? sin estadisticas a mano es dificil saber acerca de la utilidad del aparatito. [1] http://en.wikipedia.org/wiki/SecurID -- Ricardo Mun~oz A. http://www.tux.cl
Re: Access Point y músic a wireless
Aldrin Martoq escribió: 2.- Que sea un servidor DAAP y/o un tocadiscos mp3. El primero, para redirigir la música de itunes/rythmbox/etc a al subwoofer. El segundo, para que desde la misma media que tiene en los discos de respaldos toque música, segun un playlist o algo similar, con alguna interfaz web por ejemplo. ¿Has probado MPD? Tiene clientes de toda clase; me imagino que habrá web también. (Yo uso Sonata, un cliente GTK, se conecta vía TCP). No sé si se podrá redirigir la música desde otra parte. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ Bob [Floyd] used to say that he was planning to get a Ph.D. by the green stamp method, namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth)
Re: Seguridad en bancos (era Re: HA)
On Wed, 2009-09-02 at 17:34 -0400, Ricardo Munoz wrote: Obviamente, si obtengo el RUT del cliente, puedo hacer muuuchas cosas, con los contactos o movidas correspondientes (Dicom, SII, Registro Civil) como ejemplo. Eso nos remonta a tecnicas de espionaje, ingenieria social y otras morbosidades mas, que no irian al caso. porque no irian al caso? de que te sirve tener el famoso digipass si por otro lado te pueden robar igual? conoces de algun caso de transacciones realizadas por tereceros (via web) *antes* de implementado lo del digipass? conoces de casos despues de implementado el digipass? han bajado los casos? sin estadisticas a mano es dificil saber acerca de la utilidad del aparatito. El contexto es distinto. A saber: La circular 3400 de la Superintendencia de Bancos e Instituciones Financieras[1] estableció que las transacciones interbancarias debían efectuarse de inmediato. Dicho cambio en la norma, iba de la mano con cambios en la forma de operar en línea: - Encriptación sólida; - Disponer *a lo menos* de dos factores de autenticación, exigiendo que uno sea dinámico; - Firma digital (cof, cof) para transferencias de montos grandes. Antiguamente, la transacción tardaba 24 horas. Por lo tanto, en caso de fraude había tiempo para anular la transacción. Al hacerlo de inmediato, necesariamente se debía buscar un mecanismo que impidiera el fraude. El Santander, con una gran cartera de clientes y sin ánimo de invertir mucho, prefirió el cartón de bingo. Otros, un llaverito más simpático. [1] http://www.sbif.cl/sbifweb/internet/archivos/norma_6041_1.pdf -- Germán Póo-Caamaño Concepción - Chile http://www.calcifer.org/
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 17:34, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 16:41, Sebastián Veloso Varas svel...@sevelv.clescribió: El 2 de septiembre de 2009 16:05, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 15:28, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. exacto. por lo mismo dije que lo del Digipass, Multipass, etc. es solo una ilusion para hacerte sentir mas seguro... ;) lo mismo que una alarma o cerradura de seguridad. por mas alarmas, cerraduras, guardias, etc. que tengas si quieren robarte algo te van a robar igual. Discrepo en esto. Los tokens de seguridad efectivamente nos dan una seguridad adicional en nuestras transacciones bancarias. De hecho, no puedes ni ver tu cartola sin la famosa token, por lo que entiendo, solo el BCI funciona asi. ni mucho menos generar un pago. Estas amarrado a una 2° validacion robusta. Y siendo honestos, para el comun es complicadisimo quebrar este mecanismo, a no ser que se destape un agujero de seguridad de la aplicacion bancaria. el comun no va andar robando dinero ajeno por internet (estas diciendo que todos somos delincuentes? jajaja)... El comun en expertise del tema..jajaja a eso me refiero... el punto no es que sea mas dificil o no romper el mecanismo para un comun. en el link de Wikipedia que entregaron [1] bajo Theoretical vulnerabilities dice Hard tokens on the other hand can be physically stolen (or acquired via social engineering) from end users. The small form factor makes hard token theft much more viable than laptop/desktop scanning. A user will typically wait more than one day before reporting the device as missing, giving the attacker plenty of time to breach the protected system. Obviamente, si obtengo el RUT del cliente, puedo hacer muuuchas cosas, con los contactos o movidas correspondientes (Dicom, SII, Registro Civil) como ejemplo. Eso nos remonta a tecnicas de espionaje, ingenieria social y otras morbosidades mas, que no irian al caso. porque no irian al caso? de que te sirve tener el famoso digipass si por otro lado te pueden robar igual? conoces de algun caso de transacciones realizadas por tereceros (via web) *antes* de implementado lo del digipass? conoces de casos despues de implementado el digipass? han bajado los casos? sin estadisticas a mano es dificil saber acerca de la utilidad del aparatito. Nada es exacto. Simplemente, el hecho de poseer autenticacion de doble factor interpretariamos que existe un mecanismo adicional o una segunda valla a pasar. Tambien no tenemos referencias de como se comporta el diseño de seguridad del sistema bancario. Tampoco sabemos si el cifrado duro del sistema es tan asi, o si el cifrado de mi conexion es 100% segura. Para hacer ese análisis, debiesemos considerar demasiadas variantes sin responder por el momento. Otra duda ¿Existe un metodo mas pro que una autenticacion de doble factor? Lo digo por que se que los sistemas bancarios /y muchos mas/ se ven muuyy robustos, pero por detras, en bambalinas, se arman como palitos de fosforos... [1] http://en.wikipedia.org/wiki/SecurID -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
El 2 de septiembre de 2009 17:34, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 16:41, Sebastián Veloso Varas svel...@sevelv.clescribió: El 2 de septiembre de 2009 16:05, Ricardo Munoz rmu...@tux.cl escribió: El 2 de septiembre de 2009 15:28, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Ricardo Munoz escribió: con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. BTW solo con el RUT y un poco de plata puedes pedirle muchos datos sobre una persona a Dicom. exacto. por lo mismo dije que lo del Digipass, Multipass, etc. es solo una ilusion para hacerte sentir mas seguro... ;) lo mismo que una alarma o cerradura de seguridad. por mas alarmas, cerraduras, guardias, etc. que tengas si quieren robarte algo te van a robar igual. Discrepo en esto. Los tokens de seguridad efectivamente nos dan una seguridad adicional en nuestras transacciones bancarias. De hecho, no puedes ni ver tu cartola sin la famosa token, por lo que entiendo, solo el BCI funciona asi. ni mucho menos generar un pago. Estas amarrado a una 2° validacion robusta. Y siendo honestos, para el comun es complicadisimo quebrar este mecanismo, a no ser que se destape un agujero de seguridad de la aplicacion bancaria. el comun no va andar robando dinero ajeno por internet (estas diciendo que todos somos delincuentes? jajaja)... el punto no es que sea mas dificil o no romper el mecanismo para un comun. en el link de Wikipedia que entregaron [1] bajo Theoretical vulnerabilities dice Hard tokens on the other hand can be physically stolen (or acquired via social engineering) from end users. The small form factor makes hard token theft much more viable than laptop/desktop scanning. A user will typically wait more than one day before reporting the device as missing, giving the attacker plenty of time to breach the protected system. Ingenieria social, astucia, mas que conocimientos, son metodos mmm rebuscados, o sea mas bien, robos dirigidos..muy dirigidos creo yo (p.ej le quieres robar plata a tu compañero de trabajo y debes averiguar ciertas cosas antes de...) Obviamente, si obtengo el RUT del cliente, puedo hacer muuuchas cosas, con los contactos o movidas correspondientes (Dicom, SII, Registro Civil) como ejemplo. Eso nos remonta a tecnicas de espionaje, ingenieria social y otras morbosidades mas, que no irian al caso. porque no irian al caso? de que te sirve tener el famoso digipass si por otro lado te pueden robar igual? conoces de algun caso de transacciones realizadas por tereceros (via web) *antes* de implementado lo del digipass? conoces de casos despues de implementado el digipass? han bajado los casos? sin estadisticas a mano es dificil saber acerca de la utilidad del aparatito. [1] http://en.wikipedia.org/wiki/SecurID -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
On Wed, 2009-09-02 at 15:27 -0400, Alvaro Herrera wrote: Ricardo Munoz escribió: El 2 de septiembre de 2009 12:32, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: [...] con tu clave comun y corriente (obtenida mediante un keylogger en un ciber) yo podria saber la cantidad de dinero que manejas, donde/cuando/como lo gastas, donde trabajas, si tienes hijos y donde los llevas a pasear el fin de semana, etc. luego (si manejas mucho dinero) con esa informacion (podria hacer mucho mas dan~o que una simple transaccion bancaria... por ejemplo, robar las cosas de tu departamento o casa, robar tu auto, secuestrar a alguien de tu familia, etc. Bueno, este es otro tipo de ataque, totalmente diferente de los anteriores, y para el cual el tipo de solución será obviamente distinto. Eso no quiere decir que los otros mecanismos no sean válidos para cubrir los otros problemas. Para el caso que planteas, creo que una posible solución sería que el sitio web del banco desplegara un cierto número de recientes ingresos en el sitio. Así el usuario puede ver si las fechas/horas corresponden o no. Si el banco fuera más sofisticado podría ver si hay patrones en las direcciones IP del usuario dependiendo de la hora y día de la semana (por ej. entre las 9 y las 7 te conectas de la oficina y siempre vienes de la misma IP, en cambio de las 8 en adelante y los fines de semana te conectas de tal bloque que pertenece al ISP de tu casa); o incluso, si te conectas a horas en que normalmente no lo haces. Esto último es exigido en la Circular 3400 de la SBIF, para evitar fraudes. -- Germán Póo-Caamaño Concepción - Chile http://www.calcifer.org/
Re: Seguridad en bancos (era Re: HA)
Germán Póo-Caamaño escribió: On Wed, 2009-09-02 at 15:27 -0400, Alvaro Herrera wrote: Para el caso que planteas, creo que una posible solución sería que el sitio web del banco desplegara un cierto número de recientes ingresos en el sitio. Así el usuario puede ver si las fechas/horas corresponden o no. Si el banco fuera más sofisticado podría ver si hay patrones en las direcciones IP del usuario dependiendo de la hora y día de la semana (por ej. entre las 9 y las 7 te conectas de la oficina y siempre vienes de la misma IP, en cambio de las 8 en adelante y los fines de semana te conectas de tal bloque que pertenece al ISP de tu casa); o incluso, si te conectas a horas en que normalmente no lo haces. Esto último es exigido en la Circular 3400 de la SBIF, para evitar fraudes. Hmm. Dice: 4.2. Prevención de fraudes. Los bancos deberán contar con sistemas o procedimientos que permitan identificar, evaluar, monitorear y detectar en el menor tiempo posible aquellas operaciones con patrones de fraude, de modo de marcar o abortar actividades u operaciones potencialmente fraudulentas, para lo cual deberán establecer y mantener, de acuerdo a la dinámica de los fraudes, patrones conocidos de estos y comportamientos que no estén asociados al cliente. Estos sistemas o mecanismos deberán permitir tener una vista integral y oportuna de las operaciones del cliente, del no cliente (por ejemplo en los intentos de acceso), de los puntos de acceso (por ejemplo direcciones IP, Cajero Automático u otros), hacer el seguimiento y correlacionar eventos y/o fraudes a objeto de detectar otros fraudes, puntos en que estos se cometen, modus operandi, y puntos de compromisos, entre otros. No puedo deducir de aquí que la vista integral y oportuna esté a disposición del cliente; da la impresión de que consideraron sólo que los sistemas o procedimientos tuvieran acceso a esa información. Está bueno que el banco tenga un sistema o procedimiento que haga estos chequeos en forma soterrada, pero sería bueno que me mostraran también la información para poder yo hacer mis propios cotejos. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre Pensar que el espectro que vemos es ilusorio no lo despoja de espanto, sólo le suma el nuevo terror de la locura (Perelandra, CSLewis)
Re: Seguridad en bancos (era Re: HA)
Hola! El Wed, Sep 02, 2009 at 05:34:33PM -0400, Ricardo Munoz escribio: [...] porque no irian al caso? de que te sirve tener el famoso digipass si por otro lado te pueden robar igual? Si bien tienes razón que es mejor mejorar el eslabón más débil primero, eso no quita que sea bueno mejorar cualquier eslabón. El sistema de claves generadas del Digipass (u otros) aumenta enormemente la seguridad de las transacciones informáticas, eso es un hecho. Y ha tenído otro efecto, la gente común se ha dado cuenta de la importancia de la seguridad, esto lo he notado al hablar con otras personas al respecto. conoces de algun caso de transacciones realizadas por tereceros (via web) *antes* de implementado lo del digipass? conoces de casos despues de implementado el digipass? han bajado los casos? sin estadisticas a mano es dificil saber acerca de la utilidad del aparatito. Claro que sería muy bueno contar con este tipo de estadísticas, pero sospecho que los bancos no estan dispuestos a entregarlas, por lo que tenemos que conformarnos con educarnos para tener conductas seguras. Daniel.
Re: Seguridad en bancos (era Re: HA)
Hola! El Wed, Sep 02, 2009 at 02:12:25PM -0400, Leonardo San Martin escribio: 2009/9/2 Rodrigo Gutiérrez Torres rodrigogutierreztor...@gmail.com Acabo de hacer esa prueba con mi aparatito del T-Banc: escribí el número y, en cuanto cambió, presioné Enter. No me aceptó la clave y tuve que reingresar por la actual. Al menos en mi caso, los relojes andan como reloj :). Con la tecnología de hoy día, un reloj electrónico no se atrasa/adelanta fácilmente. Deben pasar unos cuantos miles de años para obtener milésimas de segundos de desfase, ergo era de esperar el resultado de tu prueba. Mmm..., ¡ojalá fueran tan precisos! :-) Un reloj de cuarzo de precisión (calibrado de fábrica) puede llegar a variar unos 30 segundos al año (aprox. 1ppm). Más precisión que esa requiere compensar según la temperatura ambiente de manera continua, con lo que puedes llegar hasta 3 segundos al año (aprox. 0.1ppm). El problema es que al envejecer, la frecuencia varia de maneras que no son predecibles. Lo que hacen los aparatitos de claves es que el servidor aprende el desface del aparato cada vez que lo utilizas, y predice el estado del reloj interno al momento de verificar la clave. Y el aparatito se deshabilita luego de unos años para que debas cambiarlo por uno nuevo calibrado. En el servidor utilizas una fuente de reloj más precisa, por ejemplo un receptor de GPS o un reloj esclavo compensado por NTP. Daniel.
