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) -- Mathieu Roy
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
