DYNES-Deployments

[Jay Ford <>]

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