Re: Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)
Well, a very striped down version of OpenBSD running off a cd and freenet's cache being on an encripted disk with a one-time key (ie a new key is randomly generated at boot) would make setting up a freenet machine simple, safe, and dificult to update. :-p , 9 years with one remote hole ~Paul On Thu, 05 Aug 2004 00:23:51 +0200, Zenon Panoussis <[EMAIL PROTECTED]> wrote: > > Toad wrote: > > >> You have taken extraordinary measures to protect against [the > >> ftp server being hacked], haven't you? > > > Umm, measures such as..? I don't see how you can defend against the > > above, really. > > Well, first of all the elementary stuff. No other services on the > same machine. You don't want your ftp server compromised because > of a flaw in mailman, or even sendmail, so put that stuff elsewhere. > Heavy firewalling. IDS. No compiler installed; most hacks begin > with a compilation. No unnecessary script interpreters; an ftp > server can live very well (and much longer) without PHP, python, > perl, java, whathaveyou. A super-lean kernel. A permanently up > to date system. > > Then the more tedious stuff. Remote syslog. Remote md5sums of every > file on the machine, regularly checked. A draconic password policy. > Why not a read-only server running from a CD-ROM? > > And then comes the really difficult part, physical security. A > gang of angry and hungry dobbermans in the outer perimeter, cobras > in the server room, tarantulas inside the server itself. > > As a side-dish, network security. If your DNS can be compromised, > nobody needs to touch your ftp server before they can serve their > own files from "your" machine. Arp. There is really no way to > ensure that a visitor to your ftp server won't end up elsewhere, > but an unpredictable control mechanism can let you know if that > happens and mitigate the damage. > > > There is one thing though... I think the CVS announcement mails are > > generated on the client side. They should be generated on the server > > side. Anyone know how to do this? > > What you mean by "CVS announcements"? > > Z > > -- > Framtiden är som en babianröv, färggrann och full av skit. > Arne Anka > ___ > Support mailing list > [EMAIL PROTECTED] > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:[EMAIL PROTECTED] > ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)
Toad wrote: The fundamental issues revolve around changes to source code. Only in theory. In practice, the source code only affects your reputation. The binary code affects the users. If you only protect the source code (which is also what might get reviewed at some point or other), you will only be protecting those users who are really careful and compile from source and don't really need protection. Protecting the binaries is much more crucial. Of course I don't mean that protecting the source is unimportant. I have the impression - from nowhere - that freenet is developed by a small and rather tight team. If that is so, then commits can be based on personal trust. If, on the contrary, source can be committed by not fully trusted people, then there is no end to the auditing requirements before you can call the resulting binaries safe. They're not easy to deal with. Specifically, no matter how deeply you secure the server, you can't certify every single build as free from unexpected code. It is human to err and, as builds 5085-5087 prove, errors will happen. However, as long as the developers are well-willing but imperfect friends, we can trust that there will be no spycode sending extensive reports to nsa.gov. There is a fundamental difference between bugs and malicious code. I am willing to take the risk of accidentally introduced security flaws, but not the guaranteed-to-work intentional security breach that an outsider would put in freenet if he could. Hence the need to ensure that for example mails get sent out EVERY time a CVS commit occurs, and if they bounce it will keep trying to send them forever. How can we achieve this? As far as I know how mail servers work, you can't. Then again, why would you need to? Really, how many people have commit permissions? As long as they are fewer than three dozen or so, you can have a cryptographically secured system of notification acknowledgements which leads to phone calls for missing acknowledgments after a certain threshold. The problem is not some notifications not reaching their destination, but rather commits happening without anyone at all being notified. I think that what you are really saying is that you ned to ensure that nothing can be committed without at least some notifications going out. If the cvs server gets hacked, you can't. One way around this is what I wrote about remotely stored md5sums of all files. The way cvs works sabotages this though (existing file unchanged, newer file present but not md5summed to begin with). Z -- Framtiden Ãr som en babianrÃv, fÃrggrann och full av skit. Arne Anka ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)
The fundamental issues revolve around changes to source code. They're not easy to deal with. Specifically, no matter how deeply you secure the server, you can't certify every single build as free from unexpected code. Hence the need to ensure that for example mails get sent out EVERY time a CVS commit occurs, and if they bounce it will keep trying to send them forever. How can we achieve this? On Thu, Aug 05, 2004 at 12:23:51AM +0200, Zenon Panoussis wrote: > > Toad wrote: > > >>You have taken extraordinary measures to protect against [the > >>ftp server being hacked], haven't you? > > >Umm, measures such as..? I don't see how you can defend against the > >above, really. > > Well, first of all the elementary stuff. No other services on the > same machine. You don't want your ftp server compromised because > of a flaw in mailman, or even sendmail, so put that stuff elsewhere. > Heavy firewalling. IDS. No compiler installed; most hacks begin > with a compilation. No unnecessary script interpreters; an ftp > server can live very well (and much longer) without PHP, python, > perl, java, whathaveyou. A super-lean kernel. A permanently up > to date system. > > Then the more tedious stuff. Remote syslog. Remote md5sums of every > file on the machine, regularly checked. A draconic password policy. > Why not a read-only server running from a CD-ROM? > > And then comes the really difficult part, physical security. A > gang of angry and hungry dobbermans in the outer perimeter, cobras > in the server room, tarantulas inside the server itself. > > As a side-dish, network security. If your DNS can be compromised, > nobody needs to touch your ftp server before they can serve their > own files from "your" machine. Arp. There is really no way to > ensure that a visitor to your ftp server won't end up elsewhere, > but an unpredictable control mechanism can let you know if that > happens and mitigate the damage. > > >There is one thing though... I think the CVS announcement mails are > >generated on the client side. They should be generated on the server > >side. Anyone know how to do this? > > What you mean by "CVS announcements"? > > Z > > > -- > Framtiden ??r som en babianr??v, f??rggrann och full av skit. > Arne Anka > ___ > Support mailing list > [EMAIL PROTECTED] > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:[EMAIL PROTECTED] -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)
Toad wrote: You have taken extraordinary measures to protect against [the ftp server being hacked], haven't you? Umm, measures such as..? I don't see how you can defend against the above, really. Well, first of all the elementary stuff. No other services on the same machine. You don't want your ftp server compromised because of a flaw in mailman, or even sendmail, so put that stuff elsewhere. Heavy firewalling. IDS. No compiler installed; most hacks begin with a compilation. No unnecessary script interpreters; an ftp server can live very well (and much longer) without PHP, python, perl, java, whathaveyou. A super-lean kernel. A permanently up to date system. Then the more tedious stuff. Remote syslog. Remote md5sums of every file on the machine, regularly checked. A draconic password policy. Why not a read-only server running from a CD-ROM? And then comes the really difficult part, physical security. A gang of angry and hungry dobbermans in the outer perimeter, cobras in the server room, tarantulas inside the server itself. As a side-dish, network security. If your DNS can be compromised, nobody needs to touch your ftp server before they can serve their own files from "your" machine. Arp. There is really no way to ensure that a visitor to your ftp server won't end up elsewhere, but an unpredictable control mechanism can let you know if that happens and mitigate the damage. There is one thing though... I think the CVS announcement mails are generated on the client side. They should be generated on the server side. Anyone know how to do this? What you mean by "CVS announcements"? Z -- Framtiden Ãr som en babianrÃv, fÃrggrann och full av skit. Arne Anka ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)
On Wed, Aug 04, 2004 at 11:08:19PM +0200, Zenon Panoussis wrote: > > Toad wrote: > > >>Or something like that. The real and ever-present danger > >>against freenet is not in your IP being shown to your peers. > >>It is in (a) the integrity of its developers and (b) in the > >>security of the software archive. If the latter ever gets > >>compromised, we might all end up running a piece of Big > >>Broher-owned spyware called "freenet". > > >Well, most PCs run insecure software, infrequently updated. Even of > >those that are relatively secure their operators don't have the > >understanding or the time to make them secure. And even if they do there > >are always more vulnerabilities, as programmers are human beings. "They" > >can probably compromize the vast majority of PCs pretty easily. > > If my machine is insecure and gets compromised, my ass might be > on fire. If your ftp server gets compromised, the ass of every > single freenet user in the world could be on fire. I was pointing out that if 99% of Freenet nodes run on Windows 98, then your anonymity isn't necessarily what it appears. > > And the idea that this could happen is not far-fetched. Remember > the linux kernel root hack a few months ago on kernel.org? The > Debian server? You can publish all the md5 checksums you want, > but whoever can manipulate the files themselves, can manipulate > the published checksums too. Among the eager competitors to hack > your server are about 120 governments, a multitude of political > organisations, several mafias of different flavours and, of course, > every Joe Hacker and Skrip T Kiddie who would consider it a > special honour to have hacked a whole network instead of only > a server. > > You have taken extraordinary measures to protect against this > happening, haven't you? Umm, measures such as..? I don't see how you can defend against the above, really. There is one thing though... I think the CVS announcement mails are generated on the client side. They should be generated on the server side. Anyone know how to do this? -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
