Re: Seguridad en bancos (era Re: HA)
El 04/09/09, Jaime Chereau jcher...@cl3k.com escribió: No ha podido matar el Visual Basic, menos a COBOL... Att. Jaime Chereau Ossa 2009/9/3 Marco González Luengo noquierou...@gmail.com El 3 de septiembre de 2009 08:02, Sebastián Veloso Varassvel...@sevelv.cl escribió: El 3 de septiembre de 2009 03:53, Marco González Luengo noquierou...@gmail.com escribió: El 03/09/09, Daniel Serpell dserp...@gmail.com escribió: 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. Disculpen un poco mi salida de tópico, pero hay algo que me queda dando vueltas de toda esta discusión, y tiene que ver con el dilema de las passwords a veces forzadamente básicas e inseguras se solicitan o asignan para estos sitios web y cajeros automáticos. Para mí es horriblemente injusto, incómodo e inseguro que, en mi caso, sea forzado a usar claves de 4 dígitos para ATM y el sitio web del banco. El cartón de bingo es prácticamente subutilizado en algunos bancos. La verdad preguntaría a quién debo matar por tal aberración, pero sería irme del tema. Por eso planteo ¿qué hay del forzar los malditos 4 dígitos? Eso responde a que los sistemas bancarios son arcaicos. Fueron diseñados en Cobol, y actualmente siguen funcionando de la misma manera. En su tiempo, no fue pensada quizas una solución mas avanzada de seguridad. Imaginate migrar o modificar un sistema completo bancario (la red bancaria nacional en realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada dia mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun funcionan ... (no se por cuanto mas) Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. Con su permiso, pero mi Desert Eagle y yo tenemos una cita. XP En realidad es porque me iba a pegar un tipo. ;) Y en cierta forma, digamos que tienes razón, pero el que funcione bien aún no implica que pueda ser así hasta el fin de los tiempos. Toda solución hoy será insegura y obsoleta mañana. De eso me dí cuenta cuando, por ejemplo, tuve que migrar mis páginas en HTML con tablas a XHTML con CSS y sin tablas. En HTML seguían funcionando, pero no era una solución buena a esas alturas. Lo que yo me pregunto es si acaso hay o no alternativas a los mentados programas COBOLísticos.
Coneccion entre ftp con bash
Antes de decir cualquiercosa, mis mas sinceras felicitaciones a Germán P. , yo al igual que él soy de Concepción, por lo que me alegro mucho más. Bueno tengo un script que me funciona bastante bien, para conectarme a un ftp: #! /bin/bash ftp -nd 192.168.xxx.xxx END quote USER $USER quote PASS $PASS binary En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Muchas gracias.
Re: Seguridad en bancos (era Re: HA)
Marco González Luengo escribió: El 3 de septiembre de 2009 08:02, Sebastián Veloso Varassvel...@sevelv.cl escribió: Eso responde a que los sistemas bancarios son arcaicos. Fueron diseñados en Cobol, y actualmente siguen funcionando de la misma manera. En su tiempo, no fue pensada quizas una solución mas avanzada de seguridad. Imaginate migrar o modificar un sistema completo bancario (la red bancaria nacional en realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada dia mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun funcionan ... (no se por cuanto mas) Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. Con su permiso, pero mi Desert Eagle y yo tenemos una cita. XP El tema es que el banco no tiene ningún incentivo para cambiarlo. Yo no creo que los bancos hayan hecho el cambio en los mecanismos de seguridad porque quisieran hacerlo, sino más bien porque la superintendencia los obligó. ¿Para qué iban a gastar millones en reconstruir los sistemas desde cero? -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J This is a foot just waiting to be shot(Andrew Dunstan)
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 10:20, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Marco González Luengo escribió: El 3 de septiembre de 2009 08:02, Sebastián Veloso Varassvel...@sevelv.cl escribió: Eso responde a que los sistemas bancarios son arcaicos. Fueron diseñados en Cobol, y actualmente siguen funcionando de la misma manera. En su tiempo, no fue pensada quizas una solución mas avanzada de seguridad. Imaginate migrar o modificar un sistema completo bancario (la red bancaria nacional en realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada dia mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun funcionan ... (no se por cuanto mas) Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. Con su permiso, pero mi Desert Eagle y yo tenemos una cita. XP El tema es que el banco no tiene ningún incentivo para cambiarlo. Yo no creo que los bancos hayan hecho el cambio en los mecanismos de seguridad porque quisieran hacerlo, sino más bien porque la superintendencia los obligó. ¿Para qué iban a gastar millones en reconstruir los sistemas desde cero? Exacto. El banco dice ¿Si funciona para que cambiarlo?. Es una plataforma estandar y cambiarla, seria un ataque convulsivo para un banco. Hasta me atreveria a decir que es mas vulnerable un sistema actual que uno arcaico que lleva mas de 25 años funcionando =), refiriendome no solo al acceso de informacion, sino estabilidad, funcionalidad. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J This is a foot just waiting to be shot(Andrew Dunstan)
Re: Coneccion entre ftp con bash
De: Juan Andres Ramirez jandresa...@gmail.com Para: lista linux linux@listas.inf.utfsm.cl Fecha: 04-09-2009 09:45 Asunto: Coneccion entre ftp con bash Enviado por: linux-boun...@listas.inf.utfsm.cl Antes de decir cualquiercosa, mis mas sinceras felicitaciones a Germán P. , yo al igual que él soy de Concepción, por lo que me alegro mucho más. Bueno tengo un script que me funciona bastante bien, para conectarme a un ftp: #! /bin/bash ftp -nd 192.168.xxx.xxx END quote USER $USER quote PASS $PASS binary En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Muchas gracias. Si puedes usar scp seria bastante sencillo. $scp u...@host1:filename1 u...@host2:filename2 Pero asumo que no puedes usar scp y tienes que hacerlo a traves de ftp, en dicho caso podrias probar si funciona esto: montar localmente (en tu ftp3) un directorio de la maquina remota donde quieres dejar los archivos (ftp2) y luego descargar en dicha carpeta desde ftp1. Saludos! PD: Felicidades a German = PD2: Ya no estoy en Conce, pero por otro lado podre ir a los beer-day aca en Santiago. -- Atte. Ricardo Utreras Estrella SIGMA S.A:
Re: Seguridad en bancos (era Re: HA)
El 3 de septiembre de 2009 23:58, Marco González Luengo noquierou...@gmail.com escribió: El 3 de septiembre de 2009 08:02, Sebastián Veloso Varassvel...@sevelv.cl escribió: [...] Eso responde a que los sistemas bancarios son arcaicos. Fueron diseñados en Cobol, y actualmente siguen funcionando de la misma manera. En su tiempo, no fue pensada quizas una solución mas avanzada de seguridad. Imaginate migrar o modificar un sistema completo bancario (la red bancaria nacional en realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada dia mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun funcionan ... (no se por cuanto mas) Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? respecto a que COBOL sea seguro o no, simplemente no aplica ya que los programas COBOL corren en un Mainframe con el cual se puede comunicar una aplicacion en Linux/Unix que a su vez ofrece las funcionalidades y datos mediante Webservices (por ejemplo en Java), los cuales a su vez son llamados por la interfaz de usuario (JSP, ASP, PHP, etc.). cada cosa en su lugar, y todos juntos pero no revueltos... ;) pd1. si manejas COBOL y sabes ingles tienes pega asegurada por muuucho tiempo. pd2. las animaciones en los cajeros es publicidad, esta ahi para que te endeudes mas, no para entretenerte! -- Ricardo Mun~oz A. http://www.tux.cl
Re: OT: Modelo de Router VPN point-to-point.
- Mensaje original - De: Andrés Ovalle Gahona aova...@debianchile.cl Para: Discusion de Linux en Castellano linux@listas.inf.utfsm.cl Enviados: Viernes, 4 de Septiembre 2009 0:50:43 GMT -04:00 Sudamérica – Región del Pacífico Asunto: Re: OT: Modelo de Router VPN point-to-point. El 4 de septiembre de 2009 00:20, Aldrin Martoq amar...@dcc.uchile.clescribió: 2009/9/3 Andrés Ovalle Gahona aova...@debianchile.cl: En realidad no toy buscando una solucion via software, ya que en donde se va instalar esto es en un colegio, y la disponibilidad de tener 2 servidores fijos solo para hacer un vpn no es una solucion optima. Si hubiera sido por usar un software claramente hubiera instalado pfsense, pero en este caso estoy buscando un hardware o un dispositivo que tenga ese particularidad, yo se que existen, y estoy buscando, pero una ayudadita nunca esta de mas :) Yo en lo personal estoy en contra de cualquier solucion WiFi: las encuentro con mucha latencia, demasiado lentas (de 10 a 100 veces, lo que es un montón!) y abiertas (incluso si la proteges con tu idea de VPN). Demasiada tecnología creo yo para algo que se soluciona de manera simple: dos cables UTP de 100 metros y un switch al medio, puede ser incluso uno barato. Otra opción es con cable coaxial, ese si llega sin problemas. Que alguien con real experiencia corrobore... http://aldrin.martoq.cl/ () Respecto de routers con soporte vpn ( IPSEC ) tengo experiencia en 2 marcas y modelos. Uno es el 3com OfficeConnect 3CR860-95 y Dlink DI804HV...ambos están mas que descontinuados... pero si consigues alguno de los 2, el 3com claramente se comporta muy bien. El Dlink a cierto nivel de carga tenia una pésima performance. Ahora, si decides extender a través de cable, te sugiero que lo hagas con FO ( que es mucho mas barato por estos días ) o con unos llamados extensores Ethernet. No recomiendo extender con 2 cables y un switch en medio, pero esa respuesta la puedes encontrar en internet :D Ojala te ayude. Saludos, -- Andrés Esteban Ovalle Gahona (kill-9) Ingeniero (E) Computación e Informática. Staff Debianchile.cl www.debianchile.cl Msn: aova...@gmail.com Blog: http://kill-9.debianchile.cl Movil: 09-5795880 Usuario Linux #456290 (counter.li.org)
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 10:56, Ricardo Munoz rmu...@tux.cl escribió: El 3 de septiembre de 2009 23:58, Marco González Luengo noquierou...@gmail.com escribió: El 3 de septiembre de 2009 08:02, Sebastián Veloso Varassvel...@sevelv.cl escribió: [...] Eso responde a que los sistemas bancarios son arcaicos. Fueron diseñados en Cobol, y actualmente siguen funcionando de la misma manera. En su tiempo, no fue pensada quizas una solución mas avanzada de seguridad. Imaginate migrar o modificar un sistema completo bancario (la red bancaria nacional en realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada dia mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun funcionan ... (no se por cuanto mas) Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. respecto a que COBOL sea seguro o no, simplemente no aplica ya que los programas COBOL corren en un Mainframe con el cual se puede comunicar una aplicacion en Linux/Unix que a su vez ofrece las funcionalidades y datos mediante Webservices (por ejemplo en Java), los cuales a su vez son llamados por la interfaz de usuario (JSP, ASP, PHP, etc.). Por eso pongo en duda que es mas seguro, si un sistema actual (que es conocido por muchos, accesible y cada dia vulnerable) o un sistema manejado por pocos, que lleva años funcionando. cada cosa en su lugar, y todos juntos pero no revueltos... ;) pd1. si manejas COBOL y sabes ingles tienes pega asegurada por muuucho tiempo. pd2. las animaciones en los cajeros es publicidad, esta ahi para que te endeudes mas, no para entretenerte! Sipues, le ponen cajeros bonitos, animaciones, flash, etc.. y hace la misma rutina de siempre : sacar y sacar dinero jejej -- Ricardo Mun~oz A. http://www.tux.cl
Re: Seguridad en bancos (era Re: HA)
Sebastián Veloso Varas escribió: El 4 de septiembre de 2009 10:56, Ricardo Munoz rmu...@tux.cl escribió: estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. Yo he escuchado de gente que ha escrito capas de abstracción ISAM sobre PostgreSQL para poder migrar aplicaciones COBOL desde el uso de archivos planos a una base de datos de verdad. (¿Conectorizar? ¿estás suscrito al suplemento de la RAE de García Márquez, o eres un japonés tratando de hacernos creer que hablas castellano nativamente? Te cuento que en castellano decimos conectar) -- Alvaro Herrera http://planet.postgresql.org/ Renaming ReiserFS to NinaFS is such an amazingly stupid suggestion, in so many ways, that it ought to qualify for some kind of award. Or perhaps we should name an award after it: the NinaFS award for outstanding crassness. (edmundo, http://lwn.net/Articles/203846/)
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 11:55, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: Sebastián Veloso Varas escribió: El 4 de septiembre de 2009 10:56, Ricardo Munoz rmu...@tux.cl escribió: estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. Yo he escuchado de gente que ha escrito capas de abstracción ISAM sobre PostgreSQL para poder migrar aplicaciones COBOL desde el uso de archivos planos a una base de datos de verdad. (¿Conectorizar? ¿estás suscrito al suplemento de la RAE de García Márquez, o eres un japonés tratando de hacernos creer que hablas castellano nativamente? Te cuento que en castellano decimos conectar) Mis disculpas publicas. Terminos mal usados que se pegan (se ocupa harto en Redes y Comunicaciones, mal dicho o no jeje) -- Alvaro Herrera http://planet.postgresql.org/ Renaming ReiserFS to NinaFS is such an amazingly stupid suggestion, in so many ways, that it ought to qualify for some kind of award. Or perhaps we should name an award after it: the NinaFS award for outstanding crassness. (edmundo, http://lwn.net/Articles/203846/)
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 11:44, Sebastián Veloso Varas svel...@sevelv.clescribió: El 4 de septiembre de 2009 10:56, Ricardo Munoz rmu...@tux.cl escribió: El 3 de septiembre de 2009 23:58, Marco González Luengo noquierou...@gmail.com escribió: [...] Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. existe. y para Oracle, DB2, etc. aunque eso de actual tampoco es tan asi, la primera version de Oracle se libero el an~o 1979. tambien puedes ejecutar programas en lenguaje C dentro de Mainframe, Java, y hasta codigo PHP. Mainframe es como la Matrix... puedes correr de todo y con recursos ilimitados (pagas por lo que usas)... cloud computing es el mismo concepto pero con acceso a traves de Internet. en todo caso, hay versiones de COBOL para Desktop (con ventanitas y botones) y tambien COBOL para Web. respecto a que COBOL sea seguro o no, simplemente no aplica ya que los programas COBOL corren en un Mainframe con el cual se puede comunicar una aplicacion en Linux/Unix que a su vez ofrece las funcionalidades y datos mediante Webservices (por ejemplo en Java), los cuales a su vez son llamados por la interfaz de usuario (JSP, ASP, PHP, etc.). Por eso pongo en duda que es mas seguro, si un sistema actual (que es conocido por muchos, accesible y cada dia vulnerable) o un sistema manejado por pocos, que lleva años funcionando. ningun sistema es seguro por si solo. el tema de la seguridad da para mucho, de hecho hay certificaciones [1] donde debes manejar no solo la seguridad de las aplicaciones, sino la seguridad fisica, gestion de riesgos, legislacion, etc. en resumen, que usen COBOL para la manipulacion de los datos no tiene ninguna relacion con la tecnologia que usen para la interfaz Web que finalmente es la que esta mas expuesta desde afuera. pero se dice que el mayor riesgo no viene desde afuera sino esta adentro... [1] http://es.wikipedia.org/wiki/CISSP -- Ricardo Mun~oz A. http://www.tux.cl
Re: Coneccion entre ftp con bash
Te refieres a esto: http://en.wikipedia.org/wiki/File_eXchange_Protocol On Fri, 2009-09-04 at 09:39 -0400, Juan Andres Ramirez wrote: Antes de decir cualquiercosa, mis mas sinceras felicitaciones a Germán P. , yo al igual que él soy de Concepción, por lo que me alegro mucho más. Bueno tengo un script que me funciona bastante bien, para conectarme a un ftp: #! /bin/bash ftp -nd 192.168.xxx.xxx END quote USER $USER quote PASS $PASS binary En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Muchas gracias.
Re: Coneccion entre ftp con bash
2009/9/4 V00w michael.iba...@gmail.com: Te refieres a esto: http://en.wikipedia.org/wiki/File_eXchange_Protocol Eso me sirve, muchas gracias. On Fri, 2009-09-04 at 09:39 -0400, Juan Andres Ramirez wrote: Antes de decir cualquiercosa, mis mas sinceras felicitaciones a Germán P. , yo al igual que él soy de Concepción, por lo que me alegro mucho más. Bueno tengo un script que me funciona bastante bien, para conectarme a un ftp: #! /bin/bash ftp -nd 192.168.xxx.xxx END quote USER $USER quote PASS $PASS binary En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Muchas gracias.
Re: Coneccion entre ftp con bash
Juan Andres Ramirez escribió: Antes de decir cualquiercosa, mis mas sinceras felicitaciones a Germán P. , yo al igual que él soy de Concepción, por lo que me alegro mucho más. Bueno tengo un script que me funciona bastante bien, para conectarme a un ftp: #! /bin/bash ftp -nd 192.168.xxx.xxx END quote USER $USER quote PASS $PASS binary En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Muchas gracias. Respondiendo de memoria, ni idea si aún funciona con los servidores FTP más nuevos: server3 $ ftp ftp open ftp1 user: password: ftp proxy open ftp2 user: password: ftp proxy get archivo en ftp1 -- arch/sparc/kernel/unaligned.c: unaligned_panic(Impossible user unaligned trap.);
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 12:32, Ricardo Munozrmu...@tux.cl escribió: El 4 de septiembre de 2009 11:44, Sebastián Veloso Varas svel...@sevelv.clescribió: El 4 de septiembre de 2009 10:56, Ricardo Munoz rmu...@tux.cl escribió: El 3 de septiembre de 2009 23:58, Marco González Luengo noquierou...@gmail.com escribió: [...] Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no son capaces de pagar lo que sea necesario para migrar los sistemas a algo más seguro. estan confundidos. COBOL se sigue usando no porque sea dificil (o caro) de migrar sino porque cumple con su tarea, ademas de existir mucho codigo y conocimiento heredado. para que cambiar algo que funciona? Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. existe. y para Oracle, DB2, etc. aunque eso de actual tampoco es tan asi, la primera version de Oracle se libero el an~o 1979. tambien puedes ejecutar programas en lenguaje C dentro de Mainframe, Java, y hasta codigo PHP. Mainframe es como la Matrix... puedes correr de todo y con recursos ilimitados (pagas por lo que usas)... cloud computing es el mismo concepto pero con acceso a traves de Internet. en todo caso, hay versiones de COBOL para Desktop (con ventanitas y botones) y tambien COBOL para Web. respecto a que COBOL sea seguro o no, simplemente no aplica ya que los programas COBOL corren en un Mainframe con el cual se puede comunicar una aplicacion en Linux/Unix que a su vez ofrece las funcionalidades y datos mediante Webservices (por ejemplo en Java), los cuales a su vez son llamados por la interfaz de usuario (JSP, ASP, PHP, etc.). Por eso pongo en duda que es mas seguro, si un sistema actual (que es conocido por muchos, accesible y cada dia vulnerable) o un sistema manejado por pocos, que lleva años funcionando. ningun sistema es seguro por si solo. el tema de la seguridad da para mucho, de hecho hay certificaciones [1] donde debes manejar no solo la seguridad de las aplicaciones, sino la seguridad fisica, gestion de riesgos, legislacion, etc. en resumen, que usen COBOL para la manipulacion de los datos no tiene ninguna relacion con la tecnologia que usen para la interfaz Web que finalmente es la que esta mas expuesta desde afuera. pero se dice que el mayor riesgo no viene desde afuera sino esta adentro... [1] http://es.wikipedia.org/wiki/CISSP -- Ricardo Mun~oz A. http://www.tux.cl Efectivamente. El mantener un sistema viejo y con limitaciones (arbitrarias o del mismo sistema) hace que con el tiempo estas cosas se jodan solas (la vejez mató al hombre y no la pistola que estaba a su lado). Ahora, por ejemplo, la limitante de tener claves de 4 dígitos tanto en ATMs como en Web hace que 1 clave sea débil y la otra no lo sea tanto (independiente del cartón de bingo o el llaverito numeral), por lo que basta con apoderarse de la clave difícil para tener más del 50% de posibilidades de acceso. Los 4 dígitos son absorbibles por el cajero (ya hemos visto cómo se hace eso), por ingeniería social (dame tu clave del cajero o el patito muere) o por fuerza bruta (dame la clave o te saco la...). He visto que el campo de contraseña de los ATMs tienen hasta 8 o 10 dígitos para poder insertar. Si tratas de poner una contraseña de, digamos, 6 dígitos, después no puedes entrar al ATM. ¿Por qué? Porque su clave *no es* de 4 dígitos. Podemos reforzar cuanto queramos las transacciones web, pero las transacciones por ATM (que están ligadas a web, querámoslo o no) son la pata más coja de la mesa.
Re: Coneccion entre ftp con bash
El 4 de septiembre de 2009 09:39, Juan Andres Ramirezjandresa...@gmail.com escribió: ... En resumen entro a este ftp y puedo hacer todas las cosas que se pueden hacer en un ftp. Lo que necesito es mover datos del ftp1 al ftp2 desde una 3 máquina con linux, sin pasar los archivos por la 3 maquina. Puedes hacer fxp utilizando lftp. Tienes que configurarlo antes: lftp :~ set ftp:ssl-force true lftp :~ set ftp:use-fxp true uso: open -p [Source Port] [Source Address] user [Source Username] [Source Password] mirror [Source Directory] ftp://[Destination Username]:[Destination passwo...@[destination Address]:[Destination Port]/[Destination Directory] puedes hacer un script también y lo llamas con lftp -f script -- Saludos! Antonio Sebastián Sallés M. UCENTUX / IEEE UCENTRAL CHILE [cel] +56-9-8-281 71 61 [lab] +56-2-582 69 31
Re: Felicitaciones a Germán!
El 3 de septiembre de 2009 09:26, Carlos (casep) Sepulvedaca...@fedoraproject.org escribió: Estimados: Para los que aún no se han enterado, esta semana finalizaron las elecciones de la junta directiva para la Gnome Foundation. Los resultados acá http://foundation.gnome.org/vote/results.php?election_id=13 Desde acá mis felicitaciones a Germán Poo-Caamaño, uno de los nuevos directores de la Gnome Foundation. Mis más sinceras felicitaciones a Germán Póo. -- Saludos! Antonio Sebastián Sallés M. UCENTUX / IEEE UCENTRAL CHILE [cel] +56-9-8-281 71 61 [lab] +56-2-582 69 31
Resultados para Encuentro Linux
Hola listeros, supuestamente hoy deberia salir el resultado de los trabajos aceptados para el encuentro linux, pero en el sitio no aparece nada, se postergo la fecha de entrega de resultados? atte Victor
Re: Seguridad en bancos (era Re: HA)
2009/9/4 Alvaro Herrera alvhe...@alvh.no-ip.org: Sebastián Veloso Varas escribió: Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. Yo he escuchado de gente que ha escrito capas de abstracción ISAM sobre PostgreSQL para poder migrar aplicaciones COBOL desde el uso de archivos planos a una base de datos de verdad. Cuidado que por lo visto desconocen y/o nunca han programado en COBOL corriendo sobre un Mainframe con todos los servicios que este provee... La plataforma es mucho mas robusta que la lectura de archivos picante que la mayoría programamos! A mi me deja mucho mas tranquilo el backend en COBOL que la página web de mi banco hecho con la última tecnología cayéndose a pedazos a cada rato; considerando lo complejo que son los sistemas modernos y que muy poca gente realmente entiende por qué son las cosas de tal o cual manera. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Felicitaciones a Germán!
2009/9/3 Alvaro Herrera alvhe...@alvh.no-ip.org: Carlos (casep) Sepulveda escribió: Estimados: Para los que aún no se han enterado, esta semana finalizaron las elecciones de la junta directiva para la Gnome Foundation. Los resultados acá http://foundation.gnome.org/vote/results.php?election_id=13 Desde acá mis felicitaciones a Germán Poo-Caamaño, uno de los nuevos directores de la Gnome Foundation. Muchas felicitaciones, abrazos, chelas, etc etc. Lo curioso es que la elección fue en 2009 spring, o sea hace como unos cuatro meses ... - elecciones hace 4 meses.. - felicitaciones hoy... - celebración (al estilo gnome http://vimeo.com/6431785) en octubre !! :D salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
Re: Seguridad en bancos (era Re: HA)
2009/9/4 Marco González Luengo noquierou...@gmail.com: Ahora, por ejemplo, la limitante de tener claves de 4 dígitos tanto en ATMs como en Web[...] Supongo que mi banco es avanzado. Sólo me obligaron a usar 6 dígitos para la web (yo quería usar unos 10, por lo menos! Tiempo después como proveedor de ese banco me tocó estar en una reunión con un (supuesto) experto de seguridad dentro del banco. Después de tratar los temas correspondientes a la reunión se me ocurrió preguntarle cual era la verdadera razón de tener una limitación tan poco acorde con los tiempos. La respuesta: Bueno, da lo mismo, si la clave te la van a jaquear igual. Como siempre intento ser optimista, tengo la esperanza de que (a) me haya estado tirando por el desvío con una mala broma o (b) no sea realmente uno de los expertos de seguridad... -- Leo Soto M. http://blog.leosoto.com
Re: OT: Modelo de Router VPN point-to-point.
2009/9/4 Alvaro Patricio Avello Mendez aave...@servinco.cl: Ahora, si decides extender a través de cable, te sugiero que lo hagas con FO ( que es mucho mas barato por estos días ) o con unos llamados extensores Ethernet. No recomiendo extender con 2 cables y un switch en medio, pero esa respuesta la puedes encontrar en internet :D Hmm... no la puedo encontrar. ¿Cuál es la respuesta? Estoy seguro de que funciona, es lo mismo que poner un bridge; pero puedo estar equivocado. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Seguridad en bancos (era Re: HA)
El 4 de septiembre de 2009 14:46, Aldrin Martoq amar...@dcc.uchile.clescribió: 2009/9/4 Alvaro Herrera alvhe...@alvh.no-ip.org: Sebastián Veloso Varas escribió: Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. Yo he escuchado de gente que ha escrito capas de abstracción ISAM sobre PostgreSQL para poder migrar aplicaciones COBOL desde el uso de archivos planos a una base de datos de verdad. Cuidado que por lo visto desconocen y/o nunca han programado en COBOL corriendo sobre un Mainframe con todos los servicios que este provee... La plataforma es mucho mas robusta que la lectura de archivos picante que la mayoría programamos! No, la verdad no tengo conocimiento del tema. Pero esa es la idea, conocer e interactuar con gente ideas y conceptos nuevos ;) A mi me deja mucho mas tranquilo el backend en COBOL que la página web de mi banco hecho con la última tecnología cayéndose a pedazos a cada rato; considerando lo complejo que son los sistemas modernos y que muy poca gente realmente entiende por qué son las cosas de tal o cual manera. Es cierto. Muy cierto!. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Seguridad en bancos (era Re: HA)
2009/9/4 Alvaro Herrera alvhe...@alvh.no-ip.org Aldrin Martoq escribió: 2009/9/4 Alvaro Herrera alvhe...@alvh.no-ip.org: Sebastián Veloso Varas escribió: Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan sus archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto que va amarrado al codigo y al modelamiento propio. Alguien me corrije si existe forma de conectorizar directamente Cobol sobre un DB actual. Yo he escuchado de gente que ha escrito capas de abstracción ISAM sobre PostgreSQL para poder migrar aplicaciones COBOL desde el uso de archivos planos a una base de datos de verdad. Cuidado que por lo visto desconocen y/o nunca han programado en COBOL corriendo sobre un Mainframe con todos los servicios que este provee... La plataforma es mucho mas robusta que la lectura de archivos picante que la mayoría programamos! Bueno, yo claramente no tengo tu experiencia con mainframes, pero la persona (dije gente arriba, pero en realidad es EL caso) que lo hizo sí que la tiene. De hecho esta persona tuvo varios problemas, porque el sistema de archivos planos era muy robusto y MUY rápido, y tuvo que conseguir varios parches a PostgreSQL para que pudiera hacerle la competencia en algunos casos. Pero una vez que eso estuvo parchado, el rendimiento del todo era mucho mejor, y además tenía la ventaja que ahora tenía una capa SQL encima de los datos, sobre la cual hacer cosas que COBOL no permitía. Acá existe un proyecto de migración de la antigua plataforma (Unix NCR) toda programada en MFCobol a la nueva plataforma (RHEL) AcuCobol, que permite realizar SQL directamente sobre archivos indexados (AcuODBC). Solo basta el conector (driver ODBC) que para nuestro caso basta que sea soportado por MS Windows. Entiendo que existen otros productos para conectar incluso desde AcuCobol hacia SQLServer, DB2 u Oracle (no se si habrá algo mas). Esta misma suite tiene productos para llevar los programas AcuCobol hacia Web y algo como VB (solo basta el runtime en los clientes). Todo esto acá funciona, cabe decir, ademas, que son productos fácilmente con 4 años de antiguedad. -- Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 World domination is proceeding according to plan(Andrew Morton) -- Saludos, Leonardo San Martín. Existen 10 tipos de personas: los que entienden binarios y los que no
Re: OT: Modelo de Router VPN point-to-point.
- Aldrin Martoq amar...@dcc.uchile.cl escribió: 2009/9/4 Alvaro Patricio Avello Mendez aave...@servinco.cl: Ahora, si decides extender a través de cable, te sugiero que lo hagas con FO ( que es mucho mas barato por estos días ) o con unos llamados extensores Ethernet. No recomiendo extender con 2 cables y un switch en medio, pero esa respuesta la puedes encontrar en internet :D Hmm... no la puedo encontrar. ¿Cuál es la respuesta? Hola Aldrinmotivos ? a) la degradación de la señal con la distancia...y bueno, no es tan obvio, pero este tipo de enlaces generalmente se efectúan en tramos al aire libre donde las condiciones no son de las mejores y donde cuesta encontrar donde conectar los switches..te imaginas instalar un enchufe en el techo de un edificio ? Otras opciones pasan por cambiar por switches que operan con FO que no son tan baratos...en fin..Si aplicamos KISS, un extensor de ethernet o FO es lo adecuado. Estoy seguro de que funciona, es lo mismo que poner un bridge; pero puedo estar equivocado. Claro que funciona ! , pero no es eficiente ;) -- Aldrin Martoq http://aldrin.martoq.cl/ Saludos !
Re: bonding y balanceo de carga (casi solucionado)
se instalaron tarjetas infiniband 40gbps y ahora drbd si anda bastante bien, pero la copia por scp como comentaba en un principio sigue dando 30MB/s lo que me parece curioso, alguien tiene alguna idea si centos tiene algun bloqueo o limitación ya que esto no pasa en otras distros corriendo en la misma máquina. On Mon, 2009-07-20 at 10:16 -0400, Aldrin Martoq wrote: 2009/7/20 Felipe Román Márquez from...@gmail.com: un poco más detallado. es para un cluster activo/pasivo que usa drbd y es vital para el rendimiento de esto el performance de la red. ya hice pruebas a los discos, locales y remotas, y todo lo sugerido en los post anteriores. con las mismas pruebas usando fedora 11 con un bonding modo 6 el performance es 3 veces lo que da en centos. si le sacaba un cable de una tarjeta de red bajaba a 60MB/ss aprox con 1 daba 30MB/s y con las 3 cercano a los 90-100MB/s Nones! tu problema no es que el balanceo no funciona, sino que no obtienes la velocidad esperada con 1 solo cable! Como referencia, una conexión gigabit da cerca de 100MiB/s; con 3 debieras obtener en teoría 300MiB/s. Insisto: aisla el problema asegurando que al menos ALGO funciona a la velocidad que esperas: conecta los servidores con un solo cable (sin bonding!) entre dos tarros (sin switchs!) con un programa que involucre solo cpu y red (el programa python que publiqué por ejemplo). Tienes los números de referencia: a si mismo, eran 750MiB/s; entre dos computadores conectados directamente via gigabit: 111MiB/s. Si no obtienes al menos 100MiB/s con esta configuración, es que algo anda mal y es lo primero que debes resolver. Si obtienes menos de 750MiB/s a localhost, es que algo peor esta pasando y también deberás resolver. Publica tus números acá. en centos con 1, 2, 3 o 4 tarjetas en bonding con la misma confing no da más que 30MB/s (en las mismas pruebas) bajé los modulos actualizados de intel y los instalé funciona la red pero el bonding sigue sin balancear carga. (cosa que como dije si funciona en fedora) el modulo igb y e1000e en fedora tiene una versión completamente distinta a las oficiales de intel y a las que vienen con centos 5.3, no pude portear los modulos de fedora a centos. Mi prueba fue entre un dell d820 (broadcom) y un macbook1,1 (marvell) ... Veamos como te va primero...
Re: Resultados para Encuentro Linux
El 04/09/09 14:56, Victor Quiroz escribió: Hola listeros, supuestamente hoy deberia salir el resultado de los trabajos aceptados para el encuentro linux, pero en el sitio no aparece nada, se postergo la fecha de entrega de resultados? Los resultados ya están. Estamos esperando que el profe HvB envíe las notificaciones antes de publicarlo. Saludos! ;) -- Renato Covarrubias Romerocounter.li.org #399677 rcovarru [at] alumnos.inf.utfsm.cl http://rnt.cl Estudiante Ingeniería Civil Informática, Casa Central, UTFSM. signature.asc Description: OpenPGP digital signature
