CloudShark released a new packet capture challenge for this Christmas season! Unfortunately, I don’t have the time to participate right now, but I wanted to reshare this for those of you that do. I also wanted this to serve as a reminder for me to come back to it later. Good luck!
Moving to S3 I’m currently in the process of moving my blog to Amazon S3. I’m not the first to do this and I won’t be the last. My reasons for this are similar to everyone else. Wordpress is an excellent blogging and site platform. I have really enjoyed working with it and getting to know its innards. As I continuously evaluate the purpose of my site though, I have to keep the technology behind it in sync.
Yesterday I sat for the AWS Solutions Architect Associate exam and passed! Thanks to the teams at A Cloud Guru and WhizLabs for the training.
Well, Tom and the team at CloudShark have put together an excellent packet capture challenge on their blog once again. It has actually been awhile since I’ve dug into a capture due to my recent shift in focus to Amazon Web Services, so this was a lot of fun for me. I feel like once you’re a “packet junkie” you are always one!
<span style="color: #ff0000;">*SPOILER ALERT*</span> The rest of this post describes the challenge and the process I followed for solving the challenge.
I no longer have a need for the Cisco Meraki MX64. It was only used for testing. It is in working condition. It has been reset to defaults and is unclaimed. It comes in the original box with the power and network cable. See the listing here.
We spend a lot of time monitoring our internal networks. Obviously, this is where we have the most tools at our disposal and where our actual responsibility lies. But, to provide good service to our customers and/or end users we also need to be aware of what is happening at our Internet providers and above. If you have global services then I recommend you monitor the submarine cables as well. For example, this was the latest submarine cable damage that impacted regions in Africa.
Performance and security is always a balancing act, but in the case of DNSSec it’s a no-brainer. In short, DNSSec allows a client to trust the domain owner when performing DNS queries. It’s another step to defending your domain (and subsequently your content and network) from the bad guys. An added benefit is there is no noticeable impact to performance!
CloudFlare just released a great blog post on their DNSSec offerings and how they are expanding.
So, all credit goes to Colm MacCárthaigh for this one. I think his recent post on Shuffle Sharding is so go it deserves a share and a place on my blog to serve as a reminder for me from time-to-time. This is one way AWS achieves the level of reliability and stability it has for its customers. Some of the methodology can easily be applied to traditional and on-prem infrastructure though as well.
Symptoms Website randomly goes down a few times a week Server stopped responding Network and CPU logs show a small spike, but not enough to lock up a server
Stopping and starting the server resolves the problem
Details This pattern repeated several weeks until the customer grew tired of rebooting the server. The evidence did not seem to lead to a system issue or network or security security problem such as a denial of service.
