Site Map - skip to main content - dyslexic font - mobile - text - print

Hacker Public Radio

Your ideas, projects, opinions - podcasted.

New episodes Monday through Friday.


Our hosting is kindly provided by Josh from AnHonestHost.com. We would appreciate it if you could donate to help reduce his costs in funding the hosting.
He is also accepting bitcoins to 1KsxJr9HtsdaUeU7yaV9bk9bQi21UPBtUq

hpr1924 :: Port Forwarding

In HPR 1900, Ahuka suggests changing the default ssh port, I ask why not employ port forwarding?

<< First, < Previous, Latest >>

Host Image
Hosted by FiftyOneFifty on 2015-12-17 is flagged as Clean and is released under a CC-BY-SA license.
Listen in ogg, spx, or mp3 format. | Comments (1)

Part of the series: Privacy and Security

In this open series, you can contribute shows that are on the topic of Privacy and Security

Port Forwarding

In Episode 1900, Ahuka advised you not to expose the ssh service to the Internet on the default port 22, there we agree. This is called "Security Through Obscurity". Whenever possible, server functions exposed to the Internet should be on non-default port numbers (the exception being HTTP on a public web server). I disagree however, in Ahuka's method of changing the port. He said you should change the port on the server itself:

From http://www.cyberciti.biz/tips/setup-ssh-to-run-on-a-non-standard-port.html

Open /etc/ssh/sshd_config file and look for line Port 22 and change line to Port 2222. Restart sshd server. systemctl restart sshd

Sshd is running on a non-standard port, connection attempts to the system will fail. You need to connect using following command:

$ ssh -p 2222 user@your-ip OR $ ssh -p 2222 user@you.homenetwork.org

This could make sense if you manage a business or school network, where you have numerous users within your network with whom you share varying levels of trust. Still, I don't think anyone who can brute force your shh logon or shared keys would be stymied by a simple change of ports. But Ahuka also mentioned home networks, and I think we would rather keep things simple. I would humbly suggest keep ssh servers set to port 22 internally, and using a technology called "port forwarding" available on most consumer routers. Port forwarding is simply an administrator configured table that redirects incoming traffic on one IP port to a specific internal IP address and IP port on your internal network. In fact, unless you have only one PC connected directly to you ISP with no router or firewall, you will still need to setup port forwarding to tell the router which machine on your network the for which incoming communication is intended.

In other words, let's say you've enabled ssh on port 40001 of a machine with an internal address of 192.168.1.5. You try to login remotely via ssh on port 40001 using the external IP assigned to you by your ISP (which is taken from a range assigned to them by the IANA). The external IP of your router should be displayed on your router's status page, or you could type "what is my IP" into Google. Instead of an IP in the range 192.168.x.y, like you are probably using internally, your external address will be in the Class A or B range, for instance 73.149.12.124.

So let's say you have ssh server running on port 40001 on a machine with IP adddress 192.168.1.5 on your home network. Your server has an external address of 73.149.12.124. You are at work or on vaction or whatever and you want to ssh into that machine on your home network, i.e,

ssh -p 40001 you@73.149.12.124

Unless the router itself supports ssh server (entirely possible with third party Linux based firmwares like Open-WRT and DD-WRT), if you haven't configured port fowarding, the router won't have any idea what to do with an incoming request on port 40001. You need to set up your port forwarding table in your router (don't worry, it's all point and click). IP forwarding may be under Advanced, in the menus, or Security, or Firewall, or a combination of the above.

You will be asked to enter the external port number (in our example, 40001), TCP or UDP or both (in our case, ssh is both, so you may have to create two separate entries), the internal IP address (in our example 192.168.1.5) and the internal port number (if you changed it internally as Ahuka recommended, in our example 40001, but, and this is the whole point of this podcast, you are going to have to set up port forwarding anyway, so why change the port number locally in the first place? If the terms TCP (Transport Control Protocol) and UDP (User Data Protocol) are unfamiliar to you, the difference can easily be explained. Using TCP, the computer transmitting data stops every few packets (I think the default is three, but don't hold me to it) until it gets an acknowledgment from the receiver that the packets were successfully received, then the sender continues. With UDP, the sender blurts out the whole transmission without caring whether the receiver go it or not.

Wikipedia has a great article on official and unofficial standardized port numbers. Once you get into five digits, conflicts to already assigned ports are rare, but it's still best to consult the Wiki. The higher numbers are generally not officially assigned, some particular software product is just "squatting" on the number. In fact, using the port number for a technology you are certain will never be used on your network may further obfuscate the service for which you are actually using it. You may think port 40001 is surely high enough to be free of conflict, but the Wiki says 40000 is used by "SafetyNET p Real-time Industrial Ethernet protocol".

Another advantage of port redirection is you could use a different external port number with every host on your network, i.e., 40001 redirects to you server, 40002 redirects to your desktop, 40003 redirects to the old laptop in the kid's room, etc. Personally, I'd only have port redirection into a single machine that is connected persistently (like a server), and the ssh from it into other hosts on the network (yes, this would be a connection of at least three nested shells). You can even run graphical programs over ssh with the -X argument, but I'm leaving that on for later discussion. Of course, we will loose that functionality when we move from x-server to Wayland, so if you need a GUI you may have to investigate technologies like VNC or VPN.

Of course, everything depends on having a static IP locally on the ssh server (either set on host itself or manual assignment of IP on the router, if possible). You either need a static external address on the WAN (i.e., external address as seen from the Internet) side or employ a domain forwarding service. Also keep in mind, once we get Ivp6, everything above goes out the window.


Comments

Subscribe to the comments RSS feed.

Comment #1 posted on 2015-12-17T01:39:58Z by Kevin O'Brien

Great show!

I am really happy that my friend Fifty One-Fifty has continued the conversation on this topic. It is just what I love to see on HPR. It is like listening in on the conversation we might have had together at a conference.

Leave Comment

Note to Verbose Commenters
If you can't fit everything you want to say in the comment below then you really should record a response show instead.

Note to Spammers
All comments are moderated. All links are checked by humans. We strip out all html. Feel free to
record a show about yourself, or your industry, or any other topic we may find interesting. We also check shows for spam :).

Provide feedback
Your Name/Handle:
Title:
Comment:
Anti Spam Question: What does the P in HPR stand for ?
Are you a spammer →
Who hosted this show →
What does HPR mean to you ?