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.

3 Answers 3


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.

  • 2
    @Rook In isolation, yes. But as part of a wider hardening/minimisation process? I disagree.
    – lew
    Commented Jun 19, 2012 at 3:53
  • 1
    @lew In this case, I don't see how removing perl has a nontrivial impact on the ease of writing an exploit. It means that this particular exploit wouldn't work (assuming you managed to get your system working without perl, which is a tall order), but that's bolting one of many barn doors after the horses have left through it. Commented Jun 19, 2012 at 15:21
  • 1
    OK thanks for the detailed answer I get it. Since I have been hacked twice and each time I found perl scripts in the temp directory of my server (under the one account's username) my idea was that it might make it a bit harder if the hacker only uses PERL kiddy scripts. As I said below I deleted everything from the user's directory and installed a backup that I believe is clean. Recent Apache logs did not show anything suspicious, but my server keeps logs within the user's own directory.
    – Guillaume
    Commented Jun 19, 2012 at 16:27

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.

  • -1 RFI is disabled by default on most systems, and by default for PHP for the past couple of years. What proof do you have that this was the attack used?
    – rook
    Commented Jun 18, 2012 at 23:21
  • 1
    Yes RFI is disabled by default in PHP>=5.2, but why would you jump and assume a box using such version? And even if it was using non-vulnerable version, does PHP alone is vulnerable to this? The post said "One of my server's web accounts got hacked a couple times." I am making an analysis based on the details of what has been posted, not with forensics infront of my terminal. Considering your argument and creating doubt, then what proof do you have that file inclusion was not the attack. Commented Jun 19, 2012 at 7:32
  • Are you sure that file inclusion is not in effect for today's environment and no one posts them in exploit boards lately? EDB-ID: 18308. Not because a vulnerability dried up few years back means no box is connected in the wild susceptible to an attack OR the "possibility" of a newly provisioned unhardened box today does not exist. A stupid misconfiguration by an admin as what you are trying to say can lead to a remote code execution whether it is remote/local. Commented Jun 19, 2012 at 12:46
  • On the other hand, even if you care TO touch the file and make unhealthy configurations, if the application is strongly written not to take advantage of the vulnerability, exploitation is useless. The point is it's logical, RFI/LFI is a product of bad programming. I tend to listen for seniors on good arguments, but to say that "RFI is disabled by default on most systems?" It is the directive which is disabled, not the flaw. Disabling it helps reduces the possibility, Do not put the blame on turning on or off a button because the very thing the option was there is because it serves a purpose. Commented Jun 19, 2012 at 12:46
  • 1
    Thanks Rook, I really appreciate being called "stupid", to be honest that's not the kind of help I was hoping for. PhpBB has been deleted from the hosting account after the first attack, I installed it some time ago to check it out really and kind of forgot about it - mistake I know. I am not an expert is security I won't lie about it, or I wouldn't be here posting basic questions - nonetheless I don't think I deserve being insulted for asking a question. The perl scripts were uploaded to the system's temp directory and executed from there. They were chrooted to the web account's user ...
    – Guillaume
    Commented Jun 19, 2012 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .