PDA

View Full Version : Guide to running the server securely (chroot)!


askwar
09-05-2003, 19:36
Hello.

On my server, I've setup TSS2 to run in chroot. A chroot is a directory into which a process changes and afterwards cannot leave it. This is good practice security wise, because even if there are security holes which allow the server process to be overtaken, the attacker can not leave the chroot directory.

To do so, I had to make sure that the process is able to run in this restricted environment. This means, that I created the following directories:

etc
dev
lib
tmp
usr
usr/lib
usr/lib/gconv
usr/lib/locale
var
var/run

These directories are all in the installation directory of the TSS2 server.

I then copied the following files into the corresponding directories in the chroot:

/etc/group
/etc/ld.so.conf
/etc/localtime
/etc/passwd
/lib/ld-linux.so.2
/lib/libc.so.6
/lib/libdl.so.2
/lib/libncurses.so.5
/lib/libpthread.so.0
/usr/lib/gconv/ISO8859-15.so
/usr/lib/gconv/gconv-modules
/usr/lib/locale/locale-archive

TSS2 needs /dev/null, which has to be created in the chroot (took me QUITE a while to figure that out :D). As root, change into the dev directory in the installation directory and do:


mknod null c 1 3
chmod 0666 null


With the attached startup script, I'm successfully starting TSS2 rc2 on my Debian Woody (3.0) server.

Cheers,

Alexander

bhurley77
11-06-2003, 01:02
Thanks for pointing the way, you saved me a lot of time. I adapted your instructions to RedHat 9 in the attachment.

Cheers,

Brian

evil_bunnY
24-06-2003, 17:07
it sounds, nice, except if you copy /etc/group and /etc/shadow, you might as well not bother with the chroot, because it'll just delay things.
(explanation: you can just let jack the ripper loose on the shadow file, and it'll take a while, but it'll break it.)
might improve the situation by moving to another type of encryption, like 3DES instead of MD5.

askwar
24-06-2003, 17:55
I don't know anymore, did I write to copy these files? You're right of course that this is bad. However, you can also put some dummy files there with no/wrong authentication details in /etc/shadow.

But where's the risk in copying /etc/group?

evil_bunnY
26-06-2003, 00:05
Originally posted by askwar
I don't know anymore, did I write to copy these files? You're right of course that this is bad. However, you can also put some dummy files there with no/wrong authentication details in /etc/shadow.

But where's the risk in copying /etc/group?


well look in your group file my friend: it lists valid logins.
it wont give the passwords, if for example, if you forbid remote root logins (and you should) on your SSH server (run telnet and "ill kill you") it gives attacker a pretty reliable list of possible logins.
if you have stupid users with weak passwords, bam hes in.

but i have to be honest you didnt tell to copy /etc/shadow, and linux machines without a shadow system are very rare nowadays, so thats a good thing.

remember: the principle of the chroot to give it as little as possible thats connected to/usable on the actuall tree.
hope im clear, just reply if you have questions.


have fun.

askwar
26-06-2003, 07:14
No, the group file does not (necessarily) list valid logins. It lists group names and their group ids.

But you're right. You shouldn't copy /etc/group and /etc/passwd but it would be better to create new files in the chroot which only list the groups/users that are really necessary.

mjrwoody
22-10-2003, 16:38
I adapted your instructions to RedHat 9 in the attachment.


For RH 7.3 your startup script and directions worked great with the following tweaks:

- * /lib/libncurses.so.5 -- This doesn't exist. Used /usr/lib/libncurses.so.5 instead, and copied to the correct chroot'ed /home/usr/lib directory.
- * /usr/lib/locale/locale-archive -- This doesn't exist, didn't substitute anything.

Also, i was converting an existing "running as root" server (d'oh!) to chroot. Here's what else i had to do:

/home/tss2 was my home dir. Had to "chown" the whole directory to "teamspeak:teamspeak" recursively (in /home run 'chown teamspeak:teamspeak tss2/ -R')

Thanks for the great script!

Andrew Myers
31-10-2003, 23:13
Here's yet another TeamSpeak chroot server script (instructions included). Primarily focused on RH9, but there's info that'd probably be useful if you were trying to get it to work on other distros.

[url removed, see message down-thread].

Near as I can tell, I only really needed:

/lib/ld-linux.so.2
/lib/libc.so.6
/lib/libdl.so.2
/lib/libpthread.so.0

and

/dev/null.

I also copied over /lib/libNoVersion.so.1 for good measure, since it shows up on the list if you ldd it.

Didn't seem to need /etc/passwd, /etc/group, or other stuff, the locale stuff, and so forth.

Haven't had it up that long, so perhaps I'm overlooking something, we'll see :)

Peter
01-11-2003, 11:39
Note:

change root-ing your server is a security thing you can do, but much more important (read: if you dont do this, dont bother with chroot) would be to run the teamspeak process as somebody else than root. Dunno if somebody could write a nice post on how to do that, but you can certanly find some start scripts that do it, if you search for "#!/bin/bash".

Brain
01-11-2003, 13:05
... and, maybe even more important, don't use your goldfish's name for your SA account password. :)

Andrew Myers
01-11-2003, 18:09
Originally posted by pwk.linuxfan
Note:

change root-ing your server is a security thing you can do, but much more important (read: if you dont do this, dont bother with chroot) would be to run the teamspeak process as somebody else than root. Dunno if somebody could write a nice post on how to do that, but you can certanly find some start scripts that do it, if you search for "#!/bin/bash".
Yep, absolutely true -- the script I posted (as do the others above) run TeamSpeak as the designated user *and* chroot it. The script I linked earlier does just that.

chroot'ing is something that's easy to do in *addition* to running the process as a restricted user.

Peter
01-11-2003, 21:45
Well,

i didnt view your script :). Maybe you make it clear in your post (edit comes to mind) that it runs a special (non root) user....

indy25
07-11-2003, 00:38
Hmmkay, I'm a bit new to this scripting malarkey, but I've looked thru the scripts here and I have a few questions.

I can see that the debian script will definately run as the tss user as it has a chuid th set the uid of the process.

For the RH9 version, from what I can see, the process will still be run as root. Or does the fact that you've chroot-ed to a directory that is owned by U tss and G tss force it. Note the fact that if a directory is owned by a non-root user and group, root can still run any executable in that directory.

I've run the various scripts that have been available and they run the server as root unless you've logged in as tss user first.

indy25
11-11-2003, 09:04
Hokay, fully read thru the script, and got mine running chroot-ed. Didn't notice first read thru the chmod 6700 on server_linux.

Sorry for doubting you guys. :)

Andrew Myers
02-03-2005, 19:57
Switched from RH9 to Debian (sarge) a while back; attached is the /etc/init.d/tss2 script I currently use to start TeamSpeak2 as the tss2:tss2 user:group, in a chroot jail.

See tips further up the topic re: which files need to be copied where, etc.

TheDrew
21-10-2005, 10:25
And for the Gentoo Users...

aorevolt
06-02-2006, 23:13
The only files I added to the tss home directory are:

~/etc/localtime (not needed, but without, server reports time in GMT -> or BIOS time)

~/lib/ld-linux.so.2
~/lib/libc.so.6
~/lib/libdl.so.2
~/lib/libpthread.so.0

~/dev/null

You can also move files like ~/Manual/ and such... although...

~/tcpquerydocs/ <- required for telnet interface
~/httpdocs/ <- required for http interface
~/sqlite.so && ~/sqlite_sql/ <- required if you use sqlite
~/libsqlmy.so && ~/mysql_sql/ <-- required if you use mysql

-----
I'm kindah new to chroot and linux so if my files I've listed are to minimal, or whatever, then just post your problems. BTW directories need "x" access for user tss, but all files/directories do not need to have write access. ~/dev/null ~/bad_names.txt ~/server.??? are the only files that have write access on my system. You could probably turn off write access on the server.??? files too, but it will give an error durring startup, and changing settings/adding users will be impossible. Good way to prevent stupid admins from give SA authority though, once you have all your users setup :rolleyes:

mpaket
05-03-2006, 18:20
can someone send me please your main-chroot-ts directory (or attach it here)? i have problems running my teamspeak because of this damn segmentation fault.
if you can run ts in chroot, it should be possible for me to run ts too with your files!
my system is debian sarge :)
thx