Liste des Groupes | Revenir à se design |
On 12/12/2024 12:32 PM, Edward Rawde wrote:>Is there any reason the camera can't talk to a phone that is also>
hosted by the customer's access point?
>
If you want to let the camera access a phone that is NOT "local",
then let the user subscribe to a DynDNS service -- provided by
any number of competing firms (even the manufacturer -- via a nice
clean OPEN interface).
Inbound is problematic for various reasons.
Do you want your cameras accepting inbound connections from anywhere in the world?
Vendors have no problem selling "hubs" as a prerequisite to talk to
their devices. Why can't the hub implement a packet filter?
Use that as a selling point: the hub can act to protect the
local network (for a fee!!) while their access point/router likely
has not been reliably configured for that purpose.
>Ok they don't have access credentials but there's still a risk of an 0-day in a camera system which isn't going to get any more>
firmware updates.
Simply putting the camera (or any device manufactured by someone who
may or may not be trustworthy) on your "internal network puts you
at risk.
>
E.g., I can open an outbound connection to hostile_actor.com and let
an external agent act as command-and-control, telling me (the camera)
what to do ON THE INTERNAL NETWORK.
>
This traffic can be disguised to look innocuous. E.g., resolving
"whatshouldIdo.hostile_actor.com" can deliver data to the camera that
can be augmented by then resolving "whatELSEshouldIdo.hostile_actor.com".
Results can be delivered to the external agency by resolving
"thepasswordisFOOBAR.hostile_actor.com", etc.
>
Or, open an HTTP connection to hostile_actor.com and anyone looking
through the logs (ha!) would just think a user visited a website of
with an oddly suspicious domain name. (So, buy up yahooo.com,
goggle.com, etc.)
>I would do this myself because I can use a firewall to restrict inbound as necessary and I can quickly add any IP or network>
attempting brute force to a blacklist.
But most people have no interest in that.
Hence the value of a "hub".
>
I "hide" my file server behind a particular "knock sequence" that is
only known to folks who should need access to it. Trying to probe
the IP address gets you no information -- it looks like there isn't
a machine AT that IP address.
>
Of course, the machine SEES all attempts to connect to it. And, which
ports and protocols are being used -- and in which sequence -- from every
potential external IP. So, if it sees the right combination of accesses
in a particular time frame, it will THEN respond to a connection attempt
for a particular service. Or, "callback" on a preassigned port on
the "caller's" IP address (as many ISPs frown on operating a server...
but, no constraints on ACCESSING some external service -- even if doing
so at the behest of said service!)
>
Meanwhile, other attempts AT THE SAME TIME still see a "dangling wire".
>
Once a connection is granted, there are no limits on what can be
transfered (set up a tunnel and all of those transactions are hidden)
>Most people just want the pictures on their phone wherever they are and they may wrongly assume that it's impossible for the>
pictures to be viewed by anyone other than themselves.
<https://www.shodan.io/search?query=camera>
>
Even if you can't (easily) access the video, the fact that someone has
INSTALLED a camera (five cameras??) has informational value.
>
Les messages affichés proviennent d'usenet.