> 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). 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 ;) 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 ;) > 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. These were only some ideas, motivated by my experience of customers' architectures, needs, and behaviours ;) (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 ^^) > 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 ;) 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
