Re: [ossec-list] Re: how to monitor the ossec agent status
On Mon, Dec 19, 2011 at 9:04 PM, Macus wrote: > It is just as easy as below to monitor OSSEC logs? > > syslog > /var/ossec/logs/ossec.log > > That should do it. > Moreover, I have enabled the debug of the syscheck and agent. Will the > log monitoring alert all logs messages or just specific "error" > messages? > Just log messages that trigger alerts. There isn't really an ossec.log tailed ruleset, so you'll mostly see 1002s. > On 12月17日, 上午3時29分, "dan (ddp)" wrote: >> You can have ossec monitor its own logs. >> >> >> >> >> >> >> >> On Tue, Dec 13, 2011 at 11:15 PM, Macus wrote: >> > Is there any way to monitor the ossec server and agent? Like to >> > capture any strange logs in the ossec.log.
[ossec-list] Re: how to monitor the ossec agent status
It is just as easy as below to monitor OSSEC logs? syslog /var/ossec/logs/ossec.log Moreover, I have enabled the debug of the syscheck and agent. Will the log monitoring alert all logs messages or just specific "error" messages? On 12月17日, 上午3時29分, "dan (ddp)" wrote: > You can have ossec monitor its own logs. > > > > > > > > On Tue, Dec 13, 2011 at 11:15 PM, Macus wrote: > > Is there any way to monitor the ossec server and agent? Like to > > capture any strange logs in the ossec.log.
Re: [ossec-list] Re: Repeated Offenders not triggering
Thanks for finding that. If I haven't already, I'll update the docs. On Sat, Dec 17, 2011 at 7:46 AM, c0by wrote: > I did some more testing, and I am happy to say I believe this issue is > SOLVED! > > The issue is that the repeated offenders configuration needs to be on > the *agents* ossec.conf file, and *not* in the servers ossec.conf. I > believe you could have it on both so it is used for both the server > and agent. It can't go in the agent.conf currently which would of been > nice, but it's fine for now. > > For more details on this see my post on this solution here: > http://www.mebsd.com/freebsd-security-hardening/solved-ossec-repeated-offenders-ignored.html > > Regards > Jake > > On Dec 17, 4:57 am, Chris Warren wrote: >> Good find! Thank you! >> >> Unfortunately the source is still a little over my head...just meaning that >> I don't have the time to right now to get in and learn. >> >> But I work regularly with a couple of different ossec server/agent groups >> for different clients, and can definitely help to test any code patches, >> and/or help with any diagnostic testing. >> >> I'd love to see this feature work, but it is by no means a deal-breaker for >> me. >> >> >> >> >> >> >> >> - Original Message - >> From: "jake 22s" >> To: ossec-list@googlegroups.com >> Sent: Friday, December 16, 2011 6:09:51 PM >> Subject: Re: [ossec-list] Repeated Offenders not triggering >> >> I can confirm that repeated_offenders *does* work on a local only install. >> >> I too run an agent / server setup with blocks going to all agents. With this >> setup repeated_offenders does *not* work. It says it's loaded in the start >> up log but it is ignored and the default ar timeout is always used. >> >> So going by your suggestion, I installed a fresh local only ossec install on >> a development server and it does indeed work. >> >> Looks like some code must be missing from the agent only build perhaps. Not >> done much testing yet, but will do more later and have a read through the >> source. >> >> Any of the developers know much about this? >> >> -Original Message- >> From: Chris Warren >> Sender: ossec-list@googlegroups.com >> Date: Fri, 16 Dec 2011 14:41:38 >> To: >> Reply-To: ossec-list@googlegroups.com >> Subject: Re: [ossec-list] Repeated Offenders not triggering >> >> Could be that it's only working for local setups currently? I am using >> server/agent, with active responses triggering blocks on all servers. >> >> Even so, I repeated abused 1 single server and could not get the >> repeated_offenders timeout to trigger. >> >> Anybody with a local install that can test this, or has it working? >> >> - Original Message - >> From: "jake 22s" >> To: ossec-list@googlegroups.com >> Sent: Wednesday, December 14, 2011 6:56:47 AM >> Subject: Re: [ossec-list] Repeated Offenders not triggering >> >> Moving the repeated_offenders to its own block did not work for me. I don't >> see anything in the log on start either. >> >> Is this feature confirmed as working? Just doesn't seem to have many docs >> for it, would be a nice feature to use. >> >> Jake >> Sent using BlackBerry® from Orange >> >> -Original Message- >> From: Chris Warren >> Sender: ossec-list@googlegroups.com >> Date: Tue, 13 Dec 2011 15:55:40 >> To: >> Reply-To: ossec-list@googlegroups.com >> Subject: Re: [ossec-list] Repeated Offenders not triggering >> >> Sometimes I see the same host blocked every 600 seconds (the timeout value). >> >> I tried adding the repeated_offenders list to it's own block as the >> documentation suggested, but then I do not see: >> >> 2011/12/12 19:39:15 ossec-execd: INFO: Adding offenders timeout: 30 (for #1) >> 2011/12/12 19:39:15 ossec-execd: INFO: Adding offenders timeout: 60 (for #2) >> 2011/12/12 19:39:15 ossec-execd: INFO: Adding offenders timeout: 120 (for #3) >> 2011/12/12 19:39:15 ossec-execd: INFO: Adding offenders timeout: 1440 (for >> #4) >> >> I will be doing some more testing as well, and will report back if I find a >> solution. >> >> - Original Message - >> From: "dan (ddp)" >> To: ossec-list@googlegroups.com >> Sent: Tuesday, December 13, 2011 3:46:23 PM >> Subject: Re: [ossec-list] Repeated Offenders not triggering >> >> Based onhttp://dcid.me/2011/02/blocking-repeated-offenders-with-ossec/ >> I think the repeated_offenders list should be in its own block. >> Example: >> >> >> firewall-drop >> all >> 7 >> 600 >> >> >> 30,60,120,1440 >> >> >> Again, I'm not sure and I don't know how easy this will be for me to test. >> >> On Mon, Dec 12, 2011 at 10:08 PM, Chris Warren >> wrote: >> > Hi, >> > I'm am trying out the option but it does not seem to >> > be triggering. >> >> > Here is my active response config: >> > >> > >> > firewall-drop >> > all >> > 7 >> > 600 >> > 30,60,120,1440 >> > >> >> > I also get this when restarting OSSEC: >> > 2011/12/12 19:39:15 ossec-execd: INFO: Adding offenders timeout: 30 (for >>
Re: [ossec-list] Re: rules 550,551,552 Decoded_as
On Mon, Dec 19, 2011 at 7:13 AM, alsdks wrote: > > Hi Dan, > > From what you said , I suppose Rule 554 ( syscheck_new_entry) , > doesn't get the "syscheck-registry New file" entries. > That makes registry monitoring (HKEY/.../.../RUN for example) > completely useless . I have added various entries under that key and > did not get an alert on any of them. > > The way this works should be clearly stated not to get false idea that > your monitor something which as it proves you don't . > > Anyway , coming back to the reason I've opened this post , is there a > way to get those new registry entries ? The entries I > mentioned are those rules in ossec_rules.xml ,550 to 554 about > syscheck ,for which I haven't been able to understand how exactly do > the decoders work. What patterns do they match against. > > Thank you > > I think being able to alert on new registry entries would be a useful feature. I'm looking into it, but everyone else is free to look at it quicker than me. ;) > > > On Dec 16, 10:08 pm, "dan (ddp)" wrote: >> On Tue, Dec 13, 2011 at 5:47 PM, alsdks wrote: >> > Hello Dan, >> >> > Interestingly, grepping for 'syscheck_integrity_changed' returns >> > different files depending platform , whether the source has been >> > compiled or not, etc etc. >> >> That makes sense. >> >> >> >> >> >> >> >> >> >> > Here is what I found in an un-compiled ossec source directory , under >> > ossec-hids-2.6/src/analysisd/rules.h : >> >> > #define ROOTCHECK_MOD "rootcheck" >> > #define HOSTINFO_NEW "hostinfo_new" >> > #define HOSTINFO_MOD "hostinfo_modified" >> > #define SYSCHECK_MOD "syscheck_integrity_changed" >> > #define SYSCHECK_MOD2 "syscheck_integrity_changed_2nd" >> > #define SYSCHECK_MOD3 "syscheck_integrity_changed_3rd" >> > #define SYSCHECK_NEW "syscheck_new_entry" >> > #define SYSCHECK_DEL "syscheck_deleted" >> >> > Other than that I could nor find exactly how the >> > syscheck_integrity_changed or syscheck_new_entry (etc) are decoding >> > events .What are they searching for . >> >> It's all in the source. >> >> >> >> >> >> >> >> >> >> > The blind spot to me is the following : >> >> > from archives.log I have pinpointed two examples : >> >> > event message example A): 2011 Dec 13 15:56:51 (wintest) 10.10.10.1- >> >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to >> > the file system. >> > example B):2011 Dec 09 04:38:56 (wintest) 10.10.10.1->syscheck- >> > registry New file 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows >> > \CurrentVersion\Uninstall\WinSSHD' added to the file system. >> >> > Example A has generated an alert as it was expected .Example B hasn't >> > although it is specified in agent's ossec.conf to monitor this >> > registry key amongst others.(Rule 554 is overwritten to alert new >> > files) .A quick eye spotted difference is syscheck in A instead of >> > syscheck-registry in B. >> >> > Question 1: Why example B did not generate an alert .(there are no >> > ignore rules for that key) >> >> What rule should be triggered? I don't know if there is one to alert >> on new registry entries. >> >> >> >> >> >> >> >> >> >> > Another interesting thing I have noticed , which led me into searching >> > the above mentioned decoders, is that if I paste example A again >> > through ossec-logtest I get the following : >> >> > **Phase 1: Completed pre-decoding. >> > full event: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1- >> >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to >> > the file system.' >> > hostname: 'ossec-server' >> > program_name: '(null)' >> > log: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1->syscheck New >> > file 'C:\Windows/System32/drivers/etc/test.txt' added to the file >> > system.' >> >> > **Phase 2: Completed decoding. >> > No decoder matched. >> >> > So there is no alert triggered. >> >> > Question 2 : were does this get triggered ? Am I seeing an altered >> >> analysisd >> >> > event in archives.log ? What are these entries searching >> >> Yes, there is a header attached to the log entry. >> >> > for that did not trigger an alert in example B (ok that was a multi >> > question ). >> >> What entries? >> >> >> >> >> >> >> >> > And finally should I be making a custom decoder and rule for example >> > B ? >> >> > I hope I have explained it as clearly as I could , I could be delving >> > down the wrong path but I though I needed to find how these decoders >> > work >> >> > Thank you ! >> >> > On Dec 13, 10:31 pm, "dan (ddp)" wrote: >> >> On Tue, Dec 13, 2011 at 5:23 AM, alsdks wrote: >> >> >> > Hello Dan, >> >> >> > hmmm those are binaries and I can't get anything out of them ... >> >> >> They should be c source code files. >> >> >> > The thing is, while troubleshooting my other issue (Syscheck issue on >> >> > Windows : alerts not generated for registry and executable checks : >> >> > default OSSEC.conf) I have noticed the following behavior : >> >> >> > While testing messa
Re: [ossec-list] File integrity check needed on archived logs
On Mon, Dec 19, 2011 at 7:18 PM, helpmailinglist wrote: > A file integrity check is needed on archived files only. For > instance, /var/log/httpd/*.gz. How is this possible? And can the > rule(s) be set up on the ossec server rather than the clients? I haven't tried putting files into syscheck, so I don't know if that would work. You could add directories entries for /var/log/httpd, and the error_log/access_log/whatever_log files. Or you could monitor /var/log/httpd and create rules to first ignore everything, then another rule to alert on .gz files changing. Or you could use the restrict option in your directories definition.
Re: [ossec-list] Re: Monitoring Command Output : is there a line number limitation
On Mon, Dec 19, 2011 at 6:46 PM, BP9906 wrote: > When I get email alerts for mine, I only get back 20 lines back. Seems > to be hard coded. > > As an example, monitoring listened ports: > > ossec: output: 'netstat -anp tcp | find "LISTEN" | find /V > "127.0.0.1"': > TCP 0.0.0.0:80 0.0.0.0:0 LISTENING > TCP 0.0.0.0:135 0.0.0.0:0 LISTENING > TCP 0.0.0.0:443 0.0.0.0:0 LISTENING > TCP 0.0.0.0:445 0.0.0.0:0 LISTENING > TCP 0.0.0.0:513 0.0.0.0:0 LISTENING > TCP 0.0.0.0:2201 0.0.0.0:0 LISTENING > TCP 0.0.0.0:2481 0.0.0.0:0 LISTENING > TCP 0.0.0.0:3588 0.0.0.0:0 LISTENING > TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING > TCP 0.0.0.0:5657 0.0.0.0:0 LISTENING > TCP 0.0.0.0:8779 0.0.0.0:0 LISTENING > TCP 0.0.0.0:9871 0.0.0.0:0 LISTENING > TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING > TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING > TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING > TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING > TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING > TCP 0.0.0.0:49163 0.0.0.0:0 > Previous output: > > > > --END OF NOTIFICATION > How many lines are passed back to the manager? (hint: use log_all) > > > On Dec 16, 11:30 am, "dan (ddp)" wrote: >> How many lines do you get back exactly? >> >> >> >> >> >> >> >> On Tue, Dec 13, 2011 at 9:05 PM, alsdks wrote: >> > Hello, >> >> > I have set up a command to monitor file permissions in Windows (Since >> > by default Ossec only supports POSIX ). The command for example is : >> >> > >> > full_command >> > icacls c:\WINDOWS\system32\*.exe >> > icacls >> > >> >> > Now the question: is there a limitation how many lines can OSSEC take >> > and process as the output of a command ?Because I seem to be getting >> > only up to letter c of the executables located in that dir. >> >> > Thank you !
[ossec-list] Re: Monitoring Command Output : is there a line number limitation
When I get email alerts for mine, I only get back 20 lines back. Seems to be hard coded. As an example, monitoring listened ports: ossec: output: 'netstat -anp tcp | find "LISTEN" | find /V "127.0.0.1"': TCP0.0.0.0:80 0.0.0.0:0 LISTENING TCP0.0.0.0:1350.0.0.0:0 LISTENING TCP0.0.0.0:4430.0.0.0:0 LISTENING TCP0.0.0.0:4450.0.0.0:0 LISTENING TCP0.0.0.0:5130.0.0.0:0 LISTENING TCP0.0.0.0:2201 0.0.0.0:0 LISTENING TCP0.0.0.0:2481 0.0.0.0:0 LISTENING TCP0.0.0.0:3588 0.0.0.0:0 LISTENING TCP0.0.0.0:3389 0.0.0.0:0 LISTENING TCP0.0.0.0:5657 0.0.0.0:0 LISTENING TCP0.0.0.0:8779 0.0.0.0:0 LISTENING TCP0.0.0.0:9871 0.0.0.0:0 LISTENING TCP0.0.0.0:47001 0.0.0.0:0 LISTENING TCP0.0.0.0:49152 0.0.0.0:0 LISTENING TCP0.0.0.0:49153 0.0.0.0:0 LISTENING TCP0.0.0.0:49154 0.0.0.0:0 LISTENING TCP0.0.0.0:49155 0.0.0.0:0 LISTENING TCP0.0.0.0:49163 0.0.0.0:0 Previous output: --END OF NOTIFICATION On Dec 16, 11:30 am, "dan (ddp)" wrote: > How many lines do you get back exactly? > > > > > > > > On Tue, Dec 13, 2011 at 9:05 PM, alsdks wrote: > > Hello, > > > I have set up a command to monitor file permissions in Windows (Since > > by default Ossec only supports POSIX ). The command for example is : > > > > > full_command > > icacls c:\WINDOWS\system32\*.exe > > icacls > > > > > Now the question: is there a limitation how many lines can OSSEC take > > and process as the output of a command ?Because I seem to be getting > > only up to letter c of the executables located in that dir. > > > Thank you !
[ossec-list] File integrity check needed on archived logs
A file integrity check is needed on archived files only. For instance, /var/log/httpd/*.gz. How is this possible? And can the rule(s) be set up on the ossec server rather than the clients?
[ossec-list] memory_size option and knowing when you've hit the limit
Watching analysisd I can see it reaches 141M (looking at TOP). If it hits the size that corresponds to your parameter, then can I assume that I should increase the memory_size parameter? Or does analysisd simply use the memory size you've given it and that is not a good way to judge when I should increase the memory size? Thoughts and suggestions? Thank you!
[ossec-list] Re: rules 550,551,552 Decoded_as
Hi Dan, >From what you said , I suppose Rule 554 ( syscheck_new_entry) , doesn't get the "syscheck-registry New file" entries. That makes registry monitoring (HKEY/.../.../RUN for example) completely useless . I have added various entries under that key and did not get an alert on any of them. The way this works should be clearly stated not to get false idea that your monitor something which as it proves you don't . Anyway , coming back to the reason I've opened this post , is there a way to get those new registry entries ? The entries I mentioned are those rules in ossec_rules.xml ,550 to 554 about syscheck ,for which I haven't been able to understand how exactly do the decoders work. What patterns do they match against. Thank you On Dec 16, 10:08 pm, "dan (ddp)" wrote: > On Tue, Dec 13, 2011 at 5:47 PM, alsdks wrote: > > Hello Dan, > > > Interestingly, grepping for 'syscheck_integrity_changed' returns > > different files depending platform , whether the source has been > > compiled or not, etc etc. > > That makes sense. > > > > > > > > > > > Here is what I found in an un-compiled ossec source directory , under > > ossec-hids-2.6/src/analysisd/rules.h : > > > #define ROOTCHECK_MOD "rootcheck" > > #define HOSTINFO_NEW "hostinfo_new" > > #define HOSTINFO_MOD "hostinfo_modified" > > #define SYSCHECK_MOD "syscheck_integrity_changed" > > #define SYSCHECK_MOD2 "syscheck_integrity_changed_2nd" > > #define SYSCHECK_MOD3 "syscheck_integrity_changed_3rd" > > #define SYSCHECK_NEW "syscheck_new_entry" > > #define SYSCHECK_DEL "syscheck_deleted" > > > Other than that I could nor find exactly how the > > syscheck_integrity_changed or syscheck_new_entry (etc) are decoding > > events .What are they searching for . > > It's all in the source. > > > > > > > > > > > The blind spot to me is the following : > > > from archives.log I have pinpointed two examples : > > > event message example A): 2011 Dec 13 15:56:51 (wintest) 10.10.10.1- > >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to > > the file system. > > example B):2011 Dec 09 04:38:56 (wintest) 10.10.10.1->syscheck- > > registry New file 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows > > \CurrentVersion\Uninstall\WinSSHD' added to the file system. > > > Example A has generated an alert as it was expected .Example B hasn't > > although it is specified in agent's ossec.conf to monitor this > > registry key amongst others.(Rule 554 is overwritten to alert new > > files) .A quick eye spotted difference is syscheck in A instead of > > syscheck-registry in B. > > > Question 1: Why example B did not generate an alert .(there are no > > ignore rules for that key) > > What rule should be triggered? I don't know if there is one to alert > on new registry entries. > > > > > > > > > > > Another interesting thing I have noticed , which led me into searching > > the above mentioned decoders, is that if I paste example A again > > through ossec-logtest I get the following : > > > **Phase 1: Completed pre-decoding. > > full event: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1- > >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to > > the file system.' > > hostname: 'ossec-server' > > program_name: '(null)' > > log: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1->syscheck New > > file 'C:\Windows/System32/drivers/etc/test.txt' added to the file > > system.' > > > **Phase 2: Completed decoding. > > No decoder matched. > > > So there is no alert triggered. > > > Question 2 : were does this get triggered ? Am I seeing an altered > > analysisd > > > event in archives.log ? What are these entries searching > > Yes, there is a header attached to the log entry. > > > for that did not trigger an alert in example B (ok that was a multi > > question ). > > What entries? > > > > > > > > > And finally should I be making a custom decoder and rule for example > > B ? > > > I hope I have explained it as clearly as I could , I could be delving > > down the wrong path but I though I needed to find how these decoders > > work > > > Thank you ! > > > On Dec 13, 10:31 pm, "dan (ddp)" wrote: > >> On Tue, Dec 13, 2011 at 5:23 AM, alsdks wrote: > > >> > Hello Dan, > > >> > hmmm those are binaries and I can't get anything out of them ... > > >> They should be c source code files. > > >> > The thing is, while troubleshooting my other issue (Syscheck issue on > >> > Windows : alerts not generated for registry and executable checks : > >> > default OSSEC.conf) I have noticed the following behavior : > > >> > While testing messages as they arrive to the system (using logall > >> > option) with ossec-logtest , even messages that have triggered an > >> > alert , it says that 'No decoder found' and further processing is not > >> > done .So I am guessing that processing and triggering the relative > >> > alerts through rules is done elsewhere or with other means . > > >> > It is very strange how it works ,
