Accessing IP restricted server from dynamic IP

hi,

Our servers (all CentOS) are all restricted by IP but often i am out and about and stuck on a dynamic IP address. Using a DynDNS widget I have set this dynamic IP to always sync with a DynDNS hostname but how should i go about making this resolve to an IP in hosts.allow. For the moment i've written a cron script that runs every few minutes and checks the IP assigned to that hostname and writes the dynamic IP to hosts.allow but i'm not too keen on that as a solution. Is there a more elegant way i could be doing this?

Thanks.

From serverfault seengee

• I'd suggest port knocking as an alternative, alternatively rent a ssh account on a 3rd party server and SSH from there.

  seengee : you mean have a non IP blocked SSH account and SSH through there?

  Hubert Kario : no, I mean use a shell service account, for example one from those: http://shells.red-pill.eu/, this way you have a computer you can ssh through that has static IP. Use port forwarding not ssh from its shell to be secure.

  seengee : interesting, i'll look into that
  From Hubert Kario

• My current solution for this is webknocking where I first make a request to a special web page (optionally with my user/pass) that opens up the SSH gates for the IP that I request from. This is how I ssh into some of my servers from my phone. This keeps the extra software involved to a minimum so I could sit down at some cafe computer and authorize it for standard ssh access in a few seconds, but keeps the intruders from even being able to play with my ssh port. A drawback of any knocking solution is the extra point of failure. My safety net is a few hard coded IP's that are allowed access and if something goes wrong with the knocking scripts or web server that handles them, I just have to use one of the other machines that has permanent access to get into and fix the broken box.

  Alternatively some dynamic ip systems have "hooks" or "callbacks" that can be used to get an automated notification of IP address changes. This could be via email or an http request that could be used as a "knock". Alternitavly you could script this on the local end so that whenever your network scripts run or local IP changes, you automatically fire off some kind of knock or trigger that forces and update of dynamic ip access list.

  seengee : another interesting, and totally different solution! I'll look into this also

  Caleb : One of the reasons I chose webknocking over portknocking or vpn/gateway restrictions was the ease of use on other platforms. I use my phone to SSH all the time, and often end up on internet cafe or other non personal computers where the platform could be anything. Getting an ssh client is tricky enough without having an authentication problem, but pretty much any platform that you're going to SSH from is going to be able to make a web page request first. For extra convenience add links to SSH clients on various platforms to your webknocking page after authentication!
  From Caleb

• I can understand your concern about 3rd parties playing with an open SSH port. I have solved this in a different manner. On my private server, the SSH port is open to everybody, but it is monitored by fail2ban, a smart little package available for debian (and probably most other distros, too). As soon as somebody fails to log in after 3 attempts from the same IP address, that address gets blocked in the firewall for several days.

  Ever since I installed this, I had peace and quiet on my server. And I can still log in (using my key from a USB stick) from anywhere in the world.

  If you are the only one logging in to that server, you could also do a simple port forward in the firewall or run sshd on a different port.

  From wolfgangsz

• I would approach this from a different way. Rather than having your servers each maintaining a list of whitelisted IPs, I would configure them all to only allow ssh from "internal" IPs. Then setup a separate gateway/landingpad host that you can VPN in to. Now, you can bounce through that box to reach the rest of the servers securely.

  This limits your attack surface to a single box, instead of all of your boxes. Additionally, many/most VPN solutions allow you to enhance the security requirements for a connection, using certificates, two factor authentication, and other things along with (or instead of) simple passwords. All in all, this will give you greater security, greater flexibility, and much better maintainability.

  There are a number of VPN options available (I'm a big fan of OpenVPN, myself) that you can use to properly setup a secure access point for your devices. Many of them are relatively easy to setup, and for a small setup like this, they require minimal resources.

  seengee : Would i be able to set this up to run on my iPhone?

  Christopher Cashell : Using an iPhone would make things a lot more difficult. Due to it's severely restricted and closed nature, you're limited to what Apple allows. Currently, they do support a few VPN methods (L2TP/IPSec and PPTP, see: http://support.apple.com/kb/ht1288), but not OpenVPN. I did a bit of quick googling, and some people have gotten OpenVPN working on jailbroken iPhones, but that's it. If it were me, I'd skip iPhone support (doing anything meaningful from an iPhone interface is annoying anyway). If it's an absolute requirement, then I'd use OpenVPN for everything else, and add PPTP for iPhone.

  Caleb : @christopher: you make "each" maintaining a list sound like a bad or hard thing. First of all this often happens once at a firewall level not inside the boxe(S) themselves. Secondly the question implies that any solution is going to be scripted anyway, so 1 server or 100, it's going to be automatic. Lastly, having some configuration at the "each server" level is good thing in the fail safe department. I have one client who uses your solution and it's a freaking pain when the vpn/gateway box goes down. The rest of the network suddenly becomes unmaintainable!

  Christopher Cashell : @Caleb: The original poster specifically mentioned 'hosts.allow', which is why I assumed this was happening on individual boxes. Even scripted, the more places you're touching, the more fragile and work to maintain. As for having access to each box being a good thing, I would have to disagree. Segmenting remote access from individual servers is the clean, right way to do this. For the problem described for your client, I consider the issue to be with their lack of fault tolerance in the VPN setup, not a problem with the VPN/gateway concept. Having a backup VPN/gateway box is critical.
  From Christopher Cashell

• The bellow script would ping your dynamic address and grab the ip only and then compare against the ip stored in last_ip.txt, if they are different the ip in hosts.allow will be removed and replaced with the new ip aswell as the ip in last_ip.txt.

  You can then set this code on your crontab to run every 5 minutes or 10 or whatever you seem fit.

  It is not as complex and might solve your problem...

  #!/bin/bash
  
  DYN_IP="www.google.com.br"
  CMD=$(ping -c1 $DYN_IP | head -1 | awk -F' ' '{ print $3}' | sed 's/(\|)//g')
  FILE="./last_ip.txt"
  NEW_IP=$CMD
  
  if [ -e $FILE ]; then
          OLD_IP=$(cat $FILE)
  else
          OLD_IP="0"
  fi
  
  if [ $OLD_IP != $NEW_IP ]; then
          echo $NEW_IP > last_ip.txt
          sed -i "/^sshd: $OLD_IP/d" /etc/hosts.allow
          echo "sshd: $NEW_IP" >> /etc/hosts.allow
          echo "Allow ip changed to $NEW_IP"
  fi
  

  seengee : although this is just a variation on what i'm doing it fits best with the setup i need to keep so i have accepted it
  From Prix

• ConfigServerFirewall has the functionality you desire. Once installed, you can check out this forum post for a good explanation.

  seengee : I like the look of that, will have to look into it further
  From calman