NTP exposed to WAN by default

A Former User

I noticed that the NTP service responds on WAN even when no interface is explicitly selected. This isn’t visible in the firewall rules, which made it easy to miss until I did an external scan.

I know this is mentioned under the interfaces field, but the current behavior feels counterintuitive from a “default deny / explicit allow” perspective.

NTP is a service that most users likely do not intend to expose publicly, and it is known to be usable in amplification attacks. Because of this, having it implicitly reachable on WAN without an explicit rule or clear indication can lead to unintended exposure.

Since localhost is always available and sufficient for the system itself, it seems like a safer default without making assumptions about LAN setups. If users want to provide NTP to LAN or WAN, they can explicitly enable it.

Would it make sense to default to localhost only or provide a clearer warning when the service is reachable on WAN?

patient0

@Mathijs said in NTP exposed to WAN by default:

I noticed that the NTP service responds on WAN

That seems unlikely since everything is blocked in on WAN per default. Or it would be a bug.

What pfSense version are you running and how is NTP configured? Any rules on WAN or floating that allow port 123/udp? And how are you testing it?

johnpoz

@Mathijs with @patient0 here, out of the box no unsolicited inbound into your wan would be allowed. If your saying ntp is reachable via public IP from the internet, you have a rule that allows that. Or something in between is answering.

Even if you had the ntp service in pfsense to listen on wan interface, or all of them - without a firewall rule it would not respond to traffic hitting the wan from the internet.. I would work if testing your public IP from say a lan side client behind pfsense. But not from the wan.. By default all unsolicited inbound traffic into the wan interface is blocked.

How exactly are you testing from outside your network - udp is difficult to check.

You could use something like this to see if ntp responds

https://network-tools.webwiz.net/ntp-server-test.htm

I just tested my IP and fails.. And can see from a packet capture.. You see the query come into my wan, but no response.

That test site is just first one that came up in search for testing ntp.. It fails on my wan IP, but works for other ntp servers I put in there to test.

stephenw10

Yup that.

ntpd does listen on every IP address on the firewall by default but isn't accessible from a WAN side client because the default firewall rule block that.

If you do choose to set a limited set of interfaces for it run on be aware that selection also governs the source IPs used for upstream ntp queries. So if you don't have appropriate NAT rules that can end up preventing it sync.

SteveITS

I’ll add if one tests from LAN the allow to any rule will allow the connection to WAN IP.

A Former User

Initially I did get a confirmed open state on UDP 123 (not open|filtered), which indicates an actual response. That’s what triggered my investigation.

I didn’t attempt further communication at that point. Because the configuration states “Selecting no interfaces will listen on all interfaces with a wildcard”, I assumed this behavior was intentional, which is what I found confusing and led me to make the post.

After reviewing the configuration and selecting localhost and lan interfaces only for NTP, the port no longer responds externally.

So something was answering at that time, even though I agree that by design the WAN should block unsolicited inbound traffic. I have no rule anywhere that should have allowed this as far as I know. I have just been staring at it again.

So now i’m mainly trying to understand under what conditions that could happen, and whether the current default behavior could lead to similar situations or confusion.
I still think that if no interface is selected, defaulting to localhost-only would be a safer and more predictable behavior.

johnpoz

@Mathijs said in NTP exposed to WAN by default:

defaulting to localhost-only would be a safer and more predictable behavior.

Kind of hard to be a ntp server for you network, when your not listening on an interface your network can talk too.

Testing UDP with something like nmap is almost never valid testing

Initially I did get a confirmed open state on UDP 123 (not open|filtered), which indicates an actual response.

how do you read "not open, filtered" as sending a response?

example - I scanned a random port 6666, I sure an the hell do not have anything listening on that port, and I sure didn't send a reject or anything


PORT     STATE         SERVICE
6666/udp open|filtered ircu

Here I just did a packet capture while I sent that traffic from nmap.. You see it gets there, and no response.

I was sending traffic from a vps I have out on the internet.

https://nmap.org/book/man-port-scanning-basics.html

open|filtered

Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

If you want to know if ntp is open on your wan - use a valid ntp test.. Say for example the link I provided before.

stephenw10

@johnpoz said in NTP exposed to WAN by default:

defaulting to localhost-only would be a safer and more predictable behavior.
Kind of hard to be a ntp server for you network, when your not listening on an interface your network can talk too.

I assume OP means default to localhost to force the user to then select the interfaces they want. Which could work but would probably be a POLA violation at this point. Tough to make that change after years of the current defaults.

johnpoz

@stephenw10 haha - yeah that makes more sense.. But could tell you for sure would get a lot of posts about why does ntp not work ;)

If going to change that, there are prob a bunch of stuff that could get changed.. The default of /32 when add an interface. We get plenty of posts about why dhcp not working because the user left it on the default /32.

Lets get rid of the default allow rules when you enable dhcp server as well ;) If our goal is more forum post asking why stuff doesn't work ;)

Gertjan

NTP is listening ?

In this thread, no one mentions that the pfSense GUI (web server !) listens, by default, on all active interfaces.
This includes so called WAN interfaces.
There is no (GUI) option to limit this.

@patient0 run this on your pfSense :

[26.03-RELEASE][root@pfSense.bhf.tld]/root: sockstat -lv | grep 'nginx'
.....
root    nginx      68142  5 tcp4    *:443                 *:*
root    nginx      68142  6 tcp6    *:443                 *:*
root    nginx      68142  8 tcp4    *:80                  *:*
root    nginx      68142 10 tcp6    *:80                  *:*
root    nginx      68068  5 tcp4    *:443                 *:*
root    nginx      68068  6 tcp6    *:443                 *:*
root    nginx      68068  8 tcp4    *:80                  *:*
root    nginx      68068 10 tcp6    *:80                  *:*
root    nginx      67805  5 tcp4    *:443                 *:*
root    nginx      67805  6 tcp6    *:443                 *:*
root    nginx      67805  8 tcp4    *:80                  *:*
root    nginx      67805 10 tcp6    *:80                  *:*

If you know who nginx is this tells me it's listening on all interfaces, using TCP 80 and 443.

So the only thing that stops someone from coming in on the WAN (this might be the entire planet) and connecting to the pfSense GUI, is the firewall rule present on that interface : a hidden block all rule.
Thus an empty WAN firewall rule list is .... as it is set by default by Netgate, perfect.

( edit : and making the GUI safer by having it listening only on localhost would be a massive show stopper ^^ - have it listening only on the assigned LAN interface .... what's against doing this ? )

johnpoz

@Gertjan Yeah from a security standpoint, services should really only listen on the interfaces they are required on.

But with all security its a compromise between security and ease of use.

If we were voting, I don't have a problem with out of the box services listening on all interfaces.. But like with ntp or dns you should be able able to control that after setup. Not sure why they don't provide that option with the web gui.. Maybe a safety net of always having to listen on say the interface (lan) that anti-lock out is applied sort of thing would be a good compromise for helping the user from shooting themselves in the foot sort of thing. Same should go with ssh access.

dennypage

@Gertjan said in NTP exposed to WAN by default:

In this thread, no one mentions that the pfSense GUI (web server !) listens, by default, on all active interfaces.
This includes so called WAN interfaces.
There is no (GUI) option to limit this.

It is not uncommon for a server to use a single socket and listen on all interfaces. Some servers don't even have the option to create individual sockets for interfaces. Chrony (modern replacement for ntpd) is one such example.

tinfoilmatt

Chrony (modern replacement for ntpd) is one such example.

What?! So you're basically left with the system's sledgeh—I mean software firewall (like here).

Is there a legitimate development reason for this? Complexity avoidance?

johnpoz

@dennypage said in NTP exposed to WAN by default:

Some servers don't even have the option to create individual sockets for interfaces. Chrony (modern replacement for ntpd) is one such example.

Chrony can be bound to an address, it seems to have a limit of 1, so yeah you can not listen on multiple without listening on all..

https://chrony-project.org/doc/3.4/chrony.conf.html#bindaddress

But you can bind it to a specific address.

dennypage

@tinfoilmatt said in NTP exposed to WAN by default:

Is there a legitimate development reason for this? Complexity avoidance?

Yes. As @johnpoz noted, it's a trade off between ease, complexity and security. Usually, there are other mechanisms for limiting access. In Chrony's case, there is the allow directive, which allows you specify the addresses (IP/masks) that Chrony will accept packets from.

In general, unless something is running in a special environment such as a docker container, specifying the listen by interface usually isn't necessary.

johnpoz

@dennypage said in NTP exposed to WAN by default:

specifying the listen by interface usually isn't necessary.

While I do agree here, I also think the ability to limit (when possible by the application/service) is a worth while security option to have. Should it be the number one priority - no prob not. And since pfsense is a firewall, you do have complete control of who can talk to what service that might be running no matter what the service does for binding to IPs the device might have.

I mean quite often many services would be on device with only 1 interface anyway ;) So the ability to call out what specific interface/ip a service is bound to really becomes moot. And it just makes it easier to setup to know that hey that service will listen to whatever IP the device has.

Back to the topic at hand, while ntp does out of the box listen on all IPs. Out of the box this would not be available via the wan no matter what IPs the service is actually listening on. Seems the OP clearly was not using valid testing methods (nmap to a udp port) - where nmap in layman terms reports I can't tell there was no answer.

What I don't get is how you could interpret

(not open|filtered)

To you got a ntp response. Or any response at all.

Nor did they follow up with validation of what they thought they were seeing before jumping to the conclusion that somehow pfsense left this service open to the wan even with default deny on all interfaces out of the box.. The only sort of exception to this is while the lan also has default deny, out of the box a any any rule is created to ease setup.