Hi, On Thu, Mar 11, 2021 at 09:32:47PM +0100, peter enderborg wrote: > On 2/27/21 4:30 PM, John Wood wrote: > > In order to mitigate a brute force attack all the offending tasks involved > > in the attack must be killed. In other words, it is necessary to kill all > > the tasks that share the fork and/or exec statistical data related to the > > attack. Moreover, if the attack happens through the fork system call, the > > processes that have the same group_leader that the current task (the task > > that has crashed) must be avoided since they are in the path to be killed. > > > > When the SIGKILL signal is sent to the offending tasks, the function > > "brute_kill_offending_tasks" will be called in a recursive way from the > > task_fatal_signal LSM hook due to a small crash period. So, to avoid kill > > again the same tasks due to a recursive call of this function, it is > > necessary to disable the attack detection for the involved hierarchies. > > Would it not be useful for forensic reasons to be able to send SIGABRT and get the a coredump? If there are many tasks involved in the attack we will generate a big number of coredumps (one per task aborted). This can be solved if we send the SIGABRT to terminate the first process found and send SIGKILL to terminate the remaining processes. But I don't know if under this scenario we will get a core dump with lack of information (the info related to the other processes). Another scenario: The process that crashes is the last in the fork hierarchy and triggers a brute force attack mitigation. In this case it it not necessary to kill the process that crashes since it is in the path to be killed. So, under this situation we will not get a coredump (we don't send any signal). Lack of information again. Currently, we show the name of the task that triggers the mitigation, the attack type (fork or exec) and the name and pid of all the offending tasks involved in the attack (the tasks that we kill). If it's necessary we can show more info. What info do you think would be necessary? Thanks, John Wood
