Date: Sat, 8 Aug 2020 17:14:36 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Mark Raynsford <list+org.freebsd.virtualization@io7m.com> Cc: freebsd-virtualization@freebsd.org Subject: Re: Restricting IP ranges for guests over tap devices Message-ID: <20200809001436.GK4213@funkthat.com> In-Reply-To: <20200801145144.7bf342d9@sunflower.int.arc7.info> References: <20200801145144.7bf342d9@sunflower.int.arc7.info>
next in thread | previous in thread | raw e-mail | index | archive | help
--iig7nzZQzi/oiJm2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Mark Raynsford via freebsd-virtualization wrote this message on Sat, Aug 01=
, 2020 at 14:51 +0000:
> Let's say I have a machine running a few dozen bhyve guests. Each bhyve
> guest gets its own tap device, and all of the tap devices are connected
> to a bridge.
>=20
> Everything works fine. I can write pf rules that control access between
> each guest, and between each guest and the world. I can't directly
> observe the IP addresses that the guests have assigned to the tap
> devices I gave them, but if I know the addresses beforehand, I can for
> example write pf rules that say things like:
>=20
> block log all
> pass in on tap23 proto tcp \
> from any to $guest_23_ip port ssh modulate state
>=20
> That then means that even if the guest is compromised and tries to bind
> a server to another address, the pf rules won't allow anyone else to
> actually connect to it.
>=20
> The good thing about this is also the bad thing about this; I have to
> write specific rules that say "only allow access to this specific IP
> via this specific tap device". Over dozens of guests, that can multiply
> to hundreds of laboriously maintained rules.
>=20
> Is there some more general way I can supply a mapping between tap
> devices and allowed addresses? Remember that pf can't see the guest
> addresses on the host sides of the tap devices, so I can't use the
> (device) syntax to expand to "the address of a NIC called 'device'".
>=20
> I can generate rule sets, but perhaps there's something "better"[0]? The
> documentation isn't suggesting much.
>=20
> [0] Better in the sense that, for example, a table is usually better
> than a massive list of macros. :)
Don't think there is anything better...
bridge does have sticky that binds the mac address to an interface, but
that doesn't deal w/ IP ARP.
One issue w/ this is how do you know the difference between one machine
that's been down for a long time, and an attacking machine that takes
over the down'd machine's IP address?
I assume that these addresses are assigned via DHCP server, otherwise
if you are launching the VM's w/ known static IP's, you could use
pf's anchor directive, and each start/stop of a VM, update the rule for
that tap's anchor.
--=20
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
--iig7nzZQzi/oiJm2
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJfLz/rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MEI1RTRGMTNDNzYyMDZDNjEyMDBCNjAy
MDVGMEIzM0REMDA2QURBAAoJECBfCzPdAGrazVYP/iiny6XQQdgJBmyde95I/NNe
ZYFVPRe+PW5a2683qqhDLnQy9LJb4j0yNAut13YM1wIc4IQjJGPhs/iPrQ5GelFi
86ti5epue+r42Ln82yURz/KCrsFa46UXmpgOc42N20zBq0OgvROPfPvuZEScS6iT
EDrET0Gt9PJjxMeipm84MADNv1IVrMfaA450T9US8FluH9xrLozu3of09Ml9/OqS
xMdAxgwj15fzsB8dSIqqlWpIGrYcNrUbsgDKRX5xhVXiO11wSegZMbfu/bQtWdcF
jAB0xD4bTlvOXHa7ACePau3plbKQ/CPy7S8VgkUJJjfWNx0BKTldb/pjaA0DCxht
xxfrYx/6WXA37Wdhg28jRL5i1CL7tESgloLe0Lyxri5ahSHhJYGzv/nJpdBf4W/G
84iAtryDXkNGhJq9vvvJ8d/qTmMREehg+abxdxrUDvOl3QkyxBiwhGBsrdsxf4Yz
g4XT7JG/UMy+miA06CufQqRhwt5RLuxxlqEmHTjF8DtRYLa7O2TRrZVysQ64VAWv
600amFEYMZq+8QUKjuXUOMKlszUdVNZN61pFOzYwvkAEkxuK/Yq+ssvj2BBcZDzE
yYA/R394zZ4S5IaLcXWwjCBwPuWqe0VR3cEplH4hRstJq90xVfwJ8iaUxlHQERW5
vzSWvLLVQa2r3yq/n2Pm
=4ATH
-----END PGP SIGNATURE-----
--iig7nzZQzi/oiJm2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200809001436.GK4213>