Inbound: Allowing SSH to a Local System | Troubleshooting Linux Firewalls

Secure Shell (SSH) is the most common means out there of remotely administering a system. If you are in a situation where you have to explicitly allow an SSH session to your system, undoubtedly you have already grasped the concept of an "unless allow, deny" policy; however, as a recap, you would need to specify the following rule if your system was configured with a default -j DROP policy on the INPUT chain.

SSH, by default uses TCP port 22. To allow SSH connections to your system, you need to add the following rule:

 $IPTABLES -A INPUT -p tcp -dport 22 -j ACCEPT

SSH supports userland connection filtering, using tcpwrappers; however, we recommend that you limit direct access to your services whenever you can because every service, including SSH, has had some type of remotely exploitable vulnerability that something like tcpwrappers would not save you from. The following example rule demonstrates a firewall set up to restrict access to only the SSH port from the hosts 22.33.44.55 and 11.22.33.44:

 # where $DNSSERVER is your systems designated DNSSERVER $IPTABLES -P INPUT -j DROP $IPTABLES -A INPUT -s  11.22.33.44 -p tcp --dport 22 \       -j ACCEPT $IPTABLES -A INPUT -s  22.33.44.55 -p tcp --dport 22 \       -j ACCEPT # allow DNS $IPTABLES -A INPUT -p udp -m udp -s $DNSSERVER \       --sport 53 -d 0/0 -j ACCEPT

This last rule allows the system to make DNS lookups. The next example was generated by Redhat's Lokkit utility and demonstrates using a user-defined chain to achieve the same:

 #part 1 $IPTABLES -N SSHCLIENTS $IPTABLES -A INPUT -N SSHCLIENTS $IPTABLES -A FORWARD -j SSHCLIENTS $IPTABLES -A SSHCLIENTS -p tcp -m tcp --dport 22 \       -s 11.22.33.44 ---syn -j ACCEPT $IPTABLES -A SSHCLIENTS -p tcp -m tcp --dport 22 \       -s  22.33.44.55 --syn -j ACCEPT $IPTABLES -A SSHCLIENTS -j ACCEPT #part 2 $IPTABLES -A  SSHCLIENTS -p udp -m udp -s $DNSSERVER \       --sport 53 -d 0/0 -j ACCEPT #part 3 $IPTABLES -A SSHCLIENTS -p tcp -m tcp --syn -j REJECT $IPTABLES -A SSHCLIENTS -p udp -m udp -j REJECT

In part 1 of these rules, we first create the user-defined chain, SSHCLIENTS with iptables -N SSHCLIENTS and then set the user define chain to be applied against the INPUT and FORWARD chains. This is so we can store our SSH rules in one chain and, if we were in a diagnostic mode, easily disable them. Also take note of the syn flagthis means that the connection is to be accepted if it starts with a SYN packet. If it does not, the rule will not be matched and the traffic discarded by rules farther down.

Part 2 of this ruleset allows the system to make DNS queries.

Part 3 is where we set the deny policy. Any packets that do not match the ruleset in part 1 will be caught and dumped with a RST/ACK message from the server. The plus side to using -j REJECT is that it returns this response to the system originating the connection cleanly (in theory, there are a lot of broken IP devices out there) and shutting down the connection. The downside is that if you were trying to hide that you had an SSH service on this system, you just failed because you sent the bad guy an RST/ACK response. If you just want to drop the packets into the ether, use -j DROP.