Client key generation seems a bit archaic, shouldn't it be some opt-in/acknowledgment system on the server side... I'd like ossec to issue certs or the keys automatically in the background. I point my client install to my ossec server, they exchange info, and in the admin interface I accept that client or deny, or accept and place in a group. Perhaps specifying the ossec server ip/fqdn then using a colon (or other separator) I put a name or ID of a group the client should be in. Seems so dated to have to generate these keys and copy them to the clients. I've not used 2.5 yet, does it have a silent install where I can put the key in via the command line for windows? (can it install via cli in M$?) I'd also like to reclaim the previous ID's used for inactive clients, should an old client get turned back on, reject until it's accepted in the admin interface even if the ID hasn't been reused. A client that hasn't connected in a week or some user configurable amount of time should be considered dead/stagnate. Perhaps the client install can also specify what IP/mask ossec should accept traffic from... if that is even a need for anyone anymore, don't most /8 or * this value when adding them anyway?
Showing a diff on a file's contents logistically sounds tough, you'd need a copy of the previous file, and large files would likely be out of reach... some limit would need to be imposed. Then where do you store the copy of the old file, the old registry key, the old hosts file... on the server, on the client? To me, while I want the feature, I'm not sure people realize the trade off they need to make, mainly client disk space so copies of originals (even if compressed) can be stored and the diff's can be made. Diskspace is cheap and this might not be an issue for some, but we run a lot of VM and the guests are only as big as they need to be, the "free" space we have is for anticipated growth, we may have to add to those estimates and grow our previous installs:) -rich
