Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Setting up community access boxes

By omegadave in Internet
Thu Oct 26, 2000 at 07:43:30 AM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

Recently, I have had many people ask me to help them learn to use Linux. Unfortunately, I do not have the time or patience to go around teaching everyone. A friend of mine suggested setting up one of my home boxes as a server to provide everyone with shell accounts. The thing is, I have no idea how to do this!


What I what to know is, has anyone is the K5 community ever done something like this? I would be interested in the feedback others could supply, such as tips or pitfalls they experienced.

The box my friend and I were going to use will probably be running Debian Gnu/Linux potato, with users logging in through using ssh. The services we want to provide are the same ones given to any Linux user, such as perl, the gnu c compiler, and mail accounts.

I have no idea how to do this, albeit, in a way that would be scaleable, secure, and manageable. I am open to any suggestions or criticisms, though we do /not/ wish to use OpenBSD simply because we were hoping to learn something from this.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Is a community box a good way to help new users learn how to use Linux?
o yes 78%
o no 21%

Votes: 57
Results | Other Polls

Related Links
o Also by omegadave


Display: Sort:
Setting up community access boxes | 18 comments (16 topical, 2 editorial, 0 hidden)
Good idea (3.00 / 4) (#1)
by maketo on Thu Oct 26, 2000 at 01:40:44 AM EST

However make sure you devise a criteria on who and how gets an account. Then the security policy comes in. And then also knowing that you might get burned (and responsible for potential damage).
agents, bugs, nanites....see the connection?
What type of criteria? (3.00 / 2) (#2)
by omegadave on Thu Oct 26, 2000 at 01:45:02 AM EST

What type of criteria do you recommend? I wasn't planning on giving just anyone an account, mainly people in my school and anyone in my LUG. Also, how might I get burned and be responsible for something. What could people do that would get me in trouble. I honestly don't know, so I glad you pointed this out.

[ Parent ]
How to get burned in one easy step... (3.66 / 3) (#8)
by Miniluv on Thu Oct 26, 2000 at 03:16:15 AM EST

What may get you in trouble is this:
You setup said box, you do your best to secure it, but nobody can make an unrootable box, well, not short of dropping it into the mariana trench sans keyboard. So the box gets rooted by your neighborhood hAx0r, who sets it up to do any number of naughty things...DDoS maybe, or perhaps he goes on a string of port scans from your ip. Eventually some Big Company sees said scans, and the security admin is bored, so he calls your ISP bitching about it, and the ISP has gotten three or four of these calls now. You end up losing your account because the ISP accuses YOU of hacking. Worst case? There's files stored on that server indicating it was used to penetrate and damage random systems on the net...depending on your locale you might end up facing prosecution.
Yeah, it's a hard to swallow string of events, but law enforcement, ISP security officers, and corporate security officers are stretched to the limit lately with the rash of incidents and suddenly heightened public awareness. Nobody wants to see somebody go through that who hasn't brought it on themselves.

See a different post of mine for MY recommendations on what to do to go about this, cuz I have done it sucessfully.
"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

Complaining to ISPs (2.50 / 2) (#15)
by terran on Fri Oct 27, 2000 at 12:40:38 PM EST

I may just be hallucinating, but I remember a time when if one had a complaint with actions coming from a certain machine, one complained to the administrator of that machine.

Your comment made me realize that these days, nobody bothers complaining to the admin of a box anymore. They go directly to whoever owns the block of IPs that the machine is on. Why do they do this? There may be a good reason, but I can't think of one. I have a sufficiently cynical opinion of people in general that I'm willing to attribute it to general assholishness.

I do try to be more considerate than this, and will send mail to the administrator of a machine if I have a complaint, assuming the machine accepts SMTP connections. If somebody's had their box cracked, they have enough problems already without me complaining to their upstream provider because I can't be bothered to ask them what's going on first.

[ Parent ]
Depends on who owns the IP... (2.50 / 2) (#17)
by Miniluv on Sat Oct 28, 2000 at 12:09:51 AM EST

In this situation, my warning was intended towards someone using a "home" services provider, such as @home for cable, or Covad for DSL in the states. Incident response, especially when it's "preventative" is tricky all the way around, and the industry is still fumbling towards some form of standard.

I agree with your approach, and it's what I practice myself, when it comes up, but if my box were cracked and I didn't see it, I'd more likely expect to hear from my ISP than someone emailing me direct, because I have no netblock.

Also bear in mind, a place I used to work had three security officers for 8 major online projects, each of which was portscanned on an average of 100-150 times a day. These portscans led to about a 40% attack ratio, plus the stuff that didn't come up on the automated scanner I helped monitor, but did show up in more customized, somewhat hand-rolled, anomaly detection systems. If it came from a netblock showing as anything close to "home services" provider, we called the ISP with a time and an IP address and offered to email them the log files, but we didn't have time for anything more. There was no reverse DNS to work with, and we certainly weren't trying to email an IP address hoping we wouldn't get bounce messages. Especially when we had 6 or 8 incidents on a single major ISP at a time.


"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

Incompatible Timesharing System (4.16 / 6) (#3)
by Sunir on Thu Oct 26, 2000 at 02:14:59 AM EST

In order to round out the practical considerations, you may want to read Richard Stallman's Lecture at KTH where he discusses the Incompatible Timesharing System. A quote:
...That machine wasn't designed also to support the phenomenon called "tourism". Now "tourism" is a very old tradition at the AI lab, that went along with our other forms of anarchy, and that was that we'd let outsiders come and use the machine.
That lecture is very long, but it's good. If you want the basic jist, there are more excerpts on MeatballWiki, including several about the ITS. ITS is also the inspiration behind much of our ideas on soft security.

On the other hand, you may also want to check out WorkSpot, which offers web-based Linux accounts (don't ask me); M-Net, the first public access Unix system (check out the rootprompt article).

"Look! You're free! Go, and be free!" and everyone hated it for that. --r

PHPWiki (3.00 / 1) (#10)
by ramses0 on Thu Oct 26, 2000 at 11:34:28 AM EST

<p>I've worked with a PHP-Wiki, and I can highly recommend it for a simple and easy way for people to share information.

<p>It's really not useful for anything more than a glorified white-board (anybody can edit and erase anything), but that's kindof what makes it useful.

<p><a href="http://wcsb.org/~swain/">This guy</a> wrote it, and you can download it from here: <a href="http://freshmeat.net/appindex/2000/02/23/951341584.html">http://freshmeat.net/appindex/2000/02/23/951341584.html</a>

<p>If you're running php3, it's literally as simple as untar and go. If you're running php4, you've got to rename all the files, and make sure that everything links up, but it's a really easy to use system.

<p>--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]
Bad idea. (2.87 / 8) (#6)
by gblues on Thu Oct 26, 2000 at 02:56:39 AM EST

If you have no idea what you are doing, you really don't want to give the entire world access to your machine. You might as well say "root me, please!" because someone will root you, either through a service 'sploit or (more likely) a root exploit on one of your system utilities.

Unless you plan out *exactly* which binaries will be allowed to be run on the public server, and verify you have updated versions of *all* of those binaries, and work out putting the home directories on a non-executable partition, compiling your kernel without module support, shadow passwords, SSH, yadda yadda yadda.. it's a lot of effort, and all it takes is one binary in the wrong spot to botch it up.

Nathan
... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
Re: Bad idea. (3.75 / 4) (#7)
by omegadave on Thu Oct 26, 2000 at 03:02:20 AM EST

I had hoped I had made it clear in the article that I posted this article for the express purpose of finding out some of the 'gotchas' that others might have experienced. I understand the implications of opening myself up to the world, in fact, I've understood them ever since I got a cable modem connection a year ago. Also, I think you went a little overboard in some of your recommendations. For example, why would I compile a kernel without module support? If there is a good reason, please tell me why, rather than just saying 'don't do it'.

[ Parent ]
Community boxes can be fun... (4.22 / 9) (#9)
by Miniluv on Thu Oct 26, 2000 at 03:25:18 AM EST

I ran one for a while, FreeBSD box for friends who needed a compiler, perl parser, and generally wanted to learn *nix.

Anyhow, the first thing I did was not expose this machine directly to the net. I put it behind a firewall which I was comfortable with the security of...it was rootable I'm sure, but I couldn't easily find a hole, and I monitored it carefully with network and host based intrusion detection, anomally AND signature based, as well as tripwire on important files with the hashes on a cdr. Now I just setup a non-standard SSH port to forward from the firewall back to the box that was to become my community machine.

Part of the advantage to this approach is not having to turn off every single service people might want to know about. Chargen is a great troubleshooting tool, but it's a security and DOS nightmare, shielding the box from the net to an extent allowed me to leave this service available, and demonstrate both the use of it and packet sniffers to my friends who were interested.

Next, I created two classes of user who was needing access, the ones who wanted to compile and that's it, and the ones who wanted to learn more. The first group got custom designed home directories that were chrooted, into which I dropped the binaries they needed and nothing more. I removed their access to EVERYTHING else. The second class got real accounts, with real home directories. Fortunately this group was a lot smaller, and thus easier to grant privileges to. I was also an inquisitive bastard and ran ttysnoop so I could keep a general idea on what these folks did with their accounts.

I did continually keep up on local root exploits on bugtraq, made sure I patched binaries and libraries as they became fixed, etc.

The best part was of course carrying on ICQ or IRC conversations with these people as I walked them through various admin tasks, slowly granting them more privilege through sudo until they gained familiarity with tasks they were likely to face in the workplace if they went that route.

One of the big benefits I got was that I had to know what I was doing, I learned an awful lot about my system that I never would've noticed otherwise because of their questions. Teaching people about something is the best way to learn it yourself.

Have fun setting yer box, and don't let the doom sayers say it can't be done. It'll be a trial and error process, and you'll have some frustration, but keep pluggin' away at it, and sooner rather than later you'll have a heck of a fun community machine for everyone to enjoy. I'd also advise having people come over and HELP you set it up, some of those folks who wanna learn maybe?
"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

got to be careful with sudo... (4.00 / 1) (#13)
by mulvaney on Fri Oct 27, 2000 at 01:56:27 AM EST

It sounds like you really know what you are doing, so I'm sure that you already know this, but I thought it might be useful for other people out there reading.

You have to be really careful with sudo. For those of you who don't know, sudo is a program that runs other programs as root. There is a sudoers file, which lists who may sudo what. this is a way to give users some powers of root, without giving away the whole potato.

There are two ways to configure sudo: one is to say "these are the things that this user is allowed to do", and the other is "these are the things that the user is NOT allowed to do." You should always use the former. And you must be very careful about what you allow users to run; if you allow them to use emacs or vi or less or any other program that gives someone a shell, you just game them root.

Using the list of deny programs doesn't work at all. This is how we do it where I work. It says, you can do anything except 'csh', 'sh', 'tcsh', 'reboot', 'halt'. The problem with this is that it only takes two lines to get a root shell:

% cp /bin/sh asdf
% sudo asdf

Since asdf isn't in your list of denied programs, it lets you run it.

Giving away any kind of root power is extremely dangerous, and you should tread lightly.

Mike

PS: sudo can still be a good thing, because it can be configured to log actions. So if you trust your users enough to give them root but still want to know when they use it, it can be a useful tool. In the above example, you wouldn't know what I did in my root shell, but you could tell that I sudo'ed 'asdf' which would look suspicious to say the least.

[ Parent ]
Combination approach... (3.00 / 2) (#16)
by Miniluv on Sat Oct 28, 2000 at 12:03:32 AM EST

I've had a wee bit of practice writing sudoer's files, yes. *grin* But you brought up a very very good point. I'm of the camp of least possible access, everything not explicitly allowed is denied.

I actually take a combination approach, because I don't feel like having a ten page, hard to maintain sudoers file, so instead I use directories. My eventual goal is to replace /bin, /sbin and the like with my own, custom crafted directories full of symbolic links, or perhaps even copied, statically linked executables. Then I can just point to one directory with no exclusions and know that I can sleep with only one eye open, and that can blink from time to time on my 'tail -f /var/sudolog' display.

But, currently I'm stuck listing a directory, then carefully deciding exactly how I'd root my box with every binary in there, until I decide that certain ones are apparently safe. I'd really like to be able to use sudo to specify more about what users can do as root...I'd rather not have to give them 'cp' to and from /etc, let alone vi or emacs into /etc or /dev, but how about if they need to edit /usr/local/etc instead? Hrm...maybe it's time I doodled in the sudo code...
"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

never allow sudo vi or emacs (none / 0) (#18)
by mulvaney on Sat Nov 04, 2000 at 10:45:54 PM EST

You cannot allow users to run programs like vi or emacs as root. Even if you try to limit the directories they can run them in. If you allow emacs, then all I have to type is "sudo emacs" followed by "M-x shell", and presto! a root shell account.

It is just as easy in vi or less, but I forget the commands. Believe me, this is how I added myself to the sudoers file at work. My office mate had sudo, and he just did a 'sudo vi', followed by whatever the shell escape command is in vi. From there, he had a root shell, and ran the 'visudoers' command, and added me to the list.

(I am supposed to have sudo anyway, so we weren't really breaking in. It was just easier to do that than it was to go through the proper channels and get the IT guys to do it 2 weeks later.)

Basically, people are root or they are not. It is almost impossible to allow users to run some commands as root without giving away the keys to the kingdom.

Mike

[ Parent ]
Local security (3.00 / 1) (#11)
by tzanger on Thu Oct 26, 2000 at 11:56:21 AM EST

I'm pretty damn good at network level security. However I am a complete clueless newbie at local (shell) security. How do I do it?

I'd like to give people the ability to compile (C/C++), play with perl, etc... I mean that's half the fun of a shell account... but I need to know how to make the shell "safe" -- chroot is painful and its usefulness is dubious: there are countless chroot jail breaker programs once root is achieved.

Ultimately it'd be nice to provide X services as well but that's another story.



Free Unix access? (3.66 / 3) (#12)
by spaceghoti on Thu Oct 26, 2000 at 05:25:35 PM EST

Much as I hate to say it, it's already been done. I get my email through Nyx Net, based out of Denver. The service is run by a professor/sysadmin at Denver University, and you can find out more about it at www.nyx.net. I first signed up in 1992, and I'm still with it.

However, the machine is down today. They have some thousands of users, and some of them like to hack unsecured systems. Maybe for practice, maybe out of sheer malice, who knows? The other problem is that this is a user-funded system that relies on donations and old hardware. They don't force anyone to pay to use the service, but they have to have a minimum amount of donations or the service will go belly-up. Still, a $20 donation every other month is cheaper than most of the online services you'll find out there.



"Humor. It is a difficult concept. It is not logical." -Saavik, ST: Wrath of Khan

another good one (3.00 / 1) (#14)
by nomadlogic on Fri Oct 27, 2000 at 11:27:36 AM EST

how about arbornet.org? much like the server you mentioned. running freeBSD, it's got bbs' galore, a good chat system called "party" and some good console games (any one remeber drug dealer?). like nyx.net, it's a public system, but i've havn't had problems accessing it in a while. the login script for new commers is straight forward, and the sys. ops. are pretty great to boot. I'm a little hisitant to let the word out ;-) but anyone intersted in starting something like this should check it out.

[ Parent ]
Setting up community access boxes | 18 comments (16 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!