Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
usuario para el dominio y uno local.

Gracias


On 19 jun, 17:34, f <usua...***ejemplo.net> wrote:
> Paco B escribió:
> Aunque supongo que no se podria logear en casa
>
> > con el mismo user del dominio y que tubieran acceso a internet con la
> > misma configuracion que la que tienen en el dominio de la empresa,
> > esto seria lo mejor, porque los usuarios de estos portatiles querran
> > iniciar sesion siempre con la misma cuenta (por tener el mismo
> > escritorio en casa y en la empresa, que me los conozco ;-) ).
>
> Sí podrán. Aunque es posible que tengan que seleccionar "máquina local"
> en vez de dominio al logearse. Además, hay una política que creo que por
> defecto permite 10 accesos consecutivos al sistema "off line". Deberán
> volver al dominio de vez en cuando y logearse on-line para que todo esté
> en orden, o bien cambias la política, que no es lo más adecuado. Piensa
> en esto con tiempo si se van a llevar los portátiles de vacaciones, por
> ejemplo, porque _no habría solución_ más que darles por teléfono la
> contraseña de administrador local.
>
> f.

Paco B escribió:
> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
> usuario para el dominio y uno local.
>

No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
política que limita el número de accesos off-line.

f.

Paco B escribió:
> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
> usuario para el dominio y uno local.
>

No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
política que limita el número de accesos off-line.

f.

Paco B escribió:
> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
> usuario para el dominio y uno local.
>

No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
política que limita el número de accesos off-line.

f.

Hola Paco, a ver si te respondo ahora con más tiempo que a ayer (y con más
claridad).

Puedes hacer que los usuarios del dominio se conecten por WAN al dominio
cuando no están en la empresa. Por fijar ideas, supongamos que:

+ tu red es 192.168.1.0/24
+ un portatil, cuando se conecta en la red interna, tierne IPs 192.168.1.10
+ para trabajar, el usuario del portátil debe acceder a los equipos:
- servidor FTP: 192.168.1.100
- servidor Web: 192.168.1.101
- servidor de correo: 192.168.1.102
+ la direccion IP publica de tu red es 80.70.60.50

Tus usuarios móviles, para conectarse a la red de la empresa, deberán
hacerlo
por la IP pública (80.70.60.50), que es la IP pública del router (la IP
privada
del mismo es la puerta de enlace que configuras en los NICs de tus hosts).

Asi que, tu usuario portatil, configura su tarjeta de red (NIC) para
conectarse a la
IP 80.70.60.50 por WAN, y surge este problema: cuando tu router recibe la
petición de conexión a un servicio (http, smtp, pop3, ftp...) ¿cómo sabe a
que host
interno tiene que dirigir la comunicación? La solución es NAT (Network
Address Traslation:
traduccion de direcciones de red). Son unas tablas que debes configurar en
tu router
y que tienen esta forma:

Servicio Host Puerto
http 192.168.1.101 1080
smtp 192.168.1.102 1023
ftp 192.168.1.100 1021
(nota: los puertos internos no tienen por qué ser los puertos standar)

Asi, cuando el router recibe en su IP pública un intento de conexion al
puerto 80
(puerto standar para web) sabe que debe dirigir esa peticion al host
192.168.1.101
por el puerto (no estandar 1080). Y deberá ser el servidor web (que puede
formar parte
de un dominio o no) quien se encargue de autentificar al usuario remoto.

Esto sería lo primero... está claro no? Pero ahora vienen los problemas
específicos
que implican los usuarios remotos:

1.- date cuenta de que el tráfico WAN, asi sin mas, se va a producir sin
ninguna protección,
es decir, cualquier host intermedio con una interfaz de red en modo
promiscuo, va a poder
captar los nombres de usuario y contraseñas que utilicen los usuarios
remotos, amén de
los archivos que circulen entre ellos y tu red. Los archivos en todo caso
pueden protegerse
encriptándolos con una utilidad como PGP. Pero... ¿cómo proteger las
credenciales de inicio
de sesión?

+ Una solución sería configurar los servidores para que utilicen solo
conexiones seguras
(distintas de las conexiones a los puertos estandar), de modo que tanto las
credenciales
de autentificacion como el intercambio de archivos, van a tener lugar a
través de un protocolo
encriptado (TLS, SSH, ...). Esta es una solución.

+ Otra solución es utilizar una conexión WAN por túnel VPN. En este caso, el
túnel protegido
sólo llega hasta tu puerta de enlace (la IP pública del router) ya que al
encriptarse las cabeceras
de los paquetes IP hacen que se vuelvan incompatibles con NAT porque...
¿como sabe el router
que un paquete tiene que dirigirlo al servidor web si no puede ver la
información de cabecera, al
encriptada por el protocolo de tunneling?. La solución a esto es que
deberías tener un servidor
de acceso conectado a tu router, donde terminaría el tunel VPN, y él
dirigiría el tráfico a los hosts
internos y se encargaría de la autentificación de los usuarios remotos.
Además, estas soluciones VPN
pueden establecerse configurándolas por software, hardware o contratándolas
a un operador de
comunicaciones.

Pero las implicaciones de seguridad no terminan ahí, porque:

+ ¿debemos proteger también el tráfico desde la puerta de enlace (router) a
los servidores internos?
+ ¿qué ocurriría si al usuario remoto le roban el portátil, como
garantizamos que el ladrón no
pueda entrar en tu red hasta la cocina haciándose pasar por el usuario
legítimo?
(la solución a esto pueden ser los sistemas de alarma/antirobo; los sistemas
de autentificación
basados en DOS de estos factores: "algo que tienes", "algo que eres", "algo
que sabes"; o la implementacion
de certificados digitales).
+ ¿cómo aseguramos el software que los usuarios remotos puedan instalar en
sus equipos, para
que no estén troyanizados con un keylogger o un analizador de protocolos
(sniffer) y roben los
documentos de tu empresa?
+ ¿qué política establecemos respecto a los puertos WiFi y BlueTooth de los
equipos portátiles,
que también pueden ser atacados para robar los documentos de tu empresa
(visita www.trifinite.org).
+ ¿cómo aseguramos que otros usuarios del portátil no instalen
(voluntariamente o no) otros software
espia?.
+ ¿como aseguramos que no se compromete la seguridad de esos equipos cuando
el usuario los lleve
a un servicio técnico. o porque no instale las actualizaciones y parches de
seguridad necesarios?

Luego, habría que tener en cuenta si tu red tiene un aarquitectura
multiplataforma (hosts windows y linux,
porque algunos de estos problemas se complican con nuevos desafíos debidos
a la interoperabilidad).

Como ves, todo esto es un mundo... Se puede hacer que tus trabajadores
puedan conectarse
remotamente a los servicios de tu red, pero aparecen toda una nueva clase de
problemas de seguridad.

Espero haber sido más claro ahora :-)

Saludos,
Pablo.





"Paco B" <pacoberu***gmail.com> escribió en el mensaje
news:e6f8d1f5-c27f-465c-a200-c0ebd0f576b3***g16g2000pri.googlegroups.com...
Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
usuario para el dominio y uno local.

Gracias


On 19 jun, 17:34, f <usua...***ejemplo.net> wrote:
> Paco B escribió:
> Aunque supongo que no se podria logear en casa
>
> > con el mismo user del dominio y que tubieran acceso a internet con la
> > misma configuracion que la que tienen en el dominio de la empresa,
> > esto seria lo mejor, porque los usuarios de estos portatiles querran
> > iniciar sesion siempre con la misma cuenta (por tener el mismo
> > escritorio en casa y en la empresa, que me los conozco ;-) ).
>
> Sí podrán. Aunque es posible que tengan que seleccionar "máquina local"
> en vez de dominio al logearse. Además, hay una política que creo que por
> defecto permite 10 accesos consecutivos al sistema "off line". Deberán
> volver al dominio de vez en cuando y logearse on-line para que todo esté
> en orden, o bien cambias la política, que no es lo más adecuado. Piensa
> en esto con tiempo si se van a llevar los portátiles de vacaciones, por
> ejemplo, porque _no habría solución_ más que darles por teléfono la
> contraseña de administrador local.
>
> f.

Hola Paco, a ver si te respondo ahora con más tiempo que a ayer (y con más
claridad).

Puedes hacer que los usuarios del dominio se conecten por WAN al dominio
cuando no están en la empresa. Por fijar ideas, supongamos que:

+ tu red es 192.168.1.0/24
+ un portatil, cuando se conecta en la red interna, tierne IPs 192.168.1.10
+ para trabajar, el usuario del portátil debe acceder a los equipos:
- servidor FTP: 192.168.1.100
- servidor Web: 192.168.1.101
- servidor de correo: 192.168.1.102
+ la direccion IP publica de tu red es 80.70.60.50

Tus usuarios móviles, para conectarse a la red de la empresa, deberán
hacerlo
por la IP pública (80.70.60.50), que es la IP pública del router (la IP
privada
del mismo es la puerta de enlace que configuras en los NICs de tus hosts).

Asi que, tu usuario portatil, configura su tarjeta de red (NIC) para
conectarse a la
IP 80.70.60.50 por WAN, y surge este problema: cuando tu router recibe la
petición de conexión a un servicio (http, smtp, pop3, ftp...) ¿cómo sabe a
que host
interno tiene que dirigir la comunicación? La solución es NAT (Network
Address Traslation:
traduccion de direcciones de red). Son unas tablas que debes configurar en
tu router
y que tienen esta forma:

Servicio Host Puerto
http 192.168.1.101 1080
smtp 192.168.1.102 1023
ftp 192.168.1.100 1021
(nota: los puertos internos no tienen por qué ser los puertos standar)

Asi, cuando el router recibe en su IP pública un intento de conexion al
puerto 80
(puerto standar para web) sabe que debe dirigir esa peticion al host
192.168.1.101
por el puerto (no estandar 1080). Y deberá ser el servidor web (que puede
formar parte
de un dominio o no) quien se encargue de autentificar al usuario remoto.

Esto sería lo primero... está claro no? Pero ahora vienen los problemas
específicos
que implican los usuarios remotos:

1.- date cuenta de que el tráfico WAN, asi sin mas, se va a producir sin
ninguna protección,
es decir, cualquier host intermedio con una interfaz de red en modo
promiscuo, va a poder
captar los nombres de usuario y contraseñas que utilicen los usuarios
remotos, amén de
los archivos que circulen entre ellos y tu red. Los archivos en todo caso
pueden protegerse
encriptándolos con una utilidad como PGP. Pero... ¿cómo proteger las
credenciales de inicio
de sesión?

+ Una solución sería configurar los servidores para que utilicen solo
conexiones seguras
(distintas de las conexiones a los puertos estandar), de modo que tanto las
credenciales
de autentificacion como el intercambio de archivos, van a tener lugar a
través de un protocolo
encriptado (TLS, SSH, ...). Esta es una solución.

+ Otra solución es utilizar una conexión WAN por túnel VPN. En este caso, el
túnel protegido
sólo llega hasta tu puerta de enlace (la IP pública del router) ya que al
encriptarse las cabeceras
de los paquetes IP hacen que se vuelvan incompatibles con NAT porque...
¿como sabe el router
que un paquete tiene que dirigirlo al servidor web si no puede ver la
información de cabecera, al
encriptada por el protocolo de tunneling?. La solución a esto es que
deberías tener un servidor
de acceso conectado a tu router, donde terminaría el tunel VPN, y él
dirigiría el tráfico a los hosts
internos y se encargaría de la autentificación de los usuarios remotos.
Además, estas soluciones VPN
pueden establecerse configurándolas por software, hardware o contratándolas
a un operador de
comunicaciones.

Pero las implicaciones de seguridad no terminan ahí, porque:

+ ¿debemos proteger también el tráfico desde la puerta de enlace (router) a
los servidores internos?
+ ¿qué ocurriría si al usuario remoto le roban el portátil, como
garantizamos que el ladrón no
pueda entrar en tu red hasta la cocina haciándose pasar por el usuario
legítimo?
(la solución a esto pueden ser los sistemas de alarma/antirobo; los sistemas
de autentificación
basados en DOS de estos factores: "algo que tienes", "algo que eres", "algo
que sabes"; o la implementacion
de certificados digitales).
+ ¿cómo aseguramos el software que los usuarios remotos puedan instalar en
sus equipos, para
que no estén troyanizados con un keylogger o un analizador de protocolos
(sniffer) y roben los
documentos de tu empresa?
+ ¿qué política establecemos respecto a los puertos WiFi y BlueTooth de los
equipos portátiles,
que también pueden ser atacados para robar los documentos de tu empresa
(visita www.trifinite.org).
+ ¿cómo aseguramos que otros usuarios del portátil no instalen
(voluntariamente o no) otros software
espia?.
+ ¿como aseguramos que no se compromete la seguridad de esos equipos cuando
el usuario los lleve
a un servicio técnico. o porque no instale las actualizaciones y parches de
seguridad necesarios?

Luego, habría que tener en cuenta si tu red tiene un aarquitectura
multiplataforma (hosts windows y linux,
porque algunos de estos problemas se complican con nuevos desafíos debidos
a la interoperabilidad).

Como ves, todo esto es un mundo... Se puede hacer que tus trabajadores
puedan conectarse
remotamente a los servicios de tu red, pero aparecen toda una nueva clase de
problemas de seguridad.

Espero haber sido más claro ahora :-)

Saludos,
Pablo.





"Paco B" <pacoberu***gmail.com> escribió en el mensaje
news:e6f8d1f5-c27f-465c-a200-c0ebd0f576b3***g16g2000pri.googlegroups.com...
Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
usuario para el dominio y uno local.

Gracias


On 19 jun, 17:34, f <usua...***ejemplo.net> wrote:
> Paco B escribió:
> Aunque supongo que no se podria logear en casa
>
> > con el mismo user del dominio y que tubieran acceso a internet con la
> > misma configuracion que la que tienen en el dominio de la empresa,
> > esto seria lo mejor, porque los usuarios de estos portatiles querran
> > iniciar sesion siempre con la misma cuenta (por tener el mismo
> > escritorio en casa y en la empresa, que me los conozco ;-) ).
>
> Sí podrán. Aunque es posible que tengan que seleccionar "máquina local"
> en vez de dominio al logearse. Además, hay una política que creo que por
> defecto permite 10 accesos consecutivos al sistema "off line". Deberán
> volver al dominio de vez en cuando y logearse on-line para que todo esté
> en orden, o bien cambias la política, que no es lo más adecuado. Piensa
> en esto con tiempo si se van a llevar los portátiles de vacaciones, por
> ejemplo, porque _no habría solución_ más que darles por teléfono la
> contraseña de administrador local.
>
> f.

Hola Paco, a ver si te respondo ahora con más tiempo que a ayer (y con más
claridad).

Puedes hacer que los usuarios del dominio se conecten por WAN al dominio
cuando no están en la empresa. Por fijar ideas, supongamos que:

+ tu red es 192.168.1.0/24
+ un portatil, cuando se conecta en la red interna, tierne IPs 192.168.1.10
+ para trabajar, el usuario del portátil debe acceder a los equipos:
- servidor FTP: 192.168.1.100
- servidor Web: 192.168.1.101
- servidor de correo: 192.168.1.102
+ la direccion IP publica de tu red es 80.70.60.50

Tus usuarios móviles, para conectarse a la red de la empresa, deberán
hacerlo
por la IP pública (80.70.60.50), que es la IP pública del router (la IP
privada
del mismo es la puerta de enlace que configuras en los NICs de tus hosts).

Asi que, tu usuario portatil, configura su tarjeta de red (NIC) para
conectarse a la
IP 80.70.60.50 por WAN, y surge este problema: cuando tu router recibe la
petición de conexión a un servicio (http, smtp, pop3, ftp...) ¿cómo sabe a
que host
interno tiene que dirigir la comunicación? La solución es NAT (Network
Address Traslation:
traduccion de direcciones de red). Son unas tablas que debes configurar en
tu router
y que tienen esta forma:

Servicio Host Puerto
http 192.168.1.101 1080
smtp 192.168.1.102 1023
ftp 192.168.1.100 1021
(nota: los puertos internos no tienen por qué ser los puertos standar)

Asi, cuando el router recibe en su IP pública un intento de conexion al
puerto 80
(puerto standar para web) sabe que debe dirigir esa peticion al host
192.168.1.101
por el puerto (no estandar 1080). Y deberá ser el servidor web (que puede
formar parte
de un dominio o no) quien se encargue de autentificar al usuario remoto.

Esto sería lo primero... está claro no? Pero ahora vienen los problemas
específicos
que implican los usuarios remotos:

1.- date cuenta de que el tráfico WAN, asi sin mas, se va a producir sin
ninguna protección,
es decir, cualquier host intermedio con una interfaz de red en modo
promiscuo, va a poder
captar los nombres de usuario y contraseñas que utilicen los usuarios
remotos, amén de
los archivos que circulen entre ellos y tu red. Los archivos en todo caso
pueden protegerse
encriptándolos con una utilidad como PGP. Pero... ¿cómo proteger las
credenciales de inicio
de sesión?

+ Una solución sería configurar los servidores para que utilicen solo
conexiones seguras
(distintas de las conexiones a los puertos estandar), de modo que tanto las
credenciales
de autentificacion como el intercambio de archivos, van a tener lugar a
través de un protocolo
encriptado (TLS, SSH, ...). Esta es una solución.

+ Otra solución es utilizar una conexión WAN por túnel VPN. En este caso, el
túnel protegido
sólo llega hasta tu puerta de enlace (la IP pública del router) ya que al
encriptarse las cabeceras
de los paquetes IP hacen que se vuelvan incompatibles con NAT porque...
¿como sabe el router
que un paquete tiene que dirigirlo al servidor web si no puede ver la
información de cabecera, al
encriptada por el protocolo de tunneling?. La solución a esto es que
deberías tener un servidor
de acceso conectado a tu router, donde terminaría el tunel VPN, y él
dirigiría el tráfico a los hosts
internos y se encargaría de la autentificación de los usuarios remotos.
Además, estas soluciones VPN
pueden establecerse configurándolas por software, hardware o contratándolas
a un operador de
comunicaciones.

Pero las implicaciones de seguridad no terminan ahí, porque:

+ ¿debemos proteger también el tráfico desde la puerta de enlace (router) a
los servidores internos?
+ ¿qué ocurriría si al usuario remoto le roban el portátil, como
garantizamos que el ladrón no
pueda entrar en tu red hasta la cocina haciándose pasar por el usuario
legítimo?
(la solución a esto pueden ser los sistemas de alarma/antirobo; los sistemas
de autentificación
basados en DOS de estos factores: "algo que tienes", "algo que eres", "algo
que sabes"; o la implementacion
de certificados digitales).
+ ¿cómo aseguramos el software que los usuarios remotos puedan instalar en
sus equipos, para
que no estén troyanizados con un keylogger o un analizador de protocolos
(sniffer) y roben los
documentos de tu empresa?
+ ¿qué política establecemos respecto a los puertos WiFi y BlueTooth de los
equipos portátiles,
que también pueden ser atacados para robar los documentos de tu empresa
(visita www.trifinite.org).
+ ¿cómo aseguramos que otros usuarios del portátil no instalen
(voluntariamente o no) otros software
espia?.
+ ¿como aseguramos que no se compromete la seguridad de esos equipos cuando
el usuario los lleve
a un servicio técnico. o porque no instale las actualizaciones y parches de
seguridad necesarios?

Luego, habría que tener en cuenta si tu red tiene un aarquitectura
multiplataforma (hosts windows y linux,
porque algunos de estos problemas se complican con nuevos desafíos debidos
a la interoperabilidad).

Como ves, todo esto es un mundo... Se puede hacer que tus trabajadores
puedan conectarse
remotamente a los servicios de tu red, pero aparecen toda una nueva clase de
problemas de seguridad.

Espero haber sido más claro ahora :-)

Saludos,
Pablo.





"Paco B" <pacoberu***gmail.com> escribió en el mensaje
news:e6f8d1f5-c27f-465c-a200-c0ebd0f576b3***g16g2000pri.googlegroups.com...
Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
usuario para el dominio y uno local.

Gracias


On 19 jun, 17:34, f <usua...***ejemplo.net> wrote:
> Paco B escribió:
> Aunque supongo que no se podria logear en casa
>
> > con el mismo user del dominio y que tubieran acceso a internet con la
> > misma configuracion que la que tienen en el dominio de la empresa,
> > esto seria lo mejor, porque los usuarios de estos portatiles querran
> > iniciar sesion siempre con la misma cuenta (por tener el mismo
> > escritorio en casa y en la empresa, que me los conozco ;-) ).
>
> Sí podrán. Aunque es posible que tengan que seleccionar "máquina local"
> en vez de dominio al logearse. Además, hay una política que creo que por
> defecto permite 10 accesos consecutivos al sistema "off line". Deberán
> volver al dominio de vez en cuando y logearse on-line para que todo esté
> en orden, o bien cambias la política, que no es lo más adecuado. Piensa
> en esto con tiempo si se van a llevar los portátiles de vacaciones, por
> ejemplo, porque _no habría solución_ más que darles por teléfono la
> contraseña de administrador local.
>
> f.

Un apunte en mi explicación anterior:

los usuarios remotos configuran sus adaptadores de red (NICs) para
conectarse
a una conexión WAN (su proveedor de acceso a internet, por ejemplo) y
configuran
la IP públioca de tu red (80.70.60.50 en el ejemplo) en sus clientes (de
web, correo, ftp, etc...).

Supongo que estaba claro, pero por si acaso... :-))

Saludos,
Pablo Q.

"f" <usuario***ejemplo.net> escribió en el mensaje
news:g3eoc8$2vk$1***news.tornevall.net...
> Paco B escribió:
>> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
>> usuario para el dominio y uno local.
>>
>
> No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
> política que limita el número de accesos off-line.
>
> f.

Un apunte en mi explicación anterior:

los usuarios remotos configuran sus adaptadores de red (NICs) para
conectarse
a una conexión WAN (su proveedor de acceso a internet, por ejemplo) y
configuran
la IP públioca de tu red (80.70.60.50 en el ejemplo) en sus clientes (de
web, correo, ftp, etc...).

Supongo que estaba claro, pero por si acaso... :-))

Saludos,
Pablo Q.

"f" <usuario***ejemplo.net> escribió en el mensaje
news:g3eoc8$2vk$1***news.tornevall.net...
> Paco B escribió:
>> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
>> usuario para el dominio y uno local.
>>
>
> No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
> política que limita el número de accesos off-line.
>
> f.

Un apunte en mi explicación anterior:

los usuarios remotos configuran sus adaptadores de red (NICs) para
conectarse
a una conexión WAN (su proveedor de acceso a internet, por ejemplo) y
configuran
la IP públioca de tu red (80.70.60.50 en el ejemplo) en sus clientes (de
web, correo, ftp, etc...).

Supongo que estaba claro, pero por si acaso... :-))

Saludos,
Pablo Q.

"f" <usuario***ejemplo.net> escribió en el mensaje
news:g3eoc8$2vk$1***news.tornevall.net...
> Paco B escribió:
>> Mmm, bueno es saber eso, entonces no hay otra que que utilicen un
>> usuario para el dominio y uno local.
>>
>
> No, no es necesario. Puede ser el mismo, pero tendrás que cambiar la
> política que limita el número de accesos off-line.
>
> f.