Re: Limiting Shell Access Damage (was Guruness)
Will H. Backman wrote: Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident. Apart from login.conf(5): It is really hard on UNIX(tm) systems to protect a system if users are conspiring to kill it. Therefore, the first rule should be to trust your users to a certain extent. Assume that the students are not dumb, but know that they will create code where malloc()'s are not free()'d (Leading to 800+Mb memory usage for a single process, login.conf(5) is your friend). Also, they will, after talking with their old somewhat nutty professor, attempt to write a simple protocol implementation in which every new incoming UDP packet results in a fork() being made Filesystem quotas can help a lot. So can process accounting in post-mortem analysis. A single odd-process-reaper running via cron(1) can do wonders to those 99%CPU spinning Matlab processes running under Linux-emulation where theres no source code fix. Remember to generalize the reaper and let the process accounting data be the guide of what to add. Do not underestimate the power of policy. A student having signed the Acceptable-Use-Policy form will not conspire as much against the system since the consequence is account deletion. Many computer users are accustomed to environments where there is a single user on a PC. A typical attack vector, however, for 1000+ account sites is a compromised account. You can assume at least 5 per 1000 accounts are compromised or have easily guessable passwords. Those will not heed your policy forms whatever you do. You can mitigate the risk by separating systems and limiting account access. When this is not possible, ProPolice, W^X, StackGhost, etc will come in very handy. Monitoring is also something you should ponder about. In general, students need the freedom to play -- they are in this to learn, so you should give them the freedom, but use policy enforcement if they abuse the freedom given. Network and filesystems can be monitored easily as well as memory, interrupt counts etc. The monitoring will make you able to act when something goes wrong in a quick manner. Beware of micro-management though.
Re: Limiting Shell Access Damage (was Guruness)
Hello! On Thu, Oct 20, 2005 at 11:01:55PM +0200, Jesper Louis Andersen wrote: [... what looks like good advice ...] A typical attack vector, however, for 1000+ account sites is a compromised account. You can assume at least 5 per 1000 accounts are compromised or have easily guessable passwords. Those will not heed your policy forms whatever you do. You can mitigate the risk by separating systems and limiting account access. When this is not possible, ProPolice, W^X, StackGhost, etc will come in very handy. You can mitigate the risk of guessable passwords by checking passwords on change, using the minpasswordlen and passwordcheck fields of login.conf. Set passwordtries to 0 so the user can't override the password policy by insisting on the bad password. [...] Kind regards, Hannah.
Re: Limiting Shell Access Damage (was Guruness)
Everything said to this point is very good... A typical attack vector, however, for 1000+ account sites is a compromised account. You can assume at least 5 per 1000 accounts are compromised or have easily guessable passwords. Those will not heed your policy forms whatever you do. You can mitigate the risk by separating systems and limiting account access. When this is not possible, ProPolice, W^X, StackGhost, etc will come in very handy. This is partly poo. ProPolice, W^X etc, will not help you from a compromised account. They may help in keeping that compromised account from escalating priviledge, but not from getting in. if you are running a public server it is absolutely necessary to make sure your passwords are not easily guessable. We do this with the passwordcheck program set up in login.conf. (See login.conf(8) for details). Now the gotcha is that while you need to be effective in what you check, being too simplisticly effecive in a password checker will reduce the search space so much that brute forcing the password becomes easy. (thinks like saying an 8 character password must have 4 numbers in it is really dumb). I've posted my checking script here before. Check the archives. -Bob
Re: Limiting Shell Access Damage (was Guruness)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of knitti Sent: Wednesday, October 19, 2005 5:23 AM To: Wolfpaw - Dale Corse Cc: misc@openbsd.org Subject: Re: Guruness (was the bug report thread) On 10/19/05, Wolfpaw - Dale Corse [EMAIL PROTECTED] wrote: Try something for me - toss 40 novice programmers on a machine, and let them hammer away at it. In this one, I think I have you beat, running a shell provider for muds, for almost 10 years - I can tell you, BSD does not stand up to it .. well, I don't know about BSD in general, but just try it with OpenBSD. If the machine is generally capable of this task (has the mem and power to suppert n sessions in parallel), it's just your task as admin to make it happen. The means are there. If your users bring down your machine it's most probably your own fault. --knitti Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident.
Re: Limiting Shell Access Damage (was Guruness)
On Wednesday, October 19, Will H. Backman wrote: Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident. A number of things... login.conf is your best friend. We used to run labs of OpenBSD machines here. They were easily our most stable and workable platform. --Toby.
Re: Limiting Shell Access Damage (was Guruness)
If you can port it, you can also use it on your own box, so where is the problem? No problem there.. Actually looking at the couple of functions I need here to see how difficult to integrate they would be. login.conf (5) Problem comes into play when a user starts say .. 50 Copies of the same thing, because it didn't boot.. They just keep hitting the button .. :( login.conf (5) Right, but login.conf either stops the usage dead, by allocating no more, or outright kills it (off the top of my head, I am not sure Which) - I think :( This causes problems with resource allocations When doing quick intensive tasks, like compiling, tar/gz, etc. Thank you for the suggestion though, I may try it out and see how Well it does with some users on it - it may well do just fine now :) D.
Re: Limiting Shell Access Damage (was Guruness)
Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident. Well, in a non-disto specific way, I have a couple that we use, if your interested: A) Process daemon checking, in 30 minute increments specifically for: - Processes using 80+% CPU - Processes over the set quota for that user (config file sets them per login) - Processes spawning 'sleep' consistently - A process with the same name, but a different ID, using the high resources. In all cases, the first time it sees the problem, its logged. The next time it is run, it loads that array, and if it sees it still going on, it sends the process a KILL. So in essence, they must do it for more then 30 minutes. Never seems to nail GCC or anything like that.. Since it changes ID's and names with each file. B) Limit outgoing access to IRC servers.. Usually and 6667 - many time someone puts in PHPBB or some such garbage, and it gets cracked. The uploaded executables tend to connect to IRC servers to be used as DDOS bots, or spam bots. C) Limit appropriately with login.conf as suggested - specifically stack size, coredumpsize, number of processes, and number of fd's D) Put each user it their own group, and make the user, the web server, and the email server a member of it. Then you can set it as only user and group rwx, and not have folks surfing around in the directories grabbing others files. May want to do the same thing with config files. We generally as I had said - use linux, which gives us GRSec, and XATTR for this .. But a least access policy to system configuration files is probably a safe bet, even if only done with the usual user/group mechanism. E) Put it on a 10Mbps port :) Stops too much damage is someone launches an attack from it. F) Implement login.access, and hosts.allow lists, controlled by a unix command, to limit specific IP's to accessing the machine at all, on priv. Ports, or using other peoples login ID's. Seems to keep unknowns from getting on the box mostly (barring social engineering :) because they need a user, a password, AND to be from the right ISP. G) Not sure if OpenBSD might have an equivalent to Linux OOM Killer.. But this has saved the box before, when things get out of control very quickly. I try not to use limits, because it slows compiling to crap :( We do some other things too, if you want some details, drop me an offlist Email :) -D.
Re: Limiting Shell Access Damage (was Guruness)
Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident. (Firsly, not mentioning restricted shells at all, because we all hate them, right? rksh? ) Back in the old days before umls or half a dozen other equally appropriate technologies which I would use in preference if I were doing it again today, I used to build a chroot environment with a minimal subset of commands and relevant data files for just this sort of thing. If y'all promise not to laugh, I found this code in my archives that I wrote in 1993. http://www.gtoal.com/historical/tcsh.c Obviously the layout of the filesystem will have changed over the years, but maybe there's something in there that's still salvagable. No, it's not hackproof, and I certainly would not write something like this nowadays, but the main reason I used this a dozen years ago was not to stop advanced hackers but to stop careless naive users (our customers, actually) doing something dangerous by accident, and to stop casual guest account visitors from browsing around the filesystem gratuitously. If you go the chroot route: this is from the linux world but probably adaptable: http://fakechroot.alioth.debian.org/ Also equally amusing in a historical sense is lsh.c in the same directory. Again, better ways exist to do that now (watch/ttysnoop). As well as full virtualization, you might look at copy-on-write filing systems to allow users to unwind mistakes. Nowadays I would use user mode linux or colinux to create a lightweight virtual machine and let them manage it completely, using c-o-ws as a quick way to revert if they screw it up. I don't what what the BSD equivalent of uml might be. A quick google search for 'virtual server bsd' shows that they do exist (http://www.esosoft.com/virtualserver/), at least for FreeBSD. If there's no specific OpenBSD lightweight virtualization then maybe you could use a more heavyweight emulation such as qemu (http://www.erikveen.dds.nl/qemupuppy/index.html) or plex86 (http://sourceforge.net/projects/plex86) or xen (http://www.xensource.com/, http://www.cl.cam.ac.uk/Research/SRG/netos/xen/) or vserver (http://www.solucorp.qc.ca/miscprj/s_context.hc) or many commercial products: virtualpc/vmware/openvz/serenity(svista)/ virtuozzo/parallels (microsoft, serenity and parallels have all had beta programs that allowed you to use their latest development products for an extended period, as opposed to the few weeks you usually get from a mere eval download. Of those I think parallels.com is the only one currently available) There's a pile of links on various subjects related to virtualization in my online bookmarks: http://www.gtoal.com/bookmarks/Computer_stuff/Virtual_PC/index.php (+ some misfiled under http://www.gtoal.com/bookmarks/Virtual_PC/index.php) and a lesser amount of relevant links in http://www.gtoal.com/bookmarks/Computer_stuff/Unix/index.php and http://www.gtoal.com/bookmarks/Computer_stuff/Security_backup_and_admin/index.php Another option is a live cd: http://www.freesbie.org/ or http://www.livebsd.com/ ... Maybe you'll find something of interest in there. If not, reading other people's bookmarks is almost as much fun as looking at their bookshelves :-) regards Graham
Re: Limiting Shell Access Damage (was Guruness)
On 10/19/05, Wolfpaw - Dale Corse [EMAIL PROTECTED] wrote: quickly. I try not to use limits, because it slows compiling to crap :( this makes no sense whatsoever.
Re: Limiting Shell Access Damage (was Guruness)
On 10/19/05, Wolfpaw - Dale Corse [EMAIL PROTECTED] wrote: quickly. I try not to use limits, because it slows compiling to crap :( this makes no sense whatsoever. To clarify, if you limit someone's ram use to a certain point, or CPU use to a certain point, it will slow down compiling due to having less resources :) As I said though - I may be wrong on this one. -D.
Re: Limiting Shell Access Damage (was Guruness)
From: Wolfpaw - Dale Corse [mailto:[EMAIL PROTECTED] On 10/19/05, Wolfpaw - Dale Corse [EMAIL PROTECTED] wrote: quickly. I try not to use limits, because it slows compiling to crap :( this makes no sense whatsoever. To clarify, if you limit someone's ram use to a certain point, or CPU use to a certain point, it will slow down compiling due to having less resources :) As I said though - I may be wrong on this one. Yes, that would be the idea of limiting resources. If I am given the ability to use 99% of the CPU compiling software, how is that different than me running a fork bomb and doing the same? DS
Re: Limiting Shell Access Damage (was Guruness)
Yes, that would be the idea of limiting resources. If I am given the ability to use 99% of the CPU compiling software, how is that different than me running a fork bomb and doing the same? In essanse I suppose it isn't - but if your (as in my case) selling shells, compiling is legitimate, and required use. When people do a lot of it, you just find other ways to deal with resource overuse. Not as well done as using limits.conf - but they work in most cases. -D.
Re: Limiting Shell Access Damage (was Guruness)
To clarify, if you limit someone's ram use to a certain point, or CPU use to a certain point, it will slow down compiling due to having less resources :) As I said though - I may be wrong on this one. Yes, that would be the idea of limiting resources. If I am given the ability to use 99% of the CPU compiling software, how is that different than me running a fork bomb and doing the same? Why are people jumping over each other, spreading horseshit like crazy? This is so wrong it's not even funny anymore...
