Originally Posted by
Brook
I am using jalied shell for the admin account though - this is what I've always done and was under the impression it's safer that way?
Actually jailshell doesn't really offer any additional security and actually
can bring you some headaches as you cannot use SUDO / SU commands
on some newer versions on some of the Linux flavors (distributions).
I actually avoid jailshell entirely because it lends itself too much to a
false sense of security. A lot of server managers out there incorrectly
believe jailshell offers additional security from being hacked by limiting
the user's actions in SSH but the reality is that there are literally hundreds
of ways to escalate privileges or bust out of the jailed session once logged
in with a jailshell shell and any real hacker is going to know each and every
one of those so the only people you limit are the average regular users
who wouldn't know enough to do any harm anyway.
In a similar vain, disabling direct root logins doesn't hurt but does not
really offer much additional protection. You could argue that the hacker
needs two passwords instead of one and that may or may not be true
since there are also other ways to get to root aside from using the
standard SU login once in a regular user account.
Mathematically speaking, you are just as good having an unusually long
random password for root and installing a login attempt defense such as
the LFD system that comes with Chirpy's CSF firewall. For increased
security, I recommend disabling password logins completely and using
certificate based logins under at least protocol 2 on a non-standard port.
Good luck to anyone attempting brute force hacks as they not only
would need to know the login port but would have to already have the
correct encryption certificate which cannot be guessed since you have
a login defense for one (see above) and because each character in the
certificate adds an exponential increased difficulty in decoding that
makes brute force unrealistic even in the best of situations and the
hacker would have to resort to some other method of attack.
If you really want to lock down security, I'd be happy to help you with
that directly or go over a much longer list of items to address with
many that are often missed or forgotten such as for example setting
your partition for /tmp non-executable without escalation bits,
securing vulnerable OS components, updating with the latest patches
to all software components and libraries, setting up a good firewall,
portscanner, hack attempt monitors, mod_security (always a good idea),
mod_evasive (helps with some web DOS conditions), using SuPHP,
methods for better tracking of user activity, Using SuHosin, Closing
out security vulnerabilities in named, exim, and other services, etc.
I could actually type all night long on the subject just simply making
a flat list of things you should do to protect your server.
Like I said, if you want to go over those, talk to me. I will be heading
to bed fairly soon but I'll be on tomorrow on and off, of course. 
What commands should I run to check permissions? Anything else to look into?
Just your standard "ls -la" and "lsattr" will tell you plenty ...
Code:
# cd /usr/bin
# lsattr /usr/bin/sudo /bin/su
------------- sudo
------------- su
# ls -la /usr/bin/sudo /bin/su
---s--x--x 2 root root 150904 Jun 27 18:55 sudo*
-rwsr-x--- 1 root wheel 28336 Jun 28 23:24 su*
Root has "rws" so the setid bit is set and root could run su as well which
is pretty obvious since that is kind of the point of su.
Notice the that "su" is grouped to wheel and has "r-x" for group permissions
which means that anyone that is a member of "wheel" can run it while
everyone else has "---" which means no access.
Now the reason for pointing this out is that I have seen a number of servers
where the administrators or data center setting it up set the group to something
other than wheel or locked down access to root only such as "-rws------" for su
which would be rather pointless and do more harm than good but that is something
you should double check and make sure that you don't have going on with your server.
I would also open up /etc/sudoers in an editor and see how you have sudo configured
While in the /etc folder, it doesn't hurt to take a look at /etc/passwd and take note
of how both your "root" and the user account designated to be your admin account look.
Can't su to root
LinkBack URL
About LinkBacks
Reply With Quote
