ET SCAN HID VertX and Edge door controllers discover
-
Hello fellow Netgate community members,
Has anyone else noticed this new IPS/IDS error show up last night?
It looks like someone remotely is attempting to set HID doors to discover mode.
Can anyone confirm?
Attached is screen shot and Virus total scan of invasive actor.
If someone can set door controllers to discover remotely new HID cards can be programmed unknowingly at any time.
Is this a pre programmed back door into mainstream China made HID controllers?
Who else has seen this?
-
@JonathanLee I haven't but this guy has from almost the same IP:-
https://forum.netgate.com/topic/178438/firewall-locks-up-possibly-unbound-config
-
J JonathanLee referenced this topic on
-
@NogBadTheBad I hypothesize this IP block has some invasive actors. HID door controllers, that is scary stuff. . .
-
@JonathanLee said in ET SCAN HID VertX and Edge door controllers discover:
@NogBadTheBad I hypothesize this IP block has some invasive actors. HID door controllers, that is scary stuff. . .
That IP block got added to the Emerging Threats DShield list precisely because it has been used for malicious activities. That's what that entire category of rules is all about -- IP subnets known to be hosting malicious actors doing an assortment of bad things.
As for the door controllers scan, that's why you should NEVER EVER expose anything on the WAN directly. Unless absolutely necessary, never allow remote access into protected networks. And if you must, then use a VPN for that remote access so that anyone accessing your protected networks is authenticated by a certificate. And lockdown that remote access as tightly as possible by IP or IP range or GeoIP as appropriate.
Turning to this particular alert, I suspect you are running the IDS on your WAN, so that's why it saw the alert. But unless you have a firewall rule that is open for UDP on port 4070 and forwarding that traffic to an internal host, there is absolutely nothing to worry about in terms of this traffic. It can't impact you in the least even if you have HID door controllers on your LAN because the default pfSense WAN rule is "deny all inbound". That means deny anything inbound that is not a stateful reply to a session first initiated from an internal host. So, the IDS really wasted CPU cycles scanning and logging this because your firewall drops it anyway. That's my entire point about putting IDS/IPS on internal interfaces. Now if you are just curious as to what is out there, then you can run IDS/IPS on the WAN just to see the traffic. Of course, you can accomplish almost the same sort of thing by logging the default deny rule on the WAN and then scanning the firewall logs to see what type of unsolicited traffic is dropped.
-
@bmeeks I agree I actually reported this IP and the .31 to IC3 because of this blanket type HID door discovery enumeration within my IP blocks. That attack one is new to me. I admit I do like to watch the WAN as you can monitor what's going on very well with the IPS/IDS. Again it takes some time to get it useable so you can see and have it no disable your internet access as you have seen with my many reports :)
