[ossec-list] Agentless ssh monitoring fails to connect every time

[Marcin Gołębiowski]

I can't seem to make the agentless monitoring to work. I added two remote 
boxes with /var/ossec/agentless/register_host.sh and configured paswordless 
connection generating ssh keys for user ossec. However after restarting 
ossec the connection to remote server fails every time. Ossec.log shows: 
ossec-agentlessd: 
ERROR: ssh_integrity_check_linux: u...@remote.server.pl: Public key 
authentication failed to host: u...@remote.server.pl. I tried to connect 
wit a password but this time I got timeout: ERROR: 
ssh_integrity_check_linux: u...@remote.server.pl: Timeout while connecting 
to host: u...@remote.server.pl. I checked .passlist file and passwords are 
correct. What is more - I am able to ssh to remote server using id_rsa 
generated for ossec user so theoretically ossec should connect with NOPASS 
option. But it doesn't. I am in the dark. Server is Ubuntu Server 16.04, 
OSSEC verson 2.8.3, expect installed, firewall disabled. Any ideas?

-- 

--- 
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] Re: DNS block active response script not run for named rule

[Ralph Durkee]

Decoding the host name in named log as "url" causes it to not get passed to
the active response script.  I just a dash "-" as a place holder.
Decoding as user isn't perfect either as the built-in validation will
sometimes reject the value and not call the script,   For example the
following error in ossec.log when the "user" has http://  in it.

2017/03/17 10:03:39 ossec-analysisd(1272): WARN: Invalid username '8.
http://www.ralph66.com'. Possible logging attack.

I can create a static block for DNS queries with an invalid 'http://' in
the host name.

Any thoughts on the decoding and the validation?


On Wed, Mar 15, 2017 at 4:32 PM, dan (ddp)  wrote:

> On Wed, Mar 15, 2017 at 4:15 PM, Ralph Durkee 
> wrote:
> > Dan,
> >
> >
> > When I started this I was apparently was using some old documentation,
> > probably the book you wrote several years ago, and the parameter examples
> > were limited. Also the newer docs show a limited set of 
> > directives, so I’m wondering if there is a  directive. Maybe
> > location would make sense? Actually the whole concept of blocking on
> > same_location will not work unless the decoder strips off the first
> random
> > hostname and grabs the rest of the domain name. Of course all of this
> may be
> > too specific and the more generic version of the rules may be preferred
> if
> > it works as well.
> >
>
> Daniel Cid wrote the book, I'm the other Dan. Daniel Cid also created
> OSSEC. :-)
> But it is outdated at this point
>
> >
> > What I have now worked against a recent flurry of bogus DNS requests, but
> > then a second flurry started and it didn’t trigger a second time. It
> would
> > have been during the timeout window of the first flurry of requests. So
> I’m
> > thinking it may be related to not triggering active response again during
> > the timeout window. When I have some more time I’ll do some testing to
> try
> > to confirm the hypothesis, but any insights or questions from those with
> > more experience are much appreciated.
> >
>
> I'm not sure why that would happen. I'll have to read through this
> thread again and maybe try to recreate it (or at least something
> similar).
>
> >
> > I will try out the decoder soon, but first wanted to test and resolve the
> > issue about not firing for a second flurry.
> >
> >
> > Thanks for the help!
> >
> > I love the flexibility and capabilities of OSSEC
> >
> >
> > -- Ralph Durkee, CISSP, GXPN, GPEN, GCIH, GSEC, GSNA, GCIA, C|EH
> > Principal Security Consultant
> >
> >
> >
> > --
> >
> > ---
> > 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 a topic in the
> Google Groups "ossec-list" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/ossec-list/BTPA-plCXxM/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Drop IP on all agents

[Martin]

Hello,

It is working now, i've re install my set-up. And after having modify the 
files, i did : */var/ossec/bin/ossec-control restart* on the server and all 
the agents. Before, I was doing this on the server only and 
*/var/ossec/bin/agent_control 
-R* for the agents (but maybe my files were wrong) ..

The only problem remaining is that the connexion get drop on all the agents 
but not on the server. (I've nothing on the active-response.log on the 
server).

When I run firewall-drop manually (on the server) it is working but I can 
still log on every agents.

Best regards

-- 

--- 
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.