Re: LDAP search without credetials
hi carsten, On Fri, Aug 21, 2015 at 07:10:09AM +0200, Carsten Czerner wrote: > I understand your points. But is it the best way to start with low security > and hope that the administrator knows exactly what to do, like me ;)? > > I thing its a better way to start with a strong security and adapt it to > your > needs (make it less secure) when you need it. An LDAP server is like a > database for me, when you whant to access any kind of data you better > setup the permissions first. I agree in general, the point I was just trying to make is not so much one of "higher" or "lower" default security, but a trade-off between two problems: either having default access for everyone to data you may not want them to have access to, or having to proliferate a high-value password all over the place. choose your poison :) regards robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: LDAP search without credetials
hi carsten,
On Mon, Aug 17, 2015 at 01:23:26PM +0200, Carsten Czerner wrote:
> on my Debian8 slapd installation I can query the ldap-server without typing
> in any password. That isn't ok!?
>
> At the dn: olcDatabase={1}mdb.ldif I found the following entry:
>
> olcAccess: {2}to * by * read
>
> I guess that gives read access to everyone without authentification.
>
> It was pure coincidence that I tested a login without credentials! Cause a
> login with credentilas works as well.
>
> Please change olcAccess: {2}to * by * read -> olcAccess: {2}to * by users
> read
not really an LDAP expert, but I do use it a lot for various bits and
pieces. I have come to the opposite conclusion: we have a windows AD
LDAP at work as well as a UNIX one that behaves as you describe,
allowing basic queries with an anonymous bind. The windows AD LDAP
always requires a full bind. perversely that does not increase security
at all, the reason being that now every silly system that wants to
authenticate a user needs to have a dn + password configured so that it
can look up the user that it tries to authenticate. As far as I see it
this comes down to the fact that you typically do not log in with your
full DN, so the system you try to log on needs to first look up your dn
from your id, and it needs some credentials to do that. The same seems
to apply to PAM as well.
In a well-behaved system you can only query "basic" information with an
anonymous bind, in our case user ids, names, emails etc. If you do log
in with real credentials, you get more information.
So just saying: locking down your LDAP may not make things more secure,
because you now need to proliferate actual credentials all over the
place...
regards robert
--
Robert Lemmen http://www.semistable.com
signature.asc
Description: Digital signature
Re: UNS: Debian 4.0 Upgrade Path
On Thu, Jan 21, 2010 at 01:45:20PM -0500, Michael Gilbert wrote: > i agree that longer support for old releases would be wonderful, but > that would mean at times providing full support for three concurrent > releases (oldstable, stable, and testing). very short times ;) > it already seems hard enough with the current level of manpower to > support two releases at the same time let alone three. it may be > doable, but the security team would need more volunteers (particularly > those interested in doing the work to keep oldstable supported). of course! i just wanted to point out that the fact that a direct upgrade from N to N+2 isn't supported doesn't mean that it wouldn't be desirable to get the length of the security support to that length. cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: UNS: Debian 4.0 Upgrade Path
On Thu, Jan 21, 2010 at 11:20:28AM -0500, Noah Meyerhans wrote: > In general, skipping major versions has never been supported. An > upgrade from etch to squeeze should always involve a short stop in > lenny. of course, but doing these two upgrades one after another on a couple of machines is still easier than doing the first one on all the machines, and then the second one a few months later. especially if you factor in paperwork and explanations of changes that might be required. i fully agree with thiemo, having the security support of release N run out when the security support for N+2 starts would be *very* cool, then people could skip releases if the cost/risk of upgrading is high and the need for brand new software is low. in fact if you look at the past releases [0], you will see that we were almost there with the last two releases. admittedly the start of security support for lenny is very early in that diagram, whether that is true is questionable. cu robert [0] http://wiki.debian.org/DebianReleases -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: first A record of security.debian.org extremely slow
On Tue, Feb 21, 2006 at 09:23:07AM +, Brett Parker wrote: > *blink* - erm, just out of interest, how does this help? This is just > going to stop packets from going to that IP, it's not going to stop > things resolving to that IP, so instead of getting a slow connection > you're just going to get a connection refused... seems like an odd way > of doing things - maybe it would be better to use a local caching > nameserver that you can configure to filter out that IP when there is > more than one A record available instead? (I can't think of a simple way > of doing that off the top of my head, though) it is an odd way, but it is simple and it works because apt will use the other records if the blocked one fails (i do the same). messing with your /etc/hosts isn't much better... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: security.debian.org extremely slow
On Mon, Feb 20, 2006 at 06:25:47PM -0800, Michael Sabala wrote: > It looks like I'm having network problems somewhere along the way. Sorry for > the noise :) no, you are not having problems along the way, or you are not the only one. me and madduck both experience the same problem from machines with otherwise good network connection (colocated). and at least one other person that i can't remember had the same problems too. it does indeed look as if tartini is a bit flaky... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Addressing the recent zlib issue
On Sun, Jul 10, 2005 at 03:59:43PM +0200, Florian Weimer wrote: > rsync (probably version 1.1) i'll take care of this one cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Debian Security Support in Place
On Sat, Jul 09, 2005 at 10:22:29AM +0200, Lupe Christoph wrote: > So in essence the announcement says "screw you, commercial customers". > > Please don't do that. It makes promoting Debian awkward. are you aware that we are talking about *oldstable* here? it was released july 2002, i think if it is supported until may 2006(one year after it got replaced with a new stable version) that's quite a long timeframe and a very good reason for promoting debian! cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Bad press related to (missing) Debian security - action
On Tue, Jun 28, 2005 at 05:20:51AM -0700, Alvin Oga wrote: > personally, i pull down all the important tar balls from the originating > author's site and compile it ... if the distro's version of any app is > "too far behind" the main point about stable security is that exactly this does not happen: i want security fixes for the versions that i have installed, not newer versions. and that's also were things get complicated... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: > `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise > my machine since March 27th... of course the only thing that really helps is good passwords, but i found this to be of great help too: http://blog.andrew.net.au/2005/02/17 cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Compromised system - still ok?
On Mon, Feb 07, 2005 at 06:32:12PM +0200, Ognyan Kulev wrote: > Another thing he doesn't like is that check is based on signed MD5 hash of > content instead of based on signed content. Is it true that signed MD5 is > weaker than signed content? assymetric crypto ops are very slow, so you wouldn't want to do them on the whole content (signature would be the same order of size as teh content too..). so you always sign a message digest. you would want to choose a better one than md5 though (sha1 for example), but that's a trivial change cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
debian security support history
hi folks, i am trying to sum up some facts about debian and created a graphic showing the timeline of debian releases and security support, you can have a look at a preliminary version [0]. i took the data from the debian news site [1] but i am not sure everything is correct, so i wanted to ask: - was there really no 2.1r1 to 2.1r3? the first point release i can see there is r4... - was there any security support for releases before slink? - any other comments? thanks a lot robert [0] http://www.semistable.com/files/releases.gif [1] http://www.debian.org/News/ -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
