Hi Steve,
Thanks for the suggestion. I committed your improved decoder to CVS already and
it will be included in the next version. As for having custom
decoders, I am thinking
on creating a new local_decoders.xml, because right now all entries
on decoders.xml
are overwritten during upgrade.
Hi Peter,
I agree with Jeff. If you can send some logs to us, we can definitely write some
rules/decoders for it.
We only have a few samples:
http://www.ossec.net/wiki/index.php/Log_Samples_Sonicwall
But with a few more we can easily add support for it.
*btw, if you prefer, you can send to me
Hi Tom,
Can you send some log samples to us? Our decoder looks for:
decoder name=netscreenfw
program_name^sav00|^ns5gt/program_name
prematch^NetScreen device_id/prematch
/decoder
Probably that's why it only works with ns5gt. However, we were told
this would be
present in all netscreen
Hi Peter,
Note that the timeout for the active response is of 10 minutes, so
after that the ip is going to be removed from block list. If you look
at /var/ossec/logs/active-responses.log do you
see the responses being called? (look at the agent that generated the
alert and not at
the server). If
Hi Peter,
They should happen almost at the same time, with the active response before
the e-mail (most of the time). Basically, as soon as the alert is
fired, it is sent to the os-remoted (on the server), which forwards to
the correct agent.
Hope it helps.
--
Daniel B. Cid
dcid ( at )
Hi DM,
Please give us more information to debug/reproduce your issue. What happens
if you do a service ossec restart? Anything else in the logs besides
these messages?
Most of the time, we need at least the following information:
http://www.ossec.net/wiki/index.php/Community_manual:BugReport
Hi Thorne,
You raise a valid concern regarding our timeouts (which is by default
10 minutes, not 5)
and it was chosen mainly based on some sshd brute force scripts (that
I had access on
the past), which gave up on a specific ip after 5/6 minutes without
response. That's why 10, so they would
Hi Stephen,
It is actually a bug in ossec. You need to set it to: (note the
underline instead of a dash)
active_response
disabledyes/disabled
/active_response
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 8/21/07, Stephen Williamson [EMAIL PROTECTED] wrote:
I have some agents that
Hi Andrew,
There is a very subtle acknowledgement that the rootcheck scan ran
that is stored on the server side. If you go to
/var/ossec/queue/rootcheck you will see one entry for each agent
(plus the one for the server, just named rootcheck).
If you look at any of the files in there, you will
Hi David,
In addition to what you mentioned, if you are using Linux, it can also
be caused by a bug
in an application that is binding to a TCP port, but not listening on
it. For some weird
reason, Linux does not report these ports on netstat...
More info here:
http://www.ossec.net/dcid/?p=87
Hi Daniel,
Are you sure ossec did this? First, it doesn't run on kernel mode, so
even if it crashed, it
would not crash the whole system. It also doesn't use a lot of memory,
so I can't see it
being responsible for that...
Can you show us more information? If you are still getting alerts from
Hi Thorne and Dan,
I just released a snapshot (alfa stage) with some rules/decoders for
mysql error and
generic query logs:
http://www.ossec.net/files/snapshots/ossec-hids-070828.tar.gz
You just need to add your mysql log file to the ossec config:
localfile
Yes, it supports logs from PIX, ASA and FWSM. Most of them are the same and our
decoders handle all cases...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 8/28/07, Patrick Roelke [EMAIL PROTECTED] wrote:
I can't recall if the PIX logs are the same as the ASA but it should
log with no
Hi Stephen,
Sorry about it. I made a fix for it and released it on the following snapshot:
http://www.ossec.net/files/snapshots/ossec-hids-070829.tar.gz
Just install it on your agent and disable active response as it should be:
active-response
disabledyes/disabled
/active-response
Hope it
Hi,
I made some fixes to the cisco IOS decoder and it should work now with the
sequence numbers. However, your syslog server should not add
additional sequence numbers, because it is against the RFC.
If you can try it out (just run the upgrade option):
Hi Peter,
Your rule looks good to me. If you can show us the log that you want
to match, it
may be easier to improve it a bit more. The only change I would do is
to use an id
above 100,000 since these are reserved for local rules.
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On
Hi Reggie,
My suggestion would be:
-Copy the whole /var/ossec and /etc/ossec-init.conf to the new system.
-Reinstall ossec (running the install.sh and choose the upgrade option).
It should do it..
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 9/5/07, Reggie Griffin [EMAIL PROTECTED]
Hi Daniel.
You can execute anything you want in there (from perl, to .sh, java,
etc). It just need
to have the executable flag set and accept the proper arguments (add,
delete, etc).
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On 9/3/07, Dan [EMAIL PROTECTED] wrote:
Hi Ossec List
Hi Slava,
We do not allow the installation to be at /, because we set the
permissions very tight and
it would probably break your system (just imagine /bin not being
accessible)... In addition
to that, ossec runs on chroot and it makes no sense to chroot to /.
*Feel free to re-write the
Hi Eric,
You shouldn't be too worried about, since it is just a scanner or
something like that. If you
do a netcat (or telnet) to your ssh server you will get the same
error. I will reduce the
severity of this one...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 9/12/07, Eric Yeoh [EMAIL
Hi,
A few suggestions to make it work:
1- Simplify your match (taken from David's reply): If you are looking
for a word, just use match (much faster):
matchDuplicate TCP SYN from/match
2- A better solution would be to use the pix ID that you want:
id^4-419002/id
3- Do not write ignore rules
Hi Chris,
The location where the alert came from can be searched using the
hostname tag.
For example:
rule id=110007 level=0
if_sid1003, 31101, 1002/if_sid
hostnameerror_log/hostname
descriptionWeb log ignore./description
/rule
Basically, when you look at an alert it has:
Hi Valerio,
Yes, OSSEC can monitor named logs and you need to use the syslog log
format in the config. You need to look at our rules to see what is wrong...
Can you submit the logs that are generating the false positive to us? It would
be much easier to fix them with that in hand.
Thanks,
--
Hi Daniel,
Regarding how to write the rules, the following documents can help:
http://www.ossec.net/ossec-docs/auscert-2007-dcid.pdf
http://www.ossec.net/wiki/index.php/Know_How:Ignore_Rules
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 9/18/07, Peter M. Abraham [EMAIL PROTECTED] wrote:
Hi Peter,
This log should already be matching the following rule:
rule id=30115 level=5
if_sid30101/if_sid
matchInvalid URI in request/match
descriptionInvalid URI (bad client request)./description
groupinvalid_request,/group
/rule
Isn't it? If you want to ignore this
Hi Paco (and anyone else with the problem),
Can you send a copy of one or two ossec e-mails to us? They must
include the original
headers and the time it was supposed to show. Without that it is going
to be hard to find
out what is going on.
Thanks,
--
Daniel B. Cid
On 9/18/07, Paco Avila
Hi Tim,
They will continue forever :) Basically, we don't queue the logs in
memory, but we just
store the location (pointer) of the last log that was read (and for
integrity checking, the last file checked). When the server is back,
we continue where we left...
Thanks,
--
Daniel B. Cid
dcid (
Hi Dan,
The rotation of the OSSEC logs happen at the end of each day (as soon as the day
changes). It will generate the checksum of the log and gzip it
(alerts.log is just a link to the current day log at
/var/ossec/logs/alerts/Year/Month/day ).
Your tool just needs to check when the inode of
Hi,
It is currently not the possible. The design we chose is that every
e-mail alert will
go to the main address specified in the global section (the alerts
that should be e-mailed are set in the email_alert_level option or
within a specific rule).
From within these e-mails is that we filter
Hi Tomas,
Sebastien Tricaud sent us a patch to add support for IDMEF on ossec,
so it can communicate with Prelude. If you are interested in alpha
versions, you can try it out at:
http://www.ossec.net/files/snapshots/ossec-hids-070927.tar.gz
*Just need to run the following before compiling: cd
Hi Andy,
The best way to ignore those is to write a local rule to ignore the
event, instead of
just ignoring them for the active response. Since you know it is a
false positive, you
don't need to be seeing alerts about them.
Something like that would work (just copy to your local_rules.xml):
Hi,
Actually, this format will not work. You need to specify each email
address on its
own email_to tag:
email_to[EMAIL PROTECTED]/email_to
email_to[EMAIL PROTECTED]/email_to
email_toxxx/email_to
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On 9/27/07, [EMAIL PROTECTED] [EMAIL
Hi Jon,
Generally this is a problem with the keys. Take a look at the
following pages in our FAQ:
http://www.ossec.net/wiki/index.php/Errors:AgentCommunication
http://www.ossec.net/wiki/index.php/Errors:1403
If that doesn't help, try giving us the following info:
? And does OSSEC have a problem with running a seperate
syslog server?
Thanks for all your help.
JM
[1] yes we use NTP for time, but sometimes things go wrong and this
double entry for time has proven to be a great help to us in the past.
On Sep 27, 8:03 pm, Daniel Cid [EMAIL PROTECTED
Hi Chad,
I would suggest ignoring this directory on the ossec server. Just add
an additional line
to the syscheck ignore:
ignoreC:\WINDOWS/system32/inetsrv/History/ignore
It should solve it. For the next version, I will make sure it comes
ignored by default...
Thanks,
--
Daniel B. Cid
dcid (
Hi Nick,
Reply inline...
On 10/2/07, Consolo, Nick [EMAIL PROTECTED] wrote:
Hello,
First of all thanks for all the work on ossec. It's a great product. I
have two questions regarding the syscheck portion of the product.
Thanks :) I am glad you are enjoying it.
1.In the
Hi Wilson,
OSSEC can definitely monitor your logs and generate alerts on real
time. That's why it
was written for :)
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 10/10/07, Wilson Lai [EMAIL PROTECTED] wrote:
Dear ALL,
I have now installed the Syslog-NG server for
Hi Carlos,
OSSEC already has parsers for these logs, but they are coming in a non
standard syslog format.
We expect:
Oct 9 09:50:40 MACHINE sshd[229596]: Accepted password for USER from
172.29.14.41 port 55839 ssh2
While you have:
Oct 9 09:50:40 MACHINE auth|security:info sshd[229596]:
Hi John,
You need to add this configuration to the ossec server, not the agent
(same to the auto_ignore option).
*Also, the alert will only come by the next time syscheck runs (which
is by default every
12 hours).
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 10/9/07, PKTan [EMAIL
( at ) ossec.net
On 10/11/07, Nerijus Krukauskas [EMAIL PROTECTED] wrote:
Hi,
On 11/10/2007, Daniel Cid [EMAIL PROTECTED] wrote:
We expect:
Oct 9 09:50:40 MACHINE sshd[229596]: Accepted password for USER from
172.29.14.41 port 55839 ssh2
While you have:
Oct 9 09:50:40 MACHINE auth
Hi,
We are not there yet :) Some of the configuration can be shared
between the server
and agents (everything under /var/ossec/etc/shared/, including rootkit
check configs, active
responses, application detection, etc), but not the main ossec.conf...
Also, since we have all the rules on the
Hi Andy,
The easiest way is to uninstall OSSEC and reinstall it as an agent. To
uninstall, just do:
# rm -rf /var/ossec/
# rm /etc/ossec-init.conf
And re-run the install.sh...
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On 10/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi
.
Regards,
Dan
Am 19.09.2007 um 03:18 schrieb Daniel Cid:
Hi Daniel,
Regarding how to write the rules, the following documents can help:
http://www.ossec.net/ossec-docs/auscert-2007-dcid.pdf
http://www.ossec.net/wiki/index.php/Know_How:Ignore_Rules
Thanks,
--
Daniel B. Cid
Hi John,
Rick explained it well, just edit your rules at local_rules.xml and
restart the server when
done. Nothing needs to be restarted at the agent side. As for writing
your own rules,
the following document can be very helpful:
http://www.ossec.net/ossec-docs/auscert-2007-dcid.pdf
Thanks,
Hi Peter,
I have ossec running on 64-bit systems without any problem (both Linux
and OpenBSD).
Is there any errors on your server log?
The following links may help:
http://www.ossec.net/wiki/index.php/Errors:AgentCommunication
http://www.ossec.net/wiki/index.php/Errors:1403
Btw, if that
Hi Adjete,
Very strange error. It looks like that your ossec-maild wasn't updated
during the upgrade
process. Can youtry again with the v1.4 BETA2? More information about it at:
http://www.ossec.net/dcid/?p=114
You will need to run a few commands before the ./install.sh this time:
$ cd
Hi David,
Thanks for tracking this down. By default we ignore /proc to avoid
this kind of problem,
but we don't check for it on other places of the system. It would be
nice to have this
information in the wiki if you can post it in there (or anyone else).
I will also look in the code
to see if
Hi Peter,
From your log, it looks like that the agent is working fine, but for
some reason losing the connection to the server very often (and
reconnecting right away). Are you getting events from this agent? Is
there an entry for it at /var/ossec/queue/syscheck ? Is your server
reporting that
( at ) ossec.net
On 10/23/07, Nerijus Krukauskas [EMAIL PROTECTED] wrote:
Hi,
On 12/10/2007, Daniel Cid [EMAIL PROTECTED] wrote:
I made some changes to the pre-decoders within ossec to support the
syslog format
from AIX. If you can try it out from:
http://www.ossec.net/files/snapshots
Hi Marco,
It is in the changelog of the version 1.3:
http://www.ossec.net/announcements/v1.3-2007-08-08.txt
-Fixed file descriptor leak on the Windows agent while reading
the Windows registry.
(Reported by Luke Bradeen lbradeen at suresource.com)
Thanks,
--
Daniel B. Cid
dcid ( at )
Hi Steve,
Are the alerts being generated based on your rule? If yes, can you
show us the output of them? (from /var/ossec/logs/alerts.log ). You
need to make sure that the srcip is present
in the alert (meaning that it was decoded properly), otherwise the
active response is not
going to fire.
Hi Timothy,
I can't help you much with the iptables rules, but you could try using
the local_ip option
in the server config to specify the IP address for OSSEC to use (in
your case the ip of eth0:1).
*example for ip 10.2.3.4:
remote
local_ip10.2.3.4/local_ip
/remote
of logs (plus their location) of your
proftpd, it will help us when adding support for it.
*for the time being, you can probably change the proftpd config to log
directly to syslog...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 10/25/07, Steve West [EMAIL PROTECTED] wrote:
Daniel Cid
Hi Peter,
OSSEC will use the IP address specified by the kernel to access that
specific destination ( the server). So, if you have two ips in
different interfaces configured to be in the same network, your
internal routing is going to be all messed up.
A simple way to fix that is to configure
Hi,
It is currently not officially supported, but Dean Takemori wrote some
decoders for it
already:
http://www.ossec.net/bugs/show_bug.cgi?id=60
The only reason why it is not in there is because of the lacking of
testing and sample
logs. If you can share some of your logs, it can be very
Hi Chris,
Thanks for the information. This is indeed a false positive and can
easily be ignored by adding the
following local rule:
rule id=100101 level=0
if_sid510/if_sid
match^NTFS Alternate data stream found/match
regexProgram Files/Exchsrvr/Mailroot//regex
descriptionIgnored
Hi Peter,
These are false positives for sure. I will make sure to fix it for the
next version.
Thanks for letting us know.
*if you can, please open a bug about it at: http://www.ossec.net/bugs/
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 3, 2007 11:09 AM, Peter M. Abraham [EMAIL PROTECTED]
Hi Dennis,
This is very easy to do with a local rule. You just need to match
based on the policy you added and the agents
you are interested to monitor. Example:
rule id=100122 level=10
if_sid512/if_sid
matchMy custom process check/match
hostnameagent1|agent2|agent3/hostname
Hi Herb,
Every alert is sent to the database, including integrity checking
events. A quick SQL to get
all files that were changed is (for postgresql):
SELECT to_timestamp(timestamp), rule_id, location.name, full_log FROM
alert,location, data WHERE location.id = alert.location_id AND data.id
=
Hi Peter,
Thanks for the suggestions. Can you post your suggestions in our
bugzilla ( www.ossec.net/bugs/ )?
We can certainly do some of them, but the granular from's emails can
be kind of trick with the
current design, where all the messages are sent together in just one e-mail...
Thanks,
--
Hi Thomas,
IF OSSEC is not able to store the alerts in the database, it is
suppose to write the error
to ossec.log and keep trying until it works (so you will not lose any
alerts). As for it just
stopping, we would need more information to try to debug it. Only
ossec-dbd stopped
or all ossec
Hi Peter,
The right syntax is to use commas between the rules ids:
if_sid4801,4803, 4806/if_sid
You can also assign groups to your rules and use if_group to match on them ...
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 17, 2007 12:31 PM, Peter M. Abraham [EMAIL
Hi Peter,
It is currently possible to do what you want. Inside the
active-response configuration there is a location
option where you specify where to execute the response...
It can be:
* local: on the agent that generated the event,
* server: on the OSSEC server,
* defined-agent:
Hey,
Answering to some of the questions in here.
-The logs are first compressed and then encrypted (off course). We use
gzip to compress it.
-The encryption uses blowfish.
-All logs are sent to the server. There is no intelligence on the
agent-side, since it has a very limited
view of what is
Hi Peter,
If you go to /var/ossec/queue/agent-info/ on the server side, you
should have one file for every
agent. Inside these files, you should have the OS and OSSEC version
number of the agents...
# pwd
/var/ossec/queue/agent-info
# cat esqueleto2-192.168.2.99
Linux esqueleto
Hi Aaron,
That's a good information to have in our wiki. Actually, It would be
nice to have all the requirements per distribution in
there:
http://www.ossec.net/wiki/index.php/InstallReqs
Anyone mind helping? Just need to register to the wiki to be able to edit it..
Thanks,
--
Daniel B. Cid
Hi Thomas,
This error happens when ossec-analysisd is not running (it is the
process that creates the
listening sockets). Can you show us all your log? (you can do a cat
ossec.log |grep analysisd).
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 14, 2007 9:43 PM, Thomas [EMAIL
Hi Peter,
This should be very easy to do. If you can show us a few log samples,
I can start a few rules
for you...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 22, 2007 7:07 PM, Peter M. Abraham [EMAIL PROTECTED] wrote:
Greetings:
We use http://kodu.neti.ee/~risto/sec/ for real
Hi Peter,
Just changing the config to the following should to it:
locationall|server/location
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 28, 2007 2:26 PM, Peter M. Abraham [EMAIL PROTECTED] wrote:
Greetings:
We use the locationall/location in active-response to block
Hi Aaron,
Peter's suggestion is pretty good, but you don't need to overwrite the
rule for it. Just
adding the following rule to local_rules.xml should solve your problem.
rule id=100100 level=0
if_sid18107/if_sid
matchLogon Type: 3/match
descriptionWindows Logon type 3
It was also fixed in the following snapshot:
http://www.ossec.net/files/snapshots/ossec-hids-071129.tar.gz
If you guys can try it out to make sure it is ok now.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 29, 2007 1:17 AM, Herb Steck [EMAIL PROTECTED] wrote:
You defiantly want to
Hi Peter,
If the defunct process dies off, then it is working as expected.
Basically, the maild process forks every time
it sends an e-mail and checks after a few minutes if the child process
finished sending it. During this time,
the child process can become defunct while waiting for the parent
Hi,
Your rules/decoders are very good, with just one small problem:
Child decoders will use the parent
name by default instead of its own, so your rules will not match. If
you change it to have use_own_name,
it should work:
decoder name=sendmail-blocked-cbl
use_own_nametrue/use_own_name
Hi Jim,
I am quite lost with your problem in here, since none of these logs
would be parsed
by the default sendmail decoder from ossec. I saw you did a few by
yourself and they
are probably the ones parsing it... Btw, it would be nice to include
them by default on
ossec (if you want to release
Hi Aaron,
The easiest way is to just get the ossec binaries (from /var/ossec/bin) and
move them to the ossec package under the bin directory.
After that, set the etc/preloaded-vars.conf file for the binary install:
USER_BINARYINSTALL=y
With that, you can just run the ./install.sh on any box
Hi Will,
Can you provide a few more details? A few examples? You meant that instead
of the ip address you can have the hostname in the logs? If that's the case we
should fix the decoder for that...
Btw, we have pix information at:
Hi Welkson,
Can you try upgrading to ossec v1.4. We fixed that a while back...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 28, 2007 8:07 AM, Welkson Renny de Medeiros
[EMAIL PROTECTED] wrote:
Others messages:
snort -i tun0 -A full -c /usr/local/etc/snort/snort.conf
[EMAIL
:
Hello,
On Thu, 29 Nov 2007 16:21:02 -0400
Daniel Cid [EMAIL PROTECTED] wrote:
rule 3302 instead of creating a new one (just paste the following on
local_rules.xml).
rule id=3302 level=1 overwrite=yes
if_sid3300/if_sid
id^550$/id
descriptionRejected by access list
You lost me. Why would you want to log in as the user ossec? They should
only be used by the ossec process. If you need to manage ossec, use sudo, su
or just login as root.
Hope it helps.
--
Daniel B. Cid
dcid ( at ) osse.net
On Dec 8, 2007 12:04 PM, Mex [EMAIL PROTECTED] wrote:
Hello
Hi Ulises,
We currently do not support authenticated SMTP, but you shouldn't need it. If
I want to send an e-mail to you, I don't need an account/password in your
SMTP server, right? That's the same principle with the e-mail alerting inside
ossec, since it has a very small and simple smtp
Hi Sergey,
The Windows agent source code is the same as the unix one, so it is all
together in the .tar.gz. Some Windows specific files are inside src/win32.
For information on how to compile on Windows using Mingw:
http://www.ossec.net/dcid/?p=68
To browse the source code:
Hi Kivanio,
The best way is to create a local rule to ignore most of these Amavis logs.
This rule should ignore all Amavis logs (just add that to
/var/ossec/rules/local_rules.xml):
group name=local
rule id=100101 level=0
program_name^amavis/program_name
descriptionAmavis Events
Hi Martin,
Thanks for the additional information. I was able to reproduce the
behavior and fix the problem inside ossec. You
can try with the following package to see if the problem persists.
http://www.ossec.net/files/snapshots/ossec-hids-071218.tar.gz
The issue is that ossec tries to remove
Hi Denis,
Currently they are combined by an OR (if any one of them matches), but
now that you
mentioned it, I think I should change to AND.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Dec 17, 2007 11:39 AM, Denis Shaposhnikov [EMAIL PROTECTED] wrote:
Hello,
From
Hi Peter,
It shouldn't make any different between running OSSEC on a real server
or on vmware, so I think
these problems are more related to network connectivity or some other issue.
Anyway, to troubleshoot ossec-maild, I would try first to send an
e-mail using telnet. From the
log, it says
with the daemon
pointed to the syslog-ng hosts directory.
Daniel Cid wrote:
Hi Wilson,
OSSEC can definitely monitor your logs and generate alerts on real
time. That's why it
was written for :)
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On 10/10/07, Wilson Lai [EMAIL PROTECTED
Hi Xu Feng,
The issue is that you have both level and rules_id in your config,
so ossec is acting on both. Try
leaving it just as:
active-response
commandhost-deny/command
locationlocal/location
rules_id5712,5720/rules_id
timeout600/timeout
/active-response
And it should work.
Hi John,
Currently this is not possible, but you can open a feature request at:
http://www.ossec.net/bugs/
And we will take a look into implementing it.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Dec 31, 2007 5:48 AM, Verlag Neue Stadt [EMAIL PROTECTED] wrote:
Hello,
we would
Hi Tony,
OSSEC by default will only alert by email if the severity is = 7.
Take a look at
/var/ossec/logs/alerts/alerts.log and see you have them (and compare
with the ammount
of emails you got).
# cat /var/ossec/logs/alerts/alerts.log | grep : mail | wc -l
Also, look at
in the
disk?
Thanks in advanced
Salute
Frank Abel
On Tue, 2007-12-18 at 21:25 -0400, Daniel Cid wrote:
Hi Kevin,
For your case, I would suggest using the strftime formats instead of
/*/**. Because the logs change everyday,
you need to tell ossec to keep following the day changes
Hi Dave,
Our wiki has some examples on how to ignore a specific IP address. The
whitelist is only used
for the active response, not for the alerts itself.
Link:
http://www.ossec.net/wiki/index.php/Know_How:Ignore_Rules#Ignoring_a_specific_IP
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
Hi Paco,
If you can forward some log samples to us, we can help you out with the rules.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 15, 2008 8:38 PM, xu Feng [EMAIL PROTECTED] wrote:
Hi
There is support for JBoss logs?
No default rules exist to analyse JBoss logs,but we can
Hi Dave,
If you are trying to ignore these messages, you can set the level to 0
(no need to increase the
severity).
rule id=100101 level=0
if_sid1002/if_sid
matchupdate.bad.phishing.sites|getpeername failed/match
descriptionIgnored messages./description
/rule
Hope it helps.
--
Hi Tom,
Just complementing Steve's response, the granular e-mail alerting are
used to restrict
what is being sent. All the e-mails will still go to the main address
(specified in the global
section), but you can restrict what the other addresses will receive
(only for specified rules
or for
Hi Sam,
Do you have alerts on this system? Did you ran the setup script and
added the Apache
user to the ossec group?
We have some instructions in here:
http://www.ossec.net/wiki/index.php/OSSECWUI:Install
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 14, 2008 9:17 AM, Sam Hancock
Hi Reggie,
Try updating your OSSEC server to the following version:
http://www.ossec.net/dcid/?p=118
It should fix your problem.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 18, 2008 5:14 PM, Reggie Griffin [EMAIL PROTECTED] wrote:
Ok, I got past the rules. I installed a default
Hi Pete,
I think your problem is really related to moving the ossec installs
around. To properly remove it,
just:
1-Stop the ossec processes
2-Remove the /var/ossec directory
3-Remove /etc/ossec-init.conf
As for syscheck, all its data is stored at /var/ossec/queue/syscheck.
So, if you remove
Hi Sherwin,
This could be easily integrated by reading the SDEE messages and forwarding them
via syslog (or writing to a file) for OSSEC. Any Perl guy in here
willing to take this job? :)
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 21, 2008 12:15 AM, Sherwin P. William Abocejo
Hi Steve,
Can you try the following snapshot:
http://www.ossec.net/files/snapshots/ossec-hids-080123.tar.gz
It seems that on version 1.4, OSSEC was still trying to call make on
the binary install. Fixed now.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 21, 2008 2:52 PM, Steve
Hi Roch,
You mean the one to send to BASE the alerts? I don't think there was
ever a mysql reporting tool..
The one for BASE is available at:
http://www.ossec.net/files/ossec2mysql/
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Jan 22, 2008 9:13 AM, Roch [EMAIL PROTECTED] wrote:
Hi,
401 - 500 of 903 matches
Mail list logo