Data Haven problems
-----BEGIN PGP SIGNED MESSAGE----- While programming my data haven code, I am wondering how to guard against spamming the data haven parser. It is trivial to mount a denial of service attack by repeatedly mailing large files. which will fill up the quota or filesystem of the data haven host, and if you have mail on a root partition, will cause hangs or crashes. Any ideas on how to guard against mailbombs, and to confirm to the sender that their files are stored successfully? Perhaps do a mailing with a test command that validates the existance of the file, and sends a reply back wether the file is okay or not, or would this result in a possible security hole? As to the code, this will have to be my second rewrite as I am going to do it in perl code, rather than C... last rewrite was from a daemon to a program activated by a .forward file. Lastly, instead of postage (like a remailer would get), how hard would it be to implement "rent" where if the "rent" is not paid, and a grace period has elapsed the file would be trashed. All this while preserving the anonymity of the sender and the data haven site. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLw7KpFLUeLjqSiixAQHs4wf+Mf4CVx77nXjUXug/3q1hINhCyWgWmal7 vY1WeCDXM+qrrdxUgqzIhYRYpCPKChMjeozFltn9T0CcH/YdaD5hx3dB5A0YUPWZ SpF5oCL3iZzf2veA8BBJEIrFdmts/nFUzWaqMx4+2IcufYb+0kVw/AKi2M5B0ZiT UoOFFIsySR9hIMMIfHlkGqrnoO8LhlViRBx4u1O0bb0GYAyc+Nv6HvDJOSWuVe9C g5B4GMLuW1t9e5Qw3W0Qy1VRIC4QbOrd0zbjDrQ38GUemOjALuZ2h4+tr3bR93KU ZthueqsIzGKlr90PU6AVVZd128mDHLofJO4I4IoOgSPV7XIK4tufyA== =KZk0 -----END PGP SIGNATURE-----
While programming my data haven code, I am wondering how to guard against spamming the data haven parser. It is trivial to mount a denial of service attack by repeatedly mailing large files. which will fill up the quota or filesystem of the data haven host, and if you have mail on a root partition, will cause hangs or crashes.
If there is no cost associated with the haven and there are no account limitations (ie anyone can get an account) then I don't see a means to do it reliably. However, if you work up a fee based scheme such that you charge per M then it is trivial. If the data is larger than the account balance it bounces. By limiting the availability of accounts you can make it less enticeing for users to spam the haven because they are hurting themselves. And it is assumed that since the accounts are limited that there is an assumed web of trust working.
Any ideas on how to guard against mailbombs, and to confirm to the sender that their files are stored successfully? Perhaps do a mailing with a test command that validates the existance of the file, and sends a reply back wether the file is okay or not, or would this result in a possible security hole?
It seems to me that a message should come back only if there is a problem.
As to the code, this will have to be my second rewrite as I am going to do it in perl code, rather than C... last rewrite was from a daemon to a program activated by a .forward file.
Lastly, instead of postage (like a remailer would get), how hard would it be to implement "rent" where if the "rent" is not paid, and a grace period has elapsed the file would be trashed. All this while preserving the anonymity of the sender and the data haven site.
This form of dating files is pretty commen in bbs systems where if a user doesn't log in for say 30 days the account and its contents are deleted. To do this doesn't even require knowing anything about the user other than how long the files have been there versus how long they are supposed to be there.
From: dfloyd@io.com While programming my data haven code, I am wondering how to guard against spamming the data haven parser. Here's an example of where the mechanism/policy distinction helps a lot. Mechanism here is how you store data. Policy is how you decide whether to accept a particular request. The suggestions to date have all suggested particular policies to put into your code (with the exception of Bill Stewart). In addition, almost all of these suggestions have been pay-per-use. As significant as policies are, they aren't your most important issue right now. The single thing you need to get right today is the means of separating the mechanism from the policy. Different operators will have different policies. If it's difficult to change policies, fewer services will be offered. The issue of policy separation is a software architecture one. I don't know the structure of your code, but I'd suggest that whatever it looks like, that you make a (1) clean interface and that you (2) document it. If you do these two things, you'll have substantially achieved separation. I think you should spend more time worrying about the interface than about the specific policies. In order to focus on the policy interface, I'd suggest an extremely simple policy to work with, namely, an access list. Anyone listed can use the server; everyone else is denied. That will get you started. I would distribute your first code with a simple policy such as this. It will allow prototypes to get worked on. Since a data haven isn't of much use without clients for it, a simple policy is adequate for a first release. Eric
-----BEGIN PGP SIGNED MESSAGE-----
Any ideas on how to guard against mailbombs, and to confirm to the sender that their files are stored successfully? Perhaps do a mailing with a test command that validates the existance of the file, and sends a reply back wether the file is okay or not, or would this result in a possible security hole?
To solve problem #1, use digital postage of some form. Digicash, FV, Tacky Tokens, Mountain Dew futures... just require a per-storage-unit charge _to initially check in the file_. You can of course charge for storage over time, too. To solve problem #2, send an MD5 hash of the file back to the sender. Ideally, you would also provide (in perl, C source, csh, or whatever) a submission script which outputs an MD5 hash before the file is sent. As long as the before-sending hash matches the hash returned by the haven, you can assume that the file is intact.
Lastly, instead of postage (like a remailer would get), how hard would it be to implement "rent" where if the "rent" is not paid, and a grace period has elapsed the file would be trashed. All this while preserving the anonymity of the sender and the data haven site.
Not very. Use a dbm database to map "rent due" dates by file, then periodically sweep through the database.
As to the code, this will have to be my second rewrite as I am going to do it in perl code, rather than C... last rewrite was from a daemon to a program activated by a .forward file.
Perl has the nice property of being fairly portable, too. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich@ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxFaRafb4pLe9tolAQH3EwQAmokOebOJtSbny7rAphWBE7n38XvWYbwy SMFXmctU6DNnM+9oGTtlaROTUy2jbbt6zDf1/1wIOG/p0C6K7BAD8lt0mkrf4OqN As1yf9JLxtTHgYIKF94aUiGiqCUo5zWe12CB+GwZ9LKma4BxXKqT3iCYrjQL+2Su us2wL5AVRd4= =McPN -----END PGP SIGNATURE-----
participants (4)
-
dfloyd＠io.com -
eric＠remailer.net -
paul＠poboy.b17c.ingr.com -
root