This is really needed and would solve the issue of agents being vulnerable to MiM attacks. Thank you for your efforts.

If you feel adventurous, maybe you take a look at agent-auth on Windows and discover why it doesn't work. :)

Great, I'll continue on with this and post updates here. Will see what the issue is with agent-auth on Windows as well, cheers.

So in order to get an agent key the agent would need its own key? Do I undrstand this correctly?

Yes, but only if that functionality is needed by the organisation using ossec-authd/agent-auth and they have the existing infrastructure in place to support it. All of this proposed functionality is optional to users and they would have to specify additional command line arguments to make use of it. If they're happy using ossec-authd/agent-auth as is and don't require any certificate verification then they will notice absolutely no difference in the way they use these utilities.

This proposed enhancement is really intended for organisations that:

1. Want a more automated way of provisioning machines into Ossec.
2. Have an existing private CA in place that they use to issue their own certificates.
3. Need verification that they're connected to the appropriate server when using agent-auth and that the SSL connection has not been compromised.

In addition to that some organisations may want the ability to verify that clients connecting to ossec-authd also present a valid certificate.

Scenario 1:
An organisation has a private CA in place which is used to issue certificates for all their existing internal services. The CA's certificate is included automatically with newly provisioned machines.

Process:
The organisation issues certificates for ossec-authd signed by their internal CA as they would any other service. Newly provisioned machines can then verify this certificate when being added via agent-auth:

ossec-authd -x /path/to/ossec-authd.crt -k /path/to/ossec-authd.key
agent-auth -m <ossec_server_ip> -v /path/to/included/ca.crt

Scenario 2:
An organisation has a private CA in place which is used to issue certificates for all their existing internal services. The CA's certificate is included automatically with newly provisioned machines. In addition to this, unique client certificates are generated and included with all newly provisioned machines.

Process:
The organisation issues certificates for ossec-authd signed by their internal CA as they would any other service. Newly provisioned machines can then verify this certificate when being added via agent-auth. At the same time ossec-authd can also verify that clients present a certificate signed by a CA that it trusts:

ossec-authd -x /path/to/ossec-authd.crt -k /path/to/ossec-authd.key -v /path/to/ca.crt
agent-auth -m <ossec_server_ip> -x /path/to/agent-auth.crt -k /path/to/agent-auth.key -v /path/to/included/ca.crt

The -x and -k options mentioned above for ossec-authd are optional and need not be specified. ossec-authd will continue to load the certificate and key from <ossec_dir>/etc/sslmanager.cert and <ossec_dir>/etc/sslmanager.key by default. I added them as a convenience for users.

The goal here is to leave existing users completely unaffected but allow users with stricter security requirements to be able to use ossec-authd.

On Mon, Mar 31, 2014 at 2:47 AM, mweigel notifications@github.com wrote:

The -x and -k options mentioned above for ossec-authd are optional and need not be specified. ossec-authd will continue to load the certificate and key from <ossec_dir>/etc/sslmanager.cert and <ossec_dir>/etc/sslmanager.key by default. I added them as a convenience for users.

The goal here is to leave existing users completely unaffected but allow users with stricter security requirements to be able to use ossec-authd.

Understood, but if you have the infrastructure to put the SSL keys on
each system, couldn't you use the same mechanism to put the OSSEC key
in place?

Reply to this email directly or view it on GitHub.

@ddpbsd I think the idea is that this resolves the agent vulnerability of it trusting any system posing as a manager. Without this patch, we have to trust that ARP poisoning won't be happening on the network such that the system will send all logs to a MiM server. It's even worse if the agent has been configured to execute remote commands. Then it becomes a potentially infrastructure-wide compromise since that MiM manager can now execute commands as root on the agent systems.

Hi all,

I've pushed up another commit here: https://github.com/mweigel/ossec-hids/commit/63a061615d48710fe3e9bcde70a1119abaacfda8

This code should only be used for testing purposes currently and if anyone wants to clone it and take a look and do some testing that would be great. I have been testing it today and it seems to be working well for me. I looked at OpenSSL's "X509_check_host" function as a reference while constructing parts of this and some of the code will be similar. Not trying to pass this off as completely original. Using X509_check_host would be the better choice but that would require OpenSSL-1.0.2.

This will allow agent-auth to check the subjectAltName extensions present the certificate it receives from the manager for a match with the hostname given on the command line. If no matches are found there it'll check the common names. This differs slightly from rfc6125 but I believe it's pretty standard behaviour. The matching is always case insensitive and certificates containing wild cards are not supported yet.

This all really came about because I wanted a more automated way of provisioning OSSEC clients and when I found that ossec-authd did 90% of what I wanted, rather than inventing another solution for my particular environment I thought I would try to contribute in a small way to this project as OSSEC is a really valuable tool for me.

Closed by mistake.

Added commit: https://github.com/mweigel/ossec-hids/commit/2f6ce89902cd44f6fc20503278d7084c3425a998

This will allow agent-auth to check the IP address given on the command line with the -m option against the subjectAltName fields in the certificate presented by ossec-authd in the case where DNS is not in use.

I want to get this in but still worried about windows and unix using different code paths for ssl.... As you have stated you don't feel this is prod ready so let's take some time to review and pick a direction. @ossec should be looking at this and the other windows ssl patch.

I haven't had a lot of time to work on this over the last couple of weeks but I'll be spending some time on it this weekend. I'm pretty happy with how it's working now and it would definitely be good to get others testing it.

I've been fairly careful not to introduce anything that would break Windows compatibility further so it shouldn't be any more difficult than it was to get it building on Windows. I'll try to spend a bit of time taking a look at that as well, cheers.

Hi guys,

Another update:

1. The original agent-auth is working on Windows again. At least on Windows 7 :) I Didn't have to change much at all in the client code to get it working and it will support all the same certificate verification functionality as on Linux which is all common code. I've only tested verification of the manager's certificate so far though which works as expected.
2. More comprehensive validation of domain names presented in manager's certificate. I've added more checking that domain names are well formed and contain only valid characters.
3. Support for wildcard certificates. The wildcard will match only the left-most label in a domain name and must match the whole label.

I'm pretty happy with this code now and don't think I will add any new functionality for the time being. I'll just be testing and possibly tidying up a bit. The Windows version of agent-auth was compiled on Linux (Fedora 20) and tested on Windows 7 Home Premium 64-bit.

Let me know what you think, cheers.

Hey guys,

I've been working on this again today and testing as much as I can and I'm really happy with how it's working. I'd love to get it merged if you're happy with the implementation. I'm happy to assist with updated documentation for users as well if that would be of benefit.

On the subject of separate clients for Linux and Windows my personal preference would be to keep the existing client compatible with both platforms rather than having two clients. My main reason for this apart from the added code is that if the clients differ in their behaviour it could be confusing for users. This probably wouldn't be a big deal at the moment as the default behaviour for both clients is to perform no verification of the server's certificate. But if in future it was decided to make verification the default with the option to turn it off then having one client doing verification by default and having another client doing no verification by default could leave users with a false sense of security.

This may never happen and it's probably not too difficult to add certificate verification to the Windows client but I don't have any experience developing for Windows so I can't really say. I don't believe there will be any issues with either client interacting with the updated ossec-authd. At the moment the client here is building for Windows again and seems to be working well but I'd like to get some input from the guys who are more experienced building OSSEC.

Let me know how you'd like to proceed, cheers.

We released 2.8 and going to get this code into master ASAP so people can test. As you have done so much great work with this. I might ping you about how things are working and if others have problems to see if you can shine some insight. I am not asking you to be a maintainer (unless you want to be).

Thank you again.

Hi there,

Cool, sounds good, I'm happy to help with any issues that come up as part
of this. I have some more ideas for security and feature enhancements that
could be implemented for authd as well. Hopefully I'll have time to look at
the docs this weekend as well. Let me know how it goes, cheers.

On Fri, Jun 6, 2014 at 12:09 AM, Jeremy Rossi notifications@github.com
wrote:

We released 2.8 and going to get this code into master ASAP so people can
test. As you have done so much great work with this. I might ping you about
how things are working and if others have problems to see if you can shine
some insight. I am not asking you to be a maintainer (unless you want to
be).

Thank you again.

—
Reply to this email directly or view it on GitHub
#166 (comment).

I am testing ossec in our environment and one of the main issues we are running into is auto auth of clients. We have thousands of devices that will be connecting to ossec. The addition of agent-auth code to Windows clients is exactly what I am looking for! I am a security analyst, and don't have a ton of experience with coding per say. How can I incorporate this code into the ossec client windows binary? Thank You for your help!

It would be nice to include the ``agent-auth` in the windows agent binary releases. I assume for now to get binaries I'll need to build the windows agent from scratch?

I have a branch with windows agent auth, but noone has tested it yet. Or atleast they haven't reported back to me. I assume it's out of lack of interest https://github.com/ddpbsd/ossec-hids/tree/winauthd?files=1

@ddpbsd I'm looking into setting up a windows build env, is it basically GNUMake and gcc? It's been a while since I compiled C from source on windows platforms.

@hh You will actually be better off compiling the Windows stuff on a NIX platform. Should be able to use Make and will need to get the right MinGW packages.

Sounds like a good idea, I'd like to statically include all libraries that aren't included with windows (ssl, gz, crypto):

@ddpbsd I'm getting close, but using mingw I'm getting an error building agent_auth.exe due to a reference to win32/agent_auth.c in the Makefile which is missing from https://github.com/ddpbsd/ossec-hids/tree/winauthd/src/win32

[hh@viii src]$ git log -1
commit 55c92fe5c32967ef259f3a12e7852194dccea5ee
Merge: 79d2cb2 2684c8c
Author: ddpbsd <ddpbsd@gmail.com>
Date:   Tue Dec 22 08:03:01 2015 -0500
    Merge branch 'master' of github.com:ddpbsd/ossec-hids into winauthd

[hh@viii src]$ TARGET=winagent make
... omitting build of other binaries ....
make[1]: *** No rule to make target 'win32/agent_auth.c', needed by 'win32/agent_auth.exe'.  Stop.
make[1]: Leaving directory '/home/hh/stratalux/lifelock/misc/src/ossec-hids/src'
Makefile:617: recipe for target 'winagent' failed
make: *** [winagent] Error 2
[hh@viii src]$ find . -name \*agent_auth\*
[hh@viii src]$ git status
On branch agent_auth
Your branch is up-to-date with 'windows/winauthd'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    win32/add-localfile.exe
    win32/manage_agents.exe
    win32/os_win32ui.exe
    win32/ossec-agent-eventchannel.exe
    win32/ossec-agent.exe
    win32/ossec-rootcheck.exe
    win32/setup-iis.exe
    win32/setup-syscheck.exe
    win32/setup-windows.exe

nothing added to commit but untracked files present (use "git add" to track)

Going back to f7d93fa get's past that make error. Passing USE_OPENSSL=yes to make causes -DLIBOPENSSL_ENABLED to be used during the compile phase.

During the link step -lssl is not used though.

Here is a build via cygwin of https://github.com/ddpbsd/ossec-hids/tree/winauthd for ossec_agent.exe only.

I couldn't get the MinGW to work @awiddersheim

ossec-agent-auth-cywin.zip

includes:

agent-auth.exe wants to write a PID file somewhere.... probably to the default of /var/ossec

We should set some reasonable defaults on windows like a path relative to the binary or c:\ossec

The -D option doesn't seem to function as expected:

Looks like we need to precreate the relative var/ossec/{etc,log} directories. This probably has to do with using cygwin vs MingGW, but I can't find a working branch that'll compile agent-auth.exe with MingGW:

I was able to get the cygwin build of agent-auth.exe to work windows (to at least write out c:\Program Files\ossec-agent\var\ossec\etc\client.keys. Now I'm going to try to use the stable 2.8.3 version from http://ossec.github.io/downloads.html to actually connect back to the OSSEC server. Will probably need to move the client.keys into `c:\Program Files\ossec-agent``

Note: I had to create the directory paths for the PID file, zoneinfo, and etc for it to be able to run.

Recipe: my_ossec::_install_windows
  * directory[c:\Program Files\ossec-agent\var\ossec\var\run] action create (up to date)
  * directory[c:\Program Files\ossec-agent\usr\share\zoneinfo] action create (up to date)
  * directory[c:\Program Files\ossec-agent\var\ossec\var\run] action create (up to date)
  * directory[c:\Program Files\ossec-agent\var\ossec\etc] action create (up to date)
  * execute[get client key from ossec server] action run
    - execute "c:\Program Files\ossec-agent\bin\agent-auth.exe" -d -g Administrators -m 10.27.37.212 -p 1515 -A ossec_agent-windows -x C:\chef\cache\WIN-6K96V2GGT6P.pem -k C:\chef\cache\WIN-6K96V2GGT6P.key -v C:\chef\cache\ca.pem

Running handlers:
Running handlers complete
Chef Client finished, 2/53 resources updated in 25.858692 seconds
PS C:\Users\Administrator> type 'C:\Program Files\ossec-agent\var\ossec\etc\client.keys'
1026 ossec_agent-windows any 8d821e91a0c511541c260a04b38eb7745a0a6be9849a83efc88ec33f0b611757

Thanks for these updates. I'm hoping to dig back into it when I find some
energy and time. You've definitely given me some things to look into!
On Jan 20, 2016 2:45 PM, "Hippie Hacker" notifications@github.com wrote:

I was able to get the cygwin build of agent-auth.exe to work windows (to
at least write out c:\Program Files\ossec-agent\var\ossec\etc\client.keys.
Now I'm going to try to use the stable 2.8.3 version from
http://ossec.github.io/downloads.html to actually connect back to the
OSSEC server. Will probably need to move the client.keys into c:\Program
Files\ossec-agent`

Note: I had to create the directory paths for the PID file, zoneinfo, and
etc for it to be able to run.

Recipe: my_ossec::_install_windows

• directory[c:\Program Files\ossec-agent\var\ossec\var\run] action create (up to date)
• directory[c:\Program Files\ossec-agent\usr\share\zoneinfo] action create (up to date)
• directory[c:\Program Files\ossec-agent\var\ossec\var\run] action create (up to date)
• directory[c:\Program Files\ossec-agent\var\ossec\etc] action create (up to date)
• execute[get client key from ossec server] action run
  • execute "c:\Program Files\ossec-agent\bin\agent-auth.exe" -d -g Administrators -m 10.27.37.212 -p 1515 -A ossec_agent-windows -x C:\chef\cache\WIN-6K96V2GGT6P.pem -k C:\chef\cache\WIN-6K96V2GGT6P.key -v C:\chef\cache\ca.pem

Running handlers:
Running handlers complete
Chef Client finished, 2/53 resources updated in 25.858692 seconds
PS C:\Users\Administrator> type 'C:\Program Files\ossec-agent\var\ossec\etc\client.keys'
1026 ossec_agent-windows any 8d821e91a0c511541c260a04b38eb7745a0a6be9849a83efc88ec33f0b611757

—
Reply to this email directly or view it on GitHub
#166 (comment).