hello
for security reason i make ln command with permission 700 and i chatter +i the file located /bin/ln
the question is , it this security i made will be effect in ANY functions about cpanel work , update , etc ....?
thanks
hello
for security reason i make ln command with permission 700 and i chatter +i the file located /bin/ln
the question is , it this security i made will be effect in ANY functions about cpanel work , update , etc ....?
thanks
There is a balance between securing things and breaking your server ...
'ln' is one of these functions that sits right on the line.
For this reason, I do not recommend locking it down or more accurately setting it root access only as there are a number of processes I can think of immediately that you would break on Cpanel servers.
Instead of completely locking access, you might want to consider
replacing it with a wrap shell to log and control user access better.
I recommend avoiding any use of the immutable attribute; using the immutable bit can and will lead to difficulties that may not be immediately evident from the start, including non-cPanel-related activity such as normal OS updates (that may need to update the "ln" binary) or other 3rd-party script installation functions (that may need to create symlinks using "ln").
Just to note: I've relocated the thread into the cPanel and WHM Security forums so that it may receive more attention and relevant discussion.
cPResources: Submit a Support Request - Submit a Bug Report - Review existing Tickets-- Donald cPanelDon Holl - Analyst, cPanel Quality Assurance
Actually there is purpose to setting the immutable flag ...
It prevents general updates from blowing away the locked down permissions so in this case the +i that the user spoke of would be
specifically to block the very updates you described.
Now with that said, if the user sets that flag, it would also be their
additional responsibility to make the necessary updates manually
as new updates or patches are released.
One way to minimize the need for this though is to stay current
with the newest and very latest version of whatever command
you have locked down and set immutable. Most Linux flavors
stay somewhat behind on component versions behind the actual
versions currently available if you manually download the origin
source and compile yourself verses grabbing them from yum.
In this particular case, I would grab the newest source for the
commands the user spoke of and get that well updated before
locking down the command.
nobody ask me why i would make permission like this ?
because hackers able to read files with ln command instead of cat or pic or the other read command , ln command make a shourtcut for files exists in the server , or files want to read it specific , for example /etc/passwd
all this operations running under perl scripts ,
there is two CIRTICAL bugs in file manage so had to disable file manager for the whole server
the first server in the frontpage
u may want to check the following link to see how can bypass to server
bypass safe mode cpanel exploit on Frontpage
the 2nd bug want to talk about is the file manager bypass with rar ext
if u disable perl , they make the commands they want in another server have perl enabled , then they tar or compress the command that was in text file and download it , upload it to the server that have perl disable and extract it , and surprise !!!
I don't know about you but I just simply wrote my own "ln" command!
Mine doesn't allow any symlinks to /etc/passwd or related and does
not allow symlinks be setup inside hosting accounts or to system files
unless explicitly done so by root. It also logs all symlink attempts.
Aside from that, it looks, functions, and operates like regular "ln".
Anyway, the point is other than permission changes, you might
consider replacing the commands.
Ironically this is actually a hacker technique normally used to compromise
a system being used instead to protect it.![]()