That goes on the manager ossec.conf
The manager takes care of analyzing syscheck data received from the agents, and
generate alerts.
I hope it helps
Santiago Bassett
@santiagobassett
> On Feb 23, 2018, at 9:59 AM, temp.email@gmail.com wrote:
>
> Hi Santiago, I just came across
Hi Arnold,
Wazuh agent version 3.x for Windows can be installed and uninstalled using
a MSI package. Afaik there is a command line tool called msiexec that
allows you to uninstall MSI packages. You can also do some scripting in
Powershell using WMI.
I hope it helps,
Santiago.
On Wed, Feb 7,
That is probably rootcheck trying to detect system anomalies and kernel
level rootkits. It does it by comparing the output of netstat with its own
results binding ports to check if they are open.
Remember that syscheckd not only does FIM, but also Rootchecks (policy
monitoring checks and
Hi,
here is an example of an Auditd rule that makes use of a dynamic field
named "audit.type".
80700
MAC_STATUS
Auditd: SELinux mode (enforcing, permissive, off) is
changed
audit_selinux,pci_dss_10.6.1,
This name of this field is defined in the
Hi,
I would advice to use OSSEC agents to collect system logs data, since you
already have it there doing FIM and anomalies detection anyway. Also
communications are authenticated and encrypted (as opposed to default
Syslog).
Other advantage is that you pre-process them through OSSEC decoders
Yes, afaik, at least Logstash and Rsyslog can be used to parse the alerts
file and split alerts on per agent basis.
On Thu, May 12, 2016 at 8:08 AM, Pedro Sanchez wrote:
> Hi,
>
> You can process alerts.json with Logstash, use a filter in the output
> section and write to
Also works on rhel an oel 7
> On May 12, 2016, at 4:38 AM, dan (ddp) wrote:
>
>> On Thu, May 12, 2016 at 6:37 AM, david franco wrote:
>> Hi
>> I was also searching this topic, specifically about the Operating system
>> requirements.
>> I have read the
Try using this script:
https://github.com/ossec/ossec-hids/blob/master/contrib/ossec-eps.sh
Another option is to enable logall option and count events in archive.log
(you can count all events in a day and then do the math).
Regarding resources it depends on how much data OSSEC manager/agents
That seems doable yes. I haven't seen that done before, but theoretically
should work.
On Tue, May 10, 2016 at 1:35 PM, Jacob Mcgrath
wrote:
> Is it possible to have Ossec monitor Snort logs for certain Sid's and then
> trigger the active response on all agents when
Do you have adduser binary? Try running it manually. I need to add it as a
package dependency, as it seems not every Debian/Ubuntu has it.
If you don't try installing it and then reinstall OSSEC, that should work.
I hope it helps
On Tue, May 10, 2016 at 9:49 AM, Alexandre Laquerre
Hi Adiel,
there are no official minimum requisites. Agents will use more or less
resources depending on the configuration (number of files to be monitored,
logs to be read,...) Ideally you should be able to test the agents in
pre-production environments before deploying them in production.
I've
I think this message just means that the agent has not exchanged data with
the manager during those 10 minutes, and it is just sending a keepalive
message to let it know that it is running. Just informational and nothing
to be worried about.
Regarding agents not connecting back after a restart,
!
>>
>> :)
>>
>>
>> Le mardi 3 mai 2016 17:15:08 UTC+2, Santiago Bassett a écrit :
>>>
>>> Yes, and on the agents too. I know the agents do not run remoted but
>>> they also use this variable to check counters.
>>>
>
Hi Bhuvanesh,
I would advice to actually use OSSEC agents as log collectors as, for PCI
DSS, you will also be using them to perform File Integrity Monitoring and
Configuration checking. Meaning that you already will have an authenticated
and encrypted channel to deliver your logs to a centralized
Yes, and on the agents too. I know the agents do not run remoted but they also
use this variable to check counters.
Santiago Bassett
@santiagobassett
> On May 3, 2016, at 7:36 AM, dan (ddp) <ddp...@gmail.com> wrote:
>
>> On Tue, May 3, 2016 at 10:26 AM, Zekicker <ol.ba
Out of curiosity, what is the rule supposed to trigger the alert? The one
is see by default looks for full partitions...
https://github.com/ossec/ossec-hids/blob/a7ca63d6d074f2f6bdb49f4bc79a054c31dcafc7/etc/rules/ossec_rules.xml#L137
On Mon, Apr 18, 2016 at 2:07 AM, Robert Micallef
was meaning to paste this link before sending last email:
http://ossec-docs.readthedocs.org/en/latest/manual/rootcheck/manual-rootcheck.html
On Tue, Apr 19, 2016 at 5:06 PM, Santiago Bassett <
santiago.bass...@gmail.com> wrote:
> Hi Eyal,
>
> try setting s
Hi Eyal,
try setting syscheck.debug=2 in internal_options.conf file. It looks like
there are some rootchecks that still run, unless you set those to no, like
check_pids, check_dev, check_ports,... see more info at:
On Mon, Apr 18, 2016 at 12:13 PM, wrote:
>
do you have errors in your manager /var/ossec/logs/ossec.log?
In case it helps try disabling rids both on the manager and agents (it is
important to do it in both places). Those probably got messed up during the
upgrade. That can be done modifying internal_options.conf
remoted.verify_msg_id=0
I
Could it be a network issue? I would try running tcpdump both on the agent
and on the manager. It looks like manager responses are not getting to the
agents somehow.
On Thu, Mar 24, 2016 at 1:17 PM, Ben wrote:
> Hi,
>
> I got the same issue here, exact same problem with 2.8.3
For the first use case, I think you should be able to use "same_source_ip"
and "not_same_user" options (I would probably define a frequency threshold
too).
For other cases I guess it all depends on the logs you want to analyze. Do
you have samples?
On Wed, Mar 23, 2016 at 5:51 AM,
Dan now that you mention it I am not 100% sure about this. AI think it is
but haven't had time to fully test it.
On Tue, Mar 22, 2016 at 4:03 AM, dan (ddp) <ddp...@gmail.com> wrote:
> On Mon, Mar 21, 2016 at 8:08 PM, Santiago Bassett
> <santiago.bass...@gmail.com> wrote:
Very nice indeed!!
On Fri, Mar 18, 2016 at 10:52 AM, Antonio Querubin
wrote:
> Nice work!
>
> Sent from my iPad
>
> On Mar 18, 2016, at 03:36, Rodrigo Montoro(Sp0oKeR)
> wrote:
>
> Presentation here: https://www.youtube.com/watch?v=TllGa-POslQ
>
> Nice
Some questions that might help:
- did you restart the agent after changing the configuration? (required,
unless it is pushed from the manager using shared agent.conf file)
- did you specify the frequency of the checks? Most cases alerts are not
generated in real time. Even when using realtime
ossec-maild reads alerts from "alerts.log" file in order to send an email.
I would check that file to see if alerts get written there as expected. If
that is the case, then the manager is not overloaded, and might be an issue
with your email configuration (or SMTP relay).
In some cases I think
In case you are interested we also have RPM packages for EL7
(CentOS/RHEL/...) in our repo:
http://ossec.wazuh.com/
http://documentation.wazuh.com/en/latest/ossec_installation_rpm.html
Regards
On Sat, Mar 19, 2016 at 5:37 AM, Eero Volotinen
wrote:
> You need to install
Hi,
I am sorry but it is not. This are the compilation options used to build
the Debian packages:
echo "HEXTRA=-DMAX_AGENTS=16384" >> src/Config.OS
(cd src; make setdb; make all; make build)
Meaning that there is support for databases but not for prelude output.
I'll take that into account when
Where are you including the configuration? That should go in the file:
/var/ossec/etc/shared/win_malware_rcl.txt
Please paste the contents of that file.
Thank you
On Mon, Mar 14, 2016 at 11:12 PM, 林威任 wrote:
> sorry,this email is google apps for education.
> About my
your emails are very difficult to understand. Please explain better and
give some more context.
Thank you
On Mon, Mar 14, 2016 at 8:59 PM, 林威任 wrote:
> Excuse me,
> (Windows Malware: Trojan Dropper.
> File: C:\Users\IEUser\AppData\Local\Temp\AcroRD32.exe. Reference:
>
It looks like the configuration for rootcheck doesn't have the right
format. I think you are inserting some extra line breaks.
It should look like this:
[Trojan Dropper] [all] [0A37D49E798F50C8F1010D5CFDE0E851]
f:C:\Users\IEUser\AppData\Local\Temp\AcroRD32.exe;
Here you go (just created the github repo)
https://github.com/santiago-bassett/malware-samples/blob/master/0A37D49E798F50C8F1010D5CFDE0E851.zip
Password: "malware"
On Sun, Mar 13, 2016 at 10:20 PM, <m0361...@gm.ncue.edu.tw> wrote:
> I really need it.
> How ca
On Fri, Mar 11, 2016 at 1:30 PM, Ben wrote:
> Hi,
>
> I googled for the following error message and can not find anything, so I
> hope someone can help in this group.
>
> I am using agentless to do file integrity check using the
> ssh_integrity_check_linux script. Everything
Hi Kai,
did you find a solution to your issue? If not, could you copy/paste your
configuration/tests, not sure I understand everything you said.
On Tue, Mar 8, 2016 at 9:51 PM, Kai wrote:
> Hi,
>
> I have a strange problem which I can't solve.
> OSSEC v8.2.3 is working
Hi, are you looking fore the malware sample I used in the presentation?
(hash 0A37D49E798F50C8F1010D5CFDE0E851)
I still have it if you need it.
Best
On Tue, Mar 8, 2016 at 10:37 PM, wrote:
> I has written this code so far.
>
> [Trojan Downloader] [all]
gt; I did this and not remoted is running (thank you!!!) but I am still not
> getting any alerts for added, modified, removed files in the ossec.log. Am
> I looking in the wrong place?
>
> On Sunday, March 6, 2016 at 1:30:51 PM UTC-5, Santiago Bassett wrote:
>>
>> Forgot to menti
Forgot to mention that you need to restart OSSEC (in the manager), once you
have done that.
On Sun, Mar 6, 2016 at 10:29 AM, Santiago Bassett <
santiago.bass...@gmail.com> wrote:
> Most likely you just need to register the first agent, so
> /var/ossec/etc/client.keys gets created.
Most likely you just need to register the first agent, so
/var/ossec/etc/client.keys gets created. You can use
/var/ossec/bin/manage_agents to register it (use "add an agent" option).
I hope it helps
On Sun, Mar 6, 2016 at 9:41 AM, Tennisha tennisha
wrote:
> I have tried to
Hi Umesh,
We do provide professional services in Wazuh (http://www.wazuh.com). Reach us
if interested.
Best
> On Mar 4, 2016, at 6:35 AM, Umesh Prabhu wrote:
>
> Please let me know if you or know of anyone who can help us with OS-SE
> installation and configuration
for the directory monitored in
realtime. This can take SYSTEM_WAIT (300 seconds, hardcoded) + time to run
the syscheck + time to run the rootcheck.
Hope that helps
On Thu, Mar 3, 2016 at 10:35 AM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Mar 3, 2016 at 1:27 PM, Santiago Bassett
> &l
Weird, are you sure the ignored directories are getting scanned? Maybe have
a duplicated directory given to the Syscheck both in ossec.conf and
agent.conf?
On Thu, Mar 3, 2016 at 7:00 AM, Joseph cosgrove
wrote:
> I have a large number of applications that i need to
Yes, it is possible. You need to use OSSEC logall option and have
logstash/filebeat reading /var/ossec/logs/archives.log
My advice is to use different Elastcisearch indexes, one for the alerts and
one for the raw logs (archives)
On Wed, Mar 2, 2016 at 11:16 PM, Bhuvanesh Bhuvanachandran <
Try also running ossec-analysisd manually in debug mode (-d -d). It will
probably give a little more info about the error in the configuration.
On Wed, Mar 2, 2016 at 7:30 AM, Fredrik wrote:
> Only a suggestion, but have you tried 2.3.4.0/24 given
> that 2.3.4.5/24 is
.(agent_name) agent_ip->syscheck.cpt
If I remember it correctly this is a hidden file that OSSEC users to
identify when the syscheck database, when it has finished writing into the
syscheck file.
"cpt" file extension stands for completed, meaning that syscheck scan has
finished.
This is on top
Agree with Daniel. Just want to add another clarification:
When you choose server profile, it will install the OSSEC manager and agent
components, meaning that you can also monitor your local system. No need to
choose hybrid mode unless you plan to forward data to another OSSEC manager.
On Thu,
Did you say other alerts are triggering emails correctly? Everything looks
good to me, but here are some questions that might help troubleshoot the
problem.
Do you see the alert in alerts.log file?
Have you configured other global email settings?
What is your email_alerts_level?
On Tue, Feb 23,
Short answer yes, deleting it from client.keys is enough.
On the other hand, although it is not necessary, there are also some
residual files you might want to delete as well. Those are in
/var/ossec/queue/rids (message counters), /var/ossec/queue/syscheck (fim
database),
This is because manage_agent also uses a chroot environment, changing root
directory to OSSEC home (/var/ossec)
Try running the command with strace and you will see something like this:
...
setgid(1003)= 0
chdir("/var/ossec") = 0
no, you need to restart the manager, after the first agent is added. Once
that is done then you don't need to restart it anymore. You can actually
insert a dummy agent, if you really need to have remoted running since the
very beginning.
best
On Fri, Feb 19, 2016 at 5:16 PM, Barry Kaplan
Not normal. OSSEC process should not start again if they are already
running.
Try using "/var/ossec/bin/ossec-control stop" and killing the remaining
processes. Then run "/var/ossec/bin/ossec-control start" multiple times and
lets see what happens. This is what I get in my installation:
gt; looking for rules under /var/ossec/opt/ossec/rules instead of
> /opt/ossec/rules.
>
> On Tuesday, February 16, 2016 at 6:24:46 PM UTC-8, Santiago Bassett wrote:
>>
>> This is because ossec-analysisd process runs in a chroot environment, so
>> it can't reach anyt
This is because ossec-analysisd process runs in a chroot environment, so it
can't reach anything out of the jail (/var/ossec).
In some scenarios, when really necessary, what we do is remount a partition
inside the jail (mount -o bind). I don't recommend this, but it is a
workaround that should
Hi Brian,
when running it through ossec-logtest, this is what I get:
**Phase 1: Completed pre-decoding.
full event: '[Tue Feb 16 04:02:21.018764 2016] [:error] [pid 3223]
[client 46.4.84.147] ModSecurity: Access denied with code 403 (phase 2).
String match "JDatabaseDriverMysqli" at
Hi,
I think this issue you are experiencing is related to this bug:
https://github.com/ossec/ossec-hids/issues/42
For some reason in Windows system resulting checksums do not seem to match
the real md5 and sha1 checksums. This works well on Unix, but not on
Windows.
I tested it in my lab and
This post is duplicated. Answered in the other thread.
On Thu, Feb 11, 2016 at 6:42 AM, wrote:
> For a couple of weeks we've been trying to isolate intermittent cases
> where OSSEC is reporting MD5 and SHA1 checksums changing for a file, only
> to have it report again in
c/logs/archives/archives.log
>
> how to resolve it? and why my logs are going in archives?
>
> marți, 9 februarie 2016, 18:03:27 UTC+2, Santiago Bassett a scris:
>>
>> ossec-logcollector seems to be reading the file on the agent side.
>>
>> Does the agent a
You need to enable Auditd on your system:
http://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers
Then you can use our rules for Auditd.
https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/rules/auditd_rules.xml
Hope that helps
On Wed,
c@*.**
>
>
>
>
> 1
> 6
>
>
>
> the results are the same :( more suggestions?
>
>
> marți, 9 februarie 2016, 04:53:05 UTC+2, Santiago Bassett a scris:
>>
>> Hi Maxim,
>>
>> please check that ossec-logcoll
Hi Maxim,
please check that ossec-logcollector process is running and reading that
file. You can do
lsof /var/log/apache2/error.log
If that is not the case there might be something wrong with the
configuration (maybe a typo).
If it is reading the logs, try enabling logall option on the OSSEC
25 key++;
> 126 }
> 127
> 128 return(hash_key);
> 129 }
>
> I might ask that the actual manager / ID failing hash be included in the
> error (or debug) log, that way we could "out of band" (not within OSSEC
> itself) attempt to identify client keys using an extern
Elasticsearch search queue size?
https://github.com/elastic/kibana/issues/3221
On Wed, Feb 3, 2016 at 10:26 AM, wrote:
> Hello Group,
>
> I'm wondering what the following error indicates and means:
> What does Courier Fetch x of xxx shards failed mean?
>
> Thanks so
ine OS_HEADER_SIZE OS_SIZE_128 /* Maximum header size */
#define OS_LOG_HEADER OS_SIZE_256 /* Maximum log header size */
#define IPSIZE 16 /* IP Address size */
On Tue, Feb 2, 2016 at 10:33 AM, Santiago Bassett <
santiag
How big are those logs, do you have an example?
This kind of behavior has been reported several times in the last few days
(for different use cases). Haven't had time to look into it but I assume is
a limitation in the alert size. Have you tried using logall option? Do you
see the complete event
Hi Sandeep,
those issues are probably not related to each other. Removing the
client.keys file, and the files in queue/rids, queue/agent-info
queue/syscheck and queue/rootcheck should be enough.
Any error message in your agent or manager log files?
On Mon, Feb 1, 2016 at 7:19 AM, sandeep
t by size, forcing it to always fit into 1 packet.
> Moving to TCP would
> solve this limitation (this is something I am trying to work right now
> --> move to TCP+OpenSSL for the agent->manager communication).
>
> thanks,
>
> On Tue, Feb 2, 2016 at 4:24 PM, Santiago
Yes, same thing happened to me in the past and I think is a limitation in
the message size. I ended up changing the command, but I guess recompiling
would work too.
Best
On Fri, Jan 29, 2016 at 3:31 AM, q
wrote:
> Hello!
>
> i have a problem with a long
I think this is due to a limitation on the alert message size. I guess, you
will need to look in the code and recompile if you want this to work.
On Thu, Jan 28, 2016 at 3:12 PM, q
wrote:
>
> list,sorry for typo
>
> the first example is not "from
Will do, thank you!
On Tue, Feb 2, 2016 at 7:10 PM, Antonio Querubin <t...@lavanauts.org> wrote:
> On Tue, 2 Feb 2016, Santiago Bassett wrote:
>
> From src/headers/defs.h, here are some interesting constants
>>
>> #define OS_MAXSTR OS_SIZE_6144/*
Server 2 external port 456 Nats to -> port 22
> "
> "
>
>
>
>
> On Monday, January 25, 2016 at 1:21:13 PM UTC-5, Santiago Bassett wrote:
>>
>> Afaik, you will need to modify the script.
>>
>> Try changing this line:
>>
>> spawn ss
Are you sure it is not in the alerts file? ossec-maild (the smtp agent)
reads the alerts.log file in order to send emails. See below:
root@vpc-ossec-manager:~# lsof /var/ossec/logs/alerts/alerts.log
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ossec-csy 506 ossecm3r REG
,
> Fredrik
>
> On Thursday, January 28, 2016 at 12:12:53 AM UTC+1, Santiago Bassett wrote:
>>
>> Agree with Dan, also double check the regexes, as it looks like there are
>> some inconsistencies at the end. I don't think that \D+ is in the right
>> place.
>>
>
If you have not done it already, try enabling "logall" option in the ossec
manager configuration file (global section). Then check your
/var/ossec/logs/archives/archives.log and see if those are getting there.
If that is the case, then agent is forwarding the logs but they are just
not triggering
Are you sure your config is not working?
I just tested this and it works for me:
/root
I created three test files:
root@vpc-ossec-manager:~# ls test.txt*
test.txt1 test.txt2 test.txt3
And this is what I get in my syscheck file:
root@vpc-ossec-manager:~# cat
Agree with Dan, also double check the regexes, as it looks like there are
some inconsistencies at the end. I don't think that \D+ is in the right
place.
Best
On Wed, Jan 27, 2016 at 7:08 AM, dan (ddp) wrote:
>
> On Jan 27, 2016 10:06 AM, "Fredrik"
Thanks Daniel! I'll definitely try the integration with Slack. Cool stuff.
On Wed, Jan 27, 2016 at 10:57 AM, Daniel Cid wrote:
> I have been working on the integrator daemon (ossec-integratord) to allow
> OSSEC
> to easily integrate with external APIs to send alerts &
Afaik, you will need to modify the script.
Try changing this line:
spawn ssh $hostname
By:
spawn ssh -p 1234 $hostname
Hope that helps
On Mon, Jan 25, 2016 at 7:03 AM, Log wrote:
> Disclaimer: I'm working with ossec for the first time.
>
> Is it possible to set up
If you don't mind touching the code, you can modify the scrip to ignore
certain files.
The script for remote file integrity monitoring in linux is
"ssh_integrity_check_linux" and it runs the following command:
send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do
tail \$i
I am afraid I don't understand the problem or question, maybe if you
explain it a little bit more we can help better.
Best
On Thu, Jan 21, 2016 at 7:56 AM, Xavier Mertens wrote:
> Hi *,
>
> Maybe a stupid question but I'm investigating an issue and I've to browse
> my
I would say you need to quiet that rule. You can either set the email alert
threshold higher, or silence that particular rule.
I haven't seen that rule, but I definitely wouldn't like to get an email
every time my iptables drops a packet or denies a connection.
Best regards
On Tue, Jan 19, 2016
Hi Christian,
what is exactly the question. Everything looks pretty good to me. Is it not
working?
Not sure about this regex:
^ \w+.\w+.\d+ (\d+) (\d+.\d+.\d+.\d+) (\w+)
(\d+) IP (\d+.\d+.\d+.\d+)
Have you tried ossec-logtest?
Best
On Tue, Jan 19, 2016 at 8:30 AM, Christian Castro <
Hi,
if I understood the question correctly I think you just need to configure a
new "localfile" section in your ossec.conf file. Regarding formats, here
are the options:
On Thu, Jan 14, 2016 at 9:00 AM, Joao T. wrote:
> So in that case i dont need to use syslog to read the
Sorry, sent my email unfinished. The documentation for localfile options
can be found here:
http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.localfile.html
Hope that helps
On Thu, Jan 14, 2016 at 10:05 AM, Santiago Bassett <
santiago.bass...@gmail.com> wrote:
> Hi,
Yes, also answered your email in our mailing list :-)
"install.sh" script will ask you if you want to update.
Best
On Thu, Jan 14, 2016 at 12:43 PM, Fletcher Cocquyt
wrote:
> Hi, I was working through the excellent ELK guide and ran into this issue
> where logstash expects
Hi,
Wazuh ruleset includes more than 200 new rules and mapping with PCI DSS
controls (tagging also out-of-the box OSSEC rules). We started this effort
for some of the OSSEC deployments we are working on, and decided it was a
good idea to put together a ruleset (specially for cases where OSSEC is
than the ones I know to work. I spent
> a bit of time contributing back to Josh's Github repository for them and
> hit the wall with some of the variations of sysmon logs
>
> Thanks for the explanation! I'll take a look at Wazuh.
>
> On Wednesday, January 13, 2016 at 12:25:36 PM UT
rd into an existing Kibana installation?
>
> Thanks,
>
>
> On Tuesday, January 5, 2016 at 2:14:47 PM UTC-5, Santiago Bassett wrote:
>>
>> Hi,
>>
>> the dashboards we have created can be found here:
>>
>> https://github.com/wazuh/ossec-wazuh/tree/master/ext
wondering if you had any
> customized dashboards or favorite OSSEC rules to share?
>
> Thanks for all the great work.
>
>
>
> On Tuesday, December 22, 2015 at 10:44:07 PM UTC-5, Santiago Bassett wrote:
>>
>> Hi,
>>
>> in case you are interested, we have d
updated.
Best
On Tue, Jan 5, 2016 at 11:14 AM, Santiago Bassett <
santiago.bass...@gmail.com> wrote:
> Hi,
>
> the dashboards we have created can be found here:
>
> https://github.com/wazuh/ossec-wazuh/tree/master/extensions/kibana
>
> Regarding the rules, here is the r
Usually there are warning or error messages in ossec.log file (check those
both in the agent and manager).
On Mon, Jan 4, 2016 at 11:06 AM, Cal wrote:
> Found a solution, thinking it might be a key issue. On one server, I had
> to chmod the keys file, which allowed
How about using Comp-\S+? I would also recommend to use a variable like
this (taken from syslog rules):
core_dumped|failure|error|attack|bad |illegal
|denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted
On Mon, Dec 28, 2015 at 10:22 AM, wrote:
>
Maxim I would recommend you to use a separate log management system, as I
would not say OSSEC covers all a system like this does.
For example you can use Splunk or ELK Stack (my preferred choice as it is
also free Open Source), or SIEM systems (AlienVault, Arcsight,...)
I hope that helps,
Hi Maxim,
although not an out of the box feature (as Dan mentioned), the
identification of the user who made a change can be done using auditd (on
Linux) or enabling audit policies (on Windows).
OSSEC can be used to analyze Auditd logs, and Windows events, (using
decoders/rules), generating
Hi,
Windows informational event rule has level "0", meaning that an alert won't
be generated, unless you take down the alert level threshold
(log_alert_level, set to "1" by default).
My advice is to create a new rule instead just for events with ID "2005" in
order to trigger an alert. I guess
The first error is caused because some rootcheck rules use $web_dirs
variable, as defined in system_audit_rcl.txt file.
system_audit_rcl.txt:
$web_dirs=/var/www,/var/htdocs,/home/httpd,/usr/local/apache,/usr/local/
apache2,/usr/local/www;
Theresa, if you don't use those files you can tune that
Hi,
in case you are interested, we have done some work integrating OSSEC with
ELK (specially for those using them to be compliant with PCI DSS, not sure
if this is the case), including the creation of Kibana dashboards.
We have also created a RESTful API for OSSEC that we plan to use with new
m : Yes
> > log_application : Yes
> > log_tomcat : Yes
> >
> > *
> >
> > Reuirement is : -
> >
> > If any changes have been done in parameters Server ,Port ,Services
> > ,log_tomcat notify to certain ema
Not sure why that is not working but, why did you create new decoders? You
could probably use syscheck fields (as Dan mentioned), a good list can be
found here:
http://ossec-docs.readthedocs.org/en/latest/formats/json.html
On Mon, Dec 21, 2015 at 4:59 AM, dan (ddp) wrote:
>
Hi,
Dan is right, we were migrating DNS servers, and still some entries have
not been propagated. I think is a matter of hours to get all back to live
(everywhere).
Sorry for the inconvenience!
Best regards
On Tue, Dec 15, 2015 at 6:05 AM, dan (ddp) wrote:
>
> On Dec 15,
Try disabling counters. They lose synchronization specially when agents are
reinstalled.
Edit /var/ossec/etc/internal_options.conf and set "remoted.verify_msg_id=0"
Then restart ossec manager.
On Mon, Dec 14, 2015 at 9:43 AM, Jamey B wrote:
> Hi everyone,
>
> I'm in a
Hi,
agents forward all log messages to the server. I assume what you want is to
tune the rules, so they stop generating alerts for some cases. That can be
done cloning the rule in local_rules.xml, using overwrite option and
lowering the level to "0" (or using "noalert" parameter).
Hope that
ped
> Powershell Function (501-Stopped).
>
>
>
> I have also created a custom OSSIM plugin for AlienVault to get the alerts
> into the SEIM:
> /etc/ossim/agent/plugins/powershell.cfg: (ATTACHED FILE)
> /etc/ossim/agent/plugins/powershell.sql: (ATTACHED FILE)
>
>
1 - 100 of 219 matches
Mail list logo