From: Mij <mi...@ss...> - 2010-07-05 16:39:18
|
This is a nice post™. In general, of course, the fact that people use sshguard for something beyond its original purpose is nothing but good news. For your points: On Jul 5, 2010, at 13:45 , Johan Bergström wrote: > Hello, > > Since switching to 1.5, sshguard has slowly evolved in my server park from a "ssh blocker" to something completely different. The way I see it, sshguard's strengths are scanning multiple logfiles and acting upon a specific behavior. > > Instead of throwing ssh in getting pf out, I would for instance like to shove it failed wordpress attempts and feed them to a nginx config or perhaps a pf tarpit. > > With this in mind, a couple of things makes "living" with sshguard a tad more complex: > > - writing recognition patterns is a tedious and compile-time-only process this is the price tag for having a parser this powerful. We can do *everything* with it, from recognizing many log formats at once, to contextual parsing, to handling tents of attack signatures in a seamlessly maintainable way. So when confronted with "but people won't be able to hack it", we decided to stick with it and provide http://www.sshguard.net/support/attacks/submit/ as the interface for users. This is win-win: users are save the hassle of coding at all, and we guarantee a consistent, secure implementation of the signatures, and redistribution. Now if you say you submitted two months ago and your pattern is still not in, I get you :) Adding a pattern costs about 10 minutes of time start to commit, but I always go after bugs before new features. The basic problem here is that in the last year sshguard's community has clearly outgrown the team's throughput. We are set with the website (thanks to Federico), but we need more developers (since TJ was sucked away in China), and we need someone to look after the mailing list, or some more interaction between users, to allow us back to the code. > - only allows for calls to pf/iptables/whatnot "whatnot" is actually easy to translate to "what you want": one year and odds ago we introduced the "command" backend to this end, which allows to run any command for blocking/releasing/flushing/etc. See http://www.sshguard.net/feedback/firewall/submit/ and as an example instance http://sshguard.svn.sourceforge.net/viewvc/sshguard/trunk/src/fwalls/command_pf.h?revision=181&view=markup This is compile time, but easily deferrable to an external user script. > - not having a config file (recently raised on list) > > Some issues are cured with simple solutions such as letting nginx write custom logs which match a current filter and to wrap calls to pf in shell scripts - but the question remains; In what direction is sshguard heading? > > See this more as an open question rather than a feature request since it's more about roadmap than anything else. This is how we go about it: * as you observe, sshguard is a general detection/reaction platform. We will add support for detecting as many attack signatures as users submit, as long as they are fairly standard. * we always try to be as general as possible (the log formats, the attack signatures, the firewall backends are examples), as long as it makes sense: a substantial set of users will benefit, and existing users will not be adversely affected. michele > > Cheers, > Johan > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |