search

ossec / ossec-hids

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.
http://www.ossec.net
Other
4.5k stars 1.04k forks source link

2.9 - networking broken on RHEL7.3 due to getaddrinfo/ipv6 changes #1145

Open dwendt opened 7 years ago

dwendt commented 7 years ago

Upgrading an RHEL environment to 2.9, this definition breaks getaddrinfo.

https://github.com/ossec/ossec-hids/blob/ef46a72250c84c068751a0161d8b5fb009fb7699/src/os_net/os_net.h#L22

It makes the addrinfo struct on line 52 have some options that make getaddrinfo fail. When the macro is undefined, it uses the other options which work perfectly fine. Not sure what those options are for (ipv6?) to begin with or I'd provide a patch suggestion....

Red Hat Enterprise Linux Server release 7.3 (Maipo)
Linux xxxxxxxxxxx 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 10:03:19 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

This is an ipv4 server, to be clear. <remote> only contains <connection>secure</connection>.

mkvocka commented 7 years ago

I had a similar issue with RHEL 6 that had no IPV6 support - getaddrinfo did not work. In src/os_net/os_net.c I used hints.ai_family = AF_INET instead of AF_INET6 or AF_UNSPEC to get it working.

ddpbsd commented 7 years ago

Did you remove/disable ipv6 support?

mkvocka commented 7 years ago

If the question was to me - yes I did. OSSEC syscheckd is commonly used in environments where PCI DSS compliance must be met. PCI DSS also requires disabling unused services, IPv6 in this case.

dwendt commented 7 years ago

@ddpbsd welp, yep, ipv6 was disabled.

# sysctl -p
net.ipv6.conf.all.disable_ipv6 = 1

what would a good fix for this look like? if getaddrinfo fails for AF_INET6, attempt again with AF_INET?

ddpbsd commented 7 years ago

Does PCI DSS actually define IPv6 as a service? That's crazy. If anyone has a suggestion on how to change things so that these niche systems can be better supported without hampering modern systems, I'm all ears.

aquerubin commented 7 years ago

Not specifically but it does say disable unused services. Security admins have been interpreting that to mean disable IPv6 if it hasn't been deployed. DSS also mandates the use of NAT. That's a non-starter if IPv6 is in use. The DSS has not really kept up with the times.

I've been wondering that if instead of breaking the network stack by disabling IPv6 completely, just disable it on individual physical interfaces only. That reduces the attack surface until IPv6 is actually deployed. I've not had a chance to test how well this would work in practice.

Tony

On Jul 15, 2017, at 09:49, Dan Parriott notifications@github.com wrote:

Does PCI DSS actually define IPv6 as a service? That's crazy. If anyone has a suggestion on how to change things so that these niche systems can be better supported without hampering modern systems, I'm all ears.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

ddpbsd commented 7 years ago

And that would make more sense to me, as well as possibly blocking IPv6 at the host's firewall.

ghost commented 7 years ago

I'm sure it's a complex debate, but from my perspective, general purpose software that doesn't run properly on a system without IPv6 support is broken. Especially if it ran fine previously.

I'm in a similar situation as above; though not PCI DSS, some of my environments are nonetheless required to disable IPv6. Blocking it at the host firewall or not configuring it at an interface level isn't good enough. The requirements are written with the specific and deliberate intent to disable IPv6 entirely, using any and all reasonably standard methods, to minimize vulnerability surface area and avoid accidental exposure due to improperly implemented partial solutions.

Taking RHEL6 as an example, that means:

We are required to run frequent audits for all of those. Whether or not such requirements actually make sense is, unfortunately, irrelevant. We're still stuck with them.

It sure would be nice if I didn't have to maintain yet another package because of a patch that changes literally one line of code. :)

ddpbsd commented 7 years ago

And I personally think any system that can't handle a minimal IPv6ness is broken. But whatever, we'll look at removing ipv6 support in 3.1.

ddpbsd commented 7 years ago

I guess we could do something like:

diff --git a/src/os_net/os_net.c b/src/os_net/os_net.c
index 4f5682f8..79619e04 100644
--- a/src/os_net/os_net.c
+++ b/src/os_net/os_net.c
@@ -49,7 +49,11 @@ int OS_Bindport(char *_port, unsigned int _proto, const char *_ip)

     memset(&hints, 0, sizeof(struct addrinfo));
 #ifdef AI_V4MAPPED
+#ifdef LEGACY_V4
+    hints.ai_family = AF_INET
+#else
     hints.ai_family = AF_INET6;    /* Allow IPv4 and IPv6 */
+#endif
     hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_V4MAPPED;
 #else
     /* Certain *BSD OS (eg. OpenBSD) do not allow binding to a

Then allow a user to set LEGACY_V4. Thoughts?

dwendt commented 7 years ago

ossec should be functional on both systems without needing a recompile, why not attempt both and take the first successful one (this is the same behavior it currently implements with socket+bind, seen right after getaddrinfo)

ddpbsd commented 7 years ago

Like this?

diff --git src/os_net/os_net.c src/os_net/os_net.c
index 4f5682f8..7137581d 100644
--- src/os_net/os_net.c
+++ src/os_net/os_net.c
@@ -68,6 +68,10 @@ int OS_Bindport(char *_port, unsigned int _proto, const char *_ip)
     }

     s = getaddrinfo(_ip, _port, &hints, &result);
+    if(s == EAI_FAMILY) {
+        hints.ai_family = AF_INET;
+        s = getaddrinfo(_ip, _port, &hints, &result);
+    }
     if (s != 0) {
         verbose("getaddrinfo: %s", gai_strerror(s));
         return(OS_INVALID);
aquerubin commented 7 years ago

On Wed, 20 Sep 2017, Ditmar Wendt wrote:

ossec should be functional on both systems without needing a recompile, why not attempt both and take the first successful one (this is the same behavior it currently implements with socket+bind, seen right after getaddrinfo)

Happy Eyeballs approach might be worth implementing. Will try to find some spare cycles.

-- Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com

aquerubin commented 7 years ago

On Wed, 20 Sep 2017, Dan Parriott wrote:

Like this?

diff --git src/os_net/os_net.c src/os_net/os_net.c
index 4f5682f8..7137581d 100644
--- src/os_net/os_net.c
+++ src/os_net/os_net.c
@@ -68,6 +68,10 @@ int OS_Bindport(char *_port, unsigned int _proto, const char *_ip)
    }

    s = getaddrinfo(_ip, _port, &hints, &result);
+    if(s == EAI_FAMILY) {
+        hints.ai_family = AF_INET;
+        s = getaddrinfo(_ip, _port, &hints, &result);
+    }
    if (s != 0) {
        verbose("getaddrinfo: %s", gai_strerror(s));
        return(OS_INVALID);

That should work too.

-- Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com

ddpbsd commented 7 years ago

I probably won't be able to submit a pull request for a few days, so feel free to submit something. If the no-ipv6 folks could test it out, I'd appreciate it.

caess commented 7 years ago

On a RHEL 6 server with IPv6 disabled, getaddrinfo() returns EAI_NONAME, not EAI_FAMILY. Changing the if statement to also handle this case worked for me:

--- a/src/os_net/os_net.c
+++ b/src/os_net/os_net.c
@@ -68,6 +68,11 @@ int OS_Bindport(char *_port, unsigned int _proto, const char *_ip)
     }

     s = getaddrinfo(_ip, _port, &hints, &result);
+    /* Try to support legacy ipv4 only hosts */
+    if ((s == EAI_FAMILY) || (s == EAI_NONAME)) {
+        hints.ai_family = AF_INET;
+        s = getaddrinfo(_ip, _port, &hints, &result);
+    }
     if (s != 0) {
         verbose("getaddrinfo: %s", gai_strerror(s));
         return(OS_INVALID);
ddpbsd commented 7 years ago

@caess Thank you! I basically guessed as to what the correct answer was there. I'll make that change in pull request #1259 immediately.

ddpbsd commented 7 years ago

Pull request updated. Thanks again!

marcRBD commented 7 years ago

Hi dan it impact only the server side ? as i was planning to upgrade to 2.9.2 (from below 2.9) In my test i didn't see a problem with agent on redhat like. If we only use ip adress and no hostname between agent and server ? Thanks Best regards

ddpbsd commented 7 years ago

@marcRBD I don't know. I can't test it.

syzop commented 6 years ago

Just to confirm I had the same issue with v2.9.3..

2018/04/30 12:23:28 ossec-remoted(1206): ERROR: Unable to Bind port '1514'

.. and that applying e1aa8f7d077b5ace4c1b2f94e21c22ab5e5cc434 and 321d2a63898671a1e2ce5ef2fd141a8a65a5be15 fixed it.

Since it has been reported a number of times. Here in #1145 but also in #917, #1061 and possibly #1063.. shouldn't a new release be published? Even if only with those two small changes? It's a shame the issue has been fixed 7 months ago in git but is not in a released version (2.9.3 at the time of writing).

phamvuong commented 6 years ago

The new release 2.9.4 has included the patch for IPv6. However, there is new issue with DNS resolve 2018/07/18 04:15:44 ossec-agentd: INFO: Trying to connect to server ***, port 1514. 2018/07/18 04:15:44 getaddrinfo: Name or service not known 2018/07/18 04:15:44 ossec-agentd(1216): ERROR: Unable to connect to '***'.

Copy/link file /etc/resolve to /var/ossec/etc and mount bind the whole library in /usr/lib64 to /var/ossec/lib64 solve the issue (each udp request form each client will hit our dns server and avoid our cache via nscd).

I have tried to writing C program to use getaddrinfo and chroot to /var/ossec environment. Below is different output for each cases

And here are the library needed by ossec ldd /var/ossec/bin/client-agentd linux-vdso.so.1 => (0x00007ffcf5954000) libm.so.6 => /lib64/libm.so.6 (0x00007f09ae7bc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f09ae5a0000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f09ae32d000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f09adecc000) libc.so.6 => /lib64/libc.so.6 (0x00007f09adb09000) /lib64/ld-linux-x86-64.so.2 (0x0000563024dbe000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f09ad8bb000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f09ad5d3000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f09ad3cf000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f09ad19b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f09acf97000) libz.so.1 => /lib64/libz.so.1 (0x00007f09acd81000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f09acb72000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f09ac96e000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f09ac754000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f09ac52c000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f09ac2ca000)

So the problem is now probably caused by lacking of library in chroot environment

AlexisLessard commented 6 years ago

FYI, same issue here with ossec 2.9.4 on Centos 7.5 using the atomic yum packages. I need some more torough testing, but I seems to get the same error with 3.0,.0. Those messages appear in ossec.log:

2018/08/13 12:57:10 getaddrinfo: System error  
018/08/13 12:57:10 ossec-maild(1223): ERROR: Error Sending email to smtp.******.ca (smtp server)

Email notifications aren't being sent, but the smtp serveur is accessible. Using the mailx command, I can send an email like ossec would. But ossec itself can't send anything. Oh, and deactivating ipv6 hasnt done anything either.

jllynch commented 5 years ago

I'm getting the same issue on Centos 7.5 with latest Ossec 3.1; 2018/11/15 17:47:04 getaddrinfo: System error 2018/11/15 17:47:44 ossec-maild(1261): ERROR: Waiting for child process. (status: 6). 2018/11/15 17:47:44 ossec-maild(1223): ERROR: Error Sending email to localhost (smtp server) Any ideas?

AlexisLessard commented 5 years ago

@jllynch We resolved this issue by copying the /etc/resolv.conf file to the etc folder of the ossec installation. The chroot seemed to affect the name resolution. The problem appeared after an os update. Try this and restart ossec, see if the messages disapear.

ddpbsd commented 5 years ago

I just did the same thing (copied the /etc/resolv.conf to /var/ossec/etc) and it worked for me. It did not work before I copied the file.

jllynch commented 5 years ago

Excellent that worked! Thanks so much.

pcrozer commented 5 years ago

Hi - is this still an open issue? I'm just trying to test out OSSEC and have installed a "local" instance (3.1.0) on a Centos 7 VM and I'm getting: 2019/01/08 11:36:50 getaddrinfo: System error 2019/01/08 11:36:50 ossec-maild(1223): ERROR: Error Sending email to mail.*****.com (smtp server)

I've copied /etc/resolv.conf to /var/ossec/etc and restarted but still seeing the error above, is there anything else I can try? Thanks!

AlexisLessard commented 5 years ago

@pcrozer is the resolv.conf file empty? And is the smtp server accessible from your ossec server? Can you send a test email? Those might be stupid questions, but I often find myself trying to solve complex problems without trying the first solutions. If everything works, the problem should be Ossec, in which case, I wouldn't know how to solve it....

pcrozer commented 5 years ago

@AlexisLessard thanks for your response - I have to confess it was my own failure to make sense of what @phamvuong had said above - after doing mount --bind /usr/lib64 /var/ossec/lib64 all works now.

ddpbsd commented 5 years ago

So probably back to the whole chroot thing. I have a couple of ideas of how to make that less of an impact, but I need to make the time to work on them.

tabmcleo commented 5 years ago

@ddpbsd was wondering what is the status of this issue and when we might expect a resolution?

I've run up against it in a lab setting with a CentOS 7.6.1810 VM running the OSSEC 3.2 server and a CentOS 7.6.1810 VM running the OSSEC 3.2 agent. Both VMs run in Oracle's VirtualBox on a physical host running openSuSE Leap 15.0.

On the server, I noticed "getaddrinfo: System error" messages. I copied /etc/resolv.conf to /opt/ossec/3.2/etc and mounted /usr/lib64 on /opt/ossec/3.2/lib64 as suggested by @phamvuong . That seemed to resolve the issue on the server side.

While that's workable in production for the server, the clients are another question. I am experimenting with the OSSEC agent. Is it necessary to copy resolv.conf and mount /usr/lib64 on the agents as well?

Thanks for your efforts on this issue.

tabmcleo commented 5 years ago

@ddpbsd this is a follow-up to my last entry (above). I started over by undoing all the changes on the OSSEC server (i.e. I deleted /opt/ossec/3.2/etc/resolv.conf and unmounted /opt/ossec/3.2/lib64). I also rebooted the VM that the server resides on. This time, the OSSEC server started fine without any mention of getaddrinfo in the OSSEC log.

I ensured that port 1514 UDP was open on the server.

On the agent side, I did all of the above, with the exception of opening port 1514 UDP. When I started the OSSEC agent, I noticed a lot of these messages in the OSSEC log:

2019/02/28 18:27:03 ossec-execd: INFO: Started (pid: 3398). 2019/02/28 18:27:03 ossec-agentd: INFO: Using notify time: 600 and max time to reconnect: 1800 2019/02/28 18:27:03 ossec-syscheckd(1702): INFO: No directory provided for syscheck to monitor. 2019/02/28 18:27:03 ossec-syscheckd: WARN: Syscheck disabled. 2019/02/28 18:27:03 rootcheck: Rootcheck disabled. Exiting. 2019/02/28 18:27:03 ossec-syscheckd: WARN: Rootcheck module disabled. 2019/02/28 18:27:10 ossec-syscheckd(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:10 ossec-syscheckd(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:12 ossec-logcollector(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:12 ossec-logcollector(1211): ERROR: Unable to access queue: '/opt/ossec/3.2/queue/ossec/queue'. Giving up.. 2019/02/28 18:27:18 ossec-syscheckd(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:18 ossec-syscheckd(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:31 ossec-syscheckd(1210): ERROR: Queue '/opt/ossec/3.2/queue/ossec/queue' not accessible: 'Connection refused'. 2019/02/28 18:27:31 ossec-syscheckd(1211): ERROR: Unable to access queue: '/opt/ossec/3.2/queue/ossec/queue'. Giving up.. 2019/02/28 18:28:18 ossec-execd(1314): INFO: Shutdown received. Deleting responses. 2019/02/28 18:28:18 ossec-execd(1225): INFO: SIGNAL [(15)-(Terminated)] Received. Exit Cleaning...

I shutdown the OSSEC agent and copied /etc/resolv.conf to /opt/ossec/3.2/etc and then started the OSSEC agent. The log revealed this:

2019/02/28 18:28:40 ossec-execd: INFO: Started (pid: 3490). 2019/02/28 18:28:40 ossec-agentd: INFO: Using notify time: 600 and max time to reconnect: 1800 2019/02/28 18:28:40 ossec-syscheckd(1702): INFO: No directory provided for syscheck to monitor. 2019/02/28 18:28:40 ossec-syscheckd: WARN: Syscheck disabled. 2019/02/28 18:28:40 rootcheck: Rootcheck disabled. Exiting. 2019/02/28 18:28:40 ossec-syscheckd: WARN: Rootcheck module disabled. 2019/02/28 18:28:44 ossec-syscheckd: INFO: Started (pid: 3501). 2019/02/28 18:28:46 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages'. 2019/02/28 18:28:46 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/secure'. 2019/02/28 18:28:46 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/maillog'. 2019/02/28 18:28:46 ossec-logcollector: INFO: Monitoring output of command(360): df -P 2019/02/28 18:28:46 ossec-logcollector: INFO: Monitoring full output of command(360): netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| ::1)' | sort 2019/02/28 18:28:46 ossec-logcollector: INFO: Monitoring full output of command(360): last -n 5 2019/02/28 18:28:46 ossec-logcollector: INFO: Started (pid: 3498). 2019/02/28 18:30:26 ossec-execd: INFO: Active response command not present: '/opt/ossec/3.2/active-response/bin/restart-ossec.cmd'. Not using it on this system.

Then, I went to the OSSEC server and manually initiated a firewall block:

./agent_control -b www.xxx.yyy.zzz -f firewall-drop600 -u 001

where I've redacted the IP address and 001 is the ID of the agent. It seemed to work perfectly. I checked the active response log on the agent and the event was logged correctly. iptables showed that the block had been inserted into the firewall on the agent.

So, out of all the remedies mentioned in this issue, the only one that seemed necessary was to copy /etc/resolv.conf to /opt/ossec/3.2/etc.

Does this jive with your understanding, or am I missing something?

tabmcleo commented 5 years ago

@ddpbsd The chroot thing has reared its head again with OSSEC 3.2 agents on openSuSE Leap 15.0 machines talking to an OSSEC 3.2 server on RHE 7.6.

After running "strace -d -d -d -f ./ossec-agentd" and inspecting the results, it was necessary to:

cp /etc/hosts /opt/ossec/3.2/etc cp /etc/resolv.conf /opt/ossec/3.2/etc cp /etc/ld.so.cache /opt/ossec/3.2/etc mount --bind /usr/lib64 /opt/ossec/3.2/usr/lib64 mount --bind /lib64 /opt/ossec/3.2/lib64

in order to get the OSSEC agent to start and connect to the OSSEC server.

Also, the permissions on the ossec.log file are not created correctly in order to let the OSSEC agent write to the file. Originally the permissions were 644 with the file owned by root and the group os-sec (our OSSEC uids and gid are in LDAP; the hyphens are necessary so as to not conflict with user accounts in LDAP). Changing the permission to 664 resolves the problem.

Was wondering if you have had time to work on these problems or an ETA on when it might be fixed?

Thanks,

tabmcleo commented 5 years ago

@ddpbsd Do you want me to open a separate issue for the chroot problem?

ddpbsd commented 5 years ago

@tabmcleo I think this issue is fine. It's got most of the necessary info. But if you feel strongly about it, another ticket is ok too.

I don't have an ETA on what I'm working on, I'm slow. I'll try to get a preview up soonish.

tabmcleo commented 5 years ago

@ddpbsd Thanks for the update. I will NOT open a new ticket.

tabmcleo commented 5 years ago

@ddpbsd Don't know if it helps, but the gcc version on openSuSE Leap 15.0 is

gcc version 7.3.1 20180323 [gcc-7-branch revision 258812] (SUSE Linux)

ddpbsd commented 5 years ago

@tabmcleo I installed an openSUSE Leap 15.0 system, did a checkout of master, and installed OSSEC as an agent. I'm using a hostname instead of IP for the server definition.

<server-hostname>rossak.example.com</server-hostname>

I did not copy the resolv.conf to/var/ossec/etc`. It connected just fine, no changes necessary. So I'm missing something from my setup that isn't allowing me to reproduce the issue.

EDIT: I disabled ipv6 and I can reproduce the error.

tabmcleo commented 5 years ago

@ddpbsd Confirmed: IPV6 is disabled on our openSuSE Leap 15.0 host as well:

lin50:/etc # cat sysctl.conf

#

/etc/sysctl.conf is meant for local sysctl settings

#

sysctl reads settings from the following locations:

/boot/sysctl.conf-

/lib/sysctl.d/*.conf

/usr/lib/sysctl.d/*.conf

/usr/local/lib/sysctl.d/*.conf

/etc/sysctl.d/*.conf

/run/sysctl.d/*.conf

/etc/sysctl.conf

#

To disable or override a distribution provided file just place a

file with the same name in /etc/sysctl.d/

#

See sysctl.conf(5), sysctl.d(5) and sysctl(8) for more information

#

net.ipv4.ip_forward = 0 net.ipv6.conf.all.forwarding = 0

net.ipv6.conf.all.disable_ipv6 = 1

Next steps? Do you require any further information from me?

ddpbsd commented 5 years ago

@tabmcleo No, thank you. After I posted I realized that disabling ipv6 might be the key. , so I'm able to reproduce it now. Getting this to work with agentd is a lot more tedious than it was for maild.

tabmcleo commented 5 years ago

@ddpbsd Another issue has cropped up in testing. It may be related to the issues you and I have been discussing. If not, let me know and I'll open up a different issue.

In short, if the location for the active response on the ossec server (RHE 7.6 and OSSEC 3.2) is set to local, the active response fires on the ossec client (openSuSE Leap 15.0 and OSSEC 3.2) where the intrusion occurred. However, if the location for the active response on the ossec server is set to all, the active response never fires on the ossec server nor the ossec client. However, we receive email alerts as if the active response fired.

I've tried the same test on an ossec server (CentOS 7.6 and OSSEC 3.2) with an ossec agent (CentOS 7.6 and OSSEC 3.2) and the location for the active response on the ossec server set to all. In that case the active response fires on the agent, where the intrusion occurred, but not the server. This seems consistent with our current production OSSEC 2.4 installation where all means everywhere but the server. We noted that bug when we installed OSSEC 2.4 about 10 years ago.

Of immediate concern, though, is the case where the ossec agent is running on openSuSE, the location of the active response on the server is set to all but no active response is triggered on the agent.

ddpbsd commented 5 years ago

@tabmcleo I'll have to test it out. I don't think I'm currently running AR on any Linux hosts. My prototype for fixing agentd is going well though, so far it's working. I need to clean it up a bunch and do some more testing (AR apparently) before submitting a PR.

tabmcleo commented 5 years ago

@ddpbsd Thanks for the update. I'll try to debug the "all" vs "local" problem some more to see if I can give you any more clues.

tabmcleo commented 5 years ago

@ddpbsd Here are the results from more detailed testing.

Scenarios 1-7: OSSEC 3.2 server on RHEL 7.6 (hids01.cs.ubc.ca) with IPV6 enabled. OSSEC 3.2 agent on openSuSE Leap 15.0 (lin50.students.cs.ubc.ca). Custom active response: unblock-firewall-drop.sh where ACTION is hardcoded as "delete" within the script. I've attached all the relevant files.

Of most immediate concern are scenarios 2 (vital) and 7. Scenario 4 can be worked around by using scenario 5. These scenarios were done in the sequence indicated.

Do you think I should disable IPV6 on the OSSEC server?

  1. Worked as expected On ossec server reverted to original ossec.conf installed when ossec was installed. Location for both firewall-drop and host-deny ARs is "local". Attacked ossec agent using ssh and invalid passwords. Both ARs worked on the ossec agent

  2. Did not work as expected On ossec server changed location for both firewall-drop and host-deny ARs to "all". Attacked ossec agent using ssh and invalid passwords. ARs did not fire on ossec server or agent. However, email alerts were received

  3. Worked as expected On ossec server changed location for both firewall-drop and host-deny ARs to "server". Attacked ossec agent using ssh and invalid passwords. Both ARs fired on server only. E-mail alerts were received

  4. Did not work as expected On ossec server changed location for both firewall-drop and host-deny ARs to "local". Included yes XML element for host-deny AR. Attacked ossec agent using ssh and invalid passwords. ARs did not fire on ossec server or agent. However, e-mail alerts were sent

  5. Worked as expected On ossec server commented out the host-deny AR rather than using the yes XML element. Attacked ossec agent using ssh and invalid passwords. AR fired on ossec agent and e-mail alerts received

  6. Worked as expected On ossec server reverted to original ossec.conf installed when ossec was installed. Location for both firewall-drop and host-deny ARs is "local". Commented out the host-deny AR. Added my own command and AR for clearing an accidental block. Attacked ossec agent using ssh and invalid passwords. AR fired on ossec agent and e-mail alert received. Successfully cleared block using "./agent_control -b 142.103.5.28 -f unblock-firewall-drop0 -u 001"

  7. Did not work as expected On ossec server added firewall-drop AR where location was specified as "server". Left original firewall-drop AR with location specified as "local". The host-deny AR was still commented out. My own command and AR for clearing an accidental block was left in place. Attacked ossec agent using ssh and invalid passwords. AR fired on ossec agent, ossec server and e-mail alerts received Successfully cleared block on ossec agent running"./agent_control -b 142.103.5.28 -f unblock-firewall-drop0 -u 001" on ossec server. However, could not clear the block on the ossec server running /agent_control -b 142.103.5.28 -f unblock-firewall-drop0 -u 000" on the ossec server. It appears that agent_control cannot initiate an active response on the ossec server itself

Config and script files.zip

tabmcleo commented 5 years ago

@ddpbsd Sorry, wording for scenario was bad. Here's the corrected version:

  1. Did not work as expected On ossec server changed location for both firewall-drop and host-deny ARs to "local". Included XML disabled element for host-deny AR set to yes. Attacked ossec agent using ssh and invalid passwords. ARs did not fire on ossec server or agent. However, e-mail alerts were sent
tabmcleo commented 5 years ago

@ddpbsd Regarding scenario 2, the problem was worked around by disabling IPV6 on the OSSEC server. Once that was done, any AR whose location was "all" fired on the agent when an intrusion was detected.

tabmcleo commented 5 years ago

@ddpbsd Ignore my comment about scenario 2 being resolved by disabling IPV6 on the OSSEC server. That was a mistake in my testing scenario.

I started again with the original ossec.conf on the ossec server that was installed when ossec was installed.

There were two ARs, host-deny and firewall-drop. The location on both was local. I knew that worked. I changed them to all. That did not work.

I commented out the host-deny AR leaving the firewall-drop AR set to all. That did not work.

I added a firewall-drop AR set to server as well as the firewall-drop AR set to all. That worked.

In conclusion, for scenario 2: I commented out the host-deny AR. I set the original firewall-drop AR to all and added another firewall-drop AR to server. IPV6 was enabled on the OSSEC server while it was disabled on the OSSEC agent. That combination of things worked.

We don't use the host-deny AR because it interferes with our management of /etc/host.deny via cfEngine.

However, the fact that you need two firewall-drop ARs, one set to all and one set to server, is strange. It works for us because that's what we want. But the fact that a single firewall-drop AR, set to all, doesn't work without the additional firewall-drop AR, set to server, is weird.

Hoping that you can reproduce this.

ddpbsd commented 5 years ago

Setting the location to all has never included the server, so that's not a surprise.

tabmcleo commented 5 years ago

@ddpbsd The documentation should be updated then to include that fact.

However, don't you agree that having to include two firewall-drop ARs, one set to ALL and the other to SERVER is a bit odd in order for the AR to fire on the OSSEC agent? I would have thought that only a single firewall-drop AR set to all would be sufficient for the AR to fire on the OSSEC agent.