|
From: Willem J. W. <wj...@di...> - 2015-08-10 18:52:03
|
On 10-8-2015 20:27, Kevin Zheng wrote: > On 08/10/2015 13:04, Willem Jan Withagen wrote: >> 50000 is a very high number, while you would like to lock out bad guys >> as early as possible.... >> For me it is like the 6th or 7th rule in the firewall > > Right, the intention is to use a high number so that the rules set by > SSHGuard do not override the users' own rules. That's why I prefer it not to do that automagic. and that is also the advantage of the table.... It requires only one rule, which can be loaded at start of the system and at the correct place. sshguard then only needs to deal with the table. Wether the table is empty or not is irelevant for the functioning of the firewall. Having it at a high number and thus implicitly at the end has the FW run a lot of rules against the access of the bad-guy. Now the bad-guy is looking for holes in the system, so the less rules he gets to sample, the beter it is... I posted part of my FW code a few days back. >> I would consider that a real bad design.... >> IMHO Stuffing automagical things in a firewall is asking for a lot of >> unexpected trouble... > > I share your concern, but it is partially mitigated by the fact that the > rule number is so high; more likely than not it will not trample on the > users' own rules. There is also precedent: since the 'ipfw' backend was > conceived it has always added firewall rules automatically. > > But I'm open to suggestions on how I can do better. How about a big notice on how to activate it in the regular FW code. Once the user has done that it require very little service until the next OS upgrade, where mergemaster will show the diff, and you need to integrate it again. It also removes the risk of trampeling on user rules. On the other hand: add 2 rules at 2500, and notice that both get executed. One really explicitly needs to remove the lines. But then that would make for a very obvfuscated system. --WjW > > Thanks, > Kevin Zheng > |