Networking

Think about the services that only a few people need to access, but they need to be accessible from anywhere, over the internet. The internet is a giant untrusted monster network, full of evil people actively trying to harm you. If only a few people (let’s say in the ten-thousands) need to access your service, why do you make the service accessible to billions? It’s so asymmetrical. VPN Gateways VPN Gateways! They’re great! They sit on the edge of your network, and they let you access all your internal stuff! But if you want someone to be able to connect to your VPN over the internet, the VPN gateway itself must be publicly accessible. Yes, you likely have authentication on your gateway such as an IPSec Pre-Shared Key, and/or a username and password. But your gateway is still internet-facing, and let’s just say there are no guarantees for security. ...

There is very peculiar behavior when a Windows DNS server is starting up. With the right request timing can result in a client with a poisoned DNS cache for that lasts for 1 hour (by default). That just seems crazy to me. To reproduce the issue, I loaded up a Windows DNS server with hundreds of zones and hundreds of records in each zone to simulate a reasonably large environment where loading the DNS database when the DNS server service starts actually takes a few seconds instead of near-instantly. ...

Port knocking is security through obscurity. Now normally, I say anything to do with security through obscurity is bad practice if that’s the only thing you’re relying on. The idea is that it’s not going to outright secure your network, but it’s going to drastically reduce the risk of an attack during an attacker’s discovery phase. Hiding valuables in your vehicle when it’s left unattended will reduce the likelihood of a criminal passerby from breaking into your vehicle. Likewise, keeping ports closed when they’re not actively in use will reduce the likelihood of a criminal portscanning your network to find your open SSH (Sometimes Secure Hell), RDP (Ransomware Deployment Protocol), or god forbid your HTTP or TELNET ports. To keep the analogy going, we are effectively keeping the open ports in the car, but we are throwing them in the glovebox. ...

Question: How long can an idle TCP connection remain open? Answer: According to the standard, indefinitely, however, most implementations impose a connection timeout. TCP keepalive is a feature that isn’t defined in the TCP specification, as crazy as that might sound. RFC1122 under section 4.2.3.6 mentions keepalives instead. Excerpt from RFC1122 4.2.3.6 TCP Keep-Alives Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off. Question: Why do we have TCP keepalives then? ...

False assumptions in distributed computing happen all the time, and they often have high costs. Peter Deutsch asserts that there are at least 7 false assumptions system architects and software developers are likely to make, and James Gosling later added an eighth fallacy. The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn’t change There is one administrator Transport cost is zero The network is homogeneous We’ll look through each one, why it’s relevant when designing and operating any distributed application, and explain what you should genuinely assume (the worst). ...