Server as an agent -- where does the agent name come from?

257 views
Skip to first unread message

Barry Kaplan

unread,
Feb 23, 2016, 3:49:22 AM2/23/16
to Wazuh mailing list
I am running a wazah ossec server. Whenever I get logs/kibana the AgentName is not the hostname but something that must have come from AWS.

Specifically:

$ hostname
ops
-security-server

$ hostname
127.0.0.1 10.0.196.218


But the AgentName value is always "ip-10-0-196-218"

For all the "real" agents, the name is the actual hostname. This is only for the server.

Pedro S

unread,
Feb 23, 2016, 6:28:39 AM2/23/16
to Wazuh mailing list
Hi Barry,

What OS are you using?

Kibana extracts the agent name from OSSEC alerts, OSSEC uses internally the standard C function gethostname() which call the function uname(). The return of this function usually match the output of running hostname in your terminal but not always. 

You can change your instance hostname like this:
  1. Open the file /etc/hostname, edit it with your desire host name and save changes.
  2. Open the file /etc/hosts, edit it, write the same host that you chose before:
127.0.0.1 localhost your-host-name

You will need to reboot (sudo reboot) to apply changes.


Let's see if everything gone well, run "hostname" command on your terminal and check the agent name at OSSEC:

/var/ossec/bin/agent_control -i 000


In terms of Amazon AWS, there are some documentation regarding to change host names: Changing Hostname of your Linux instance.


I hope it helps, if you have any doubts don't hesitate to ask.

Regards,

Pedro S.

Barry Kaplan

unread,
Feb 23, 2016, 10:03:53 AM2/23/16
to Wazuh mailing list
Thanks Pedro,

I was not asking how to change the hostname -- the host is correct as I showed above. I wanted to know how ossec itself decides what the hostname is. Because it is not using the normal hostname, nor the hostname in /etc/hosts. 

in any case, its seems that agent_control has the correct value:

$ bin/agent_control -i 000

OSSEC HIDS agent_control
. Agent information:
   
Agent ID:   000 (local instance)
   
Agent Name: ops-security-server
   IP address
: 127.0.0.1
   
Status:     Active/Local

   
Operating system:    Linux ops-security-server 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64
   
Client version:      OSSEC HIDS v2.8
   
Last keep alive:     Not available

   
Syscheck last started  at: Tue Feb 23 06:52:04 2016
   
Rootcheck last started at: Tue Feb 23 04:59:56 2016


Ah! I found it. It's coming from /var/log/auth.log. So nothing to do with ossec. I'll have to dig a bit deeper.

Barry Kaplan

unread,
Feb 23, 2016, 10:07:51 AM2/23/16
to Wazuh mailing list
A restart of rsyslog fixed it up. Will need to add the ansible playbook...

Pedro S

unread,
Feb 23, 2016, 10:59:31 AM2/23/16
to Wazuh mailing list
Oh, so I did not understand the question quite right, excuse me.

Let's be clear, hostname field could come from the log itself matching a valid pre-decoder:

Feb 23 05:19:29 hostname-test1 sshd[35929]: Accepted password for root from 192.168.1.36 port 50675 ssh2


**Phase 1: Completed pre-decoding.
       full event: 'Feb 23 05:19:29 hostname-test1 sshd[35929]: Accepted password for root from 192.168.1.36 port 50675 ssh2'
       hostname: 'hostname-test1'
       program_name: 'sshd'
       log: 'Accepted password for root from 192.168.1.36 port 50675 ssh2'



Or if a pre-decoder can't extract a valid hostname from the log, local machine hostname will be used:

root@ubuntu:/home/snaow/ossec-wazuh# hostname
ubuntu5



2016-02-18 03:46:05 status unpacked libmailutils4:amd64 1:2.99.98-1.1
**Phase 1: Completed pre-decoding.
       full
event: '2016-02-18 03:46:05 status unpacked libmailutils4:amd64 1:2.99.98-1.1'
       hostname
: 'ubuntu5'
       program_name
: '(null)'
       log
: '2016-02-18 03:46:05 status unpacked libmailutils4:amd64 1:2.99.98-1.1'



Like you figured out, your logs had still old hostname that's why hostname was not right.

Good luck with that ansible deployment! I hope you can tell us how is going, thanks for the contribution,

Best regards,

Pedro S.
Reply all
Reply to author
Forward
0 new messages