Date: Thu, 20 Nov 1997 18:42:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@sdf.com (Tom) Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, craig@ProGroup.COM, hackers@FreeBSD.ORG Subject: Re: Partitioning suggestions? Message-ID: <199711201842.LAA11374@usr01.primenet.com> In-Reply-To: <Pine.BSF.3.95q.971119184734.28359B-100000@misery.sdf.com> from "Tom" at Nov 19, 97 06:50:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I can't accept that idea of a "graceful" failure. I don't know if there > > > are any "catastrophic" (ie. eaten e-mail, destroyed password > > > files, etc) failures in FreeBSD, due to full filesystems. But the > > > so-called graceful failures are the real essence of this thread. How do > > > you avoid them in the first place? > > > > By not engaging in sysadm pilot error that results in filled drives. > > In what universe is this? Point me to a mail server that you use, and > I will fill one or more filesystems for you. Then when done, I will blame > it on your pilot error. It will start refusing your mail as originating from a mail bomber based on hueristics before that could happen. If this failed, and it didn't, then it would start refusing your mail on the basis of my account being over quota, since unlike stupid configurations, my mail server is set up to deliver mail directly to use accounts (and runs as the user to do so). If this failed (ie: I was so stupid as to overcommit my disk space), then it would begin refusing your mail as soon as there were less than some minimum number of blocks free on the FS to which it is spooling. In none of these cases is the failure triggered by the FS actually getting full. Are you trying to convinve me you can DOS attack me? I know that already. There are much more clever ways of doing that than you suggest, however, and therefore much more effective. I could make an smtp connection from a relatively large and geographically seperate number of locations, and do nothing with it (for example). I would send "NOP" requests to keep the sendmail up and sucking up virtual memory, as well as keeping the number of processes high enough that your memory overcommit based VM system would start "sniping" other processes. If you've intentionally limited the number of sendmail's that could run simultaneously, then at worst I can deny all other inbound connections. Denial of Service attacks are a problem. Handle them on a one-by-one basis, but please start in order of severity. The attack you have described is down in the noise, easily trackable, and easily (and cheaply) prosecuted in a local venue (ie: you can eat the travel costs to appear in my local jurisdiction's courtroom, or you can pay the summary judgement entered in after your failure to appear; in other words, you lose financially if you use that naieve an attack. > > > > That doesn't guarantee it. What if your FS fills up with PID files? > > > > > > What would be creating pid files in /var/log? > > > > In /var. > > The original poster, said to make /var/log a separate filesystem. > This goes along with my point, because it would eliminate the problem. You would still be able to deny service. You just wouldn't be able to deny logging. Luckily, you could force the logs to roll over in the available space, and thus obliterate whatever you wanted to obliterate from the logs, and *still* deny logging service. Denial of service is a blivit. No matter how you shovel, you can't fit 10 pounds of manure into a 5 pound sack. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711201842.LAA11374>