pfBlockerNG blocking Insteon Hub - advice requested

bmeeks

I'm 100% with @johnpoz about trying to edit what NTP servers the device uses. That just seems sketchy on the surface with those domain names.

johnpoz

But if the device is set to use said pool, you have no idea where those might go - anyone that is in those pools.. All might be trying to do good things - and then their site gets compromised on the same IP, and there you go blacklist and IP ends up in block list, etc. etc.

This part of the reason vendors are suppose to setup their own pool to use on their devices..

I am a member of the pool, and host both ipv4 and ipv6 stratum 1 server to it.. For the good of the community, etc.. But if my ip got listed on some black list - then sure it would show up as bad when users trying and hit me.. But I register a valid name in the pool ntp.domain.tld, etc...

Those are all the PTR for those IPs - the couple I checked..

;; QUESTION SECTION:
;222.85.209.185.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
222.85.209.185.in-addr.arpa. 3600 IN    PTR     b9d1-55de.led01.ru.misaka.io.

;; QUESTION SECTION:
;198.253.46.78.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
198.253.46.78.in-addr.arpa. 86400 IN    PTR     maggo.info.

If you were going to do it correctly then you should edit the ptr of your IPs to be ntp related ;) But if the IPs are some home connection they might not have control, and or they might host different things on the same IP and the PTR is for those other forward things, etc.

bmeeks

Yeah, you're correct. But when I see domain names with "tor" and ".ru" in them my spidy sense fires off ... even if it's supposed to just be NTP traffic.

johnpoz

see my edit about the PTR..

bmeeks

@johnpoz said in pfBlockerNG blocking Insteon Hub - advice requested:

see my edit about the PTR..

Noted. I would be in that boat if I hosted a pool server since I'm on a cable ISP where I have no control over what my PTR record says.

bmeeks

It would be easy for the OP to do a quick capture and validate the type of traffic. If it is just NTP sync packets on UDP port 123, then you could make a firewall rule to allow that out or punch a pinhole in pfBlockerNG's list to allow it.

johnpoz

Exactly - for example my IPv4 ptr is the cable company provide PTR

ipaddress.nap.wideopenwest.com.

But for the IPv6 I control the PTR to the forward ntpv6.domain.tld etc..

but atleast ipaddress.ispname.tld is less bad looking than tor-relais2.link38.eu ;)

edit: Yup simple sniff will tell if just ntp - which is prob working, its just the dns queries for the ptr being blocked? Not sure why something is doing a ptr for the IPs though? Or maybe that is what his ips is reporting?

He should check if his hub can set ntp servers - and then prob just set it to his pfsense local side IP which can provide ntp to all clients. Or even do just a redirect for all ntp traffic to end up on pfsense..

bmeeks

So to the OP -- after some further investigations by @johnpoz it's possible this is just simple and harmless NTP sync traffic which your Insteon device is using to keep accurate time. But I would still suggest verifying that with a quick packet capture and then maybe adjusting your pfBlockerNG setup so that you can allow but police NTP traffic out of your IoT network.

Still would be a good idea to isolate IoT stuff on its own network behind your firewall.

johnpoz

This is yet another example of why you can not just turn on IPS and think its clicky clicky all done.. Running IPS takes work and diligence and maintenance... Or you quite often are going to do more harm then good ;)

And using block lists for dns as well there is going to be some pain, where something "you" or your clients need or want is blocked when it shouldn't be for something you want to do to work as intended..

There is a skillset that is required to do this sort of stuff - and part of the problem with pfsense is makes these sorts of tools available to people who think clickly clicky = all safe ;) The issue discovered with pfblocker for example with the any rule on wan is prime example of how a great tool in the wrong hands can be issue!!!

khorton

@bmeeks said in pfBlockerNG blocking Insteon Hub - advice requested:

So to the OP -- after some further investigations by @johnpoz it's possible this is just simple and harmless NTP sync traffic which your Insteon device is using to keep accurate time. But I would still suggest verifying that with a quick packet capture and then maybe adjusting your pfBlockerNG setup so that you can allow but police NTP traffic out of your IoT network.

Still would be a good idea to isolate IoT stuff on its own network behind your firewall.
I'll have a go at capturing some of the outbound stuff from the Insteon Hub and get back. It'll likely be a day or two, as I've got a couple of major issues burning at work.

I'll do some learning on how to set the hub up on its own network.

Thanks for the advice @bmeeks and @johnpoz

khorton

I captured many hours of traffic on port 123 from this device. As you would hope, it all is NTP traffic, if I can believe Wireshark. Some of the traffic was to one of the IPs on the block list I had selected in pfBlockerNG (185.209.85.222:123 b9d1-55de.led01.ru.misaka.io).

I'll keep capturing traffic, as I'd like to see something to 188.68.53.92:123 tor-relais2.link38.eu before I declare this as a false alarm.

I was surprised to see that this device hits NTP every 10 minutes, which is much more frequent than I would have predicted.

I'll also look into putting the device on its own VLAN, after I get back from my trip that starts tonight. I'll start a new thread in the appropriate forum if I have any questions about that.

johnpoz

@khorton said in pfBlockerNG blocking Insteon Hub - advice requested:

I was surprised to see that this device hits NTP every 10 minutes, which is much more frequent than I would have predicted.

normal ntp client will ramp its poll time either up or down depending.. Normal ntp poll times will be between 64 and 1024 seconds.. Poll of 512 seconds would be 8.5 something minutes.

So it could be that, or maybe the client is just using ntpdate with a defined time of 10 minutes.

Did you look to see if you could actually set the ntp on the device? Another option would be to look to what ntp.pool fqdn its actually using, and then setup host overrides for those if its cycling through say 0.ntp.pool and 1.ntp.pool etc.. so that they all point the IP of the ntp server you want it to use..

I have devices that poll time.nist.com and ios-time.apple.com - I just have some host overrides to point those to my local ntp server.

This will accomplish couple of things - it will make sure all your devices on your network are using the same ntp as source.. Also will remove external ntp queries and keep your logs clear of stuff like your seeing that get you all worked up ;)

example here is my windows box current poll time

$ ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.local.lan   .PPS.            1 u  103  128  377    0.694   -0.230   0.589
ntpq>

So every 128 seconds he does a query to my local ntp server.

JeGr

As those PTRs are simply Domains for NTP Pool addresses, perhaps change the pool to a regional one (better for less delay and jitter anyway) so we switch ntps to e.g. 1 & 2 of X.de.pool.ntp.org
Yes you don't have that many IPs in the regional pools than if you include the big ones but normally you have enough. Also if you use IPV6 make sure you have a pool that includes v6 members, too. :)

johnpoz

Yeah we are not sure he can change the fqdn his client can use - but I agree if your going to use the pool for your source its best to call out a regional fqdn..

JeGr

Well, as last resort, one could catch udp/123 and redirect it to localhost like DNS ;)

NogBadTheBad

I've occasionally seen TOR exit points pop up in Snort when using the following ntp pools:-

0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
3.pool.ntp.org

johnpoz

Yeah you could do that too..

To be honest this is yet another example of filtering be it via dns, or ips that can cause user grief and pain when they do not understand the full implications of doing this.

Implementation of increased levels of security will always come with a price.. You have to be willing to pay that price - especially when the things blocked are outside of your control as well.. And you pull in lists that are maintained by others.

Signature and or lists are going to have mistakes, they are going to have false positives, etc.

In the example of this - it seems from me looking that atleast 1 of those names is gotten its way on to block list due to malware.. Be it on purpose by the site owner, or his site got compromised.

That maggo.info site is listed as serving up malware by

Avira Malware ADMINUSLabs

So while the website might be serving up malware - doesn't mean the ntp server has been compromised that is running on the same IP, etc.

The use of such security is always going to cause false positive.. The admins job when they decide to run such tools is to manage the lists and remove the false positives from filtering, or make the decision that what the thing is blocked for is a requirement on this network.. For example you might be blocking a known AD server, but when you do so channel xyz doesn't function on your streaming box.. So you need to decide do you want the channel to work, or do you want to block said ad server, etc.. ;)

johnpoz

@NogBadTheBad

Yeah I can promise you for sure that people that run tor exit sites might also be members of the ntp pool.. NTP doesn't limit who can join - your IP just needs to provide stable time.. Which is checked and if your score drops below 10 then your IP is removed from the pool until its score goes above 10, etc..