> > We were advised to turn sshd PasswordAuthentication off because it allows
> > clear text passwords.
> > hey? That doesn't sound right.
>
> pass
PasswordAuthentication allows the use of an account even if you don't have
a key on the box.. i.e. all you have to know is a username and
password.. and you're in.
The best way to do this is using keys - this also makes access control
easier on the box. So in effect, you should have a separate /etc/passwd
user per admin and in ~/.ssh/authorized_keys (ssh1) you should have the
public key of the admin. PasswordAuthentication should be set to no, and
PermitRootLogin should be set to no. This way, if someone ssh's in, not
only must they have the private key component belonging to the account,
but they must also have the passphrase to decrypt it. Once they're in,
they should su to root.
This way, you have a much more robust authentication scheme and it will
also leave an audit trail of which admin su'd to root etc.
> > Mount partitions read only where possible.
> > I guess this is a good idea, but in what situation would this add security?
> > You need to be root to be able to write to the partitions that I could mount read
> > only, and if someone gets root, they can remount partitions read write.
Two assumptions/problems:
1: you're assuming that they eventually get root access. This is not
always true. Most remote exploits allow an attacked to only get a non-priv
user on the box. From there, they must get root. Run all daemons (where
possible) as non-priv users.
2: Forensics: unmounting, remounting, fiddling and generally playing with
filesystems leaves marks. The more you fiddle, the longer you're on the
box and liable to be caught. The more you fiddle, the more a chance that
you'll leave a trail of sorts. If you have to leave in a hurry and you've
left the system in a non-original state (i.e. mounted rw instead of
ro) after you've trojaned the binaries, there will be a much greater
chance of it being noticed.
> > Remove man pages.
> > Again, I can't see the harm in doing this, but I can't see the point.
>
> If you don't know what to do, why are you fiddling with box. Basically,
> if someone gets in, man pages help them know the particular variety of
> your box. Just makes it harder for script kiddies, dorfs, staff wanting
> to create ICQ holes, etc to fiddle.
Remove anything nd everything that doesn't serve a purpose on the box,
including libraries, and config files not needed by what needs to
run. Everything on your system is info for an attacker.
This is especially true if the box has been "inherited" or if it has been
setup by someone else who used an "easy install methodology" which asks
you a bunch of questions like "your mail server", "nameservers" etc
etc.. if I'm on your box and I don't know your environment, and I don't
want to immediately portscan your subnet and put your eth into promisc
mode, I can always poke around in /etc/*/* and look for config files which
will point me to other boxes on your network perhaps.. or I may be able to
find implicit trust relationships which will aid me in my next step of
taking your network.
> > Remove unnecessary binaries.
> > A good idea no doubt, but the firewall doesn't allow shell access, and the
> > way I see it is if someone gets shell access they can upload their own bin's.
>
> Yes, but they still have to upload them, which takes time, which
> increase the chances of discovery, etc. If you don't need it, then it
> shouldn't be there.
Absolutely. As above - remove anything and everything that isn't needed
specifically!
Think of it this way, I'm on your box, I have a shell as user
"named" (sound familiar anyone? :P ) .. what's my next step?
The next step depends on what I want to do.. let's assume I want root.. ok
- I'm named and I need tools. Ok, let's assume I'm a script kiddy.. the
first thing I'm going to do is to perhaps wget the LRK (linux root kit) or
ftp it down.. or perhaps figure out exactly what kernel I'm running etc or
scan through your pacages and libs to find known vulnerable ones.. then
I'm going to most probably download an exploit..
How do I progress if there isn't a /bin/ftp or a /usr/bin/wget?
There are other ways to get your tools down, but remember, most of your
adversaries are clueless script kiddies who will most probably give up
when they realize that they can't get their root kit or exploits down..
Every additional thing you have on the box is an extra tool for an
attacker. Don't give them any more help.
> > It doesn't mention it in the report, but would mounting /home, /tmp and /var with
> > noexec help? It might stop a non root user from running their own programs, but it
> > won't stop root.
Again, you're assuming that they *initially* get root access. If you're in
as user "squid" chrooted to /cache with only access to /cache/cache1 and
/cache/cache2 which are mounted noexec and nosuid, what next?
//umar.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
