<div dir="ltr">I think if you use double authentication (both keys and a password) and put your SSH server on a different port then you are doing the best you can. You hope to prevent a 0-day but you cannot fully protect yourself...<br>
<br><br>James<br><br><div class="gmail_quote">On Fri, Jul 10, 2009 at 7:06 PM, Rob Townley <span dir="ltr"><<a href="mailto:rob.townley@gmail.com">rob.townley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Fri, Jul 10, 2009 at 9:33 AM, Peter Kjellstrom<<a href="mailto:cap@nsc.liu.se">cap@nsc.liu.se</a>> wrote:<br>
> On Friday 10 July 2009, Rob Kampen wrote:<br>
>> Coert Waagmeester wrote:<br>
> ...<br>
>> > it only allows one NEW connection to ssh per minute.<br>
>> ><br>
>> > That is also a good protection right?<br>
> ...<br>
>> Not really protection - rather a deterrent - it just makes it slower for<br>
>> the script kiddies that try brute force attacks<br>
><br>
> Basically it's not so much about protection in the end as it is about keeping<br>
> your secure-log readable. Or maybe also a sense of being secure...<br>
><br>
> It's always good to limit your exposure but you really have to weigh cost<br>
> against the win. Two examples:<br>
><br>
> Limit from which hosts you can login to a server:<br>
>  Configuration cost: trivial setup (one iptables line)<br>
>  Additional cost: between no impact and some impact depending on your habits<br>
>  Positive effect: 99.9+% of all scans and login attempts are now gone<br>
>  Verdict: Clear win as long as the set of servers are easily identifiable<br>
><br>
> Elaborate knocking/blocking setup:<br>
>  Configuration cost: significant (include keeping it up-to-date)<br>
>  Additional cost: setup of clients for knocking, use of -p XXX for new port<br>
>  Positive effect: "standard scans" will probably miss but not air tight<br>
>  Verdict: Harder to judge, I think it's often not worth it<br>
><br>
> Other things worth looking into are, for example, access.conf (pam_access.so)<br>
> and ensuring that non-trivial passwords are used.<br>
><br>
> my €0.02,<br>
>  Peter<br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> CentOS mailing list<br>
> <a href="mailto:CentOS@centos.org">CentOS@centos.org</a><br>
> <a href="http://lists.centos.org/mailman/listinfo/centos" target="_blank">http://lists.centos.org/mailman/listinfo/centos</a><br>
><br>
><br>
<br>
</div>Virtual Networks are such as <a href="http://tinc-vpn.org" target="_blank">tinc-vpn.org</a> or hamachi create an<br>
encrypted network only accessible to members of the virtual network.<br>
So if your server's virtual nic has an address of 5.4.3.2, then the<br>
only other host that may see your server would be your laptop with<br>
address 5.4.3.3.  No other internet hosts would even see 5.4.3.2...<br>
It is like IPSec, but much easier.<br>
<div><div></div><div class="h5">_______________________________________________<br>
CentOS mailing list<br>
<a href="mailto:CentOS@centos.org">CentOS@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos" target="_blank">http://lists.centos.org/mailman/listinfo/centos</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.goldwatches.com">http://www.goldwatches.com</a><br><br><br><br>
</div>