-------- Original Message --------
Subject: Re: Virtualization Networking
From: Warren Young <wyml@xxxxxxxxxxx>
Date: Wed, September 28, 2016 1:19 pm
To: CentOS mailing list <centos@xxxxxxxxxx>
On Sep 28, 2016, at 9:43 AM, <tdukes@xxxxxxxxxxxxxxxxxxx>
<tdukes@xxxxxxxxxxxxxxxxxxx> wrote:
>
> The first one, I created in my / file system but didn't really have the
> space so I deleted it.
One of the primary advantages of VMs over real machines is that you can
pause them, move them, and then restart them, with the VM guest OS not
realizing that anything has happened.
Some virtual machine management systems even automate this, letting you
move an active VM without any downtime at all.
> The second one, I created in /home/kvm, but deleted it as well when I
> couldn't access it FROM the internet.
That’s actually the main reason to use NAT over bridged networking: to
*prevent* outsiders from connecting into the VM guest. It’s a good
thing for exactly the same reason your home internet service’s
router/gateway’s NAT is a good thing.
While it is possible to drill a hole back through the VM’s NAT layer
into the guest using port mapping rules, that amounts to double NAT,
which adds an unnecessary amount of complexity.
If all of the threats to the VM guest are outside the LAN’s border
gateway, it’s simpler to use bridged networking, and set up the port
forwarding rules on the LAN border gateway.
Beyond that general advice, you escape anything CentOS-specific, so you
need to take the problem up elsewhere, such as https://portforward.com/
> I want to be able to access this VM from the internet.
Once the VM is set to use port forwarding and a static IP, you can
forward port 22 to the Internet.
I recommend that the port forwarding rule expose the internal port 22 as
some random value on the outside. This will cut down on a lot of script
kiddie spam in your logs. Some will decry this as “security through
obscurity,” but that’s bogus. Obscurity is not a bad thing in
itself. The problem comes when obscurity is your *only* security.
That’s not the case with SSH.
I don’t recommend forwarding any other ports to the Internet, if you
can possibly get away with it. SSH can do its own port forwarding, which
reduces your VM’s attack surface from the Internet. With SSH acting as
a poor-man’s VPN, an attacker would have to break SSH before they can
get into any of your internal VM’s other services.
Alternately, you could set up a VPN, and then you wouldn’t need to
mess with port forwarding, either at the LAN border or via SSH.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
It appears I am confused. I thought a VM could be accessible with all
services like the host machine.
Thanks
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
