I work in a University Security office, and although our institution's approach sounds different from yours, I'll see if I can explain where they are coming from.
Just to clarify - there is a big difference between a bastion host and the
server that you eventually want to talk to. The bastion should be locked
down to make almost any operation *except* inwards connection impossible,
in order to prevent users on the bastion from attacking each other.
Excerpts from Hayden Metsky's message of 2015-08-08 11:33:19 +1200:
> * "Mosh requires opening UDP ports on the Broad perimeter. That makes
> the Broad network available as a participant in a DDoS performed
> against external entities, specifically ICMP PORT UNREACHABLE class of
> attack ("Smack" is one productized version). Even unwitting
> participation by the Broad in a DDoS could have materially damaging
> effect upon the Broad as a whole and the outcome of such an event
> would inevitably involve closing the ports anyway."
> - This is the team's primary concern. Our initial thought is that it
> is difficult to imagine a single machine (server or router) having
> a meaningful impact in a DDoS amplification, but perhaps this is
> mistaken. Or maybe it is possible to use mosh with restrictions on
> outgoing traffic that would avoid the Broad from participating in
> this kind of attack? Even though this is not specific to mosh, we
> would very much appreciate your thoughts.
It's difficult to imagine one machine making a significant technical
difference to an attack, but there is still reputational damage to
consider; I assume that they have their firewalls set to drop all traffic
over UDP (rather than reject) in that case. Allowing the UDP ports to
receive traffic from the Internet then allows the OS to either accept or
reject the packet, and the rejection ICMP messages are unwanted; it would
be technically possible to just drop outbound ICMP messages instead. There
may still be some packet leakage, but it should be much reduced.
> * "Mosh is based on the experimental MIT State Synchronization Protocol
> (SSP). SSP is not know to any commercially available firewalls or
> perimeter devices, so the use of mosh would not be manageable. Also
> the first UDP mosh packet is from client to server. That underscores
> the fact that there is no way for a firewall to have any control of
> state."
Agreed that this is a problem. However, even knowing SSP at the firewall
wouldn't help, because SSP doesn't align with traditional src/dst state;
any source address can be used at any time to 'take over' a session, and
the "most recent" connection is not always the correct one.
The vast majority of firewalls are used in a stateful mode, which keeps
track of src/dst connections. As a client roams, we end up with multiple
src/dst pairs and only one of them is actually needed - the firewall has
no way of telling which one is actually valid. These connections also need
to timeout, while SSP doesn't, so we'll get the cost of removing a state
and setting it back up again sometimes (that's inefficiency, not
necessarily an actual problem)
So the firewall's state tracking for SSP will be inefficient - this isn't
very good, especially for a busy site.
> * "Both Google and Mozilla have rejected mosh."
> - I don't know about Mozilla, but my understanding is that this is
> incorrect with regard to Google. Even if Google only allows mosh
> access from within a VPN and we're asking the Broad to allow access
> from outside (ssh is allowed from outside), it is difficult to see
> how this is an argument against mosh.
I guess that's irrelevant unless they provide references to what decision
was made in what context.
> * "Mosh sends the session key as an environment variable. User-
> controlled environment variables are an injection path - their use
> for sensitive purposes opens security vulnerabilities."
>
> * "Mosh requires server-side modification to /etc/sshd_config to enable
> 'SendEnv LANG LC_*'; this is turned off by default to protect against
> environment variable injection."
>
> * "The mosh client can, at startup, invoke any program on the server.
> The program does not have to be the mosh-server. So it is an
> unrestricted and unmonitored remote execution environment like rsh."
These are arguments about the security of the bastion host itself, and not
mosh per-se. Given that the bastion exists only to allow connection
forwarding, their concern seems to be around the possibility that a
hostile mosh client might be able to subvert the bastion. mosh generally
expects that the code is fine because it affects only the user who could
have ssh'd in in the first place; this objection states that the user
doesn't have general-purpose shell access, and therefore the mosh code
needs to be less permissive.
> - We're a bit confused on this point. The same (we believe) is true
> of ssh, and since mosh authenticates via ssh we don't quite see how
> this might be held against mosh given that ssh is already used.
No, the ssh environment is probably very locked down on their bastion.
Hope that helps to suggest some of where they're coming from. Plus in
general it's easier to say "no" than to say "yes" :-)
Have you considered running mosh over a VPN? It might always introduce
more latency (which mosh would try to alleviate), but it should also try
to reconnect when changing network, and as it succeeds, mosh will
reconnect you to your session quickly.
--
Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
✉ jim.cheet...@otago.ac.nz ☏ +64 3 470 4670 ☏ m +64 21 279 4670
⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605
signature.asc
Description: PGP signature
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
