CentOS docs - Mar 2013 - Fwd: mistake on Securing SSH

This was sent to me regarding the wiki.
---------- Forwarded message ----------
From: "Martin Kon??ek" <mkonicek12 at gmail.com>
Date: Mar 7, 2013 4:44 AM
Subject: mistake on Securing SSH
To: <timothy.ty.lee at gmail.com>
Cc:

Hi TImothy,

I saw wiki http://wiki.centos.org/HowTos/Network/SecuringSSH and it is
pretty good, but there is a mistake.

*Instead of having*
iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60
--hitcount 4 --name ssh --rsource -j ACCEPT

*You should have*
iptables -A INPUT -p tcp --dport 22 *-m state --state NEW* -m recent --set
--name ssh --rsource
iptables -A INPUT -p tcp --dport 22 *-m state --state NEW* -m recent !
--rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

Brgds.
--
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos-docs/attachments/20130307/85af321c/attachment-0006.html>

On 07/03/13 02:28, Timothy Lee wrote:
> This was sent to me regarding the wiki.
> ---------- Forwarded message ----------
> From: "Martin Kon??ek" <mkonicek12 at gmail.com>
> Date: Mar 7, 2013 4:44 AM
> Subject: mistake on Securing SSH
> To: <timothy.ty.lee at gmail.com>
> Cc:
>
> Hi TImothy,
>
> I saw wiki http://wiki.centos.org/HowTos/Network/SecuringSSH and it is
> pretty good, but there is a mistake.
>
> *Instead of having*
> iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
> iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60
> --hitcount 4 --name ssh --rsource -j ACCEPT
>
> *You should have*
> iptables -A INPUT -p tcp --dport 22 *-m state --state NEW* -m recent --set
> --name ssh --rsource
> iptables -A INPUT -p tcp --dport 22 *-m state --state NEW* -m recent !
> --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT
>
> Brgds.
> --
> Martin
>
>


Many thanks for forwarding Timothy, and to Martin for the feedback.

Updated, although personally I prefer to accept established/related 
connections earlier in the chain prior to deploying such a rule, for 
example:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

At which point, any packets matching that rule are by definition new. 
Still, it's a valid point.