ddos defence?
James Wilkinson
fedora at aprilcottage.co.uk
Wed Jan 18 20:39:24 UTC 2012
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’
More information about the users
mailing list