[ossec-list] active response scripts using wrong locale
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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.
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)
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?
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?
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
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
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
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
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
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?
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?
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
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?
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?
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
