Solutions for handling symlink attacks

Status
Not open for further replies.

NetMantis

BANNED
Apr 22, 2012
116
1
66
Utah
cPanel Access Level
DataCenter Provider
I have a bit more of what you might call an evil anti-symlink implementation setup already.

The server's inodes are monitored in real time and if anyone attempts to create any symlink to any resource outside of their account and / or attempts to create a php.ini file (disabled regardless so doesn't work anyway) then the server will immediately suspend their account on the spot, ban their last known connection IP, send an alert to administrators, backup the account to cpmove archive, and fully terminate the account. :)
 

SoftDux

Well-Known Member
May 27, 2006
1,023
5
168
Johannesburg, South Africa
cPanel Access Level
Root Administrator
I have a bit more of what you might call an evil anti-symlink implementation setup already.

The server's inodes are monitored in real time and if anyone attempts to create any symlink to any resource outside of their account and / or attempts to create a php.ini file (disabled regardless so doesn't work anyway) then the server will immediately suspend their account on the spot, ban their last known connection IP, send an alert to administrators, backup the account to cpmove archive, and fully terminate the account. :)
mmmm, would you mind sharing this script?
 

Estiny

Registered
Nov 9, 2011
2
0
51
cPanel Access Level
Root Administrator
I have a bit more of what you might call an evil anti-symlink implementation setup already.

The server's inodes are monitored in real time and if anyone attempts to create any symlink to any resource outside of their account and / or attempts to create a php.ini file (disabled regardless so doesn't work anyway) then the server will immediately suspend their account on the spot, ban their last known connection IP, send an alert to administrators, backup the account to cpmove archive, and fully terminate the account. :)
Yeah seriously. You can't just tell us this and then not provide the script! :(
 

voshka

Active Member
Apr 4, 2010
30
0
56
I've found out that one of the way to secure the server against this kind of attacks is to limit the permission of the binary file
for this it only requires you to lower the permission of the /bin binaries
in this case it is the ln that has to be lowered in permission
by default the file system binary files have permission to 755
you could easily change it to I think 750
But please make sure it wont break the sever as changing it to a very low permission may break your server not be able to boot up

Please advise if this is a good way to harden server against this type of attack

Thanks
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
I've found out that one of the way to secure the server against this kind of attacks is to limit the permission of the binary file
for this it only requires you to lower the permission of the /bin binaries
in this case it is the ln that has to be lowered in permission
by default the file system binary files have permission to 755
you could easily change it to I think 750
If you don't need to enable ln to other users, simply chmod it to 0700. We use 0700 and it does not break cPanel.
 

NetMantis

BANNED
Apr 22, 2012
116
1
66
Utah
cPanel Access Level
DataCenter Provider
mmmm, would you mind sharing this script?
It's not a script per say but yes I could help you setup something sort of like that.

My operating system has been heavily customized and I also use a separate server and hardware to monitor all activity on the hosting server in live real time so it's a little bit more complicated than just a "script".

However, even without that, you should be able to put together something fairly comparable and I could certainly help you with that if you really wanted to try to build something similar.

- - - Updated - - -

If you don't need to enable ln to other users, simply chmod it to 0700. We use 0700 and it does not break cPanel.
The group and everyone bit set to "0" could actually break a few behind the scenes things you might not be aware.

If you don't want to grant execute access, I would suggest using "4" instead of "0" when restricting Linux commands.

Recommend Suggestion:
Code:
OWNER:   root
GROUP:   cpanel  (or root if you want to push the tight threshold a bit)
CHMOD:   0754
 

voshka

Active Member
Apr 4, 2010
30
0
56
make the owner and group
root:cpanel

and chmod 754
is that okey?

making this permissions for ln and ls

thanks
 

NetMantis

BANNED
Apr 22, 2012
116
1
66
Utah
cPanel Access Level
DataCenter Provider
For 'ln' yes absolutely, you got it exactly and quoted back correctly what I said to setup!

HOWEVER -- DO NOT SET 'ls' PERMISSIONS. BAD, BAD IDEA !!!!

Restricting 'ls' will make for a very, very broken server!
Code:
ln --- sure, no problem.      
ls --- definitely, do not touch that one
EDIT: In terms of security, you can generally safely restrict the following using the (0754 root:cpanel) type of permissions without causing too many problems:

/bin/ln
/bin/ping
/bin/traceroute
/bin/touch (root:root 0754)
/bin/chown (root:root 0754)
/usr/bin/chattr (root:root 0754)
/usr/bin/wget
/usr/bin/lynx
/usr/bin/lsattr
/usr/kerberos/bin/telnet

Obviously, there is more but the above list is the most advantageous to restrict. If you don't understand how a command works behind the scenes especially with scripts and programs, do not restrict it! Fine examples of commands that you should not touch the permissions for any reason would be 'echo', 'ls', 'grep', 'sed', 'awk', 'chmod', etc as you'd be guaranteed to break your server.
 
Last edited:

voshka

Active Member
Apr 4, 2010
30
0
56
For 'ln' yes absolutely, you got it exactly and quoted back correctly what I said to setup!

HOWEVER -- DO NOT SET 'ls' PERMISSIONS. BAD, BAD IDEA !!!!

Restricting 'ls' will make for a very, very broken server!

ln --- sure, no problem. ls --- definitely, do not touch that one
What other binaries that should be limit in their permissions that you recommend to lower their permissions

having ownerships to root:cpanel wont break the sever ?
Thanks
 

voshka

Active Member
Apr 4, 2010
30
0
56
Oh Thanks NetMantis
do you confirm the following ?

/bin/ln (root:cpanel 0754)
/bin/ping (root:cpanel 0754)
/bin/traceroute (root:cpanel 0754)
/bin/touch (root:root 0754)
/bin/chown (root:root 0754)
/usr/bin/chattr (root:root 0754)
/usr/bin/wget(root:cpanel 0754)
/usr/bin/lynx(root:cpanel 0754)
/usr/bin/lsattr(root:cpanel 0754)
/usr/kerberos/bin/telnet(root:cpanel 0754)

and also my question is that when the system is booting up it needs ln to understand directories locations and more
making ln group to cpanel wont break it ?
Thank You
 

voshka

Active Member
Apr 4, 2010
30
0
56
Also how About the patch was in discussion in this thread
was that useful and working ?
do you people who used it are now satisfied with it?

Thanks
 

NetMantis

BANNED
Apr 22, 2012
116
1
66
Utah
cPanel Access Level
DataCenter Provider
Oh Thanks NetMantis
do you confirm the following ?

/bin/ln (root:cpanel 0754)
/bin/ping (root:cpanel 0754)
/bin/traceroute (root:cpanel 0754)
/bin/touch (root:root 0754)
/bin/chown (root:root 0754)
/usr/bin/chattr (root:root 0754)
/usr/bin/wget(root:cpanel 0754)
/usr/bin/lynx(root:cpanel 0754)
/usr/bin/lsattr(root:cpanel 0754)
/usr/kerberos/bin/telnet(root:cpanel 0754)

and also my question is that when the system is booting up it needs ln to understand directories locations and more
making ln group to cpanel wont break it ?
Thank You
None of those are folders and you should not be setting the group on the folders those files are in, just the files themselves and the reason why 'cpanel' is set on a few of those for the group is so that cpanel is still able to execute those commands. I have found a few places where cpanel does make script calls to those executing as cpanel instead of root and a "root:root" restricted configuration would break those scripts but a "root:cpanel" would not.

Regarding your "boot up" question, the system only understands one user at boot up --- root.

The list you quoted looks fine for making command use more restricted but also minimizing breaking any scripts.

I have very thoroughly tested all of those on many servers and the list you quoted should be fine as you listed.
 

NetMantis

BANNED
Apr 22, 2012
116
1
66
Utah
cPanel Access Level
DataCenter Provider
Someone was asking me some questions about symlink topics privately and part of that discussion, I told them about how to determine if a file has a symlink pointing to it, "hard" or "soft" and that little piece of information might be useful to some of you if you don't already know about this.

Code:
# ls -l -- pass* shad*

-rw-r--r-- 1 root root  6562 Jul  6 21:14 passwd
-rw-r--r-- 1 root root  6562 Jul 15 02:08 passwd-
-rw------- 1 root root 22346 Jul 15 02:08 passwd.cache
-rw------- 1 root root 17586 Jul 15 02:08 passwd.nouids.cache
-rw------- 1 root root  5553 Jul 15 02:08 shadow
-rw------- 1 root root  5553 Jul 15 02:08 shadow-
In the directory listing I was returned in the above command, take notice of the "1" in the second field just after the permissions are given. This "1" is the number of symlinks that are pointing to a file including the file itself.

Folders get incremented for every file that is in the folder so they show the total number of files plus 1 typically.

Files should under normal circumstances always be "1" especially those files in user account areas.

If your /etc/passwd or /etc/shadow suddenly goes to "2" or higher, you got a problem as someone just linked to your password and user account information but that also should give you an idea about how you can easily script to monitor for these changes and alert administrators.

If you find a file has symlinks to it per the directory listing, you can pull the extended long form directory information and the inode information for the file to determine where the symlink is located. Files using hard symlinks will have the same inode identification number on the drive. This however gets quite advanced and would be a lengthy discussion topic for this forum thread.

If you want to find soft symlinks in user accounts, this is really as simple as using the 'find' command.
Code:
# find /home/*/public_html -type l
For those that have not setup their servers yet or are willing to make a major overhaul, I would strongly recommend that you put your /home on it's own partition at the least or preferably on it's own physical separate hard drive by itself and apart from / and the rest of your operating system files and folders.

The reason for this is hard symlinks can only be created within the same storage volume so by putting /home on it's own drive or partition, you disable the ability for anyone to hard link to anything outside /home leaving only soft symlinks as a possibility which are trivial to detect and eliminate.
 

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
In the directory listing I was returned in the above command, take notice of the "1" in the second field just after the permissions are given. This "1" is the number of symlinks that are pointing to a file including the file itself.
This isn't entirely true.

Folders get incremented for every file that is in the folder so they show the total number of files plus 1 typically.
This is completely false.

Code:
[[email protected] ~]# rm -f /foo ; ls -ld / ; touch /foo ; ls -ld /
drwxr-xr-x 23 root root 4096 Jul 18 15:07 //
drwxr-xr-x 23 root root 4096 Jul 18 15:07 //

If you find a file has symlinks to it per the directory listing, you can pull the extended long form directory information and the inode information for the file to determine where the symlink is located. Files using hard symlinks will have the same inode identification number on the drive.
There is no such thing as a "hard symlink".

If you want to find soft symlinks in user accounts, this is really as simple as using the 'find' command.
Code:
# find /home/*/public_html -type l
1) It is redundant to say "soft symlink".

2) You haven't taken hard links into account.

The reason for this is hard symlinks can only be created within the same storage volume so by putting /home on it's own drive or partition, you disable the ability for anyone to hard link to anything outside /home leaving only soft symlinks as a possibility which are trivial to detect and eliminate.
Again, there is no such thing as "hard symlinks".
 

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
The list you quoted looks fine for making command use more restricted but also minimizing breaking any scripts.
This is terrible advice. Lowering the group permissions on files is unsafe and can introduce great security risks.
 

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
EDIT: In terms of security, you can generally safely restrict the following using the (0754 root:cpanel) type of permissions without causing too many problems:

/bin/ln
/bin/ping
/bin/traceroute
/bin/touch (root:root 0754)
/bin/chown (root:root 0754)
/usr/bin/chattr (root:root 0754)
/usr/bin/wget
/usr/bin/lynx
/usr/bin/lsattr
/usr/kerberos/bin/telnet
This is dangerous advice and should not be followed.
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
This is dangerous advice and should not be followed.
Could you tell us why it is dangerous? If I will lower permisions to binaries IMHO I disallow to run those commands?

If I will remove execution permission by:

chmod 754 /bin/touch
chmod 754 /bin/chown
chmod 754 /usr/bin/chattr

what it will break? what security impacts it will have (please explain regarding those 3 binaries: touch, chown, chattr)?
 
Last edited:

JeffP.

Well-Known Member
Sep 28, 2010
164
15
68
Changing the group of a binary is what could have potential security implications. Changing the permissions of /bin/touch to 754 for example doesn't have any security implications, but it is useless. Here's one of a number of ways to create a new file (assuming that is the reason for attempting to disable the touch binary):

Code:
[[email protected] ~]$ ls -l test
/bin/ls: test: No such file or directory

[[email protected] ~]$ touch test
-bash: /bin/touch: Permission denied

[[email protected] ~]$ > test

[[email protected] ~]$ ls -l test 
-rw-r--r-- 1 user user 0 Jul 18 19:39 test

Here's a trivial way to defeat permissions of 0754:

Code:
[[email protected] ~]$ ls -l /bin/chown 
-rwxr-xr-- 1 root root 41968 Mar 21 08:35 /bin/chown*

[[email protected] ~]$ /bin/chown
-bash: /bin/chown: Permission denied

[[email protected] ~]$ cp /bin/chown .

[[email protected] ~]$ chmod 755 chown 

[[email protected] ~]$ ./chown 
./chown: missing operand
Try `./chown --help' for more information.
But since that user does not have root privileges, it can't change ownerships anyway.

The same applies to chattr.
 
Status
Not open for further replies.