¿Hay otros rastros en los registros del sistema? Parece extraño que alguien pueda desinfectar tan a fondo un sistema que los registros no muestren nada, y, sin embargo, no detecten Tripwire o al menos restablezcan las marcas de tiempo correctamente.

Intente actualizar un paquete y vea si los archivos actualizados tienen la marca de tiempo de cuando ejecutó la actualización, o la marca de tiempo del archivo original dentro del paquete de actualización (esto es típico en Windows, no así en las distribuciones Linux I ' Estoy familiarizado con, pero por otro lado no dijiste qué distro estás usando).

También, puede comparar las sumas de comprobación con las de una buena versión conocida de su misma distribución.

actualizar

pam_systemd.so se actualizó oficialmente (al menos en el sistema que verifiqué, Ubuntu 14.04-LTS), y el parche se publicó el día que informa:

-rw-r--r-- 1 root root 42864 Feb  1 16:01 /lib/x86_64-linux-gnu/security/pam_systemd.so

Note que estoy en Italia, pero el reloj de mi sistema está en UTC; si estás en España, nuestros archivos se actualizaron dentro de los treinta minutos entre sí .

Entonces, supongo que alguien inició su computadora al menos dos veces (una en enero y otra en febrero), y si inició sesión o no, el sistema procedió a realizar actualizaciones automáticas.

Dependiendo de si se trata de una computadora portátil o una computadora de escritorio, etc., y de si está enchufada, es posible que se haya encendido solo (una vez tuve una computadora de escritorio que hacía eso aproximadamente una vez cada dos semanas). en caso de tormentas), y luego se apaga de nuevo por sí mismo después de algunas horas de inactividad.

Hice lo que sugeriste, actualicé algunos paquetes y comparé las fechas. Llegué a la misma conclusión que mencionaste en tu actualización:

La fecha mencionada por tripwire se basa en la fecha de modificación del paquete y no en la fecha en que se actualizó en mi sistema. Entonces, ¿es realmente necesario considerar un ataque desde afuera? ¿No es posible que sea una actualización después del 27 de febrero (la fecha en que regresé) con la fecha de modificación del paquete anterior?

Soy un perfil bastante bajo para cualquier persona, supongo, para que cualquiera pueda manipular mi computadora portátil para arrancar a través de Internet, y mucho menos entrar en mi apartamento, parece bastante improbable.

Pero para responder a sus otras preguntas, mis registros están vacíos o comienzan el 27 de febrero.

kernel log starts 27.feb
syslog starts 07.03
wtmp begins Thu Mar  1 23:31:40 2018
btmp begins Tue Mar 13 23:07:08 2018
auth.log starts 27.02
faillog is completely empty

la respuesta a tu siguiente pregunta es ubuntu 16.04

Aquí está el extracto de antes de la actualización:

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      529894                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Do 18 Jan 2018 13:42:58 CET 
* CRC32                A/JGJG                      D/hJue                      
* MD5                  A94qrwY3famFuyjNRqByy/      AIg7I1UyImK4SMXV/P3IVE  

... y eso es después de la actualización:

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      527608                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Fr 02 Mär 2018 15:40:49 CET
* CRC32                A/JGJG                      DLot5B                      
* MD5                  A94qrwY3famFuyjNRqByy/      D6A8JWReWbockgtVM8p70R

..pero para apoyar esa teoría del atacante, hay otra cosa: encontré un número de teléfono móvil extraño en mi cuenta de eBay con una contraseña fuerte y moderada.

Ah, y la unidad se rompió, así que intenté arreglarlo, pero fallé. Creé otro usuario y luego estuvo bien.

Verifique los tiempos de creación de los archivos tripwire detectados como modificados. Descubrirá que fueron consecuencia de un proceso de instalación ejecutado por usted o de un trabajo cron .

Si su sistema hubiera sido pirateado por alguien que conocía tripwire , nunca encontraría tal registro de modificación. Preferirías haber encontrado tripwire desinstalado. No se conoce ninguna forma de corromper la base de datos interna tripwire para ocultar las modificaciones debidas a un ataque, a menos que su clave principal tripwire sea demasiado débil o esté almacenada de forma transparente en la misma computadora (2 posibilidades, que sería estúpido para alguien consciente de la seguridad ).