Como aislar una VM de la red local

Iniciado por Schaiden, 17 Agosto 2017, 00:33 AM

0 Miembros y 1 Visitante están viendo este tema.

Schaiden

Muy buenas! Estaba viendo algunos conceptos relacionadas con la seguridad y el hardening. Uno de ellos es el aislamiento, es decir, aislar cada servicio en una diferente màquina virtual. Por ejemplo, si quiero contar con servicios de SMTP y HTTP, pondría Apachee/nginx en una VM y el servidor SMTP en otra VM... Ahora, lo que yo quiero lograr es que desde la VM no pueda escanear los otros host de la red, incluyendo al host sobre el que corre la VM y otras PCs que pueda haber en la misma red. Lo que hice para intentar lograr esto fue dejar configurada la VM con NAT. Mi red sería la 192.168.0.0/24, el host sobre el que tengo la VM serìa 192.168.0.100, y la VM configurada a travès de NAT tiene una IP que comienza con 10.x.x.x. Yo desde la VM con IP 10.x.x.x probé hacerle ping a 192.168.0.100 (la pc sobre la que corre la VM), y tambien escanearlo con nmap, y pude comunicarme con los puertos abiertos a nivel de LAN, y tambien obtuve las respuestas del ICMP... Tambien escaneando la red: nmap 192.168.0.0/24 -sP, puedo ver la direcciòn del router (192.168.0.1), y otras PCs fisicas de mi red. Me gustaría poder evitar esto. Es decir, que si estoy en la VM 10.x.x.x y quiera escanear la red 192.168.0.0/24 no obtenga ninguna respusta. Hoy por hoy estoy experimentando en mi propia red con VirtualBox desde Windows. El dia de mañana si tengo que administrar un servidor supongo q utilizaria Linux con kvm o xen. Y me gustaría lograr ésta aislamiento, asi si por ejemplo, el servidor web tiene una vulnerabilidad, que sea incapaz de acceder a los equipos de la red local para hacer pivoting, ataques MITM, tener acceso al SMB de los Windows de la red, etc... Espero haberme explicado bien. Saludos y gracias de antemano!

engel lex

Aislar los servicios sobre vm requiere mucho hardware ya que levantas un sistema operativo completo para un servicio, es como diseñar un edificio de 5 pisos para una sola oficina, el aislamiento usualmente se hace por medio de usuarios, chroot, y otros sistemas

Igual para aislar tienes que colocar tu vm tal cual vienes haciendo, obviamente podrás escanear el rango de la red de tu pc, porque pertenece al rango de dominio externo.. es decir, es como si escaneadas 8.0.0.0/24 , sin embargo ni desde red ni internet se podrá escanear tus vm, ya que edtan detrás de un nat
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.

Schaiden

#2
Muchas gracias engel lex por la ayuda! Perdón por todo lo que voy a escribir, pero me gustarìa saber la opinión de alguien que esté hace tiempo con la seguridad, sobre lo que creo que sería una configuración segura. Mira, lo que yo quería utilizar para aislar los servicios originalmente era LXC (containers), pero cuando lo quise combinar con SELinux noté que SELinux aparentemente estaba deshabilitado en cada container, lo cual me llevo a pensar que necesitaría utilizar varias VM por cada servicio y emplear SELinux en cada VM. Después de leer un poco ésto:

https://major.io/2014/04/21/launch-secure-lxc-containers-on-fedora-20-using-selinux-and-svirt/

noté que a través de libvirt se pueden utilizar las dos cosas (LXC y SELinux) perfectamente en armonía (todavía tendría que leer bien la documentación para entender bien como trabaja libvirt). Entonces con LXC podríamos tener todo tipo de aislamiento (filesystem, networks namespaces (se podrìa configurar NAT, como bien decis engel lex, para que no me puedan escanear desde afuera), y asignar bien los recursos a cada container). chroot por si solo no me convence ya que solo sirve para aislar filesystems. Entonces al usar LXC y no VM no tendríamos que desperdiciar tantos recursos para correr el kernel en cada VM (con un kernel nos alcanza para todo). Después tendría que ver bien donde implementar el firewall y el IDS, es decir, si utilizar snort/iptables en la máquina host, o sobre cada container por separado.

Por otra parte, como vos lo decis engel lex, noto que no se podría evitar un escaneo desde 10.x.x.x (supongamos que es la IP del container con apache que utiliza NAT), a la red 192.168.0.0/24, ya que pertenece al rango de dominio externo.

Repasemos un poco todo ésto. Hagamos de cuenta que tengo mi máquina host con ip 192.168.0.100, donde iran todos los containers. Por un lado tengo un container con un apache, supongamos que el container utiliza NAT y tiene IP 10.x.x.1. Por otra parte tenemos otro container con un server SMTP, tmb con NAT, y con IP 10.x.x.2.

En caso que el atacante vulnerara el servidor web, de todas maneras no podría tener acceso al container con SMTP ya que está a través de NAT. Pero si podría tener acceso a 192.168.0.100 y a todos los servicios disponibles para la red 192.168.0.0/24. Si alguno de los servicios fuera vulnerable, supongo que desde el container podrìa tomar control del host, y una vez aca, ya podría detener el container con SMTP, o hacer muchas cosas peores. Tendía que ver como configurar bien iptables para evitar que desde un container pueda tener acceso a los servicios del host. De todas formas supongo que lo correcto sería no tener NINGÚN servicio sobre el host 192.168.0.100.

Finalmente, y con motivos de administración supongo que en cada container debería incluir un servidor SSH muy bien configurado, con buenas contraseñas, tal vez implementando un port knocking, entre otras cosas. Entonces nuestros containers quedarían asi:

container 1:   servidor web (Apache) + servidor SSH
container 2:   servidor SMTP + servidor SSH

Y si incluyera por ejemplo FTP, agregaría:

container 3:    servidor FTP + servidor SSH


Bueno me gustaría saber que piensan sobre todo ésto, ya que uno por ahí lee y entiende algunas cosas pero puede estar entendiendo mal algo, o incluso al llevarlo a la práctica es como un mundo nuevo al de la teoría. Saludos y gracias!

engel lex

uff largo....
si es preferible el uso de contenedores, porque no te obliga a virtualizar hardware (es el problema con la vm más allá de tener que cargar el kernel)

CitarPero si podría tener acceso a 192.168.0.100

iptables, todo lo que vaya para 192.168.0.0/16 se bloquea, excepto el gateway...

CitarFinalmente, y con motivos de administración supongo que en cada container debería incluir un servidor SSH muy bien configurado, con buenas contraseñas, tal vez implementando un port knocking

port knocking?
en ssh con desactivar el acceso a usuario root y limitarlo a un usuario personalizado hiciste ya más de la mitad del trabajo de seguridad, porque tienen que dar con la conbiación user:pass a ciegas para ambos...

Citarcontainer 3:    servidor FTP + servidor SSH

yo no agregaría ftp, hoy dia no hay basicamente utilidades para ese protocolo, si quisieras acceder a archivos, está https o ssh (scp)...

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.