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!
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.
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.
I have attended multiple Wireshark webinars presented by Riverbed and leaders in the field. They title this series “Return to the Packet Trenches” with some sort of variation or subtitle for the different sessions. I always walk away with something new. This latest webinar was no exception. It reviewed several CLI options for creating, analyzing, and editing packet captures. I highly recommend attending these webinars if you have any interest in Wireshark and staring at packets.
I love packets and tracing issues at a micro level. However, like I stated in Preparing for the Capture you need to know where to capture before you can dig into the bits an bytes. In order to know where to capture you must understand your service/app/network. The best way to do that is to diagram your service.
I generally avoid creating posts that are specific to my employer, but this is already public knowledge and it was fun to be involved even in a small way. So often us “packet junkies” only get to see the results of our work through the lens of smoothly flowing packets. If we’re lucky we might hear the delight in our customer’s voice over the phone or get a nice email sharing the results.
Performance monitoring is two-fold. There is proactive performance monitoring and reactive investigation. The majority of my posts and case studies reflect the latter. This post is more related to the former. Services on premise typically rely on SLAs, NetFlow, scripts, synthetic transactions and more to provide monitoring and alerting. While some of this is possible in the cloud to keep track of specific pieces, you first need a good foundation by knowing if the underlying technology by your cloud provider is operating as expected.
- OLDER POSTS
- page 1 of 4