[SOLVED] SSH to a computer behind a DD-WRT router

upnort · 11-24-2016, 08:58 PM

I want to remotely SSH into my home LAN server from anywhere outside the home.

I am using a recent beta of DD-WRT on an Asus RT-AC66U.

The ISP has provided me a static IP address. I am using SSH key pairs with a pass phrase. The public keys have been copied to the server and router.

I configured the router to allow remote access SSH using port 2387.

I configured port forwarding in DD-WRT:

static.public.ip.address WAN port 3498 -> static.private.server.address port 22

My ~/.ssh/config file looks like this:

Code:

Host remote_router
  HostName static.public.ip.address
  Port 2387
  User root
  IdentityFile ~/.ssh/remote_router
Host remote_server
  HostName static.public.ip.address
  Port 3498
  User abcd
  IdentityFile ~/.ssh/remote_server

The two configurations are similar, using different WAN side ports and key-pairs. The first configuration connects successfully to the router. The second is supposed to connect to the LAN server using port forwarding in the router.

I can SSH directly into the router using the static public IP address. Smooth as silk. The direct router connection affirms no problems with NAT or the public IP address.

The LAN server connection attempt always times out. Using the SSH verbose option does not help.

The DD-WRT logs show me connecting directly to the router. The logs show nothing when attempting to connect to the LAN server through port forwarding.

Disabling the DD-WRT firewall has no effect.

Running nmap -Pn -p 2387 static.public.ip.address shows the port is open. Running nmap -Pn -p 3498 static.public.ip.address shows the port is filtered. Perhaps this means DD-WRT is not actually forwarding the port.

The ISP is not filtering or blocking ports.

Despite the security concerns, as a quick proof-of-concept I temporarily configured a PPTP VPN. I connected directly to my LAN, again affirming no problems with the public IP address. I eventually will configure OpenVPN, but I still want the SSH option as well.

I do not want to use a third system and reverse SSH.

I have looked at many online posts about this topic. At the moment I am stumped.

I appreciate any help from somebody who uses DD-WRT and can SSH successfully to a computer behind the router. I am hoping I am missing something obvious.

Thanks.

Edit:
The DD-WRT iptables rules show the following:

Code:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             lan.server            tcp dpt:ssh 
ACCEPT     udp  --  anywhere             lan.server            udp dpt:ssh

That would seem to indicate the router should be forwarding the port.

sag47 · 11-25-2016, 10:38 AM

Have you checked the firewall of the internal server? If you run tcpdump on the internal server do you see traffic hitting the server? Is sshd outputting logs to /var/log/secure or /var/log/auth.log?

upnort · 11-25-2016, 11:01 AM

I did not mention that, yes, I had checked /var/log/secure. The firewall is not blocking because on the LAN side all computers are configured to trust everything on the subnet, including the firewall. For example, when I SSH into the router, either from the Internet or the LAN, I can ping back to any box on the subnet, including the server. I can SSH into the server from any box in the LAN that has SSH key pairs correctly stored.

There is nothing in the router logs when I try to use port forwarding, but there are entries when I SSH into the router from the Internet or LAN. I would think, but could be wrong, that with port forwarding I would see something in the router logs.

I have not tried running tcpdump on the server while attempting to port forward through the router. Did not seem important because nothing seems to be getting through the router.

jefro · 11-25-2016, 03:07 PM

Just some thoughts.

Guess you read this already but I'll point it out just in case. http://www.dd-wrt.com/wiki/index.php...ort_Forwarding

Since you can get into the router from the outside, what happens when you then go from router to home lan computer?

rknichols · 11-25-2016, 07:37 PM

Quote:

Originally Posted by upnort

I did not mention that, yes, I had checked /var/log/secure. The firewall is not blocking because on the LAN side all computers are configured to trust everything on the subnet, including the firewall.

The packet received by the server will retain its original source address and will not have a source address in your LAN subnet.

sag47 · 11-25-2016, 10:05 PM

Quote:

Originally Posted by rknichols

The packet received by the server will retain its original source address and will not have a source address in your LAN subnet.

^^ that is true. Your firewall on the internal server is likely blocking internet addresses which is the source in port forwarding. Firewall logs should show it blocking and tcpdump should show one way traffic.

upnort · 11-26-2016, 04:42 PM

Thanks for the tips everybody.

There were two obstacles.

One, I had to add an iptables rule to allow external access to port 22. My firewall rules only allowed SSH access from the LAN subnet.

The generic rule:

Code:

/sbin/iptables -A tcp_inbound -p TCP -s 0/0 --destination-port 22 -j ACCEPT

To limit remote access to my public IP address I modified the rule to:

Code:

/sbin/iptables -A tcp_inbound -p TCP -s static.public.ip.address --destination-port 22 -j ACCEPT

Two, I had to edit /etc/hosts.allow to allow sshd access from static.public.ip.address. My hosts.allow only accepted everything local to the LAN subnet.

These original configurations made sense because I never allowed remote access to my LAN. All WAN side access on my router was closed.

Now that I have remote access to my LAN server, I created some firewall rules to block brute force attacks. I added some meaningful logging for the firewall rules.

I would like to add some email alerts of any non LAN IP addresses. How best to implement this?

sag47 · 11-26-2016, 06:22 PM

Install fail2ban and disable password auth on WAN are my two recommendations. Here's a snippet of my /etc/ssh/sshd_config and my LAN is 192.168.10.x.

Code:

AllowGroups sshusers chrootjail
Match Address 192.168.10.0/24
    PasswordAuthentication yes
Match group chrootjail
    ChrootDirectory /var/jail
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp
Match All
    PasswordAuthentication no
    ChallengeResponseAuthentication no

Then make sure a specific user you want to have SSH access is in the sshusers group. This helps protect against default accounts using SSH.

jefro · 11-26-2016, 08:28 PM

Thanks for the update and solution.

As noted by sag47 you need to secure SSH access more than you'd think. Bots are trying to access it everywhere. I'd even consider time based service open and/or self signed certificates. At least have a very secure password.

sag47 · 11-26-2016, 11:23 PM

Port knocking using knockd is another thing to consider.

Turbocapitalist · 11-27-2016, 06:16 AM

Quote:

Originally Posted by upnort

Two, I had to edit /etc/hosts.allow to allow sshd access from static.public.ip.address. My hosts.allow only accepted everything local to the LAN subnet.

tcpwrappers support has already gone away for more recent versions of OpenSSH. So if you want to future-proof your configurations, do away with hosts.allow and hosts.deny and let the local firewall take that job.

upnort · 11-27-2016, 11:56 AM

I am using Slackware on the LAN server. OpenSSH is built with tcp-wrapper support.

To further clarify, for these two external WAN connections I am using key pairs and a 20+ character pass phrase using mixed characters. Malicious actors need both to connect.

Inside the LAN I use only key pairs. This is a home LAN and all computers inside the LAN are trusted. No Windows machines are on the LAN.

Likely I will keep the WAN side services disabled until needed and the ports would not be open 24/7. Thankfully, toggling the services is a few check boxes in DD-WRT.

The DD-WRT firewall log shows continual port scanning. SSH and Telnet ports are the most popular.

The LAN server logs are not yet showing anything punching through the port forwarding except my own testing. I am guessing that even if a port scan revealed the port I am forwarding, a malicious actor still needs to investigate further. I am using ports higher than 1000. A standard "lazy" nmap scan only scans the first 1000 ports.

Like onions and ogres, I am aware that security is about layers. Configuring for remote access is new to me but tens of thousands of people do this daily. I'll keep reading and learning.

I am aware of the concept of port knocking. I need to read more.

For emails, looks like fail2ban or denyhosts or something similar might suffice. Possibly a challenge though is the LAN server is not directly facing the Internet. The DD-WRT router does that. The only IP addresses the LAN server will see for SSH requests are from the LAN subnet and the single public IP address. I do not want to programmatically block the public IP address.

I have the firewall rules configured at the LAN server to rate limit brute force attempts. As I use key pairs within the LAN that means all brute force attacks will fail even if they are cleverly timed to avoid the firewall rate limiting. I added similar rate limiting rules in DD-WRT for the specific port I am forwarding. DD-WRT is already designed to rate limit brute force attacks on the WAN side SSH port.

I would like to learn more about how to test all of the changes I have made. I have noticed that running nmap port scans against the public IP address return mixed results. Sometimes the open ports show open and other times they show filtered. I am guessing the DD-WRT rate limiting might be affecting the results. I also noticed that when I run nmap port scans against the public IP address that I could not actually use SSH to get into the router or LAN server. I had to wait a while to get in. I am guessing again that the rate limiting rules prevented me from getting in. If my guessing is correct or close then that is kind of cool.

I should start a new thread with respect to testing or monitoring the open WAN ports on the router.

Now on to configuring a VPN.