On Fri, Jan 14, 2011 at 9:42 AM, Laurent Guyon <laurent.gu...@adelux.fr>wrote:
>
> > The current code use certificates, so what certif did you give to your
> > rogue arbiter? The sample cetifs are just samples. Every one got the
> > same, so they are not good for authentification. I put a doc about how
> > create new ones in the wiki.
>
> The only problem I see is precisely supplying a fully functionnal sample
> CA : too many sysadmins (or trainee, because many supervision platforms
> are often setup by trainees ^^) are lazy, and will keep the beautiful
> default certificates you give them (everyone is not aware about
> certificates, and setting up the Shinken infrastructure is already more
> complex than an original Nagios, so all optional point of the
> installation doc will be passed).
>
Yes it's true. I'll update the "security" chapter of the documentation. But
with lazy admin, you can't have security. No matter what the application
does, the worse the admin is, the worse the system will be :)
With this way of working, they have crypted communication, but no
authentification. If they want it, they can have one of the best way for it,
x509 certificates. I won't do a mere ip filter for un-security-aware admins
:)
>
> When I think about all Nagios installations I've seen, trust me, all
> params will be kept to their default value, as well as the
> certificates ;)
>
Yes, it's true.
>
> Perhaps, not giving a sample CA, but firing a python script that offers
> to generate automagically a new CA at the end of setup.py, and supplying
> another to generate signed certificates, like ssh-server ? Would imply
> more dependancies, ok, but could be safer ;)
>
Beleve me, generate new certif is too easy :
http://shinken-monitoring.org/wiki/ssl_certificates
I'm wodnering if it should be a part of the automatic setup. Distro can't do
it I think (they use setup.py to have their files, not to really install
it). I don't know how others tools are doing this.
ssh-server is able to generate x509 certificates? I thoug it was special
ones. If so, it can be a good thing :)
>
> > I think we won't go any thurser that X50 certificates, if the admin
> > want more, there iptables/netfilter because like Gerhard said, like
> > for syn attack, even a ssl authentification is useless :)
>
> For authenticating daemons, x509 is good, I didn't meant something else.
>
> But for livestatus, I don't totally agree with you. It's true that
> firewal level restrictions is better, but not sufficient imho.
> Generally, firewall rules are not setup directly on servers, because
> it's way too much complex to manage in big sized environements,
> filtering is let to routers and appliances that interconnect subnets.
> Moreover, livestatus accepts parameters, so adding an application-level
> is always good, as well as proper parameters cleaning, for example to
> ensure authorized accesses will not crash the broker accidentaly.
>
The problem is that if we add a layer over livestatus, we should do it with
the official livestatus too, and ask the tools to update their lib. It's
possible of course, but it will ask some time.
>
> These were only some ideas, motivated by my experience of customers'
> architectures, needs, and behaviours ;)
>
> Yes, some people really love security, and don"t give a such important
architecture to a trainee :)
(btw, your idea of passive configuration dispatching is very good,
> because arbiter -> scheduler will ne be always possible, this will be
> mandatory for some of my customers ^^)
>
Yes, with DMZ and co, the admin should be able to choose the connexion way.
It will not be easy, and the active way will still be the default because
it's more "natural", but passive is important :)
>
>
> > But it's good : it seems that the ssl code is working and not only on
> > my computer and in the integration server, thanks for the test :)
>
> No problem ;)
>
:D
Jean
>
>
> Laurent
>
>
> > Jean
> >
> > On Thu, Jan 13, 2011 at 8:01 PM, Gerhard Lausser
> > <gerhard.laus...@consol.de> wrote:
> > Hi,
> >
> > > In the same way, imho, securing the livestatus module socket
> > > should be thought about (for example limiting hosts/IP that
> > > can send requests), against malveillant users that could
> > send
> > > external commands or malformed requests (DoS).
> >
> > that's true, but i don't think this belongs into the Shinken
> > code. Why not
> > delegate the protection to a very low level, iptables or
> > Windows firewall?
> > If an admin sets up a distributed monitoring system, he should
> > easily have
> > another 10 minutes to think about some firewall rules.
> > This way, the threat is blocked with less impact on the
> > Shinken processes.
> > Because if, for example i implement an access list for the
> > livestatus
> > broker, it still has to handle the connections (established
> > connections,
> > where iptables throws away the first syn-packet). If there are
> > lots of
> > connections/sec the broker is busy filtering the bad ones and
> > throwing
> > them away instead of handling the good ones.
> >
> > Gerhard
> >
> >
> >
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them.
> > Understand
> > malware threats, the impact they can have on your business,
> > and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > Shinken-devel mailing list
> > Shinken-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/shinken-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________ Shinken-devel mailing
> list Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
