[ossec-list] Re: if_sid vs if_matched_sid
I'm wondering the same thing. Whats the difference between the 2 anyway? I'm ultimately trying to have 2 frequency rules and the second one doesnt fire. I suspect its something to do with the if_sid or if_matched_sid. On Jun 27, 2:09 pm, "dan (ddp)" wrote: > Hi Jason, > > On Mon, Jun 27, 2011 at 2:48 PM, Jason 'XenoPhage' Frisvold > > > > > > > > > > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > Hi all, > > > I'd like to see the online docs updated to make this more clear. Can > > someone please verify my understanding (original from > >http://www.ossec.net/doc/syntax/head_rules.html#options) : > > > group.rule.if_sid > > Matches if the ID has matched once. > > Allowed: Any rule id > > > group.rule.if_matched_sid > > Matches if the ID has matched multiple times. Used for composite rules. > > Allowed: Any rule id > > These always confuse me. I'll look into it. :) > > > If this is correct, who do I need to contact to get the online docs > > updated? Or maybe the online docs should all be moved to the wiki so > > the community can update it? > > Wikis suck. The current documentation can be found > athttps://bitbucket.org/ddpbsd/ossec-rules > It's done in sphinx (with help from paver). Someone else started it, > and I don't have a good grasp on how to do anything fancy with it. But > I can definitely update the above. > Feel free to fork it, modify it, etc. And/or create issues on bitbucket for > me. > dan > > > > > > > > > - -- > > - --- > > Jason 'XenoPhage' Frisvold > > xenoph...@godshell.com > > - --- > > "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/ > > > iEYEARECAAYFAk4I0JIACgkQ8CjzPZyTUTQ0KQCeNrV4+Z30ivqj40GbWkdsB27y > > RWUAmQFvpQBuhS0WFImE0LOYIYyZnHFv > > =2EZS > > -END PGP SIGNATURE-
[ossec-list] Re: Help on composite rules
I have the same issue. I have a custom decoder, and 2 composite (frequency/reoccurring) rules. The first composite rule matches properly, even when testing with ossec-logtest. I'm trying to match the same IP for a lower bound threshold and an upper bound thresdhold. Example: 10 in 3 minutes 20 in 10 minutes The 10 in 3 minutes flags properly (and I've considered the info you provided about how the counting actually works... set it to 8, so on the 10th time it actually alerts). If I test the event 20 times quickly, I end up with the 2 3min alerts and not 1 3min and 1 10min. (http://marc.info/?l=ossec-list&m=129736702512080&w=2) With the above considered, I went as far as removing the 20 in 10 and using a group. I labeled the "10 in 3 minutes" as 3min. Then created a rule that does 3min (with ) and that rule never flags either. It seems as though OSSEC is very top down and once an event goes down a different path, it never continues for composite rules (atomic rules they do). I thought the group alerting would help or be an independent list, but it appears to not be. I tried adding the with the because it seems there's a dependency there, but that didnt help. (syslog) Any light you can shed on composite rule functions and group alerts would be beneficial to all. Thank you! On May 27, 6:45 am, Denis Gasparin wrote: > I tested with frequency=0. The alarm is triggered at the receival of the > second line but the email with the alarms contains only the last row and not > the first (that with the error)... :-( > > Denis > > - Messaggio originale - > > Da: "Denis Gasparin" > A: ossec-list@googlegroups.com > Cc: ossec-list@googlegroups.com > Inviato: Venerdì, 27 maggio 2011 15:33:44 > Oggetto: Re: [ossec-list] Help on composite rules > > From what I read, I should set frequency to 0 in order to get the alarm every > 2 events. I'll try and let you know.. > > The 1005001 fires. > > Thank you > Denis > > Il giorno 27/mag/2011, alle ore 14:22, "dan (ddp)" ha > scritto: > > > > > > > > > Does 100501 fire? > > > It may be a "frequency" issue, take a look at the following thread, it > > may be useful: > >http://marc.info/?l=ossec-list&m=129736702512080&w=2 > > > On Thu, May 26, 2011 at 4:28 PM, Denis Gasparin > > wrote: > > >> Hi to all. > > >> We have a postgresql installation that writes two lines for every query > >> error. For example after executing the query "select * from > >> unexistant_table", the postgresql log file has the following two lines: > > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-17] > >> user@ossec([local]) SELECT ERROR: relation "unexistant_table" does not > >> exist > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-18] > >> user@ossec([local]) SELECT STATEMENT: select * from unexistant_table; > > >> We need to send an alert for every query error with attached the relative > >> "STATEMENT". > > >> Because our postgres log format is different from that bundled with ossec, > >> we wrote our decoder and our rules. > > >> The decoder (edistar_pgsql) works fine. The rules works ok for single > >> events. > >> For sending the previous two lines within the same alert we created a > >> composite rule with a very restricted timeframe, so the two events will be > >> grouped together. He are the relevant rules written so far: > > >> > >> > >> edistar_postgresql > >> Edistar PostgreSQL messages grouped. > >> > > >> > >> 100500 > >> ERROR|STATEMENT > >> PostgreSQL error message and relative > >> statement. > >> pgsql_query_failures, > >> > > >> > >> pgsql_query_failures > >> PostgreSQL error message. Query attached. > >> >> > > >> The composite rule does not work as expected. In order to trigger it, two > >> query error must be generated in the timeframe, so the log would be: > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-17] > >> user@ossec([local]) SELECT ERROR: relation "unexistant_table" does not > >> exist > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-18] > >> user@ossec([local]) SELECT STATEMENT: select * from unexistant_table; > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-17] > >> user@ossec([local]) SELECT ERROR: relation "unexistant_table" does not > >> exist > >> May 26 20:11:46 test_machine postgres: 22495[4dde97bd.57df-18] > >> user@ossec([local]) SELECT STATEMENT: select * from unexistant_table; > > >> In this case OSSEC would generate an alert with only two lines (the second > >> and the third). > > >> Can you help me? Is there another way to get the correct result? > > >> Thank you in advance for your help, > >> Denis > >> Inviato da iPad
[ossec-list] Re: if_sid vs if_matched_sid
Thanks Dan, that makes more sense. Would that be the same for vs ? Also, how does if_group_matched figure into if_matched_sid? It seems as though as events come in the group list counting isnt every alert being processed; meaning the alert would either be added to the sid match composite rule counts OR the group match composite rule counts. On Jul 8, 4:58 pm, "dan (ddp)" wrote: > On Fri, Jul 8, 2011 at 11:29 AM, dan (ddp) wrote: > > > if_sid: For this log message, is sid XXX a valid match> > > if_matched_sid: Has sid YYY matched a recent log message (but not > > necessarily this one)? > > This is simplistic and partly wrong. > > if_sid is basically correct. If sid XXX matches the current log > message, then use rule YYY instead: > > > XXX > This rule should be triggered instead of XXX > > > if_matched_sid is generally used in frequency based rules, and > determines whether sid XXX has been triggered Z times in A seconds. :P > > > XXX > If XXX is triggered 5+ times in 30 seconds, YYY should > be triggered > > > HTH
[ossec-list] Re: Help on composite rules
So I have an event that triggers for a custom decoder. Decoder reads IP's written to a file. iplog IPs ipaddy, ipaddy Mult-Group ipaddy same IP - 6 in 5min ipaddy,reoccurring, 71 Multiple ipaddy same IP - 6 in 5min ipaddy,reoccurring, 71 Multiple ipaddy same IP - 12 in 10min ipaddy,reoccurring, Basically, Rule 13 alerts when it should and 15 does sometimes too, but I dont trust 15. 12 never alerts. I would expect 12 to alert more often then the rest, but it never alerts. Originally we wrote the rules 13/5 but realized that when we get the same IPs over multiple devices that the rule doesnt flag (hence the need for if_matched_group instead of if_matched_sid). I've played with alert levels and didnt seem to help. Any ideas?
[ossec-list] Composite Rule - Ignore option
For the ignore option (for silencing a rule for X seconds), does it silence the rule for X seconds no matter the source IP or does it look at the source ip? My observation is that it silences the rule for X seconds no matter the source IP. Ideally I would silence the IP for X seconds so that after I've taken action (say ban for 30 minutes), then ossec wont have to alert about it for 30 minutes too. Thank you.
[ossec-list] Re: Help on composite rules
Here's the correct one: iplog IPs ipaddy, ipaddy Mult-Group ipaddy same IP - 6 in 5min ipaddy,reoccurring, 11 Multiple ipaddy same IP - 6 in 5min ipaddy,reoccurring, 11 Multiple ipaddy same IP - 12 in 10min ipaddy,reoccurring,
[ossec-list] Re: Help on composite rules
Did some more investigation and it seems like the if_matched_group is still only agent dependent, meaning even after rule 11 records in alerts.log 10+ times from 5 different agents, the alert doesnt flag until its 6 times from the same agent (obviously with the same source ip). Seems like the logic in Ossec is broken. On Jul 11, 2:35 pm, BP9906 wrote: > Here's the correct one: > > > iplog > IPs > ipaddy, > > > > ipaddy > > Mult-Group ipaddy same IP - 6 in 5min > ipaddy,reoccurring, > > > > 11 > > Multiple ipaddy same IP - 6 in 5min > ipaddy,reoccurring, > > > > 11 > > Multiple ipaddy same IP - 12 in 10min > ipaddy,reoccurring, >
[ossec-list] Re: Help on composite rules
Anyone have any suggestions to make the composite rules not agent specific? I get IP notifications from many servers and want to correlate them for occurrence. On Jul 13, 8:27 am, BP9906 wrote: > Did some more investigation and it seems like the if_matched_group is > still only agent dependent, meaning even after rule 11 records in > alerts.log 10+ times from 5 different agents, the alert doesnt flag > until its 6 times from the same agent (obviously with the same source > ip). Seems like the logic in Ossec is broken. > > On Jul 11, 2:35 pm, BP9906 wrote: > > > > > > > > > Here's the correct one: > > > > > iplog > > IPs > > ipaddy, > > > > > > > ipaddy > > > > Mult-Group ipaddy same IP - 6 in 5min > > ipaddy,reoccurring, > > > > > > > 11 > > > > Multiple ipaddy same IP - 6 in 5min > > ipaddy,reoccurring, > > > > > > > 11 > > > > Multiple ipaddy same IP - 12 in 10min > > ipaddy,reoccurring, > >
[ossec-list] Re: Help on composite rules
I can confirm that by having the following rules, it works when testing using ossec-logtest but when I trigger the event manually on the systems with the agent, I get 3 of the same rule. Meaning Rule 12 emails me 3 times, but Rule 13 never alerts. But when I use Logtest 13 alerts when it should. iplog IPs ipaddy, ipaddy Mult-Group ipaddy same IP - 6 in 5min ipaddy,reoccurring, ipaddy Multiple ipaddy same IP - 18 in 15min ipaddy,reoccurring, On Jul 15, 11:18 am, BP9906 wrote: > Anyone have any suggestions to make the composite rules not agent > specific? > > I get IP notifications from many servers and want to correlate them > for occurrence. > > On Jul 13, 8:27 am, BP9906 wrote: > > > > > > > > > Did some more investigation and it seems like the if_matched_group is > > still only agent dependent, meaning even after rule 11 records in > > alerts.log 10+ times from 5 different agents, the alert doesnt flag > > until its 6 times from the same agent (obviously with the same source > > ip). Seems like the logic in Ossec is broken. > > > On Jul 11, 2:35 pm, BP9906 wrote: > > > > Here's the correct one: > > > > > > > iplog > > > IPs > > > ipaddy, > > > > > > > > > > ipaddy > > > > > > Mult-Group ipaddy same IP - 6 in 5min > > > ipaddy,reoccurring, > > > > > > > > > > 11 > > > > > > Multiple ipaddy same IP - 6 in 5min > > > ipaddy,reoccurring, > > > > > > > > > > 11 > > > > > > Multiple ipaddy same IP - 12 in 10min > > > ipaddy,reoccurring, > > >
[ossec-list] How to find agents not reporting in
For those that use OSSEC regularly, you probably notice that although when you run agent_control or list_agents, it seems as though they show "available" or "connected" but you havent gotten anything from them. Enter problem, how do you know you're actually getting something from those machines? Wrote a couple of quick script to help with this. Hope someone finds this useful. #!/bin/bash DATA=`agent_control -l | sed 's/.*Name: //g' | sed 's/,.*//g'` SUBFILTER=$1 RESULT="" echo "" > missing_data.txt echo "" > data.txt for a in $DATA; do RESULT="" if [ -d $SUBFILTER ]; then RESULT=`cat /var/ossec/logs/alerts/alerts.log | grep -m 1 \($a \)` else RESULT=`cat /var/ossec/logs/alerts/alerts.log | grep $SUBFILTER | grep -m 1 \($a\)` fi COUNT=`echo -n $RESULT | wc -m` echo $a echo $RESULT echo $COUNT if [ $COUNT -eq 0 ]; then echo $a >> missing_data.txt else echo $RESULT >> data.txt fi done
[ossec-list] 2.6 Windows Agent issue
Hello, I added a few windows changes to the agent.conf file. After waiting a few hours for the agent.conf to get updated, I restarted the agent and noticed an odd error in the ossec.log: 011/07/28 08:44:33 ossec-agent: Received exit signal. 2011/07/28 08:44:33 ossec-agent: Exiting... 2011/07/28 08:44:33 ossec-agent: Remote commands are not accepted from the manager. Ignoring it on the agent.conf 2011/07/28 08:44:33 ossec-agent(1202): ERROR: Configuration error at 'shared/agent.conf'. Exiting. 2011/07/28 08:44:33 ossec-execd(1350): INFO: Active response disabled. Exiting. 2011/07/28 08:44:33 ossec-agent(1410): INFO: Reading authentication keys file. Oddly enough, different machine with 2.5 does not show this and has the same md5 agent.conf. I'm in process of downgrading the 2.6 agent to 2.5 and confirm resolution. Any ideas whats going on here?
[ossec-list] BUG: 2.6 Windows Agent issue
Figured out that 2.6 doesnt like the full_command agent.conf section and thats a bug. Reverting to 2.5.1 resolves the issue. On Jul 28, 9:04 am, BP9906 wrote: > Hello, > I added a few windows changes to the agent.conf file. After waiting a > few hours for the agent.conf to get updated, I restarted the agent and > noticed an odd error in the ossec.log: > > 011/07/28 08:44:33 ossec-agent: Received exit signal. > 2011/07/28 08:44:33 ossec-agent: Exiting... > 2011/07/28 08:44:33 ossec-agent: Remote commands are not accepted from > the manager. Ignoring it on the agent.conf > 2011/07/28 08:44:33 ossec-agent(1202): ERROR: Configuration error at > 'shared/agent.conf'. Exiting. > 2011/07/28 08:44:33 ossec-execd(1350): INFO: Active response disabled. > Exiting. > 2011/07/28 08:44:33 ossec-agent(1410): INFO: Reading authentication > keys file. > > Oddly enough, different machine with 2.5 does not show this and has > the same md5 agent.conf. > > I'm in process of downgrading the 2.6 agent to 2.5 and confirm > resolution. > > Any ideas whats going on here?
[ossec-list] Re: Help on composite rules
http://groups.google.com/group/ossec-list/browse_thread/thread/1fa288e494a7acc4# The internal memory increase resolved the issue. On Jul 18, 12:48 pm, BP9906 wrote: > I can confirm that by having the following rules, it works when > testing using ossec-logtest but when I trigger the event manually on > the systems with the agent, I get 3 of the same rule. Meaning Rule > 12 emails me 3 times, but Rule 13 never alerts. But when I use > Logtest 13 alerts when it should. > > > iplog > IPs > ipaddy, > > > > ipaddy > > Mult-Group ipaddy same IP - 6 in 5min > ipaddy,reoccurring, > > > > ipaddy > > Multiple ipaddy same IP - 18 in 15min > ipaddy,reoccurring, > > > On Jul 15, 11:18 am, BP9906 wrote: > > > > > > > > > Anyone have any suggestions to make the composite rules not agent > > specific? > > > I get IP notifications from many servers and want to correlate them > > for occurrence. > > > On Jul 13, 8:27 am, BP9906 wrote: > > > > Did some more investigation and it seems like the if_matched_group is > > > still only agent dependent, meaning even after rule 11 records in > > > alerts.log 10+ times from 5 different agents, the alert doesnt flag > > > until its 6 times from the same agent (obviously with the same source > > > ip). Seems like the logic in Ossec is broken. > > > > On Jul 11, 2:35 pm, BP9906 wrote: > > > > > Here's the correct one: > > > > > > > > > iplog > > > > IPs > > > > ipaddy, > > > > > > > > > > > > > ipaddy > > > > > > > > Mult-Group ipaddy same IP - 6 in 5min > > > > ipaddy,reoccurring, > > > > > > > > > > > > > 11 > > > > > > > > Multiple ipaddy same IP - 6 in 5min > > > > ipaddy,reoccurring, > > > > > > > > > > > > > 11 > > > > > > > > Multiple ipaddy same IP - 12 in 10min > > > > ipaddy,reoccurring, > > > >
[ossec-list] Re: BUG: 2.6 Windows Agent issue
01:15 no full_command ver | find "5.0" >nul || reg QUERY HKLM\System \CurrentControlSet\Enum\USBSTOR full_command netstat -an | find "LISTEN" | find /V "127.0.0.1" On Jul 29, 9:03 am, "dan (ddp)" wrote: > Can you provide the agent.conf? > > > > > > > > On Fri, Jul 29, 2011 at 11:32 AM, BP9906 wrote: > > Figured out that 2.6 doesnt like the full_command agent.conf section > > and thats a bug. Reverting to 2.5.1 resolves the issue. > > > On Jul 28, 9:04 am, BP9906 wrote: > >> Hello, > >> I added a few windows changes to the agent.conf file. After waiting a > >> few hours for the agent.conf to get updated, I restarted the agent and > >> noticed an odd error in the ossec.log: > > >> 011/07/28 08:44:33 ossec-agent: Received exit signal. > >> 2011/07/28 08:44:33 ossec-agent: Exiting... > >> 2011/07/28 08:44:33 ossec-agent: Remote commands are not accepted from > >> the manager. Ignoring it on the agent.conf > >> 2011/07/28 08:44:33 ossec-agent(1202): ERROR: Configuration error at > >> 'shared/agent.conf'. Exiting. > >> 2011/07/28 08:44:33 ossec-execd(1350): INFO: Active response disabled. > >> Exiting. > >> 2011/07/28 08:44:33 ossec-agent(1410): INFO: Reading authentication > >> keys file. > > >> Oddly enough, different machine with 2.5 does not show this and has > >> the same md5 agent.conf. > > >> I'm in process of downgrading the 2.6 agent to 2.5 and confirm > >> resolution. > > >> Any ideas whats going on here?
[ossec-list] Daily Reports - Race Condition
I hope Dan will see this so he can note the bug or help me with a work around. Apparently when I schedule 3 daily reports to run, the time they run is shortly after midnight, which is the same time that the log rollover happens to archive previous day's alerts.log. My ossec.log shows that the report is trying to generate and each day it reports something different. Sometimes: 2011/08/01 00:01:49 ossec-monitord: INFO: Report 'Report 1 - Daily Summary' completed and zero alerts post-filter. 2011/08/01 00:01:31 ossec-monitord: INFO: Report Report 2 - Daily Summary' completed. Creating output... 2011/07/29 00:00:56 ossec-monitord: INFO: Report 'Report 2 - Daily Summary' completed. Creating output... 2011/07/29 00:01:23 ossec-monitord: INFO: Report 'Report 1 - Daily Summary' completed. Creating output... 2011/07/29 00:01:31 ossec-monitord: WARN: Report taking too long to complete. Waiting for it to finish... 2011/07/29 00:01:37 ossec-monitord: INFO: Report 'Daily Report: File Changes' completed. Creating output... 2011/07/29 00:01:51 ossec-monitord: File '/logs/alerts/2011/Jul/ossec- alerts-28.log' not found. MD5 checksum skipped. 2011/07/29 00:01:51 ossec-monitord: File '/logs/alerts/2011/Jul/ossec- alerts-28.log' not found. SHA1 checksum skipped. I think this shows the interference with log rollover time. If I can somehow change the report generation time or log rollover time, that would be best.
[ossec-list] Regex Ranges
Can you use Regex Ranges [1-5] as an example? Seems to not be processed.
[ossec-list] Re: IIS log fail
I altered this decoder to fix it to be more detailed: windows-date-format ^\d+.\d+.\d+.\d+ \S+ web-log ^(/\S* \S+) (\d+) \S+ (\d+.\d+.\d+.\d +) (\.*) (\d+) url, dstport, srcip, extra_data, id The output from your sample above, using my decoder is: **Phase 1: Completed pre-decoding. full event: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;rv: 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' hostname: 'ossec-server' program_name: '(null)' log: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;rv: 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' **Phase 2: Completed decoding. decoder: 'windows-date-format' url: '/+union+select+'+where -' dstport: '80' srcip: '172.16.1.21' extra_data: 'Mozilla/5.0+(Windows+NT+6.1;+WOW64;rv:5.0)+Gecko/ 20100101+Firefox/5.0' id: '404' On Aug 8, 7:50 am, Hermes wrote: > wtf... > works like a charme!! > > Thank you very, very much :) > > On 8 Aug., 16:43, "dan (ddp)" wrote: > > > > > > > > > I'm not an expert, but try this: > > > > > windows-date-format > > ^\d+.\d+.\d+.\d+ \S+ > > web-log > > ^\d+.\d+.\d+.\d+ (\S+) (/\S+) \S+ (\d+) > > \S+ (\d+.\d+.\d+.\d+) \S+ (\d+) > > action,url, dstport, srcip, id > > > > > On Mon, Aug 8, 2011 at 10:15 AM, Hermes wrote: > > > Hmm... > > > Here are my first results: > > > > > > > > > > > windows-date-format > > > web-log > > > true > > > ^\d+.\d+.\d+.\d+ \S+ > > > ^(\S+ \S+) \S+ \d+ \S+ (\d+.\d+.\d+.\d > > > +) > > > \S+ \S+ \S+ \S+ (\d+) > > > url, srcip, id > > > > > > > When I start the logtest, I get: > > > > **Phase 1: Completed pre-decoding. > > > full event: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select > > > +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv: > > > 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' > > > hostname: 'ubuntu' > > > program_name: '(null)' > > > log: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select > > > +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv: > > > 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' > > > > **Phase 2: Completed decoding. > > > decoder: 'windows-date-format' > > > > **Phase 3: Completed filtering (rules). > > > Rule id: '31100' > > > Level: '0' > > > Description: 'Access log messages grouped.' > > > > What I get, when logtest without my new decoder: > > > **Phase 1: Completed pre-decoding. > > > full event: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select > > > +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv: > > > 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' > > > hostname: 'ubuntu' > > > program_name: '(null)' > > > log: '2011-08-08 11:49:54 172.16.1.69 GET /+union+select > > > +'+where - 80 - 172.16.1.21 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv: > > > 5.0)+Gecko/20100101+Firefox/5.0 404 0 2 187' > > > > **Phase 2: Completed decoding. > > > decoder: 'windows-date-format' > > > > **Phase 3: Completed filtering (rules). > > > Rule id: '1012' > > > Level: '11' > > > Description: 'SQL Injection attempt' > > > **Alert to be generated. > > > > *sigh* > > > > At least the malicous URL was detected with the old decoder. Some kind > > > of regex expert out there?^^ > > > > On 8 Aug., 14:59, Hermes wrote: > > >> Thanks :) > > > >> On 8 Aug., 14:48, "dan (ddp)" wrote: > > > >> > Remember to add your decoder to local_decoder.xml so it won't be > > >> > overwritten > > >> > on upgrade. > > > >> > On Monday, August 8, 2011, Hermes wrote: > > >> > > Yes. I am already writing the new decoder^^ > > >> > > But something that really helped (and THANKS for that): > > >> > > For every log decoder, there is an example directly above, so I can > > >> > > instantly compare differences, without installing IIS5 and IIS6. > > > >> > > On 8 Aug., 14:39, "dan (ddp)" wrote: > > >> > >> Run the log message through ossec-logtest. Decoders.xml has > > >> > >> examples, and > > >> > >> they don't appear to be in the same format as the log you posted. > > > >> > >> On Monday, August 8, 2011, Hermes wrote: > > >> > >> > _Sorry_ for the double post!! > > > >> > >> > The more I appreciate the answers! > > >> > >> > Is there something weird with the log file? Because, shouldn't it > > >> > >> > already be in IIS style, ready for decode? > > > >> > >> > On 8 Aug., 14:28, "dan (ddp)" wrote: > > >> > >> >> On Mon, Aug 8, 2011 at 8:08 AM, Hermes > > >> > >> >> wrote: > > >> > >> >> > Hello again! > > > >> > >> >> > After successfully troubleshooted another problem, here is a > > >> > >> >> > new > > >> > one. > > > >> > >> >> > First I will provide all necessary logs (etc), then I will > > >> > >> >> > post my > > >> > >> >> > problem: > > > >> > >> >> > Ossec WUI output on the manager (ubuntu): > > >> > >> >> > 2011 Aug 08 04
[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: 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] Re: Monitoring Command Output : is there a line number limitation
The alerts.log contains both the output and previous output. The email does not. Whats the log_all option you refer to? I couldnt find any reference to it online. On Dec 19, 4:36 pm, "dan (ddp)" wrote: > 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: how to monitor the ossec agent status
We had to do that also, since we found it difficult to make sure machines were communicating correctly. Like the server looking for ossec agent errors in its own log, and also when an agent fails to look at a log file it's supposed to, we would trigger an agent restart command (agent_control) from the server so that the agent would see the new log (for log rollovers). On Dec 19, 6:23 pm, "dan (ddp)" wrote: > 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: Monitoring Command Output : is there a line number limitation
So what does logall do? How does that relate to the email getting chopped off? On Dec 20, 9:01 am, "dan (ddp)" wrote: > On Tue, Dec 20, 2011 at 11:52 AM, BP9906 wrote: > > The alerts.log contains both the output and previous output. The email > > does not. > > > Whats the log_all option you refer to? I couldnt find any reference to > > it online. > > I meant logall. I apparently get those mixed up. > > > > > > > > > On Dec 19, 4:36 pm, "dan (ddp)" wrote: > >> 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
Ah yes, I see what you're talking about now, but I can see from the alerts.log file that it does contain the whole output current and previous. Seems like email isnt getting the whole thing in the body. On Dec 20, 11:09 am, "dan (ddp)" wrote: > On Tue, Dec 20, 2011 at 1:57 PM, BP9906 wrote: > > So what does logall do? How does that relate to the email getting > > chopped off? > > The idea was to see if the output is chopped off before it gets to the > manager or after. > > http://www.ossec.net/doc/syntax/head_ossec_config.global.html#element... > > > > > > > > > On Dec 20, 9:01 am, "dan (ddp)" wrote: > >> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 wrote: > >> > The alerts.log contains both the output and previous output. The email > >> > does not. > > >> > Whats the log_all option you refer to? I couldnt find any reference to > >> > it online. > > >> I meant logall. I apparently get those mixed up. > > >> > On Dec 19, 4:36 pm, "dan (ddp)" wrote: > >> >> 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] Syscheck Ignore sregex not working
How do I ensure that I ignore these log files? I have apache log files that are ending with a date/time in the filename. The below isnt working for some reason. /var/www/log/httpd_access.log.* I also tried /var/www/log/httpd_access.log.\d+ but that didntn work either. Its in agents.conf file. no 21600 /var/www/log/ /var/www/log/httpd_access.log.* ... Any suggestions?
[ossec-list] Re: Syscheck Ignore sregex not working
I only tried that after /var/www/log/ httpd_access.log.\d+ failed to do the job. Suggestions? On Dec 21, 11:23 am, "dan (ddp)" wrote: > On Wed, Dec 21, 2011 at 1:47 PM, BP9906 wrote: > > How do I ensure that I ignore these log files? > > > I have apache log files that are ending with a date/time in the > > filename. The below isnt working for some reason. > > > /var/www/log/httpd_access.log.* > > That's not proper sregex. > > > > > > > > > I also tried /var/www/log/httpd_access.log.\d+ but that didntn work > > either. > > > Its in agents.conf file. > > > > > > > no > > 21600 > > > /var/www/log/ > > /var/www/log/httpd_access.log.* > > > > > ... > > > Any suggestions?
[ossec-list] Re: Syscheck Ignore sregex not working
Thanks. I didnt see the sregex reference at the bottom, I obviously was looking at the regex only part. :) On Dec 21, 12:50 pm, "dan (ddp)" wrote: > On Wed, Dec 21, 2011 at 3:00 PM, BP9906 wrote: > > I only tried that after /var/www/log/ > > httpd_access.log.\d+ failed to do the job. > > > Suggestions? > > http://www.ossec.net/doc/syntax/regex.html#os-match-sregex-syntax > > > > > > > > > On Dec 21, 11:23 am, "dan (ddp)" wrote: > >> On Wed, Dec 21, 2011 at 1:47 PM, BP9906 wrote: > >> > How do I ensure that I ignore these log files? > > >> > I have apache log files that are ending with a date/time in the > >> > filename. The below isnt working for some reason. > > >> > /var/www/log/httpd_access.log.* > > >> That's not proper sregex. > > >> > I also tried /var/www/log/httpd_access.log.\d+ but that didntn work > >> > either. > > >> > Its in agents.conf file. > > >> > > >> > > >> > no > >> > 21600 > > >> > /var/www/log/ > >> > /var/www/log/httpd_access.log.* > > >> > > >> > ... > > >> > Any suggestions?
[ossec-list] Re: Monitoring Command Output : is there a line number limitation
Try putting this into your agent.conf file on the ossec server for your Windows machine(s). Its a good test if you do it against a machine with many ports open. Perhaps you could setup a Windows DC to test with? full_command netstat -anp tcp | find "LISTEN" | find /V "127.0.0.1" Use this rule in your local_rules.xml: 530 ossec: output:\.*netstat -an Listened ports have changed. For internal-options.conf, I have the following maild options set: maild.strict_checking=1 maild.groupping=0 maild.full_subject=1 Thank you. On Dec 22 2011, 5:49 am, "dan (ddp)" wrote: > On Thu, Dec 22, 2011 at 4:59 AM, alsdks wrote: > > Hi Dan, > > > So it seems that the output is chopped off before it gets to the > > manager .The limitation on ossec agent ? > > > Thank you > > There are conflicting reports on this, so it's up to me to test it. > When I find time and interest. > > > > > > > > > On Dec 20, 11:34 pm, BP9906 wrote: > >> Ah yes, I see what you're talking about now, but I can see from the > >> alerts.log file that it does contain the whole output current and > >> previous. Seems like email isnt getting the whole thing in the body. > > >> On Dec 20, 11:09 am, "dan (ddp)" wrote: > > >> > On Tue, Dec 20, 2011 at 1:57 PM, BP9906 wrote: > >> > > So what does logall do? How does that relate to the email getting > >> > > chopped off? > > >> > The idea was to see if the output is chopped off before it gets to the > >> > manager or after. > > >> >http://www.ossec.net/doc/syntax/head_ossec_config.global.html#element... > > >> > > On Dec 20, 9:01 am, "dan (ddp)" wrote: > >> > >> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 wrote: > >> > >> > The alerts.log contains both the output and previous output. The > >> > >> > email > >> > >> > does not. > > >> > >> > Whats the log_all option you refer to? I couldnt find any reference > >> > >> > to > >> > >> > it online. > > >> > >> I meant logall. I apparently get those mixed up. > > >> > >> > On Dec 19, 4:36 pm, "dan (ddp)" wrote: > >> > >> >> 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: How to trigger cascading alerts
You could use this ossec default rule as a way to create it. This rule triggers when the "attacks" group gets triggered 4 times (frequency + 2) within 300 seconds (5 minutes) AND the group "adduser" is triggered. adduser attacks Attacks followed by the addition of an user. On Dec 30 2011, 12:08 pm, Phil Cox wrote: > Anyway to use OSSEC to write a rule that would alert on the following: > > "If > X failed SSH login attempts, then Success -> Send alert" > > Any pointers are appreciated. > > Phil > -- > Director of Security and Compliance > RightScale Inc -http://www.rightscale.com > 805-243-0942 > Skype: phil.cox.rs > Twitter: @sec_prof
[ossec-list] Re: How to trigger cascading alerts
Also, this rule already exists: authentication_success authentication_failures Multiple authentication failures followed by a success. On Jan 3, 3:25 pm, BP9906 wrote: > You could use this ossec default rule as a way to create it. This rule > triggers when the "attacks" group gets triggered 4 times (frequency + > 2) within 300 seconds (5 minutes) AND the group "adduser" is > triggered. > > > > adduser > attacks > Attacks followed by the addition > of an user. > > > > On Dec 30 2011, 12:08 pm, Phil Cox wrote: > > > > > > > > > Anyway to use OSSEC to write a rule that would alert on the following: > > > "If > X failed SSH login attempts, then Success -> Send alert" > > > Any pointers are appreciated. > > > Phil > > -- > > Director of Security and Compliance > > RightScale Inc -http://www.rightscale.com > > 805-243-0942 > > Skype: phil.cox.rs > > Twitter: @sec_prof
[ossec-list] Re: Monitoring Command Output : is there a line number limitation
Right, I'm pointing out here that there is a line limitation on ossec emailing of result output. You're saying that the rule processing must have a limitation shorter as permissions on files beginning with D are not alerting. I added it to the thread because it is relevant that there are several "line number limitations" (your subject line) around command output monitoring. Hope that adds clarity to those watching. On Jan 4, 5:58 am, alsdks wrote: > BP9906 I do not have an issue with a netstat command . Please read > again my first post . > I was asking if there is a limitation to a command's output in how > many lines can it be . > > The conclusion is that there is definetelly a line number limitation > which restricts the use of commands that their output is big.Whether > this limitation can be > modified or not , I do not know . > > Anyway if you want to continue your case with netstat email output > please open another thread. > > Thank you > > On Jan 4, 3:30 pm, "dan (ddp)" wrote: > > > > > > > > > On Tue, Jan 3, 2012 at 6:21 PM, BP9906 wrote: > > > Try putting this into your agent.conf file on the ossec server for > > > your Windows machine(s). Its a good test if you do it against a > > > machine with many ports open. Perhaps you could setup a Windows DC to > > > test with? > > > That's out of my budget at the moment. > > > > > > > full_command > > > netstat -anp tcp | find "LISTEN" | find /V "127.0.0.1" > > command> > > > > > > > Use this rule in your local_rules.xml: > > > > > > > 530 > > > ossec: output:\.*netstat -an > > > > > > Listened ports have changed. > > > > > > > For internal-options.conf, I have the following maild options set: > > > > maild.strict_checking=1 > > > maild.groupping=0 > > > maild.full_subject=1 > > > > Thank you. > > > > On Dec 22 2011, 5:49 am, "dan (ddp)" wrote: > > >> On Thu, Dec 22, 2011 at 4:59 AM, alsdks wrote: > > >> > Hi Dan, > > > >> > So it seems that the output is chopped off before it gets to the > > >> > manager .The limitation on ossec agent ? > > > >> > Thank you > > > >> There are conflicting reports on this, so it's up to me to test it. > > >> When I find time and interest. > > > >> > On Dec 20, 11:34 pm, BP9906 wrote: > > >> >> Ah yes, I see what you're talking about now, but I can see from the > > >> >> alerts.log file that it does contain the whole output current and > > >> >> previous. Seems like email isnt getting the whole thing in the body. > > > >> >> On Dec 20, 11:09 am, "dan (ddp)" wrote: > > > >> >> > On Tue, Dec 20, 2011 at 1:57 PM, BP9906 wrote: > > >> >> > > So what does logall do? How does that relate to the email getting > > >> >> > > chopped off? > > > >> >> > The idea was to see if the output is chopped off before it gets to > > >> >> > the > > >> >> > manager or after. > > > >> >> >http://www.ossec.net/doc/syntax/head_ossec_config.global.html#element... > > > >> >> > > On Dec 20, 9:01 am, "dan (ddp)" wrote: > > >> >> > >> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 > > >> >> > >> wrote: > > >> >> > >> > The alerts.log contains both the output and previous output. > > >> >> > >> > The email > > >> >> > >> > does not. > > > >> >> > >> > Whats the log_all option you refer to? I couldnt find any > > >> >> > >> > reference to > > >> >> > >> > it online. > > > >> >> > >> I meant logall. I apparently get those mixed up. > > > >> >> > >> > On Dec 19, 4:36 pm, "dan (ddp)" wrote: > > >> >> > >> >> 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. > > >
[ossec-list] OSSEC Agent Disconnected - definition
I'm not trying to ask a dumb question for an obvious description, but what does "Ossec agent disconnected" mean? The obvious answer is that the agent disconnected temporarily. I get these alerts from agents off and on, and when the ossec server is very busy (remoted, monitord, and analysisd). I reviewed ossec.log files on the agents that disconnect and have found no issue listed. In fact, agent_control on ossec server shows connected and 'keep alive' date/ time are within a minute or so. So why get alerts on these? Also, why not get alerts on ossec agent reconnected? Would an agent disconnecting also lead to potential events not being received by the ossec server? I've noticed that select windows events are not making it to the ossec server, but my EPS (events per second) is only ~311 for Jan 2012. Thoughts? Thank you!
[ossec-list] Re: Exact windows event ID
Dan is right, I've found that ## wont work as well as
^## or ^##$.
(## = windows event id)
On Jan 6, 6:15 am, "dan (ddp)" wrote:
> Try:
> ^19$
>
>
>
>
>
>
>
> On Fri, Jan 6, 2012 at 8:34 AM, banjer wrote:
> > Hi, I'm trying to log Windows update events, which in Windows is Event
> > ID 19. I have had success with this rule:
>
> >
> > 18101
> > ^INFORMATION
> > 19
> > Windows Update successfully installed.
> >
>
> > OSSEC will now log typical update events such as this:
>
> > WinEvtLog: System: INFORMATION(19): Microsoft-Windows-
> > WindowsUpdateClient: SYSTEM: NT AUTHORITY: myserver.domain.foo.com:
> > Security Update for Microsoft .NET Framework 2.0 SP2 on Windows Vista
> > SP2 and Windows Server 2008 SP2 for x64 (KB2656362) {7ECDE510-
> > CD10-478B-89EC-1D7B255C3419} 104
>
> > However, it also log and informational events with 19 in the event ID,
> > such as:
>
> > WinEvtLog: Application: INFORMATION(3198): MSSQL$CAST: SYSTEM: NT
> > AUTHORITY: SEDNA.omni.imsweb.com: I/O was resumed on database
> > castmain60-vt-report_test_updated. No user action is required.
>
> > Is it possible to log an event id that is EXACTLY 19? Thanks!
[ossec-list] Re: distributed blocking
As Dan mentions, yes, you'll need rule(s) to detect/log/alert on what you're looking for, then use ossec.conf on ossec server to trigger an active-response either locally on the agent (web server where the log originated) or active-response on the ossec server. We actually do active-response on the ossec server, created a custom script that does a bunch of stuff and then issues the agent_control -b -u -f for the specific agent(s) involved. This can be particularly useful when dealing with many webservers load-balanced. On Jan 5, 12:08 pm, murf wrote: > Hello, forgive me if I'm a total noob, > but I have a particular scenario that I would like to > implement, and I'm wondering if ossec could be used-- > my first impression is that with the server/agent setup, > this might be achievable... ? > > Here it is: > > Lets say I have N hosts in a cloud. Each runs a particular > set of servers open to public access. All hosts have their > own firewall, and all hosts reside in a common IP range (big or > small). > > I've been noting that the bad guys are scanning my hosts by > IP, and usually within a few minutes, they hit each server in turn. > I have fail2ban running, and it does a fair job of picking up on the > attempts and triggering. I'm using iptables to block ip's. Sorry, I > don't > want to utter heresy ;), I'm trying to give ossec due diligence. > > What I'd like to do is, if ANY machine gets attacked, I'd like to > report back to the server, and have the server set up the blocking IP > and then have it command all the other agents to block that IP also. > > This way, the attacker might get a peek at one or two systems, > but will find nothing but a wall at all the other servers. > > Can ossec do this easily? > > murf
[ossec-list] Re: syscheck granular alerting
I'd recommend using syscheck instead of 550, 551, 552 only to get all your syscheck stuff, but your choice. On Jan 7, 11:13 am, Ross Lawrie wrote: > On 2012-01-06, at 4:52 PM, dan (ddp) wrote: > > > > > > > > > > > On Fri, Jan 6, 2012 at 7:07 PM, Ross Lawrie wrote: > >> On 12-01-06 03:09 PM, dan (ddp) wrote: > >>> On Fri, Jan 6, 2012 at 5:51 PM, Ross Lawrie wrote: > Hi, > > I've been trying to get this to work, but I'm obviously missing > something or not understanding something. What I'd like to do issue an > alert to an alternate email address should a file change occur within a > particular directory. > > From my reading, it seemed like the method to do this would be to create > a custom rule, and then have an alert based on it in the ossec.conf. > Unfortunately nothing seems to be happening... > > In local_rules.xml I've created a custom rule: > > > ... > > Change to a custom directory > /home/ross > > >>> Does this rule get triggered? > > >> Good question, I hadn't thought to track down the appropriate log file > >> (alerts.log right?). It doesn't appear to be triggered, I'm only seeing > >> the usual (550/554) ids being triggered, for example: > > >> ** Alert 1325894109.26688: mail - ossec,syscheck, > >> 2012 Jan 06 15:55:09 myhost->syscheck > >> Rule: 550 (level 7) -> 'Integrity checksum changed.' > >> Integrity checksum changed for: '/home/ross/ross-test' > >> Size changed from '47' to '13' > >> Old md5sum was: 'c3fbbd59f074b47bcdc99ddbb4af329a' > >> New md5sum is : '3ebfdcf378cc6221db90e4d6f11900f3' > >> Old sha1sum was: '491150eb08a96cd1baf222df1e4173d21800457f' > >> New sha1sum is : '76951d7c9d6b27d972c12866095cef8fca25b4e6' > > >> Does the match/regex not work against the line containing the file name? > >> I have other custom rules that seem to work (and that I've disabled as > >> part of my efforts to get this one to work, just in case they were > >> conflicting somehow) so I think I've got it in the right place. I've > >> changed the match/regex to only be against the word 'ross', just to try > >> and increase my chances, but still no luck. > > > Crud, I should have mentioned this in the previous email (but I just saw > > it). > > > Try: > > > > > 550 > > Change to a custom directory > > /home/ross > > > > > Give that a shot. > > Fantastic! I was sure I'd tried this, but obviously I missed something if I > did. Works great, thanks very much Dan.
[ossec-list] Re: Whitelisting by server
Depends on how you're whitelisting. Whitelist from Active Response? Or whitelist from rules alerting? ossec.conf whitelist is AR whitelist. There is no whitelist for rules, so you'll have to create a rule to do it. a bunch of low level rules (like 1002) IP_address IP_address2 Whitelist rule triggered That should take care of it. On Jan 9, 10:29 am, Jason 'XenoPhage' Frisvold wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > white_list is a global option in ossec.conf .. But is there an easy > way to whitelist by server? For instance, I want to whitelist some > web developer IPs on the web servers, but I don't want them > whitelisted on other servers such as database or storage servers. I > don't see a very easy way to do this, though.. > > Thoughts? > > - -- > - --- > Jason 'XenoPhage' Frisvold > xenoph...@godshell.com > - --- > > "Any sufficiently advanced magic is indistinguishable from technology.\" > - - Niven's Inverse of Clarke's Third Law > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8LMhQACgkQO80o6DJ8Uvn0+gCfWZGS1Wu6LZHoK/zO6OviRcp1 > ATsAn3ojJ1+LA7PU7x9//X1gMXcO4RI8 > =B9hT > -END PGP SIGNATURE-
[ossec-list] Re: A more specific match?
>From experience, the way it should be done is: (Untested) 5701 servername Bad protocol version identification 'quit' from UNKNOWN$ Ignore error from servername no_log STUFF1 servername Bad protocol version identification 'quit' from UNKNOWN$ Stuff1 happened 3 times in 5 min **some notes here: A) frequency is 0, but ossec logic is that it happened 2+frequency. B) Using level 0 fails on frequency alerts, so using alert 1 + no_log option will generate the outcome you expect but not log the first event. On Jan 9, 6:50 am, murf wrote: > On Jan 7, 8:42 am, "dan (ddp)" wrote: > > > On Fri, Jan 6, 2012 at 10:49 PM, murf wrote: > > > Here I am again. I have a machine where the "big brother" stuff is > > > People still use big brother? > > Apparently! > > Don't look at me-- I just secure the stuff! > > > > > > > > > > > > > > How exactly (or even roughly) would this sort of thing be achieved? > > > > murf > > > What do you have so far? > > > Untested: > > > > 5701 > > Bad protocol version identification 'quit' from UNKNOWN$ > > Ignore from bb > > > > > > > STUFF > > More than 1 STUFF in 5 minutes > > > > I'm flying blind here. I read the docs and they aren't being really > very helpful > in this regard. > > I see that if_sid, if_group, if_level, if_matched_sid gives me some > "conditionals" > on the activation of a rule, and that these can form a hierarchy. > > Do the rules ALL get tested and matched? Rule evaluation does not stop > with the > first match? > > The "if_"'s are the only way to stop conditionally stop a rule > evaluation? > > If the above is true, then maybe, just maybe, I could put something > together that > might work, but it would be nice if the above list (if_sid, etc) had > inverses, like > if_not_sid, if_not_group, etc. > > Can a rule belong to more than one group? Can I define a group in a > group? There's > no syntax definition for group in thewww.ossec.net/doc/syntaxstuff > on the ossec site. > > I see that a group option exists under . But beyond "Add > additional groupings to the alert", > there is nothing more said about it. > > As to your example, the docs do state that if you use level 0, then > the rule is tossed immediately, > and will not trigger a if_matched_sid, so, assuming the if_matched_sid > (as Chris noted), and > a level > 0, with perhaps an no_log added, then... > > I'll form my best guess at an attack after some of the above questions > are answered > > murf
[ossec-list] Importing copied log into ossec
I'm having an issue where I'm not able to import log data into OSSEC server. I created an empty file, created a cronjob to daily empty the file, restart the ossec agent, verify in ossec.log that agent sees the log, then append to the file the entries from the previous day. Debug logging on ossec agent indicates its reading the appended entries (good thing), however, when I look at the alerts.log on OSSEC server, I only get that the log file was reduced. If I echo a line to the log file, the ossec server gets it. Question here is why would ossec server alert on reduced log and not on subsequent events? Especially since when I manually echo a line to the file, it works fine.
[ossec-list] Re: Email Alerts
Try putting a space between rule id's 10201, 10202 Make sure the ossec server ossec.conf has no extra carriage returns in it too. On Jan 10, 8:02 am, "--[ UxBoD ]--" wrote: > Hi, > > I have just sent up a specific email alert in ossec.conf but the recipient is > receiving every alert! What have I mis-configured ? > > > u...@domain.com > 10201,10202 > a.client.server.com > > > > > -- > Thanks, Phil
[ossec-list] Re: Importing copied log into ossec
rm -f /var/log/ossec_import.log
touch /var/log/ossec_import.log
/var/ossec/bin/ossec-control restart
while read line
do
echo -e "${line}" >> /var/log/ossec_import.log
sleep 2
done < /var/log/customlog.tab
customlog.tab is a file that gets copied from another machine.
Ossec.conf on agent is configured to analyze /var/log/
ossec_import.log. I restart the agent to ensure it is reading that
file when its empty to start with.
Thoughts?
On Jan 9, 5:14 pm, "dan (ddp)" wrote:
> How are you appending the new entries?
>
>
>
>
>
>
>
> On Mon, Jan 9, 2012 at 7:57 PM, BP9906 wrote:
> > I'm having an issue where I'm not able to import log data into OSSEC
> > server. I created an empty file, created a cronjob to daily empty the
> > file, restart the ossec agent, verify in ossec.log that agent sees the
> > log, then append to the file the entries from the previous day. Debug
> > logging on ossec agent indicates its reading the appended entries
> > (good thing), however, when I look at the alerts.log on OSSEC server,
> > I only get that the log file was reduced.
>
> > If I echo a line to the log file, the ossec server gets it.
>
> > Question here is why would ossec server alert on reduced log and not
> > on subsequent events? Especially since when I manually echo a line to
> > the file, it works fine.
[ossec-list] Re: Importing copied log into ossec
I went about it a different way and used cronjob to netcat entries via
a syslog packet request, capture it, then ossec monitor the syslog
capture log. Does the job, but not sure why 'echo >> file' wasnt
enough for ossec server to capture it.
On Jan 10, 8:41 am, BP9906 wrote:
> rm -f /var/log/ossec_import.log
> touch /var/log/ossec_import.log
>
> /var/ossec/bin/ossec-control restart
>
> while read line
> do
>
> echo -e "${line}" >> /var/log/ossec_import.log
> sleep 2
>
> done < /var/log/customlog.tab
>
> customlog.tab is a file that gets copied from another machine.
> Ossec.conf on agent is configured to analyze /var/log/
> ossec_import.log. I restart the agent to ensure it is reading that
> file when its empty to start with.
>
> Thoughts?
>
> On Jan 9, 5:14 pm, "dan (ddp)" wrote:
>
>
>
>
>
>
>
> > How are you appending the new entries?
>
> > On Mon, Jan 9, 2012 at 7:57 PM, BP9906 wrote:
> > > I'm having an issue where I'm not able to import log data into OSSEC
> > > server. I created an empty file, created a cronjob to daily empty the
> > > file, restart the ossec agent, verify in ossec.log that agent sees the
> > > log, then append to the file the entries from the previous day. Debug
> > > logging on ossec agent indicates its reading the appended entries
> > > (good thing), however, when I look at the alerts.log on OSSEC server,
> > > I only get that the log file was reduced.
>
> > > If I echo a line to the log file, the ossec server gets it.
>
> > > Question here is why would ossec server alert on reduced log and not
> > > on subsequent events? Especially since when I manually echo a line to
> > > the file, it works fine.
[ossec-list] Syslog message not processing
I'm having difficulty trying to determine why certain syslog messages are not making it to the ossec server. I've enabled debugging in internal conf (=2) and restarted ossec server and agent that I'm looking at. I see the ossec agent log file shows: 2012/01/17 12:37:35 ossec-logcollector: DEBUG: Reading syslog message: '[ WARN] 17 Jan 2012 12:37:34 ... I dont see anything in ossec server ossec.log or any alert get generated. The interesting point is that if the message from the same log changes, then I do get an alert. 2012/01/17 12:14:43 ossec-logcollector: DEBUG: Reading syslog message: '[DEBUG] 17 Jan 2012 12:14:43 ... The differences between the messages are very slight (Warn vs debug and success vs error) are the only keyword differences. ossec-logtest for both log entries gives me my expected results so I suspect that the agent or server processes is throwing an error and ignoring the "Warn" messages. Any suggestions on how to debug? I'd like to see if ossec server is receiving the message but tcpdumps show encrypted traffic. debug=2 on all the ossec server settings dont give me any output (ossec server v2.6 and ossec agent v2.5). Thank you for your help.
[ossec-list] Re: Syslog message not processing
Thanks, so the complete message shows up in the archive.log file when I enable logall in ossec.conf on the ossec server. Now I know its not the 2.5 ossec agent. How do I see what the analysisd result is for the event? I've copy pasted the event minus the date, hostname, logfile location into the ossec-logtest and it comes out fine. If I paste the whole thing, I get Alert 1002 triggering. Thoughts? On Jan 17, 4:00 pm, "dan (ddp)" wrote: > On Tue, Jan 17, 2012 at 3:44 PM, BP9906 wrote: > > I'm having difficulty trying to determine why certain syslog messages > > are not making it to the ossec server. > > > I've enabled debugging in internal conf (=2) and restarted ossec > > /var/ossec/bin/ossec-control enable debug && > /var/ossec/bin/ossec-control restart > > > > > > > > > > > server and agent that I'm looking at. I see the ossec agent log file > > shows: > > > 2012/01/17 12:37:35 ossec-logcollector: DEBUG: Reading syslog message: > > '[ WARN] 17 Jan 2012 12:37:34 ... > > > I dont see anything in ossec server ossec.log or any alert get > > generated. The interesting point is that if the message from the same > > log changes, then I do get an alert. > > > 2012/01/17 12:14:43 ossec-logcollector: DEBUG: Reading syslog message: > > '[DEBUG] 17 Jan 2012 12:14:43 ... > > > The differences between the messages are very slight (Warn vs debug > > and success vs error) are the only keyword differences. > > > ossec-logtest for both log entries gives me my expected results so I > > suspect that the agent or server processes is throwing an error and > > ignoring the "Warn" messages. > > > Any suggestions on how to debug? I'd like to see if ossec server is > > receiving the message but tcpdumps show encrypted traffic. debug=2 on > > all the ossec server settings dont give me any output (ossec server > > v2.6 and ossec agent v2.5). > > Upgrade your agent. ;) > > Enable the log all option, look for the log message in archives.log. > > > > > > > > > Thank you for your help.
[ossec-list] Re: Syslog message not processing
I got it figured out now, after creating a different rule that was very vague. keyword Debug! keyword I would like to know if there is a way to log what analysisd's result is for an event. On Jan 18, 8:45 am, BP9906 wrote: > Thanks, so the complete message shows up in the archive.log file when > I enable logall in ossec.conf on the ossec server. Now I know its not > the 2.5 ossec agent. > > How do I see what the analysisd result is for the event? I've copy > pasted the event minus the date, hostname, logfile location into the > ossec-logtest and it comes out fine. If I paste the whole thing, I get > Alert 1002 triggering. > > Thoughts? > > On Jan 17, 4:00 pm, "dan (ddp)" wrote: > > > > > > > > > On Tue, Jan 17, 2012 at 3:44 PM, BP9906 wrote: > > > I'm having difficulty trying to determine why certain syslog messages > > > are not making it to the ossec server. > > > > I've enabled debugging in internal conf (=2) and restarted ossec > > > /var/ossec/bin/ossec-control enable debug && > > /var/ossec/bin/ossec-control restart > > > > server and agent that I'm looking at. I see the ossec agent log file > > > shows: > > > > 2012/01/17 12:37:35 ossec-logcollector: DEBUG: Reading syslog message: > > > '[ WARN] 17 Jan 2012 12:37:34 ... > > > > I dont see anything in ossec server ossec.log or any alert get > > > generated. The interesting point is that if the message from the same > > > log changes, then I do get an alert. > > > > 2012/01/17 12:14:43 ossec-logcollector: DEBUG: Reading syslog message: > > > '[DEBUG] 17 Jan 2012 12:14:43 ... > > > > The differences between the messages are very slight (Warn vs debug > > > and success vs error) are the only keyword differences. > > > > ossec-logtest for both log entries gives me my expected results so I > > > suspect that the agent or server processes is throwing an error and > > > ignoring the "Warn" messages. > > > > Any suggestions on how to debug? I'd like to see if ossec server is > > > receiving the message but tcpdumps show encrypted traffic. debug=2 on > > > all the ossec server settings dont give me any output (ossec server > > > v2.6 and ossec agent v2.5). > > > Upgrade your agent. ;) > > > Enable the log all option, look for the log message in archives.log. > > > > Thank you for your help.
[ossec-list] Re: E-mail alerting
Some rules in ossec are designed to notify you regardless. Rule 1002 is one of them. You'd have to overwrite the rule (use your local_rules.xml). $BAD_WORDS Unknown problem somewhere in the system. Just make sure you define $BAD_WORDS at the top of your local_rules.xml too. Problem is that you might miss something worthwhile because of a bad decoder or rule. Thats why 1002 is set to alert by default. On Jan 21, 10:51 am, Hugo Deprez wrote: > yes that's right. > So this rule will always send e-mail ? > > I'll try to correct all the error reported by this rule, but it's not > always easy thing to do. > > Thank you for the answer ! > > Hugo > > On 21 January 2012 18:18, dan (ddp) wrote: > > > > > > > > > On Sat, Jan 21, 2012 at 8:30 AM, Hugo Deprez wrote: > >> Dear community, > > >> I just setup a ossec server with the following e-mail alerting settings : > > >> > >> > >> yes > >> m...@domain.com > >> smtp.domain.com > >> ossec-ser...@domain.com > >> > > >> > >> 1 > >> 7 > >> > > >> I am still receinving e-mail alerts for level 2 for example. > >> Does the log_alert_level parameter doing this ? > > >> Regards, > > >> Hugo > > > Rule 1002 perhaps? It has an option set to always email.
[ossec-list] Re: syscheck and ignored directories
Your ignore syntax for ossec.conf might be a bit off. Try this: ^/etc/something That will ignore anything that starts with /etc/something. Then restart the agent of course to take effect. On Jan 21, 7:16 am, Julien Vehent wrote: > On Fri 20.Jan'12 at 22:12:00 -0800, SuilAmhain wrote: > > > Add an ignore rule to ossec.conf. Reststart ossec after adding it. > > Had you read my email, you would have noticed that this has been done > already, before following syscheckd's activity with strace. > > - Julien
[ossec-list] Re: Linux Management Server, Windows Agents, streamline config files from manager
Word of advice too. When you make changes to the agent.conf on the
ossec server, it takes a few minutes to copy down to the agents. Then
you have to somehow remember to restart all the agents to re-read the
newly copied agent.conf file. To restart all the agents, you can do
something like this:
for i in `/var/ossec/bin/agent_control -l | grep "ID:" | awk '{print
$2}' | sed 's/.$//'`; do /var/ossec/bin/agent_control -R $i; sleep 2;
done
On Jan 23, 12:11 pm, AlexD wrote:
> It worked.
> Thanks for your help! :-)
>
> Alex
>
> On Jan 12, 9:44 am, Andy Jack wrote:
>
>
>
>
>
>
>
> > 'md5sum' is usually the command for getting md5 checksum of a file on
> > linux, e.g.:
>
> > md5sum file.txt
>
> > According to the documentation, you should see the md5sum of the
> > agent.conf that the agent has in the agent_control -i output.
> > To test that this works you could add something trivial (e.g. xml
> > comment) to the agent.conf on the linux server, get the updated md5sum,
> > and wait for the new md5sum to appear on the windows agent (or restart
> > ossec on the linux server). I think you'd also see the modification
> > time of the file change on the windows agent when it is updated.
>
> > Andy
>
> > On Thu, Jan 12, 2012 at 09:08:33AM -0800, AlexD wrote:
> > > I tried that but when I check the md5 checksum and issue the command
> > > md5 /var/ossec/etc/shared/agent.conf it says command not found. How
> > > will I know if my agent.conf file is being pushed across my agents?
> > > And if it does, will it update a file on the Windows side or not?
>
> > > Thanks,
>
> > > Alex
>
> > > On Jan 11, 10:11 am, Andy Jack wrote:
> > > > Hello, I think this is what you're after:
>
> > > >http://www.ossec.net/doc/manual/agent/agent-configuration.html
>
> > > > Andy
>
> > > > On Wed, Jan 11, 2012 at 09:33:58AM -0800, AlexD wrote:
> > > > > Hi everybody and thanks for you help!
>
> > > > > So, I have this architecture:
>
> > > > > - 1 linux server with OSSEC HIDS 2.6 installed
> > > > > - several Windows boxes where I need to deploy the agents
>
> > > > > I would like to know if there is a way to have a centralized
> > > > > configuration file on the linux server that then gets "pushed" to all
> > > > > the windows agents. Also, I believe I will have to go and manually
> > > > > install the Windows agents manually on every single box (or maybe
> > > > > using a script).
>
> > > > > Moreover, since if this architecture will work I will add Linux agents
> > > > > as well, is it possible to have two configuration files on the
> > > > > management server so that the Linux boxes point at the linux config
> > > > > and the Windows boxes point at the windows config?
>
> > > > > Thanks,
>
> > > > > AlexD =)
[ossec-list] Re: Problem Reading Windows log files on Server 2008 R2 SP1
What agent version is it? You could try enabling debugging for the agent and see what ossec.conf says. I know I ran into issues w/ ossec 2.6 agent so I use 2.5.1 until another version comes out. On Jan 24, 7:39 am, btsteve wrote: > We are running windows server 2008 r2 SP1, and our logfiles are > located in: > > C:\inetpub\logs\LogFiles\W3SVC1 > C:\inetpub\logs\LogFiles\W3SVC2 > C:\inetpub\logs\LogFiles\W3SVC3 > C:\inetpub\logs\LogFiles\W3SVC4 > C:\inetpub\logs\LogFiles\W3SVC5 > C:\inetpub\logs\LogFiles\W3SVC6 > > When ever we try and read logfiles from this location it fails with > error 1103 unable to open file. If we place it in a different > directory we do not have a problem. > > We have checked the permissions and OSSEC is set to run as the system > account and the system account has full control over the directory. We > have tried running it as a user that is a member of the administrators > group. Either way we get the same result. > > Has anyone else encountered this problem? > > Thanks
[ossec-list] Re: syscheck and ignored directories
No, that option does tell syscheckd to ignore that entire folder and subcontents. If you have windows, I believe its different. See http://www.ossec.net/main/manual/manual-syscheck#examples On Jan 24, 11:03 am, Julien Vehent wrote: > On Mon 23.Jan'12 at 11:46:17 -0800, BP9906 wrote: > > > Your ignore syntax for ossec.conf might be a bit off. > > > Try this: > > > ^/etc/something > > > That will ignore anything that starts with /etc/something. Then > > restart the agent of course to take effect. > > That will ignore the alerts, but not prevent syscheckd from browsing > that directory, which is the issue. > > The ignore rule works fine: content of that directory does not generate > alerts. But my problem is with syscheckd scanning a 12TB NFS share. > > - Julien
[ossec-list] Re: Script assistance
Well, you could start with using a rule for that user first. Then you could change the "2" option you're using to 11, assuming that's your rule ID. Then you can just configure the script to do something, either block the IP, lock the user account, etc. Hope that helps. On Jan 25, 1:38 pm, "Carrie Poole" wrote: > I'm trying to set an Active Response alert based on a particular user > login, and I'm not sure how to write the script. > > Anyone out there have any ideas? > > What I need it to do is email an alert when a certain user account logs > into any one of the agents. > > I think I got the command config and active response config correct, but > I don't know how to write the script so it sets off on only that user: > > > > beeper-login-Notification > > beeper-login.sh > > username > > no > > > > > > no > > beeper-login-Notification > > all > > 2 > > authentication_success > > > Carrie Poole, > > Network Engineer > > (610) 821-8980 ext 559 > > (610)841-5559 (Direct) > > Fax: (610)821-1245 > > carrie.po...@andesaservices.com > > CONFIDENTIALITY NOTICE: This e-mail is confidential and intended > solely for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, be advised that you have received > this email in error and that any use, dissemination, forwarding, printing > or copying of this e-mail is strictly prohibited. If you received this e-mail > in error, please delete it from your computer and contact the sender. > > image001.gif > 4KViewDownload
[ossec-list] Re: Agents cannot connect to server
Could it be because you have multiple source IPs? Try creating a new agent on the server and use the subnet. manage_agents, a, hostname, 192.168.1.0/24, y. Then import the new key generated and see if that helps. That would confirm source IP origination is the problem. Else, use wireshark or tcpdump on agent and server to look for 1514 packets sent/received. On Jan 25, 12:35 pm, Steve Kuntz wrote: > I have communication issues between my server and agents. > > All agents on the servers subnet can connect to the server. > > I have agents on other subnets which I've tried to configure in > different ways and they can't connect to the server > > 2012/01/25 15:25:51 ossec-agent: INFO: Trying to connect to server > (10.100.10.11:1514). > 2012/01/25 15:25:51 ossec-agent: INFO: Using IPv4 for: 10.100.10.11 . > 2012/01/25 15:26:12 ossec-agent(4101): WARN: Waiting for server reply > (not started). Tried: '10.100.10.11'. > > No entries in the log of the server ossec.log for this. > No client firewall running. > > There is a firewall between the subnets so I opened 1514 between them > but I still had the communication issue. I tried to get around this by > adding an interface for the other subnets on the ossec server with IPs > on those subnets and pointing the agents to the IP on their subnet. I > get the same result above. I haven't been able to find anything. Any > help is appreciated. > > OSSEC HIDS v2.6
[ossec-list] Re: Agents cannot connect to server
Check the ossec.log file on the server? Just curious if there's any issue there. Else, you'll probably have to enable debugging on both sides to see whats going on. On Jan 26, 8:56 am, Scott VR wrote: > On Jan 26, 2012, at 9:26 AM, Steve Kuntz wrote: > > > I'm reluctant to install wireshark on the agent at this point. > > It may be your quickest path to a resolution, though. That or a span/mirror > port on the switch. > Check the routing table on the server to see how traffic is sent back *to* > the server. Run a tcpdump on all interfaces on the server for traffic > destined *to* the client; it may be that traffic the other direction is > trying to go out a different interface. > > --ScottVR
[ossec-list] Re: OSSEC server No Daily Reports
I found that my reports in ossec server 2.5.1 dont run because of a race condition where log rollover happens before the reports generate so there's no file and thus no results. ossec.log file will show that. I found that by creating a cronjob that runs a daily report shell script runs all my reports and emails them to be more effectively. On Feb 6, 3:46 am, "dan (ddp)" wrote: > On Thu, Feb 2, 2012 at 8:53 PM, Macus wrote: > > "..." means Ellipsis. > > I think the syntax is valid, because I have received the report daily > > for over a month. However, I couldn't receive it sometimes starting > > I missed that in your original mail, my apologies. > > > from last week. "No report" mean no alert? > > Possibly. Run it manually and check. Also check for report temporary > files (.reportSOMETHING or something like that, somewhere in > /var/ossec, I can't remember specifics and can't check at the moment). > > > > > > > > > On 2月2日, 下午9時04分, "dan (ddp)" wrote: > >> On Tue, Jan 31, 2012 at 8:42 PM, Macus wrote: > >> > I have setup a daily report like below for the syscheck. it is > >> > supposed to have the report delivered to my mailbox? The syscheck is > >> > scheduled daily at 20:00 > > >> > > >> > syscheck > >> > OSSEC Daily Report: File Integrity Check Result > >> > ... > >> > ... > > >> I don't think "..." is valid syntax. > > >> > yes > >> > > > >> > thanks.
[ossec-list] Syscheck agent.conf multiple start times
Is it possible to have multiple start times for Syscheck? I tried 05:00,11:00,18:00 but the ossec agent complains about it. I'm going to try 05:00 11:00 18:00 Just trying to find a happy medium here. The problem is that if I use frequency to every 6-7 hrs it causes a UDP storm from 30+ machines for syscheck data on top of the usual alert sending. I've maxed out the buffer size on my linux kernel, ossec server agent count is very high, and the server can handle it, just that there's so much that the ossec server doesnt read the buffer fast enough for the data coming through so I get intermittent results/ data for the roughly 30 min window while all these machines send their syscheck results. It would be nice to be able to give syscheck a random 2hr window to the start time to reduce this chance, or to be able to stagger out the machines in separate agent.conf configs based on multiple start times.
[ossec-list] Re: full_command examples
May seem a bit rudimentary but this helps to make sure your ossec log and active response log doesnt chew up space. I do both for Windows and Linux. Then I alert if their sizes are over a certain size. Its helpful for systems with low space in /var or low space on C (if you install it there). full_command dir *.log | find ".log" 3600 full_command du -ah /var/ossec/logs 3600 On Feb 8, 1:50 pm, "dan (ddp)" wrote: > Does anyone have any interesting full_command examples they want to > share? I'd love to include a few in the documentation. So if you have > anything new and unique let's see it! I'm especially looking for > Windows examples. I don't really have anything applicable to Windows > except a basic netstat. > > dan
[ossec-list] Re: Syscheck agent.conf multiple start times
Yeah I agree. The random window is good. Would be good if it was configurable though because that window might not amount to much if you have a lot of agents at a particular interval. I think having an hour random time for me should be sufficient, but others might not like a whole hour. On Feb 10, 5:34 am, "dan (ddp)" wrote: > On Thu, Feb 9, 2012 at 3:04 PM, BP9906 wrote: > > Is it possible to have multiple start times for Syscheck? > > > I tried > > 05:00,11:00,18:00 > > > but the ossec agent complains about it. > > I'm going to try > > 05:00 > > 11:00 > > 18:00 > > > Just trying to find a happy medium here. > > > The problem is that if I use frequency to every 6-7 hrs it causes a > > UDP storm from 30+ machines for syscheck data on top of the usual > > alert sending. I've maxed out the buffer size on my linux kernel, > > ossec server agent count is very high, and the server can handle it, > > just that there's so much that the ossec server doesnt read the buffer > > fast enough for the data coming through so I get intermittent results/ > > data for the roughly 30 min window while all these machines send their > > syscheck results. > > > It would be nice to be able to give syscheck a random 2hr window to > > the start time to reduce this chance, or to be able to stagger out the > > machines in separate agent.conf configs based on multiple start times. > > I like the randomized start time idea. Something like "run every 6-ish > hours, but start 1-30 minutes after the 6 hour mark."
[ossec-list] Re: Syscheck agent.conf multiple start times
Added it to bitbucket. https://bitbucket.org/dcid/ossec-hids/issue/35/syscheck-agentconf-configurable-random Hopefully something we could get added in a near release. :) On Feb 14, 7:18 am, "dan (ddp)" wrote: > Agree, 100%. > > > > > > > > On Fri, Feb 10, 2012 at 6:23 PM, BP9906 wrote: > > Yeah I agree. The random window is good. Would be good if it was > > configurable though because that window might not amount to much if > > you have a lot of agents at a particular interval. I think having an > > hour random time for me should be sufficient, but others might not > > like a whole hour. > > > On Feb 10, 5:34 am, "dan (ddp)" wrote: > >> On Thu, Feb 9, 2012 at 3:04 PM, BP9906 wrote: > >> > Is it possible to have multiple start times for Syscheck? > > >> > I tried > >> > 05:00,11:00,18:00 > > >> > but the ossec agent complains about it. > >> > I'm going to try > >> > 05:00 > >> > 11:00 > >> > 18:00 > > >> > Just trying to find a happy medium here. > > >> > The problem is that if I use frequency to every 6-7 hrs it causes a > >> > UDP storm from 30+ machines for syscheck data on top of the usual > >> > alert sending. I've maxed out the buffer size on my linux kernel, > >> > ossec server agent count is very high, and the server can handle it, > >> > just that there's so much that the ossec server doesnt read the buffer > >> > fast enough for the data coming through so I get intermittent results/ > >> > data for the roughly 30 min window while all these machines send their > >> > syscheck results. > > >> > It would be nice to be able to give syscheck a random 2hr window to > >> > the start time to reduce this chance, or to be able to stagger out the > >> > machines in separate agent.conf configs based on multiple start times. > > >> I like the randomized start time idea. Something like "run every 6-ish > >> hours, but start 1-30 minutes after the 6 hour mark."
[ossec-list] Username report fields (srcuser and dstuser)
Hi Dan, I used your custom windows-sub1 filter to properly decode usernames for all the various contexts of windows event logs. It works great, however, I end up with 2 username fields (ie srcuser and dstuser). OSSEC treats srcuser as username and thus I dont see a way to include the dstuser to see the top entries for dstuser. Is there a way to include this currently? If not, I'll post a request on the bug tracking site. Thanks!
Re: [ossec-list] Re: Large installs.
I suppose size is relative to the amount of data you have too. I dont quite have 1000 hosts, but OSSEC reports 1287103.2 events per hour. Yes 1.2 million events per hour. I'm pretty certain that I've hit the OS cap on UDP packet volume at times during peak data sending times. This is usually due to Syscheck running during already busy times. I would recommend to ensure your ossec server(s) have a higher increased UDP buffer size (sysctl -A) for the OS. Thats of course on top of the previously mentioned agent size increasing. I've had to be creative for syscheck to break it up into chunks otherwise I potentially miss data (downside to UDP) and group into separate OSSEC servers (though the downside is not being able to take data very easily from 1 ossec server env and perform active response on another ossec server). I do have a feature request to allow syscheck to be performed during a random window so you can spread out the volume of results back to the server. Also, the agent disconnected alerts in volume are an indication of UDP traffic so I would recommend keeping it, but perhaps doing a threshold rule. Hope that helps. On Friday, April 6, 2012 7:39:54 AM UTC-7, Zate wrote: > > That helps immensely, it's pretty much exactly what we are looking to > build, right down to us using splunk and puppet and about the same amount > of hosts in the same amount of locations. > > Thanks a lot. > > Zate > > > On Sun, Apr 1, 2012 at 6:22 AM, Kat wrote: > >> 4 installs -- >> 1700 hosts >> 1200 hosts >> 1340 hosts >> and 900 (oops, that is not over 1000, but close) >> >> Use puppet to manage deployments rather than OSSEC itself. Also, >> puppet maintains more than just agent.conf. Splunk on the backend with >> "Splunk for OSSEC" app handling all the "details". Also, because >> this was large mixed platform of Linux, Hp-UX, AIX, Solaris and >> Windoze, puppet made things much easier. >> >> Biggest problem was the constant alerts of disconnected agents, when >> they really weren't. This was caused mostly by the load and short >> check times in the agent/server codes. I found some patches to bump >> that up, but in the beginning I just disabled the "Agent disconnected" >> rules, which also worked. >> >> ** Maybe a note to developers -- as the agent count goes up - set up >> check-in timers that go up with the agent count. It would avoid a lot >> of false-positives on these alerts. >> >> My biggest issue was with reporting, which is why Splunk was added to >> the mix. This gives the flexibility needed to support both SOC type >> engineers as well as auditors requests, and once the reports are >> defined, they can modify them easily enough for their needs with just >> a little training. >> >> Hope this helps - if you have questions, just ask and I will try to >> answer. >> >> ~K >> > >
[ossec-list] Re: List blocked IPs without using iptables
I think the answer is no. When I use null route to block an IP for a given agent, if I manually remove that null route for an IP (i dont know if the null route was there previous to ossec agent null routing it), then the agent wont re-null route the IP until the timeout has happened or I restart the agent. Perhaps the answer for you is to use a block mechanism that is unique to ossec agent and not anything else. Sorry I couldnt help more. On Thursday, April 5, 2012 8:08:15 AM UTC-7, Joel Oliveira wrote: > > Hello, > > Just bumping this issue. Does anyone know anything about this? > > Thanks, > Joel Oliveira > > Quarta-feira, 21 de Março de 2012 16h58min44s UTC, Joel Oliveira escreveu: >> >> Hello Daniel and all, >> >> I am using OSSEC 2.5.1 on different Linux environments for the past year >> and half with OpenSIPs and Asterisk applications to ban SIP brute-forcing >> attackers and of course it is doing its job very well. Thank you to all >> people involved with the development of this software. >> >> So, for the past 2 days I've been in a battle with having a way to check >> which IPs are blocked by OSSEC-Server in an agent. I know that if I look >> into the active-responses.log I'll see what were the actions taken in a >> certain agent ( add and delete from the Iptables ) and if I look on the >> IPTables I'll be able to see the blocked IPs as well. But in an agent that >> the IPtables are complex there is no way of making sure that I am looking >> at OSSEC inserted rules. >> >> My theory is that the server or the agent knows the association between >> the timeout, the blocked IP and the agent so that it can remove that >> active-response ( rule on the IPTable ) just after the timeout occured. >> Question is: where can I find that association, i.e where is the list of >> the blocked IPs of an agent? >> >> I already looked into this list and the IRC channel and didn't find any >> information regarding this which for me it's odd because it seems to me >> that this should be a functionality asked by a lot of people. >> >> On the same page of this problem I would like to know if it's possible to >> remove an IPTable rule without doing an "iptables -D" and without >> restarting the agent. You see, if I remove a rule "by hand", and because I >> am using timeouts of 24h, if the attacker tries again it'll send >> email_alerts but it'll not apply the active-response. So, my other question >> is: Is it possible to remove an active response before it's timeout where >> the agent is aware of that? >> >> Thank you very much for your time. Best Regards, >> Joel Oliveira >> >
[ossec-list] Re: Username report fields (srcuser and dstuser)
Actually I'm going to try to just flip/flop the fields. Using logtest on some of the events seems to show good results. If it works good, then we should change the default decoder next release. On Monday, April 9, 2012 8:50:57 AM UTC-7, BP9906 wrote: > > Hi Dan, > I used your custom windows-sub1 filter to properly decode usernames for > all the various contexts of windows event logs. It works great, however, I > end up with 2 username fields (ie srcuser and dstuser). OSSEC treats > srcuser as username and thus I dont see a way to include the dstuser to see > the top entries for dstuser. Is there a way to include this currently? If > not, I'll post a request on the bug tracking site. > > Thanks! > >
[ossec-list] Re: Syscheck agent.conf multiple start times
What does this tcp protocol option do for ossec? I thought OSSEC requires UDP traffic from ossec agents. > > Does the tcp protocol option in the remote section of the server > config affect syscheck logging from client to server? If so, would > that solve your problem?
[ossec-list] Re: Syscheck agent.conf multiple start times
After reading further about the TCP option, I dont think the TCP option will help because A) We're using Secure Option B) We're using Ossec Agent C) We're monitoring system and application logs On Monday, June 4, 2012 10:57:54 AM UTC-7, BP9906 wrote: > > What does this tcp protocol option do for ossec? I thought OSSEC requires > UDP traffic from ossec agents. > >> >> Does the tcp protocol option in the remote section of the server >> config affect syscheck logging from client to server? If so, would >> that solve your problem? > >
[ossec-list] Re: Multiple cores?
Kat, Did you just work around the issue by having many ossec instances? Or did you somehow get beyond the CPU issue? Thanks for your help! Brian On Thursday, December 8, 2011 8:45:42 AM UTC-8, Kat wrote: > > Yep -- sending 1800 agents to a single server so it has a lot to > analyze. I am finding that this causes many of the agents to show > "disconnected" because they can't get to the server while it is > processing very busy nodes. So rather than throw additional servers at > it, I have all the cores, but I am maxing out a single core and the > others just sit there. :-( > > On Dec 8, 9:09 am, "dan (ddp)" wrote: > > OSSEC isn't really built for multiple cores. Are you pushing enough > > data through it to consume a whole core? How many eps? > > > > > > >
[ossec-list] ossec-monitord memory usage - log rollover
Hello, I'm running ossec server 2.6 and at log roll over my alerts.log is ~12GB. Ossec-monitord seems to consume a whole bunch of memory and IO to the point the system is unresponsive and the console shows swap completely used. System has 8GB memory and swap. Any idea what would cause this? Would 2.7 fix this? After rebooting the system, I had available memory and disk space and the system continued as normal, except that /var/ossec/logs/alerts/2013/Jan/ossec-alerts-05.log was uncompressed. Thank you! Log entry: Jan 6 00:18:42 kernel: Out of memory: Killed process 27993, UID 502, (ossec-monitord).
[ossec-list] geoip - cannot open shared object file: No such file or directory
I followed these instructions: http://www.ossec.net/files/ossec-hids-2.7-release-note.txt After compiling and installing it errors on start up: /var/ossec/bin/ossec-logtest: error while loading shared libraries: libGeoIP.so.1: cannot open shared object file: No such file or directory Any suggestions? I have GeoIP installed and see that file here: /usr/local/lib/libGeoIP.so.1 I confirmed its a symlink to the latest version and permissions are set properly on symlink and binary. Thoughts?
[ossec-list] Re: ossec-monitord memory usage - log rollover
I updated to OSSEC 2.7 and it resolved the issue. On Sunday, January 6, 2013 7:06:47 AM UTC-8, BP9906 wrote: > > Hello, > I'm running ossec server 2.6 and at log roll over my alerts.log is ~12GB. > Ossec-monitord seems to consume a whole bunch of memory and IO to the point > the system is unresponsive and the console shows swap completely used. > System has 8GB memory and swap. Any idea what would cause this? Would 2.7 > fix this? > > After rebooting the system, I had available memory and disk space and the > system continued as normal, except that > /var/ossec/logs/alerts/2013/Jan/ossec-alerts-05.log was uncompressed. > > Thank you! > > Log entry: Jan 6 00:18:42 kernel: Out of memory: Killed > process 27993, UID 502, (ossec-monitord). > > >
Re: [ossec-list] geoip - cannot open shared object file: No such file or directory
Thanks. Added: /usr/local/lib to /etc/ld.so.conf and ran /sbin/ldconfig. Verified it is there in /sbin/ldconfig -v | grep -i geo All set, thanks! Redhat Linux was the culprit.
[ossec-list] OSSEC Server 2.7 - Active Responses intermittent
Hello, I recently upgraded my ossec server to 2.7 and everything is working great. The weird issue I'm having is that the active responses sometimes dont fire. Its very intermittent because I get email spam for my Rule that is supposed to trigger a null-route. I check the server's active-responses.log and it shows no entries, though previously in the same day (couple hours ago) I see entries for the same rule number. Any suggestions on helping determine why the ossec server couldnt spawn my active response for the rule? Thank you, Brian -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Re: Basic OSSEC Configuration for Web Servers / Website Security
Nice write up. Saw a typo just below this in the rule sample you give. The category end tag got remoed. "In that file you'll find this rule:" -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Re: OSSEC Server 2.7 - Active Responses intermittent
Good point. For clarity, my AR is set for server execution. It then launches a shell script that then loops through a set of servers in a LB pool to do a null route on those servers. I would then see the AR in the Ossec Server AR log and client AR log. I dont even see the AR log entry on the Ossec Server AR log. On Wednesday, March 13, 2013 1:20:06 PM UTC-7, Kat wrote: > > are you checking the right logs and do you have the ARs set for the right > place? Sometimes people forget the log entries will be in agents log files, > not the SERVER. > > > On Wednesday, March 13, 2013 10:56:34 AM UTC-7, BP9906 wrote: >> >> Hello, >> I recently upgraded my ossec server to 2.7 and everything is working >> great. The weird issue I'm having is that the active responses sometimes >> dont fire. >> Its very intermittent because I get email spam for my Rule that is >> supposed to trigger a null-route. I check the server's active-responses.log >> and it shows no entries, though previously in the same day (couple hours >> ago) I see entries for the same rule number. >> >> Any suggestions on helping determine why the ossec server couldnt spawn >> my active response for the rule? >> >> Thank you, >> Brian >> >> >> -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Re: OSSEC Server 2.7 - Active Responses intermittent
Well thats the problem, I dont get any log entry on the OSSEC server AR log so I think I need a debug config enabled to verify it is triggering an AR. What config setting do I set to see that? On Wednesday, March 13, 2013 2:40:40 PM UTC-7, dan (ddpbsd) wrote: > > On Wed, Mar 13, 2013 at 4:43 PM, BP9906 > > wrote: > > Good point. > > For clarity, my AR is set for server execution. It then launches a shell > > script that then loops through a set of servers in a LB pool to do a > null > > route on those servers. > > I would then see the AR in the Ossec Server AR log and client AR log. > > I dont even see the AR log entry on the Ossec Server AR log. > > > > Can you provide your configuration, log samples that do work, and log > samples that do not work? > > > > > On Wednesday, March 13, 2013 1:20:06 PM UTC-7, Kat wrote: > >> > >> are you checking the right logs and do you have the ARs set for the > right > >> place? Sometimes people forget the log entries will be in agents log > files, > >> not the SERVER. > >> > >> > >> On Wednesday, March 13, 2013 10:56:34 AM UTC-7, BP9906 wrote: > >>> > >>> Hello, > >>> I recently upgraded my ossec server to 2.7 and everything is working > >>> great. The weird issue I'm having is that the active responses > sometimes > >>> dont fire. > >>> Its very intermittent because I get email spam for my Rule that is > >>> supposed to trigger a null-route. I check the server's > active-responses.log > >>> and it shows no entries, though previously in the same day (couple > hours > >>> ago) I see entries for the same rule number. > >>> > >>> Any suggestions on helping determine why the ossec server couldnt > spawn > >>> my active response for the rule? > >>> > >>> Thank you, > >>> Brian > >>> > >>> > > -- > > > > --- > > 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 ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Re: OSSEC Server 2.7 - Active Responses intermittent
Hi Dan, I enabled debugging and I dont seem to get a whole lot more logs out of it. I had a few examples happen over the weekend. The issue is always for a particular rule number that I have set to null route 30 minutes. I did enable debugging from ossec-control enable debug. I reviewed the ossec.log and the only commonality I see so far is that there are a lot of these messages at the time of the issue for both cases. 2013/03/16 04:38:13 ossec-remoted: DEBUG Sending file 'merged.mg' to agent. I do have 373 agents talking to the server. Any idea how to enable execd debug logging? On Wednesday, March 13, 2013 4:49:10 PM UTC-7, dan (ddpbsd) wrote: > > On Wed, Mar 13, 2013 at 6:47 PM, BP9906 > > wrote: > > Well thats the problem, I dont get any log entry on the OSSEC server AR > log > > so I think I need a debug config enabled to verify it is triggering an > AR. > > What config setting do I set to see that? > > > > > You can run "/var/ossec/bin/ossec-control enable debug" on the server, > and I think setting debug values to 2 in internal_options.conf might > work as well. > > But if you know it's working intermittently, you have to know what log > events are not triggering AR and which ones are. > > > > On Wednesday, March 13, 2013 2:40:40 PM UTC-7, dan (ddpbsd) wrote: > >> > >> On Wed, Mar 13, 2013 at 4:43 PM, BP9906 wrote: > >> > Good point. > >> > For clarity, my AR is set for server execution. It then launches a > shell > >> > script that then loops through a set of servers in a LB pool to do a > >> > null > >> > route on those servers. > >> > I would then see the AR in the Ossec Server AR log and client AR log. > >> > I dont even see the AR log entry on the Ossec Server AR log. > >> > > >> > >> Can you provide your configuration, log samples that do work, and log > >> samples that do not work? > >> > >> > > >> > On Wednesday, March 13, 2013 1:20:06 PM UTC-7, Kat wrote: > >> >> > >> >> are you checking the right logs and do you have the ARs set for the > >> >> right > >> >> place? Sometimes people forget the log entries will be in agents log > >> >> files, > >> >> not the SERVER. > >> >> > >> >> > >> >> On Wednesday, March 13, 2013 10:56:34 AM UTC-7, BP9906 wrote: > >> >>> > >> >>> Hello, > >> >>> I recently upgraded my ossec server to 2.7 and everything is > working > >> >>> great. The weird issue I'm having is that the active responses > >> >>> sometimes > >> >>> dont fire. > >> >>> Its very intermittent because I get email spam for my Rule that is > >> >>> supposed to trigger a null-route. I check the server's > >> >>> active-responses.log > >> >>> and it shows no entries, though previously in the same day (couple > >> >>> hours > >> >>> ago) I see entries for the same rule number. > >> >>> > >> >>> Any suggestions on helping determine why the ossec server couldnt > >> >>> spawn > >> >>> my active response for the rule? > >> >>> > >> >>> Thank you, > >> >>> Brian > >> >>> > >> >>> > >> > -- > >> > > >> > --- > >> > 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 ossec-list+...@googlegroups.com. > >> > For more options, visit https://groups.google.com/groups/opt_out. > >> > > >> > > > > > -- > > > > --- > > 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 ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] logtest matches but rule fails in practice?
Hi It's because the host name field. The ossec server isn't listed. Add a pipe and ossec server name. It should work. :) -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] logtest matches but rule fails in practice?
Sorry. Didn't read the whole thing. Rule 1002 is triggered on error keywords so you can add 1002 to your if Sid. Also if your decoder doesn't match there's probably a regex issue. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Operating System Wrong
Hello, Has anyone noticed that the operating system is wrong on certain agents, especially on larger environments? I have several hundred agents reporting in and noticed that some have wrong OS names. If I delete the agent ID and recreate it, its fixed. So I'm very suspicious that its message bleeding somehow. I have OSSEC Server 2.7 with OSSEC agents all running 2.5.1 (for the remote execution rules in windows). Any ideas what might be causing this? Thank you, Brian -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] 2.6 compile error on RHEL3u9
I can confirm the same. I have an old dev box running RHEL 3u8 and adding
that line fixed the compile issue on OSSEC 2.7 src too.
vi Config.Make
CFLAGS = -g -Wall -I${PT} -I${PT}headers ${CPATH} ${CEXTRA} ${DEXTRA}
${EEXTRA} ${FEXTRA} ${GEXTRA} ${HEXTRA} ${CGEOIP} -DARGV0=\"${NAME}\"
-DXML_VAR=\"var\" -DOSSECHIDS -I/usr/kerberos/include
On Wednesday, January 11, 2012 2:58:22 PM UTC-8, Swartz, Patrick H wrote:
>
> Hi Dan,
> Adding the "-I..." did the trick!! Couldn't get the patch to work, but not
> an issue since adding the line worked.
> Just wanted to post results for future readers...
> Thanks again!
>
> Patrick Swartz
>
> -Original Message-
> From: ossec...@googlegroups.com [mailto:
> ossec...@googlegroups.com ] On Behalf Of dan (ddp)
> Sent: Wednesday, January 11, 2012 4:23 PM
> To: ossec...@googlegroups.com
> Subject: Re: [ossec-list] 2.6 compile error on RHEL3u9
>
> Copy it to a text file on the linux system. Change into the src
> directory (/home/patrick/ossec-hids-2.6/src or whatever) and run:
> patch < /path/to/text/file
>
> That should work. If not, just add "-I/usr/kerberos/include " to the
> CFLAGS line and give it a shot.
>
> On Wed, Jan 11, 2012 at 5:17 PM, Swartz, Patrick H
> > wrote:
> > Please forgive this noobie question.. how does one apply said diff?
> >
> > Patrick Swartz
> >
> >
> > -Original Message-
> > From: ossec...@googlegroups.com [mailto:
> ossec...@googlegroups.com ] On Behalf Of dan (ddp)
> > Sent: Wednesday, January 11, 2012 3:59 PM
> > To: ossec...@googlegroups.com
> > Subject: Re: [ossec-list] 2.6 compile error on RHEL3u9
> >
> > Actually, you can try this diff (no promises ;)):
> >
> > --- Config.Make.origWed Jan 11 16:58:30 2012
> > +++ Config.Make Wed Jan 11 16:58:39 2012
> > @@ -8,7 +8,7 @@
> > include ${PT}Config.OS
> >
> >
> > -CFLAGS = -g -Wall -I${PT} -I${PT}headers ${CPATH} ${CEXTRA} ${DEXTRA}
> > ${EEXTRA} ${FEXTRA} ${GEXTRA} ${HEXTRA} -DARGV0=\"${NAME}\"
> > -DXML_VAR=\"var\" -DOSSECHIDS
> > +CFLAGS = -g -Wall -I${PT} -I${PT}headers -I/usr/kerberos/include
> > ${CPATH} ${CEXTRA} ${DEXTRA} ${EEXTRA} ${FEXTRA} ${GEXTRA} ${HEXTRA}
> > -DARGV0=\"${NAME}\" -DXML_VAR=\"var\" -DOSSECHIDS
> >
> > SOURCES = *.c
> > OBJECTS = *.o
> >
> >
> > On Wed, Jan 11, 2012 at 4:38 PM, Swartz, Patrick H
> > > wrote:
> >> Update.. that Kerberos header is under -- /usr/kerberos/include/krb5.h
> ...
> >> Is this just a matter of telling the ossec compile where to look? If
> so, how do I do that?
> >>
> >> Thanks!
> >>
> >> Patrick Swartz
> >>
> >>
> >> -Original Message-
> >> From: ossec...@googlegroups.com [mailto:
> ossec...@googlegroups.com ] On Behalf Of Swartz, Patrick H
> >> Sent: Wednesday, January 11, 2012 3:34 PM
> >> To: ossec...@googlegroups.com
> >> Subject: RE: [ossec-list] 2.6 compile error on RHEL3u9
> >>
> >> Hi Dan,
> >> Thanks for the quick reply..
> >> Here is what is installed on the build server:
> >>
> >> rpm -qa|grep krb5
> >> krb5-workstation-1.2.7-64
> >> krb5-devel-1.2.7-64
> >> krb5-libs-1.2.7-64
> >> pam_krb5-1.79-1
> >>
> >> But, I don't see any krb5 headers like yours under /usr/include.
> >>
> >> Patrick Swartz
> >>
> >>
> >>
> >> -Original Message-
> >> From: ossec...@googlegroups.com [mailto:
> ossec...@googlegroups.com ] On Behalf Of dan (ddp)
> >> Sent: Wednesday, January 11, 2012 3:17 PM
> >> To: ossec...@googlegroups.com
> >> Subject: Re: [ossec-list] 2.6 compile error on RHEL3u9
> >>
> >> On Wed, Jan 11, 2012 at 3:34 PM, Swartz, Patrick H
> >> > wrote:
> >>>
> >>> Hi All,
> >>> I'm need to compile 2.6 on a RHEL3u9 server but it fails at the
> >>> os_auth phase. The following Openssl packages are installed --
> >>> openssl-0.9.7a-33.23, openssl096b-0.9.6b-16.46, and
> >>> openssl-devel-0.9.7a-33.23
> >>> We need the compile to be built with openssl.
> >>>
> >>> Here are the messages during the build:
> >>>
> >>> *** Making os_auth ***
> >>>
> >>> make[1]: Entering directory `/root/ossec-hids-2.6/src/os_auth'
> >>> gcc -g -Wall -I../ -I../headers -DDEFAULTDIR=\"/opt/ossec/\"
> >>> -DCLIENT -DUSE_OPENSSL -DARGV0=\"ossec-authd\" -DXML_VAR=\"var\"
> >>> -DOSSECHIDS main-server.c ssl.c ../addagent/validate.c
> >>> ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a
> >>> ../os_regex/os_regex.a ../os_crypto/os_crypto.a ../os_zlib/os_zlib.c
> >>> ../external/libz.a -lssl -lcrypto -o ossec-authd
> >>> In file included from /usr/include/openssl/ssl.h:179,
> >>>from auth.h:24,
> >>>from main-server.c:14:
> >>> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
> >>
> >> My guess would be that the openssl devel package needs a kerberos
> >> package it didn't install.
> >>
> >> Maybe:
> >> [ddp@corrin include]$ rpm -qf /usr/include/krb5.h
> >> krb5-devel-1.6.1-62.el5
> >>
> >>
> >>> In file included from /usr/include/openssl/ssl.h:179,
> >>>from auth.h:24,
> >>>from main-
Re: [ossec-list] OSSEC-Agent: socketerr & Queue Error
Hello, I'm seeing this behavior but its repeatable by this 1 host I have. It is running Redhat 5.8. 2013/09/25 14:35:49 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 2013/09/25 14:35:49 ossec-syscheckd: INFO: Starting syscheck database (pre-scan). 2013/09/25 15:03:36 ossec-syscheckd: socketerr (not available). 2013/09/25 15:03:36 ossec-syscheckd(1224): ERROR: Error sending message to queue. Any ideas? I've reinstalled ossec 2.7 from scratch but same error each time. On Monday, June 25, 2012 7:30:09 AM UTC-7, Oliver wrote: > > > > Am Freitag, 22. Juni 2012 14:00:36 UTC+2 schrieb dan (ddpbsd): >> >> On Fri, Jun 22, 2012 at 3:16 AM, Oliver wrote: >> >>> > >>> >> > >> > On Thursday, June 21, 2012 12:42:22 PM UTC+2, dan (ddpbsd) wrote: >> >> >> >> On Thu, Jun 21, 2012 at 3:55 AM, Oliver wrote: >> >> > Hi folks, >> >> > >> >> > I know my problem was posted several times. After reading a lot of >> the >> >> > old >> >> > and also newer posts, I can't see them matching my problem or any >> useful >> >> > solution. >> >> > >> >> > My Setup: >> >> > OSSEC-Manager & OSSEC-Agent => Version ossec-hids-2.6 >> >> > >> >> > Configuration is pretty much default, I just added a directory to >> >> > monitor >> >> > for testing realtime monitoring. This was all working fine during >> the >> >> > night >> >> > happened something and now I'm having all two minutes the entry >> >> > "ossec-logcollector: socketerr (not available). >> >> > >> >> > This are the log entries in ossec.log on the agent when the error >> first >> >> > occurred(RED), the same error for ossec-syscheckd occurred only once >> and >> >> > never again(BLUE): >> >> > 2012/06/21 01:35:36 ossec-syscheckd: INFO: Starting syscheck scan. >> >> > 2012/06/21 01:35:58 ossec-syscheckd: INFO: Ending syscheck scan. >> >> > 2012/06/21 01:50:58 ossec-syscheckd: INFO: Starting syscheck scan. >> >> > 2012/06/21 01:51:20 ossec-syscheckd: INFO: Ending syscheck scan. >> >> > 2012/06/21 02:03:17 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:05:27 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:06:20 ossec-syscheckd: INFO: Starting syscheck scan. >> >> > 2012/06/21 02:06:20 ossec-syscheckd: socketerr (not available). >> >> > 2012/06/21 02:06:20 ossec-syscheckd(1224): ERROR: Error sending >> message >> >> > to >> >> > queue. >> >> > 2012/06/21 02:06:42 ossec-syscheckd: INFO: Ending syscheck scan. >> >> > 2012/06/21 02:07:38 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:09:48 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:11:58 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:14:08 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:16:18 ossec-logcollector: socketerr (not available). >> >> > 2012/06/21 02:16:43 ossec-syscheckd: INFO: Starting syscheck scan. >> >> > 2012/06/21 02:17:05 ossec-syscheckd: INFO: Ending syscheck scan. >> >> > 2012/06/21 02:18:28 ossec-logcollector: socketerr (not available). >> >> > >> >> >> >> Are all of the OSSEC processes running? Does it correct itself if you >> >> remove your changes to the ossec.conf? Try running the processes in >> >> debug mode. >> >> >> > Yes, I did a $OSSEC/bin/ossec-control status and all the processes were >> > running. How do you mean "correct itself"? If I have a typo? yes. >> >> >> >> I mean, if you remove your changes and restart the OSSEC processes, >> does everything work? >> > > Didn't try that. Actually not really helpful if I would. Since the error > occurred after the rollover of the logs and after hours I haven't touched > the system. > >> >> >> > In the logfile on the OSSEC-Manager for that period is nothing >> >> > mentioned, >> >> > the first entry this morning was a restart of the Manager performed >> by >> >> > myself. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous md5 checksum found: >> >> > '/logs/archives/2012/Jun/ossec-archive-19.log.sum'. Starting over. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous sha1 checksum found: >> >> > '/logs/archives/2012/Jun/ossec-archive-19.log.sum'. Starting over. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous md5 checksum found: >> >> > '/logs/alerts/2012/Jun/ossec-alerts-19.log.sum'. Starting over. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous sha1 checksum found: >> >> > '/logs/alerts/2012/Jun/ossec-alerts-19.log.sum'. Starting over. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous md5 checksum found: >> >> > '/logs/firewall/2012/Jun/ossec-firewall-19.log.sum'. Starting over. >> >> > 2012/06/21 00:00:36 ossec-monitord: No previous sha1 checksum found: >> >> > '/logs/firewall/2012/Jun/ossec-firewall-19.log.sum'. Starting over. >> >> > 2012/06/21 08:38:27 ossec-monitord(1225): INFO: SIGNAL Received. >> Exit >> >> > Cleaning... >> >> >> >> Is this where you killed the processes? >> >> Were a
[ossec-list] Locate agent: Incorrectly formated message from 'any'.
2013/09/26 10:41:38 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. We have an agent that keeps flagging this and I obviously have no idea who it is because we have about 30 agents setup with 'any' for the IP. Any suggestions to locating this? Can I enable debug and it will log the source IP? Thank you -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] ossec-logtest and syscheck
Hello, Is there a way of testing ossec-logtest with syscheck? I'm trying to build rules based on the original syscheck rules so that I can create separate reports and alerts based on few factors like application. Its become such trial and error that its a little frustrating. If I could use ossec-logtest to feed a sample into it for testing that would be very helpful. Thank you, Brian -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
I'm trying to exclude Symantec registry keys from being checked because they change with every definition change. Any idea why this isnt working? I tried with and without sregex and using the carrot "^" in front and nothing seems to take. I'm not using profiles, I just have a blanket Thank you for your help and/or suggestions to try. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
It appears a copy paste into ossec.conf on the local agent is successful. I cannot get any feedback from those regkeys using ./bin/syscheck_control -r -i So what do I do now? On Tuesday, November 5, 2013 8:32:40 AM UTC-8, dan (ddpbsd) wrote: > > On Mon, Nov 4, 2013 at 4:31 PM, BP9906 > > wrote: > > I'm trying to exclude Symantec registry keys from being checked because > they > > change with every definition change. > > > > Any idea why this isnt working? I tried with and without sregex and > using > > the carrot "^" in front and nothing seems to take. > > I'm not using profiles, I just have a blanket os="Windows"> > > > > Does it work if you put it in the ossec.conf? > > > Thank you for your help and/or suggestions to try. > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ > > > > > > > > -- > > > > --- > > 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 ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
I take it all back. Sorry. I didnt wait for a definition update. I ran another syscheck on the same box as earlier and it showed up again. :( HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG 2013 Nov 06 21:21:53,4 - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG 2013 Nov 06 21:21:53,4 - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 What do you suggest now? On Wednesday, November 6, 2013 4:47:59 PM UTC-8, BP9906 wrote: > > It appears a copy paste into ossec.conf on the local agent is successful. > I cannot get any feedback from those regkeys using ./bin/syscheck_control > -r -i > So what do I do now? > > On Tuesday, November 5, 2013 8:32:40 AM UTC-8, dan (ddpbsd) wrote: >> >> On Mon, Nov 4, 2013 at 4:31 PM, BP9906 wrote: >> > I'm trying to exclude Symantec registry keys from being checked because >> they >> > change with every definition change. >> > >> > Any idea why this isnt working? I tried with and without sregex and >> using >> > the carrot "^" in front and nothing seems to take. >> > I'm not using profiles, I just have a blanket > os="Windows"> >> > >> >> Does it work if you put it in the ossec.conf? >> >> > Thank you for your help and/or suggestions to try. >> > >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ >> >> >> > >> > >> > -- >> > >> > --- >> > 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 ossec-list+...@googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
I'm trying combinations on ossec.conf locally so far no change. I tried this (added carrot since sregex is there) and no change, I still see it reporting as a registry changed. Trying to remove carrot and sregex type next. ^HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 ^HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG On Wednesday, November 6, 2013 9:59:54 PM UTC-8, BP9906 wrote: > > I take it all back. Sorry. > I didnt wait for a definition update. I ran another syscheck on the same > box as earlier and it showed up again. :( > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > 2013 Nov 06 21:21:53,4 - > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > 2013 Nov 06 21:21:53,4 - > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > What do you suggest now? > > On Wednesday, November 6, 2013 4:47:59 PM UTC-8, BP9906 wrote: >> >> It appears a copy paste into ossec.conf on the local agent is successful. >> I cannot get any feedback from those regkeys using ./bin/syscheck_control >> -r -i >> So what do I do now? >> >> On Tuesday, November 5, 2013 8:32:40 AM UTC-8, dan (ddpbsd) wrote: >>> >>> On Mon, Nov 4, 2013 at 4:31 PM, BP9906 wrote: >>> > I'm trying to exclude Symantec registry keys from being checked >>> because they >>> > change with every definition change. >>> > >>> > Any idea why this isnt working? I tried with and without sregex and >>> using >>> > the carrot "^" in front and nothing seems to take. >>> > I'm not using profiles, I just have a blanket >> os="Windows"> >>> > >>> >>> Does it work if you put it in the ossec.conf? >>> >>> > Thank you for your help and/or suggestions to try. >>> > >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 >>> >>> >>> > >> > >>> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ >>> >>> >>> > >>> > >>> > -- >>> > >>> > --- >>> > 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 ossec-list+...@googlegroups.com. >>> > For more options, visit https://groups.google.com/groups/opt_out. >>> >> -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
So apparently having it like this in ossec.conf worked. I remember trying it before on agent.conf, so I'm going to try it again to see if it works there, and remove it from ossec.conf. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG On Thursday, November 7, 2013 6:54:49 AM UTC-8, dan (ddpbsd) wrote: > > On Thu, Nov 7, 2013 at 12:59 AM, BP9906 > > wrote: > > I take it all back. Sorry. > > I didnt wait for a definition update. I ran another syscheck on the same > box > > as earlier and it showed up again. :( > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > > > > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > > > > > 2013 Nov 06 21:21:53,4 - > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > 2013 Nov 06 21:21:53,4 - > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > > > What do you suggest now? > > > > Since you're not using any simple regex, try those entries without the > type being specified. > Other than that, I imagine tracking down the issue in the code is your > best bet. I don't have any Windows systems to test with, and I've > never gotten the Windows compilation to work. > Oh, and you can open a ticket in the bitbucket > https://bitbucket.org/jbcheng/ossec-hids > > > On Wednesday, November 6, 2013 4:47:59 PM UTC-8, BP9906 wrote: > >> > >> It appears a copy paste into ossec.conf on the local agent is > successful. > >> I cannot get any feedback from those regkeys using > ./bin/syscheck_control -r > >> -i > >> So what do I do now? > >> > >> On Tuesday, November 5, 2013 8:32:40 AM UTC-8, dan (ddpbsd) wrote: > >>> > >>> On Mon, Nov 4, 2013 at 4:31 PM, BP9906 wrote: > >>> > I'm trying to exclude Symantec registry keys from being checked > because > >>> > they > >>> > change with every definition change. > >>> > > >>> > Any idea why this isnt working? I tried with and without sregex and > >>> > using > >>> > the carrot "^" in front and nothing seems to take. > >>> > I'm not using profiles, I just have a blanket >>> > os="Windows"> > >>> > > >>> > >>> Does it work if you put it in the ossec.conf? > >>> > >>> > Thank you for your help and/or suggestions to try. > >>> > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 > > > >>> > >>> > > >>> > > type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ > > > >>> > > >>> > > >>> > -- > >>> > > >>> > --- > >>> > 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 ossec-list+...@googlegroups.com. > >>> > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > > > --- > > 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 ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/groups/opt_out. > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] restart-ossec active response doesn't works in 2.7.1
On the ossec server, are you missing a disable/enable param in active responses? The -L should show it if the server recognizes it. also, its in ossec.conf right? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] recv_counter_flush
If I increase this value, will it make ossec remoted read the udp os buffer in larger chunks? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] registry_ignore not working for OSSEC 2.7 agents/server agent.conf
I've tried many variations and it doesnt seem to help. I did notice that with windows debug = 2, I dont see anything about the windows agent being aware of the registry ignores. I'm not sure if the issue is the reading of the agent.conf or just not processing the regex against the syscheck results. When the entry is in ossec.conf, it works fine. My agent.conf file is pretty big where I have different ossec_agent stanzas for different hostnames. Could it be that windows agents dont fully parse the whole agent.conf file? Any other suggestions? On Thursday, November 7, 2013 3:45:18 PM UTC-6, BP9906 wrote: > > So apparently having it like this in ossec.conf worked. I remember trying > it before on agent.conf, so I'm going to try it again to see if it works > there, and remove it from ossec.conf. > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG > > > On Thursday, November 7, 2013 6:54:49 AM UTC-8, dan (ddpbsd) wrote: >> >> On Thu, Nov 7, 2013 at 12:59 AM, BP9906 wrote: >> > I take it all back. Sorry. >> > I didnt wait for a definition update. I ran another syscheck on the >> same box >> > as earlier and it showed up again. :( >> > >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 >> >> >> > > > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG >> >> >> > >> > 2013 Nov 06 21:21:53,4 - >> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG >> > 2013 Nov 06 21:21:53,4 - >> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 >> > >> > What do you suggest now? >> > >> >> Since you're not using any simple regex, try those entries without the >> type being specified. >> Other than that, I imagine tracking down the issue in the code is your >> best bet. I don't have any Windows systems to test with, and I've >> never gotten the Windows compilation to work. >> Oh, and you can open a ticket in the bitbucket >> https://bitbucket.org/jbcheng/ossec-hids >> >> > On Wednesday, November 6, 2013 4:47:59 PM UTC-8, BP9906 wrote: >> >> >> >> It appears a copy paste into ossec.conf on the local agent is >> successful. >> >> I cannot get any feedback from those regkeys using >> ./bin/syscheck_control -r >> >> -i >> >> So what do I do now? >> >> >> >> On Tuesday, November 5, 2013 8:32:40 AM UTC-8, dan (ddpbsd) wrote: >> >>> >> >>> On Mon, Nov 4, 2013 at 4:31 PM, BP9906 wrote: >> >>> > I'm trying to exclude Symantec registry keys from being checked >> because >> >>> > they >> >>> > change with every definition change. >> >>> > >> >>> > Any idea why this isnt working? I tried with and without sregex and >> >>> > using >> >>> > the carrot "^" in front and nothing seems to take. >> >>> > I'm not using profiles, I just have a blanket > >>> > os="Windows"> >> >>> > >> >>> >> >>> Does it work if you put it in the ossec.conf? >> >>> >> >>> > Thank you for your help and/or suggestions to try. >> >>> > >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSxpx86 >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx64 >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BHDrvx86 >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVEX15 >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NAVENG >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDSVia64 >> >> >> >>> > > >>> > >> >>> > >> type="sregex">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ccSettings_ >> >> >> >>> > >> >>> > >> >>> > -- >> >>> > >> >>> > --- >> >>> > 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 ossec-list+...@googlegroups.com. >> >>> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > -- >> > >> > --- >> > 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 ossec-list+...@googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] full_command netstat and other output in alerts.log file
The full output should be in a folder. Ive seen it before just dont recall where. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] ossec report filters
Hello, I just wanted to inquire if anyone has been able to create separate filtered reports for file integrity? I noticed all FIM alerts are "syscheck" group tag and I can create sub-rules with new group tags but I cant find a way to do an "all except" report with ossec-reportd. So I have group tags for groups of servers. Syscheck --app1 --app2 --app3 I can run reports on app1,2,3 but I cant say give me everything else in sysycheck thats not in app1,2,3. Anyone have a suggestion to accomplish this? Thank you for your help. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Active Response Requires Agent Restarts?
Yes. This is true. I mentioned this a long time ago in a post here. The way to do it is syscheck the ossec/etc/shared folder. Then rule on ossec server to detect agent.conf / ar.conf change and trigger restart on active response. I do have a script to loop thru agent control and restart all the agents in case my agent.conf gets malformed. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Re: Integrity checksum changing ..... half a day after the change actually happened
Check the agents ossec.log. You might be running it too often. 15min min is what I suggest or use realtime but that can be tricky. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] ossec-logcollector 2.7.1 not reading nfs mounted log
I have a log being written on a different machine via syslog to nfs mounted log. Ossec on a different server has the same mount to the nfs and it appears to be ignoring the log. Soon as I open the log on "vi" then write it (even with no changes), then ossec all of a sudden kicks in and reads the whole log from the beginning. This is fine because I have logrotate rotating the log each day too. Any idea what is going on here, ie why ossec-logcollector doesnt see the log entries until i touch the log? Thanks. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Script to push agent keys
You can setup ssh keys and script the manage agents options. Its quite easy to do. Then you can do a precompiled package and install and config the agent. The only tricky part is restarting the agent after agent.conf get pulled down which couls be a while. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] ossec-logcollector 2.7.1 not reading nfs mounted log
Figured out it wasnt nfs mounted. It was cifs (smb) mounted and changing to nfs fixed it. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: release 2.7.1, Windows agents and profiles, and Server 2012
I noticed ossec-hids-2.7.1 is broken for Server 2012 R2 because it doesnt pull the OS, it doesnt pull the agent.conf, it doesnt report the ossec agent status so the ossec 2.7.1 server shows "never connected" yet the syscheck entries are being updated and syscheck reports in. So it appears syscheck works, but other agent communication features do not. On Friday, November 15, 2013 3:50:23 AM UTC-6, Chris H wrote: > > Hi. I'll have a go setting up a build environment following that guide, > and see what I can come up with. > > I've installed the agent on Windows 2012, it works but doesn't detect OS, > never mind the profile. I had a poke through the code and it looked like > the OS detection routine was just missing the reference to 2012. > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: release 2.7.1, Windows agents and profiles, and Server 2012
The ossec.log locally looks good to detect the os but the agent_control -i into ossec server 2.7.1 for that agent still shows never connected and its been 12hrs. The syscheck dates are updating and the agent.conf is working. I think something with status/keep alive isnt working. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] how do you know certainly server get the logs from agent. because it uses UDP port 1514
I adjusted my rmem default and max and I still get send/receive errors. My values are 16777216 and 26214400 (respectively). I think remoted isnt reading the buffer fast enough to process. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Active Responses Slow
I've been watching active responses lately and it seems like they dont always generate an active response. I have the settings properly but I would say the actual active response triggers about 25% of the time. I say that because the alerts.log (and respective emails in my inbox) indicate the correct rule is firing. I have a lot of local active responses that fire regularly so I"m thinking there's a queue size for active responses that is not big enough. Any idea of what setting I should take a look at? Thank you -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] ossec 2.7.1 can not integrity-check windows for system32 directory
Dumb question here, but are you letting syscheck run after the agent has been restarted after the agent.conf has been downloaded? You can force syscheck to run from the ossec server using ./bin/syscheck_control -r -u ### where ### = agent ID Then watch ossec.log on the agent show Syscheckd start .. do stuff... finish .. realtime syscheck started. On Thursday, May 29, 2014 5:27:50 PM UTC-5, Ash Windy wrote: > > i test these problems again. > important issues following: > 1. upload some files to two folders but just detected one. > 2. upload different files to different folders at same time but just > detected one. > > I used procexp.exe and procmon.exe to monitor files access. > > >1. testing environment > > OS: windows 2003 R2 > > OSSEC version: 2.8 bate1 > > server configure for syscheck(already add new file alert in > local_rules.xml) > > ===ossec.conf== > > > > > > 79200 > > yes > > no > > > > /etc,/usr/bin,/usr/sbin > > /bin,/sbin > > > > /etc/mtab > > /etc/mnttab > > /etc/hosts.deny > > /etc/mail/statistics > > /etc/random-seed > > /etc/adjtime > > /etc/httpd/logs > > /etc/utmpx > > /etc/wtmpx > > /etc/cups/certs > > /etc/dumpdates > > /etc/svc/volatile > > > > == > > > > agent configure for syscheck: > > agent.conf== > > > > 600 > > no > > report_changes="yes">c:\autoexec.bat > > c:\config.sys > > %WINDIR% > > %WINDIR%/System32/LogFiles > > %WINDIR%/system32/wbem/Logs > > %WINDIR%/Prefetch > > %WINDIR%/Debug > > %WINDIR%/PCHEALTH/HELPCTR/DataColl > > %WINDIR%/SoftwareDistribution > > %WINDIR%/Temp > > %WINDIR%/SchedLgU.Txt > > %WINDIR%/system32/config > > %WINDIR%/system32/CatRoot > > %WINDIR%/system32/wbem/Repository > > %WINDIR%/LastGood.Tmp > > %WINDIR%/LastGood > > %WINDIR%/Help > > %WINDIR%/Fonts > > %WINDIR%/PCHEALTH > > %WINDIR%/system32/dllcache > > .log$|.htm$|.jpg$|.png$|.chm$|.pnf$ > > > > HKEY_LOCAL_MACHINE\Security > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session > Manager\KnownDLLs > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg > > > HKEY_LOCAL_MACHINE\Software\Policies > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows > NT\CurrentVersion > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\URL > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows > NT\CurrentVersion\Windows > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows > NT\CurrentVersion\Winlogon > > HKEY_LOCAL_MACHINE\Software\Microsoft\Active > Setup\Installed Components > > HKEY_LOCAL_MACHINE\Software\Microsoft\Internet > Explorer > > > HKEY_LOCAL_MACHINE\Software\Classes > > > HKEY_LOCAL_MACHINE\Software\Classes\batfile > > > HKEY_LOCAL_MACHINE\Software\Classes\cmdfile > > > HKEY_LOCAL_MACHINE\Software\Classes\comfile > > > HKEY_LOCAL_MACHINE\Software\Classes\exefile > > > HKEY_LOCAL_MACHINE\Software\Classes\piffile > > > HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects > > > HKEY_LOCAL_MACHINE\Software\Classes\Directory > > > HKEY_LOCAL_MACHINE\Software\Classes\Folder > > > HKEY_LOCAL_MACHINE\Software\Classes\Protocols > > > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group > > Policy\State > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate > > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet > > Settings\Cache > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows > NT\CurrentVersion\Profi leList > > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows > NT\CurrentVersion\Prefetcher > > > HKEY_LOCAL_MACHINE\Software\Classes\Interface > > > HKEY_LOCAL_MACHINE\Software\Classes\TypeLib > > > HKEY_LOCAL_MACHINE\Software\Classes\MIME > > > HKEY_LOCAL_MACHINE\Software\Classes\Software > > > HKEY_LOCAL_MACHINE\Software\Classes\CLSID > > > HKEY_LOCAL_MACHINE\Security\Policy\Secrets > > > HKEY_LOCAL_MACHINE\Security\SAM\Domains\Account\Users > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses > > > HKEY_LOCAL_MAC
RE: [ossec-list] ossec file integrity performance >1000000 files
Have you checked the ossec agent log? Have you tuned the kernel udp buffer settings? On ossec server you can do agent control -i -e and see start and stop times to compare with agent ossec log. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
