search

sethsec / celerystalk

An asynchronous enumeration & vulnerability scanner. Run all the tools on all the hosts.
https://sethsec.github.io/celerystalk/
MIT License
397 stars 69 forks source link

Is cancelling a task really killing it? I'm not sure anymore #140

Open cwaazywabbit opened 4 years ago

cwaazywabbit commented 4 years ago

I have got a call today regarding the hogged network and found out that my 6 gobuster instances were chocking the network. Because they asked nicely I went ahead and ./celerystalk cancel <id>d all those instances but.. something still feels off.. every now and then I look at ./celerystalk query breif to find out that a new gobuster instance is running again, which is kind of strage because what I am seeing, is that only 3 nikto-tasks are left, while the others either finished or cancelled.

Submitted: 58 | Queued: 0 | Running: 3 | Completed: 47  | Cancelled: 8  | Paused: 0

and here is it again while I am writing this, 2 nikto-tasks have finished and instead two gobuster-tasks are back there, those which I remember cancelling!

grafik

and just to confirm it, here is a snapshot of the latest cancelled tasks confirming my suspecious!

grafik

and just right now I have this

grafik

but gobuster still appears in the processes

grafik

even nethogs confirms it

grafik

I am not sure anymore!

sethsec commented 4 years ago

Cancel really just sends a SIGTERM to the process via the kill command politely: https://en.wikipedia.org/wiki/Kill_(command).

Reference: https://github.com/sethsec/celerystalk/blob/master/lib/cancel.py#L71

There are definitely times where SIGTERM is not enough to kill the process and you have to send a SIGKILL (kill -9), but I don't have that coded in right now.

It was a long time ago but i think I didnt want to just do a SIGKILL right away was that i would potentially lose logs of partially run commands.

That said, i think it seems like a good idea to:

  1. First try the sigterm
  2. Check to see if the pid is still running. If it is, then send the sigkill
  3. Check to see if the pid is running, if it is (i'm not sure why it would still be after a sigkill), don't switch the task to cancelled, but somehow notify the user at the command line that we could not kill the procces.

sound resonable?

cwaazywabbit commented 4 years ago

Sounds perfect.