-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mr Starks put out a call for a wishlist, so I will comply and put forth my top feature requests...
1) Please, for the love of <insert deity here>, please add a way to push a config to a agent. I'm ok with having to use some form of scripting to restart agents when they receive the new config, but there is currently no way that I know of to push a config out to an agent. I made changes to the config, the agent needs them. I don't typically have the time to wait for the agents to come get them. 2) Somewhat related to the previous request, there is no way, that I know of, to identify whether the config the agent has is the one that is currently being used. For instance, I update the agent.conf file. I completely forget to restart the agent when it gets the config, likely because of #1. If I use agent_control to look at the agent, it shows the md5sum of the new agent.conf, even though it's not the one actively being used.. Perhaps a flag that agent_control can show as to whether the agent has been restarted since it received the new config? 3) Prior to moving to OSSEC, I used Osiris for integrity checking. Osiris would send a single email detailing all of the changes for a single client. This was extremely useful as I could see, at a glance, all of the files that changed since the last check. As I understand it, and I could be wrong, syscheck runs every x minutes and is a single process. ie, when syscheck runs, it checks every directory and file specified before going back to sleep. It *should* be possible, I think, to generate a single email detailing all of the changes. I think you can write specific rules that trigger on syscheck events, so perhaps OSSEC should continue to act as it does now, but add a flag to allow the changes to queue and be sent as a single email? The agent should be able to signal to the server that the syscheck process is complete. 4) It would be nice to be able to monitor ports and kernel modules. I think this can be done by calling an external program, but native support for this would be nice. Plus, if this was done internally, I believe it would thwart any root kits that try to hide modules and ports from the common tools used to look at them. ... That's all I have for now.. Let's get chatting and see what else comes of it.. - --------------------------- Jason 'XenoPhage' Frisvold [email protected] - --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - - Niven's Inverse of Clarke's Third Law -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkyybM8ACgkQ8CjzPZyTUTRabACffkSw3EvuYmDuZEisI6qecLbh nQwAoI6dCCykvwbnsNp/Vo/PVqmLF8UN =8Mct -----END PGP SIGNATURE-----
