Hi Michael, I can say, no, its not an updated batch file, its the stock one from the windows agent distribution. I was unaware there was an update, thanks for that nugget. I will find and grab it later today for comparison.
Don't take my comments as disparaging. Given our networking team refuses to do *any* active-response from the core down to the edge devices... even though we have all the tools for it and no policy or funding from senior leadership, OSSEC really has been a blessing and also fills some other gaps neatly; I am looking forward to greatly building out our fledgling install. Right now I am proofing it out and the active response has been very encouraging. I entered the fray from 2.8 only about a month ago and have little to no knowledge of historically significant milestones in OSSEC's development aside from it switching ownership a couple of times and a number of people on the SANS advisory board having recommended it. I assumed the route-null.cmd batch worked at some point and maybe fell by the way side during continued development, but I guess not. :( Although, I am curious, going back to the Regex issue... I'm all for bounds checking, but is there some other engineering reason why it was included? I mean, technically, can't the script expect the manager to send the correct parameters? I agree, NT based command scripts can be a challenge, I've seen some smart people do some really crazy-neat things with them, but it always seems the code is necessarily overburdened with coding tricks to get anything done (ie. few approaches seem to be simple and clean). I have been mulling over getting more involved, if you have any advice in this regard over whats on the website, I'd like to hear it. I am already mulling over some local customization that might hopefully be useful to people with similar setups and constraints. BTW- Thanks for the feedback and enlightenment. - Eric On Tue, Sep 23, 2014 at 12:13 PM, Michael Starks < [email protected]> wrote: > On 2014-09-23 10:40, Eric Johnfelt wrote: > > The active-response script that comes with the Windows agent is just >> hopelessly broken... here is why... >> > > It didn't work at all prior to 2.8. At least it works now from the command > line (with the latest update). As to why it only works that way remains to > be seen. > > - The 2.8.1 script expects positional parameter %2 to be the IP >> Address, its not, %3 is >> > > Is this with the updated script I sent to the list or the original one? I > submitted a dev version accidentally for 2.8. But it was still no worse off > than <2.8, since that version also didn't work. :) My intention was not to > change the approach, but to make what was there actually at least work with > an updated version. > > - The regular expression for validating IP's is wrong. Findstr's >> RegExp facility is well... just terrible, so >> [0-9]*.[0-9]*.[0-9]*.[0-9]* is the best you can do, but its not 100% >> correct for validating IP addresses either, but it works for the >> complete subset of valid addresses. >> > > The regex is as good as it can get by using a batch file with findstr. As > you mentioned, the regexp facility of findstr is terrible. But the version > prior to 2.8 had nothing, so this is... something. > > - The OSSECPATH variable is not set. This *should* be set in the >> environment via the install, or manually (via Start|Right-Click >> Computer Properties|Advanced System Settings|Environment Variables, be >> admin when you do so) Obviously some people prefer setting a registry >> key and looking it up... and that's fine too. >> > > Is this with the updated script I sent to the list or the original one? It > should be set now. I agree that the installer should take care of this and > it should be an environment variable. Patches are welcome! > > - The method used to choose the null-route is a bit flawed. It doesn't >> take into account any combination of multiple IP's or network >> interfaces; which is common for people using any kind of >> virtualization (Virtual Box, VMware, Virtual PC) or servers with >> multiple IPs or NICS. Technically, it will still work, it is just... >> not fundamentally correct and your mileage may vary. >> > > Yup, but there isn't a better way unless the AR is written in something > better. The batch approach is terrible. I think it should be rewritten in > something like Power Shell, but whatever it is has to work across different > Windows versions natively, or it has to be built into OSSEC. I'm no longer > interested in fighting with Windows scripting. > > Lastly, testing the active-response does not seem to work... at least >> for me... I'm still working on that... however I can say the following >> for certain. First, when I issue a test, I see the packet received via >> wireshark, the agent just doesn't seem to respond. However, when a >> real active-response comes in from the manager, the route-null.cmd >> script is executed; with the fixes mentioned above, the script does >> work. >> > > Good to hear! > > Anyhow, the point is, you can fix the bundled script or replace it; >> replacing will give you access to better AND more functionality, IMHO. >> Either way fixed or replaced, when it works... its a beautiful thing. >> > > I think the update I sent works... sort of. It seems to on the command > line anyway. And what was there for the entire history of OSSEC didn't > work, so that's progress... sort of. :) But it's still a bug, ugly batch > file hack. > > I would however, like to see the agent_control, OSSECPATH variable and >> script fixed in the distro, mainly because the bugs are *extremely* >> frustrating and at least two of them are easily fixable. >> > > If you are so inclined, please take this on and implement something nice! > > > -- > > --- You received this message because you are subscribed to the Google > Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
