Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
With the way the job market is, I had a bunch of free time to get a computer together and I am working on creating a free shell account community.
I don't want people to be able to make outgoing connections on my computer, because they like to do things that will get me in trouble.
A lot of shell providers block outgoing connections made by users who aren't supposed to, do they do it using iptables or something else? I can do it with iptables but I'd like to know how other people are doing what I'm trying to do.
Yes, you can do it with iptables. But what if iptables for some bizarre and unknown reason fails (don't say it won't happen)? Do you have a second line of defense, or will this be a single point of failure? Besides that, and I'm not about to spread FUD here, but parts of iptables are *still* considered Alpha quality. No one can predict a vulnerability within the Netfilter framework, but we've seen this twice already.
The most secure way I can propose is running a Grsecurity-patched kernel. Grsecurity has a lot of features you will want on a shellserver box to aid you defending your resources.
Some notable features:
- PAX mmap/stack and /dev/kmem protection against *some* forms of exploitation,
- /tmp race protection,
- deny creating (any|client|server) sockets per group of users,
- deny seeing processes outside own UID for any user,
- deny running binaries outside the trusted path (TPE) for a group
- fork protection for users with proper ulimits set,
- extensive auditing and logging
- ACL's on processes.
*If you think this is too much hassle (or features) wrt what you're trying to accomplish, then maybe it's time you evaluate again what you're trying to do... If you think this will be usefull but want some examples, just post a scenario for a typical user on your box and we'll try and whip up a case.
Note this isn't *all* you have to do to secure your shellserver.
Please have a look at the Security references thread.
I invite you to post any other issues you have wrt securing the shellserver in this thread, the total Q&A when finished should make for a nice checklist and good reading for anyone trying to do the same...
Today I got the 2.4.21 kernel source and patched it with grsecurity 1.9.10 and then I went and installed gradm 1.9.10. The coolest thing I noticed without doing any hard work is the process list. As a regular user a lot of processes are not visible, and as root you can see it all. I included a snippet to show what I mean:
Yes, neat, innit? :-]
Now have a look at the ACL's. Cummon. Make a few dirs "disappear". Good fun. If you want to commence along the "hardening your distro" path, then make /tmp or some /var/log/files disappear, and see how daemons react to that :-]
Also get aquainted with the audit and logging stuff. That could come in handy as well.