While playing around with AWS CloudWatch Log Insights to analyze VPC flow logs, I thought of a couple of fun ways to identify (probably) malicious traffic. Finding Vulnerability Scanners These are the guys that hammer your box looking for anything from silly SQL injection attacks (so 2005) to CSRF vulnerabilities. The tell: look for hosts that reuse the same source port. The Query filter (srcPort > 1024 and srcAddr !
I recently got an email from a viewer of my Practical Networking course who asked how the TCP/IP networking terms I used mapped to the Open Systems Interconnect (OSI) model. First, a bit of background. The OSI model is a generic networking model that is supposed to describe conceptually how networks carry data. Within the last four decades or so, 99.9% of all computer networking curricula for beginners has started by rehashing the OSI model.
Puzzled by networking on AWS? Check out my AWS networking deep dive series! AWS Networking Deep Dive: Route 53 DNS Configure Route 53 for any domain name, and configure health checks and routing policies. AWS Networking Deep Dive: Virtual Private Cloud (VPC) Create secure and scalable VPCs. Implement multi-VPC topologies, build peering connections, network address translation, and more. AWS Networking Deep Dive: Elastic Load Balancing (ELB) Securely configure load balancing for any public or private application.
You probably know the popular Google DNS server IP addresses by heart: 184.108.40.206 and 220.127.116.11. Before those were around you might have even used Level3’s 18.104.22.168 and 22.214.171.124. Of course, everyone else uses these too, which means these popular servers are under a pretty heavy load. Fortunately, there are faster public DNS servers out there. Much faster. 101 DNS Servers I’ve compiled a list of 101 public DNS servers (PDF), sorted in order of fastest to slowest (for me).
youtube Z7IwF1oSA5M Learn to subnet in your head in just seconds! This clip is from my Pluralsight course Basic Networking for CCNP Routing and Switching 300-101 ROUTE.
I think it’s time to stop using the term “network function virtualization”. Why? Because it doesn’t exist, at least not in the way the term suggests. The term is a category error, and when people try to make sense of the term, confusion and frustration ensue. Think of it like this: what’s the difference between a “virtual network function” and a “non-virtual network function”? For example, how is “virtual IP forwarding” different than “non-virtual IP forwarding?
If you haven’t learned IPv6 yet, well, you’re not the only one. In December 2016, IPv6 (as we know it today) turned 18 years old. Children who were in the womb when RFC 2460 was being drafted are now old enough to vote, get married, and purchase firearms in some states. In honor of IPv6’s 18th birthday, allow me to share my theories on why people have been so slow to adopt it.