Obtener la hora del servidor en un cliente windows

Con respecto a lo que Alfredo comenta, me hizó pensar un poco, sí necesitas
seguridad, creo que lo que Alfredo comenta cobra mucho sentido, en todo
caso
deberías proporcionar un webservice que devuelva los datos en xml, y que
también
te permita actualizar datos, para que el SQL server no quede expuesto a
ningún tipo de ataque, ni interno ni externo, a menos claro los que se
hagan desde el propio servidor donde está instalado el sql server :).

En un ambiente corporátivo, creo que lo más común, es el tener una
seguridad alta,
y la mejor forma es no exponer lo que no debemos exponer :)

así que me parece que Alfredo tiene la razón en esto en casi la totalidad
:)

perdón por este rollo tan largo :P

Saludos.

En Sun, 15 Apr 2007 17:28:07 -0600, Alfredo Novoa
escribió:

On 15 Apr 2007 13:10:24 -0700, "Diego Jancic"
wrote:

Los servidores SQL son para eso.

No, definitivamente es un error de seguridad en muchisimos casos
exponer el servidor SQL en algun lugar (internet o toda la red) si son
necesarios solamente para ver la hora.

Error de seguridad no es, pero si que sería un poco excesivo instalar
un SGBD SQL solo para ver la hora. Pero Victor decía que ya lo estaba
usando para su aplicación.

El servidor SQL puede no estar
expuesto para ser accedido solamente desde una aplicacion web o un
terminal server que corre en la misma maquina.

Cierto, aunque no es el caso de Victor, y eso no quita que los
servidores SQL deban de estar preparados para exponerlos en la red.

Los servidores SQL no son para publicarse abiertamente,

¡Anda que no!

Menudo disparate.

y en caso de
que exista una aplicacion windows funcionando a travez de internet (al
estilo un mensajero instantaneo, por ejemplo) lo mejor seria realizar
un servicio en el servidor que provea solo la informacion necesaria.

¿Y por qué?

¿Por que el SGBD es tan malo que no te fías de él?

¿O por que no te sientes capaz de programarlo correctamente?

Los SGBD SQL tienen que programarse para exponer solo la información
necesaria para cada usuario. En caso contrario si que sería un error
de seguridad. Imagínate que un "bug" de un Web Service pueda borrar la
contabilidad de la empresa.

Si creas un servicio que acepte consultas SQL, entonces tu servicio
será el nuevo servidor SQL. Y si no acepta SQL o algo por el estilo,
entonces ya no será muy apropiado para trabajar con aplicaciones de
bases de datos mínimamente complejas.

Yo dudo que microsoft haya publicado un Sql server donde tiene toda la
informacion de los contactos de MSN Messenger a internet, asi que no
digas que los servidores SQL son para eso.

Non sequitur, y de los gordos.

Messenger no es una aplicación de bases de datos. Las necesidades de
gestión de datos que tiene un cliente Messenger son mínimas y además
necesita un servidor de mensajería de todas formas.

Que Microsoft no de acceso público al SGBD que controla la base de
datos de usuarios de Messenger no quiere decir que los SGBD SQL no
sirvan para estar conectados a la red. Es obvio.


Saludos

Http://fox.desdeguate.com

Hola Jorge,

On Mon, 16 Apr 2007 13:04:33 -0600, Jorge_Mota
wrote:

deberías proporcionar un webservice que devuelva los datos en xml, y que
también
te permita actualizar datos, para que el SQL server no quede expuesto a
ningún tipo de ataque, ni interno ni externo

Pero entonces el que queda expuesto a los ataques es el Web Service.

Si se supone que usamos un SGBD seguro, de calidad industrial que ha
sido probado y depurado durante años por miles o millones de personas,
entonces por lógica no debería de ser menos seguro que un Web Service
casero que acabamos de hacer.

¿Para que perder el tiempo entonces creando un Web Service que no
aporta ningún valor?

Por otra parte XML es una de las peores formas de intercambiar datos
que han existido.


Saludos

claro, pero lo expongo como una alternativa, no me detuve a pensar en lo
que es realmente seguro, más bien, en que sí queremos en realidad seguro,
no nos tenemos que detener en lo que nos dan, más bien en lo que podemos
hacer :)

o algo así :P, pero sí discrepo contigo con lo de xml en un tanto :) pero
no soy muy conocedor del tema, así que en eso no opino.


Saludos.

En Mon, 16 Apr 2007 15:52:32 -0600, Alfredo Novoa
escribió:

Hola Jorge,

On Mon, 16 Apr 2007 13:04:33 -0600, Jorge_Mota
wrote:

deberías proporcionar un webservice que devuelva los datos en xml, y que
también
te permita actualizar datos, para que el SQL server no quede expuesto a
ningún tipo de ataque, ni interno ni externo

Pero entonces el que queda expuesto a los ataques es el Web Service.

Si se supone que usamos un SGBD seguro, de calidad industrial que ha
sido probado y depurado durante años por miles o millones de personas,
entonces por lógica no debería de ser menos seguro que un Web Service
casero que acabamos de hacer.

¿Para que perder el tiempo entonces creando un Web Service que no
aporta ningún valor?

Por otra parte XML es una de las peores formas de intercambiar datos
que han existido.


Saludos

Http://fox.desdeguate.com

Exponer un MSSQL server sobre internet no es la mejor de las ideas, es
exponerlo a ataques de denegción de servicio y potenciales riesgos de robo
de información.

Si te atacan con exito un mssql seguramente eso afectara amuchas
aplicaciones las expuestas sobre internet y las internas.

La protección de los datos al exponer un sql sobre internet no tiene que ver
con la calidad del motor, tiene que ver con que el administrado, el bendito
DBA tenga conocimientos en buenas prácticas y seguridad.

Tal como vos decis un web service escrito por un programador inexperto es
mas factible a ser vulnerado que un sql server, pero tambien es cierto que
el riesgo potencial de daño es menor, el atacante no tiene total acceso al
servidor de datos si te encuentra una falla en el ws. ( aunque
potencialmente es posible )

Pero bueno, esta puede llagar a ser una discución sin fin.

Solo un punto de vista.

Saludos


Daniel A. Calvin
Cooperator Team Member
http://www.cooperator.com.ar
Microsoft Certified Professional



"Alfredo Novoa" escribió en el mensaje
news:

Hola Jorge,

On Mon, 16 Apr 2007 13:04:33 -0600, Jorge_Mota
wrote:

deberías proporcionar un webservice que devuelva los datos en xml, y que
también
te permita actualizar datos, para que el SQL server no quede expuesto a
ningún tipo de ataque, ni interno ni externo

Pero entonces el que queda expuesto a los ataques es el Web Service.

Si se supone que usamos un SGBD seguro, de calidad industrial que ha
sido probado y depurado durante años por miles o millones de personas,
entonces por lógica no debería de ser menos seguro que un Web Service
casero que acabamos de hacer.

¿Para que perder el tiempo entonces creando un Web Service que no
aporta ningún valor?

Por otra parte XML es una de las peores formas de intercambiar datos
que han existido.


Saludos

On Mon, 16 Apr 2007 20:52:42 -0300, "Daniel A. Calvin - Cooperator
Team" wrote:

Si te atacan con exito un mssql seguramente eso afectara amuchas
aplicaciones las expuestas sobre internet y las internas.

Depende del éxito del ataque, si entran a una cuenta con pocos
privilegios no podrán hacer muchas cosas. Y las bases de datos
internas no tienen por que estar en el mismo servidor que las de las
aplicaciones expuestas en internet.

La protección de los datos al exponer un sql sobre internet no tiene que ver
con la calidad del motor, tiene que ver con que el administrado, el bendito
DBA tenga conocimientos en buenas prácticas y seguridad.

Tiene que ver con las dos cosas, y si el DBA no sabe hacer su trabajo
entonces habría que despedirlo.

Tal como vos decis un web service escrito por un programador inexperto es
mas factible a ser vulnerado que un sql server, pero tambien es cierto que
el riesgo potencial de daño es menor, el atacante no tiene total acceso al
servidor de datos si te encuentra una falla en el ws. ( aunque
potencialmente es posible )

Y el atacante tampoco tiene acceso total al SGBD si encuentra una
clave de un usuario limitado.

Por ejemplo podríamos impedir que alguien se conecte como
administrador desde internet y muchas cosas más para aumentar la
seguridad sin tener que gastar un montón de tiempo en escribir Web
Services que también pueden ser vulnerables.

Por ejemplo .NET Remoting me parece poco seguro, no creo que me
costase mucho trabajo colapsar a un servidor que lo use.


Saludos