Hi Mathieu, (Note: is it possible to word-wrap your mails?)
I had answered your previous mail, but given that it was under the "SQL Injection" thread I suppose you antispammed it out. So the SQL Injection Monitor script is a quick hack that Michael developped following the recent Savannah password compromise. Of course it's not perfect and I suggest you get in touch with him to see how to fix it best. chkrootkit has been triggering a lot of false positive (like SQL injection monitor ;)). In addition it can only be run securely on a trusted box, because an attacker installing a rootkit can patch or disable chkrootkit on a compromised system. I don't remember if it was installed at Gna! but we didn't keep it at Savannah for these reasons. (Jame Villate found the Savannah rootkit in 2003 btw, not Vincent, but that's an old story now) /root/TODO is basically my personal roadmap when I was working mostly alone on upgrading the infra. I didn't think much about it but it was more convenient to use than a dozen of separate tracker items in that particular case. We use trackers for a number of things but we also know when not to use them. /root/.ssh/authorized_keys is managed automatically in the host (Bearstech procedure). The guests are managed manually because nobody took the time to install the script. Note that the script does not automate the task for security reasons, instead it suggests what keys to add. Mixing Savane users and system users doesn't sound good, so better leave the backup key as-is. Your last remark shows you're aware of the tone of your mail :/ - Sylvain On Thu, Jan 06, 2011 at 12:44:19PM +0100, Mathieu Roy wrote: > Hello, > > My spam setup considered soon enough these possible SQL injection attack as > spam. I mean it's nice to know if someone may try something nasty. However, > be warned 150 times about the same IP and in the end do nothing about it, > that's just noise. > > I considered modifying the script so it bans temporarily IPs of suspicious > clients. I'm finally hesitating to do so: > > - First, really, it's stored in /root/bin? Not trying to enforce LSB but > creating a bin directory in /root is a bit wild, isn't? I known Vincent and > Sylvain aren't happy at all with the idea of using dpkg/apt-get to maintain > scripts and configs and I admit this method (old gnapgnap packages) is not > flexible, a pain in the ass in some regards. But I'm not sure creating a bin > directory in /root is the kind of flexibility that ease things. Easy to set > up sure, but if I want to modify it without breaking anything, what should I > do? How was it installed? Was it a standalone script? Is there any other > version of this script around? Could I commit my changes somewhere? etc. > Plenty of questions, just for one script. > > - Second, a simple look at the script shows that scalabily was not took into > account. With this script running, anyone could considerably flood all of our > mailboxes and have the mail server running on this system sending thousand of > mails in a way too short time span. > When Gna! was created, Vincent had this nice script called logalert > http://home.gna.org/logalert/ I'm not sure to understand why it was dropped > but even if it required some time to configure it properly, seems to me a > better starting point. For instance, I'm not sure it is so great to have a > daemon to watch a single file instead of a cronjob. Granted, the daemon will > catch the malicious log line when it appear, not 3 minutes laters. But since > it only send mails about it, it may as well catch it 3 minutes later. And > will we have a daemon for each new log file we may want to monitor? > > > > Actually, I noticed that plenty of things disappeared over time and I do not > know why; I guess I missed much anyway so it is not unexpected that I do not > know why and when these are gone, I'm puzzled still, I understand these were > maybe annoying in some ways but I'm getting afraid of a setup with many open > doors and too few checks. If these were annoying, that's because somehow they > addressed issues. > Simple crude example, I found no installed version of chkrootkit. Why so? > Seeing that, I have the same feeling than years ago when I was poking poor > Paul Fisher to get a kernel without the kmod/ptrace bug running on the > original savannah.gnu.org box (first mail about it sent 27-03-2003, the > upgrade occured 16-06-2003... so we knowlegdly ran almost 3 month with a > flawed kernel). We had no valid security policy, everything was flexible as > hell, and when Vincent joined an had the _fun_ idea to run chkrootkit, we > discovered we were compromised, remember? > I'm not saying the current setup isn't good. I just have the feeling that no > one is able to tell exactly what it the policy on these machines about > security. If so that would be mean there's a dangerous lack of vision on the > issue. If not so, then I think this policy should be more clearly described > (for instance it should be easy to know which security checks are made on > each system and which scripts/programs should be installed on each system - > without such list, there's no telling if everything is right). > Other example, we have a file /root/TODO. Really? On Gna! we have to rely on > text file somewhere on a computer? Not even a TODO with the Emacs intergrated > feature, no a simple flat text. Does it mean Gna! web interface is not > practical enough to manage tasks? If so, we ought to do something about it > soon. Moreover, when people does not use the tools they provides, they > quickly enough lose touch with theirs users needs, that's my pick on > sourceforge. You cannot provide decents services that you make no use of. > Other example, /root/.ssh/ seems now managed by hand. There was a script that > extracted ssh keys of Gna! relevant users. If I create a new key, will I > have to go over each system of put it or is there any other script that will > do it for me? If why no longer using it? Was there a problem with it that > could not be addressed by modifying the script? When adding a virtual user to > access system to make backups, why doing it by hand instead of creating a > virtual user on the web interface that we can easily track afterwards, add > new keys, etc? > > So I guess I'm missing info, overlooked stuff and am wrong on some or all > points, but in the overall, that's a bit the feeling that comes to me that > makes me unable to do anything. So tell me I'm wrong and how so and > everything will be good :-) > > > (Don't take me wrong, I admire and welcome all the work done to get > hardware/bandwidth up and running over years. I'm sure you understand that's > not the point. The vserver-based setup is a fine one and obviously better > than the chroot-based previous one. Everything is up and running and that's > what matters most. > I understand as well that, obviously, the set up should be practical in the > eyes of the ones that maintains it most of the time. I'm just finding it > however very hard now to contribute because I've not enough time to guess > what policies could be, where stuff should be, etc) _______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
