dynes-deployments - Re: [dynes-deployments] impact of blocking traffic to normal SSH port
Subject: DYNES-Deployments
List archive
- From: Shawn McKee <>
- To: Jay Ford <>
- Cc:
- Subject: Re: [dynes-deployments] impact of blocking traffic to normal SSH port
- Date: Mon, 17 Dec 2012 17:27:42 -0500
Hi Jay,
They could also cut the WAN link to campus for an even more effective defense ;) (OK, maybe too sarcastic but firewalls have caused more problems for distributed data-intensive science than anything else I can think of...)
FYI, we have implemented SSH throttling in the default DYNES iptables configuration already. The relevant stanzas from /etc/sysconfig/iptables are:
# ssh throttling
-A INPUT -p tcp -m tcp -m state -m recent --dport ssh --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource
-A INPUT -p tcp -m tcp -m state -m recent --dport ssh --state NEW -j ACCEPT --set --name THROTTLE --rsource
This should allow one ssh attempt every 20 seconds. It could be tuned.
We also have in place an alternate option to only open port 22 to specific DYNES admin subnets. There is some info in the iptables file to show how to do that instead of ssh throttling.
Of course good security involves defense-in-depth: In addition to the iptables setup, the /etc/ssh/sshd_config is setup as follows:
i) Only specific users can login (PermitUser stanza)
ii) PasswordAuthentication is disabled (the script kiddies can try as many times as they want)
iii) Root logins are disabled (PermitRootLogin no)
iv) Only PubKeyAuthentication is enabled
I think this is a much more sane way to protect systems than blindly blocking all port 22 access to the institution.
I hope this would be sufficient to allow all the DYNES equipment to remain accessible to the collaboration. Let us know if you have questions.
Thanks,
Shawn
On Mon, Dec 17, 2012 at 4:45 PM, Jay Ford <> wrote:
DYNES folk:
Our IT security folks are hell-bent on blocking all traffic destined for the
normal SSH port (TCP 22) as it comes into our campus. (This is an effort to
thwart brute-force SSH attacks.)
I think DYNES is dependent on SSH for normal operation, or at least
administration, so I suspect this traffic block will have a negative impact
on our DYNES participation.
Is there a reasonable way to have our DYNES connectivity continue to work in
the presence of the SSH traffic block (other than exempting our DYNES gear
from the traffic block)?
________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: , phone: 319-335-5555, fax: 319-335-2951
- [dynes-deployments] impact of blocking traffic to normal SSH port, Jay Ford, 12/17/2012
- Re: [dynes-deployments] impact of blocking traffic to normal SSH port, Shawn McKee, 12/17/2012
- Re: [dynes-deployments] impact of blocking traffic to normal SSH port, Jay Ford, 12/17/2012
- Re: [dynes-deployments] impact of blocking traffic to normal SSH port, Shawn McKee, 12/17/2012
- Re: [dynes-deployments] impact of blocking traffic to normal SSH port, Jay Ford, 12/17/2012
- Re: [dynes-deployments] impact of blocking traffic to normal SSH port, Shawn McKee, 12/17/2012
Archive powered by MHonArc 2.6.16.