33

Why do we generally configure firewalls to filter out all traffic that we don't specifically allow? Is this just an extra layer of security for defense-in-depth that buys us nothing if we are not running malware on our system?

Are there any dangers in say opening up say ports 60000 to 61000 for incoming UDP connections that is significantly less safe than say just opening up a few ports?

I've just heard of mosh which advertises itself as a better way to do mobile ssh (over wifi/cell phone). Mosh uses UDP rather than TCP, so if you briefly enter a tunnel or your IP address changes (switching cell phone towers), you don't have to wait to come back from congestion control or establish a new ssh session. Basically mosh uses ssh to remotely start a mosh-server as an unprivileged user, exchanges a AES-OCB key using ssh, and then sends/receives encrypted packets (with sequence numbers) to a port in the range 60000-61000, which you should configure your firewall to open.

I'm somewhat uncomfortable with opening up ~1000 ports for incoming (UDP) connections, but can't think of a very good reason for this. If no software is listening for data on that port, it just gets ignored right? (On edit: no -- it actually directs the server to send back a ICMP (ping) destination unreachable response). I guess if I had malware running on my server, it could be waiting to listen to instructions from forged IP addresses on one of these opened ports. However, malware running on an internet connected systems already could establish connections/download information from other malware servers (though would have to know an IP address) and fetch instructions, so this doesn't make the security that much less secure.

EDIT: Interesting, just saw this other question which lead me to read about UDP_flood_attack. I guess additionally I would need to somehow disable my system from sending ping destination unreachable replies for the newly opened UDP ports.

Improve this question
1
  • This is the one I've been thinking about with mosh, that and while they use OCB mode, it's not all that verified yet, and their implementation certainly isn't. I was considering if it would be possible to just send a request to the firewall to open on-demand, but one would need a root service running to get the requests and open the necessary port, and it's harder on separate hardware firewalls.
    – ewanm89
    Commented Apr 13, 2012 at 0:17

4 Answers 4

Reset to default
13

In addition to Justin's answer about inadvertently opening up applications to be remotely accessed, remember that even if nothing is specifically listening for a connection, the operating system is ALWAYS going to be listening -- if only to route/map to the appropriate process or refuse or silently drop the packet. Therefore, the operating system is still one specific attack vector which can remain unprotected when a firewall allows traffic to flow to an "inactive" port.

However, all things being equal in this scenario, opening up one inactive port or 1000 inactive ports makes little difference. But definitely heed the advice of principle of least privilege.

Improve this answer
12

As far as I understand, Mosh doesn't really need a thousand ports to work; it only needs one (per client). So you can open up any single port, and tell Mosh to use it (from the manual):

mosh -p 60000 my.server

What is the reason for selecting the port at random? This I do not understand.

[UPDATE] it does not select a random port. It searches through a set of ports to find the first open one (see code). If not for this, you'd have to pick a free port manually on a multi-user system.

This means that you only need as much ports as you have users (people who might use mosh) on your server. If it's your own box, you only need to open up port 60000.

Improve this answer
4
  • Minor nitpick: maximum port number is 65535.
    – mlp
    Commented Jun 12, 2012 at 7:01
  • 5
    If you limit to a single port, each user can only have one mosh session to each server. I often like to have multiple simultaneous connections to the same server.
    – Nicholas Tolley Cottrell
    Commented Jan 11, 2013 at 9:20
  • @NicholasTolleyCottrell Would SO_REUSEPORT mitigate this?
    – Janus Troelsen
    Commented Jun 3, 2014 at 12:49
  • One port is not enough if you must expect that the mosh-client could be terminated unexpectedly e.g. by closing a terminal window. The session info is lost, while the mosh-server process on the server side is waiting to continue communication. The user should login to the server and to kill the old mosh-server process, otherwise many ports in the range become blocked by that mosh-server processes with lost sessions and a new mosh session could be impossible. A solution is ssh me@the-server -c "pkill -U my_uid mosh-server".
    – hynekcer
    Commented May 10, 2017 at 16:23
8

The problem is that opening up a large range of ports might allow an attacker to expose another application that may be using those ports. For example, my EMR application that is used to store patient records might be configured to use those range of ports, but I do not want someone from the untrusted Internet to be able to exploit that opening. It comes down to enforcing least privledge as much as you can. In these scenarios you would want to leverage a VPN that would have that port range open. That takes care of the problem of authentication and therefore authorization. If your talking about your external firewall on your DMZ your trusting only at the protocol/port level and therefore have to be even more strict.

Improve this answer
3
  • 2
    VPN typically performs poorly while mobile (connection loss when IP changes or signal temporarily lost), which is the main use-case for mosh over traditional ssh. I definitely would not try a new relatively untested product like mosh on an important production system like an EMR (which should be heavily restricted anyway; e.g., intranet only)--I'm considering testing on my home server for mundane stuff. Any real application shouldn't be listening on ports outside 0-1023 (rarely up to ~10000; /etc/services lists only two apps above 20k (none over 30k) using UDP - both little used.
    – dr jimbob
    Commented Apr 17, 2012 at 16:29
  • 1
    Using a VPN would completely destroy three usefulness of mosh. There is a time and place for everything, but while this answer may have decent generic value, it fails to take into account the use case in the question and ends up offering negative value advice.
    – Caleb
    Commented Jun 11, 2012 at 17:31
  • 2
    I'm not sure you want your EMR server accessible from the internet anyway. Even if you do, I think you could reduce the ports down to a manageable range and then ensure nothing else is using those ports (including a UDP port scan). I would imagine that your EMR application probably uses TCP though.
    – Bradley Kreider
    Commented Nov 30, 2012 at 17:01
5

It should be perfectly possible to minimize mosh's UDP port range in

https://github.com/keithw/mosh/blob/master/src/network/network.h#L77

If I understood correctly this is the range from which the sender process will pick the UDP port. So it should be possible to compile a local "narrow-range" mosh edition and have a fitting local "narrow-range" firewall UDP policy for mosh.

Which brings me to the meta question: how narrow a range is wide enough for mosh being useful?

If I understood correctly, one port per mosh server is needed. So in the case of a personal server and the habitual use of tmux (= only one client) one for working and one for fixing things is needed.

But I may be wrong, I'm no C coder and I discovered mosh only yesterday.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .