...

IPTABLES doesn't filter based on hostname.

Just ignore me, I haven't had breakfast yet.

j

Ryan wrote:

On Saturday 08 July 2006 10:06 am, Jason Bradley Nance wrote:

...

...

iptables -A FORWARD -d chatenabled.mail.google.com -j DROP

IPTABLES doesn't filter based on hostname. You would need some special module (assuming it exists) and it for sure isn't part of RHEL/CentOS.

Are you sure about this?

I have had no problem creating rules by hostname, although I've only used the front ends shorewall and firestarter on CentOS.

Yea it does work. What would really be handy though would be if iptables would resolve the hostnames internally and adhere to the TTL records. Then it would lookup the address again when the TTL expires. This would allow you to set a hostname and know that it would eventually get updated when the DNS record changes. Currently you have to re-run the iptables rules any time the DNS changes. DNS can be spoofed and taken over in other ways so this would not be for everyone but for some uses it would come in very handy.

William L. Maltby wrote:

If we can presume that the man page for iptables is correct that it can filter using hostname, we can also presume that it must have some method for doing a DNS-like resolution process. Since dig of "chatenabled..." shows it exists and is resolvable, is your iptables set up to use your resolution facility? If early in the boot procedure, maybe resolution is not yet available?

Iptables do not filter based on host names. The name gets resolved to the IP adress, and the rule is inserted using that IP address (as the output of iptables -L shows you). If IP address changes, the rule doesn't get automagically updated.

DNS lookup can return more than one address. Do you know what iptables will do in that case?

DNS lookup can also return a different address depending on which ISP you are using. For example, chatenabled.mail.google.com from the example can also resolv to 216.239.63.189 (queried from my hotel's network in California) or 66.102.11.189 (queried from host located in Croatia). If I were to query it from my home in Winnipeg, I'd probably get yet another IP address.

Another example, try resolving www.google.com and you'll most likely get several IP addresses returned. Who knows, maybe resolving Google's chatenabled will also start returning multiple RR A records one day in the future.

Check /etc/nsswitch.conf and /etc/resolv.conf. See if configuration inthere is correct. Note that utilities such as dig or nslookup use only resolv.conf file.

During the boot, iptables script runs before network script. Or at least should run before network script. Therefore, you can't resolve names using DNS during boot (you can only use names that are in /etc/hosts).

Check if firewall rules actually allow you to perform DNS query. Maybe your iptables rules are blocking themself.

Said all this, as manual page says, using host names with iptables is really bad idea. You never know what you are going to get. And you always run a risk of somebody breaking into your network by spoofing DNS replies (or playing with your trust in DNS in some other way).

I had something like this come up a while back for dynamic hosts accessing a specific service. What I did, generally speaking, is set up an input rule to redirect all incoming requests for that service to a new chain, then dynamically rebuild the chain periodically to "refresh" the IP addresses via a cron job.

The initial setup would be something along the lines of this, substituting the service you want to control for 'fubar':

iptables --new-chain fubar-chain iptables --append fubar-chain --jump DROP iptables --insert RH-Firewall-1-INPUT --in-interface ! lo \ --protocol tcp --dport fubar --jump fubar-chain

This sets up the initial state so that any requests for service fubar get dropped. You could add the following to /etc/sysconfig/iptables (just before the line saying "COMMIT") to accomplish the same thing when iptables gets started:

--BEGIN :fubar-chain - [0:0] -A fubar-chain -j DROP -I RH-Firewall-1-INPUT -i ! lo -p tcp --dport fubar -j fubar-chain --END

Now you need to flush the chain and put the correct rules in to allow them to work, using a shell script something like this to make it go:

--BEGIN #!/bin/bash iptables --flush fubar-chain iptables --append fubar-chain --jump DROP for ipaddr in $( host chatenabled.google.com | \ awk '( / has address / ) { print $NF }' ) do iptables --insert fubar-chain --source ${ipaddr} \ --protocol tcp --dport fubar --jump ACCEPT done --END

There might be some disruption of service while this is running, so a little tweaking might be necessary to NOT remove the rules unless the DNS translation has actually changed. Set this script up to run as a cron job with whatever frequency makes sense.

This is pretty generic and will have to be adapted to your specific needs, altering the service names and protocols as appropriate. Since this was basically from memory, make DARNED sure you make backup copies of any files you modify before trying this out!

Your mileage may vary!

Quoting Ryan ryanag@zoominternet.net:

On Saturday 08 July 2006 1:25 pm, Aleksandar Milivojevic wrote:

...

Said all this, as manual page says, using host names with iptables is really bad idea. You never know what you are going to get.

The same is true of IP addresses. Blocking an IP address can block many domain names since hosting providers sometimes do name-based hosting.

You are still going to end up blocking the IP address. The (user space) iptables command will resolve the host name to IP address. You'll end up with exactly the same rule no matter if you used host name directly or IP address. The only difference is, in later case you know exactly what the rule is going to be. When configuring firewall, you do want to be exact.