One of my server's web accounts got hacked a couple of times. Each time someone downloaded a Perl script via some phpBB forum and used the Perl script to do whatever they wanted to do (mostly connect to IRC and start DDoS attacks according to the script's code).
I would like to disable Perl for most (not all as some processes I use are using Perl) or some specific users.
How can I do it properly? I am using Debian.
I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user).
However as an aside, the straightforward way if you have an application in linux that you want to restrict to certain users, you first, create a group, then add users to that group. The following commands accomplish this in ubuntu (creating the perl group and adding user1, user2, user3 to it:
sudo addgroup perl
sudo adduser user1 perl
sudo adduser user2 perl
sudo adduser user3 perl
Now find where perl currently is (which perl which on my system was /usr/bin/perl) find what it's perl's ownership and permissions currently are (ls -l /usr/bin/perl on ubuntu by default set to owned by user root and in group root) with everyone having read/execute permissions, which you should disable for other users unless they are in the perl group:
sudo chgrp perl /usr/bin/perl
sudo chmod o-rx /usr/bin/perl
Note that an attacker on your system who isn't a member of the perl group, if they can get to a terminal could upload their own version of the perl executable (or if you didn't remove read access to other users; they could have just copied it) to some local/tmp directory, set the executable bit on it (if they can run chmod), and then use that run perl script's off their own executable.
Disabling perl is useless. The exploit that can be written in Perl can also be written in another language. Say, PHP, which you obviously aren't going to disable.
If you take a system that's already very secure (as in: vulnerabilities are rare and tend to affect only a small part of the system with no direct way of enabling the execution of arbitrary code), then it can be worthwhile to disable all methods of scripting. This can limit the extent to which some vulnerabilities can be exploited. For example, if you can only inject a small number of ASCII characters, writing a machine executable might be a major challenge whereas writing a script would be trivial.
Against the kind of vulnerability you encountered, disabling interpreters wouldn't help. The attacker could upload PHP, or machine code. You're shooting the messenger.
The attack you are experiencing is called a Remote File Inclusion (RFI) technique. It's basically the outcome of a vulnerable web application which is being taken advantage of to upload malicious code to spawn a remote shell.
You do not need to specifically disable Perl. You can start identifying the vulnerable application like for example phpBB that the attacker uses, then patch or completely remove that application and replace it with an upgraded version.
Since the box is compromised, it is mostly unsafe to just rely with the method above given that they might have already installed a backdoor running on your host. If you have a physical access to the server, try to bring it down on the network. If you do have remote access, then just work around with the firewall rules first ensuring access only to your location of origin (IP address).
One thing you can do is to explicitly DENY all incoming traffic from the network layer and SPECIFY only traffic for a given or used port: TCP/22,80 to ensure that even though they might have installed a backdoor running on a port different from the two, it won't bind and spawn a remote shell.
Removing Perl will break all the Perl dependent applications running on your host.
