Re: [ossec-list] Parsing OSSEC XML Rules
Hi Dave, thanks for sharing your conclusions with us, let me answer you each point. *"convert the OSSEC/WAZUH rules to a MySQL database table"* In case it helps, I think OSSEC already insert each rule into a MySQL database, I can't try it out right now but you can see in the links below the MySQL schema and where OSSEC read and insert each rule. https://github.com/wazuh/ossec-wazuh/blob/master/src/os_dbd/mysql.schema#L17 https://github.com/wazuh/ossec-wazuh/blob/5441889d963ce6d8ee3fae0e9f273e701b6c89eb/src/os_dbd/main.c#L218 1. Totally agree, in fact, we had encounter this problem while creating the RESTful API, we use some Python parsers from XML to JSON. We solved the problem adding a parent tag like you did, we are doing that in all XML levels, in some cases (for example, parsing ossec.conf) we introduced some particular solutions to each tag (studying all configuration possibilities). 2. You are right, there are so many "hidden" options in OSSEC rules, we are working on document everything in detail. 3. Same than 2. 4. Agree, please feel free to send a pull request to our repository so it will be solved to everyone : D Thanks! It sounds very interesting, please keep us updated on with your progress, we will be happy to help you. Regarding to that API you mention, how is it going to work? will it ask the database for rules info? Cheers, Pedro S. On Wed, Jul 20, 2016 at 1:26 PM, Dave Stoddard wrote: > I am posting this to both the OSSEC and WAZUH mailing lists as this > message applies to both. First, I want to express my appreciation for OSSEC > and all of the work that the developers have put into this tool. I worked > with a number of programs in the past to collect SIEM event data (Snare and > others) and we had to write a lot of code to make it work. OSSEC is a > superior application for event collection and rating for SIEM. > > > > I have been working on a program to convert the OSSEC/WAZUH rules to a > MySQL database table for use in an external monitoring application, and I > thought I would share some of the things I discovered while going through > this process. Note that none of these things are criticisms – it’s more of > a road map for anyone that needs to convert the rules to another format. I > used Perl with the LibXML library to do the parsing of the XML. Here are a > few of the things I found: > > > > 1. The XML in the /var/ossec/rules directory is not conformant to strict > XML standards in that the XML standard requires all elements in a file to > be grouped within one outside element. In the OSSEC rules, many of the > files contain multiple elements on the first level, which breaks > the LibXML parser. To get around this limitation, I slurped each file into > a scalar variable and wrapped its contents in and > elements. This solved the problem. > > > > 2. In the documentation for OSSEC rules, there are a number of elements > that have been defined to function within a element container. I > discovered that several elements are not defined in the documentation found > here: > > > > http://ossec-docs.readthedocs.io/en/latest/syntax/head_rules.html > > > > A list of all the elements used within a container for all of the > files is provided below. The elements that have an asterisk next to them > are not defined in the current documentation: > > > > action * > > category > > check_diff > > check_if_ignored * > > compiled_rule * > > decoded_as > > description > > different_url * > > extra_data > > group > > hostname > > id > > if_fts * > > if_group > > if_matched_group > > if_matched_sid > > if_sid > > ignore * > > info > > match > > options > > program_name > > regex > > same_id > > same_source_ip > > same_user > > status * > > time > > url > > user > > > > You can find some documentation on a few of these elements by doing a > Google search, such as if_fts (first time seen), and compiled_rule. You can > also grep the XML rule files to find other examples in use, however some of > these elements are mysterious in their use including , > , , and . > > > > 3. A number of elements have attributes, and I needed a definitive list in > order to build a table that would capture those items. There are only four > elements that use attributes in OSSEC rules. A list of those elements and > their attributes is provided below: > > > > : name > > : type > > : frequency, id, ignore, level, maxsize, noalert, overwrite, > timeframe > > : name > > > > Of these attributes, only the noalert attribute is undefined in the > documentation. > > > > 4. One of the files, netscaler_rules.xml, has a comment with two hyphens > in it (a sample log entry), which breaks XML (yes, the friggin LibXML > parser scans comments!). I had to modify the comment by replacing one of > the hyphens with an equal sign to allow it to continue. > > > > 5. When parsing the XML data, the structure of each file containing rules > is very simple to process. There are no complex CDATA nodes to deal with, > entit
Re: [ossec-list] Irregular Agent Activity in OSSEC agents
Hey Eero, >From examining the server - Both disk speed and network should not be a problem, but I did notice a shortage of Available RAM (around 300 MB left). Ill make the changes tomorrow and add more RAM and update if it was the case. On Wednesday, July 20, 2016 at 10:47:41 PM UTC+3, Eero Volotinen wrote: > > Are you running out of network or disk speed? > > Eero > > 20.7.2016 10.39 ip. "eyal gershon" > > kirjoitti: > >> Hey Jose, >> >> There was no update or upgrade done. >> I performed the procedure you mentioned before but the results stayed the >> same. >> >> I have around 1600 servers and 400 who do not connect. >> >> Do you have any other idea on why this happens? >> Or any thing else I can test? >> >> >> On Wed, Jul 20, 2016 at 6:03 PM, Jose Luis Ruiz > > wrote: >> >>> Hi Eyal, >>> >>> >>> >>> this is a familiar problem that we have come across in the past as well. >>> The counter of the rids file can run out of sync, if the manager and the >>> respective agent have troubles exchanging control messages. >>> >>> Have you perhaps reinstalled the manager or one of the agents recently? >>> >>> >>> >>> You can fix your problem by following the below steps: >>> >>> >>> >>> 1. On every agent: >>> >>> >>> >>> 1. stop ossec >>> >>> 2. go to: .../ossec/queue/rids (or ossec-agent/rids on Windows) and >>> remove every file in there. >>> >>> >>> >>>2. Go to the server: >>> >>> >>> >>> 1. Stop ossec >>> >>> 2. Remove the rids file with the same name as the agent id that is >>> reporting errors. >>> >>> >>> >>>3. Restart the server >>> >>>4. Restart the agents. >>> >>> >>> >>> If you have reinstalled one of your machines recently, then we recommend >>> that you use the update option. Do not remove and reinstall the ossec >>> server, unless you plan to do the same for all agents. >>> >>> Just a heads up, please refrain from using the same agent key between >>> multiple agents, or the same agent key after you removed/re-installed an >>> agent…. >>> >>> >>> Reference: >>> http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html#fixing-duplicate-errors >>> >>> >>> Regards >>> --- >>> Jose Luis Ruiz >>> Wazuh Inc. >>> jo...@wazuh.com >>> >>> On July 20, 2016 at 11:54:41 AM, eyal gershon (gersh...@gmail.com >>> ) wrote: >>> >>> Hey Everyone, >>> >>> I am noticing some irregular activity in some of my OSSEC agents - >>> >>> *A little bit about the system - * >>> >>> My Deployment is on 2000~ servers managed from dedicated ossec manager. >>> I currently have 1600~ agents connected on a full basis and 400~ servers >>> who connect and disconnect all the time. >>> >>> All the ports are opened (confirmation with NC and telnet) >>> >>> On my management server I see the following error in the logs - >>> >>> 2016/07/20 05:33:49 ossec-remoted(1407): ERROR: Duplicated counter for >>> '**'. >>> 2016/07/20 05:33:55 ossec-remoted: WARN: Duplicate error: global: >>> >>> >>> I checked the /var/ossec/queue/rids and made sure there is only a single >>> entry in there and that entry is the same on both host and Management. >>> I made a double check and also compared client.keys on both servers,Same >>> Key and same Entry on both servers. >>> >>> >>> I did a key exchange manually between both servers just to make sure >>> Nothing was wrong in that section. >>> Same error. >>> >>> >>> Does anyone have an idea on how to continue? >>> -- >>> >>> --- >>> 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/d/optout. >>> >>> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ossec-list" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ossec-list+...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Parsing OSSEC XML Rules
I am posting this to both the OSSEC and WAZUH mailing lists as this message applies to both. First, I want to express my appreciation for OSSEC and all of the work that the developers have put into this tool. I worked with a number of programs in the past to collect SIEM event data (Snare and others) and we had to write a lot of code to make it work. OSSEC is a superior application for event collection and rating for SIEM. I have been working on a program to convert the OSSEC/WAZUH rules to a MySQL database table for use in an external monitoring application, and I thought I would share some of the things I discovered while going through this process. Note that none of these things are criticisms – it’s more of a road map for anyone that needs to convert the rules to another format. I used Perl with the LibXML library to do the parsing of the XML. Here are a few of the things I found: 1. The XML in the /var/ossec/rules directory is not conformant to strict XML standards in that the XML standard requires all elements in a file to be grouped within one outside element. In the OSSEC rules, many of the files contain multiple elements on the first level, which breaks the LibXML parser. To get around this limitation, I slurped each file into a scalar variable and wrapped its contents in and elements. This solved the problem. 2. In the documentation for OSSEC rules, there are a number of elements that have been defined to function within a element container. I discovered that several elements are not defined in the documentation found here: http://ossec-docs.readthedocs.io/en/latest/syntax/head_rules.html A list of all the elements used within a container for all of the files is provided below. The elements that have an asterisk next to them are not defined in the current documentation: action * category check_diff check_if_ignored * compiled_rule * decoded_as description different_url * extra_data group hostname id if_fts * if_group if_matched_group if_matched_sid if_sid ignore * info match options program_name regex same_id same_source_ip same_user status * time url user You can find some documentation on a few of these elements by doing a Google search, such as if_fts (first time seen), and compiled_rule. You can also grep the XML rule files to find other examples in use, however some of these elements are mysterious in their use including , , , and . 3. A number of elements have attributes, and I needed a definitive list in order to build a table that would capture those items. There are only four elements that use attributes in OSSEC rules. A list of those elements and their attributes is provided below: : name : type : frequency, id, ignore, level, maxsize, noalert, overwrite, timeframe : name Of these attributes, only the noalert attribute is undefined in the documentation. 4. One of the files, netscaler_rules.xml, has a comment with two hyphens in it (a sample log entry), which breaks XML (yes, the friggin LibXML parser scans comments!). I had to modify the comment by replacing one of the hyphens with an equal sign to allow it to continue. 5. When parsing the XML data, the structure of each file containing rules is very simple to process. There are no complex CDATA nodes to deal with, entity references, documents, or other esoteric data. The complete list of node types includes elements, attributes, text, comments, white space, and “end elements”. This level of simplicity makes it easy to read and process the rules into other formats. If anyone is interested, I will post the code on the list after I get it working. We have a proprietary API we use to talk to our database, but I can rewrite those calls to make it more vanilla so others can use this too. Best, Dave Stoddard Network Alarm Corporation -- --- 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] Irregular Agent Activity in OSSEC agents
Are you running out of network or disk speed? Eero 20.7.2016 10.39 ip. "eyal gershon" kirjoitti: > Hey Jose, > > There was no update or upgrade done. > I performed the procedure you mentioned before but the results stayed the > same. > > I have around 1600 servers and 400 who do not connect. > > Do you have any other idea on why this happens? > Or any thing else I can test? > > > On Wed, Jul 20, 2016 at 6:03 PM, Jose Luis Ruiz wrote: > >> Hi Eyal, >> >> >> >> this is a familiar problem that we have come across in the past as well. The >> counter of the rids file can run out of sync, if the manager and the >> respective agent have troubles exchanging control messages. >> >> Have you perhaps reinstalled the manager or one of the agents recently? >> >> >> >> You can fix your problem by following the below steps: >> >> >> >> 1. On every agent: >> >> >> >> 1. stop ossec >> >> 2. go to: .../ossec/queue/rids (or ossec-agent/rids on Windows) and >> remove every file in there. >> >> >> >>2. Go to the server: >> >> >> >> 1. Stop ossec >> >> 2. Remove the rids file with the same name as the agent id that is >> reporting errors. >> >> >> >>3. Restart the server >> >>4. Restart the agents. >> >> >> >> If you have reinstalled one of your machines recently, then we recommend >> that you use the update option. Do not remove and reinstall the ossec >> server, unless you plan to do the same for all agents. >> >> Just a heads up, please refrain from using the same agent key between >> multiple agents, or the same agent key after you removed/re-installed an >> agent…. >> >> >> Reference: >> http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html#fixing-duplicate-errors >> >> >> Regards >> --- >> Jose Luis Ruiz >> Wazuh Inc. >> j...@wazuh.com >> >> On July 20, 2016 at 11:54:41 AM, eyal gershon (gershon...@gmail.com) >> wrote: >> >> Hey Everyone, >> >> I am noticing some irregular activity in some of my OSSEC agents - >> >> *A little bit about the system - * >> >> My Deployment is on 2000~ servers managed from dedicated ossec manager. >> I currently have 1600~ agents connected on a full basis and 400~ servers >> who connect and disconnect all the time. >> >> All the ports are opened (confirmation with NC and telnet) >> >> On my management server I see the following error in the logs - >> >> 2016/07/20 05:33:49 ossec-remoted(1407): ERROR: Duplicated counter for >> '**'. >> 2016/07/20 05:33:55 ossec-remoted: WARN: Duplicate error: global: >> >> >> I checked the /var/ossec/queue/rids and made sure there is only a single >> entry in there and that entry is the same on both host and Management. >> I made a double check and also compared client.keys on both servers,Same >> Key and same Entry on both servers. >> >> >> I did a key exchange manually between both servers just to make sure >> Nothing was wrong in that section. >> Same error. >> >> >> Does anyone have an idea on how to continue? >> -- >> >> --- >> 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. >> >> > -- > > --- > 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. > -- --- 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] Irregular Agent Activity in OSSEC agents
Hey Jose, There was no update or upgrade done. I performed the procedure you mentioned before but the results stayed the same. I have around 1600 servers and 400 who do not connect. Do you have any other idea on why this happens? Or any thing else I can test? On Wed, Jul 20, 2016 at 6:03 PM, Jose Luis Ruiz wrote: > Hi Eyal, > > > > this is a familiar problem that we have come across in the past as well. The > counter of the rids file can run out of sync, if the manager and the > respective agent have troubles exchanging control messages. > > Have you perhaps reinstalled the manager or one of the agents recently? > > > > You can fix your problem by following the below steps: > > > > 1. On every agent: > > > > 1. stop ossec > > 2. go to: .../ossec/queue/rids (or ossec-agent/rids on Windows) and > remove every file in there. > > > >2. Go to the server: > > > > 1. Stop ossec > > 2. Remove the rids file with the same name as the agent id that is > reporting errors. > > > >3. Restart the server > >4. Restart the agents. > > > > If you have reinstalled one of your machines recently, then we recommend that > you use the update option. Do not remove and reinstall the ossec server, > unless you plan to do the same for all agents. > > Just a heads up, please refrain from using the same agent key between > multiple agents, or the same agent key after you removed/re-installed an > agent…. > > > Reference: > http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html#fixing-duplicate-errors > > > Regards > --- > Jose Luis Ruiz > Wazuh Inc. > j...@wazuh.com > > On July 20, 2016 at 11:54:41 AM, eyal gershon (gershon...@gmail.com) > wrote: > > Hey Everyone, > > I am noticing some irregular activity in some of my OSSEC agents - > > *A little bit about the system - * > > My Deployment is on 2000~ servers managed from dedicated ossec manager. > I currently have 1600~ agents connected on a full basis and 400~ servers > who connect and disconnect all the time. > > All the ports are opened (confirmation with NC and telnet) > > On my management server I see the following error in the logs - > > 2016/07/20 05:33:49 ossec-remoted(1407): ERROR: Duplicated counter for > '**'. > 2016/07/20 05:33:55 ossec-remoted: WARN: Duplicate error: global: > > > I checked the /var/ossec/queue/rids and made sure there is only a single > entry in there and that entry is the same on both host and Management. > I made a double check and also compared client.keys on both servers,Same > Key and same Entry on both servers. > > > I did a key exchange manually between both servers just to make sure > Nothing was wrong in that section. > Same error. > > > Does anyone have an idea on how to continue? > -- > > --- > 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. > > -- --- 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: Random OSSEC Agents Offline
I'd like to see answers for that as well, since I have a similar problem Em terça-feira, 19 de julho de 2016 11:13:50 UTC-3, Quintin Beukes escreveu: > > Hi, > > A few days ago some of my OSSEC agents started going offline and stop > sending alerts, and then a long while after come back online again like > nothing's wrong. Restarting the agents don't help fix the offline status. > This affects both agents running through a router/firewall to reach the > server, and agents running in the same subnet as the server. > > I removed all iptables filters and did a tcpdump on both offline and > online agents, but couldn't notice anything out of the ordinary. > > Here are packets from an offline agent showing successful traffic from > server to client and vice versa, as well as some curious port unreachable > errors. Even though there is traffic, the agent shows as offline and no > alerts are generated for events on this agent. > > OSSEC Server IP: 10.10.12.171 > Agent IP: 10.10.13.8 > > agent_control -l: >ID: 019, Name: devjerm1, IP: 10.10.13.8, Disconnected > > tcpdump: > 15:47:36.515777 IP 10.10.13.8 > 10.10.12.171: ICMP 10.10.13.8 udp port > 58989 unreachable, length 109 > 15:47:36.517646 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 > 15:47:40.526516 IP 10.10.12.171.1514 > 10.10.13.8.58989: UDP, length 73 > 15:47:40.526567 IP 10.10.13.8 > 10.10.12.171: ICMP 10.10.13.8 udp port > 58989 unreachable, length 109 > 15:47:41.518182 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 > 15:47:47.518732 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 > 15:47:59.581518 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 > 15:48:07.897110 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 > 15:48:14.725335 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 > 15:48:19.395627 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 > 15:48:25.521404 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 > 15:48:31.522261 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 > 15:48:35.522794 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 > > Any insights are appreciated. > > Quintin > -- --- 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: DB schema
On Wed, Jul 20, 2016 at 11:05 AM, Kumar G wrote: > Hi, Is there any harm in increasing the varchar in schema. I expect it > should be good to change, but not sure if this is defined anywhere in the > source code. > The source is open, you can check. You can also make the change in a testing environment to see if it affects anything. > > > On Tuesday, 19 July 2016 22:59:00 UTC+5:30, Kumar G wrote: >> >> Hi all, >> >> We have a requirement like increasing the description data type from >> varchar 255 to higher value. Is it advisable to do this change or we need to >> limit ourway description field with in 255 char? >> >> >> CREATE TABLE signature >> >> ( >> >> id SERIAL NOT NULL, >> >> rule_id INT8 NOT NULL UNIQUE, >> >> level INT4, >> >> description VARCHAR(255)NOT NULL, >> >> PRIMARY KEY (id) >> >> ); >> >> Thanks >> >> Kumar > > -- > > --- > 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. -- --- 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: DB schema
Hi, Is there any harm in increasing the varchar in schema. I expect it should be good to change, but not sure if this is defined anywhere in the source code. On Tuesday, 19 July 2016 22:59:00 UTC+5:30, Kumar G wrote: > > Hi all, > > We have a requirement like increasing the description data type from > varchar 255 to higher value. Is it advisable to do this change or we need > to limit ourway description field with in 255 char? > > > CREATE TABLE signature > > ( > > id SERIAL NOT NULL, > > rule_id INT8 NOT NULL UNIQUE, > > level INT4, > > description VARCHAR(255)NOT NULL, > > PRIMARY KEY (id) > > ); > > Thanks > > Kumar > -- --- 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] Irregular Agent Activity in OSSEC agents
Hi Eyal, this is a familiar problem that we have come across in the past as well. The counter of the rids file can run out of sync, if the manager and the respective agent have troubles exchanging control messages. Have you perhaps reinstalled the manager or one of the agents recently? You can fix your problem by following the below steps: 1. On every agent: 1. stop ossec 2. go to: .../ossec/queue/rids (or ossec-agent/rids on Windows) and remove every file in there. 2. Go to the server: 1. Stop ossec 2. Remove the rids file with the same name as the agent id that is reporting errors. 3. Restart the server 4. Restart the agents. If you have reinstalled one of your machines recently, then we recommend that you use the update option. Do not remove and reinstall the ossec server, unless you plan to do the same for all agents. Just a heads up, please refrain from using the same agent key between multiple agents, or the same agent key after you removed/re-installed an agent…. Reference: http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html#fixing-duplicate-errors Regards --- Jose Luis Ruiz Wazuh Inc. j...@wazuh.com On July 20, 2016 at 11:54:41 AM, eyal gershon (gershon...@gmail.com) wrote: Hey Everyone, I am noticing some irregular activity in some of my OSSEC agents - *A little bit about the system - * My Deployment is on 2000~ servers managed from dedicated ossec manager. I currently have 1600~ agents connected on a full basis and 400~ servers who connect and disconnect all the time. All the ports are opened (confirmation with NC and telnet) On my management server I see the following error in the logs - 2016/07/20 05:33:49 ossec-remoted(1407): ERROR: Duplicated counter for '**'. 2016/07/20 05:33:55 ossec-remoted: WARN: Duplicate error: global: I checked the /var/ossec/queue/rids and made sure there is only a single entry in there and that entry is the same on both host and Management. I made a double check and also compared client.keys on both servers,Same Key and same Entry on both servers. I did a key exchange manually between both servers just to make sure Nothing was wrong in that section. Same error. Does anyone have an idea on how to continue? -- --- 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. -- --- 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] Agents going offline intermittnently
On Tue, Jul 19, 2016 at 10:19 AM, Quintin Beukes wrote: > The logs on the agent show this: > 2016/07/19 16:18:27 ossec-agentd(4101): WARN: Waiting for server reply (not > started). Tried: 'ossec.jeoffice/10.10.12.171'. > 2016/07/19 16:18:29 ossec-agentd: INFO: Trying to connect to server > (ossec.jeoffice/10.10.12.171:1514). > 2016/07/19 16:18:29 ossec-agentd: INFO: Using IPv4 for: 10.10.12.171 . > 2016/07/19 16:18:44 ossec-logcollector: WARN: Process locked. Waiting for > permission... > Try turning on debug on the manager (`/var/ossec/bin/ossec-control enable debug && /var/ossec/bin/ossec-control restart`) > Quintin > > On Tue, Jul 19, 2016 at 4:13 PM Quintin Beukes > wrote: >> >> Hi, >> >> A few days ago some of my OSSEC agents started going offline and stop >> sending alerts, and then a long while after come back online again like >> nothing's wrong. Restarting the agents don't help fix the offline status. >> This affects both agents running through a router/firewall to reach the >> server, and agents running in the same subnet as the server. >> >> I removed all iptables filters and did a tcpdump on both offline and >> online agents, but couldn't notice anything out of the ordinary. >> >> Here are packets from an offline agent showing successful traffic from >> server to client and vice versa, as well as some curious port unreachable >> errors. Even though there is traffic, the agent shows as offline and no >> alerts are generated for events on this agent. >> >> OSSEC Server IP: 10.10.12.171 >> Agent IP: 10.10.13.8 >> >> agent_control -l: >>ID: 019, Name: devjerm1, IP: 10.10.13.8, Disconnected >> >> tcpdump: >> 15:47:36.515777 IP 10.10.13.8 > 10.10.12.171: ICMP 10.10.13.8 udp port >> 58989 unreachable, length 109 >> 15:47:36.517646 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 >> 15:47:40.526516 IP 10.10.12.171.1514 > 10.10.13.8.58989: UDP, length 73 >> 15:47:40.526567 IP 10.10.13.8 > 10.10.12.171: ICMP 10.10.13.8 udp port >> 58989 unreachable, length 109 >> 15:47:41.518182 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 >> 15:47:47.518732 IP 10.10.13.8.49382 > 10.10.12.171.1514: UDP, length 73 >> 15:47:59.581518 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 >> 15:48:07.897110 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 >> 15:48:14.725335 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 >> 15:48:19.395627 IP 10.10.12.171.1514 > 10.10.13.8.49382: UDP, length 73 >> 15:48:25.521404 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 >> 15:48:31.522261 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 >> 15:48:35.522794 IP 10.10.13.8.59490 > 10.10.12.171.1514: UDP, length 73 >> >> Any insights are appreciated. >> >> Quintin >> >> -- >> >> --- >> 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. > > -- > > --- > 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. -- --- 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] Custom rules to send email alerts about Chrome Remote Desktop events
On Mon, Jun 6, 2016 at 5:49 PM, Kevin Branch wrote: > The news about folks getting exploited via TeamViewer made me want to get > proactive notification whenever any of my systems get logged into via Chrome > Remote Desktop. These rules will send email alerts about failed and > successful logins via Chrome Remote Desktop, plus generate an OSSEC event > when chromoting sessions close. Feel free to improve on them. > > > 18103 > : chromoting: \.* Access denied for client: > Chrome Remote Desktop attempt - access denied > alert_by_email > > > > 18101 > : chromoting: \.* Client connected: > Chrome Remote Desktop attempt - connected > alert_by_email > > > > 18101 > : chromoting: \.* Client disconnected: > Chrome Remote Desktop attempt - disconnected > > > Thanks to Doug for assisting me in getting these working. > Can you provide log samples for these? > Kevin Branch > > -- > > --- > 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. -- --- 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] Irregular Agent Activity in OSSEC agents
Hey Everyone, I am noticing some irregular activity in some of my OSSEC agents - *A little bit about the system - * My Deployment is on 2000~ servers managed from dedicated ossec manager. I currently have 1600~ agents connected on a full basis and 400~ servers who connect and disconnect all the time. All the ports are opened (confirmation with NC and telnet) On my management server I see the following error in the logs - 2016/07/20 05:33:49 ossec-remoted(1407): ERROR: Duplicated counter for '**'. 2016/07/20 05:33:55 ossec-remoted: WARN: Duplicate error: global: I checked the /var/ossec/queue/rids and made sure there is only a single entry in there and that entry is the same on both host and Management. I made a double check and also compared client.keys on both servers,Same Key and same Entry on both servers. I did a key exchange manually between both servers just to make sure Nothing was wrong in that section. Same error. Does anyone have an idea on how to continue? -- --- 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] Solaris Compilation - Visibility
Tried compiling ossec 2.8.3 under Solaris/x86 5.10 and it worked. Any of these messages are not errors, they are just warnings. Please provide complete output from compiling. Eero 2016-07-19 22:28 GMT+03:00 Kumar Mg : > Hi, > > We also have the agent compilation issue on the Solaris platform with the > 2.8.3 version of code. How can we fix the "Checking for > attribute(visibility) support... No"? > > For time being we updated the lua* conf updated to remove the warning > message, however the below warning are still showing up. > > > *** Making zlib (by Jean-loup Gailly and Mark Adler) *** > cd zlib-1.2.8/; ./configure; make libz.a; > Checking for shared library support... > Building shared library libz.so.1.2.8 with /usr/sfw/bin/gcc. > Checking for off64_t... Yes. > Checking for fseeko... Yes. > Checking for strerror... Yes. > Checking for unistd.h... Yes. > Checking for stdarg.h... Yes. > Checking whether to use vs[n]printf() or s[n]printf()... using > vs[n]printf(). > Checking for vsnprintf() in stdio.h... Yes. > Checking for return value of vsnprintf()... Yes. > Checking for attribute(visibility) support... No. > > > > *** Making monitord *** > > /usr/sfw/bin/gcc -g -Wall -I../ -I../headers -DCLIENT -DUSE_OPENSSL > -DSOLARIS -DHIGHFIRST -DARGV0=\"ossec-monitord\" -DOSSECHIDS -lsocket > -lnsl -lresolv compress_log.c main.c manage_files.c monitor_agents.c > monitord.c sign_log.c generate_reports.c ../os_maild/sendcustomemail.c > ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a > ../os_regex/os_regex.a ../os_xml/os_xml.a ../os_crypto/os_crypto.a > ../os_zlib/os_zlib.c ../external/libz.a -o ossec-monitord > generate_reports.c: In function `generate_reports': > generate_reports.c:59: warning: int format, pid_t arg (arg 4) > /usr/sfw/bin/gcc -g -Wall -I../ -I../headers -DCLIENT -DUSE_OPENSSL > -DSOLARIS -DHIGHFIRST -DARGV0=\"ossec-monitord\" -DOSSECHIDS -lsocket > -lnsl -lresolv -UARGV0 -DARGV0=\"ossec-reportd\" report.c > ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a > ../os_regex/os_regex.a ../os_xml/os_xml.a ../os_crypto/os_crypto.a > ../os_zlib/os_zlib.c ../external/libz.a -o ossec-reportd > > > *** Making os_auth *** > > /usr/sfw/bin/gcc -g -Wall -I../ -I../headers -DCLIENT -DUSE_OPENSSL > -DSOLARIS -DHIGHFIRST -DARGV0=\"ossec-authd\" -DOSSECHIDS -lsocket > -lnsl -lresolv 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 > main-server.c: In function `ssl_error': > main-server.c:53: warning: passing arg 1 of `SSL_get_error' discards > qualifiers from pointer target type > /usr/sfw/bin/gcc -g -Wall -I../ -I../headers -DCLIENT -DUSE_OPENSSL > -DSOLARIS -DHIGHFIRST -DARGV0=\"ossec-authd\" -DOSSECHIDS -lsocket > -lnsl -lresolv main-client.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 agent-auth > > > > If any one can shower some light on this, that will be great. > > > Thanks > Kumar > > -- > > --- > 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. > -- --- 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.
