Re: [Hackademy] Contramedidas SQL
Hola, no sé si he comprendido bien los detalles de tu problema de seguridad, pero a simple vista me parece que denyhosts configurado apropiadamente puede ser una solución muy eficiente y efectiva en tu caso: http://denyhosts.sourceforge.net/ Desde que lo uso los ataques de fuerza no tienen ninguna posibilidad en mis servidores. Un saludo El 14 de septiembre de 2010 06:55, Bodescu bode...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No digo que no le comprenda. Sé muy bien lo que montar una VPN implica, y del rendimiento del sistema, ni hablamos: Velocidades de pena para un servicio crítico... En fin... Lo que sugiero es que cuando uno dice que no, o que sí, debe argumentar, y no vale No, nunca o Sí siempre, porque yo lo valgo. El asunto está ya en estudio, de modo que, en principio, la consulta queda resuelta. Asias mutxas :D Un saludo, Bodescu El 13/09/2010 15:10, lasizoillo escribió: El día 12 de septiembre de 2010 21:32, Bodescu bode...@gmail.com escribió: Me gusta la solución sobre VPN... La estudiaré con calmita. El problema es que en su día la propuse, y mi jefe dijo NO! sin más explicación. Jefes, que quereis que os cuente... ¬¬ Hay muchas cosas por las que tu jefe los puede odiar: * Lentitud * Problemas a la hora de configurar los clientes (openvpn funciona con todo, pero no me preguntes que clase de magia negra hay que hacer en un cliente windows vista). * Interoperabilidad. No todas las soluciones funcionan en todos los sistemas operativos. Según lo que useis, y hay muchas opciones, puede ser un infierno. * Problemas de mantenimiento, cofiguración. Ejemplo: Te haces un tunnel GRE para juntar dos redes. Es una solución rápida y simple. Pero si no tienes en cuenta que el paquete contenido (cabecera y datos) ha de caber en el area de datos de otro paquete, acabas teniendo problemas enviando paquetes grandes (y solo con ellos). Este caso es simple (aunque puede dar dolores de cabeza), pero con un protocolo más complejo y encima encriptado, encontrar el error puede ponerse más dificil. El tunelizar puertos a través del ssh es una de las formas de tener el tunnel menos problemáticas que hay. Tener una VPN mola mucho, pero conseguir tenerla puede ser doloroso, el que vaya bien algo legendario. Lo bueno es que probar es barato. Se monta y si todo va bien se quita el acceso a la bb.dd. desde internet, y si no funciona solo has perdido algo de tiempo en la prueba. Seguramente tu jefe haya perdido el tiempo muchas veces y no le queden ganas de intentarlo otra vez. Pero si conseguis montarla te quitas un montón de mantenimiento (los ataques del día a día y que no hay que actualizar a toda velocidad cuando hay un ataque remoto, aparte del riesgo de que te entren con los que todavía no tienen parches). Espero haberte dado argumentos para convencer y comprender a tu jefe ;-) Un saludo: Javi -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPAD8ACgkQFj65y95iPXnTKACg6GyjLvbYeFwmoe2H5FUstMP5 sUMAoNFCt/N4uONwsBxLRhhnWnVwD4DL =I123 -END PGP SIGNATURE- ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
Re: [Hackademy] Contramedidas SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Es un gran apunte, gracias :) Aunque el problema se ha solucionado vía VPN. Un salaudo, Bodescu El 12/10/2010 11:14, Jorge Ibáñez escribió: Hola, no sé si he comprendido bien los detalles de tu problema de seguridad, pero a simple vista me parece que denyhosts configurado apropiadamente puede ser una solución muy eficiente y efectiva en tu caso: http://denyhosts.sourceforge.net/ Desde que lo uso los ataques de fuerza no tienen ninguna posibilidad en mis servidores. Un saludo El 14 de septiembre de 2010 06:55, Bodescu bode...@gmail.com mailto:bode...@gmail.com escribió: No digo que no le comprenda. Sé muy bien lo que montar una VPN implica, y del rendimiento del sistema, ni hablamos: Velocidades de pena para un servicio crítico... En fin... Lo que sugiero es que cuando uno dice que no, o que sí, debe argumentar, y no vale No, nunca o Sí siempre, porque yo lo valgo. El asunto está ya en estudio, de modo que, en principio, la consulta queda resuelta. Asias mutxas :D Un saludo, Bodescu El 13/09/2010 15:10, lasizoillo escribió: El día 12 de septiembre de 2010 21:32, Bodescu bode...@gmail.com mailto:bode...@gmail.com escribió: Me gusta la solución sobre VPN... La estudiaré con calmita. El problema es que en su día la propuse, y mi jefe dijo NO! sin más explicación. Jefes, que quereis que os cuente... ¬¬ Hay muchas cosas por las que tu jefe los puede odiar: * Lentitud * Problemas a la hora de configurar los clientes (openvpn funciona con todo, pero no me preguntes que clase de magia negra hay que hacer en un cliente windows vista). * Interoperabilidad. No todas las soluciones funcionan en todos los sistemas operativos. Según lo que useis, y hay muchas opciones, puede ser un infierno. * Problemas de mantenimiento, cofiguración. Ejemplo: Te haces un tunnel GRE para juntar dos redes. Es una solución rápida y simple. Pero si no tienes en cuenta que el paquete contenido (cabecera y datos) ha de caber en el area de datos de otro paquete, acabas teniendo problemas enviando paquetes grandes (y solo con ellos). Este caso es simple (aunque puede dar dolores de cabeza), pero con un protocolo más complejo y encima encriptado, encontrar el error puede ponerse más dificil. El tunelizar puertos a través del ssh es una de las formas de tener el tunnel menos problemáticas que hay. Tener una VPN mola mucho, pero conseguir tenerla puede ser doloroso, el que vaya bien algo legendario. Lo bueno es que probar es barato. Se monta y si todo va bien se quita el acceso a la bb.dd. desde internet, y si no funciona solo has perdido algo de tiempo en la prueba. Seguramente tu jefe haya perdido el tiempo muchas veces y no le queden ganas de intentarlo otra vez. Pero si conseguis montarla te quitas un montón de mantenimiento (los ataques del día a día y que no hay que actualizar a toda velocidad cuando hay un ataque remoto, aparte del riesgo de que te entren con los que todavía no tienen parches). Espero haberte dado argumentos para convencer y comprender a tu jefe ;-) Un saludo: Javi ___ Hackademy mailing list Hackademy@listas.sindominio.net mailto:Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0KRcACgkQFj65y95iPXnxwQCeMEYAzzrI0WH7TsAxEqeCzNRs iRYAnRBZw/cdRvBeWQ3OS5HSNSQk+o1K =uRdc -END PGP SIGNATURE- ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
Re: [Hackademy] Contramedidas SQL
El día 12 de septiembre de 2010 21:32, Bodescu bode...@gmail.com escribió: Me gusta la solución sobre VPN... La estudiaré con calmita. El problema es que en su día la propuse, y mi jefe dijo NO! sin más explicación. Jefes, que quereis que os cuente... ¬¬ Hay muchas cosas por las que tu jefe los puede odiar: * Lentitud * Problemas a la hora de configurar los clientes (openvpn funciona con todo, pero no me preguntes que clase de magia negra hay que hacer en un cliente windows vista). * Interoperabilidad. No todas las soluciones funcionan en todos los sistemas operativos. Según lo que useis, y hay muchas opciones, puede ser un infierno. * Problemas de mantenimiento, cofiguración. Ejemplo: Te haces un tunnel GRE para juntar dos redes. Es una solución rápida y simple. Pero si no tienes en cuenta que el paquete contenido (cabecera y datos) ha de caber en el area de datos de otro paquete, acabas teniendo problemas enviando paquetes grandes (y solo con ellos). Este caso es simple (aunque puede dar dolores de cabeza), pero con un protocolo más complejo y encima encriptado, encontrar el error puede ponerse más dificil. El tunelizar puertos a través del ssh es una de las formas de tener el tunnel menos problemáticas que hay. Tener una VPN mola mucho, pero conseguir tenerla puede ser doloroso, el que vaya bien algo legendario. Lo bueno es que probar es barato. Se monta y si todo va bien se quita el acceso a la bb.dd. desde internet, y si no funciona solo has perdido algo de tiempo en la prueba. Seguramente tu jefe haya perdido el tiempo muchas veces y no le queden ganas de intentarlo otra vez. Pero si conseguis montarla te quitas un montón de mantenimiento (los ataques del día a día y que no hay que actualizar a toda velocidad cuando hay un ataque remoto, aparte del riesgo de que te entren con los que todavía no tienen parches). Espero haberte dado argumentos para convencer y comprender a tu jefe ;-) Un saludo: Javi ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
Re: [Hackademy] Contramedidas SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No digo que no le comprenda. Sé muy bien lo que montar una VPN implica, y del rendimiento del sistema, ni hablamos: Velocidades de pena para un servicio crítico... En fin... Lo que sugiero es que cuando uno dice que no, o que sí, debe argumentar, y no vale No, nunca o Sí siempre, porque yo lo valgo. El asunto está ya en estudio, de modo que, en principio, la consulta queda resuelta. Asias mutxas :D Un saludo, Bodescu El 13/09/2010 15:10, lasizoillo escribió: El día 12 de septiembre de 2010 21:32, Bodescu bode...@gmail.com escribió: Me gusta la solución sobre VPN... La estudiaré con calmita. El problema es que en su día la propuse, y mi jefe dijo NO! sin más explicación. Jefes, que quereis que os cuente... ¬¬ Hay muchas cosas por las que tu jefe los puede odiar: * Lentitud * Problemas a la hora de configurar los clientes (openvpn funciona con todo, pero no me preguntes que clase de magia negra hay que hacer en un cliente windows vista). * Interoperabilidad. No todas las soluciones funcionan en todos los sistemas operativos. Según lo que useis, y hay muchas opciones, puede ser un infierno. * Problemas de mantenimiento, cofiguración. Ejemplo: Te haces un tunnel GRE para juntar dos redes. Es una solución rápida y simple. Pero si no tienes en cuenta que el paquete contenido (cabecera y datos) ha de caber en el area de datos de otro paquete, acabas teniendo problemas enviando paquetes grandes (y solo con ellos). Este caso es simple (aunque puede dar dolores de cabeza), pero con un protocolo más complejo y encima encriptado, encontrar el error puede ponerse más dificil. El tunelizar puertos a través del ssh es una de las formas de tener el tunnel menos problemáticas que hay. Tener una VPN mola mucho, pero conseguir tenerla puede ser doloroso, el que vaya bien algo legendario. Lo bueno es que probar es barato. Se monta y si todo va bien se quita el acceso a la bb.dd. desde internet, y si no funciona solo has perdido algo de tiempo en la prueba. Seguramente tu jefe haya perdido el tiempo muchas veces y no le queden ganas de intentarlo otra vez. Pero si conseguis montarla te quitas un montón de mantenimiento (los ataques del día a día y que no hay que actualizar a toda velocidad cuando hay un ataque remoto, aparte del riesgo de que te entren con los que todavía no tienen parches). Espero haberte dado argumentos para convencer y comprender a tu jefe ;-) Un saludo: Javi -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPAD8ACgkQFj65y95iPXnTKACg6GyjLvbYeFwmoe2H5FUstMP5 sUMAoNFCt/N4uONwsBxLRhhnWnVwD4DL =I123 -END PGP SIGNATURE- ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
[Hackademy] Contramedidas SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A ver, fieras, que os pongo en situación: Desde hace algún tiempo vengo sufriendo ataques de fuerza bruta, que acaban derivando en DoS casi siempre, sobre un servidor SQL 2005. Las contramedidas adoptadas son contraseña aleatoria de 20 caracteres, cambio de puerto bien conocido por otro, más bien alto, y despliegue de un cortafuegos de soft, que se revela claramente insuficiente y en breve será sustituido por un fire dedicado Dlink NetDefend. De todos modos me gustaría que me comenteis, si alguno sabe/ quiere/ puede, que otras contramedidas se pueden adoptar entre que despliego el DLink y no. Ya que estamos, si alguno conoce la serie NetDefend de Dlink, le quedaría muy agradecido si puede darme unas pautas generales acerca de la redirección de puertos y publicación de servidores en ese tipo de aparatos. Lo que veo en el manual, y en los foros oficiales de Dlink, está muy bien, pero es una info demasiado resumida como para que resulte todo lo útil que sería deseable. Todo vuestro, a ver qué se os ocurre :) Un saludo, Bodescu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyMj4gACgkQFj65y95iPXnXOgCgr7Sr8CCSpcftMcazxhZKUM+8 EYwAn3DgrorClc4/lRiRTzESrHgjVNA/ =5MIW -END PGP SIGNATURE- ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
Re: [Hackademy] Contramedidas SQL
El día 12 de septiembre de 2010 10:30, Bodescu bode...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A ver, fieras, que os pongo en situación: Desde hace algún tiempo vengo sufriendo ataques de fuerza bruta, que acaban derivando en DoS casi siempre, sobre un servidor SQL 2005. DoS es un término muy genérico. Qué es lo que produce los problemas: * ¿Agota el numero de conexiones a base de datos? * ¿Problemas porque te consumen demasiado ancho de banda? * ¿...? Ser más específico ayuda a plantear soluciones más específicas. Las contramedidas adoptadas son contraseña aleatoria de 20 caracteres, cambio de puerto bien conocido por otro, más bien alto, y despliegue de un cortafuegos de soft, que se revela claramente insuficiente y en breve será sustituido por un fire dedicado Dlink NetDefend. * La contraseña evitaría que consigan su objetivo * El cambio de puerto resultaría insuficiente si te realizan escaneo de puertos * Lo del cortafuegos de soft no se puede saber su utilidad si no hablas de su configuración. De todos modos me gustaría que me comenteis, si alguno sabe/ quiere/ puede, que otras contramedidas se pueden adoptar entre que despliego el DLink y no. Para evitar que te escaneen puertos, puedes hacer con scripting un servidor que escuche en el puerto anterior y posterior a la base de datos. Si alguien accede a uno de esos dos puertos le cortas el acceso en el firewall. Cudiadito al probar el script ;-) Mejor que hacer un cutre-IPS casero, puedes instalar openvpn o similares y dejar la base de datos accesible solo desde la red privada virtual. Con la red privada virtual tu podrías conectarte a la base de datos, pero desde internet no podrían hacerte el brute force. Ya que estamos, si alguno conoce la serie NetDefend de Dlink, le quedaría muy agradecido si puede darme unas pautas generales acerca de la redirección de puertos y publicación de servidores en ese tipo de aparatos. Lo que veo en el manual, y en los foros oficiales de Dlink, está muy bien, pero es una info demasiado resumida como para que resulte todo lo útil que sería deseable. No tengo ni idea de esos cacharros. Pero por lo que dice tiene varias funcionalidades útiles para tu problema: * IPS http://es.wikipedia.org/wiki/Sistema_de_Prevenci%C3%B3n_de_Intrusos * VPN Todo vuestro, a ver qué se os ocurre :) Primero montar la VPN y si no es posible miraria lo de hacer un cutre-ips a base de scripting para acabar con el problema mientras instalas el chisme serio de verdad. Un saludo: Javi ___ Hackademy mailing list Hackademy@listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackademy
