agent-auth failing using password authentication in 3.0.0 with specified password but works with server generated

[repl-mike-roest]

We're trying to get 3.0.0 to work with agent auth, in that release there is currently the issue fixed by #1464 To try to unblock our moving forward I'm attempting to get agent auth working with a specified password.

If I do echo "password" > /var/ossec/etc/authd.pass on both my server and client

I see this in my server log:

2018/07/23 15:45:20 ossec-authd: INFO: Started (pid: 9).
2018/07/23 15:45:20 Accepting connections. Using password specified on file: /var/ossec/etc/authd.pass

I get the following in response to a auth request:

[root@ip-10-31-68-35 etc]# /var/ossec/bin/agent-auth -m 10.31.69.47 -P /var/ossec/etc/authd.pass -d -d -d -d
2018/07/23 15:46:45 ossec-authd: DEBUG: Starting ...
2018/07/23 15:46:45 ossec-authd: INFO: Started (pid: 23539).
2018/07/23 15:46:45 ossec-authd: DEBUG: Returning CTX for client.
INFO: Using specified password.
2018/07/23 15:46:45 INFO: Connected to 10.31.69.47 at address 10.31.69.47, port 1515
INFO: Connected to 10.31.69.47:1515
INFO: Using agent name as: i-06484aae53ee227cc
INFO: Send request to manager. Waiting for reply.
ERROR: Unable to create key. Either wrong password or connection not accepted by the manager.
INFO: Connection closed.

Server Log:

2018/07/23 15:46:46 ossec-authd: INFO: New connection from 10.31.68.35
2018/07/23 15:46:46 ossec-authd: ERROR: Invalid password provided by 10.31.68.35. Closing connection.

If I remove the authd.pass in the server log I get:

2018/07/23 15:48:14 Accepting connections. Random password chosen for agent authentication: 6663484170b2c69451e01ba11f319533

If I then do echo "6663484170b2c69451e01ba11f319533" > /var/ossec/etc/authd.pass

I get:

[root@ip-10-31-68-35 etc]# /var/ossec/bin/agent-auth -m 10.31.69.47 -A $INSTANCE_ID -P /var/ossec/etc/authd.pass -d -d -d -d
2018/07/23 15:49:43 ossec-authd: DEBUG: Starting ...
2018/07/23 15:49:43 ossec-authd: INFO: Started (pid: 23540).
2018/07/23 15:49:43 ossec-authd: DEBUG: Returning CTX for client.
INFO: Using specified password.
2018/07/23 15:49:43 INFO: Connected to 10.31.69.47 at address 10.31.69.47, port 1515
INFO: Connected to 10.31.69.47:1515
INFO: Using agent name as: i-06484aae53ee227cc
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.

It appears that using a specified password does not work.

This causes a issue for us as we're doing all of the install and creation through automation and getting the generated password out of the server log to be fed into launch configurations of other servers is not really practical.

[enver]

@repl-mike-roest try using 32 characters long password and it should work (not sure why 😄)

[repl-mike-roest]

@enver thanks for the tip. I've actually implemented a solution that works pretty good (and actually doesn't require us to pipe a given password around). I added a lighttpd server to the ossec server and a script that runs on a minutely cron job that finds the random password and outputs it into the lighttpd hosting dir for our clients to fetch and use for registration cat /var/ossec/logs/ossec.log | grep "Random password chosen for agent authentication:" | tail -n1 | cut -d':' -f4 | awk '{$1=$1};1' > /var/www/html/authd.pass

[Jon-100110002]

This seems to be a bigger issue. Since migrating to 3.0, the ONLY way we've been able to get agents to register via agent-auth is to allow ossec-authd to generate it's own password and then manually pass that to the agents. Specifying a 32 character password or various other lengths always fails. Disabling passwords with ossec-authd -n also always results in registration failure. Even trying to specify the ossec-authd password as a previous randomly generated one fails. We're on Ubuntu 16.04 using packages ossec-hids-agent_3.0.0-5505xenial_amd64.deb and ossec-hids-server_3.0.0-5505xenial_amd64.deb.

[Jon-100110002]

Well, this explains why -n doesn't work: https://github.com/ossec/ossec-hids/pull/1464

[Jon-100110002]

After further experimentation, I was able to get password authentication for ossec-authd working using a specified 32 character password. The key was to have a line feed at the end of the password file (/var/ossec/etc/authd.pass). Without the line feed, client authentication would fail every time. Curiously, the password file for agent-auth does not require the line feed.

[ddpbsd]

The newline issue might be caused by fgets? We could try something like the following to see if it helps: EDIT: untested diff. Will update shortly.

diff --git src/os_auth/main-server.c src/os_auth/main-server.c
index 682754e1..2efeaade 100644
--- src/os_auth/main-server.c
+++ src/os_auth/main-server.c
@@ -310,21 +310,27 @@ int main(int argc, char **argv)

         /* Checking if there is a custom password file */
         fp = fopen(AUTHDPASS_PATH, "r");
-        buf[0] = '\0';
+        char *passbuf = NULL;
         if (fp) {
-            buf[4096] = '\0';
-            char *ret = fgets(buf, 4095, fp);
+            ssize_t linelen;
+            size_t linesize = 0;
+            if((linelen = getline(&passbuf, &linesize, fp)) == -1) {
+                merror("Cannot get password from password file: %s: %s", AUTHDPASS_PATH, strerror(errno));
+            } else {
+                passbuf[0] = '\0';
+            }

-            if (ret && strlen(buf) > 2) {
+            if (strlen(passbuf) > 2) {
                 /* Remove newline */
-                buf[strlen(buf) - 1] = '\0';
-                authpass = strdup(buf);
+                passbuf[strlen(passbuf) - 1] = '\0';
+                authpass = strdup(passbuf);
+                free(passbuf);
             }

             fclose(fp);
         }

-        if (buf[0] != '\0')
+        if (authpass != '\0')
             verbose("Accepting connections. Using password specified on file: %s",AUTHDPASS_PATH);
         else {
             /* Getting temporary pass. */

EDIT2: compile tested only

[sijis]

For us, we need to pass the complete path to the authd.pass file, as /var/ossec/bin/agent-auth -m $HOSTNAME -P /var/ossec/etc/authd.pass

Also, the -h output of agent-auth did show the following

    -P <path>   Authorization password file [default: /var/ossec/etc/authd.pass

[jeffdyke]

just FYI, for anyone that stumbles across this in the newest update the newline issue seems to be fixed.

[packetfairy]

This seems to be a bigger issue. Since migrating to 3.0, the ONLY way we've been able to get agents to register via agent-auth is to allow ossec-authd to generate it's own password and then manually pass that to the agents. Specifying a 32 character password or various other lengths always fails.

How -- in the name of all that is holy -- does configuring the software to behave this way make any sense at all? How are new clients supposed to get this randomly chosen password every time it changes? Do you really presume that we're constantly monitoring log files and installing your software by hand everywhere?! It's not 1996 anymore!

Could you please stop breaking your own software? I'll get on my knees and ask again, if it helps. We lose a day every time you release a new version trying to figure out what you broke this time. First you decided to disable authd at boot altogether for "$security." Now you made authd functionally unusable, again in the name of "$security!" I cannot say this clearly enough: THIS STRONGLY DISINCENTIVIZES APPLYING VERSION UPGRADES! This software is supposed to keep our hosts secure. Seeing an OSSEC upgrade should not instantly fill us with fear and loathing. We should not have to hand hold the upgrade every single time. And we DEFINITELY should not feel like never installing upgrades is the right choice!

[ddpbsd]

@packetfairy Thanks for the encouraging words. I will definitely try harder, and look forward to your testing reports in the future!

[RanaBhagathChand]

@repl-mike-roest @JuanjiJG

I have installed my OSSEC manager on the AWS ec2 instance. When I trying to add an agent to the manager using ossec-authd

/var/ossec/bin/ossec-authd -p 1515

here are the logs after the execution of the above command:

2020/08/26 05:10:35 Accepting connections. Random password chosen for agent authentication: 31e1a47ea4f8a1b1dc9e5f2e991aa3be 2020/08/26 05:10:35 ossec-authd: DEBUG: Returning CTX for server. 2020/08/26 05:10:35 IPv6: :: on port 1515 2020/08/26 05:10:35 Request to allocate and bind sockets failed. 2020/08/26 05:10:35 ossec-authd: Unable to bind to port 1515 On the agent side when I am trying to connect to the manager using agent-auth using:

/var/ossec/bin/agent-auth -m <manager_ip> -p 1515 -A <agent_name> -P /var/ossec/etc/authd.pass

where /var/ossec/etc/authd.pass consists of the random password chosen for the agent in this case it is: 31e1a47ea4f8a1b1dc9e5f2e991aa3be

It's responding in the following manner:

2020/08/26 16:11:14 ossec-authd: DEBUG: Starting ... 2020/08/26 16:11:14 ossec-authd: INFO: Started (pid: 31847). 2020/08/26 16:11:14 ossec-authd: DEBUG: Returning CTX for client. INFO: Using specified password. 2020/08/26 16:11:15 INFO: Connected to <server_ip> at address <server_ip>, port 1515 INFO: Connected to <server_ip>:1515 INFO: Using agent name as: nineleaps-ThinkPad-L470 INFO: Send request to manager. Waiting for reply. ERROR: Unable to create key. Either wrong password or connection not accepted by the manager. INFO: Connection closed. can you help me with this issue?

[ddpbsd]

@RanaBhagathChand Request to allocate and bind sockets failed. looks suspicious. Looks like this is an error from OS_Bindport() in os_net.c. Make sure ossec-authd is actually listening on 1515.

But, I just tried it with a fresh 3.6 install and everything worked.

[RanaBhagathChand]

@ddpbsd

I have already enabled udp and tcp ports 1515 on the manager.

Whenever a request was made by the client here are the logs for it even after I have copy-pasted Random password chosen for agent authentication:

2020/08/26 13:07:51 ossec-authd: INFO: New connection from 157.84.54.41 2020/08/26 13:07:51 ossec-authd: ERROR: Invalid password provided by 157.84.54.41. Closing connection.

And also able to get response from tcpdump port 1515 when the agent requested the server.

[ddpbsd]

@RanaBhagathChand What distro/version are you using? What version of OSSEC? I'd probably add a line to printf tmpstr in main-server.c in the /* Checking for shared password authentication. */ section. Make sure the correct password is getting passed.