"Approve MAC Addresses"

[Wayne Workman]

I see the link to approve MAC addresses, but it approves all of them…

I don’t see a way to deny a MAC, or just approve some MACs.

[Wayne Workman]

Additionally, this same MAC address just keeps popping up for approval… I don’t know what’s going on with it. I’ve approved it 4 or 5 times now.

r3398 - Fedora 21 Server

[Wayne Workman]

Bump… how about eliminating “approve MAC addresses” completely?

The new client is secure - I feel it’s safe to rely on it. Why not have the FOG front-end just update the DB with whatever is reported from the new clients? I feel like “Approving” mac addresses over and over every time I image is silly.

[Tom Elliott]

I disagree. While the new client and server are much more secure communicatively speaking, it’s still one of those things I feel you should have interaction with. This is because dog is/can be much more than just an imaging platform. It’s also a useful element in inventory management. See if the Mac is pending it isn’t quite “belonging” to the host.

[Tom Elliott]

It can also be used to filter out potential spoofs. For example, the Additional and primary mac fields (unless otherwise specified) is how the service is handled for now. Basically, it tests any/all macs against all hosts in the system. If there’s a match, it continues to pass information to the host about what’s being sent. This is important, for example, in the case of Active directory.

If we just assumed all MACs were safe for the host it’s registering from, you would potentially be opening yourself up for attack. Not necessarily in a traditional sense.

For example, the most secure piece of information we want to protect, the Active Directory Password. Yes, I know you shouldn’t have admin rights on the user (create a new one as necessary) to allow FOG to register the host to the domain. However, this isn’t always practical. Whether by inexperience/knowledge, or because the setup was just done quick and dirty. That said, if all mac’s where automatically “approved” the potential arises that somebody could inject their own macs to a host. Because their host is no registered, they can see all the data sent from the server including the AD Password. (of course the new client doesn’t have this issue as readily, but still).

It’s these types of things we’re trying to help prevent as much as possible that we require you to approve the macs. If you are always going in and approving all macs, then I say shame on you, but to each their own. The mac’s can be approved by the individual MAC from the relevant host or hosts. The “green checkbox” that appears is the link on how to approve a single mac address. You can also approve all macs from the host as well.

It’s actually these security concerns that allowed us to have the FOG Client (New again) register the host if it was not already registered to the main FOG system. In olden times the client did register the host to the server if it wasn’t already done, but it also registered them as “approved”.

Main flaw, I think, in that approach is FOG is dependent upon a system being compatible to image/task a system. This is why the full register drops you into the init and you get asked all those questions, followed by a reboot if you wanted the system to image. If we only registered hosts through iPXE, the potential arises that a host is registered, and FOG recognizes it, but the init’s do not have the proper drivers to actually support imaging that device, so your system is stuck in a boot loop. Under the new client, the registration still happens, and the potential is still there that the registered through the client system is not compatible, but you can’t task the system until it is in an “approved” state.

Basically, we’re moving fog into an admin centric style system. The Administrator of the network/systems should know about any and all items being input especially when dealing with a host. If you’re registering through one of the registration/quick reg systems on the PXE menu, you already have a head start because there had to be a form of action performed to enable that reception of the task. So these full/quick registration methods are assumed to be “trusted”. Systems that are registered by the fog client is not automatically assumed trusted, because anybody can download the FOG Client installer and communicate to your fog server. By placing the system in a “pending” state, we keep the service from receiving unwarranted data. It also gives you and your admins a chance to verify the host indeed is valid for your network. The same principle for the MAC addresses.

Hopefully all this makes sense.

[Wayne Workman]

@Tom-Elliott biggest post ever…

So what happens if I DON’T approve a legit MAC?

[Tom Elliott]

If you don’t approve, it’s not used to associate to a host. So it will appear to the fog system, and you, that it is simply an invalid host.

[Junkhacker]

I would also like to point out the potential issues of a single MACaddress getting registered on multiple systems. that alone is a big reason to not auto-approve of all pending MACs. duplicate MACs can happen when a virtual network device is installed on an image, like with virtualbox, or you have plugged a usb NIC into multiple machines.