Reco: On Sat, 16 Jan 2016 12:57:30 +0300, you wrote:
>> -j, --jump target >> This specifies the target of the rule; i.e., what to do >> if the packet matches it. The target can be a user-defined >> chain (other than the one this rule is in), one of the special builtin >> targets which decide the fate of the packet >> immediately, or an extension (see EXTENSIONS below). If this option >> is omitted in a rule (and -g is not used), then matching the rule >> will have no effect on the packet's fate, but the counters on the rule >> will be incremented. >> >> So if the inbound packet has some property which matches any of those >> specified in the `--tcp-flags' list, drop it? > >This rule simply drops all incoming NEW connections to tcp:22. >By itself, this rule is evil as it forbids to connect via ssh to anyone. > >But with conjunction with the previous one it implements the following >policy: > >- anyone can connect up to 16 times via ssh. >- anyone exceeding the connection limit is tarpitted, and must wait >for an hour to try again. That seems more than fair. Nobody using the system correctly should ever break this rule under normal circumstances and/or conditions. >> How do these commands function to lock out specific addresses or >> address ranges? > >The current implementation works with single source IPs. >Modifying the rules to work with IP ranges is an exercise left for the >reader :) By "the current implementation," do you mean before or after I used the commands you gave? There is nothing in either of these two complex-side command sets that specify a single address. >> In the `--tcp-flags' list, why is `SYN' mentioned twice? >It's simple. There's absolutely no need for these rules to apply once >the connection is established. >Removing SYN match would effecively limit any ssh session to 16 packets >total, which will break ssh in a most curious ways. OK. This is way over my head, I'll just accept it as gospel until I understand it better. Thanks for the explanations though.
