|
From: Willem J. W. <wj...@di...> - 2015-08-10 20:18:22
|
On 10-8-2015 21:58, James Harris wrote: > This is how the iptables backend works. Sshguard puts all rules into a > table 'sshguard' it is then left to the user to use that table in the > correct place. Which as pointed out, is one rule. Personally I like this > design as it requires a level of interaction and understanding by the > user. It also means sshguard can run in a completely normal mode of > operation but not actually block during an evaluation period. Well things get even better when we get to 11.0 # ipfw table sshguard add 1.1.1.1 DEPRECATED: inserting data info non-existent table sshguard. (auto-created) added: 1.1.1.1/32 0 # ipfw table sshguard list --- table(sshguard), set(0) --- 1.1.1.1/32 0 And thus we do not need to use numbers. # ipfw add 5000 deny ip from table\(sshguard\) to any 05000 deny ip from table(sshguard) to any # ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 05000 deny ip from table(sshguard) to any 65000 allow ip from any to any 65535 deny ip from any to any --WjW > On Aug 10, 2015 11:52 AM, "Willem Jan Withagen" <wj...@di... > <mailto:wj...@di...>> wrote: > > 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 > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > <mailto:Ssh...@li...> > https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |