Solutions for handling symlink attacks

[ThinIce]

I personally would use grsecurity with selinux in mode permissive (Send alert via email or suspend account)

One of the attractive points of cloud linux is it removes the need for administrators without the requisite experience to get similar levels of protection without having to roll their own grsecurity kernel for CentOS.

I'm saying that on the basis that I'm not aware of a trust-able repository or good set of documentation for producing a functioning cPanel compatible grsec kernel, there seems to be a rather bloody minded view going along the lines that if I've had to go through the pain and time of producing such, I won't share the goodies.

I know that makes sense from a commercial point of view, perhaps I'm just getting crabby in my old age.

 

[asd_asd]

I'll just make a short introduction

It all starts by CSF.

You need to do a filter on incoming emails (LDF)

You get thousands of emails from the server, correct?

So doing a filter you separate the important delivered by LDF

i.e:

If email has subject with ( Suspicious ) and body has ( bash or perl /tmp )

Then in your filter, you separate the emails with important keywords.


Every server, you have 1 email per day, or 1 email per week, referring to a hacked site. I averaged 3000 websites hosted by server. The problem happens 1 time per week on average.

Your cron will only look at this email (the important email separated in the filter) and detect the flagged account as dangerous then simply suspend automatically.

- - - Updated - - -

Look. You will look 1 email filtered per day or per week. No more than 30 lines. This does not generate high load.

Your script will check the username and suspend the account hacked.

Amazingly Simple!

- - - Updated - - -

Moreover, this protection will beyond the symlink attack.

This will serve to protect any script in PERL or BASH running.

The protection is broader than the corrections presented here by cPanel.

Hi konrath,
i have seen the cagefs solution and i proposed it to my boss. But he is not agree to the payment of a monthly fee.
It's possible to have a your solution tutorial. I need of the script i have to cron every minute to change permission and the script to send the mail to advice the suspension of account...
Thanks a lot.

 

[quizknows]

symlink race condition protection in EasyApache is free, and offers more comprehensive protection than Konrath's solution.

While I have seen proof-of-concept to bypass the old rack911 patch, I never saw a hacker try to do it. I have not seen proof of concept to bypass the symlink race condition patch in EasyApache. I have seen it stop many symlink attack attempts.

 

[konrath]

Hi konrath,
after i read all your reasons, i prefer your solution.
Can you send me or post a tutorial with all steps to set your solution?
Thanks.

Hello asd_asd


Run this script in cron every 1 minute.

I'm not a programmer but it helps me. It can be improved.

1) You need to configure your server to receive all emails from CSF

2) You need to create a second email account to receive filtred emails. This email account is checked every 1 minute to see if there are new emails. The script below will do this and suspend the account.


Create a file called hack. Put in /usr/local/hack/ ( i.e. )
and chmod 755 to this file.


Put in cron

*/1 * * * * /usr/local/hack/hack

Configure in this script

1) USER ( user account ) ( line 1 and line 6 )
2) WEBSITE ( website name ) ( line 1 and line 6 )
3) USEREMAIL ( email user ) ( line 1 and line 6 )
3) YOUREMAIL HERE ( put your email to receive notifications )





grep Account /home/USER/mail/WEBSITE/USEREMAIL/new/* > userhack
us=`cut -d ":" -f 2 userhack`
/scripts/suspendacct $us "Website hacked" 1
echo $us| mail -s "PERL HACK "$us" suspended " YOUREMAIL HERE
rm userhack -rf
rm -rf /home/USER/mail/WEBSITE/USEREMAIL/new/*

Filter email received from csf and send to email destination



This second filter should be placed in the second email to avoid false positives.




IMPORTANT !!!!!!

This filter is more tuned to detect perl files running on TMP. You should and can create another filters.


IMPORTANT !!!!!!

Edit file called filealert.txt in /etc/csf/alerts and change word Owner: to Account:

Final result ( i.e )

From: root
To: root
Subject: lfd on [hostname]: Suspicious File Alert
Time: [time]
File: [file]
Reason: [reason]
Account: [owner]
Action: [action]


How it works:

1) You need to have 2 emails.
1.1) First email account that will receive all emails from CSF.
1.2) Second email account that will receive filtered email

The script will check every 1 minute and will suspend the account (user) that this email is filtered.


--------------------------------------

To finish. Another tip. I post this solution here too if you need.

I have a script that blocks ANY site to run perl files via port 80. If a site run
hxxp://www.sitename.com / hack.pl
He will be suspended automatically.

--------------------------------------

 

[konrath]

As a security professional responsible for thousands of cPanel servers I recommend you use a real solution that does not reply on crontab or AV detection. If you use SuPHP, simply select the Symlink Race Condition protection option in EasyApache. Otherwise review the other options here https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p23.html#post1397221

Sorry but you are wrong.

Their logic is:

If you are a professional in security then you should close all doors of your server. Preferably turn off your server.

My recommendation works as a complement to the firewall.
My suggestion protection is not 100% safe and nothing is 100% safe.

My suggestion even protects other threats not just symlink attack

If this verification system that I am proposing, was present at the firewall you would find beautiful and wonderful. I'm sure it would activate.

 

[quizknows]

Your script is a work-around, not a patch. Simple as that. I'm not saying it's horrible, I'm saying there are safer, easier, and more effective alternatives for preventing symlink hacks.

Your solution is effective for suspending a single compromised account, and I give it credit for that. However it should not be relied on as your only defence against cross-account symlink attacks.

 

[konrath]

Hello asd_asd

I have a script that blocks ANY site to run perl files via port 80. If a site run
hxxp://www.sitename.com / hack.pl
He will be suspended automatically.

This is another layer of protection. You want it?

- - - Updated - - -

Your script is a work-around, not a patch. Simple as that. I'm not saying it's horrible, I'm saying there are safer, easier, and more effective alternatives for preventing symlink hacks.

Your solution is effective for suspending a single compromised account, and I give it credit for that. However it should not be relied on as your only defence against cross-account symlink attacks.

If this solution is present in the firewall you use?

The firewall has several bandaid. This could be one.

Could be better written and put in future CSF versions

Do not you agree?

 

[davidhan]

Hi!
You cannot make all of your files to be 600 as that can break many web applications on the server.
Also you can't control that users will not change the permissions of the files by themselves.

 

[konrath]

Hi!
You cannot make all of your files to be 600 as that can break many web applications on the server.
Also you can't control that users will not change the permissions of the files by themselves.

Please read completely what I wrote.

Thank you.

 

[abdelhost77]

Hello , if you use apache with "symlink race condition protection" and suPHP , i advice that you also add this layer of security wich consist to suspend any user executing Perl , Python , CGI ... from apache .
In fact you have just to create script that will check in
/var/log/httpd/suexec_log
i can provide script if you want .
by doing that with a crontab of 1 min for example , a special hacker will not have any chance to bypass the "symlink race condition protection" because the account from which he have access will be suspended once he tried to launch any perl , python or cgi script even if if he change the ".pl" extension and execute a perl script such as : /home/xx/public_html/test.test .

 

[mimran]

Hi please provide me with this script, some hacker installed sucrack python script on my server I don;t know how, I got to know this via lfd notifications. How can we stop this kind of installation ? How can a hacker install this without ssh access.

Suspicious File Alert
File: /tmp/xpl/64/2
Reason: Linux Binary

Also

with File /tmp/find/sucrack

 

[abdelhost77]

Hello mimran ,

for your case You should first secure your /tmp

/scripts/securetmp
chmod 1777 /tmp


############################

 

[mimran]

Thanks, I had to reload the Operating system, but I will keep use the above for securing /tmp.
Is there a way to limit user access to /tmp like a particular user can access his own tmp folder which is usually in /home/username/tmp
Thanks.

 

[brianoz]

No no no!

You should never run ANYTHING every minute from cron, that's just insanely poor practice. Anytime you need to run something from cron you've made a basic design mistake. Why? For two excellent reasons:

1. Running every minute loads up your server which will slow things down. The larger the server grows, the quicker things will slow down.
2. if the jobs start to take more than one minute to run (eg server loaded), you're in trouble

The real solution is to run a daemon which tails the log file, and that would be relatively low CPU. However, there is a much better way ...

If you want to take an action on CSF blocking something, the CSF author has already included a nice mechanism for you to do that via the BLOCK_REPORT variable - check out /etc/csf/readme.txt for more info. Using this you can arrange for a script to run when a block is done and it can take actions based on the value of (in this case) $8. However:

Use industry standard solutions wherever you can to leverage from the knowledge of experts

And of course, anything apart from using the established industry standard here (ie CloudLinux, rack911, Easyapache patch) is really a waste of time. If you invent a home-brewed solution, you have to run it yourself and maintain it yourself and that just doesn't scale well, apart from the fact that it adds to your own stress levels. I just need to say this clearly as there will be people reading this thread without realizing how terrible some of the advice given here actually is. I notice I'm not the only one saying this, and it's for good reason that we're saying it.

 

[quizknows]

No no no!

You should never run ANYTHING every minute from cron, that's just insanely poor practice. Anytime you need to run something from cron you've made a basic design mistake. Why? For two excellent reasons:

1. Running every minute loads up your server which will slow things down. The larger the server grows, the quicker things will slow down.
2. if the jobs start to take more than one minute to run (eg server loaded), you're in trouble

The real solution is to run a daemon which tails the log file, and that would be relatively low CPU. However, there is a much better way ...

If you want to take an action on CSF blocking something, the CSF author has already included a nice mechanism for you to do that via the BLOCK_REPORT variable - check out /etc/csf/readme.txt for more info. Using this you can arrange for a script to run when a block is done and it can take actions based on the value of (in this case) $8. However:

Use industry standard solutions wherever you can to leverage from the knowledge of experts

And of course, anything apart from using the established industry standard here (ie CloudLinux, rack911, Easyapache patch) is really a waste of time. If you invent a home-brewed solution, you have to run it yourself and maintain it yourself and that just doesn't scale well, apart from the fact that it adds to your own stress levels. I just need to say this clearly as there will be people reading this thread without realizing how terrible some of the advice given here actually is. I notice I'm not the only one saying this, and it's for good reason that we're saying it.

THANK YOU.

IMHO this thread is about due to be locked (left stickied, but locked). While defending against cross account symlinks is of critical importance, there's really nothing new to add here any more.

 

[Infopro]

Agreed. Closed.