This is just a thought, but has anyone used the Windows command, "SC.EXE" in a script to restart the service, i.e.,
sc.exe \\servername OssecSvc stop sc.exe \\servername OssecSvc start This is making the assumption that you have a domain account and access to all of your Windows-based hosts. The script would read the client.keys file one line at a time and process the name/ip address. The script could log success or not. Another tool that is available is plink.exe (part of WinSCP). Although these solutions require integration with Windows, I'm sure someone could expand upon this idea from a Linux point of view. BW -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jason 'XenoPhage' Frisvold Sent: Wednesday, June 15, 2011 1:32 PM To: [email protected] Subject: Re: [ossec-list] Re: shared config being distributed to ALL hosts -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/14/2011 10:54 PM, GeorgeY wrote: > Thanks Dan and Christopher. Most helpful. > Now to my next question ;), after any changes to agent.conf, the > automatic "pushing" of the updated agent.conf file is working as > expected. This is great. However, is the configuration applied > immediately or it requires a manual restart of the Ossec HIDS service > on the Windows machines? i tried the agent_control -R <id> option but Unfortunately, this is currently an issue with OSSEC. Of course, you can also argue that not automatically restarting the agents on a new config push is a feature.. But regardless, if it's something you're looking to do, then you may be in luck. Note : This works for Linux and requires some changes to make it work in Windows. I'm not in a Windows environment, so I'm not sure what the exact changes are. I can give some hints, though. :) The short version is this. Add the following to your local_rules.xml file (using an appropriately unique rule id) <rule id="100005" level="12"> <if_matched_group>syscheck</if_matched_group> <description>agent.conf changed, restarting OSSEC</description> <match>/var/ossec/etc/shared/agent.conf</match> </rule> What this will do is use syscheck (which you should have configured to monitor the ossec directory) to watch the agent.conf file (you'll need to update the location of that file for windows). If it changes, it triggers a level 12 alert. Next, add the following to your ossec.conf file on the server (above all other active response sections) : <command> <name>restart-ossec</name> <executable>restart-ossec.sh</executable> <expect>srcip</expect> <timeout_allowed>no</timeout_allowed> </command> <active-response> <command>restart-ossec</command> <location>local</location> <rules_id>100005</rules_id> </active-response> This looks specifically for rule 100005 (or whatever rule ID you're using) and if it fires, launches the restart-ossec command on the machine that triggered the alert. You'll need to write a restart-ossec program for windows, but I imagine you can use powershell or something like that to make it work. A restart on the ossec service should do it. That should get you on the right road. If you would, please post any modifications you make back to the list so others can benefit. I'm interested in what the restart-ossec.cmd program for windows might look like. Enjoy. - -- - --------------------------- 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 v2.0.17 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk347HMACgkQ8CjzPZyTUTQqdACglvHott3QVSMr2rPD6q95Rsl+ f4cAn0z6677aozm+65msiaoPXVO/ZTwK =aPRc -----END PGP SIGNATURE-----
