| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] XCP Xen Cloud Control System ver 0.3 released!
On 2010-05-25, at 3:15 PM, "Iustin Pop" <iusty@xxxxxxxxx> wrote:
On Tue, May 25, 2010 at 10:04:26AM -0400, Vern Burke wrote:
I only do static IP assignments on the VMs. I have no idea how you'd
stop a VM from running a DHCP server from outside the VM (not that I
can imagine why anyone would want to do that anyways). The best
answer I've found for a lot of shennanigans is a zero tolerance
policy in the terms of service (do it and you're gone, period).
From http://en.wikipedia.org/wiki/DHCP: "DHCP uses the same two
ports assigned
by IANA for BOOTP: 67/udp for sending data to the server, and 68/udp
for data
to the client."
You could simply filter packets on port 67/udp towards the VM, so it
doesn't
see the requests, and on port 68/udp from the VM, so it's not able
to reply.
regards,
iustin
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
The original question was that a VM's IP is configured by a DHCP
server and the concern was that they did not want a rogue DHCP server
to cause problems. So if the solution is to use iptables, you can not
just block udp ports, but you would have to have pass rules from the
legitate IP addresses. Using ebtables may also help for link-layer
protocols.
It's always good practice to know the communications and data flows in
your environment. Testing for rogue servers doing dhcp is a good idea,
especially with wireless and vm environments. Passing data to an
unexpected default gateway would not be good so making sure no one is
passing themselves off as the default gateway is another step.
Frank
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home