[ossec-list] Re: Active response responding to other agent's alerts
On Friday, November 10, 2017 at 3:00:36 PM UTC-5, Josmell Chavarri wrote: > > Hi, can you help me with a problem? > > I have a ossec-wazuh Server with 20 agents connected with active response > for agent id 001. > > > Ossec.conf --- the server > > > > firewall-drop > defined-agent > 001 > 8 > 600 > > You specified a response location of 'defined-agent' and the agent id of '001', so yes, this response will trigger *on* agent 001, regardless of which agent generated the alert. Working as written, if not as intended. A location of 'local' would cause the ip to be blocked on the agent that the IP contacted. A location of 'server' would cause the server to drop the IP, regardless of which agent was contacted. 'all' would cause all active agents to drop the IP if any agent generates the alert. Someone please correct me if I'm wrong, I haven't turned on active-response at my site yet-- primarily because it would be really helpful if I could set a location of "defined-group", and allow me to specify a group of servers that that response would run on. Perhaps for 3.x? Looking at the examples in the documentation, it's a bit ambiguous, and I can see how you misinterpreted it. -- --- 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] mariadb monitoring?
Link to the MariaDB audit plugin format: https://mariadb.com/kb/en/mariadb/about-the-mariadb-audit-plugin/#audit-log-format syslog format: [timestamp][syslog_host][syslog_ident]:[syslog_info][serverhost],[username],[host], [connectionid],[queryid],[operation],[database],[object],[retcode] We're using syslog, since it allows us to easily forward the logs to our central logging server for archiving. And here's a small sample of log files: May 23 14:40:00 mysql09a mysql-server_auditing: mysql09a.local,root,MYSQLADM.local,725989,179577437,QUERY,,'DROP DATABASE `ese_adherence_s`',0 May 24 10:22:21 mysql09a mysql-server_auditing: mysql09a.local,ahc_shwb01_t,10.15.190.182,840046,210662172,QUERY,`ahc_shwb01_t`,'CREATE TABLE `zipcodes` ( `zip` varchar(16) NOT NULL DEFAULT \'0\' COMMENT \'Postal / ZIP code.\', `city` varchar(30) NOT NULL DEFAULT \'\' COMMENT \'City.\', `state` varchar(30) NOT NULL DEFAULT \'\' COMMENT \'Province / State.\', `latitude`',0 May 24 10:22:21 mysql09a mysql-server_auditing: mysql09a.local,ahc_shwb01_t,10.15.190.182,840046,210662174,QUERY,`ahc_shwb01_t`,'/*!4 ALTER TABLE `zipcodes` DISABLE KEYS */',0 May 24 11:51:30 mysql09a mysql-server_auditing: mysql09a.local,ahc_shwb01_t,ahc-web29d.local,849705,0,CONNECT,ahc_shwb01_t,,0 May 24 11:51:30 mysql09a mysql-server_auditing: mysql09a.local,ahc_shwb01_t,ahc-web29d.local,849705,0,DISCONNECT,ahc_shwb01_t,,0 May 24 12:01:12 mysql09a mysql-server_auditing: mysql09a.local,,AHC-GSMPX11.local,850526,0,FAILED_CONNECT,,,1158 The 'mysql-server_auditing' is a user-configurable option (I took the default). I can provide a larger sample of logs if anyone wants. -- --- 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] mariadb monitoring?
As the default audit plugins for MySQL are somewhat horrific (XML is not a log format), and the log syntax for MySQL is multi-line, I've been looking for other options. The MariaDB audit plugin so far looks very nice-- It's highly tunable in terms of what it can report and it plays nice with syslog. And since it works with the API, it plugs nicely into not just MariaDB, but MySQL 5.6 and 5.7. Has anyone written OSSEC rulesets that parse the logs from the MariaDB audit plugin? Failed login attempts are easy, but more devious things like rights changes and schema changes would be nice to track as well. -- --- 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] Re: syscheckd causing soft lockups
Upgrading has not solved the problem.
Still appears to be some form of port / bind issue based on the backtrace.
To obfuscate things, this was my ossec master (wazuh docker image), so it
was running in a docker container, on a virtual machine under VMWare.
Nothing complicated there, right?
I'd love to hear any suggestions on where to look next to track down this
problem. I can (apparently) get around it by disabling rootcheck, but
since that's one of the key features of ossec I really want for security,
it's not a very good solution.
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s!
[ossec-syscheckd:16223]
Modules linked in: xt_nat veth binfmt_misc ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 xt_addrtyp
e xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc
iptable_filter vmw_vsock_vmci_transport vsock btrfs zlib_deflate raid6_pq
xor intel_p
owerclamp coretemp iosf_mbi crc32_pclmul ghash_clmulni_intel ppdev
aesni_intel lrw gf128mul glue_helper vmw_balloon ablk_helper cryptd pcspkr
sg vmw
_vmci i2c_piix4 shpchp parport_pc parport nfsd auth_rpcgss nfs_acl lockd
grace sunrpc ip_tables ext4 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi
sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common
crc32c_intel vmwgfx drm_kms_helper ata_piix syscopyarea serio_raw
sysfillrect
sysimgblt fb_sys_fops ttm vmxnet3 drm libata vmw_pvscsi
i2c_core floppy fjes dm_mirror dm_region_hash dm_log dm_mod
CPU: 2 PID: 16223 Comm: ossec-syscheckd Not tainted
3.10.0-514.10.2.el7.x86_64 #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform, BIOS 6.00 09/21/2015
task: 88000593ce70 ti: 8800130ec000 task.ti: 8800130ec000
RIP: 0010:[] []
_raw_spin_lock+0x32/0x50
RSP: 0018:8800130efde0 EFLAGS: 0203
RAX: 411c RBX: 0020 RCX: bb00
RDX: 384c RSI: 384c RDI: c900016fe4f0
RBP: 8800130efde0 R08: 8800b7aa9380 R09: c900016fe4f0
R10: 0008 R11: 0206 R12: c900016fe3e0
R13: 88013ae99a80 R14: 0246 R15: 8800130efd78
FS: 7efe439a5740() GS:88013ae8() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0063e000 CR3: 13e8c000 CR4: 000407e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Stack:
8800130efe68 815bc2b5 0005811de175 8800b8993640
81f96140
c900016fe4f0 0c01
Call Trace:
[] inet_csk_get_port+0x385/0x5c0
[] inet_bind+0x14c/0x200
[] SYSC_bind+0xe0/0x120
[] ? __secure_computing+0x73/0x240
[] ? __audit_syscall_exit+0x1e6/0x280
[] ? __audit_syscall_entry+0xb4/0x110
[] ? syscall_trace_enter+0x173/0x220
[] SyS_bind+0xe/0x10
[] tracesys+0xdd/0xe2
Code: 00 02 00 f0 0f c1 07 89 c2 c1 ea 10 66 39 c2 75 01 c3 55 83 e2 fe 0f
b7 f2 48 89 e5 b8 00 80 00 00 eb 0d 66 0f 1f 44 00 00 f3 90 <83> e8 01 74
0a 0f b7 0f 66 39 ca 75 f1 5d c3 66 66 66 90 66 66
--
---
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: Implementing ossec-local at scale in Docker containers
Running the ossec server in a docker container, makes sense, and I run the Wazuh fork of ossec in their provided container with logstash / kibana4. Running ossec agent in a container makes no sense to me. I would suggest instead that you use the docker logging driver to reroute stdout from your containers to syslog, and run ossec agent on your docker host, if you want to monitor your containers. Regardless, running the agent within a container will make it highly problematic to monitor the underlying host. -- --- 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] Re: syscheckd causing soft lockups
to follow up to my own post-- First, the problem was indeed happening during ossec-rootcheck, but I was unable to determine what was failing. Secondly, the affected servers all were at one time or another, exporting a CIFS or NFS share. Disabling the share didn't prevent ossec-rootcheck from crashing. Reading the docs on 2.9.0, I thought the "skip_nfs" option might be helpful, so I upgraded-- but the problem went away before I enabled skip_nfs. So upgrading seems to have solved the problem, but I don't know why. -- --- 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: syscheckd causing soft lockups
Followup. ossec-syscheckd appears to be doing some bind operation:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(12310),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
close(6) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(12311),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
close(6) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(12312),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
close(6) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(12313),
sin_addr=inet_addr("0.0.0.0")}, 16
2017 Mar 1 10:27:58 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:19286]
2017 Mar 1 10:28:26 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:19286]
2017 Mar 1 10:28:58 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:19286]
2017 Mar 1 10:29:26 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:19286]
2017 Mar 1 10:29:54 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:19286]
My guess is that it's trying to bind, running out of available sockets, and
waiting until a socket frees up (or forever, whichever comes first).
Why would syscheckd be attempting to bind to 0.0.0.0, however?
--
---
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] syscheckd causing soft lockups
Was running wazuh 2.8.1 agent on "most" systems, with the wazuh ossec
docker container for a master server.
Upgraded to 2.8.3 to try to resolve this problem, with no luck.
Out of about 160 machines, 4-5 of them will reliably wedge themselves after
some amount of time with messages akin to:
2017 Feb 28 15:35:34 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:12608]
2017 Feb 28 15:36:02 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 22s! [ossec-syscheckd:12608]
2017 Feb 28 15:36:34 NMI watchdog: BUG: soft lockup - CPU#0 stuck
for 23s! [ossec-syscheckd:12608]
If this continues long enough, the entire system grinds to a halt, and
requires Big Red Button service.
I finally managed to attach an strace to one today, but I may not have
gotten it right.
# strace -e trace=read,write -p 12608
which displayed an awful lot of noise (I'd just done a clean reinstall of
ossec-hids-agent) of the format:
read(7, "ST6=m\nCONFIG_CRYPTO_CAST6_AVX_X8"..., 1024) = 1024
read(7, "TO_DEV_QAT=m\nCONFIG_CRYPTO_DEV_Q"..., 1024) = 1024
read(7, "G_PERCPU_RWSEM=y\nCONFIG_ARCH_USE"..., 1024) = 1024
read(7, "NFIG_TEXTSEARCH_BM=m\nCONFIG_TEXT"..., 1024) = 479
read(7, "", 1024) = 0
before going into this loop:
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13344,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13346,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13355,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13357,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13359,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13361,
si_status=0,si_utime=0, si_stime=0}
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13363,
si_status=0,si_utime=0, si_stime=0}
...
SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13660,
si_status=0,si_utime=0, si_stime=0}
and then the soft lockup messages started-- and no, I didn't think to
attach an strace to pid 13660 until after I'd rebooted.
It's a production server, and while it's not heavily used, it's used enough
that we don't want it off during production hours.
Some information about the server:
kernelrelease => 3.10.0-514.6.1.el7.x86_64
lsbdistdescription => Red Hat Enterprise Linux Server release 7.3
(Maipo)
It's a VM under VMware esx, 2 cores, 2 gig memory, ext4 / LVM. All of the
affected systems appear to be Red Hat 7, all patched within the last 30
days.
Any suggestions where to look next?
Thanks in advance!
--John
--
---
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.
