[nSLUG] Securing Linux with shell users

Ian Campbell ian at slu.ms
Thu Dec 11 15:01:51 AST 2008

On Thu, Dec 11, 2008 at 02:32:11PM -0400, D G Teed wrote:
> On Thu, Dec 11, 2008 at 1:06 PM, Ian Campbell <ian at slu.ms> wrote:
> > 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?
> >
> Some ISPs do offer shell access.  Generally they want some ID so they have
> something solid on who to come after.  We have the equivalent in our case.

I said most, not all. ID only helps you with the expected account user, it doesn't do
anything for you if the account has been compromised in some way...

> I didn't want to discuss excessive details of our set
> up in a public forum, and I certainly don't expect
> someone to do the analysis for me.  I'm mainly looking
> for the checklist type of document and then I can
> consider the ones that apply.  I would have thought
> this exists, perhaps in a book form as I've seen
> before regarding writing CGIs.  But as we've discussed
> here before, print matter is becoming a rarity in IT
> these days.

Search engines are a wonderful thing. I suggest "linux security
checklist" or "securing linux checklist." There's a lot of old cruft,
but there are plenty of recent ones. If you're looking for something a
bit bigger name than the various CERTs, try the NSA checklist.

... but they're all still basic stuff: "Turn off unused services", "Use
strong passwords", because you can't generalize security, and your
setup puts unique restrictions on you. They're not going to go into
application-specific details on whether
virtualization/chroots/jails/whatever are a good fit or even possible.
They're not likely to mention selinux, and they almost certainly won't
mention PaX. 
-------------- 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/561b59f4/attachment-0002.pgp>

More information about the nSLUG mailing list