[ossec-list] last -10

[Aj Navarro]

i want to monitoring the last connections on a server.
 
I configuring last -10 command on a ossec.conf client 
 

full_command
last 10
60
  
I need that the output of this command will send to the ossec server, but I 
not watching any alert on the ossec wui.
 
can i need to configure anything else on the client or on the ossec server?
 
 
 
 

-- 

--- 
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] OpenBSD 6 - Real Monitoring

[dan (ddp)]

On Mon, Oct 3, 2016 at 6:07 PM, R0me0 ***  wrote:
> Hello dan !
>
> Real monitoring still not working, but it could be regarding my ossec server
> running 2.8.3. After I upgraded agent to 2.9 ( which is that cloned ) it
> stopped to make sums ( md5 sha1 ) so I think is regarding update  that real
> monitor isn't working .
>

It's not really working for me either, but I haven't had time to
figure out if libinotify isn't working, or if it's actually OSSEC.


> I will need to configure a lab with current branch of ossec and perform all
> possible tests like report_changes , check_sum ( which at moment isnt
> working properly with current version I running ) I ran a lot of OpenBSD
>
> Thank you so much your time, attention , need to pay a beer for u.
>
>
> Regards,
>
>
>
>
> 2016-10-03 14:36 GMT-03:00 R0me0 *** :
>>
>> Hey dannn ! compiled
>>
>> + DEFINED+=-DINOTIFY_ENABLED
>>
>> It was i didn 't :P
>>
>> tail /var/ossec/logs/ossec.log  | fgrep "real time"
>> 2016/10/03 14:22:51 ossec-syscheckd: INFO: Directory set for real time
>> monitoring: '/etc'.
>>
>> I am waiting diff to populate and I will check if real time it really
>> working
>>
>> back soon :) Thank you so much !
>>
>>
>>
>> 2016-10-03 14:32 GMT-03:00 dan (ddp) :
>>>
>>> On Mon, Oct 3, 2016 at 1:16 PM, R0me0 ***  wrote:
>>> > Dan , Just have take a look what you changed and I already did it.
>>> >
>>> > Just for curiosity I will clone and try to compile
>>> >
>>> > :)
>>> >
>>>
>>> It Compiles for Me (TM)
>>>
>>> > 2016-10-03 13:58 GMT-03:00 dan (ddp) :
>>> >>
>>> >> Found the issue, looks like I forgot to commit a few bits. It should
>>> >> work
>>> >> now.
>>> >>
>>> >> On Mon, Oct 3, 2016 at 12:54 PM, dan (ddp)  wrote:
>>> >> > On Mon, Oct 3, 2016 at 12:51 PM, R0me0 *** 
>>> >> > wrote:
>>> >> >> Hello Dan,
>>> >> >>
>>> >> >> I tried to compile the last OSSEC stable release
>>> >> >> https://github.com/ossec/ossec-hids/archive/v2.8.3.tar.gz
>>> >> >> Also I have cloned https://github.com/ddpbsd/ossec-hids (
>>> >> >> openbsd_inotify )
>>> >> >> branch
>>> >> >> Tried the pre-release of OSSEC (
>>> >> >> https://github.com/ossec/ossec-hids/archive/2.9rc3.tar.gz )
>>> >> >> All of them fail to compile witrh inotify
>>> >> >>
>>> >> >> Note: I am trying to compile OSSEC AGENT with inotify support under
>>> >> >> OpenBSD
>>> >> >> 6.0 stable  branch all patches applied until 009
>>> >> >>
>>> >> >> Inotify from:
>>> >> >> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>>> >> >>
>>> >> >> pkg_add inotify-tools-3.14pl0.tgz dependency is
>>> >> >> libinotify-20160503.tgz
>>> >> >>
>>> >> >
>>> >> > Ok, I haven't tried an agent build yet.
>>> >> >
>>> >> >>
>>> >> >> Thanks
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> 2016-10-03 8:37 GMT-03:00 dan (ddp) :
>>> >> >>>
>>> >> >>> On Fri, Sep 30, 2016 at 6:19 PM, R0me0 *** 
>>> >> >>> wrote:
>>> >> >>> >  latest stable 2.8.3 neither openbsd_initify from your
>>> >> >>> > repository
>>> >> >>> > compiles.
>>> >> >>> >
>>> >> >>> > ldconfig -r | fgrep inotify
>>> >> >>> >
>>> >> >>> > linotify.2.0 => /usr/local/lib/inotify/libinotify.so.2.0
>>> >> >>> >
>>> >> >>>
>>> >> >>> How did you try to build it (MASTER from github)? I'm trying with
>>> >> >>> a
>>> >> >>> TARGET=server, and it's working for me.
>>> >> >>> Try adding:
>>> >> >>> V=1
>>> >> >>> to the Makefile. That might provide more information.
>>> >> >>>
>>> >> >>> --
>>> >> >>>
>>> >> >>> ---
>>> >> >>> 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.
>>> >>
>>> >> --
>>> >>
>>> >> ---
>>> >> 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

[ossec-list] Re: Ossec authd, Cant connect

[Jesus Linares]

Hi, 

it looks like a firewall issue. You could run tcpdump in the Manager to see 
if there are a connection between the manager and the agent.

Regards.

On Monday, October 3, 2016 at 10:02:52 AM UTC+2, Ali Khan wrote:
>
> Hi All,
>
> I am trying to use ossec-authd and agent-authd for auto agent key 
> registration . On OSSEC server i did the following 
>
>
>1. *openssl genrsa -out /var/ossec/etc/sslmanager.key 2048*
>2. *openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out 
>/var/ossec/etc/sslmanager.cert -days 365*
>3. */var/ossec/bin/ossec-authd -p 1515 -i >/dev/null 2>&1 &*
>4. *also added the following rule in etc/ossim/firewall_include : *
>5. *-A INPUT –p tcp –-dport 1515 –j ACCEPT*
>6. *Run the ossim-reconfig and then again run **/var/ossec/bin/ossec-authd 
>-p 1515 -i >/dev/null 2>&1 and the process starts.*
>
>
> *However on agent side when i enter  **./agent-auth -m 192.168.10.246 -p 
> 1515 it gives me the following error .* 
>
> 2016/10/03 12:34:58 ossec-authd: INFO: Started (pid: 9656).
> 2016/10/03 12:34:58 ossec-authd: Unable to connect to 192.168.10.246:1515
>
> Any kind of help would be highly appreciated as I cant think of workaround 
> for this issue . 
>
> Looking forward to your reply.
>

-- 

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

[ossec-list] Re: Windows SSTP VPN rule.

[Jesus Linares]

I'm not familiar with RRAS or Radius. If you share the logs, we can help 
with decoders and rules for the events that you need.

On Monday, October 3, 2016 at 6:11:37 PM UTC+2, namobud...@gmail.com wrote:
>
> It looks like I want to monitor for windows event log source entries that 
> have keyword “RASClient” in the list. These log entries are generated from 
> the Microsoft VPN RAS application. according to research I did.
>
> Apparently RRAS keeps local logs too.
>
> Ideally it would be great to be able to GEOLocate the VPN connection.
>
> Maybe I need to be monitoring Radius connections too?
>
> On Saturday, October 1, 2016 at 5:03:18 AM UTC-4, Jesus Linares wrote:
>>
>> Hi,
>>
>> if you share the events (logs) that you want to track, we can help to 
>> create the decoders and rules.
>>
>> Regards.
>>
>> On Wednesday, September 28, 2016 at 5:58:03 PM UTC+2, 
>> namobud...@gmail.com wrote:
>>>
>>> I'm wondering if anyone has done an OSSEC Windows SSTP VPN rule?
>>> I want to start tracking and logging them, GEO tracking would be awesome?
>>>
>>> Has anyone already done this, or could they suggest a rule?
>>>
>>> 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.

Re: [ossec-list] ossec-authd: Unable to connect

[Pedro S]

Hi again,

I don't really understand how it works if you don't have any OSSEC 
listening to 1514, maybe you are mistaken the hosts. On my labs if I run

*netstat -tunlp*


The output for OSSEC will be:


> *udp0  0 0.0.0.0:15140.0.0.0:* 
>   14287/ossec-remoted**tcp0  0 0.0.0.0:1515   
>  0.0.0.0:*   LISTEN  9684/ossec-authd*


Another tool for analysis is "traceroute", you can see how many jumps and 
how are you getting to the OSSEC manager destination.
Debian: apt-get install traceroute

*traceroute your_ossec_server*



Hope it helps, I am sorry I am not being so helpful but I don't really know 
your network so.. I am not sure what could be happening there : D


On Tuesday, October 4, 2016 at 9:25:46 AM UTC+2, Ali Khan wrote:
>
> These are the listening ports on server 
> Proto Recv-Q Send-Q Local Address   Foreign Address State 
>  
> tcp0  0 127.0.0.1:250.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:443 0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:40001   0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:40002   0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:514 0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:40003   0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:40004   0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:25672   0.0.0.0:*   
> LISTEN 
> tcp0  0 127.0.0.1:40009 0.0.0.0:*   
> LISTEN 
> tcp0  0 127.0.0.1:27017 0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:33060.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:40011   0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:15150.0.0.0:*   
> LISTEN 
> tcp0  0 127.0.0.1:6379  0.0.0.0:*   
> LISTEN 
> tcp0  0 127.0.0.1:11211 0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:63800.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:93900.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:93910.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:80  0.0.0.0:*   
> LISTEN 
> tcp0  0 127.0.0.1:28017 0.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:43690.0.0.0:*   
> LISTEN 
> tcp0  0 0.0.0.0:22  0.0.0.0:*   
> LISTEN 
> tcp6   0  0 :::3128 :::*LISTEN 
> 
> tcp6   0  0 :::514  :::*LISTEN 
> 
> tcp6   0  0 :::40005:::*LISTEN 
> 
> tcp6   0  0 :::40006:::*LISTEN 
> 
> tcp6   0  0 :::5672 :::*LISTEN 
> 
> tcp6   0  0 :::6380 :::*LISTEN 
> 
> tcp6   0  0 :::22   :::*LISTEN 
>
> Now 1515 is in listening state and is also allowed in iptables but I am 
> not able to telnet it. Moreover when I do manual agent key registration ,it 
> works perfectly. I even checked by doing some fail login attempts and those 
> login attempts  were shown on AV dashboard by HIDS after I did manual key 
> registration, but when i netstat, 1514 it isnt being shown as listening 
> state. Now all these things contradict each other, and I myself dont know 
> whats happening here.Neither 1515 nor 1514 can be telnet , bufail login 
> attempts on the system for which I did manual registration is being shown 
> on the dashboard and Ossec uses 15154 for this purpose but 1514 cant be 
> telnet and isnt in listening state , and when I run nmap none of these 
> ports are open .  
>
>
>
> On Mon, Oct 3, 2016 at 10:58 PM, Dodain Dodo  > wrote:
>
>> The manual agent installation works perfectly and it even shows hids 
>> events /alarm for my host/PC . 
>>
>> On Oct 3, 2016 10:51 PM, "Pedro Sanchez"  
>> wrote:
>> >
>> > Hi,
>> >
>> > I think this could be a connectivity issue, ossec-authd looks listening 
>> correctly, did you try to add the agent manually and check for 1514 
>> connectivity? I am not sure if both server are able to communicate on a 
>> different way, try to use tcpdump on server side and telnet on other.
>> >
>> > Server:
>> >
>> >> tcpdump -i eth0 port 1515 -vv
>> >
>> >  
>> > Agent:
>> >
>> >> telnet server_ip 1515
>> >
>> >
>> >
>> > Try to add it manually, if that works, we can keep going with ossec 
>> 

[ossec-list] Re: Ossec Naming Conventions

[Jesus Linares]

I don't think so. Check out the ossec.log of the agents that don't connect 
to the Manager. Usually they do not connect due to: firewall, bad key or 
duplicate counters (rids). The hostname should not be a problem.

On Friday, September 30, 2016 at 2:56:28 PM UTC+2, EvilZ wrote:
>
> Hi everyone i would like to know if Ossec use a Netbios naming convention 
> where the name must be less than 14 charaters ? because i noticed a few 
> servers who will not connect and realized it was because they are 15 
> characters however their are other servers who are active and yet have the 
> same number of characters
>
> In this example, these two "servers" have two different name however my 
> fear is that the second one would not be accepted as it would be seen as a 
> duplicate as Ossec cannot read further than the 14 characters name which 
> would then ignore the 1.
>
>
> bob-the-bobiest
> bob-the-bobiest1
>
> Am i correct ?
>
> 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/d/optout.

[ossec-list] Re: Simultaneous Events at 25 EPS, but Missing Alerts

[Pedro S]

Hi Jon,

This is an interesting test, I think we can get a lot of useful information 
from here.

On my experience probably the bottleneck is on remoted socket/buffer or 
logcollector speed performance to read each log line.

For Remoted, try to enable debug mode at the agent, internal_options.conf 
file, remoted.debug=2, and agent.debug=2. You will find at ossec.log each 
line read by logcollector and sent to remoted, this way we can figure out 
if the problem is related to gathering/sending or lately 
receiving/proccesing.

On my tests I can see how everything is being pushed, but just a few events 
on archives are displayed, I think OSSEC also have some protection for 
multiple identical messages.

2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
> '--MARK--: '
> 2016/10/04 11:07:43 ossec-agent: DEBUG: Attempting to send message to 
> server.





On Monday, October 3, 2016 at 8:27:04 PM UTC+2, Jon Goodgion wrote:
>
> I've been curious about the performance of OSSEC in a server/agent 
> architecture, so I have been emulating simultaneous events on a single 
> agent by appending log entries to the agent's syslog.
>
> Using a shell script for loop on the agent, I append 25 consecutive logs 
> that match the format of a telnet failed password log. I figured 25 EPS 
> should be easily captured by OSSEC.
>
> However, on the server, (after enabling logall to archives), it doesn't 
> seem like it is processing all the logs. 
> /var/ossec/logs/archives/archives.log shows:
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[*1*]: refused connect from 81.215.42.24
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[*13*]: refused connect from 81.215.42.158
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[14]: refused connect from 81.215.42.69
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[15]: refused connect from 81.215.42.32
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[16]: refused connect from 81.215.42.41
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[17]: refused connect from 81.215.42.74
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[18]: refused connect from 81.215.42.32
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[19]: refused connect from 81.215.42.222
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[20]: refused connect from 81.215.42.25
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[21]: refused connect from 81.215.42.141
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[22]: refused connect from 81.215.42.248
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[23]: refused connect from 81.215.42.45
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[24]: refused connect from 81.215.42.166
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[25]: refused connect from 81.215.42.178
>
> I put the for loop sequence identifier in the telnetd brackets [ ], and as 
> you can see, this particular test didn't catch anything between the 2nd and 
> 12th log.
>
> Does this have to do with UDP loss? Am I missing something, or possibly 
> need to reconfigure OSSEC a certain way? Any help would be greatly 
> appreciated!
>

-- 

--- 
You received this message because you are subscribed to 

Re: [ossec-list] ossec-authd: Unable to connect

[Dodain Dodo]

HI Pedro ,

I have already done all these things .Your and mine netstat results are
same. 1515 is in listening state and 1514 is also there. Sorry since
its(1514)  a udp port so how can it be in listening mode. My bad.

udp0  0 0.0.0.0:15140.0.0.0:*
27560/ossec-remoted
tcp0  0 0.0.0.0:15150.0.0.0:*   LISTEN
 5504/ossec-authd

So we are back at where we started. Server end is fine and ossec agent is
sending logs on 1514 but 1515 although in listening state is not able to
make connection with ossec server. Is your agent-auth working fine ?
 */var/ossec/bin/agent-auth
-m x.x.x.x -p 1515*

Moreover I was interested in reading source code for agent-auth , to see if
i can find a workaround .  :) .



On Tue, Oct 4, 2016 at 1:49 PM, Pedro S  wrote:

> Hi again,
>
> I don't really understand how it works if you don't have any OSSEC
> listening to 1514, maybe you are mistaken the hosts. On my labs if I run
>
> *netstat -tunlp*
>
>
> The output for OSSEC will be:
>
>
>> *udp0  0 0.0.0.0:1514 
>>  0.0.0.0:*   14287/ossec-remoted**tcp0
>>0 0.0.0.0:1515 0.0.0.0:*
>> LISTEN  9684/ossec-authd*
>
>
> Another tool for analysis is "traceroute", you can see how many jumps and
> how are you getting to the OSSEC manager destination.
> Debian: apt-get install traceroute
>
> *traceroute your_ossec_server*
>
>
>
> Hope it helps, I am sorry I am not being so helpful but I don't really
> know your network so.. I am not sure what could be happening there : D
>
>
> On Tuesday, October 4, 2016 at 9:25:46 AM UTC+2, Ali Khan wrote:
>
>> These are the listening ports on server
>> Proto Recv-Q Send-Q Local Address   Foreign Address State
>>
>> tcp0  0 127.0.0.1:250.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:443 0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:40001   0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:40002   0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:514 0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:40003   0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:40004   0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:25672   0.0.0.0:*
>> LISTEN
>> tcp0  0 127.0.0.1:40009 0.0.0.0:*
>> LISTEN
>> tcp0  0 127.0.0.1:27017 0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:33060.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:40011   0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:15150.0.0.0:*
>> LISTEN
>> tcp0  0 127.0.0.1:6379  0.0.0.0:*
>> LISTEN
>> tcp0  0 127.0.0.1:11211 0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:63800.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:93900.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:93910.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:80  0.0.0.0:*
>> LISTEN
>> tcp0  0 127.0.0.1:28017 0.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:43690.0.0.0:*
>> LISTEN
>> tcp0  0 0.0.0.0:22  0.0.0.0:*
>> LISTEN
>> tcp6   0  0 :::3128 :::*
>>  LISTEN
>> tcp6   0  0 :::514  :::*
>>  LISTEN
>> tcp6   0  0 :::40005:::*
>>  LISTEN
>> tcp6   0  0 :::40006:::*
>>  LISTEN
>> tcp6   0  0 :::5672 :::*
>>  LISTEN
>> tcp6   0  0 :::6380 :::*
>>  LISTEN
>> tcp6   0  0 :::22   :::*
>>  LISTEN
>>
>> Now 1515 is in listening state and is also allowed in iptables but I am
>> not able to telnet it. Moreover when I do manual agent key registration ,it
>> works perfectly. I even checked by doing some fail login attempts and those
>> login attempts  were shown on AV dashboard by HIDS after I did manual key
>> registration, but when i netstat, 1514 it isnt being shown as listening
>> state. Now all these things contradict each other, and I myself dont know
>> whats happening here.Neither 1515 nor 1514 can be telnet , bufail login
>> attempts on the system for which I did manual registration is being shown
>> on the dashboard and Ossec uses 15154 for this purpose but 1514 cant be
>> telnet and isnt in listening state , and when I run nmap none of these
>> ports are open .
>>
>>
>>
>> On Mon, Oct 3, 2016 at 10:58 PM, Dodain Dodo  wrote:
>>
>>> The manual agent installation works perfectly and it even shows hids
>>> events /alarm for my host/PC .
>>>
>>> On Oct 3, 2016 10:51 PM, "Pedro Sanchez"  wrote:
>>> >
>>> > Hi,
>>> >
>>> > I think this could be a connectivity issue, ossec-authd looks
>>> listening correctly, did you try to add the agent manually and check for
>>> 1514