Secure Digital Life #67
Recorded on June 5, 2018 at G-Unit Studios in Rhode Island!
- Check out our On-Demand material! Some of our previously recorded webcasts are now available On-Demand at: securityweekly.com/ondemand.
- Ticket Sales are open for Social Engineering RI Conference. Saturday, June 6th at Salve Regina University in Newport RI. Go to - http://se-ri.org/ to register! We are giving away 2 tickets to this conference. Please send your best meme of Paul and Larry to email@example.com.
- How do you feel about User and Entity Behavior Analytics? What about your SEIM? Check out Logrhythm's webcast on June 14th at 3:00pm-4:00pm.
Topic: SNAT and PAT
Run for the Border, SNAT and PAT
- So, as we are well aware, IPv4 addresses have run out. The entire 2^32-1 address space has essentially been issued. Yesterday's news.
- The solution to the IPv4 problem had two approaches, 1 was IPv6, a 128 bit addressing scheme that didn't really appeal to the masses (think 2001:A00:1F1A:1771::1, kind of thing). The other was the use of a protocol called NAT, Network Address Translation.
- NAT had several sub protocols embedded in it but basically the two that emerged are called Static NAT (SNAT) and PAT (port address translation).
- The whole idea was that private addresses (that is 10.0.0.0/8; 172.16.0.0/16; and 192.168.0.0/24) could be used instead of the use of public IPv4 addresses which were never going to be sufficient for the whole world and IoT.
- So, if you have 10.0.0.0/8 that means you can have internally 2^24-1 (16,777,215) addresses and if that's not enough hey, use 172.16.0.0/16 next and you have another 65,536 addresses waiting for you.
- So, the problem is not having enough private addresses, it's having enough public addresses. All those (4,294,967,295) had been issued by ARIN back in 2015 and basically, that's it. Certainly classless interdomain routing (CIDR) had helped but there just weren't any more.
- The idea of NAT was that if private addresses, could be used internally, maybe not every single device would need a public address. That worked, for about 5 minutes. Initially, we could just wall off our border with a nat statement and that meant that we used SNAT (1:1 addresses) so that internal private addresses, could have external public addresses.
- ip nat inside source static 10.1.1.80 22.214.171.124
- is a cisco statement that allows the equation of one internal to one external device.
- That was great, but soon, all those other devices inside wanted to phone home (think Windows update) and the advent of IoT makes the idea almost silly. Drone swarm anyone?
- Enter PAT. Port address translation took advantage of something else every tcp/ip stack had, a 16 bit address space for ports. That means 65536 ports are possible on every wintel type machine using tcp/ip and most of them are not in use.
- Interlude to layer 4 of the OSI model. The transport layer of the OSI model allows for source and destination ports in the header for l4. That means that the destination port is pretty important in all cases but the source port? Well, it matters but what if a device could mod that packet a bit.
Enter PAT. So, pat takes a packet like this
l34s: 10.1.1.128:3017 l34d: 126.96.36.199:53
And mods it at the NAT translation point in the system. Now in SNAT it mods it like this
- So, in that model, you have own two addresses (at least) that are public. But PAT does something different, it uses only a single (or a pool) of external addresses. So, if we own 188.8.131.52 and that is the outside of our router in the public space, we can use that.
L34s: 10.1.1.80:3017 L34d: 184.108.40.206:53
- So, now a table is created which says:
- anything for port 3017 is really translated as
- L34S: 10.1.1.80:3017
right there at the border. (note it doesn't have to be the same port)
- So, essentially PAT can allow that 1 public address to support a large number of internal private addresses. This is not the same thing as open port forwarding.
- The negatives are:
- You can't directly access those internal devices from outside (maybe a positive) so it's just one way and acks.
- There is no clear indication on the internet where the traffic originated other than the border and the XLATE table of translations may not persist very long.
- The upside is that you can share addresses on your border and host many, many private ips inside.
- Obvious question: Does PAT affect performance? Well, think of it this way, if you had 65000 static ips and you set them all up on one interface using SNAT, it would actually be the same bandwidth demand as if you used PAT. If you use multiple interfaces (load balancing), then maybe you have 10 drops at the border, ok, so you can still manage PAT just by using rules so that each drop handles 6500 or so.
NOTE/RANT: USE sequential POWERS OF TWO for your DHCP! That means don't use things like 1-100 for dhcp. Use 64-95 or whatever. This is because when you write PAT rules, you can't control decimal based groups. Always use powers of two in sequential blocks (1100 0000) or you will be sorry.