![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Or, Pull Model is bad, M'Kay?
Should you have occasion to design a system to manage the configurations of a large number of computers or networking devices, you will realize a number of things quickly:
However, that second desire, that the clients pull from the server, puts the server at a risk that the client (or something claiming to be a valid client) will attack it. This is no fun. In particular, it leads to you wanting to allow protocols with notoriously weak security models, such as TFTP and DHCP, direct untrammeled access to your centralized server. The one with the keys to the kingdom. The one where your admins will be helpfully setting the standard passwords that can get into everything, because there are only so many passwords that people can keep track of before they start printing up little cards for their wallet that list all of the passwords for the secure systems back at the office [Ed's note: That's a bad thing].
So what to do? Push instead of pull. Have the out of the box config on the client be just smart enough that it can allow the server to connect to it [Ed's note: There are more sophisticated refinements that one can make to this, but that would be a much longer article]. If someone hacks the central server itself, than own the network, but you bought that farm when you decided to do centralized management (and presumably you decided to do centralized management because you have a lot of systems to manage and want them all to behave predictably). The centralized server can get into the clients and hand them configuration information, which they may or may not respect, but the server itself is no longer at risk from all of the things that it's managing.
And that's a good thing.
Should you have occasion to design a system to manage the configurations of a large number of computers or networking devices, you will realize a number of things quickly:
- You can make mistakes really quickly. If someone (including one of your administrators) puts bogus data into the system, the system itself can misconfigure a large number of the systems under management in very little time.
- You will want for the hosts/devices under management to pull their configurations from the central server, because this allows you to configure more of the systems, including system binaries, applications, user data, etc. It's also less work, involves more use of existing off-the-shelf software without additional revision, etc.
- The centralized server will end up having the keys to the kingdom. You will want to distribute system binaries and user credential data from the central server to the clients, in which case you now have a single system that can be used to horribly break your network (if someone puts bogus data into it by accident) or very, very efficiently attack it (if someone puts bogus data into it on purpose).
However, that second desire, that the clients pull from the server, puts the server at a risk that the client (or something claiming to be a valid client) will attack it. This is no fun. In particular, it leads to you wanting to allow protocols with notoriously weak security models, such as TFTP and DHCP, direct untrammeled access to your centralized server. The one with the keys to the kingdom. The one where your admins will be helpfully setting the standard passwords that can get into everything, because there are only so many passwords that people can keep track of before they start printing up little cards for their wallet that list all of the passwords for the secure systems back at the office [Ed's note: That's a bad thing].
So what to do? Push instead of pull. Have the out of the box config on the client be just smart enough that it can allow the server to connect to it [Ed's note: There are more sophisticated refinements that one can make to this, but that would be a much longer article]. If someone hacks the central server itself, than own the network, but you bought that farm when you decided to do centralized management (and presumably you decided to do centralized management because you have a lot of systems to manage and want them all to behave predictably). The centralized server can get into the clients and hand them configuration information, which they may or may not respect, but the server itself is no longer at risk from all of the things that it's managing.
And that's a good thing.
