IPTABLES question

server: linux location: NOC
I want to allow ssh access from our home PCs. At home we have cable/DSL modems, So the pubic address changes from time to time. But, I could get a static host name from no-ip.com

Can I use the acutal hostname on the iptables Right now, I am using
".......... -s 67.200.54.36 .............." in a iptable stmt, but I want to be able to use an acutal hostname for the source, which would get resolved by DNS automatically (no-ip.com)

Any solution?
Dont tell me to get an static IP from the ISP.

Good Day,

When you think of IPTables think IP Addresses being filtered and not Hostnames. Proxy or socks = Hostname filtering.

Great Info on IPTables Click Here:

But if there is a way, I hope someone will post it. I'd be happen to learn more as well!

cheers

Hi nomun,

These might help you along the way...I'm not exactly sure what you're asking so I thought I'd cover a few bases...

http://www.hn.edu.cn/book/NetWork/Ne...sh/ch09_02.htm
Port Forwarding (SSH, The Secure Shell: The Definitive Guide)

http://www.linuxguruz.com/iptables/
LinuxGuruz Netfilter IPTABLES Firewall Page

http://yolinux.com/TUTORIALS/LinuxTu...rkGateway.html
Using Linux iptables or ipchains to set up an internet gateway / firewall / routerfor home or office.

http://iptables-tutorial.frozentux.n...-tutorial.html
Iptables Tutorial 1.1.19

Eg ;)

As far i know, the names are resolved by iptables command during rule load; so it wont work like you expect. You will need to reload the rule each time that you ip changes, so it will be useless.
If you think deeply about that idea you will notice that it would be silly resolve the hostname on each packet/connection, wouldnt it? :)
Instead going on that way, why you dont just create a VPN between your home PC and your "corporate" network? It will be FAR more secure.

I have never tried this, so as cacosapo said it may not work as intended, but should be able to keep up with addy changes.

May not be elegant;

Can you write a CRON job to update your /etc/hosts file with the current ip address of your.com from no-ip.com?

then you should be able to use “ -s your.com “

Also, you should probably redirect such requests to another chain so every packet doesn't have to get resolved ( BAD DOG, BAD, BAD ) , something like

if eth0 is Internet facing device:

Quote:

---

echo create ssh_entries table
iptables -N ssh_entries
# allow entries from your.com to log in via ssh, log all such connections
iptables -A ssh_entries -p tcp -i eth0 --dport 22 -s your.com -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level info --log-prefix "ssh_in: "
iptables -A ssh_entries -p tcp -i eth0 --dport 22 -s your.com -j ACCEPT
iptables -A ssh_entries -j DROP
# -----------
# send all ssh requests coming in to ssh_entries table
iptables -A INPUT -p all -i eth0 --dport 22 -j ssh_entries

---

Maybe a VPN isn't such a bad idea ...

The idea about CRON inst bad but instead updating \Hosts thru CRON (that will be ineffective since iptables already resolved at rule load and it wont re-read hosts and/or DNS), you can use use a small script (thru CRON), deleting and reinserting that specific "allow" rule.

I think trying set your kernel to do name resolution on every packet it gets would probably be a bad idea (Dont cross the streams :)). However, I also think you could easily use patch-o-matic to add the string matching module into netfilter and set up a rule that only allows the packets in if the hostname match is in the packet. Of course this could be spoofed but hey, nothings perfect :) I think it will still add a beneficial layer to at least keep the casual scanner at bay.

-Maest0

I think cacosapo has hit the nail right on the head! Kudos!

First, some background on my understanding thus far: I was under the impression that iptables would ( from prior searching and readings ) look up the host-name each time the rule was called. This apparently is not correct ( found through testing because of this post. I think this may also answer Maestr0’s post. But even if it was so, using the new chain as I did you could mitigate most of the problems. ) What I found was that when the ruleset is loaded it does the DNS lookup, and holds that IP address until the rule is loaded again. ( *2 note quirk below )

God I love this site: posts like this make me learn!

Anyway, if that is the case, then to get the new IP address if it changed you would have to reload iptables ( bad idea, could slow things, jam things, or even open holes momentarily every time the entire ruleset reloaded ) or you could just reload that rule as cacosapo said.

So, for the example given ( notice I removed the logging for your.com )

Quote:

---

echo create ssh_entries table
iptables -N ssh_entries
# allow entries from your.com to log in via ssh
iptables -A ssh_entries -p tcp -i eth0 --dport 22 -s your.com -j ACCEPT
iptables -A ssh_entries -j LOG --log-level info --log-prefix "ssh_in_drop: "
iptables -A ssh_entries -j DROP
# -----------
# send all ssh requests coming in to ssh_entries table
iptables -A INPUT -p all -i eth0 --dport 22 -j ssh_entries

---

in a CRON job, just replace the chain rule where you call your.com: in doing so it should reread the DNS and replace as necessary.
So, in the above example, the rule to change the rule would be

Quote:

---

iptables -R ssh_entries 1 -p tcp -o eth0 –dport 22 -d your.com -j ACCEPT

---

In above, the “ -R” tells iptables to replace a rule, “ ssh_entries” says what chain the rule is in, “ 1 “ is the rule number in the chain, the rest is the rule to replace the old.

to get the rule number once the chain is loaded the first time, use
“ iptables –list –line-numbers -v “

If you need special treatment for the lookup ( I do not know how no-ip.com works ) you could still include that lookup in the CRON job, placing it in your /etc/hosts file.


One other note here, and someone may run into this so be mindful. The reason I used the /etc/hosts file initially, not only because of using no-ip.com, but also because, thinking that it would look up the host name each time the rule was called I thought it easier because you would not have to worry about placement of the rule in the table.
If you place a host name in a ruleset which requires a DNS lookup before the rule which allows DNS look-ups, the rule will fail and will not be loaded!

Hope this has helped, it helped me.

*1 Note here, if the host name resolves to multiple addresses the " -R " command will fail ( from the iptables man pages, and yes, I tried it )


*2 quirk: ( this worked for me )
run a ruleset with a destination host name, then do
“ iptables –list -v “
you will see the host name in the ruleset. Now run
“ iptables –list -n -v “
Since the “ -n “ tells iptables not to display host names, but use the IP address, you will see the IP address of the host name in the rule.
Now, again try
“ iptables –list -v “
no “ -n” but the IP address is still there!

I would handle this differently.

I would allow all port 22 but only allow key authorisation, not password authorisation.

Make these changes to sshd_config on the server:

Ensure you are only using protocol 2

Code:

---

#Port 22
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

---

Prevent root login

Code:

---

#LoginGraceTime 600
PermitRootLogin no
#StrictModes yes

---

Disable password logon:

Code:

---

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

---

Next you need to generate a keypair on each client machine as the normal user.

Code:

---

ssh-keygen -t dsa

---

And press enter a couple of times to use the default files.

On the client machine make sure id_dsa is chmod 600 and take a copy of id_dsa to the server

On the server login as the user you wish to be when connected via ssh and:

Code:

---

cat id_dsa.pub >> ~/.ssh/authorized_keys

---

Only those in posession of the relevant id_dsa keys wil be allowed to connect and no attempt can be made to brute force passwords since they are disallowed.

HTH
Steve

Quote:

---

I would allow all port 22 but only allow key authorisation, not password authorisation.

---

Yes, no, yes ... I don’t think we got there yet .... this is just another layer.

If someone finds a flaw in SSH to exploit, they have to get by the firewall. Hopefully they will not find ( with a default drop on port 22 ) that any connections are possible there, so they won’t know to try, and if they do they won’t be allowed in ( again, hopefully, unless they find a flaw in Netfilter too. )

Just trying to stack the odds in our favor, but it is still just a gamble!