New cameras from Netgear-Arlo
-
@Dashrender said in New cameras from Netgear-Arlo:
@JaredBusch said in New cameras from Netgear-Arlo:
@scottalanmiller BTW, I know where he went south on this. He has apparently always thought there was some magic secret sauce to the Skype thing. It is true that the node your went through in old Skype jsut handed off address info, it did not mean that a person form that IP the node was on could not attempt to barge the call if they knew the info from port sniffing after the call was initiated. It is simple UDP/UPNP.
Edit: Skype advertised on their FAQ that the signaling nodes knew nothing about the calls. This was true from the sense that the SKype software that was the node did not do anything to know about the calls.
But he took that to mean that the call was somehow secure point to point which it never was (encryption not withstanding).
Wow - I really didn't make any of those assumptions.
Then explain what assumption you are making, because you are claiming something that does not exist.
-
@Dashrender said in New cameras from Netgear-Arlo:
It was a very cleaver trick that worked based on timing.
Camera tells proxy server it's IP address and Port abc that it will talk on
viewer tells proxy server it's IP address and port xyz that it will talk onthe Proxy gives the camera the viewer info, and the viewer the camera info.
Now there's a race condition - the camera will attempt to connect directly to the viewer on the provided information, this pokes a hole in the NAT firewall of the camera network, that will only accept traffic back on the port provided by the camera to the proxy and only from the IP of the viewer (again, just like how web surfing works)
At the same time, the viewer is doing the exactly same thing - the viewer will attempt to connect directly to the camera on the information provided though the proxy, the viewer's firewall will only accept traffic back on the port provided to the viewer to the proxy and only from the IP of the camera (again, just like web surfing)So there is something huge missing here.... you are talking about application data but thinking that it controls the firewall. But it cannot do that. How would a camera proxy tell your firewall to do this? It can't. The only way to do this that I can see is to turn off the main firewall completely unless you are using UPnP or similar.
-
The idea that a proxy could feed information to an application somewhere to listen on a specific port is one thing, but that would do nothing for the outside firewall, leaving the devices unable to communicate.
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
Camera tells proxy server it's IP address and Port abc that it will talk on
It also has to public which one it will listen on, that's the "open firewall" portion. YOu can't talk without listening in TCP/IP.
OK let's step back and answer another question first.
how does web surfing work through a NAT firewall?
A client behind a NAT firewall sends out some traffic to the NAT, it then assigned a port to that traffic and send it to the web server, the webserver gets the traffic along with the port it needs to respond on, and then responds on that port?
The firewall sees the incoming traffic on that port, from the IP it sent traffic out on, on behalf of our client PC, so it knows that it's valid incoming traffic and sends it inside the network to the client.
is this correct?
-
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
-
@Dashrender said in New cameras from Netgear-Arlo:
A client behind a NAT firewall sends out some traffic to the NAT, it then assigned a port to that traffic and send it to the web server, the webserver gets the traffic along with the port it needs to respond on, and then responds on that port?
The firewall sees the incoming traffic on that port, from the IP it sent traffic out on, on behalf of our client PC, so it knows that it's valid incoming traffic and sends it inside the network to the client.
is this correct?
That's correct but missing some of the detection and security pieces. But lacking those pieces, the parts that are there appear to be correct.
-
So from your description of how NAT works, can you now see why your proxy idea would not work?
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
-
@Dashrender said in New cameras from Netgear-Arlo:
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
No, that would require it to breach the security of the firewall. The communications between the two firewalls is invisible to either end point. A proxy in the middle could see that info, and even pass that info as data to the applications. But I'm unclear of how either application could usefully use that information.
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
No, that would require it to breach the security of the firewall. The communications between the two firewalls is invisible to either end point. A proxy in the middle could see that info, and even pass that info as data to the applications. But I'm unclear of how either application could usefully use that information.
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
-
@Dashrender said in New cameras from Netgear-Arlo:
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
Not sure what you mean. Nothing on the inside network would create any predictable port on the outside. Otherwise two Skype clients on the inside would conflict with each other trying to use the same port on the outside. The open port on the outside is a random number from a pool of unused ports. It's random, ephemeral and requires a response (when using a stateful firewall) that matches an ongoing conversation that is already in progress.
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
Not sure what you mean. Nothing on the inside network would create any predictable port on the outside. Otherwise two Skype clients on the inside would conflict with each other trying to use the same port on the outside. The open port on the outside is a random number from a pool of unused ports. It's random, ephemeral and requires a response (when using a stateful firewall) that matches an ongoing conversation that is already in progress.
So now I'm asking for educational purposes.
client pc A makes a connection to www.microsoft.com, then makes a connection to www.google.com and then one to www.scotthatesme.com.
Question, does the NAT firewall assign a different randomly picked port to each connection? or is it the same port since it's the same client behind the firewall?
-
@Dashrender said in New cameras from Netgear-Arlo:
Question, does the NAT firewall assign a different randomly picked port to each connection? or is it the same port since it's the same client behind the firewall?
The question isn't quite right. It makes many, many connections to each one because HTTP is stateless. Each connection gets its own port, randomly assigned on the outside. So it's even less predictable than you were imagining possible.
-
So I was reading JB's link UDP hole punching.
UDP hole punching is a method for establishing bidirectional UDP connections between Internet hosts in private networks using network address translators. The technique is not applicable in all scenarios or with all types of NATs, as NAT operating characteristics are not standardized.
Hosts with network connectivity inside a private network connected via a NAT to the Internet typically use the Session Traversal Utilities for NAT (STUN) method or Interactive Connectivity Establishment (ICE) to determine the public address of the NAT that its communications peers require. In this process another host on the public network is used to establish port mapping and other UDP port state that is assumed to be valid for direct communication between the application hosts. Since UDP state usually expires after short periods of time in the range of tens of seconds to a few minutes,[2] and the UDP port is closed in the process, UDP hole punching employs the transmission of periodic keep-alive packets, each renewing the life-time counters in the UDP state machine of the NAT.
UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the well known STUN server is restricted to receiving data from the well-known server, and therefore the NAT mapping the well-known server sees is not useful information to the endpoint.
In a somewhat more elaborate approach both hosts will start sending to each other, using multiple attempts. On a Restricted Cone NAT, the first packet from the other host will be blocked. After that the NAT device has a record of having sent a packet to the other machine, and will let any packets coming from this IP address and port number through. This technique is widely used in peer-to-peer software and Voice over Internet Protocol telephony. It can also be used to assist the establishment of virtual private networks operating over UDP. The same technique is sometimes extended to Transmission Control Protocol (TCP) connections, with less success due to the fact that TCP connection streams are controlled by the host OS, not the application, and sequence numbers are selected randomly; thus any NAT device that performs sequence number checking will not consider the packets to be associated with an existing connection and drop them
Please explain the difference between my above explanation and this. Where am I missing the boat?
-
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@JaredBusch said in New cameras from Netgear-Arlo:
The next IoT device to add to the botnet
Yup. Get a DVR and use a VPN or SSL not something that uses their online service...
I don't have a problem with using someone's online service as long as my device doesn't need to be published through my own router. Sure if the vendor gets hacked, the hackers could use that connection to try to get back into my network, but I'm a soft target compared to the vendor's network.
Not really.. Not when there's millions of those devices to uses in a DDoS. You all become part of the plan.
I get what you're saying, but normals want remote access their DVRs and setting up access through a cloud provider that then has a secure connection to the DVR is way better than normals trying to setup and maintain VPNs, etc.
Or people could be content to miss whatever it is.
I'm sure people will live and civilisation continue if DVR's and other toys aren't accessible outside home LANs -
@nadnerB said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@JaredBusch said in New cameras from Netgear-Arlo:
The next IoT device to add to the botnet
Yup. Get a DVR and use a VPN or SSL not something that uses their online service...
I don't have a problem with using someone's online service as long as my device doesn't need to be published through my own router. Sure if the vendor gets hacked, the hackers could use that connection to try to get back into my network, but I'm a soft target compared to the vendor's network.
Not really.. Not when there's millions of those devices to uses in a DDoS. You all become part of the plan.
I get what you're saying, but normals want remote access their DVRs and setting up access through a cloud provider that then has a secure connection to the DVR is way better than normals trying to setup and maintain VPNs, etc.
Or people could be content to miss whatever it is.
I'm sure people will live and civilisation continue if DVR's and other toys aren't accessible outside home LANs While it's true that people would learn to cope, but the cat's already out of the bag. Unless ISPs start blocking outbound traffic, you can't stop someone from doing this. Plus there are already probably millions of those things out there, it's not like people are just going to give them up tomorrow if they saw the news and realized they were partly to blame for these types of problems.
I do wish that ISPs were the tiniest bit more altruistic and would take a list from the forensic analysis of large attacks like this and at minimum send emails to their customers who's IP was on the list of those participating in the attacks.
AND while it's much less effective now considering the number of IoT devices available to attack with real IPs, I wish ISPs would drop outgoing packets that have forged return addresses.
