ddos defence?

[Paul Allen Newell]

On 1/18/2012 12:39 PM, James Wilkinson wrote:
> jdow suggested:
>> iptables -A INPUT -p tcp --syn --dport 22 -m recent --name
>> sshattack --set
>> iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
>>    --rcheck --seconds 60 --hitcount 2 -j LOG --log-prefix 'SSH REJECT: ' \
>>    --log-level info
>> iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
>>    --rcheck --seconds 60 --hitcount 2 -j REJECT --reject-with tcp-reset
> Paul Allen Newell asked:
>> How does one add a rule to this that allows LAN attempts to not be
>> subject to this rule? Often when I need to sync things up, I ssh to
>> all machines in the LAN and can do more than one within 60 seconds.
>> Normal traffic is expected to be near nil, but the blast of everyone
>> ssh's to everyone does happen.
> I’d imagine adding --src ! 192.168.0.0/24 after --dport 22 would do this
> (replace 192.168.0.0 with whatever’s appropriate for your LAN).
>
> Alternatively, you could set up a .ssh/config file (on the client) with
> ControlMaster and ControlPath (and possibly ControlPersist) set. This
> allows you to have multiple sessions multiplexed over the one SSH
> connection: later connections “piggyback” on the first and won’t fire
> these rules (because they won’t be new TCP/IP connections, so no SYN
> gets sent).
>
> As a bonus, later sessions don’t have to do the same security
> handshakes, so they become ready much more quickly, which is noticeable
> on an Atom.
>
> man ssh_config for details, or for an example:
>
> Host rawhide
>     HostName rawhide.example.com
>     User james
>     ControlMaster auto
>     ControlPath ~/.ssh/master-%r@%h:%p
>     ControlPersist 60
>     ForwardX11 yes
>     ForwardX11Trusted yes
>     Protocol 2
>
> Hope this helps,
>
> James.

James:

Sorry for the delay in getting back.

The iptable info helps, I need to read up on ssh_config / ControlMaster 
/ ControlPath to understand what your suggestion does

Thanks,
Paul