0

So we found that some trojan has been the cause of our two web servers crashing once a week as we found that perl was executing dozens of malicious "gif" files spiking the memory and eventually restarting the boxes. We're only using the box for PHP and some general nix-y things like chrontabs. Is it possible to disable perl and not uninstall completely? If not any problem with PHP not having perl on the box?

Apologies, I'm a .NET developer working with some LAMP stuff right now and this is just a touch out of my comfort zone.

Thanks. Bryan

bryan
  • 133
  • 6
  • As noted below, disabling perl is a potentially server crashing solution. The best solution is to find the security flaw and patch it. More than like this is caused by an older, exploitable version of some web application you have running. Try running something like nikto2 against your server to find any obvious vulnerabilities. – Kyle Nov 01 '11 at 21:43

3 Answers3

2

It looks to me that you pose the wrong question. And you'll probably will get wrong answers to your original questions (as in easily worked around)

If you have a trojan, "disabling" the execution of programming languages is not the right thing to do.

What's the right thing to do? Patch your servers. Make them secure (and ideally, hire a UNIX System Engineer).

Some questions for you:

  • What will you do once the trojan is executing files in the native Executable and Linkable Format (elf). Will you disable the execution of C-programs (hint: remove libc [Just kidding])?
  • What if the trojan has the interpreter embedded (e.g., pp does this on perl)?
  • What if the script is run in some indirect way?
  • ...

By the way, "disabling" the execution of programming languages, and specially Perl on UNIX, will break a lot of stuff. A lot.

C.

nxadm
  • 121
  • 3
  • So we've patched what was identified and also have done analysis on what is using Perl (thus far only Git) as the server is very lightweight and only hosts one php site. Also, I was looking to disable perl and not uninstall it precisely to test some functionality and to verify what we think was patched, was in fact patched. – bryan Nov 02 '11 at 14:52
  • I don't see many differences between disabling and removing. When Perl is marked as a dependency, it means the package in question needs Perl (or whatever other dependency it has). When you remove the package, the system know that it misses *required* elements (and may remove the packages because the dependencies are not met). When "disabling" --it seems you mean "make not executable"-- the system in question does not know about your *broken* setup and takes the dependencies for granted: the application will probably crash or it will not function as intended (otherwise it's not a dependency). – nxadm Nov 02 '11 at 17:14
  • Are you sure you are not confusing your request with disabling installed services (something common on UNIX)? – nxadm Nov 02 '11 at 17:18
1

Turn off the executable bits:

sudo chmod a-x `which perl`
Kevin
  • 338
  • 2
  • 13
0

One quick thing that could be done would be to temporarily rename the Perl binary from /usr/bin/perl to /usr/bin/perl.SAVE

mdpc
  • 11,856
  • 28
  • 53
  • 67