How do I add a dyndns alias to my Iptables?

Question

First of all: I'm aware of this old question: iptables allow dyndns domain name and auto update rules But somehow it doesn't help me.

The Problem

Iptables on my work pc are configured to drop all requests from the internet except for a few chosen ip-adresses. This is because we face about 10,000 attacks a day. Form time to time I'd like to ssh into my work pc from home. At home however I do not have a static ip.

My solution (semi-working)

So I figured I register with dyndns and add a rule to /etc/iptables for that dynalias myUser.dynalias.net:

# in /etc/iptables

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT
# namesevers
-A RH-Firewall-1-INPUT -p 50 -d some.local.ip -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -d the.same.local.ip -j ACCEPT
    # ...and so on...
# all connections already established (started outgoing from my machine)
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow local connections
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 --source some.local.ip/255.255.0.0 -j ACCEPT
# allow my dns
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 --source myuser.dynalias.net -j ACCEPT
# block all others (without answering - thus nobody is able to scan the network)
-A INPUT -p icmp --icmp-type echo-request -j DROP
-A RH-Firewall-1-INPUT -j DROP
COMMIT

What's not working with this solution

That works until my home ip is reset each day at midnight. So on weekends I'm basically screwed and can not login. My guess is, that I have to update the rule on a regular basis (e.g. using cron). My question is: How do I update the rule on regular basis? For some reason, when I update the table on a running system using:

The update commands (not working):

sudo iptables -D RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 --source ip.that's.listed.by.-L.option -j ACCEP
sudo iptables -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 --source myUser.dynalias.net -j ACCEP

I can not ssh into my work pc after that update. The only thing that helps is calling someone to reboot my work pc. Somehow the changes will not take effect without that reboot despite the rule being listed correctly:

username@server:~/bin$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            
DROP       icmp --  anywhere             anywhere            icmp echo-request 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

Chain RH-Firewall-1-INPUT (2 references)
# some stuff (e.g. nameserver)
# ....
DROP       all  --  anywhere             anywhere    
ACCEPT     tcp  --  123-123-12-123.host.name.foo.bar.at  anywhere            state NEW tcp dpt:ssh 

In this listing there is no difference before and after update at all - it just doesn't work to ssh into the work pc.

Answer 1

Some times ago, I was faced to the same problem, and my solution was to create a template iptables files of rules, to modify on the basis of the current dyndns retrieved IP, then setup the tables with iptable-restore. The routine tested the IP periodically and updated the firewall when required.

I abandoned such approach when a collegue asked to use the same ssh server, and setting up the system for two IPs, though not particularly difficult, make me change my mind.

I would suggest some other way to approach the problem.

A commonly used approach is to use software to detect and block attacks. For example fail2ban can analyze ssh logs at runtime and ban/unban suspicious hosts using firewall rules.

On the other part, denyhosts add suspicious hosts to /etc/hosts.deny, achieving the same target of fail2ban.

Yet another option is to use a third party public ssh server (see shellium, blinkensheel, etc.) as a bridge to reach your personal ssh server, in which you should trust the public server and no others, and which as a static IP.

I'm sure experts out there can suggest yet other solution better than what I suggest.