On Thu, Jun 5, 2014 at 9:43 PM, Lou <[email protected]> wrote:
> If i use the logtest tool against the sample apache log you provided it
> decodes it correctly. If i substitute my timzone (see below) it does not
>
> Mine: 115.239.248.56 - - [05/Jun/2014:21:10:29 -0400] "GET
> /manager/html/captcha.php HTTP/1.1" 200 295 "-" "Mozilla/3.0 (compatible;
> Indy Library)"
>
> Yours: 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)"
>
> Any idea what's going on here?
>
Do you use pureftpd? If not, comment out the pure-transfer decoder,
and the pure-ftpd_rules.xml entry in your ossec.conf and try again.
I thought we had cleaned up the pure ftpd decoder issue, but I guess not.
>
> On Thursday, June 5, 2014 4:51:47 PM UTC-4, Lou wrote:
>>
>> Thanks guys.. i will have to take a closer look. My apache log isn't
>> being decoded properly - it's not grabbing the url OR scrip. I'm using this
>> for my Log Format currently LogFormat "%{HOST}i %h %l %u %t \"%r\" %>s %b
>> \"%{Referer}i\" \"%{User-Agent}i\""
>>
>> I'm done for now.. i will hopefully have some more time later this evening
>> to investigate further.
>>
>> Thanks to you both!!
>>
>> On Thursday, June 5, 2014 4:37:57 PM UTC-4, Christian Beer wrote:
>>>
>>> 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_sid>31108</if_sid>
>>> <url>captcha.php</url>
>>> <description>Captcha 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_sid>31101</if_sid>
>>> > <url>captchaDB.php</url>
>>> > <match>GET</match>
>>> > <description>Captcha attempt.</description>
>>> > </rule>
>>> >
>>> > <rule id="100507" level="10" frequency="4" timeframe="60">
>>> > <if_matched_sid>100506</if_matched_sid>
>>> > <same_source_ip />
>>> > <description>Captcha attack.</description>
>>> > <group>attack,</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 <[email protected]>
>>> > 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" group.
>>> > > To unsubscribe from this group and stop receiving emails from
>>> > it, send an
>>> > > email to [email protected].
>>> > > For more options, visit https://groups.google.com/d/optout
>>> > <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 [email protected]
>>> > <mailto:[email protected]>.
>>> > 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
