# Firewall - designating source by hostname = bad?

## libertytrek

The man page of iptables says this about the -s (and -d) flags:

"-s, --source [!] address[/mask]

Source specification.  Address can be either a network name, a hostname (please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea),"

What about a situation where the source or destination uses a hostname as a font end to multiple IP addresses that might change?

Real world example...

To be able to limit outbound ntp requests to only the desired server pool, instead of this:

-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT

Why would it be bad to use this (or would it even work?):

-A OUTPUT -p udp -m udp -d us.pool.ntp.org --dport 123 -j ACCEPT

This way, if the IP addresses change, the rule still works...

----------

## think4urs11

Obviousely it is bad because you 'outsource' your security partly.

Means anybody who can change DNS can possibly tunnel your firewall easily without even touching it.

In your setup i'd just need to add an additional IP to us.pool.ntp.org (or to be precise i'd just need to convince your firewall that i've done so, you may want to read about dns spoofing) and i'm able to tunnel everything through your firewall on port 123/udp. Now combine that with e.g. a OpenVPN server running on this new 'ntp'-host...

----------

## libertytrek

 *Think4UrS11 wrote:*   

> Obviousely it is bad because you 'outsource' your security partly.

 

Ok, I really want to understand this, but that doesn't make sense to me...

Like I said, currently, I must allow ALL in order for ntpclient to be able to work...

I don't see how allowing only a few IP addresses based on hostname is less secure than allowing ALL?

Obviously, I can (and probably will) just limit this by IP address, and I certainly do see how that is safer than doing so by hostname...

 *Quote:*   

> Means anybody who can change DNS can possibly tunnel your firewall easily without even touching it.

 

Maybe  this is due to my ignorance, but again, I don't see how limiting by hostname is worse than no limit at all...

 *Quote:*   

> In your setup i'd just need to add an additional IP to us.pool.ntp.org (or to be precise i'd just need to convince your firewall that i've done so, you may want to read about dns spoofing) and i'm able to tunnel everything through your firewall on port 123/udp. Now combine that with e.g. a OpenVPN server running on this new 'ntp'-host...

 

I guess I'm missing something obvious... hopefully your answers to the above questions will enlighten me...

----------

## think4urs11

 *libertytrek wrote:*   

> I guess I'm missing something obvious... hopefully your answers to the above questions will enlighten me...

 

You're right, compared to ALL the restriction on hostname is better, but it also gives you a false sense of security.

You limit on some dns name and think you're secure - so far so good, at least it is better as before - correct? No.

Some time later someone _outside_ of your network changes DNS and by that you have again holes in your (from your point of view secure) firewall without you even beeing aware about it - and thats what makes it problematic.

Better have the config done on ip address level. When you do it that way it doesn't matter if someone changes DNS; worst what can happen is that your clients no longer get their time from the ntp servers configured.

When you configure the rules by dns name the person who has access to the DNS server can change where your clients can connect to, when you configure on ip address level you and only you can change where your clients can connect to, thats the difference.

----------

## libertytrek

 *Think4UrS11 wrote:*   

>  *libertytrek wrote:*   I guess I'm missing something obvious... hopefully your answers to the above questions will enlighten me... 
> 
> You're right, compared to ALL the restriction on hostname is better, but it also gives you a false sense of security.

 

Heh... not sure how to 'apply' that answer... its better - but its not better?

I guess my follow-up is, from what you've said, given a situation where you don't know the IP addresses, or they might change without notice, filtering based on hostname is better than just allowing ALL, correct?

Also, as for my specific example, apparently there are a lot of IP addresses (20 total) for us.pool.ntp.org (I just nslook'd them up) - should I filter/allow them all? What do you (or others here) do?

As to a 'false sense of security', that ass-u-me-s that I would believe my system to be 'secure', when in fact, I would know otherwise. I'm not stupid. Any computer that is powered up is at risk. That risk increases by a few orders of magnitutude when you plug it into a network, and by a few more orders when you plug that network into the internet.

 *Quote:*   

> Better have the config done on ip address level. When you do it that way it doesn't matter if someone changes DNS; worst what can happen is that your clients no longer get their time from the ntp servers configured. When you configure the rules by dns name the person who has access to the DNS server can change where your clients can connect to, when you configure on ip address level you and only you can change where your clients can connect to, thats the difference.

 

Fair enough... ok, so you've definitely convinced me that filtering by IP is more secure...  :Smile: 

Now, do you have any pointers on where to go to learn about each type of service, and how to best protect each from being exploited, and to minimize the potential damage?

How do others here lock down services like these? public web server, corporate mail server that requires outside access, ntp-client on said server, etc...

----------

## depontius

It strikes me that an interesting addendum would be to keep a table of hostname/IP mappings that you want to use in your firewall rules, and verify them periodically.  None of these mappings should change normally, though occasional changes due to server administration on one family of destinations could be considered normal.  Simultaneous changes on many destination families could be considered a sign of a DNS MITM attack.

For that matter, why confine the saved table to just firewall rules - I'd consider having a table of frequently-visited sites, especially considering sites where you perform financial transactions.  Periodic confirmation of hostname/IP mappings wouldn't be a bad idea, though there needs to be some way to recognize/accept ordinary administrative actions.

----------

## think4urs11

 *libertytrek wrote:*   

> Heh... not sure how to 'apply' that answer... its better - but its not better?

 

well, any kind of restriction is better than no restriction at all, isn't it? And 'the good' is always 'the enemy' of 'the even better', correct? Of course there's never 100% security, the task is to make it as hard as possible to attackers to break something.

 *libertytrek wrote:*   

> I guess my follow-up is, from what you've said, given a situation where you don't know the IP addresses, or they might change without notice, filtering based on hostname is better than just allowing ALL, correct?

 

correct

 *libertytrek wrote:*   

> Fair enough... ok, so you've definitely convinced me that filtering by IP is more secure... 

 

Good, so task acomplished  :Smile: 

 *libertytrek wrote:*   

> Also, as for my specific example, apparently there are a lot of IP addresses (20 total) for us.pool.ntp.org (I just nslook'd them up) - should I filter/allow them all? What do you (or others here) do?

 

We have e.g. three NTP servers in DMZs across EMEA each fetching NTP time from three different sources (restricted on IP level) in the internet (Stratum 1) and one internal Stratum-1 source (GPS signal iirc). All three of them are Stratum-2 for our internal servers and those additionally peer with each other. And finally e.g. our Windows AD-Controllers are Stratum-3 to the clients.

 *libertytrek wrote:*   

> Now, do you have any pointers on where to go to learn about each type of service, and how to best protect each from being exploited, and to minimize the potential damage?
> 
> How do others here lock down services like these? public web server, corporate mail server that requires outside access, ntp-client on said server, etc...

 

Just the usual ones

- keep your stuff up2date

- document everything (also on paper just in case - a docu on a fileserver isn't useful when this server crashes, you get the idea)

- read about good practices, secure setup (normally each app has some sort of docs for that; in worst case 'appname'+howto+security on google isn't a bad idea)

- harden your setup on all levels (firewall, kernel hardening, no modules, no test users, encryption wherever possible, no easy passwords, system access only to as few persons as possible, ....)

- allow only the very minimum of in/outbound traffic (whitelist approach, means allow only whats needed instead of blacklisting whats unwanted)

----------

## Genone

There are also non-security reasons for not using hostnames in iptables rules:

- performance. Worst case: you get a DNS lookup each time a given rule is processed

- deadlocks. If you use a hostname in a rule that is triggered by DNS lookups ... I guess you get the picture.

----------

## libertytrek

 *Genone wrote:*   

> There are also non-security reasons for not using hostnames in iptables rules:
> 
> - performance. Worst case: you get a DNS lookup each time a given rule is processed
> 
> - deadlocks. If you use a hostname in a rule that is triggered by DNS lookups ... I guess you get the picture.

 

<smacks head>

I actually thought of the performance-hit aspect at one time when thinking about this in the weeks/months prior to posting the question, but forgot...

These are probably the best reasons of all, especially on a busy server... thanks...

----------

## libertytrek

 *Think4UrS11 wrote:*   

>  *libertytrek wrote:*   Now, do you have any pointers on where to go to learn about each type of service, and how to best protect each from being exploited, and to minimize the potential damage?
> 
> How do others here lock down services like these? public web server, corporate mail server that requires outside access, ntp-client on said server, etc... 
> 
> Just the usual ones
> ...

 

Well, the only one I haven't pursued yet is the hardened kernel and one of the Access Control based security models... one day, maybe...

Thanks again for the replies...

----------

