pfBlockerNG blocking Insteon Hub - advice requested
-
Those domains would certainly give me pause. They look very questionable. It is very common for IoT (Internet of Things) devices to have security issues including backdoors that allow malware installation without your knowledge. The devices, once compromised, then periodically check in with home base to see what the attack target for today is. Compromised IoT devices are connected together into huge botnets that are usually used for DDoS attacks. Those domains may be your device attempting to ask home base (the botnet controller) what today's targets are.
Is this home automation hub exposed to the Internet? In other words, can you connect to it from outside your home? If "yes", then always worry about compromise of the device. Much much better to isolate these things to their own network, prohibit most outbound traffic from them and connect to them from outside your home by using a VPN. Yeah, that makes it harder to connect as you then can't always use the handy iPhone or Android app the vendor provides, but it is much more secure.
You can capture and examine the outbound packets from your device to those domains to see what's actually in them. Could be expected and harmless traffic, but based on those domain names my bet is not "harmless".
And lastly, immediately change any and all passwords associated with that home automation hub. Make sure you have changed any default password the device may have. And then do a thorough Google search for your device's model to see if any default passwords exist and if any known compromises or exploits are published on the web.
-
None of those fqdn look legit to me, off the bat..
Simple look to that maggo site for example shows it blacklisted and virustotal marks it with 1 hit that malware..
Are those udp or tcp to 123? Its possible for example you setup pool for ntp, and those are listed in the pool site?
BRB..
So the maggo IP is listed for ntp in the pool
https://www.ntppool.org/scores/78.46.253.198
so so is the tor
https://www.ntppool.org/scores/188.68.53.92
and
https://www.ntppool.org/scores/37.187.17.67So I would guess your using ntp.pool on that device..
Can you edit what ntp server(s) the hub thing points too? A real company should register their own name for ntp pool and their devices are suppose to use that.. For example the pfsense uses its own..
https://www.pool.ntp.org/vendors.html -
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.
-
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.
-
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.
-
see my edit about the PTR..
-
@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.
-
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.
-
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..
-
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.
-
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!!!
-
@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.
-
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.
-
@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.
-
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. :) -
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..
-
Well, as last resort, one could catch udp/123 and redirect it to localhost like DNS ;)
-
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 -
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.. ;)
-
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..