"Steve Hanson" <shanson@...> kirjoitti viestissä
news:422529FC.3020506@...
> As far as I can tell, the Windows 1.36.2 downloads are corrupted - The
> zip file will not unzip, and the .exe won't initialize. Anyone else
> having this trouble? The Linux ones seem to work fine.
>
I noticed the same. No prior experience about bacula, but tried to install
it today. FC3 rpm (mysql) installed nicely, don't know yet how it works.
--
TiN

> Hello,
>=20
> We have received the following feature request to have the Clients return=
=20
> their version to be printed in the Job report, which I think is a good id=
ea=20
> -- at least it would help with support requests. =20
>=20
> The problem I have with this request, and the reason I am sending this fo=
r=20
> your comments, is that in general, transmitting version information is a=
=20
> security violation. However, in this case, the information would only be=
=20
> transmitted after authentication.
>=20
> Comments?
Fingerprinting will always be possible one way or another... however I thin=
k it would be nice if it was possible to turn version information on or off=
in the client as well as change the returned message to something else lik=
e "My obfuscated version"=20
/Jens

>We have received the following feature request to have the Clients return=20
>their version to be printed in the Job report, which I think is a good ide=
a=20
>-- at least it would help with support requests. =20
>
>The problem I have with this request, and the reason I am sending this for=
=20
>your comments, is that in general, transmitting version information is a=20
>security violation. However, in this case, the information would only be=20
>transmitted after authentication.
Correct me if I am wrong but Bacula has no concept of privileges or
access lists. Any director that can authenticate is assumed to be
trusted and can do pretty much whatever it would like. So long as it is
post-authentication only, I don't see a problem with it. As someone else
pointed out, it can be a bad idea to provide information to any old Joe
that send packets your way but that is not the case here.=20
JMTC but supposedly those letters in my sig make me some kind of
security expert. ;)
--=20
---
Nathan Valentine, CISSP - nathan.valentine@...
Open Source Technician/Computer Forensics Analyst
Venn Technologies, Inc. : http://www.venntech.net

Hello,
I attach a perl script that perhaps can help admins to see the distribution=
of=20
their bacula clients. This script is part of a discontinued project where I=
=20
did work to add autoupgrade capabilities to Bacula.
Run script when no jobs are running and choose option 3. Ignore the other=
=20
options.
Best regards,
Juan Luis Franc=E9s
El Martes 01 Marzo 2005 23:13, Kern Sibbald escribi=F3:
> On Tuesday 01 March 2005 19:37, Joshua Kugler wrote:
> > On Tuesday 01 March 2005 08:53, Kern Sibbald wrote:
> > > Hello,
> > >
> > > We have received the following feature request to have the Clients
> > > return their version to be printed in the Job report, which I think is
> > > a good idea -- at least it would help with support requests.
> > >
> > > The problem I have with this request, and the reason I am sending this
> > > for your comments, is that in general, transmitting version informati=
on
> > > is a security violation. However, in this case, the information would
> > > only be transmitted after authentication.
> > >
> > > Comments?
> > >
> > > Best regards, Kern
> >
> > Well, in general I suppose it is a security violation, but someone needs
> > to tell the OpenSSH group that:
> >
> > [joshua@... ~]$ telnet localhost 22
> > Trying 127.0.0.1...
> > Connected to ad.doubleclick.net (127.0.0.1).
> > Escape character is '^]'.
> > SSH-2.0-OpenSSH_3.9p1
> > ^]
> > telnet> quit
> > Connection closed.
> > [joshua@... ~]$
>
> Not too cool, IMO.
>
> > It would help in support requests, and it would not allow any informati=
on
> > gathering as a prelude to an attack, since it would only be sent after
> > authentication. Would this require modifications to the protocol?
>
> Yes, but 1.37 is a total disaster when it comes to protocol and DB
> modifications. With the exception of things like this, I hope it is pretty
> much stabilized now.
>
> > I've surprised it's not sent already, as it seems you would check
> > versions
>
> to make sure director/client are compatible.
>
> I'm not really sure it is worth the programming and maintenance effort as
> one generally finds out rather rapidly when the daemons are not compatibl=
e,
> and I discourage running mixed versions. Daemons with the first two of the
> three version numbers the same are always compatible (i.e. 1.36.1 is
> compatible with 1.36.2).
>
> > I think this would be a good feature since it would 1) help with support
> > requests, as was stated, and 2) lessen legwork by the admins since they
> > wouldn't have to manually check versions for all the clients. I don't
> > see it as being a security problem since the director is already
> > authenticated, so can't be used for information gathering (unless of
> > course someone is sniffing your network, in which case you have other
> > problems).
> >
> > So, in short, go for it.
>
> Thanks for your comments. :-)
>
> > j----- k-----