Cómo encontrar un Crontab fugitivo

17

Hace unos años configuré un trabajo cron para hacer ping automáticamente a una URL cada minuto como parte de un sistema de monitoreo (eso es una simplificación excesiva, pero servirá para esta pregunta). Como soy una persona horrible, no documenté esto en ningún lado.

Hoy, años después, comencé a tener problemas con la aplicación en el otro extremo de la URL que se está haciendo ping. Lo arreglé, pero luego me di cuenta, no tengo idea de dónde viene este trabajo cron .

¿Hay alguna manera de buscar rápidamente o eliminar todos los crontabs en un sistema en particular? Tengo acceso a la raíz, por lo que los permisos no son un problema. Solo he sido un usuario cron, nunca he analizado demasiado su implementación, pero mis instintos * nix dicen que tiene que haber un grupo de archivos de texto en algún lugar que contenga todos los crontabs. Simplemente no sé dónde estarían, y si profundizara en ello, me daría miedo encontrar algunos, pero no todos, o perder algunos matices extraños del sistema.

Además, me doy cuenta con acceso raíz que pude

  1. Obtenga una lista de todos los usuarios en el sistema
  2. su como usuario
  3. crontab -l
  4. Repita con todos los usuarios.

pero estoy buscando algo un poco menos manual (y estoy buscando aprender algo sobre la implementación de cron)

Alan Storm
fuente
2
es posible que deba mirar este enlace: stackoverflow.com/questions/134906/…
Daniel t.

Respuestas:

20

Solo hay unos pocos lugares donde los crontabs pueden esconderse:

  • /etc/crontab
  • /etc/cron.d/*
  • /etc/crond.{hourly,daily,weekly,monthly}/*
    estos se llaman desde /etc/crontab, así que tal vez un asterisco en esto
  • /var/spool/cron/*(a veces /var/spool/cron/crontabs/*)

Asegúrese de verificar attambién, que mantiene sus trabajos en /var/spool/at/o/var/spool/cron/at*/

Además, en lugar de

su <user>
crontab -l

Solo haz esto:

crontab -lu <user>
tylerl
fuente
8

Crontabs viven en /etc/crontab(y con muchas implementaciones) sus componentes en /etc/cron.*/*(todos editados por root) y en /var/spool/cron/*(crontabs de usuarios)

Si tiene problemas para localizar el trabajo ofensivo, otro enfoque es investigar uno mientras continúa. Por ejemplo, puede agregar una regla de firewall para registrar la identificación de usuario del proceso que abre las conexiones en example.comel puerto 80:

iptables -A OUTPUT -p tcp --syn -d example.com --dport 80 -j LOG --log-prefix "[->example.com] " --log-uid

Si el trabajo está utilizando una aplicación como pingo curl, sombree el binario habitual mediante un contenedor que registre información sobre lo que lo está utilizando, con un script como este en /usr/local/bin:

#!/bin/sh
{
  date
  echo "$0" "$@"
  ps -p $PPID
  echo
} >>"/tmp/$(basename "$0").log"
exec "/usr/bin/$(basename "$0")" "$@"
Gilles 'SO- deja de ser malvado'
fuente
¡+1 porque muestra cómo explicar el problema!
Joe
6

La manera rápida y sucia:

grep -r ping /var/spool/cron/crontabs

La ubicación exacta donde se almacenan los crontabs puede variar de un sistema a otro, pero generalmente está en/var/spool y tiene crontabalgún lugar en el nombre.

También tenga en cuenta que muchos sistemas tienen crontabs del sistema (como en ) /etc/crontab, /etc/cron.dalgunos de los cuales pueden llamar a más scripts como /etc/cron.hourly, .daily...

Stéphane Chazelas
fuente
4

Eso suena como un cronjob creado por crontab. No todos los crontabs tienen un -uinterruptor, pero para GNU / Linux está disponible. Esta es una línea útil para enumerar todos los cronjobs creados por crontab.

for user in $(awk -F':' '{ print $1}' /etc/passwd); do crontab -u $user -l; done

(Ejecutar como root)

Christopher
fuente
2

Si todo lo demás falla, puede hacer un honeypot con la URL que está solicitando, es decir, servir un archivo grande o algo así y buscar el proceso que está esperando recibir los datos, y luego buscar su PPID.

sendmoreinfo
fuente
2

Cualquier sistema decente debería explicar la ubicación precisa de los crontabs en la página de manual (generalmente en la FILESsección cerca del final, y también para otros demonios).

En mi sistema, por ejemplo, cron(8)contiene lo siguiente:

 FILES
      /etc/crontab          system crontab file
      /var/cron/atjobs      directory containing at(1) jobs
      /var/cron/log         cron's log file
      /var/cron/tabs        directory containing individual crontab files
      /var/cron/tabs/.sock  used by crontab(1) to tell cron to check for
                            crontab changes immediately

Y secundo el consejo de tylerl de buscar attrabajo mientras estás en ello.

Vucar Timnärakrul
fuente
2

Abordarlo al revés: cron mantiene un registro de lo que está haciendo, precisamente para evitar este tipo de problemas en primer lugar. En mi sistema, el registro se mantiene /var/cron/logy se ve así:

==> /var/cron/log <==
Oct 25 00:21:01 fortress cron[20232]: (vucar) CMD (/home/vucar/lighttpd-watchdog)

Esta línea me dice que la instancia cron con PID 20232 en la máquina se fortressestá ejecutando /home/vucar/lighttpd-watchdogen nombre del usuariovucar . Un sistema con buen comportamiento solo tiene un cron en ejecución, por lo que será sencillo.

Esto también funciona para attrabajos, ya que generalmente solo se los entregan a cron de todos modos:

==> /var/cron/log <==
Oct 25 00:28:01 fortress cron[31282]: (vucar) ATJOB (1414189680.c)

Los fragmentos son de un sistema BSD, pero es muy probable que el concepto general sea el mismo en cualquier otro lugar.

Vucar Timnärakrul
fuente