[ossec-list] active response scripts using wrong locale

2019-04-19 Thread 'Christian Beer' via ossec-list
Hi,

this problem is not new to me and I mainly ignore it but now I thought
to tackle it again since I moved to a new server and installed
ossec-server using the atomicorp debian packages.

I have a fairly default use case and have a ossec server with one agent
attached to it. I also have active response enabled using the default
scripts. This is all working. Where I have a problem is the active
response logfile. In particular the way time and date is logged to the file.

I installed ossec on this server on Feb 16 and the format is as I expected:
Sat Feb 16 14:11:29 CET 2019 /var/ossec/active-response/...

But after upgrading the server from debian stable to testing the output
changed:
Sat Apr  6 12:19:14 CEST 2019 /var/ossec/active-response/...
Sat 06 Apr 2019 12:39:54 PM CEST /var/ossec/active-response/...

I just noticed this now and I looked up the locale configuration for
root and it was set to en_US.UTF-8 which is not what I want. So I
changed the default system locale to C.UTF-8. After restarting ossec the
output of the ar scripts hasn't changed. I logged out and logged in as
root again to verify that the date output is as I want and yes it is:
Fri Apr 19 19:38:34 CEST 2019

So my question is where does the process that triggers active response
gets its locale from? How can I change that so I get a 24h time format
not the AM/PM format.

Normally I would ignore it but I have a script that gathers the number
of active responses for a given time period and it needs to parse the
date and time from the logfile reliably.

Regards
Christian

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ossec-list] OSSEC + Active Response + ModSecurity Issues

2015-07-16 Thread 'Christian Beer' via ossec-list
I just tested your log with the latest code from github and it triggered
rule 30411 as expected. So you should update your decoder and rule files
at least the apache ones.
I couldn't tell if the srcip was extracted but it should have.

The [:error] is the new apache 2.4 log format.

Regards
Christian

Am 16.07.2015 um 21:44 schrieb greybrimstone:
 Oh and one more thing... why do my logs have [:error] rather than
 [error]... what's the deal?
 
 On Thursday, July 16, 2015 at 3:09:49 PM UTC-4, greybrimstone wrote:
 
 Hi Dan, thank you for the reply.  My comments are embedded within.
 
 On Thursday, July 16, 2015 at 2:55:12 PM UTC-4, dan (ddpbsd) wrote:
 
 
 On Jul 16, 2015 2:50 PM, greybrimstone adr...@netragard.com
 wrote:
 
  Hi All, 
 
  I am in need of some assistance.  I've been trying to get
 OSSEC to respond to mod security events by banning IP addresses
 that generate events of level 6+.  
 
  1-) I have apache error logs configured and piped to
 /var/log/apache2/error.log
  2-) ModSecurity events are correctly being sent to the error log:
 
  [Thu Jul 16 14:25:18.746621 2015] [:error] [pid 17398] [client
 xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase 1).
 Pattern match wp-login.php at REQUEST_URI. [file
 
 /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_61_customrules.conf]
 [line 49] [id 46] [hostname www.xxx.com
 http://www.xxx.com] [uri /wp-login.php] [unique_id
 Vaf3DgoFB9wAAEP2b4ME]
 
 
 Is the IP properly decoded when you run this log through
 ossec-logtest?
 
 
 It appears that srcip is not being properly decoded.  How do I
 resolve this?
 
 [root@ossec bin]# /var/ossec/bin/ossec-logtest 
 
 2015/07/16 15:00:50 ossec-testrule: INFO: Reading local decoder file.
 
 2015/07/16 15:00:50 ossec-testrule: INFO: Started (pid: 391).
 
 ossec-testrule: Type one log per line.
 
 
 [Thu Jul 16 14:46:14.691767 2015] [:error] [pid 17396] [client
 50.22.203.210] ModSecurity: Access denied with code 403 (phase 1).
 Pattern match wp-login.php at REQUEST_URI. [file
 
 /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_61_customrules.conf]
 [line 49] [id 46] [hostname www.netragard.com
 http://www.netragard.com] [uri /wp-login.php] [unique_id
 Vaf79goFB9wAAEP0hpAC]
 
 
 
 **Phase 1: Completed pre-decoding.
 
full event: '[Thu Jul 16 14:46:14.691767 2015] [:error] [pid
 17396] [client xx.xx.xx.xx] ModSecurity: Access denied with code 403
 (phase 1). Pattern match wp-login.php at REQUEST_URI. [file
 
 /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_61_customrules.conf]
 [line 49] [id 46] [hostname www.netragard.com
 http://www.netragard.com] [uri /wp-login.php] [unique_id
 Vaf79goFB9wAAEP0hpAC]'
 
hostname: 'ossec'
 
program_name: '(null)'
 
log: '[Thu Jul 16 14:46:14.691767 2015] [:error] [pid 17396]
 [client xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase
 1). Pattern match wp-login.php at REQUEST_URI. [file
 
 /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_61_customrules.conf]
 [line 49] [id 46] [hostname www.netragard.com
 http://www.netragard.com] [uri /wp-login.php] [unique_id
 Vaf79goFB9wAAEP0hpAC]'
 
 
 **Phase 2: Completed decoding.
 
No decoder matched.
 
 
 **Phase 3: Completed filtering (rules).
 
Rule id: '100051'
 
Level: '7'
 
Description: 'WARNING: wp-admin access detected'
 
 **Alert to be generated.
 
 
  
 
 
  3-) When I create a rule with srcip!xx.xx.xx.xx/srcip in
 the local_rules.xml file that rule no longer fires for
 xx.xx.xx.xx which is expected.  I did that to test and make sure
 that scrip was being properly extracted.  
 
 
 What is the exclamation point for?
 
 
 It was to filter out the attack from the test system.  I figured if
 it detected the IP address then it was parsing the srcip
 correctly... apparently I was wrong.
  
 
  4-) When I remove the srcip!xx.xx.xx.xx/srcip  the rule
 fires just fine, I see the event in the alerts. 
 
  5-) Active Response is never called and xx.xx.xx.xx is not
 blocked.  That said, active response is triggered by other
 servers with other events and those events are resulting in blocks. 
 
  
 
 What is your AR configuration? Is ossec-execd running on the
 agent that isn't running the AR block?
 
 
 Yes, ossec-execd is running.   The mail server is successfully
 extracting and blocking IP's on all agents including www which is
 the agent in question.  My AR configuration is as follows:
 
   !-- Active 

Re: [ossec-list] Storing alerts as JSON problem

2015-03-12 Thread Christian Beer
From:
http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.global.html#element-jsonout_output
and:
http://ossec-docs.readthedocs.org/en/latest/manual/output/json-alert-log-output.html

Note: This feature first appeared in OSSEC 2.9.

Regards
Christian

Am 12.03.2015 um 09:39 schrieb Juan Carlos Jimenez:
 hello, im trying to configure Ossec to store alerts in JSON format, but
 the configuration method on the ossec´s documentation seems not working.
 
 ossec_config
   global
 jsonout_outputyes/jsonout_output
 ...
   /global
   ...
 /ossec_config
 
 When I restart the ossec-control to apply changes, this error appears: 
 /OSSEC analysisd: Testing rules failed. Configuration error. Exiting./
 
 I´m using 'Server Virtual Appliance 2.8.1 .ova'  on a VirtualBox. Any 
 solutions? Thank you.
 
 
 -- 
 
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com
 mailto: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] OSSEC Decodes for Cisco ASA CX - Context-Aware Firewall - PRSM

2015-03-10 Thread Christian Beer
Here is the commit:
https://github.com/score1more4me/ossec-hids/commit/ed45c6fc6fe02a9016e1e709f17a1960fcf42c40

It's not a pull request yet.

Regards
Christian


Am 10.03.2015 um 21:14 schrieb Brent Morris:
 Well  I think it worked..  I stumbled my way through GIT but managed
 to push my changes back to the project.
 
 I chose some rule id numbers close to the Cisco VPN concentrator - it
 looked like there was a gap in numbers in that rule section to the next.
 
 I can also submit the decodes for the on-prem Microsoft Azure 2FA if
 that would help (I posted earlier on this).
 
 Thanks for your help!
 
 On Tuesday, February 3, 2015 at 7:54:48 AM UTC-8, dan (ddpbsd) wrote:
 
 On Tue, Feb 3, 2015 at 8:44 AM, Brent Morris brent@gmail.com
 wrote:
  Greetings all.
 
  Would it be better to submit a pull request on github to get these
 included
  in the next release of OSSEC?  I'm not github aware... never used
 it other
  than to download stuff.
 
 
 Submitting a pull request is the best way to get these included. I can
 do it if you really need me to.
 The basic process is:
 create an account/login to your account
 Fork the ossec-hids project
 Clone your repo on your local system
 Apply your changes
 `git add` changed files
 `git commit` and add a useful commit message
 `git push` your changes to your repository
 Go to https://github.com/ossec/ossec-hids
 https://github.com/ossec/ossec-hids and click the new link at
 the top asking if you want to compare changes/submit a pull request.
 
  Here are my final decodes for ASA CX - These are coming off a Cisco
  ASA-5515X with PRSM on-box.  The advantage to sending these to a
 syslog
  server is that you can keep the logs from the on-box PRSM as
 long as you
  like.  On-Box PRSM only allows 30 days of rolling logs, and the
 reporting
  feature leaves much to be desired.  Off-box PRSM is a separate
 license/cost
  item, and does a little more but still leaves much to be desired in
  reporting.  It also supports Syslog.  Downside to syslog is that the
  messages sometimes hit the limit of syslog size and are truncated.
  I've
  accommodated for this by picking out the interesting bits usually
 included
  toward the beginning of the message.  the URL= portion of the log can
  sometimes be extremely long in today's world.  After speaking to
 Cisco TAC -
  they said 1024 bytes was the max they could send - referencing
  http://tools.ietf.org/html/rfc3164#section-4
 http://tools.ietf.org/html/rfc3164#section-4 - So without further
 ado
 
 
 
  local_rules.xml
 
 
 
  group name=syslog,cisco-cx,
rule id=100210 level=0
decoded_ascisco-cx/decoded_as
descriptionCisco CX Flows./description
/rule
 
  rule id=100211 level=10
if_sid100210/if_sid
matchDeny/match
descriptionFlow Denied/description
/rule
 
  /group
 
  local_decoder.xml
 
decoder name=cisco-cx
 
 
 
 prematch^\d\s\d\d\d\d-\d\d-\d\d\w\d\d:\d\d:\d\d.\d\d\dZ\s\d+.\d+.\d+.\d+\sCiscoNGFW\s\d\d\d\d\s/prematch
 
/decoder
 
decoder name=cisco-cxalert
 parentcisco-cx/parent
 prematch offset=after_parent^1|^2|^3|^4|^5/prematch
 regex
 
 
 offset=after_parent\.+Flow_DstIp=\p(\d+.\d+.\d+.\d+)\p\.+Flow_SrcIp=(\d+.\d+.\d+.\d+)\.+Url_Category_Name=(\w+\s*\w*\s*\w*\s*\w*)
 
  \.+Url=(\.+)\.*/regex
 orderdstip,srcip,extra_data,url,action/order
/decoder
 
decoder name=cisco-cxalert2
 parentcisco-cx/parent
 prematch offset=after_parent^6|^7|^8|^9|^10/prematch
regex
 
 
 offset=after_parent^\.+Web_Reputation_Threat_Type=(\w+\s*\w*\s*\w*\s*\w*)\.*Event_Type_Name=(\w+\s*\w*\s*\w*\s*\w*)
 
  User_Realm=(\w+\p*\w*\p*\w*\p*\w*)\.+Url=(\.+)\.*/regex
orderstatus,action,user,url/order
/decoder
 
 
  Sample Logs.
 
  Flow Denied
 
  1 2015-02-02T23:09:03.733Z 1.1.1.23 CiscoNGFW 2827 6 [ngfwEvent@9
  Flow_Dst_Service=tcp/80 Flow_Bytes_Sent=396 Event_Type=0
  Flow_DstIp=162.255.119.254 Flow_SrcIp=1.2.3.32 Count=1
  Url_Category_Name=Uncategorized Flow_Bytes=396
  Web_Reputation_Threat_Type=Related to Phishing Avc_Tag_Name=
  Ev_SrcLabel=CX-CX Event_Type_Name=HTTP Deny User_Realm=1.2.3.32
  Policy_Name=Implicit Allow Flow_Transaction_Id=0
  Url=http://image2.seethenewscan-updates.us/
 http://image2.seethenewscan-updates.us/ Identity_Source_Name=None
  Auth_Policy_Name=Default Flow_SrcIfc=inside
 Flow_ConnId=29106287
  Flow_DstHostName=image2.seethenewscan-updates.us
 http://image2.seethenewscan-updates.us
  Flow_Transaction_Count=1 Ev_Id=2281992
 Web_Reputation_Score=-8.4
  Event_Type_Action=Deny 

Re: [ossec-list] Re: Unusual active response behavior

2015-03-04 Thread Christian Beer
Hi,

are you monitoring the AR logfile with ossec? Some time ago I saw the
same thing where the unblock triggered a block again. I solved it by not
monitoring the AR logfile. You can also try to deactivate on of the 60x
rules.

Regards
Christian

Am 04.03.2015 um 22:09 schrieb Bill Price:
 Yes, they are being logged and email notifications are being sent.  Yes,
 the rule ids are the same: 601/603 block, 602/604 unblock.  No, there is
 no sign of activity on the manager that would explain this behaviour/
 
 On Wednesday, March 4, 2015 at 2:32:51 PM UTC-5, Bill Price wrote:
 
 My project is going through some penetration testing and I am
 occasionally observing  some unusual behaviour with respect to
 active-response.  Active response is doing a great job of detecting
 attacks and blocking the
 offending IP.  However, it has begun to display a unblock/block loop
 behaviour.  After the grace period, it will unblock the IP address. 
 However, for no apparent reason, 2 seconds later it will block the
 address again.  This behaviour
 will continue for hours until the agent is restarted.  We have
 verified that the attack is no longer proceeding.
 
 Any suggestions on what could be causing this behaviour?
 
 Bill Price
 
 -- 
 
 ---
 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
 mailto: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] Some newbie questions

2015-02-24 Thread Christian Beer
Am 24.02.2015 um 10:18 schrieb Matthias Fraidl:
 4) We do want to know if there appear failed logins (ssh f.e.) on our
 systems, but we only want to get noticed, we do not need an
 active-response (already disbaled). May it be possible to only fire the
 rule if there happen more then 3 or 5 failed tries (like fail2ban does)?
 Further there are some systems (vpn servers f.e.) we want to know failed
 or successfull logins immediatley, how can i realize such a rule for
 some specific hosts?
 

This one can be done using local rules to overwrite the existing rules.
First you have to identify which rule you want to exclude from AR but
want notices send. Then copy this rule to your local_rules.xml add the
overwrite=yes and alert_by_email option and reduce the level to at
least AR_level-1. This way an AR will not fire but you will get a notice
even if the mail level is set higher.

For most failed login rules there is another rule that covers the case
of subsequent failed logins from the same IP or same username within a
given timeframe. These can be modified using local_rules.xml too, if you
need to.

Regards
Christian

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ossec-list] Ossec's active response doesn't work

2015-02-20 Thread Christian Beer
Hi,

I fiddled a little bit with rules and decoders and I think I have it
working so that ModSecurity Messages get decoded properly.

I added some rules for grouping and one rule that triggers an AR when
Access denied with code 403 is in the log message. Does that help in
your case?

Do you need to fire an AR also in the Warning cases?

I'll polish the test cases now and create a Pull request. So this may be
included in the upcoming 2.9 release.

Regards
Christian


Am 17.02.2015 um 08:50 schrieb Ricardo Galossi:
 Hi Christian,
 I'm not using ossec to read modsecurity's log anymore. I've configured
 the apache's log (access.log and error.log) on ossec, however, no one
 rule matching with then. I've tried to use the versions 2.8 and 2.8.1,
 but any of them worked. If you want to see the log files, they ate
 attach. For while I'm using ossec 2.7, because this version matching
 with rule ID 31151. I'm studying ossec's decoder to make my own decoder
 for when there is a determinate sentence (ModSecurity: Access denied
 with code 403) on the apache's error.log, ossec block the request source ip.
 
 Em segunda-feira, 16 de fevereiro de 2015 09:39:25 UTC-2, ChristianB
 escreveu:
 
 I took a look at the file you send. As far as I am aware, ossec does
 not
 understand the modsec_audit log format. Mainly because it is a
 multiline
 log. This seemed to work for you in 2.7 because some of the lines also
 match the apache decoder and rule 31101. Thus triggering an AR. But
 this
 was sheer coincidence and not intended behavior.
 
 You should configure modsecurity to also print log messages to the
 apache error log and monitor this with ossec. There is a good chance
 that the apache decoder can also read modescurity related lines in
 there.
 
 Ossec basically needs a single line that has the information to
 identify
 a threat and block the attacker. With the modsec_audit log this is not
 possible.
 
 Regards
 Christian
 
 
 Am 16.02.2015 um 06:04 schrieb Ricardo Galossi:
  Hi Christian,
  Thanks for answer me, I've attached the modsecurity's log. I've
 tried to
  use ossec 2.8, but it does not work, it only alert the rule ID 1002
  (syslog_rules). For while I'm using ossec 2.7, because this version
  matching with rule ID 31151, when someone try attacking the site,
 modsec
  block his request and ossec block his IP matching the rule ID 31151.
 
  Em quinta-feira, 12 de fevereiro de 2015 06:54:57 UTC-2, ChristianB
  escreveu:
 
  Apache 2.4 style log messages are only supported in the master
  branch on
  github.com/ossec/ossec-hids
 http://github.com/ossec/ossec-hids
 http://github.com/ossec/ossec-hids
 http://github.com/ossec/ossec-hids or
  the upcoming 2.9 release.
 
  It would be nice if you could provide some log messages of
 ModSecurity
  so we can try this out in the dev version.
 
  Regards
  Christian
 
  Am 12.02.2015 um 00:03 schrieb Ricardo Galossi:
   Hi Dan,
   I'm so sorry for my delay, I was really busy yesterday. So,
 I've
   attached the output ossec-logtest in both versions of ossec
 2.7 and
   2.8.1. The version 2.8.1 don't match with no one high level
 rules.
  I'm a
   beginner ossec user, but I've taken a look on decoder.xml
 file and
  got a
   doubt on apache decoder. The log example of this decoder is
 [error]
   [client 64.94.163.159] Client sent malformed Host header,
  however, this
   style of log is from apache 2.2, on the other hand, the new
  version of
   apache, 2.4, has a different log style, example [:error]
 [pid 6629]
   [client 172.16.10.57] ModSecurity: Warning. Operator EQ
 matched 0 at
   REQUEST_HEADERS. I don't understand too much about decoder,
 because
   that, I don't know if it could influence on the matching of
 the rule.
  
   Thank you so much for help me.
  
   Em terça-feira, 10 de fevereiro de 2015 10:24:14 UTC-2, dan
 (ddpbsd)
   escreveu:
  
   On Mon, Feb 9, 2015 at 3:42 PM, Ricardo Galossi
   chacal...@gmail.com wrote:
Hi Dan,
I installed ossec as local. Yeah, the AR
 configuration is
   default. The
daemon ossec-execd is running normally and the
 firewall is
  enable.
   I made
testes with both versions of ossec 2.7 and 2.8.1
 within the
  same VPS.
However, only the version 2.7 block the attacker based on
  the rule
   ID 31151.
   
If you want I can send you the logs of ossec 2.8.1.
   
Thank you for 

Re: [ossec-list] Ossec's active response doesn't work

2015-02-16 Thread Christian Beer
I took a look at the file you send. As far as I am aware, ossec does not
understand the modsec_audit log format. Mainly because it is a multiline
log. This seemed to work for you in 2.7 because some of the lines also
match the apache decoder and rule 31101. Thus triggering an AR. But this
was sheer coincidence and not intended behavior.

You should configure modsecurity to also print log messages to the
apache error log and monitor this with ossec. There is a good chance
that the apache decoder can also read modescurity related lines in there.

Ossec basically needs a single line that has the information to identify
a threat and block the attacker. With the modsec_audit log this is not
possible.

Regards
Christian


Am 16.02.2015 um 06:04 schrieb Ricardo Galossi:
 Hi Christian,
 Thanks for answer me, I've attached the modsecurity's log. I've tried to
 use ossec 2.8, but it does not work, it only alert the rule ID 1002
 (syslog_rules). For while I'm using ossec 2.7, because this version
 matching with rule ID 31151, when someone try attacking the site, modsec
 block his request and ossec block his IP matching the rule ID 31151.
 
 Em quinta-feira, 12 de fevereiro de 2015 06:54:57 UTC-2, ChristianB
 escreveu:
 
 Apache 2.4 style log messages are only supported in the master
 branch on
 github.com/ossec/ossec-hids http://github.com/ossec/ossec-hids or
 the upcoming 2.9 release.
 
 It would be nice if you could provide some log messages of ModSecurity
 so we can try this out in the dev version.
 
 Regards
 Christian
 
 Am 12.02.2015 um 00:03 schrieb Ricardo Galossi:
  Hi Dan,
  I'm so sorry for my delay, I was really busy yesterday. So, I've
  attached the output ossec-logtest in both versions of ossec 2.7 and
  2.8.1. The version 2.8.1 don't match with no one high level rules.
 I'm a
  beginner ossec user, but I've taken a look on decoder.xml file and
 got a
  doubt on apache decoder. The log example of this decoder is [error]
  [client 64.94.163.159] Client sent malformed Host header,
 however, this
  style of log is from apache 2.2, on the other hand, the new
 version of
  apache, 2.4, has a different log style, example [:error] [pid 6629]
  [client 172.16.10.57] ModSecurity: Warning. Operator EQ matched 0 at
  REQUEST_HEADERS. I don't understand too much about decoder, because
  that, I don't know if it could influence on the matching of the rule.
 
  Thank you so much for help me.
 
  Em terça-feira, 10 de fevereiro de 2015 10:24:14 UTC-2, dan (ddpbsd)
  escreveu:
 
  On Mon, Feb 9, 2015 at 3:42 PM, Ricardo Galossi
  chacal...@gmail.com wrote:
   Hi Dan,
   I installed ossec as local. Yeah, the AR configuration is
  default. The
   daemon ossec-execd is running normally and the firewall is
 enable.
  I made
   testes with both versions of ossec 2.7 and 2.8.1 within the
 same VPS.
   However, only the version 2.7 block the attacker based on
 the rule
  ID 31151.
  
   If you want I can send you the logs of ossec 2.8.1.
  
   Thank you for your attention.
  
 
  Run ossec-logtest, and paste the log message I used in it
 multiple
  times. Let's see if 31151 or whatever fires (and see if the
 output
  differs from what I saw with post 2.8.1).
  I'm hoping to have a chance to try active responses tonight.
 
 
   Em segunda-feira, 9 de fevereiro de 2015 18:23:09 UTC-2, dan
 (ddpbsd)
   escreveu:
  
   On Mon, Feb 9, 2015 at 2:53 PM, Ricardo Galossi
  chacal...@gmail.com
   wrote:
Hi Dan,
The logs are in attach.
   
  
   Ok, it looks like active response is being triggered by
 rule 31151:
   Mon Feb  9 15:10:03 BRST 2015
   /var/ossec/active-response/bin/host-deny.sh add - 172.16.10.87
   1423501803.36643 31151
  
   Using ossec-logtest, and pasting the log message in a few
 times,
  does
   trigger 31151:
   172.16.10.87 - - [09/Feb/2015:15:10:03 -0200] GET
   /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
   (Nikto/2.1.6) (Evasions:None) (Test:map_codes)
  
  
   **Phase 1: Completed pre-decoding.
  full event: '172.16.10.87 - - [09/Feb/2015:15:10:03
 -0200]
  GET
   /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
   (Nikto/2.1.6) (Evasions:None) (Test:map_codes)'
  hostname: 'arrakis'
  program_name: '(null)'
  log: '172.16.10.87 - - [09/Feb/2015:15:10:03 -0200]
 GET
   /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
   (Nikto/2.1.6) (Evasions:None) 

Re: [ossec-list] Ossec's active response doesn't work

2015-02-12 Thread Christian Beer
Apache 2.4 style log messages are only supported in the master branch on
github.com/ossec/ossec-hids or the upcoming 2.9 release.

It would be nice if you could provide some log messages of ModSecurity
so we can try this out in the dev version.

Regards
Christian

Am 12.02.2015 um 00:03 schrieb Ricardo Galossi:
 Hi Dan,
 I'm so sorry for my delay, I was really busy yesterday. So, I've
 attached the output ossec-logtest in both versions of ossec 2.7 and
 2.8.1. The version 2.8.1 don't match with no one high level rules. I'm a
 beginner ossec user, but I've taken a look on decoder.xml file and got a
 doubt on apache decoder. The log example of this decoder is [error]
 [client 64.94.163.159] Client sent malformed Host header, however, this
 style of log is from apache 2.2, on the other hand, the new version of
 apache, 2.4, has a different log style, example [:error] [pid 6629]
 [client 172.16.10.57] ModSecurity: Warning. Operator EQ matched 0 at
 REQUEST_HEADERS. I don't understand too much about decoder, because
 that, I don't know if it could influence on the matching of the rule.
 
 Thank you so much for help me.
 
 Em terça-feira, 10 de fevereiro de 2015 10:24:14 UTC-2, dan (ddpbsd)
 escreveu:
 
 On Mon, Feb 9, 2015 at 3:42 PM, Ricardo Galossi
 chacal...@gmail.com wrote:
  Hi Dan,
  I installed ossec as local. Yeah, the AR configuration is
 default. The
  daemon ossec-execd is running normally and the firewall is enable.
 I made
  testes with both versions of ossec 2.7 and 2.8.1 within the same VPS.
  However, only the version 2.7 block the attacker based on the rule
 ID 31151.
 
  If you want I can send you the logs of ossec 2.8.1.
 
  Thank you for your attention.
 
 
 Run ossec-logtest, and paste the log message I used in it multiple
 times. Let's see if 31151 or whatever fires (and see if the output
 differs from what I saw with post 2.8.1).
 I'm hoping to have a chance to try active responses tonight.
 
 
  Em segunda-feira, 9 de fevereiro de 2015 18:23:09 UTC-2, dan (ddpbsd)
  escreveu:
 
  On Mon, Feb 9, 2015 at 2:53 PM, Ricardo Galossi
 chacal...@gmail.com
  wrote:
   Hi Dan,
   The logs are in attach.
  
 
  Ok, it looks like active response is being triggered by rule 31151:
  Mon Feb  9 15:10:03 BRST 2015
  /var/ossec/active-response/bin/host-deny.sh add - 172.16.10.87
  1423501803.36643 31151
 
  Using ossec-logtest, and pasting the log message in a few times,
 does
  trigger 31151:
  172.16.10.87 - - [09/Feb/2015:15:10:03 -0200] GET
  /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
  (Nikto/2.1.6) (Evasions:None) (Test:map_codes)
 
 
  **Phase 1: Completed pre-decoding.
 full event: '172.16.10.87 - - [09/Feb/2015:15:10:03 -0200]
 GET
  /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
  (Nikto/2.1.6) (Evasions:None) (Test:map_codes)'
 hostname: 'arrakis'
 program_name: '(null)'
 log: '172.16.10.87 - - [09/Feb/2015:15:10:03 -0200] GET
  /wordpress/KwJ55hQv.asmx HTTP/1.1 403 1510 - Mozilla/5.00
  (Nikto/2.1.6) (Evasions:None) (Test:map_codes)'
 
  **Phase 2: Completed decoding.
 decoder: 'web-accesslog'
 srcip: '172.16.10.87'
 url: '/wordpress/KwJ55hQv.asmx'
 id: '403'
 
  **Phase 3: Completed filtering (rules).
 Rule id: '31151'
 Level: '10'
 Description: 'Multiple web server 400 error codes from
 same source
  ip.'
  **Alert to be generated.
 
  Since you didn't provide your AR configuration I'll have to assume
  it's the default. Based on that, we get back to earlier questions:
  Is ossec-execd running on the agent?
  Is the firewall enabled on the system?
 
   Em segunda-feira, 9 de fevereiro de 2015 17:20:05 UTC-2, dan
 (ddpbsd)
   escreveu:
  
   On Mon, Feb 9, 2015 at 2:14 PM, Ricardo Galossi
 chacal...@gmail.com
   wrote:
Hi Dan,
I see. As soon as I get home I'll send the log files. Do you
 want
only
the
alert.log or something else?
   
  
   I'd love to see the apache log messages that work in OSSEC 2.7
 but not
   in
   2.8.
  
Em segunda-feira, 9 de fevereiro de 2015 17:00:38 UTC-2, dan
 (ddpbsd)
escreveu:
   
On Mon, Feb 9, 2015 at 1:39 PM, Ricardo Galossi
chacal...@gmail.com
wrote:
 Hi guys,
 I made some tests here with ossec 2.7. When I try to scan
 the
 target,
 the
 modsec delivery a 403 error page, so, ossec read the apache
 access.log
 file
 and match the rule with ID 31151 from web_rules.xml and
 block the
 attacker's
 IP on iptables. Follow the rule below:

Re: [ossec-list] Apache error log problem

2014-12-28 Thread Christian Beer
This is fixed in current OSSEC master on github. If you don't want to
upgrade to an experimental version you can manually copy the portions of
the decoder.xml and apache.xml rules file.

There are log samples and tests for apache 2.4 log style already on
github. I also have two OSSEC instances in production (CentOS 7) that
work well with those new rules.

Regards
Christian

Am 28.12.2014 um 18:29 schrieb art.mor...@gmail.com:
 I am upgrading a server from CentOS 6.6 with Apache 2.2.16 to CentOS 7
 with Apache 2.4.6. One thing I've noticed is that there seems to be a
 change in the Apache log format. So previously an error would be e.g.
 
 [Sun Dec 28 09:08:46 2014] [error] etc etc
 
 That's now eg
 
 [Sun Dec 28 16:26:22.703615 2014] [cgi:error] [pid 13742] or
 [Sun Dec 28 16:21:11.368100 2014] [fcgid:warn] [pid 13396] etc
 
 I am sure I did a clean install of OSSEC onto the new server, and yet
 the the Apache rules seem to be written for the older version:
 
 / if_sid30100/if_sid/
 
 /rule id=30101 level=0
 if_sid30100/if_sid
 match^[error] /match/
 
 That will miss [cgi-error] presumably! I know I *could* fix this with
 a custom rule, but then I'm wondering whether I am doing something wrong
 with my Apache logging set up, and who knows what else won't be working!
 
 Any suggestions much appreciated!
 
 
 -- 
 
 ---
 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
 mailto: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] Ask syscheck to temporarily stop alerting on a directory

2014-11-03 Thread Christian Beer
Am 03.11.2014 um 16:51 schrieb David Alston:
 I've come up with some ideas on how to approach the problem, but I'm not
 sure which ones will be possible with OSSEC..
 
 1) pass one-time command-line argument to client-syscheckd so that it
 updates the MD5 sums without alerting
 2) write a rule that does not alert if a particular process/arguments is
 running (eg. rsync)
 3) write a rule that does not alert when some similar condition is met
 that we can change on the fly
 4) delete the ossec-server:/var/ossec/queue/syscheck/AGENTNAME   
 file so that OSSEC doesn't alert
 5) a better solution not on this list
 

Some time ago we had a similar discussion about situations when a system
update is underway. The solution then was to clear the syscheck-db
before and start with a fresh baseline (your 4).

The alternative that was discussed would fit into your 1 and involves
calculating the new md5/sha1 and populating the syscheck-db with those
values circumventing an alert. If I remember correctly this was done
using a CDB where the approved md5/sha1 values of the modified files
where stored and syscheck could compare this to the identified change
before creating an alert. Personally I find this the best and general
solution which would handle both use cases and maybe others as well.

Maybe we should draft a design doc?

Part 1 is a DB of approved md5/sha1 values and filenames that get's
populated by third-party tools like apt-get, yum or deployment scripts.

Part 2 is an addition to the syscheck daemon to check the DB before
creating an alert.

Problematic might be the realtime mode and the load that it produces.

Regards
Christian

-- 

--- 
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] CIS checks via OSSEC

2014-07-23 Thread Christian Beer
Hi I downloaded the Benchmark paper and tool a quick look.

The question is what is to do? As I understand the document one has to
copy the script snippets from the audit sections into the CIS text files
and annotate with some information, right?

This seems to me like a copypaste job and a pull request on github.

Regards
Christian

Am 23.07.2014 10:31, schrieb Michiel van Es:
 Hello,
 
 We see that OSSEC does some CIS checks for Red Hat 5 and older.
 Is it possible to update the CIS checks in OSSEC to do CIS checks for
 RHEL 6 etc?
 (http://benchmarks.cisecurity.org/downloads/show-single/?file=rhel6.120)
 This helps with PCI-DSS v3 compliance (2.2).
 
 Or is it easy to add these checks yourself or are they on the planning
 to be included in a new release?
 
 Michiel
 
 -- 
 
 ---
 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
 mailto: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] block multiple http get requests from same IP

2014-06-05 Thread Christian Beer
You should also note that your rule 100507 will not be triggered by
ossec-logtest because of the timeframe and frequency settings.

I tried a little bit with a normal apache access log:
115.239.248.56 - - [05/Jun/2014:21:10:29 +0200] GET
/manager/html/captcha.php HTTP/1.1 200 295 - Mozilla/3.0
(compatible; Indy Library)

**Phase 1: Completed pre-decoding.
   full event: '115.239.248.56 - - [05/Jun/2014:21:10:29 +0200] GET
/manager/html/captcha.php HTTP/1.1 200 295 - Mozilla/3.0
(compatible; Indy Library)'
   hostname: 'exp'
   program_name: '(null)'
   log: '115.239.248.56 - - [05/Jun/2014:21:10:29 +0200] GET
/manager/html/captcha.php HTTP/1.1 200 295 - Mozilla/3.0
(compatible; Indy Library)'

**Phase 2: Completed decoding.
   decoder: 'web-accesslog'
   srcip: '115.239.248.56'
   url: '/manager/html/captcha.php'
   id: '200'

**Phase 3: Completed filtering (rules).
   Rule id: '31108'
   Level: '0'
   Description: 'Ignored URLs (simple queries).'

Then I added this rule:
I used this rule:
rule id=100506 level=1
 if_sid31108/if_sid
 urlcaptcha.php/url
 descriptionCaptcha attempt./description
   /rule

Then I got:
**Phase 1: Completed pre-decoding.
   full event: '115.239.248.56 - - [05/Jun/2014:21:10:29 +0200] GET
/manager/html/captcha.php HTTP/1.1 200 295 - Mozilla/3.0
(compatible; Indy Library)'
   hostname: 'exp'
   program_name: '(null)'
   log: '115.239.248.56 - - [05/Jun/2014:21:10:29 +0200] GET
/manager/html/captcha.php HTTP/1.1 200 295 - Mozilla/3.0
(compatible; Indy Library)'

**Phase 2: Completed decoding.
   decoder: 'web-accesslog'
   srcip: '115.239.248.56'
   url: '/manager/html/captcha.php'
   id: '200'

**Phase 3: Completed filtering (rules).
   Rule id: '100506'
   Level: '1'
   Description: 'Captcha attempt.'
**Alert to be generated.

Now you only have to tweak 100507.

As for your modified access_log I can recommend to include the
domainname before the path. I use this:
LogFormat %h %l %u %t \%m %v%U%q %H\ %s %b \%{Referer}i\
\%{User-agent}i\

and there are no problems with ossec or logwatch

Regards
Christian


Am 05.06.2014 21:08, schrieb Lou:
 I did some google'n and came up with this rule.  
 
 rule id=100506 level=1
 if_sid31101/if_sid
 urlcaptchaDB.php/url
 matchGET/match
 descriptionCaptcha attempt./description
   /rule
 
   rule id=100507 level=10 frequency=4 timeframe=60
 if_matched_sid100506/if_matched_sid
 same_source_ip /
 descriptionCaptcha attack./description
 groupattack,/group
/rule
 
 And then I tested:  cat /tmp/access_log | /var/ossec/bin/ossec-logtest -a
 
 The tool triggered one alert (the word 'error' in a filename - which is
 ok).  So my rule does not seem to be working.  Any suggestions?  I also
 have one other question.  I modified my apache log format to include the
 domain at the start of the log entry... does this affect how OSSEC rules
 parse the logs?
 
 My full log entry actually looks like this:
 
 www.mydomain.com 70.55.163.53 - - [05/Jun/2014:08:46:36 -0400] GET
 /path/to/file/captcha.php HTTP/1.1 200 https://mydomain.com;
 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0;
 SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media
 Center PC 6.0; .NET4.0C; .NET4.0E)
 
 On Thursday, June 5, 2014 12:13:18 PM UTC-4, Lou wrote:
 
 I receive other alerts so at least I know it is partially configured
 correctly. 
 
 The apache log file entries look something like this:
 
 70.55.163.53 - - [05/Jun/2014:08:46:36 -0400] GET
 /path/to/file/captcha.php HTTP/1.1 200
 
 thanks 
 
 On Thursday, June 5, 2014 11:55:09 AM UTC-4, dan (ddpbsd) wrote:
 
 On Thu, Jun 5, 2014 at 11:44 AM, Lou lui.c...@gmail.com wrote:
  I'm new to OSSEC and have recently installed it on some web
 servers that are
  being 'abused'.  Every 15-20 seconds the user is accessing the
 captcha file
  and i believe he is using an OCR tool to bypass it.  I was
 under the impression
  that OSSEC would detect this automatically with it's included
 rules and send
  me a notification (similar to DOS attack).  This does not seem
 to be the
  case.  Do i need to create a specific rule for this?  Or do i
 have something
  mis-configured?  I would appreciate any help.
 
 
 There's probably no rule for it. You can use the ossec-logtest
 program
 to help create rules for these events. Giving us log samples can
 also
 help.
 There is definitely a possibility for misconfiguration though.
 Without
 knowing how your systems are configured, it's hard to tell.
 
  Thanks!
 
  --
 
  ---
  You received this message because you are subscribed to the
 Google Groups
  ossec-list 

Re: [ossec-list] heloname while alerting by e-mail

2014-05-27 Thread Christian Beer
This is hardcoded in src/os_maild/sendmail.c and
src/os_maild/sendcustommail.c

You have to change it there and run install.sh again. At least this is
what I do but I don't use the repo.

I think it should also be possible to whitelist the default HELO but
didn't investigate.

Regards
Christian


Am 27.05.2014 12:07, schrieb Vasiliy Shpanskiy:
 Hi, guys.
 Sorry for my english ;)
 I have some trouble with sending e-mail from OSSEC server. While
 ossec-maild trying to send mail to my smtp-server it refused with follow
 response:
 450 4.7.1 notify.ossec.net: Helo command rejected: Host not found;
 from=oss...@example.com
 Is this a way to config ossec-maild to use explicit heloname? Or it is
 hardcoded and i must edit sources?
 I use:
 OS: Debian 7 (wheezy)
 OSSEC: installed from AlienVault repo: deb
 http://ossec.alienvault.com/repos/apt/debian wheezy main
 
 -- 
 
 ---
 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
 mailto: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] ossec-maild tags

2014-03-14 Thread Christian Beer
Or you could change this file:
https://github.com/ossec/ossec-hids/blob/master/src/os_maild/sendmail.c
on each server and add something to SUBJECT so you can filter that out
on gmail.

I always have to change this file as my local mailserver is very strict
about the HELOMSG and I have to change it to the servername.

Regards
Christian


Am 14.03.2014 13:09, schrieb dan (ddp):
 On Thu, Mar 13, 2014 at 3:01 AM, Gaurav Rajput gx1...@gmail.com wrote:
 Hi,

 I have 3 different infrastructures (Development, Production and Testing),
 running the same configuration (with same ip-address and subnet) and nodes.
 I have 3 ossec-servers running. Each ossec-server is sending the mails to a
 central gmail account.

 All I want is, to categorize the mails from each infrastructure. In other
 words I want to tag the emails with Dev, Prod or Test. Is there any way to
 do this, as I searched a lot in the configuration file ???

 
 I think your best bet is to have them sent from different email addresses.
 
 Thanks.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 

-- 

--- 
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] decoder can't cope with umlaute

2014-03-03 Thread Christian Beer
I also found the OS_CleanMsg function and was working on a fix when you
wrote. I added a check and repair right before the date detection.
I'll open a pull request. So far it only works for the German case of
March but could be adapted to other languages easily.

Regards
Christian

Am 03.03.2014 17:20, schrieb Jeremy Rossi:
 OSSEC does not use a regex to parse out the date on logs.  Due to this
 it depends on the Month being 3 chars:
 OS_CleanMSG in analysis/cleanevent.c
 I adding a check for this type of log file should not be hard, and
 patches are welcome.  I don't have a huge amount of time to look at this
 right now, but if you need something done create a github.com issue.
 Maybe not today but sometime. 
 THank you,
 -Jeremy
 
 Hi,

 it's March or März as it is called in Germany. The only month with an
 umlaut in German. My proftpd installation on my German localized server
 is now producing this log lines:
 Mär 02 17:30:52 server proftpd[11769] servername
 (58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
 password

 Feeding it into logtest gives:

 **Phase 1: Completed pre-decoding.
   full event: 'Mär 02 17:30:52 server proftpd[11769] servername
 (58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
 password'
   hostname: 'server'
   program_name: '(null)'
   log: 'Mär 02 17:30:52 server proftpd[11769] servername
 (58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
 password'

 **Phase 2: Completed decoding.
   No decoder matched.

 **Phase 3: Completed filtering (rules).
   Rule id: '2501'
   Level: '5'
   Description: 'User authentication failure.'
 **Alert to be generated.

 When I change the umlaut ä to a normal a I get:
 **Phase 1: Completed pre-decoding.
   full event: 'Mar 02 17:30:52 server proftpd[11769] servername
 (58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
 password'
   hostname: 'server'
   program_name: 'proftpd'
   log: 'servername (58.215.179.53[58.215.179.53]): USER root (Login
 failed): Incorrect password'

 **Phase 2: Completed decoding.
   decoder: 'proftpd'
   srcip: '58.215.179.53'

 **Phase 3: Completed filtering (rules).
   Rule id: '100110'
   Level: '6'
   Description: 'Login failed accessing the FTP server using root
 user'
 **Alert to be generated.

 Of course I want the srcip to be decoded because my active-response
 needs to block this. For now it seems that I can block the attackers by
 hand but I would like to have a working solution for the rest of March.

 I will look into the code a little bit more on Tuesday but if anyone
 else has a quicker solution would be great.

 Regards
 Christian

 -- 

 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[ossec-list] decoder can't cope with umlaute

2014-03-02 Thread Christian Beer
Hi,

it's March or März as it is called in Germany. The only month with an
umlaut in German. My proftpd installation on my German localized server
is now producing this log lines:
 Mär 02 17:30:52 server proftpd[11769] servername 
 (58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect password

Feeding it into logtest gives:

**Phase 1: Completed pre-decoding.
   full event: 'Mär 02 17:30:52 server proftpd[11769] servername
(58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
password'
   hostname: 'server'
   program_name: '(null)'
   log: 'Mär 02 17:30:52 server proftpd[11769] servername
(58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
password'

**Phase 2: Completed decoding.
   No decoder matched.

**Phase 3: Completed filtering (rules).
   Rule id: '2501'
   Level: '5'
   Description: 'User authentication failure.'
**Alert to be generated.

When I change the umlaut ä to a normal a I get:
**Phase 1: Completed pre-decoding.
   full event: 'Mar 02 17:30:52 server proftpd[11769] servername
(58.215.179.53[58.215.179.53]): USER root (Login failed): Incorrect
password'
   hostname: 'server'
   program_name: 'proftpd'
   log: 'servername (58.215.179.53[58.215.179.53]): USER root (Login
failed): Incorrect password'

**Phase 2: Completed decoding.
   decoder: 'proftpd'
   srcip: '58.215.179.53'

**Phase 3: Completed filtering (rules).
   Rule id: '100110'
   Level: '6'
   Description: 'Login failed accessing the FTP server using root user'
**Alert to be generated.

Of course I want the srcip to be decoded because my active-response
needs to block this. For now it seems that I can block the attackers by
hand but I would like to have a working solution for the rest of March.

I will look into the code a little bit more on Tuesday but if anyone
else has a quicker solution would be great.

Regards
Christian

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] Update file integrity signatures database...

2014-01-27 Thread Christian Beer
Dan: I think I know what he wants. He wants to change the signature
before the change is detected by ossec so he does not get an alert. This
is similar to the discussion last year about updating syscheck when
doing an apt-get upgrade.

Bruno: search within the archive of this group for What's a good way to
update syscheck after an apt-get upgrade? There is some mail exchange
from 29.05.2013

There is a patch somewhere in there that kind of queries a trusted
source for the md5/sha1 hash and doesn't generate an alert if the new
hash equals the trusted hash. The patch is kind of bulky and I don't use
it because I only have one server to monitor at the moment and can
manage the update myself.

For the future it would be nice if syscheck had the ability to check a
trusted source if the file change was to be expected. This DB has to be
filled by the admin during update. Just my 2cents.

Regards
Christian


Am 27.01.2014 19:50, schrieb dan (ddp):
 On Mon, Jan 27, 2014 at 1:47 PM, Bruno Andrade b...@eurotux.com wrote:
 On Mon, 27 Jan 2014 12:08:44 -0500
 dan (ddp) ddp...@gmail.com wrote:

 On Mon, Jan 27, 2014 at 12:06 PM, Bruno Andrade b...@eurotux.com
 wrote:
 On Mon, 27 Jan 2014 11:45:41 -0500
 dan (ddp) ddp...@gmail.com wrote:

 On Mon, Jan 27, 2014 at 11:25 AM, Bruno Andrade b...@eurotux.com
 wrote:
 On Mon, 27 Jan 2014 07:51:08 -0500
 dan (ddp) ddp...@gmail.com wrote:

 On Mon, Jan 27, 2014 at 4:33 AM, Bruno Andrade b...@eurotux.com
 wrote:

 Hey, that's not what I thinking.

 Lets restart... I install OSSEC, he generate file signatures,
 I change a file, OSSEC trigger an alarm for that file because
 the signature change. What happens now?


 That's really up to you. OSSEC doesn't really care why a file
 changed, it just reports that it has changed. We don't advocate
 handling those alerts in any particular fashion, too many groups
 handle it too differently for us to make those kinds of
 recommendations.

 When a file changes, the new hash will be used for the next
 check. If you have not turned off the auto ignore, 3 changes
 will make a file not be reported anymore.

 Thanks.

 That was kind of the answer I was looking for.
 Say that, after the first change to the file I want to make the
 file not to be reported anymore. How can I do it? But, I want to
 do it because I now that change was legitimate, if not, it
 continues to report.


 There's no way to really pause reporting on the file.

 I'm not talking about pause reporting, but the capacity to update
 the signature if you know that change is legitimate.


 I don't think updating the signature is a problem, it'll automagically
 update on the next syscheck scan(/realtime). I thought you just didn't
 want to be updated when it does change that next time.


 Hey, I found this http://centralwire.sourceforge.net/, that's
 basically what I was asking if it is possible to do with OSSEC. With
 this tool is possible to review the file changes and accept them.

 
 I guess I don't understand what you expect to happen when you accept
 a change. OSSEC notices a change, it alerts you. It will not revert
 the change and it will not continue to alert you on that same change.
 So I'm kind of missing the point. What are you hoping to accomplish
 exactly?
 

 --
 Bruno Andrade b...@eurotux.com
 Programador (ID)
 Eurotux Informática, S.A. | www.eurotux.com
 (t) +351 253 680 300 (m) +351 936 293 858

 --

 ---
 You received this message because you are subscribed to the Google Groups 
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] trigger rule when invalid su attempt

2013-12-15 Thread Christian Beer
The email_alert_level is the minimal level for which emails are send.
Meaning: a rule with level 7 or above will trigger an email!
Levels are severities in ossec: the higher level is the more severe log
message (see:
http://www.ossec.net/doc/manual/rules-decoders/rule-levels.html).

To suppress a certain rule from sending emails you should decrease the
level to below the email_alert_level, which is 6 in your case.

The amount of log entries is defined with the rule not the level. In
case of rule 5302 there is only one entry needed.
See: http://www.ossec.net/doc/syntax/head_rules.html for the syntax of a
rule definition. The frequency option is used to tell ossec to invoke
the rule after how many log entries (plus 2).

Regards
Christian

Am 15.12.2013 09:43, schrieb evangeline eleanor:
 Hi,
 
 Thank you for the response. I have found the entry you were referring to. I 
 have one additional level. The email_alert_level is set to level 7, so 
 email alerts will be sent for every rule matching the level 7, but the su 
 rule is level 9:
 
   rule id=5302 level=9
 if_sid5301/if_sid
 user^root/user
 descriptionUser missed the password to change UID to 
 root./description
 groupauthentication_failed,/group
   /rule
 
 Therefore by setting this rule to level 7 would definitely change the 
 amount of emails sent. 
 
 But exactly how many su password failure alerts need to be sent to ossec 
 for the rule to be triggered and email sent? Basically I would like to know 
 where the rules for the levels are defined: how many log entries are 
 required for certain level to be invoked.
 
 Thank you
 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] Re: Ssh freeze whenever goes into mysql.

2013-12-10 Thread Christian Beer
I also had this problem some time ago. Make sure you either whitelist
your IP (if it doesn't change) or disable ossec before using phpmyadmin.
As it is now, some actions are detected by ossec as malicious
SQLInjection attacks and thus trigger the rule 31106. The firewall-drop
is triggered by the 31106 rule and thus you ssh freezes. I found (and
didn't really investigate) no other way to whitelist the phpmyadmin
installation.

Regards
Christian

Am 10.12.2013 03:54, schrieb frwa onto:
 Dear Dan,
   This log is showing  2013/12/08 01:48:43 ossec-execd: INFO: 
 Active response command not present: 
 '/var/ossec/active-response/bin/restart-ossec.cmd'. Not using it on this 
 system.  That active response is not present right so then why does is 
 deny the host. In fact that is my local ip where I am accessing the server 
 locally not from eternal. I only do is that using phmyadmin to access my db 
 and I always get denied and my ssh is broken? Does ossec sniff it as an 
 attack is it?
 
 Regards,
 Frwa.
 
 On Sunday, December 8, 2013 3:24:39 PM UTC+8, frwa onto wrote:

 I have centos 6.5(Final) running. Lately I notice whenever I do anything 
 in mysql after few minutes my ssh gets freeze. I dont know what is 
 happening so looking to my /var/log/secure nothing is pointing there then I 
 look into my ossec logs and I notice these lines.

 In my /var/ossec/log/ossec-log I see this

 2013/12/07 20:50:27 ossec-syscheckd: INFO: Ending syscheck scan.
 2013/12/08 01:48:43 ossec-execd: INFO: Active response command not 
 present: '/var/ossec/active-response/bin/restart-ossec.cmd'. Not using it 
 on this system.
 2013/12/08 14:20:27 ossec-rootcheck: INFO: Starting rootcheck scan.
 2013/12/08 14:31:27 ossec-rootcheck: INFO: Ending rootcheck scan.

 But in my /var/ossec/log/active-responses.log I see this 

 Sun Dec  8 15:14:25 MYT 2013 /var/ossec/active-response/bin/host-deny.sh 
 delete - 10.212.134.200 1386486234.11964 31106
 Sun Dec  8 15:14:25 MYT 2013 
 /var/ossec/active-response/bin/firewall-drop.sh delete - 10.212.134.200 
 1386486234.11964 31106

 What can I do about this? 

 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] Re: Trying to log firewall drops within OSSEC (so I get notifications)

2013-11-07 Thread Christian Beer
The Rules 601 and 602 only get triggered if you monitor your
active_responses.log file in /var/ossec/logs/. Every AR event is a line
in there and at the end of the line should be the rule that invoked this
event. You can take a line and test with ossec_logtest too.

So check your ossec.conf file for:
 localfile
 log_formatsyslog/log_format
 location/var/ossec/logs/active-responses.log/location
   /localfile
Examples:
 Do 7. Nov 07:59:48 CET 2013
 /var/ossec/active-response/bin/firewall-drop.sh add - 37.187.77.137
 1383807588.12075 100200
 Do 7. Nov 08:10:19 CET 2013
 /var/ossec/active-response/bin/firewall-drop.sh delete - 37.187.77.137
 1383807588.12075 100200
In case you have a non-English OS you may have to change the AR decoder.
As you can see I have a German OS so weekdays are in German
abbreviation. This is done by my local_decoder.xml:
 decoder name=ar_log

 prematch^Mo|^Di|^Mi|^Do|^Fr|^Sa|^So|^Mon|^Tue|^Wed|^Thu|^Fri|^Sat|^Sun
 \S+\s+\d+ \d\d:\d\d:\d\d \S+ \d+ /\.+/active-response/prematch
 regex offset=after_prematch/bin/(\S+) (\S+) - (\S+)
 (\d+.\d+) (\d+)/regex
 orderaction, status, srcip, id, extra_data/order
 /decoder
This was suggested on this mailing list a long time ago and I just
copied it from there.

Regards
Christian

Am 07.11.2013 10:18, schrieb Gerard Petersen:
 @Christian and Dan,

 I just tested again with a fresh view and I'm still having problems
 when changing rules (in this case adding Christians rules). My test
 case is a Wordpress brute force login attempt. I can see rule 31509
 getting triggered ('WordPress login attempt.'), after 5 times rule
 31510 gets triggered (WordPress wp-login.php brute force attempt.').
 Then the active response kicks in and rule 31510 (configured as level
 7) emails me. So everything working as it should.

 Then, when I override 601,602 with Christian’s rules (placed in
 local_rules.xml on the server) I don’t get the expected email from the
 601 rule. Seems like not all rules in the 'tree' go via the 601 or do
 they?

 I could easily add something to the firewall-drop.sh scripts but then
 I loose the information in the email by what rule the active response
 was actually invoked. Any suggestions are highly appreciated. I can
 also provide any log info that would be useful.

 Kind regards,

 Gerard.

 On Saturday, November 2, 2013 1:27:54 PM UTC+1, Gerard Petersen wrote:

 Hi All,

 I'm trying to get notifications for AR Firewall drops but I can't
 get it to work. The easiest (but not preferred) way seemed to edit
 file firewall_rules.xml and change this:

   rule id=4101 level=5
 if_sid4100/if_sid
 actionDROP/action
 optionsno_log/options
 descriptionFirewall drop event./description
 groupfirewall_drop,/group
   /rule

 Into this:

   rule id=4101 level=8
 if_sid4100/if_sid
 actionDROP/action
 descriptionFirewall drop event./description
 groupfirewall_drop,/group
   /rule

 Then, amazingly, the active response stops working completely. The
 preferred way, as I see it, would be to add a new rule and if_sid
 from the 4101 with a level=8. 

 group name=firewall,
   rule id=100201 level=8
 if_sid4101/if_sid
 descriptionTEST - Firewall DROP./description
   /rule
 /group !-- firewall, --

 But no luck on either setup. Can anybody see what I do not?

 Thanx a lot.

 Kind regards,

 Gerard.

 -- 
  
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] Re: AnaLogi login page?

2013-10-12 Thread Christian Beer
Why would you need a login page? Where should this login page get it's
credentials from? As it is now you can use apache basic authentication
(or similar) which in fact can be tied into other authentication systems
(such as an ldap directory). It's not the job of analogi to keep the bad
boys out but rather show you where the bad boys are ;).

Regards
Christian

Am 12.10.2013 05:51, schrieb Richard McAlexander:
 Ok, Thanks Dimitri! I didn't see anything to set a login page. That
 would be a great feature though!

 On Friday, October 11, 2013 10:53:21 AM UTC-6, Richard McAlexander wrote:

 I have AnaLogi installed and one thing that seems odd is that
 there's no login page. I haven't had much time spend researching,
 but there also doesn't seem to be much in the way of
 documentation. Is there a way to enable a login page? Or am I just
 wrong in the assumption that there should be a login page? Thank
 you very much!

 -- 
  
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ossec-list] Re: AnaLogi login page?

2013-10-12 Thread Christian Beer
Am 12.10.2013 16:04, schrieb Michael Starks:
 On 10/12/2013 05:28 AM, Christian Beer wrote:
 Why would you need a login page? Where should this login page get it's
 credentials from? As it is now you can use apache basic authentication
 (or similar) which in fact can be tied into other authentication systems
 (such as an ldap directory). It's not the job of analogi to keep the bad
 boys out but rather show you where the bad boys are ;).

 You need access control because logs contain sensitive data. Using
 Apache access control is not sufficient for everyone because once
 authenticated, you have access to everything, which may not be in line
 with the roles need. For example, you could grant the DBAs access to
 only database logs/alerts, while the Windows admins could have access
 to only Windows logs/alerts. I'm not saying that this should
 necessarily be a design objective of AnaLogi, but that's the
 justification for having it.

That's right, of course. I'm more the all-in-one person and like AnaLogi
the way it is. I didn't associate a login page with a role-based
authentication concept.

Regards
Christian

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[ossec-list] ossec-dbd not shut down with 2.7.1-beta-1

2013-06-30 Thread Christian Beer
Hi All,

I installed the beta 1 of 2.7.1 on a new server and noticed that
ossec-dbd is not shut down from ossec-control stop or restart.

I compiled with mysql database support. Enabled the database
(ossec-control enable database) and restarted ossec. I than had to make
another change in the source, recompiled und updated again. At the end
of install.sh I got the error:

make[1]: Leaving directory `/root/ossec-hids-2.7.1-beta-1/src/os_auth'
Killing ossec-monitord ..
Killing ossec-logcollector ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
Killing ossec-execd ..
ossec-dbd not running ..
OSSEC HIDS v2.7.1-beta-1 Stopped
cp: reguläre Datei „/var/ossec/bin/ossec-dbd“ kann nicht angelegt
werden: Das Programm kann nicht ausgeführt oder verändert werden (busy)
Starting OSSEC HIDS v2.7.1-beta-1 (by Trend Micro Inc.)...
Started ossec-dbd...
Started ossec-maild...
2013/06/30 12:18:29 ossec-execd: INFO: Adding offenders timeout: 60 (for #1)
2013/06/30 12:18:29 ossec-execd: INFO: Adding offenders timeout: 120
(for #2)
2013/06/30 12:18:29 ossec-execd: INFO: Adding offenders timeout: 1440
(for #3)
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

I than checked and found three ossec_dbd processes running. That's why
the cp was not possible.
I stopped ossec and killed the remaining ossec-dbd processes. I then
cleaned my /var/ossec/bin/.process_list file to only contain
DB_DAEMON=ossec-dbd and started ossec again. Here is what it says:

root@server:~/ossec-hids-2.7.1-beta-1# l /var/ossec/var/run/
insgesamt 0
root@server:~/ossec-hids-2.7.1-beta-1# /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.7.1-beta-1 (by Trend Micro Inc.)...
Started ossec-dbd...
Started ossec-maild...
2013/06/30 12:37:25 ossec-execd: INFO: Adding offenders timeout: 60 (for #1)
2013/06/30 12:37:25 ossec-execd: INFO: Adding offenders timeout: 120
(for #2)
2013/06/30 12:37:25 ossec-execd: INFO: Adding offenders timeout: 1440
(for #3)
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.
root@server:~/ossec-hids-2.7.1-beta-1# l /var/ossec/var/run/
insgesamt 24
-rw-r- 1 ossec ossec 6 Jun 30 12:37 ossec-analysisd-20823.pid
-rw-r- 1 root ossec 6 Jun 30 12:37 ossec-execd-20819.pid
-rw-r- 1 root root 6 Jun 30 12:37 ossec-logcollector-20827.pid
-rw-r- 1 ossecm ossec 6 Jun 30 12:37 ossec-maild-20814.pid
-rw-r- 1 ossec ossec 6 Jun 30 12:37 ossec-monitord-20834.pid
-rw-r- 1 root root 6 Jun 30 12:37 ossec-syscheckd-20831.pid

root@server:~/ossec-hids-2.7.1-beta-1# ps aux | grep ossec
root 20810 0.0 0.3 44700 1680 ? S 12:37 0:00 /var/ossec/bin/ossec-dbd
ossecm 20814 0.0 0.1 12644 604 ? S 12:37 0:00 /var/ossec/bin/ossec-maild
root 20819 0.0 0.0 12512 504 ? S 12:37 0:00 /var/ossec/bin/ossec-execd
ossec 20823 0.1 0.4 14356 2428 ? S 12:37 0:00 /var/ossec/bin/ossec-analysisd
root 20827 0.0 0.1 4284 580 ? S 12:37 0:00 /var/ossec/bin/ossec-logcollector
root 20831 1.8 0.1 4556 724 ? S 12:37 0:02 /var/ossec/bin/ossec-syscheckd
ossec 20834 0.0 0.1 12772 592 ? S 12:37 0:00 /var/ossec/bin/ossec-monitord
root 20906 0.0 0.1 11724 916 pts/0 S+ 12:40 0:00 grep ossec

ossec.log does not contain any further insight, only some of these (that
I fix soon)
ossec-dbd(5202): ERROR: Error connecting to database
'127.0.0.1'(ossecdb): ERROR: Access denied for user 'ossec'@'localhost'
to database 'ossecdb'.

To me it seems that ossec-dbd forgets to place a pid file in var/run/. I
did a quick search in the source code but couldn't find the right spot.
I'm on Debian 7 64bit.

Regards
Christian

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] Re: ossec-logtest error in OSSEC 2.7

2013-04-03 Thread Christian Beer
deleting rules is a bad idea because they may be referenced by other
rules. You should overwrite those rules you need/do not need in your
local_rules.xml. You can either increase the level of the interesting
rules above the email alert level (that you have to raise too) or
decrease the level of the uninteresting rules. I would do the second.

Basically you copy all the uninteresting rules from the ms_auth.xml file
into your local_rules.xml and edit the rule tags by setting level=0
overwrite=yes for every rule.

Regards
Christian

Am 03.04.2013 13:20, schrieb Paul Dittrich:
 I edited msauth_rules.xml by deleting most of the rules, leaving only
 a few that our sysadmins were interested in using.

 msauth_rules.xml is now only a few hundred bytes instead of the
 original 30k+

 Any ideas?

 Paul D.

 On Apr 2, 5:32 pm, Aixia mnemon...@gmail.com wrote:
 Can you post the rule you edited?







 On Tuesday, April 2, 2013 4:04:10 PM UTC-5, Paul Dittrich wrote:

 Brand-new OSSEC user.
 Fresh install of Debian 6.0.7 with OSSEC 2.7  Everything working
 perfectly until the first time I tried to edit a ___rules.xml file.
 Then I get OSSEC analysisd: Testing rules failed. Configuration error.
 Exiting.
 I've google'd like crazy and found dozens of references to this error for
 version 2.6 but in 2.7 the ossec-control script already has the corrected
 line.
 What else do I need to look at / fix ???
 Paul D.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] How to block bad bots without mail alert

2013-03-18 Thread Christian Beer
Hi,

just adjust the level of this rule so it is equal or over your active
reponse threshold (by default level 6) and under your email_alert_level
threshold (default level 7). Bot his specified in your ossec.conf

Regards
Christian
Am 17.03.2013 11:17, schrieb Jan Kopecký:
 Hello,

 I would like immediately block bad search bots with auto-response but
 I don't want get mail alerts because of lot of accesses.

 I created this rule:

   rule id=100061 level=14
 if_sid31100/if_sid
 matchMJ12bot/match
 descriptionMajestic bot access/description
   /rule

 and it seems works but it send mail alert with every access so I get
 hundreds mails per day. Is there possibility to block with
 auto-response and avoid mail alert or is there some better way to
 block bad bots?
 -- 
  
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] Issue with Overwrite option and rule 533

2013-03-13 Thread Christian Beer
As I use this overwrite mechanism also very often and it works in 2.6
and 2.7, could you please post your faulty rule overwrite? Maybe you
missed something.

Regards
Christian

Am 13.03.2013 18:16, schrieb Stephane Rossan:
 Hi all,

 I use Ossec 2.6 on my server and unix clients.
 Recently, I tried to tune rule 533, and set the level of alert from 7
 to 6. In my setup, 6 doesn't generate email alerts.
 After few hours of this implementation, I noticed following errors in
 ossec.log:
 2013/03/11 22:41:35 ossec-syscheckd(1224): ERROR: Error sending
 message to queue.
 2013/03/11 22:41:36 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2013/03/11 22:41:38 ossec-syscheckd(1210): ERROR: Queue
 '/apps/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2013/03/11 22:41:38 ossec-syscheckd(1211): ERROR: Unable to access
 queue: '/apps/ossec/queue/ossec/queue'. Giving up..
 2013/03/11 22:41:39 ossec-logcollector(1210): ERROR: Queue
 '/apps/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2013/03/11 22:41:39 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/apps/ossec/queue/ossec/queue'. Giving up..

 I did some research and found this error message has nothing to do
 with the queue. It is related to a syntax error in local_rules.xml. I
 checked it, couldn't figure the issue, validated it with
 ossec-logtest, everything was fine. Reviewing my SCM for any change in
 the rules, I noticed issues started around the time I added rule 533
 to my local_rules.xml file. I rolled back to the previous version,
 minus rule 533. I monitored ossec.log for 24 hours, no issue. When I
 added rule 533 back, it broke again.

 Is there a way to fix this bug? I really need to collect netstat info
 but don't want to get an email alert every time there is a change.

 Thanks in advance,
 -Stephane
 -- 
  
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] Issue with Overwrite option and rule 533

2013-03-13 Thread Christian Beer
I also can't find an error here. Maybe it's some wierd line ending
problem that is only triggered by the logcollector and not logcheck.

Am 13.03.2013 18:49, schrieb Stephane Rossan:
 Here is my rule, from local_rules.xml
 rule id=533 level=6 overwrite=yes
 if_sid530/if_sid
 matchossec: output: 'netstat -tan/match
 check_diff /
 descriptionListened ports status (netstat) changed (new port
 opened or closed)./description
   /rule

 I use the overwrite option a lot, and can not figure what went wrong here.


 On Wed, Mar 13, 2013 at 10:31 AM, Christian Beer
 cb.mailli...@googlemail.com mailto:cb.mailli...@googlemail.com wrote:

 As I use this overwrite mechanism also very often and it works in 2.6
 and 2.7, could you please post your faulty rule overwrite? Maybe you
 missed something.

 Regards
 Christian

 Am 13.03.2013 18:16, schrieb Stephane Rossan:
  Hi all,
 
  I use Ossec 2.6 on my server and unix clients.
  Recently, I tried to tune rule 533, and set the level of alert
 from 7
  to 6. In my setup, 6 doesn't generate email alerts.
  After few hours of this implementation, I noticed following
 errors in
  ossec.log:
  2013/03/11 22:41:35 ossec-syscheckd(1224): ERROR: Error sending
  message to queue.
  2013/03/11 22:41:36 ossec-logcollector(1224): ERROR: Error sending
  message to queue.
  2013/03/11 22:41:38 ossec-syscheckd(1210): ERROR: Queue
  '/apps/ossec/queue/ossec/queue' not accessible: 'Connection
 refused'.
  2013/03/11 22:41:38 ossec-syscheckd(1211): ERROR: Unable to access
  queue: '/apps/ossec/queue/ossec/queue'. Giving up..
  2013/03/11 22:41:39 ossec-logcollector(1210): ERROR: Queue
  '/apps/ossec/queue/ossec/queue' not accessible: 'Connection
 refused'.
  2013/03/11 22:41:39 ossec-logcollector(1211): ERROR: Unable to
 access
  queue: '/apps/ossec/queue/ossec/queue'. Giving up..
 
  I did some research and found this error message has nothing to do
  with the queue. It is related to a syntax error in
 local_rules.xml. I
  checked it, couldn't figure the issue, validated it with
  ossec-logtest, everything was fine. Reviewing my SCM for any
 change in
  the rules, I noticed issues started around the time I added rule 533
  to my local_rules.xml file. I rolled back to the previous version,
  minus rule 533. I monitored ossec.log for 24 hours, no issue. When I
  added rule 533 back, it broke again.
 
  Is there a way to fix this bug? I really need to collect netstat
 info
  but don't want to get an email alert every time there is a change.
 
  Thanks in advance,
  -Stephane
  --
 
  ---
  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
 mailto:ossec-list%2bunsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 



-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] How to check actively FTP activity on server using OSSEC?

2013-03-11 Thread Christian Beer
Hi,

I'm running a proftpd server. I don't see any reason to monitor the
activity via OSSEC but here are the rule IDs that are relevant for
proftpd. For the other servers you may want to check the rules file.

11205 - succesfull authentication of a user (happens very often!)
11201 - FTP session opened
11202 - FTP session closed

Those are all lvl 3 alerts and sometimes a lot of them for just one file
upload. In order to get an alert on uploads you might monitor the
xferlog file and write a custom rule to detect uploads. This however
will also result in a lot of alerts you get.

I don't know the traffic you expect but it better not much or you will
get a lot of mails.

Regards
Christian

Am 11.03.2013 08:38, schrieb Pratap:
 Hi ,

 I am trying to enable FTP log monitoring but my FTP logs are getting
 stored in syslog.log file and another file for transfer log for FTP. I
 need to get alert for any FTP user login/logout and file upload so
 that I can monitor my FTP server actively and keep an eye on it for
 any activity. 

 Any help would be help full .

 Thanks,
 -- 
  
 ---
 You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] Re: Book on Amazon still valid for OSSEC version 2.7?

2013-03-11 Thread Christian Beer
Why? As I understand your documentation system you just have to replace
the 50_*.xml files with the ones from the jbcheng repository. Maybe get
rid of the numbers (if they are not neccessary) and rebuild documentation.

Your bitbucket has two repos (ossec-docs-dev and ossec-rules) that are
forked from jrossi/ossec-rules (which has not changed since 2011). So I
assume one of yours is the authoritative repo for online documentation?

If you say which repo I should diff against, I can sure copy some files
over.

Regards
Christian

Am 11.03.2013 15:12, schrieb dan (ddp):
 On Mon, Mar 11, 2013 at 6:47 AM, Christian Beer
 cb.mailli...@googlemail.com wrote:
 On slightly related note. Could someone please update the rule reference on
 http://www.ossec.net/doc/rules/rules/index.html
 Compare the ossec rules as an example:
 documentation: http://www.ossec.net/doc/rules/rules/50_ossec_rules.xml.html
 current source:
 https://bitbucket.org/jbcheng/ossec-hids/src/60fa0f8a2bcc/etc/rules/ossec_rules.xml?at=default

 Regads
 Christian

 Please send patches.

 Am 11.03.2013 11:24, schrieb mikes:

 Of course not: Publication Date: March 17, 2008 |

 However, 2.7 and 2.6 is the same, here is all changes:
 http://www.ossec.net/?p=577

 Writing rules and configurations is the same.

 W dniu poniedziałek, 11 marca 2013 10:26:40 UTC+1 użytkownik Gerard Petersen
 napisał:
 Hi All,

 I'm currently testing OSSEC (2.7). I'm clear on what I want to know from
 my infrastructure, the learning curve for me is to figure out how OSSEC can
 do this for me.

 Is the book on amazon still good or has there been to many changes since
 OSSEC 2.7 in the nitty-gritty to be usefull. In other words would the online
 found documentation suffice?

 Ref:
 http://www.amazon.com/OSSEC-Host-Based-Intrusion-Detection-Guide/dp/159749240X

 Thanx a lot.

 Kind regards,

 Gerard.
 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [ossec-list] Manually unblock IP blackisted by active-reponse before timeout expiration

2012-10-16 Thread Christian Beer
I also use active_response (OSSEC 2.6) on a Debian server and whenever I 
want to unblock someone I delete the firewall rule directly using 
iptables commands. That always works instantaneously. But I have only 
one machine. In your setup using server/agent you have to unblock the IP 
at every agent and the server separately. Running host-deny and/or 
firewall-drop just on one machine is not enough because it is not 
propagated to the others.


Regards
Christian

Am 16.10.2012 17:16, schrieb Zoe:

Operating System : Linux openSuse

I agree with you : that doesn't make any sense :)
Re-apply firewall rules ? already done, no change.
A copy of my ossec.conf is above, have I missed something ?
I firewall-drop delete on agent, have i to do it on server ? on 
server ad agents ? from server to agents ?
I check ossec.log on server, active-response.log on agents, nothing 
strange there. Nothing in system logs.

Can others log files help ?


On Tuesday, October 16, 2012 4:56:14 PM UTC+2, dan (ddpbsd) wrote:

On Tue, Oct 16, 2012 at 10:49 AM, Zoe raea...@gmail.com
javascript: wrote:
 Thanks for explication.
 IP is not set anywhere else.

 Sorry for the lack of information :

 Ossec 2.6 is installed on server and agents with Suse Linux.

 # ossec.conf on Ossec Server
 ossec_config
 ...
 command
 namehost-deny/name
 executablehost-deny.sh/executable
 expectsrcip/expect
 timeout_allowedyes/timeout_allowed
 /command

 command
 namefirewall-drop/name
 executablefirewall-drop.sh/executable
 expectsrcip/expect
 timeout_allowedyes/timeout_allowed
 /command

 command
 namedisable-account/name
 executabledisable-account.sh/executable
 expectuser/expect
 timeout_allowedyes/timeout_allowed
 /command

 command
 namerestart-ossec/name
 executablerestart-ossec.sh/executable
 expect/expect
 /command

 command
 nameroute-null/name
 executableroute-null.sh/executable
 expectsrcip/expect
 timeout_allowedyes/timeout_allowed
 /command

 active-response
 commandhost-deny/command
 locationall/location
 level10/level
 rules_id11306/rules_id
 timeout900/timeout
 repeated_offenders15,30,60,120/repeated_offenders
 /active-response

 active-response--
 commandfirewall-drop/command
 locationall/location
 level10/level
 rules_id11306/rules_id
 timeout900/timeout
 repeated_offenders15,30,60,120/repeated_offenders
 /active-response
 /ossec_config
 ...

 # ossec.conf on Ossec agent
 ossec_config
 client
 server-ip1.1.1.2/server-ip
 /client
 active-response
 repeated_offenders15,30,60,120/repeated_offenders
 /active-response
 /ossec_config

 Is there any other information that can help ?


Operating system?

 Thanks in advance for your help.

 Note : when ossec execute firewall-drop delete and host-deny
delete
 after timeout, it's ok : IP is now allowed.
 But when I execute these commands manually, firewall and
hosts.deny are
 modified, but IP remains blocked...


That doesn't make any sense. Are you positive you haven't missed
something? All the scripts do is remove the IP from the firewall or
hosts.deny. Perhaps the firewall rules have to be re-applied or
something?

Other than that, I have no clue. I've never seen this problem, and
don't know why your system would be blocking something without any
reason to block it (ossec doesn't directly do any blocking). You'd
think there'd be a log somewhere though...

 Zoe

 On Tuesday, October 16, 2012 4:09:17 PM UTC+2, dan (ddpbsd) wrote:

 On Tue, Oct 16, 2012 at 9:40 AM, Zoe raea...@gmail.com wrote:
  Thanks for reply.
 
  No, IP is not blocked anywhere else.
  IP is not in firewall, neither in hosts.deny. But is still
blocked until
  timeout expired.
  After 900s (timeout), IP is allowed, but not before. Evend if
deleted
  from
  firewall and hosts.deny.
 
  The question : how is defined timeout ? Where or how can i
remove it
  after
  active-response is applied ?
 

 Remove it from where-ever you set it. The supplied AR scripts
don't do
 anything fancy. Generally if you remove the IP from the
firewall block
 and from the hosts.deny block it'll be allowed. If you remove the
 block from every place you have OSSEC set the block, it won't be
 blocked (by OSSEC) anymore. It's that simple.
 Since you haven't provided any useful information, that's all I
can
 help with. My guess would be you aren't using your tools
correctly,
 but that's just a guess.

  On Tuesday, October 16, 2012 3:28:20 PM UTC+2, dan (ddpbsd)
wrote:
 
  On Tue, Oct 16, 2012 at 9:12 AM, Zoe raea...@gmail.com 

Re: [ossec-list] active response email notifications not working?

2012-07-31 Thread Christian Beer

Am 31.07.2012 17:56, schrieb dan (ddp):

On Tue, Jul 31, 2012 at 11:49 AM, ChristianB
cb.mailli...@googlemail.com  wrote:

Hello all,

I now have my local installation of OSSEC working and integrated with my
running services. So far it's working really good. There is still one thing
that is not really working. I set up email notifications for active response
rules in my ossec.conf like this:
email_alerts
 email_tom...@email.de/email_to
 rule_id601, 602/rule_id
 do_not_delay /
 do_not_group /
/email_alerts

I also tried using therule_group  tag but this also didn't work. Every
other notification is correctly send (ossec start and everything above level
7). For the meantime I want to have all active_response action send to me
immediately to finetune the system.

And before you ask. Yes I checked with analogi that there where indeed
alerts triggering rules 601 and 602. I also have a minimal local_rules.xml
(Listen ports warning and load average warning) and an extended ar_log
decoder in my local_decoder.xml (added German weekdays to the regex).

Regards
Christian

What is your email_alert_level set to? 601 is only a level 3, so if
it's set higher than that you shouldn't expect email notification.
email_alert_level is set to 7. But I don't really want to lower this 
just get the ar notifications on top. I thought that for individual 
email notifications this alert level is ignored. As it is a global 
setting I will overwrite the rules in question and set the level to 7 
for the meantime.


Re: [ossec-list] active response preview possible?

2012-07-21 Thread Christian Beer

Thanks for this fast response, I'll answer inline.

On 21.07.2012 16:52, dan (ddp) wrote:


 1. Is there an option I can set to enable active_response but not 
actually block the attacker? Some kind of file or log with messages 
like: OSSEC would have added the IP 123.123.123.123 to your 
iptables/host.deny. I would like this to see before enabling it and 
potentially block a customer.



Create an AR script that just logs that information. `echo $@  
/var/log/almost-ar.log`



Ok, I'll try this and see what I have to tweak.
 3. Speaking of the webUI. I find it very disturbing that it is still 
listed at the OSSEC download page (and hosted on ossec.net 
http://ossec.net) and not the least marked as deprecated or not 
supported. There seem to be several patches in the archives but 
nowhere else.


I've been told it's being worked on.

Good to hear, but I'll try the patches from this list (if I can find 
them again) nevertheless.


 last note: the first steps with OSSEC page should be updated because 
some links are not working anymore ( I would liked to have seen a 
video tutorial or some more first-steps documentation.



Do you have a video to share? How exciting is a video of command line 
activity? I don't think that page is part of the documentation I work 
on, but I'll double check. Maybe someone with access will fix it.


I'll find it better if there is a audio commentary to the questions of 
the install script. It helps to understand the different features and 
how they are connected. But that may be just my view as a junior sysadmin.


Regards
Christian