Best practice rules/setup for icmp and NTP?
-
@V3lcr0:
In the spirit of understanding port forward, rules and best practices….are these just 2 ways to accomplish the same thing? Port forward or interface rules? Not trying to stir a pot but simply trying to understand why one way might be better then the other.
Your current rule setup simply blocks attempts to use an outside NTP server. Which is fine if you can configure an NTP address on all devices, or if you don't care if some devices can't sync the time via NTP because they try to reach a fixed server on the Internet.
By using a port forward all NTP traffic will be redirected at pfSense. So every device will be able to sync the time, no matter what outside server it actually tries to reach.
-
Why would you port forward between network that are not natting? Lan segment do not nat between them.. So why would you port forward?
A port forward would be required when you had multiple clients sharing the same IP via a NAPT (network address port translation).. Like what you have between typical wan and lan setup in pfsense.
Still don't get your first rule? Your allowing dns to only what is in that alias - google_opendns? But call it access to unbound? And state no wan leak??
Then your other rule where you block access to firewall is going to block way more than just dns.. It would block all access to any port on on any IP on the firewall… So webgui, sure dns.. but would also block say proxy access or pinging
You do understand that letting a client talk to google or open would be a dns wan leak ;) Google or open would see the query coming for your wan IP.. So your note on that real makes no sense to me at all.
-
Thank you both…
From what I get from this is:
- A port forward would work in the absence of VLAN on this interface (This rule would apply to all devices on a non-VLAN Interface)
- With VLANs a rule in the interface is a better approach for VLANs
I also updated my "allow" rules with a "!RFC1918" as the destination...I assume this would segregate/harden my VLANs further from each other each other?
Regarding my first rule, fair challenge regarding my note "Allow DNS access to Unbound(NO_WAN_LEAK)", I replaced the note with "By pass Unbound and allow access to OpenDNS/Google(NO_WAN_LEAK)".
Regarding the "NO_WAN_LEAK" I am doing what I understand to be "Policy Filtering", specifically I have "NO_WAN_LEAK" text in the interface "Tag" field of this rules, and a corresponding floating rule(Interface=WAN, Direction=OUT, Tagged="NO_WAN_LEAK"). This is my effort to push everything thru the VPN...
I have "Don't pull routes" checked on my VPN clients and my "Outgoing Network Interfaces" in Unbound only has my VPN selected(No WAN).
Thoughts?
-
Update…
I tried both port forward and an interface rule and I still get blocks on port 123! Using an interface rule my Firewall log showed Source= Apple TV to Destination = 17.253.24.253:123 (Blocked)
When I tried the port forward I recieved a block: Source= Apple TV to Destination = 127.0.0.1 (Blocked)
-
The logic was some geographic diversity with switzerland…
You don't want geographic diversity with NTP. You want lowest possible response time with the lowest jitter. That almost always means using a source that is geographically closest to you from a network standpoint.
-
"I tried both port forward"
What? There is NO scenario when you would use a port forward out your wan from your lan side.. .You mean you tried to redirect it to a local instance of ntp running on pfsense?
If you have floating rules - lets see them, they are applied before interface rules.
-
I ended up rebuidling my firewall…no floating rules.
I do however still get the following blocks to the following destination:
17.253.24.253:123 (From Apple TV)
239.255.255.250:1900 (From Amazon TV)Both are blocked by my "Block all other rules" on the IOT interface(last block "ALL" rule)...
What the F...is this Apple and Amazon sending my info back? As an FYI both devices are working...I am really struggling with changing my last 2 rules to "ANY" ports if I don't have to.
(Thanks KOM...went local now with my NTP)
-
Without you posting your rules for us to see its pointless for you to post up this info.
That 2nd thing is multicast… So yeah depending on how your rules are it would be blocked.
-
@V3lcr0:
I ended up rebuidling my firewall…no floating rules.
I do however still get the following blocks to the following destination:
17.253.24.253:123 (From Apple TV)
239.255.255.250:1900 (From Amazon TV)Both are blocked by my "Block all other rules" on the IOT interface(last block "ALL" rule)...
What the F...is this Apple and Amazon sending my info back? As an FYI both devices are working...I am really struggling with changing my last 2 rules to "ANY" ports if I don't have to.
(Thanks KOM...went local now with my NTP)
17.253.24.253:123 (From Apple TV). << NTP
239.255.255.250:1900 (From Amazon TV). << SSDPIf you do a host time.apple.com does it come back with 17.253.24.253 ?
I'm in Europe so it's resolving to EU based IP addresses.
mac-pro:~ andy$ host time.apple.com
time.apple.com is an alias for time-osx.g.aaplimg.com.
time-osx.g.aaplimg.com has address 17.253.54.125
time-osx.g.aaplimg.com has address 17.253.52.253
time-osx.g.aaplimg.com has address 17.253.52.125
time-osx.g.aaplimg.com has address 17.253.34.125
time-osx.g.aaplimg.com has address 17.253.34.253
mac-pro:~ andy$If you do a packet capture you'll see the ATV doesn't request NTP via a DHCP option, iPhones & iPads are the same too and you can't set the NTP server, the server can be changed in Mac OS.
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
If you're really paranoid ;) this may be of some help :-
https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense
-
Thanks NogBadTheBad (Love the name!)…
To your point the logs I see are from my Apple devices...Johnpoz had mentioned in previous posts that his light bulbs talk to other NTP servers(despite his efforts to curb this). I figured Apples were likely doing the same...
2 questions:
-
How would I do a "...host time.apple.com does it come back with 17.253.24.253 ?" where do I go for this?
-
I am definitely paranoid! I just had a Phishing page presented to me the other day...I think the issue is still with my DNS configuration, unless there is another way for an attacker to do this. While I am likely to give up "privacy" I am thinking additional "security" might be better route...the thought is to use OpenDNS or another provider.
My current configuration follows this pfSense doc guideline: https://doc.pfsense.org/index.php/Blocking_DNS_queries_to_external_resolvers
Would a port forward as you provided: https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense enhance my DNS security?
Thanks again for any thoughts...
V
-
-
Lets be clear to the term guideline.. That is a doc how to do something - it by no means is an sort endorsement or encouragement of how to setup your network.
You can redirect something that resolves to a name to something else like ntp.. So for example time.apple.com could redirect to internal ntp server via a simple host override where time.apple.com resolves to the internal or pfsense local IP its listening for ntp on.
Letting iot device out for ntp shouldn't be a concern.. My whole issue with those which I did redirect the uk.pool.ntp.org fqdn they were using because its just moronic to use a UK pool for ntp when the device is in the US.. Proper use for iot that want to use the pool, is to register their own pool name for ntp with ntp.org
-
@V3lcr0:
-
How would I do a "…host time.apple.com does it come back with 17.253.24.253 ?" where do I go for this?
-
Would a port forward as you provided: https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense enhance my DNS security?
-
On the pfSense router, connect via ssh or via Diagnostics -> Command Prompt
-
Some devices could be hard coded for google, my Panasonic TV is, if I wanted to force my TV to use my pfSense box this would be the only method.
-
