ddos defence?

[James Wilkinson]

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.
-- 
E-mail:     james@ |    “Just for once, I wish we would encounter an alien
aprilcottage.co.uk | menace that wasn’t immune to bullets...”
                   |     -- The Brigadier, ‘Doctor Who’