Skip to Content.
Sympa Menu

dynes-deployments - Re: [dynes-deployments] impact of blocking traffic to normal SSH port

Subject: DYNES-Deployments

List archive

Re: [dynes-deployments] impact of blocking traffic to normal SSH port


Chronological Thread 
  • 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:54:50 -0500

Hi Jay,

The short answer is yes;  we can run ssh on any port X fairly simply.  The problem is the inconsistency this puts into the framework.  We have to create special handling for U Iowa in everything we do.  

University's should recognize that a major function that is *required* in Research and Education institutions is collaboration outside of your institution.  As sarcastically noted by both of us, if security trumps everything then cutting the WAN link and turning of the power will make your institution secure and any (known) external IT threat!   In my opinion your security people aren't considering the big picture and are being unreasonable.

I will have to check but I believe there was some sign-off from your CIO and networking people with your DYNES application?  It may be time to contact the CIO and put a line in the sand for the security people?  If, for whatever reason, this won't work we can discuss how best to proceed.   

Sorry you are stuck in the middle on this...I feel your pain!  Let's hope we can figure out a reasonable way forward.  Thanks,

Shawn

On Mon, Dec 17, 2012 at 5:41 PM, Jay Ford <> wrote:
On Mon, 17 Dec 2012, Shawn McKee wrote:
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...)

I completely agree.  We sometimes further suggest powering down the university to save electricity.  ;^)


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.

Again, I agree.  I run similar throttling on my systems.

My attempts to get our security folks to deal with the problem at a system level rather than a campus border level have been unsuccessful so far.


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.

Your comments reinforce my feeling that the DYNES gear is well configured &
thus at reasonably low risk.  Basically, this type of gear is not the
problem.  It's poorly managed or badly implemented devices which are the
problem.

A more pointed version of my original question is perhaps this:

   Can the DYNES system be configured so that uiowa DYNES gear is accessed
   via some other TCP port than 22?

Jay




Archive powered by MHonArc 2.6.16.

Top of Page