Artwork

Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

HPR1924: Port Forwarding

 
Share
 

Archived series ("Inactive feed" status)

When? This feed was archived on February 10, 2021 18:12 (3y ago). Last successful fetch was on February 26, 2021 20:39 (3y ago)

Why? Inactive feed status. Our servers were unable to retrieve a valid podcast feed for a sustained period.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 121125566 series 49648
Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

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.

Links

  continue reading

3280 episodes

Artwork

HPR1924: Port Forwarding

Hacker Public Radio

74 subscribers

published

iconShare
 

Archived series ("Inactive feed" status)

When? This feed was archived on February 10, 2021 18:12 (3y ago). Last successful fetch was on February 26, 2021 20:39 (3y ago)

Why? Inactive feed status. Our servers were unable to retrieve a valid podcast feed for a sustained period.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 121125566 series 49648
Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

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.

Links

  continue reading

3280 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide