This morning, we found that the OpenVPN process was
stopped on the (VMWare ...) VM that processes credit-card transactions. Relevant log entries include the following:
Code:
Jun 23 05:57:26 X-auth systemd[1]: Started ACPI event daemon.
Jun 23 05:57:27 X-auth ovpn-auth-server[1126]: event_wait : Interrupted system call (code=4)
Jun 23 05:57:27 X-auth ovpn-auth-server[1126]: Closing TUN/TAP interface
Jun 23 05:57:27 X-auth ovpn-auth-server[1126]: /sbin/ip addr del dev tun0 10.9.0.1/24
Jun 23 05:57:27 X-auth ovpn-auth-server[1126]: SIGTERM[hard,] received, process exiting
Jun 23 05:57:29 X-auth ovpn-auth-server[13590]: OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Jun 23 05:57:29 X-auth ovpn-auth-server[13590]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Diffie-Hellman initialized with 4096 bit key
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: TUN/TAP device tun0 opened
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: TUN/TAP TX queue length set to 100
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: /sbin/ip link set dev tun0 up mtu 1500
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: /sbin/ip addr add dev tun0 10.9.0.1/24 broadcast 10.9.0.255
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: UDPv4 link local (bound): [undef]
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: UDPv4 link remote: [undef]
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: MULTI: multi_init called, r=256 v=256
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: IFCONFIG POOL: base=10.9.0.2 size=252, ipv6=0
Jun 23 05:57:29 X-auth ovpn-auth-server[13591]: Initialization Sequence Completed
Jun 23 05:57:30 X-auth systemd[1]: Reloading.
Jun 23 05:57:30 X-auth systemd[1]: snapd.refresh.timer: Adding 3h 22min 54.080594s random time.
Jun 23 05:57:30 X-auth systemd[1]: Started ACPI event daemon.
Jun 23 05:58:05 X-auth ovpn-auth-server[13591]: event_wait : Interrupted system call (code=4)
Jun 23 05:58:05 X-auth ovpn-auth-server[13591]: Closing TUN/TAP interface
Jun 23 05:58:05 X-auth ovpn-auth-server[13591]: /sbin/ip addr del dev tun0 10.9.0.1/24
Jun 23 05:58:06 X-auth ovpn-auth-server[13591]: SIGTERM[hard,] received, process exiting
Jun 23 05:58:06 X-auth systemd[1]: Started Daily apt activities.
The unique thing is
SIGTERM[hard,] received. The first time, it appears to have restarted. The second time it did not.
System logs offer no evidence of intrusion and these systems cannot be reached
at all without OpenVPN: there are no exposed "open ports," etc. This has never happened before and I need to explain why it might have happened now.
It appears to have occurred each time immediately after
Started ACPI event daemon, which occurred twice in the space of 4 seconds.
And, why on earth is that demon being started, and then started again,
now? It's not exactly like a VMWare VM has a laptop-lid to be closed.
I am suspicious – not of intrusion, but – of something external to the VM, as in the VMWare environment, which we do not directly own.