Re: HTTPS enabled Debian Security repository
As already answered in this thread, this is already available. Per https://deb.debian.org/: } The redirection service is also available on HTTPS, so with the } apt-transport-https package installed, you can use: } } deb https://deb.debian.org/debian stable main } deb https://deb.debian.org/debian-security stable/updates main Thanks. -- Luca Filipozzi
Re: SSL for debian.org/security?
On Wed, Oct 30, 2013 at 11:12:57AM -0400, Mark Haase wrote: > On Mon, Oct 28, 2013 at 10:01 PM, Luca Filipozzi wrote: > > On Mon, Oct 28, 2013 at 09:31:35PM -0400, Mark Haase wrote: > > > I'd like to suggest that Debian should at least use SSL on their security > > > site, even if nowhere else. > > > > We are in the process of purchasing SSL certificates for a number of our > > 'web properties' including www.debian.org. I hope to have some of them > > deployed in the next couple of weeks. > > Thanks, Luca. Will you notify this mailing list when the SSL certs have been > installed? We have partnered with gandi.net for SSL certificates. They have been quietly and consistently generous to the open source community. Debian has been designated a supported project and we are happily generating certificates, now. I or a DSA colleague of mine will inform this list when we've deployed certs to www.debian.org and security.debian.org: won't be long now. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: SSL for debian.org/security?
On Mon, Oct 28, 2013 at 09:31:35PM -0400, Mark Haase wrote: > I'd like to suggest that Debian should at least use SSL on their security > site, even if nowhere else. Hi, We are in the process of purchasing SSL certificates for a number of our 'web properties' including www.debian.org. I hope to have some of them deployed in the next couple of weeks. For Debian System Administration Team, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Known vulnerabilities left open in Debian?
On Mon, Mar 22, 2004 at 02:31:14PM -0800, Matt Zimmerman wrote: > On Mon, Mar 22, 2004 at 01:56:48PM -0800, Jamie Heilman wrote: > > > Matt Zimmerman wrote: > > > If you have concrete information about unfixed bugs, bring it forth. > > > Otherwise this is just more FUD. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196590 > > Thanks; this is something that needs to be checked up on. > > Luca - if you are not able to prepare a security update, can you assist in > gathering a list of all of the vulnerabilities which need to be fixed? Then > I can use that list to prepare an update. Just so there's no confusion, given that I've posted in this thread. Luca Filipozzi != Luca De Vitis I am the former; bug 196590 is on zope, maintained by the latter. Yours, Luca (Filipozzi) -- Luca Filipozzi (there it is again) "Linux gives us the power we need to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: Known vulnerabilities left open in Debian?
On Mon, Mar 22, 2004 at 02:31:14PM -0800, Matt Zimmerman wrote: > On Mon, Mar 22, 2004 at 01:56:48PM -0800, Jamie Heilman wrote: > > > Matt Zimmerman wrote: > > > If you have concrete information about unfixed bugs, bring it forth. > > > Otherwise this is just more FUD. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196590 > > Thanks; this is something that needs to be checked up on. > > Luca - if you are not able to prepare a security update, can you assist in > gathering a list of all of the vulnerabilities which need to be fixed? Then > I can use that list to prepare an update. Just so there's no confusion, given that I've posted in this thread. Luca Filipozzi != Luca De Vitis I am the former; bug 196590 is on zope, maintained by the latter. Yours, Luca (Filipozzi) -- Luca Filipozzi (there it is again) "Linux gives us the power we need to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Known vulnerabilities left open in Debian?
On Mon, Mar 22, 2004 at 09:45:00PM +0100, Jan Lühr wrote: > Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman: > > On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote: > > > Cron is another example > > > > Cron is another example of what? By all means, please elaborate. > > Of a package of the discussed categorie. ITHM, give us a reference to a security issue in cron that hasn't been addressed by Debian's security team (hey guys!). Saying 'cron is an example of an insecure package' implies you know in what way it is insecure as far as Debian stable is concerned. So tell us! (why oh why do this need to be spelled out...) My once yearly post to debian-security, Luca -- Luca Filipozzi "Linux gives us the power we need to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: Known vulnerabilities left open in Debian?
On Mon, Mar 22, 2004 at 09:45:00PM +0100, Jan Lühr wrote: > Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman: > > On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote: > > > Cron is another example > > > > Cron is another example of what? By all means, please elaborate. > > Of a package of the discussed categorie. ITHM, give us a reference to a security issue in cron that hasn't been addressed by Debian's security team (hey guys!). Saying 'cron is an example of an insecure package' implies you know in what way it is insecure as far as Debian stable is concerned. So tell us! (why oh why do this need to be spelled out...) My once yearly post to debian-security, Luca -- Luca Filipozzi "Linux gives us the power we need to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Big VPN
On Wed, Mar 03, 2004 at 12:18:32AM +0100, I.R. van Dongen wrote: > Richard Atterer wrote: > >On Tue, Mar 02, 2004 at 10:00:58PM +0100, I.R. van Dongen wrote: > > >You might want to check tinc (http://tinc.nl.linux.org) > > > > > > > > > >I strongly recommend *not* to use tinc. > ><http://www.securityfocus.com/archive/1/249142> illustrates that the > >authors didn't have enough expertise to build a secure tool 2 years ago. > >The problems were still present last autumn, see > ><http://www.mit.edu:8008/bloom-picayune/crypto/14238>. What a track record! > > > >With VPN software, IPSec is the only real option if you want to be certain > >it is secure. > > > Nice, the first article is based on a alpha version (pre-beta) of tinc, > you didn't include the official answer. > > This sounds alot like FUD, are you the author of a compeditive product? What about the second link? Perhaps you could have pointed us to TINC's reply to Gutmann's (the second link) criticisms rather than simply claiming this is FUD. Unfortunately, I can only point to the google cache of the TINC's response since the machine (nl.linux.org) that hosts TINC's website has been rooted. Anyway, here's the google cache of the response: http://www.google.ca/search?q=cache:tinc.nl.linux.org/security Gutmann's criticisms, slightly expanded over his original posting, can be found here: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt I'm personally in favour of an IPsec VPN using openbsd or linux 2.6. I think an acceptable user-land alternative might be openvpn. I would have to do more investigation of Gutmann's claims before feeling comfortable with the other user-land alternatives: tinc, cipe or vtun. Yours, Luca -- Luca Filipozzi gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: Big VPN
On Wed, Mar 03, 2004 at 12:18:32AM +0100, I.R. van Dongen wrote: > Richard Atterer wrote: > >On Tue, Mar 02, 2004 at 10:00:58PM +0100, I.R. van Dongen wrote: > > >You might want to check tinc (http://tinc.nl.linux.org) > > > > > > > > > >I strongly recommend *not* to use tinc. > ><http://www.securityfocus.com/archive/1/249142> illustrates that the > >authors didn't have enough expertise to build a secure tool 2 years ago. > >The problems were still present last autumn, see > ><http://www.mit.edu:8008/bloom-picayune/crypto/14238>. What a track record! > > > >With VPN software, IPSec is the only real option if you want to be certain > >it is secure. > > > Nice, the first article is based on a alpha version (pre-beta) of tinc, > you didn't include the official answer. > > This sounds alot like FUD, are you the author of a compeditive product? What about the second link? Perhaps you could have pointed us to TINC's reply to Gutmann's (the second link) criticisms rather than simply claiming this is FUD. Unfortunately, I can only point to the google cache of the TINC's response since the machine (nl.linux.org) that hosts TINC's website has been rooted. Anyway, here's the google cache of the response: http://www.google.ca/search?q=cache:tinc.nl.linux.org/security Gutmann's criticisms, slightly expanded over his original posting, can be found here: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt I'm personally in favour of an IPsec VPN using openbsd or linux 2.6. I think an acceptable user-land alternative might be openvpn. I would have to do more investigation of Gutmann's claims before feeling comfortable with the other user-land alternatives: tinc, cipe or vtun. Yours, Luca -- Luca Filipozzi gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vlans in a firewall
On Sun, Aug 17, 2003 at 09:28:32AM -0600, John Repass wrote: > My question is this: Can I treat say bond0.433 and bond0.434 as completely > seperate interfaces for iptables purposes? What I mean to say is, I know I > can do it, can I do it as safely as the old fashioned method of configuring > one port to be vlan 433 and one on 434, one internal, one external, or with > putting a firewall in-line with each internet connection? Both the old method (one physical port per vlan) and the new method (multiple physical ports in a trunk using tagged vlans) are (somewhat) unsafe *if* the switch uses a single MAC address table for all the VLANs. Just make sure that the model / version of Cisco switch / IOS firmware supports separate tables per VLAN and you should be able to tread bond0.433 and bond0.434 as completely separate interfaces. Hope this helps, Luca -- Luca Filipozzi "Linux gives us the power to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: vlans in a firewall
On Sun, Aug 17, 2003 at 09:28:32AM -0600, John Repass wrote: > My question is this: Can I treat say bond0.433 and bond0.434 as completely > seperate interfaces for iptables purposes? What I mean to say is, I know I > can do it, can I do it as safely as the old fashioned method of configuring > one port to be vlan 433 and one on 434, one internal, one external, or with > putting a firewall in-line with each internet connection? Both the old method (one physical port per vlan) and the new method (multiple physical ports in a trunk using tagged vlans) are (somewhat) unsafe *if* the switch uses a single MAC address table for all the VLANs. Just make sure that the model / version of Cisco switch / IOS firmware supports separate tables per VLAN and you should be able to tread bond0.433 and bond0.434 as completely separate interfaces. Hope this helps, Luca -- Luca Filipozzi "Linux gives us the power to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vim modeline vulnerability
Hi Thomas, I have already, now many weeks ago, submitted a fixed vim package to the Security Team. When they are ready (have reviewed, have time, etc), they will make a DSA. I've asked them if there's anything else I can do for them, with no reply. I suspect that they are occupied with other security bugs. Yours, Luca On Mon, Mar 10, 2003 at 08:18:21PM +0100, Thomas Krennwallner wrote: > Hi! > > Accourding to http://www.guninski.com/vim1.html vim is vulnerable in > woody and sarge (I tried it myself on both). > > ChangeLog of vim (1:6.1-266+1) in sid says: > > + 6.1.265: libcall() can be used in 'foldexpr' to call any system > function. rename(), delete() and remote_send() can also be > used in 'foldexpr'. These are security problems. > > Will there be a security update of vim in woody? > > Last discussion of this bug was in Jan 2003: > http://lists.debian.org/debian-security/2003/debian-security-200301/msg00153.html > > so long > Thomas > > -- > ___Obviously we do not want to leave zombies around. > _/___\ - W. Richard Stevens > ( ^ > Thomas Krennwallner > / \ 1024D/67A1DA7B 9484 D99D 2E1E 4E02 5446 DAD9 FF58 4E59 67A1 DA7B > (__\/_)_ http://bigfish.ull.at/~djmaecki/ -- Luca Filipozzi "Linux gives us the power to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: vim modeline vulnerability
Hi Thomas, I have already, now many weeks ago, submitted a fixed vim package to the Security Team. When they are ready (have reviewed, have time, etc), they will make a DSA. I've asked them if there's anything else I can do for them, with no reply. I suspect that they are occupied with other security bugs. Yours, Luca On Mon, Mar 10, 2003 at 08:18:21PM +0100, Thomas Krennwallner wrote: > Hi! > > Accourding to http://www.guninski.com/vim1.html vim is vulnerable in > woody and sarge (I tried it myself on both). > > ChangeLog of vim (1:6.1-266+1) in sid says: > > + 6.1.265: libcall() can be used in 'foldexpr' to call any system > function. rename(), delete() and remote_send() can also be > used in 'foldexpr'. These are security problems. > > Will there be a security update of vim in woody? > > Last discussion of this bug was in Jan 2003: > http://lists.debian.org/debian-security/2003/debian-security-200301/msg00153.html > > so long > Thomas > > -- > ___Obviously we do not want to leave zombies around. > _/___\ - W. Richard Stevens > ( ^ > Thomas Krennwallner > / \ 1024D/67A1DA7B 9484 D99D 2E1E 4E02 5446 DAD9 FF58 4E59 67A1 DA7B > (__\/_)_ http://bigfish.ull.at/~djmaecki/ -- Luca Filipozzi "Linux gives us the power to crush those that oppose us." - switchlinux gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 245-1] New dhcp3 packages fix potential network flood
On Tue, Jan 28, 2003 at 05:48:07PM +0100, Siegbert Baude wrote: > I dont't quite understand the consequences of the above DSA posted by Martin > Schulze earlier this day on "Debian Security Announcements". When the problem > is the dhcp-relay, why is then the dhcp3 package upgraded for Debian and not > the dhcp3-relay package? Binary packages are built from source packages. The dhcp3 source package builds multiple binary packages, including dhcp3-relay. Luca -- Luca Filipozzi gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: [SECURITY] [DSA 245-1] New dhcp3 packages fix potential network flood
On Tue, Jan 28, 2003 at 05:48:07PM +0100, Siegbert Baude wrote: > I dont't quite understand the consequences of the above DSA posted by Martin > Schulze earlier this day on "Debian Security Announcements". When the problem > is the dhcp-relay, why is then the dhcp3 package upgraded for Debian and not > the dhcp3-relay package? Binary packages are built from source packages. The dhcp3 source package builds multiple binary packages, including dhcp3-relay. Luca -- Luca Filipozzi gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vim modeline vulnerability - is Debian Woody affected?
On Thu, Jan 23, 2003 at 09:39:19AM +0100, Sasha Nedvedicky wrote: > i've noticed, that many other linux distros released a fix of CAN-2002-1377 > (vim modeline vulnerability). > > by http://online.securityfocus.org/bid/6384, it seems, that only few linux > distributions (excluding Debian) are affected. > > so is it true, that current package of vim in Debian Woody is not affected > by vim modeline vulnerability ? The current Debian Woody version of vim is vulnerable. I have already produced a fixed package and given it to the Security Team. When they are ready (i.e., after they have checked my work), I'm sure that they will post an advisory. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: vim modeline vulnerability - is Debian Woody affected?
On Thu, Jan 23, 2003 at 09:39:19AM +0100, Sasha Nedvedicky wrote: > i've noticed, that many other linux distros released a fix of CAN-2002-1377 > (vim modeline vulnerability). > > by http://online.securityfocus.org/bid/6384, it seems, that only few linux > distributions (excluding Debian) are affected. > > so is it true, that current package of vim in Debian Woody is not affected > by vim modeline vulnerability ? The current Debian Woody version of vim is vulnerable. I have already produced a fixed package and given it to the Security Team. When they are ready (i.e., after they have checked my work), I'm sure that they will post an advisory. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: userids introduced by package installs
On Sat, Jun 08, 2002 at 12:51:00AM -0500, Jor-el wrote: > On Sat, 8 Jun 2002, Phillip Hofmeister wrote: > > > Just a guess... > > but it probably has something to do with another package may > > be utilizing that ID > > I doubt it. 'find / -user ' returned nothing > in all cases. Its possible that programs from another package may have > runtime dependancies on the ids, but given the names of the ids (gnats, > msql, etc) I doubt that is the case. Read /usr/share/doc/base-passwd/README ids 0-99 are 'built in' to Debian ids 100-999 are created by packages on install (and deleted on purge) Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is there a prompt for a root shell when the default linux kernel boots?
On Tue, Apr 30, 2002 at 10:17:00PM +0200, Santiago Vila wrote: > Javier Fernández-Sanguino Peña wrote: > > Now that I think of it this might be an issue with self-installed > > kernels. I'm going to document this behavior in the Manual, commit the > > changes and close the bug. Of course, woody does *not* install 2.4 kernels > > IIRC. > > The default install does not, but the "bf2.4" flavor does. Please take > a look at the dists/woody/main/disks-i386/current directory in the > Debian archives. And the stock kernel images available in woody include 2.4 kernels. These, also, have an initrd that offers a root shell, I believe. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is there a prompt for a root shell when the default linux kernel boots?
On Tue, Apr 30, 2002 at 10:17:00PM +0200, Santiago Vila wrote: > Javier Fernández-Sanguino Peña wrote: > > Now that I think of it this might be an issue with self-installed > > kernels. I'm going to document this behavior in the Manual, commit the > > changes and close the bug. Of course, woody does *not* install 2.4 kernels > > IIRC. > > The default install does not, but the "bf2.4" flavor does. Please take > a look at the dists/woody/main/disks-i386/current directory in the > Debian archives. And the stock kernel images available in woody include 2.4 kernels. These, also, have an initrd that offers a root shell, I believe. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: > After doing some reading about it, the only thing that turns me off to > SFS is that you still have to run the usual NFS services for it to work. > A large part of the reason I am seeking alternatives is that those > services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Tue, Apr 09, 2002 at 06:51:38AM -0500, Rob VanFleet wrote: > After doing some reading about it, the only thing that turns me off to > SFS is that you still have to run the usual NFS services for it to work. > A large part of the reason I am seeking alternatives is that those > services are so often vulnerable. You run those service locally on each machine only. You don't make them available to other hosts. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Mon, Apr 08, 2002 at 08:23:17AM +0300, Sami Haahtinen wrote: > On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote: > > Two choices (I like lists :) ): > > > > (1) use libpam-ldap: > > i recommend this. I also recommend this. > > (2) don't use libpam-ldap: > > You don't have to use libpam-ldap. You could just use > > libnss-ldap and have the ldap server transfer the password > > hashes to the workstations in the clear ... which is equivalent > > to NIS. You could also use libnss-ldap with SSL/TLS so that the > > hashes are transferred more securely (equivalent to NIS+). > > i don't recommend the above to anyone (do as i say, not as i do.. =) it > will cause problems, you are forced to enter the database access > password to the configuration, which you will then need to make readable > to root, which in turn forces you to use nscd. No, you don't. You can set the ACLs in slapd.conf for userPassword to 'by * read'. Sure, it's not a good choice. That's why I said that it is the equivalent of NIS. > this also allows crackers to access your userbase, unlike libpam-ldap, > where you are not forced to allow userpassword read access to the > database. The cracker just needs to hack this machine, read the password > from config and voila, ur nt3w0rk has been 0wn3d! You don't need to put a binddn/bindpw into libnss-ldap if you make userPassword readable by all. libnss-ldap can bind anonymously. It's NIS-equivalent, however, so if the hashes are weak based on weak passwords, a dictionary attack is possible (just like NIS). Also, if you were to use a binddn/bindpw, you wouldn't use the rootdn/rootpw. Note for non-LDAP folk: userPassword is the hashed password, not the cleartext password. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:22:12PM -0700, tony mancill wrote: > What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set > up in a mode that's called "opportunistic encryption" that will use IPsec > for communication when it's available and allow other traffic to proceed > as normal. In this way, you won't care if things like LDAP (or even NIS) > pass passwords around in cleartext, just as long as the workstation <-> > file-server or authentication server connections are encrypted. Although > I haven't done it, you should be able to run the server services bound to > a specific IP that is only accessible via clients that have successfully > IPsec-attached. For the NFS traffic, opportunistic encryption seems like a very intersting idea. There's no way I would use libpam-ldap without knowing *for certain* that it was going over a TLS/SSL connection, however. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Mon, Apr 08, 2002 at 08:23:17AM +0300, Sami Haahtinen wrote: > On Sun, Apr 07, 2002 at 08:14:26PM -0700, Luca Filipozzi wrote: > > Two choices (I like lists :) ): > > > > (1) use libpam-ldap: > > i recommend this. I also recommend this. > > (2) don't use libpam-ldap: > > You don't have to use libpam-ldap. You could just use > > libnss-ldap and have the ldap server transfer the password > > hashes to the workstations in the clear ... which is equivalent > > to NIS. You could also use libnss-ldap with SSL/TLS so that the > > hashes are transferred more securely (equivalent to NIS+). > > i don't recommend the above to anyone (do as i say, not as i do.. =) it > will cause problems, you are forced to enter the database access > password to the configuration, which you will then need to make readable > to root, which in turn forces you to use nscd. No, you don't. You can set the ACLs in slapd.conf for userPassword to 'by * read'. Sure, it's not a good choice. That's why I said that it is the equivalent of NIS. > this also allows crackers to access your userbase, unlike libpam-ldap, > where you are not forced to allow userpassword read access to the > database. The cracker just needs to hack this machine, read the password > from config and voila, ur nt3w0rk has been 0wn3d! You don't need to put a binddn/bindpw into libnss-ldap if you make userPassword readable by all. libnss-ldap can bind anonymously. It's NIS-equivalent, however, so if the hashes are weak based on weak passwords, a dictionary attack is possible (just like NIS). Also, if you were to use a binddn/bindpw, you wouldn't use the rootdn/rootpw. Note for non-LDAP folk: userPassword is the hashed password, not the cleartext password. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:04:01PM -0500, Rob VanFleet wrote: > On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: > > Two choices for authentication (passwd + shadow): > > (1) Kerberos > > Never used it. Can't advise you. > > I've looked at Kerberos, but at least a cursory glance at leaves the > impressions that it is ridiculously complicated to set up and requires > multiple servers. If someone has used it and can correct me, please do. I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. > > (2) LDAP > > Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do > > the equivalent of NIS but securely. > > Without using SSL or Kerberos, would LDAP still be sending passwords > across the net in plain text? Two choices (I like lists :) ): (1) use libpam-ldap: libpam-ldap sends the password to the ldap server. If not using TLS/SSL, then it is sent in the clear. By sending the password to the server (rather than using a salt+hash), you can use whatever hash algorithm you want on the server. The server takes the password and does the hashing locally. So, you *must* use TLS/SSL if you are using libpam-ldap, imo. (2) don't use libpam-ldap: You You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:22:12PM -0700, tony mancill wrote: > What if you use FreeS/WAN (or really, any sort of IPsec)? It can be set > up in a mode that's called "opportunistic encryption" that will use IPsec > for communication when it's available and allow other traffic to proceed > as normal. In this way, you won't care if things like LDAP (or even NIS) > pass passwords around in cleartext, just as long as the workstation <-> > file-server or authentication server connections are encrypted. Although > I haven't done it, you should be able to run the server services bound to > a specific IP that is only accessible via clients that have successfully > IPsec-attached. For the NFS traffic, opportunistic encryption seems like a very intersting idea. There's no way I would use libpam-ldap without knowing *for certain* that it was going over a TLS/SSL connection, however. Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: > I work for several University astronomers who basically want something > like what they're used to at other places: a pure sun shop, running > NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 10:04:01PM -0500, Rob VanFleet wrote: > On Sun, Apr 07, 2002 at 07:39:43PM -0700, Luca Filipozzi wrote: > > Two choices for authentication (passwd + shadow): > > (1) Kerberos > > Never used it. Can't advise you. > > I've looked at Kerberos, but at least a cursory glance at leaves the > impressions that it is ridiculously complicated to set up and requires > multiple servers. If someone has used it and can correct me, please do. I suspect that if all your boxes are running Debian that your life will be made easier by all the Debian kerberos packages. > > (2) LDAP > > Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do > > the equivalent of NIS but securely. > > Without using SSL or Kerberos, would LDAP still be sending passwords > across the net in plain text? Two choices (I like lists :) ): (1) use libpam-ldap: libpam-ldap sends the password to the ldap server. If not using TLS/SSL, then it is sent in the clear. By sending the password to the server (rather than using a salt+hash), you can use whatever hash algorithm you want on the server. The server takes the password and does the hashing locally. So, you *must* use TLS/SSL if you are using libpam-ldap, imo. (2) don't use libpam-ldap: You You don't have to use libpam-ldap. You could just use libnss-ldap and have the ldap server transfer the password hashes to the workstations in the clear ... which is equivalent to NIS. You could also use libnss-ldap with SSL/TLS so that the hashes are transferred more securely (equivalent to NIS+). Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NFS, password transparency, and security
On Sun, Apr 07, 2002 at 09:02:56PM -0500, Rob VanFleet wrote: > I work for several University astronomers who basically want something > like what they're used to at other places: a pure sun shop, running > NIS and NFS. Two choices for authentication (passwd + shadow): (1) Kerberos Never used it. Can't advise you. (2) LDAP Use LDAP (recompile --with-tls flag) + libpam-ldap + libnss-ldap to do the equivalent of NIS but securely. Several choices for authorisation (pam_access.so): (1) local /etc/secuirty/access.conf listing all users (2) local /etc/secuirty/access.conf listing a group or netgroup - use local group file - use LDAP-distributed group or netgroup map Several choices for file sharing: (1) NFS + iptables + tcpwrappers (2) SFS (see sfs-server sfs-client packages and www.fs.net) Requires users to authenticate against the file server, also. Consider using libpam-sfs (I'm rewriting it as we speak.) (3) OpenAFS (see openafs-fileserver + openafs-client) Also requirres users to authenticate against the file server, but when used in a Kerberos environment, you only have to logon once due to Kerberos' ticket-granting system. Hope this (probably incomplete) list helps, Luca -- Luca Filipozzi, Debian Developer [dpkg] We are the apt. You will be packaged. Comply. gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SpamAssassin (Was Re: SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON)
On Fri, Jan 25, 2002 at 08:31:24AM +0100, Oliver M . Bolzer wrote: > I've heard Razor is (configurabule) part of SpamAssassin. I'd recommend > disabling that check because somebody is tagging about 1/3 of Bugtraq mail > in Razor thus sending it to the Spam folder. Or you can add whitelist_from [EMAIL PROTECTED] to your .spamassassin.cf file. Luca -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged. pgp024xiFfGUF.pgp Description: PGP signature
Re: SpamAssassin (Was Re: SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON)
On Fri, Jan 25, 2002 at 08:31:24AM +0100, Oliver M . Bolzer wrote: > I've heard Razor is (configurabule) part of SpamAssassin. I'd recommend > disabling that check because somebody is tagging about 1/3 of Bugtraq mail > in Razor thus sending it to the Spam folder. Or you can add whitelist_from *@lists.debian.org to your .spamassassin.cf file. Luca -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged. msg05530/pgp0.pgp Description: PGP signature
Re: Was I hacked into? who is user "nobody"? please help....
On Mon, Nov 05, 2001 at 09:59:54AM -0500, Gianguido Cianci wrote: > a few minutes ago I heard my PC getting into a lot of fuss over something, > the HDD was spinning like crazy... so I looked at "top" and found that user > > "nobody" was running a "find" comand You were not hacked into. (1) look at /etc/crontab (2) look at /etc/cron.daily/* (3) look at /etc/cron.daily/find (4) man updatedb Basically, all the things in /etc/cron.daily are run at 6h25 every morning. /etc/cron.daily/find updates the database of file names used by the locate command line utility by calleing updatedb as user 'nobody'. Luca -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged.
Re: Was I hacked into? who is user "nobody"? please help....
On Mon, Nov 05, 2001 at 09:59:54AM -0500, Gianguido Cianci wrote: > a few minutes ago I heard my PC getting into a lot of fuss over something, > the HDD was spinning like crazy... so I looked at "top" and found that user > > "nobody" was running a "find" comand You were not hacked into. (1) look at /etc/crontab (2) look at /etc/cron.daily/* (3) look at /etc/cron.daily/find (4) man updatedb Basically, all the things in /etc/cron.daily are run at 6h25 every morning. /etc/cron.daily/find updates the database of file names used by the locate command line utility by calleing updatedb as user 'nobody'. Luca -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: need help.....
> Is There any utility or process that can check specified directory? > > What¡¯s the best way to check the directory quantity in Linux..? why not use quotas? > And how can I alarm to M$-client..? look at smbclient -M but quota will warn via email -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged.
Re: need help.....
> Is There any utility or process that can check specified directory? > > What¡¯s the best way to check the directory quantity in Linux..? why not use quotas? > And how can I alarm to M$-client..? look at smbclient -M but quota will warn via email -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HHHEEEEEEEEELLLLLLLLPPPPPPPP!!!!!!!!!!
On Tue, Jul 04, 2000 at 11:52:25AM -0700, Alexander Hvostov wrote: > Dennis, > > We don't want you to leave debian-security. ;) Welcome to the Hotel California... :) -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged.
Re: HHHEEEEEEEEELLLLLLLLPPPPPPPP!!!!!!!!!!
On Tue, Jul 04, 2000 at 11:52:25AM -0700, Alexander Hvostov wrote: > Dennis, > > We don't want you to leave debian-security. ;) Welcome to the Hotel California... :) -- Luca Filipozzi [dpkg] We are the apt. Resistance is futile. You will be packaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
