I already have my /tmp partition for FC3 set to - loop,noexec,nosuid,rw.
Even with that, attackers can still run perl script in /tmp directory.

I found a lot of them running udp.pl scripts to flood other servers. How is it possible they can run these scripts on /tmp if after I have set the partition as non-executable?. Is there a way to secure /tmp so it can't run perl scripts or anything for that matter?

Hope you guys can help me on this. Thanks!

-Joe

They're not running the script, they're running perl... just reading a file from /tmp. On another note, how are they getting access to run that on your system? It sounds like your computer is thoroughly compromised.

I've already installed arno's rc.iptables. Disabled all the unneccessary services. What else is there to secure? Can someone direct me on this?
How do i disable perl to be executed from tmp or from user 'apache'? Anyone could help me on this?

Matir, any suggestions on what more i can do more to secure my FC3? Anyone out there could recommend? I'm running an apache web server hosting some heavy traffic sites. Please advice!

-Joe

Perl isn't being executed from /tmp it's being run from /usr/bin/perl (Or where ever it is on your system) and they are just using that file i.e. $perl /tmp/somefile.pl

The main problem is that they are able to run commands on your syste, this is what you need to address! You can try to track them down and see how they are doing it (what user is creating the /tmp files - that would be a good place to start!) then stop them.

Run chkrootkit and rkhunter. Confirm you havent been rooted.

http://www.chkrootkit.org/
http://www.rootkit.nl/projects/rootkit_hunter.html

Then change all your passwords for all accounts.

Update all software packages.

Or

Reinstall and re-secure (your likely gonna have to do this whatever happens).

Like Matir said, you're likely already compromised, since they're running stuff from your box.

Dear v00d00101,

Well, my server is quite secure as it is. The only reason how they could access the /tmp to run those scripts, is because the server is being used to host some big websites.
As you know /tmp is world-writable, and there is no way to change it to otherwise. I'm not sure how they could gain access to the /tmp directory to upload and execute files, but i'm it has something to do with the Apache Web Server. Not sure of what restrictions to set in httpd.conf to disable them accessing /tmp
I already ran al lthe tests, no trojans were detected. I'm sure the system is not compromised, its just that I need to find a way how to restrict access to /tmp or also from using the perl commands.

Regards,
J

If someone is running commands from your system without authorization, your system IS compromised. You need to figure out if this is a user with normal access or if it is an outside entity and take appropriate action.

Note: If your system attacks other systems due to your negligence in security, you may be held liable for this. (Or so I've heard: I'm not a lawyer)

As I said, thetere is no compromise of the system. Those commands are run by user apache, since user 'apache' are what runs the webserver processes. Anything else you would like to know?

-J

If some of your hosting clients have poorly written CGI or PHP scripts, they can be easily abused to execute commands as the user the webserver is running under (usually nobody or apache). You might want to implement a policy of running nessus or nikto periodically against the system to identify any security holes introduced by webserver scripts. Also keep in mind that if someone can upload and run a cracking tool like a udp flooder, they can also uplaod and execute a local root exploit. So writing off an incident like this as being minor simply because only the apache user is involved is a serious mistake. Maybe if you descibed in detail the steps you've taken to investigate this incident, we can can stop asking about it and move onto other things.

You'll need to look through your apache logfiles to find the source of the compromise.

Look at the modification times for the files in /tmp and then look into the apache logfiles for that date and time. Find out what sites and scripts were accessed. These scripts may have security holes: a few wiki's and php bulletin boards have recently been found to have remote code execution vulns.

Beyonds, did you ever figure out how the attacker was getting in? I have a client that is having the same problem... udp.pl script (owned by user apache) appearing in the /tmp directory and being run.

EDIT:
I believe I found the problem... they still had a very old version of phpBB running that they didn't even remember because nobody was using it! I found it by doing a "locate viewtopic.php". Anyway, the phpBB has been removed. Hopefully that was the only doorway on their server.

Can you post a copy of upd.pl? Or send me a copy of it. I seem to have a similar problem with different name of script.

Why would need a copy of upd.pl? Planning on DOSing someone?

Maybe he wants to see what a file like that looks like. You don't always have to assume the worse in people. In college, my teacher showed me how to do a ddos attack, then he taught me how to react to a ddos attack.

Just curious whether it is the same udp.pl from packetstormsecurity.org
http://packetstormsecurity.org/DoS/udp.pl

That's it.