[nSLUG] Securing Linux with shell users

Ian Campbell ian at slu.ms
Thu Dec 11 13:06:53 AST 2008

On Thu, Dec 11, 2008 at 12:52:30PM -0400, D G Teed wrote:
> This is one of those topics where googling for information
> is finding either the wrong topic (secure web services),
> or it turns up ancient information which does not apply
> for modern Linux distros.
> By default, telnet isn't open on modern Linux, and we
> have an iptables firewall with only necessary ports open.
> I am looking for a resource on setting up a server
> with Academic shell users, with the aim of preventing
> local exploits.
> I'm working on a new server install so it is a good opportunity
> to set it up right from the start.
> For example, Redhat ships sshd with allowing root logins by default.
> So we always disable that.  We also use a program to scan
> login attempts, to close the door on ssh brute force attempts.
> We can add ulimit values and a user quota.  I want to
> expand on this kind of thing.
> This isn't going to be as ultra-restricted as many examples
> I could think of as we need to allow access to compilers.
> Is there a methodology common to ISPs?  Some of it would
> fit our case I imagine.

Most ISPs with any sense don't provide shell access anymore, given the
difficulty of securing it properly and still providing a
useful/pleasant service.

You haven't given enough information for anyone to answer the question
-- basically you need to enumerate (as much as possible anyway)
everything users should be able to do with the machine, and then
remove everything else.

For example, you need to provide access to compilers, but do you need
to provide the ability for users to run the compiled binaries, or is
it just a compile farm? You're blocking inbound traffic except on
given ports, but are you blocking outbound traffic? What about
loopback traffic?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20081211/ee1d75eb/attachment-0002.pgp>

More information about the nSLUG mailing list