Ssh – what is the required ports to be opened on the firewall

aixfirewallssh

Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.

I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.

My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?

Best Answer

This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.

An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.

The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.

Email should generally go to a relay server which will route it appropriately.

Related Solutions

Ssh – How to configure ssh tunneling past a firewall

You don't need to open tunneled ports on the firewall. You are fine opening only the SSH port.

You may be getting caught by one of a few problems.

The local ports may already be in use. Try using netstat to see if the port is occupied.
When you connect to the tunneled port you will find it a localhost (127.0.0.1) not the remote address. Some software may not like this.
Tunneling can be turned off in the server. In that case your tunnels won't work.
If you are tunneling to another host (remote.ip.address is not on the host you are tunneling through), you may be blocked by the SSH server's AllowTcpForwarding setting.
If you are tunneling to a port on the same host (remote.ip.address is 127.0.0.1, or some other IP on the server) you are tunneling to the destination software may not like it. For example, some VNC servers default to preventing same host connections to prevent looping conditions.

Try connecting with the debug flag enabled.

iptables – Set Firewall Ports to Only Accept Local Network Connections

With the kernel's iptables completely empty (iptables -F), this will do what you ask:

# iptables -A INPUT -p tcp --dport 22 -s 192.168.0.0/24 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -s 127.0.0.0/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP

This says that all LAN addresses are allowed to talk to TCP port 22, that localhost gets the same consideration (yes, 127.* not just 127.0.0.1), and packets from every other address not matching those first two rules get unceremoniously dropped into the bit bucket. You can use REJECT instead of DROP if you want an active rejection (TCP RST) instead of making TCP port 22 a black hole for packets.

If your LAN doesn't use the 192.168.0.* block, you will naturally need to change the IP and mask on the first line to match your LAN's IP scheme.

These commands may not do what you want if your firewall already has some rules configured. (Say iptables -L as root to find out.) What frequently happens is that one of the existing rules grabs the packets you're trying to filter, so that appending new rules has no effect. While you can use -I instead of -A with the iptables command to splice new rules into the middle of a chain instead of appending them, it's usually better to find out how the chains get populated on system boot and modify that process so your new rules always get installed in the correct order.

RHEL 7+

On recent RHEL type systems, the best way to do that is to use firewall-cmd or its GUI equivalent. This tells the OS's firewalld daemon what you want, which is what actually populates and manipulates what you see via iptables -L.

RHEL 6 and Earlier

On older RHEL type systems, the easiest way to modify firewall chains when ordering matters is to edit /etc/sysconfig/iptables. The OS's GUI and TUI firewall tools are rather simplistic, so once you start adding more complex rules like this, it's better to go back to good old config files. Beware, once you start doing this, you risk losing your changes if you ever use the OS's firewall tools to modify the configuration, since it may not know how to deal with handcrafted rules like these.

Add something like this to that file:

-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 192.168.0.0/24 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 127.0.0.0/8 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -j DROP

Where you add it is the tricky bit. If you find a line in that file talking about --dport 22, simply replace it with the three lines above. Otherwise, it should probably go before the first existing line ending in -j ACCEPT. Generally, you'll need to acquire some familiarity with the way iptables works, at which point the correct insertion point will be obvious.

Save that file, then say service iptables restart to reload the firewall rules. Be sure to do this while logged into the console, in case you fat-finger the edits! You don't want to lock yourself out of your machine while logged in over SSH.

The similarity to the commands above is no coincidence. Most of this file consists of arguments to the iptables command. The differences relative to the above are that the iptables command is dropped and the INPUT chain name becomes the special RHEL-specific RH-Firewall-1-INPUT chain. (If you care to examine the file in more detail, you'll see earlier in the file where they've essentially renamed the INPUT chain. Why? Couldn't say.)