Bubba shell security

[limpo]

Hi,

Currently bubba samba is not encrypting the traffic from the client to the server(this allows for a tcp attack, to gain access to transmitted content),in this day an age you cant trust the internet or your lan users from sniffing you(is just to damn easy to do).
But everyone needs a way to download upload files.

Whats currently installed in bubba is ssh with sftp and scp support, this will give your users encrypted access of file transfers. The only drawback of this from a root or admin point of view. Is that the users are allowed shell access in the entiry root filesystem, so they can poke around an figure things out about your configuration and security settings to find exploits to use. There are solutions to this to use ssh2(different licens than openssh) or scripts that create a chrooted enviroment for you(though not with your current users home folder, but a newly created chrooted enviroment).
Sorry for the long text, but Im getting security paranoid

What I am getting at is are there any other ways of getting a secure chroot to your users homes(scp/sftp) without shell access and having to create a totally new chroot enviroment ?

THX
/Limpo

[bjorn]

Hi,

you should check out "scponly" http://sublimation.org/scponly/wiki/index.php/Main_Page. It has options to lock users to a chrooted home.

scponly is available from debian repositories. However, the version available from Sarge repo's are of verision 4.0, and as read on the scponly site, all versions prior to 4.1 has exploits to enable users to breakout of jail and become root!. Downloading and compiling latest version IS recommended, unsure if debian-version is patched against this flaw.

I've used scponly a couple of times (not on bubba or with chrooted home though) and it works well for getting'n'putting files to the host.

Check it out, have fun.

/Bjorn

[limpo]

Hi,

Great I had actually looked at this , but I dont think it supports chroot from the users homefolders, you have to create a new chroot home enviroment. And then you would have too enviroments, one in /home/$user and one for example in /chroot/user(for scp and sftp).

As stated on the scponly page "It is very important that the user's home directory be unwritable by the user, as a writable homedir will make it possible for users to subvert scponly by modifying ssh configuration files."

What Im looking for is a chroot to /home/$user, but still be able to have Maildir and such still working.

/Limpo

[Ubi]

That is impossible. In Linux (any version) the user can always edit files in his/her home dir.

I don't see the functionality in your paranoia however. The system should be locked down anyway, and shell users shouldnt be able to do or see anything they are not supposed to. Patching the login because you were sloppy in securing config files is not a good way to secure a system, especially if the user can have a html dir (in which case the chroot won;t help the slightest bit).

Ubi

[limpo]

Hi Ubi,

I think you missunderstod me, because I wasnt to clear.
With the scp only you have to create a new chroot enviroment that is different from your normal /home/$user. Ex, you would then have your normal homedir /home/$user and your scp only capable chroot dir /chroot/user.
And this new chroot cant be writable by anyone, becasue then they can break out of the chroot.
And it is right as you say, default in linux the users home dir is writable by the owner.

Why my paranoia, well even if you secure your system(setting very restrictive rights, denying users, configure services for secure settings) and then let your users use ssh for shell access for secure filetranfer, homefolder access , etc. The users can then traverse your filesystem and read configurationfiles(some has to be world readable) and figure out what versions you are using on different services and tools, to find exploits to use. And in this dayn age attacks are coordinated from the inside(users) with the internet(hackers, crackers). And using samba for filetransfer and homefolder access is supposedly susceptible to tcp attacks that give you access to a logdon samba users home content, by sniffing the traffic. And the encrypted samba passwords are sniffed and cracked with L0pthrcrack.

And the solutions are to use:
chroot scripts/patches or ssh2(but it is only free of use for private/educational)

/Limpo

[Tim]

Hi limpo,

There is an active thread on slashdot about the use/abuse of chroot - http://it.slashdot.org/article.pl?sid=07/09/27/2256235 It is based on an article at Kernal Trap with an interesting quote by Alan Cox http://kerneltrap.org/Linux/Abusing_chroot

I hope this helps.

/Tim

[Ubi]

Exactly

If you're that overparanoid about security you should not let users log onto your server directly anyway, but dedicate a separate machine for it. Access to files can then be made by having the server spill data to the login machine.

I have yet to find the first config file of a serious app that "has to be" world readable. Let alone that such a file will have any security implication whatsoever.

Besides if you keep your patches up to date there is no worries about people knowing your versions. They can find that out easily anyway via other means.

ubi

[limpo]

Hi,

Thanx Tim that was interesting reading

Ubi indeed you are correct, it is a good strategy to have a dedicated linux server box just for you services and one for your users with shell access.

But currently I only have bubba as a dedicated server, and dont have any plans on setting up a second one for just my services. So Ill try the best I can with what Ive got.

Be carful not to be to confident, that leads to the dark side:)
"I have yet to find the first config file of a serious app that "has to be" world readable. Let alone that such a file will have any security implication whatsoever."

And your last statement is also correct,
"Besides if you keep your patches up to date there is no worries about people knowing your versions. They can find that out easily anyway via other means."

But what you call paranoia is something that is more becoming mainstream. Today we are all more or less always connected to the internet and we want to access our different services at home over the internet. And attacks are always ongoing, if it hasent happend to you yet it will. So one can only try to be as prepared as one can be until that day.

What it all comes down to for me is that I dont want to allow shell access for my users, but allow them to download/upload files to their homefolders over the internet. And for that I need it to be secure. What Ive found is that I could use proftp with tls/ssl, indeed it still uses the chroot command which has exploits. But at least its security by obscurity(I know its never a good alternative to the real thing). This is easier than using ssh and setting the shell to /sbin/sftp.

Please anyone if there are better alternatives please tell!

/Limpo

[Ubi]

So what you have is the possibility that someone somehow manages to upload a file that is then selected by a root-priviledged process to run and then take over your machine. Yes this is theoretically possible.

The likeliness of this is however so incredibly small (given the fact that every ISP in the world allows unencrypted ftp for literally billions of clients) the chance that you're the one to be attacked this way is much smaller than a scriptkiddie attack on the apache headers, the SMTP engine or the TCP frame stack, yet you do not seem to care about those at all (hint: SSL does not prevent attacks there at all).

[limpo]

Hi Ubi,

Indeed it sounds remote. But it could happen if you have critical info that a hacker(has insider info) is directed at getting.

So your are saying, screw all security because its a remote chans that you would ever be targetted?

I say try at your best abilites and then at least you would have some protection, read up on the rest.

And as far as the FTP at the ISP goes, they are most likely running dedicated virtual machine for only FTP logins, no other critical services(and mostly they do support FTPS or SFTP)

What do you mean I dont care about apache, smtp or TCP security, I do!
Its just that for apache, most of the attacks are of DoS sort and you can often tweak/limit these. In the worst case you have to restart the apache daemon.

For the headers Im not quite sure how to protect yourself but I guess one could use a proxy with some security implimentation(header checks/rewrite rule set).

The same goes for the SMTP use a filtering proxy(Spam/virus) or do you mean after an intruder has executed injected code onto the system? Then theres not much to do but, backup important stuff and load your last full backup(to be on the safe side).

The TCP frame im not quite sure about, but I would go with iptables/netfilter and drop or deny TCP SYN.

Thanx by the way for all the great info, please Im intrigued tell me more how these could be put into effect or if there are anyother security explotation one should no how to protect oneself from on a linux system(of course I understands there are thousands, but the most important once).

PS. By the way Im no security expert in anyway, these are just specilations
/Limpo