New cameras from Netgear-Arlo
-
@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.
