Limit Cronjobs Execution
Limit cronjob`s only to user /home/ so he can`t read outside /home/user/ and execute /bin/bash commands.
Example Commands on Cron Logs.
Jan 12 15:52:01 s3 CROND[12892]: (user) CMD (lspci >> /home/user/pci.txt)
Jan 12 16:06:02 s3 CROND[19681]: (user) CMD (ls /home > /home/user/home.txt)
Jan 12 16:09:02 s3 CROND[21587]: (user) CMD (ls -al / >> /user/user/home.txt)
Jan 12 16:19:01 s3 CROND[27623]: (user) CMD (uname -a >> /home/user/dmi.txt)
Jan 12 16:20:01 s3 CROND[27757]: (user) CMD (ls /proc > /home/user/dmi.txt)
Jan 12 16:24:02 s3 CROND[29854]: (user) CMD (w > /home/user/w.txt)
Jan 12 16:27:01 s3 CROND[31356]: (user) CMD (free -m > /home/user/mem.txt)
There also can be use wget , curl to download and execute exploit.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
The feature to jail users already exists within cPanel & WHM as of 11.38. As long as the user is *not* set to the /bin/bash shell, (No Shell, Jailshell), then their cron tasks will be jailed.
Certain binaries are required for a functional shell and cannot be disallowed without breaking functionality. Therefore jailing users from every command that the individual sysadmin considers undesirable is not realistic.
If the primary concern is the user downloading and executing code on their account, the focus should be on preventing access to the account. Once the user has access to the account, crond isn't going to be their only venue of downloading or executing code. They would have a myriad of tools available to them (FTP, SFTP, PHP, Perl, File Manager, WebDAV, etc) in which to at least download files if not execute them (even if simply via an Apache request). Once a user has access to the account, security is already breached. If you can itemize methods in which users are gaining this access, those would be the vectors to pursue.
On an individual basis, you can always choose to adjust permissions/ownerships for specific system binaries to prevent users from executing them (jailed or not). Simply be aware of the prior warning in that disabling execution of some of them may result in a broken shell/functionality.
Note that items like "ls /home" and "ls -al /" expose no usable information while crond is jailed through 11.38's existing jailshell functionality with crond.
The feature to jail users already exists within cPanel & WHM as of 11.38. As long as the user is *not* set to the /bin/bash shell, (No Shell, Jailshell), then their cron tasks will be jailed.
Certain binaries are required for a functional shell and cannot be disallowed without breaking functionality. Therefore jailing users from every command that the individual sysadmin considers undesirable is not realistic.
If the primary concern is the user downloading and executing code on their account, the focus should be on preventing access to the account. Once the user has access to the account, crond isn't going to be their only venue of downloading or executing code. They would have a myriad of tools available to them (FTP, SFTP, PHP, Perl, File Manager, WebDAV, etc) in which to at least download files if not execute them (even if simply via an Apache request). Once a user has access to the account, security is already breached. If you can itemize methods in which users are gaining this access, those would be the vectors to pursue.
On an individual basis, you can always choose to adjust permissions/ownerships for specific system binaries to prevent users from executing them (jailed or not). Simply be aware of the prior warning in that disabling execution of some of them may result in a broken shell/functionality.
Note that items like "ls /home" and "ls -al /" expose no usable information while crond is jailed through 11.38's existing jailshell functionality with crond.
The feature to jail users already exists within cPanel & WHM as of 11.38. As long as the user is *not* set to the /bin/bash shell, (No Shell, Jailshell), then their cron tasks will be jailed.
Certain binaries are required for a functional shell and cannot be disallowed without breaking functionality. Therefore jailing users from every command that the individual sysadmin considers undesirable is not realistic.
If the primary concern is the user downloading and executing code on their account, the focus should be on preventing access to the account. Once the user has access to the account, crond isn't going to be their only venue of downloading or executing code. They would have a myriad of tools available to them (FTP, SFTP, PHP, Perl, File Manager, WebDAV, etc) in which to at least download files if not execute them (even if simply via an Apache request). Once a user has access to the account, security is already breached. If you can itemize methods in which users are gaining this access, those would be the vectors to pursue.
On an individual basis, you can always choose to adjust permissions/ownerships for specific system binaries to prevent users from executing them (jailed or not). Simply be aware of the prior warning in that disabling execution of some of them may result in a broken shell/functionality.
Note that items like "ls /home" and "ls -al /" expose no usable information while crond is jailed through 11.38's existing jailshell functionality with crond.
The feature to jail users already exists within cPanel & WHM as of 11.38. As long as the user is *not* set to the /bin/bash shell, (No Shell, Jailshell), then their cron tasks will be jailed.
Certain binaries are required for a functional shell and cannot be disallowed without breaking functionality. Therefore jailing users from every command that the individual sysadmin considers undesirable is not realistic.
If the primary concern is the user downloading and executing code on their account, the focus should be on preventing access to the account. Once the user has access to the account, crond isn't going to be their only venue of downloading or executing code. They would have a myriad of tools available to them (FTP, SFTP, PHP, Perl, File Manager, WebDAV, etc) in which to at least download files if not execute them (even if simply via an Apache request). Once a user has access to the account, security is already breached. If you can itemize methods in which users are gaining this access, those would be the vectors to pursue.
On an individual basis, you can always choose to adjust permissions/ownerships for specific system binaries to prevent users from executing them (jailed or not). Simply be aware of the prior warning in that disabling execution of some of them may result in a broken shell/functionality.
Note that items like "ls /home" and "ls -al /" expose no usable information while crond is jailed through 11.38's existing jailshell functionality with crond.
Replies have been locked on this page!