Oops. I think I caught that when I passed it on to the dev list, but forgot to 
send it here as well. Sorry about that.

Sent from my Nokia phone
-----Original Message-----
From: tm
Sent:  06/11/2010 6:21:32 PM
Subject:  [ossec-list] Re: decoder.xml bug: decoder name="ssh-reverse-mapping"

Dan,

That "W" in your decoder should be a "w".  Other than that, your
decoder works for all of our environments (Redhat, Solaris, SuSE &
Mac).

Cheers!
Trevor

On Jun 9, 3:35 pm, "dan (ddp)" <[email protected]> wrote:
> Thanks for pointing that out. I've submitted a couple of fixes
> (including an addition similar to that I posted earlier in this
> thread).
> If you come up with anything else that isn't working, definitely let
> the list know. I'm not sure how well the rules are tested for
> regressions yet, and I kind of have an idea on how to help that...
>
>
>
> On Wed, Jun 9, 2010 at 12:24 PM, tm <[email protected]> wrote:
> > Hi Dan,
>
> > I agree about the different OSes/distros.  However, I get suspicious
> > when the decoder ssh-reverse-mapping won't even work with the two
> > examples shown in decoder.xml.  Perhaps whoever wrote the decoder
> > wasn't writing it for those two examples?
>
> > Anyway, we are trying to set up our DNS so that I can simulate this
> > problem on the 4 different OS's we use.  I'll post the results.
>
> > Trevor
>
> > On Jun 8, 5:25 am, "dan (ddp)" <[email protected]> wrote:
> >> On Mon, Jun 7, 2010 at 5:19 PM, tm <[email protected]> wrote:
> >> > Hello,
>
> >> > I believe that there is a bug with this decoder.  The example in
> >> > decoder.xml looks like this:
>
> >> >  sshd[23578]: reverse mapping checking getaddrinfo for pib4.catv-
> >> > bauer.at failed - POSSIBLE BREAKIN ATTEMPT!
>
> >> > The decoder looks like this:
>
> >> > <decoder name="ssh-reverse-mapping">
> >> >  <parent>sshd</parent>
> >> >  <prematch>^reverse mapping checking </prematch>
> >> >  <regex offset="after_prematch">^\w+ for (\S+) </regex>
> >> >  <order>srcip</order>
> >> > </decoder>
>
> >> > What is being decoded as the source IP address would be:  pib4.catv-
> >> > bauer.at.  This is not correct.
>
> >> > This came to light this past weekend when I saw an entry in active-
> >> > response.log like this:
>
> >> > Sat Jun  5 11:29:27 PDT 2010 /opt/ossec/active-response/bin/host-
> >> > deny.sh add - 92.117.127.124.broad.bj.bj.static.163data.com.cn
> >> > 1275762567.604428 5703
>
> >> > Obviously, it didn't work because the third parameter is not an IP
> >> > address.  The event which generated the alert looked this:
>
> >> > OSSEC HIDS Notification.
> >> > 2010 Jun 05 11:29:27
>
> >> > Received From: (x.w.y.z) a.b.c.d->/var/log/secure.log
> >> > Rule: 5703 fired (level 10) -> "Possible breakin attempt (high number
> >> > of reverse lookup errors)."
> >> > Portion of the log(s):
>
> >> > Jun  5 11:29:27 x sshd[53408]: reverse mapping checking getaddrinfo
> >> > for 92.117.127.124.broad.bj.bj.static.163data.com.cn [124.127.117.92]
> >> > failed - POSSIBLE BREAK-IN ATTEMPT!
> >> > Jun  5 11:29:25 x sshd[37460]: reverse mapping checking getaddrinfo
> >> > for 92.117.127.124.broad.bj.bj.static.163data.com.cn [124.127.117.92]
> >> > failed - POSSIBLE BREAK-IN ATTEMPT!
> >> > Jun  5 11:29:25 x sshd[53405]: reverse mapping checking getaddrinfo
> >> > for 92.117.127.124.broad.bj.bj.static.163data.com.cn [124.127.117.92]
> >> > failed - POSSIBLE BREAK-IN ATTEMPT!
> >> > Jun  5 11:29:23 x sshd[37458]: reverse mapping checking getaddrinfo
> >> > for 92.117.127.124.broad.bj.bj.static.163data.com.cn [124.127.117.92]
> >> > failed - POSSIBLE BREAK-IN ATTEMPT!
> >> > Jun  5 11:29:22 x sshd[53402]: reverse mapping checking getaddrinfo
> >> > for 92.117.127.124.broad.bj.bj.static.163data.com.cn [124.127.117.92]
> >> > failed - POSSIBLE BREAK-IN ATTEMPT!
>
> >> > Rule 5703 tries to activate the active response by passing
> >> > 92.117.127.124.broad.bj.bj.static.163data.com.cn as the IP address
> >> > because of the flaw in the decoder.
>
> >> > This particular set of events was generated on a Mac.  I don't know
> >> > yet what similar events from other OS's would look like.
>
> >> > Trevor
>
> >> It seems like a number of OSes/distros have differing error messages
> >> for the same ssh events. So it isn't a flaw in the decoder, just no
> >> decoder for this particular platform.
> >> Adding a decoder for this shouldn't be too difficult. I can't test it
> >> out at the moment, but you could try adding the following decoder to
> >> decoder.xml above the decoder you mentioned:
> >> <decoder name="ssh-reverse-mapping-osx">
> >>   <parent>sshd</parent>
> >>   <prematch>^reverse mapping checking </prematch>
> >>   <regex offset="after_prematch">^\W+ for \S+ [(\S+)] </regex>
> >>   <order>srcip</order>
> >> </decoder>
>
> >> Use ossec-logtest to test it out.- Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Reply via email to