IPC-HDW5231R-ZE trying to contact Amazon IP

[pilotsnipes]

I have 3 IPC-HDW5231R-Z cameras and 1 newer IPC-HDW5231R-ZE.

All working well, and all on their own VLAN after reading a lot about security on this forum. This morning I was playing with my router and decided to use the services of papertrailapp.com to send my router logs to them for easier browsing etc.

It only took a few minutes before I saw this:

Jul 26 14:29:34 ubnt kernel: [VLAN20_IN-default-D]IN=eth1.20 OUT=eth0 MAC=<snip> SRC=192.168.20.14 DST=54.69.152.187 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=53177 DF PROTO=TCP SPT=52536 DPT=2195 WINDOW=14600 RES=0x00 SYN URGP=0 
Jul 26 14:29:36 ubnt kernel: [VLAN20_IN-default-D]IN=eth1.20 OUT=eth0 MAC=<snip> SRC=192.168.20.14 DST=54.69.152.187 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46932 DF PROTO=TCP SPT=52538 DPT=2195 WINDOW=14600 RES=0x00 SYN URGP=0 
Jul 26 14:29:37 ubnt kernel: [VLAN20_IN-default-D]IN=eth1.20 OUT=eth0 MAC=<snip> SRC=192.168.20.14 DST=54.69.152.187 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46933 DF PROTO=TCP SPT=52538 DPT=2195 WINDOW=14600 RES=0x00 SYN URGP=0

Every few seconds, my IPC-HDW5231R-ZE camera (192.168.20.14) keeps trying to contact 54.69.152.187.

Having looked it up, it appears to be an Amazon IP address.

I've had a look at all the services on the camera and nothing else appears to be enabled, so I don't know why or what it is trying to connect to.

And just to be clear, the older IPC-HDW5231R-Z cameras do NOT do this.

Does anyone have any idea?

 

[VorlonFrog]

If I were at home right now, or had a VPN capable laptop at work, I'd tell you exactly where it is. There's a long 'identifier' string in one of the configuration screens, used to multi-cast the camera's availability on your LAN. I believe if you disable that service, it will stop trying to phone home.

 

[reverend]

Do you have any IVS rules set or notifications - there was an older post where notifications weren't working on a Dahua NVR and that was because 2195/tcp was being blocked.

I have multicast disabled on the cams here but still see traffic destined for AWS EC2 instances but on different ports.

I did notice that the P2P option seems to keep re-enabling itself every so often, possibly after firmware upgrades.

This is what I usually see dropped each day - as you can see very different destinations to the 2195/tcp you see:

 

[pilotsnipes]

If I were at home right now, or had a VPN capable laptop at work, I'd tell you exactly where it is. There's a long 'identifier' string in one of the configuration screens, used to multi-cast the camera's availability on your LAN. I believe if you disable that service, it will stop trying to phone home.

I've gone through everything again and I just don't see what, whenever you get a chance would you mind having a look at your camera again to point me in the right direction?

Do you have any IVS rules set or notifications - there was an older post where notifications weren't working on a Dahua NVR and that was because 2195/tcp was being blocked.

Yes I have 2 IVS rules. I know port 2195 needs to be open on the firewall to send ios push notifications (I have a post about this to write up actually soon for others). But I also know from my research that those notifications are sent to apples servers in the 17.0.0.0/8 range.

So that is what I have opened in my edge lite router, and everything is working great (it didn't before) and I am getting ios notifications through my idmss app.

By now I'm wondering why there are more data packets being sent to port 2195 but on amazon servers?

I wonder if those are android push notifications??

 

[pilotsnipes]

So I managed to capture some packets to that amazon ip address in wireshark format.

I ran it through cloudshark (online version of wireshark) but to be honest I don't really know how to read/use it.

However (having allowed the connection in my firewall) the following is what I noticed in one of the packets that was sent/received from the Amazon address.

0..G0../.......
...,....0...*.H.
.......0..1.0...
U....US1.0...U..
..Apple Inc.1,0*
..U...#Apple Wor
ldwide Developer
 Relations1D0B..
U...;Apple World
wide Developer R
elations Certifi
cation Authority
0...171120120648
Z..181220120648Z
0..1'0%....&...,
d....com.dahuate
ch.idmssplus1503
..U...,Apple Pus
h Services: com.
dahuatech.idmssp
lus1.0...U....9Q
Z8T7G56W1+0)..U.
.."ZHEJIANG DAHU
A TECHNOLOGY CO.
,LTD.1.0...U....
US0.."0...*.H...
..........0.....
.......{*s..q. .
...x........Z...
.2..]T(a.......,
R.8S.]5..p...i.o
.....Q.js.I@....
...mS.X.h....H.Q
..g.Ssm....pD..z
J..d5{.....#s.`1
_...X...<K_|.?..
...gw&....R..a].
p..#..oVK.6.fPb.
.\CX._.......f.Z
?..<..9}.....W..
J.....z .|..<u..
Lb./_.].n.b.o($>
^&.Z8!.p.p..u...
...........|0..x
0...U........1J.
.....hs+=.|....0
...U.......0.0..
.U.#..0....'....
.`.....GY.RT..0.
....U. ....0...0
.....*.H..cd..0.
.0....+.......0.
....Reliance on
this certificate
 by any party as
sumes acceptance
 of the then app
licable standard
 terms and condi
tions of use, ce
rtificate policy
 and certificati
on practice stat
ements.05..+....
....)http://www.
apple.com/certif
icateauthority00
..U...)0'0%.#.!.
.http://crl.appl
e.com/wwdrca.crl
0...U...........
0...U.%..0...+..
.....0...*.H..cd
.......0...*.H..
cd.......0....*.
H..cd....~0|..co
m.dahuatech.idms
splus0...app..co
m.dahuatech.idms
splus.voip0...vo
ip.$com.dahuatec
h.idmssplus.comp
lication0...comp
lication0...*.H.
............ 3..
..;...@S.Q..cj.W
p5!..... .....0.
..%.g..j..`....=
.&.43..@)...q9..
.}.C>..z.h

I'll attached the pcap file to see if anyone else knows what how to read it properly.

 

[adamg]

Multiple mentions in the ASCII capture of that frame saying Apple, Apple Push Services.

 

[reverend]

Multiple mentions in the ASCII capture of that frame saying Apple, Apple Push Services.

Also iDMSS Plus which makes you think it's sending the notifications out to Apple and a Dahua instance running in AWS EC2 probably as backup so the notification gets through if the other is blocked?

What happens if you block the connectivity to the Apple IP range and allow it just to the AWS range?

 

[pilotsnipes]

Also iDMSS Plus which makes you think it's sending the notifications out to Apple and a Dahua instance running in AWS EC2 probably as backup so the notification gets through if the other is blocked?

What happens if you block the connectivity to the Apple IP range and allow it just to the AWS range?

I've just blocked any output to apple (17.0.0.0/8) and allowed the connection to Amazon (54.0.0.0/8) and triped the camera tripwire.

Instant packets to amazon, but NO push notification on the phone, and no events in the alarm manager in iDMSS.

So I've re-blocked the amazon ip address. Not sure I'm happy at all about that.

 

[Rockford622]

This post inspired me to check my cameras as well, and come to find out I have similar behavior on 2 of my 4 Dahua cameras:

Jul 30 11:24:39 ubnt kernel: [LAN_IN-1-D]IN=switch0 OUT=eth0 MAC=<> SRC=192.168.1.60 DST=54.241.203.224 LEN=59 TOS=0x00 PREC=0x00 TTL=63 ID=41896 DF PROTO=UDP SPT=45875 DPT=8800 LEN=39

This entry is from one of my IPC-HFW5231E-Z12 cams, and my other one does the same thing, both every 3 seconds. My 2 IPC-HDW5231R-Z cams are fine and do not do this.

This particular IP looks like it's for Amazons AWS service. Just like @pilotsnipes, I looked through all of the cameras configuration pages and see nothing that has anything to do with AWS. Very bizarre.

 

[catcamstar]

I can confirm that not only IPC's, but also VTO/VTH devices are calling out to the same aforementioned ip's with UDP & TCP.

 

[reverend]

Well it seems some of the traffic I saw was the p2p server (Network - Access Platforms - p2p) being enabled.

Now I swear I've turned that off multiple times and it was back on both 5231 cameras so I've turned it off again, rebooted and for now it seems to have stuck.

Interestingly I just probed one of the addresses and you get some debug info from one of the p2p ports:


As for the host on 54.69.152.187 it seems it's wanting an SSL Client cert to authenticate to it on tcp/2195 for the IDMSS Plus application and 10000/tcp is for GESS View Plus from Home - GESS Technologies.

Half makes you wonder if they've left some testing code in these newer firmwares or we're seeing a firmware that's moving across to a new way of working, for example instead of having to have seperate on camera code for each platform maybe they're moving to have all the cameras talk to AWS SNS and then that could push the messages to either iOS or Android devices regardless.

 

[Cam_curious]

If you set the gateway address purposely wrong, ie: 192.168.0.55 for example does that block the camara's
attempt to call home? That should prevent it from communicating outside the local network.

 

[Rockford622]

Well it seems some of the traffic I saw was the p2p server (Network - Access Platforms - p2p) being enabled.

Now I swear I've turned that off multiple times and it was back on both 5231 cameras so I've turned it off again, rebooted and for now it seems to have stuck.

Interestingly I just probed one of the addresses and you get some debug info from one of the p2p ports:

View attachment 31914
As for the host on 54.69.152.187 it seems it's wanting an SSL Client cert to authenticate to it on tcp/2195 for the IDMSS Plus application and 10000/tcp is for GESS View Plus from Home - GESS Technologies.

Half makes you wonder if they've left some testing code in these newer firmwares or we're seeing a firmware that's moving across to a new way of working, for example instead of having to have seperate on camera code for each platform maybe they're moving to have all the cameras talk to AWS SNS and then that could push the messages to either iOS or Android devices regardless.

Interesting. If I hit that port number on the IP my cams are trying to connect to, I get a similar output. I have no [Network - Access Platforms - p2p] menu on my -Z12 cameras, however, to shut that off.

 

[Terk]

I've just started reading this post, do your cameras have the option for "Auto-check for updates" checked in the firmware section? If so does unchecking that effect this behavior, maybe this is how they plan to utilize that option one day? Although the frequency your seeing would be crazy for this.

 

[guykuo]

+1 for the Edgerouter. I have mine set to allow the cameras only NTP access. Other than that, they aren't allowed out on the WAN nor my main LAN's.

I too have all the web options turned off, but there is still some access attempts to the outside world. Glad to have the Edgerouter blocking it all.

 

[SkyLake]

Disable Bonjour and Multicast:

Network -> Bonjour
Network -> Multicast

Give it a try.

 

[catcamstar]

+1 for the Edgerouter. I have mine set to allow the cameras only NTP access. Other than that, they aren't allowed out on the WAN nor my main LAN's.

I too have all the web options turned off, but there is still some access attempts to the outside world. Glad to have the Edgerouter blocking it all.

If you enable logging on these ER rulesets, you can tail -f /var/log/messages and see all these UDP requests flying around.

I also tried with only NTP enabled, but push notifications do require TCP 2195, how did you tackle that?

@SkyLake: not all devices have these options (eg VTO/VTH), although the VTO in particular has an API to enable/disable it: http://192.168.1.110/cgi-bin/configManager.cgi?action=setConfig&Multicast.TS[0].Enable=false ... Even with that one disabled, the VTO keeps calling home UDP wise.

 

[reverend]

Disable Bonjour and Multicast:

Network -> Bonjour
Network -> Multicast

Give it a try.

I don't think it's those as I turn those off when setting cams up - got a feeling it could be one of the following options on newer firmwares:

System - Security
Mobile Push (that could explain the Apple cert being used to AWS servers)
Password Reset (as newer firmwares ask for an email you can use to remotely reset the password so that will be chatty to keep a link up)
Genetec Service (think that's for compatibility with Genetec Security Center but as I don't use that I've turned it off to free up resources)

I've turned off Mobile Push here on the cameras here and so far it seems to have stopped the traffic from all cameras here and it may be worth testing to see if that disables the traffic to both Apple and AWS - if so they have something in that part of the code which may be in the middle of an update which is why you're seeing traffic both ways even though one doesn't appear to do anything (or taking a paranoid view they're logging it all somewhere for statistics and analytics).

 

[guykuo]

I don't allow any push notifications. My "NVR" Mac Pro is the only machine that my Edgerouter rules allow to talk beyond the camera LAN (other than a specific NTP server for the cameras). That Mac Pro runs Security Spy. If I want any notifications, I can have SecuritySpy do it rather than relying on the cameras.

I plan on there always being camera firmware shenanigans and just block everything except what I explicitly allow.

 

[pilotsnipes]

Well it seems some of the traffic I saw was the p2p server (Network - Access Platforms - p2p) being enabled.

Now I swear I've turned that off multiple times and it was back on both 5231 cameras so I've turned it off again, rebooted and for now it seems to have stuck.

As for the host on 54.69.152.187 it seems it's wanting an SSL Client cert to authenticate to it on tcp/2195 for the IDMSS Plus application and 10000/tcp is for GESS View Plus from Home - GESS Technologies.

Half makes you wonder if they've left some testing code in these newer firmwares or we're seeing a firmware that's moving across to a new way of working, for example instead of having to have seperate on camera code for each platform maybe they're moving to have all the cameras talk to AWS SNS and then that could push the messages to either iOS or Android devices regardless.

In my case I definitely have p2p stuff all disabled. The 54.69.152.187 is the only IP address so far that any of the cameras have tried to connect with and its always been on port 2195 (tcp). Seeing as this is also the exact same port number as Apple uses for their push notifications, that does seem like an unlikely coincidence. They must be linked in some way.

I've just started reading this post, do your cameras have the option for "Auto-check for updates" checked in the firmware section

100% auto check updates disabled.

Disable Bonjour and Multicast:

Network -> Bonjour
Network -> Multicast

Both 100% disabled, Outbound packets to amazon still get sent when one of my IVS rules gets triggered (tripwire in my case, have not checked others).

I also tried with only NTP enabled, but push notifications do require TCP 2195, how did you tackle that?

I use an edge router and all cameras are on their own VLAN, so your mileage may vary if you have something else. The rules are quite simple.

Start by making sure ALL packets coming from the cameras get dropped.




Now, only allow a few data packets out, like the apple push notification:






I also found using papertrailapp.com a great way to route all the logs from my router to a service to monitor them much easier. You can of course use the logs from the CLI/GUI on the router but I liked the website approach for me.

Hope that helps.